user/sven/linux.git/drivers/macintosh, branch v4.19.170

drivers/macintosh: Fix memleak in windfarm_pm112 driver

2020-06-22T07:05:29Z

commit 93900337b9ac2f4eca427eff6d187be2dc3b5551 upstream. create_cpu_loop() calls smu_sat_get_sdb_partition() which does kmalloc() and returns the allocated buffer. In fact it's called twice, and neither buffer is freed. This results in a memory leak as reported by Erhard: unreferenced object 0xc00000047081f840 (size 32): comm "kwindfarm", pid 203, jiffies 4294880630 (age 5552.877s) hex dump (first 32 bytes): c8 06 02 7f ff 02 ff 01 fb bf 00 41 00 20 00 00 ...........A. .. 00 07 89 37 00 a0 00 00 00 00 00 00 00 00 00 00 ...7............ backtrace: [<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat] [<000000003010fcb7>] .pm112_wf_notify+0x104c/0x13bc [windfarm_pm112] [<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180 [<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90 [<00000000131d8149>] .wf_thread_func+0x114/0x1a0 [<000000000d54838d>] .kthread+0x13c/0x190 [<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64 unreferenced object 0xc0000004737089f0 (size 16): comm "kwindfarm", pid 203, jiffies 4294880879 (age 5552.050s) hex dump (first 16 bytes): c4 04 01 7f 22 11 e0 e6 ff 55 7b 12 ec 11 00 00 ...."....U{..... backtrace: [<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat] [<00000000b94ef7e1>] .pm112_wf_notify+0x1294/0x13bc [windfarm_pm112] [<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180 [<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90 [<00000000131d8149>] .wf_thread_func+0x114/0x1a0 [<000000000d54838d>] .kthread+0x13c/0x190 [<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64 Fix it by rearranging the logic so we deal with each buffer separately, which then makes it easy to free the buffer once we're done with it. Fixes: ac171c46667c ("[PATCH] powerpc: Thermal control for dual core G5s") Cc: stable@vger.kernel.org # v2.6.16+ Reported-by: Erhard F. Signed-off-by: Michael Ellerman Tested-by: Erhard F. Link: https://lore.kernel.org/r/20200423060038.3308530-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman

macintosh: windfarm: fix MODINFO regression

2020-03-18T06:14:21Z

commit bcf3588d8ed3517e6ffaf083f034812aee9dc8e2 upstream. Commit af503716ac14 made sure OF devices get an OF style modalias with I2C events. It assumed all in-tree users were converted, yet it missed some Macintosh drivers. Add an OF module device table for all windfarm drivers to make them automatically load again. Fixes: af503716ac14 ("i2c: core: report OF style module alias for devices registered via OF") Link: https://bugzilla.kernel.org/show_bug.cgi?id=199471 Reported-by: Erhard Furtner Tested-by: Erhard Furtner Acked-by: Michael Ellerman (powerpc) Signed-off-by: Wolfram Sang Cc: stable@kernel.org # v4.17+ Signed-off-by: Greg Kroah-Hartman

macintosh: therm_windtunnel: fix regression when instantiating devices

2020-03-05T15:42:18Z

commit 38b17afb0ebb9ecd41418d3c08bcf9198af4349d upstream. Removing attach_adapter from this driver caused a regression for at least some machines. Those machines had the sensors described in their DT, too, so they didn't need manual creation of the sensor devices. The old code worked, though, because manual creation came first. Creation of DT devices then failed later and caused error logs, but the sensors worked nonetheless because of the manually created devices. When removing attach_adaper, manual creation now comes later and loses the race. The sensor devices were already registered via DT, yet with another binding, so the driver could not be bound to it. This fix refactors the code to remove the race and only manually creates devices if there are no DT nodes present. Also, the DT binding is updated to match both, the DT and manually created devices. Because we don't know which device creation will be used at runtime, the code to start the kthread is moved to do_probe() which will be called by both methods. Fixes: 3e7bed52719d ("macintosh: therm_windtunnel: drop using attach_adapter") Link: https://bugzilla.kernel.org/show_bug.cgi?id=201723 Reported-by: Erhard Furtner Tested-by: Erhard Furtner Acked-by: Michael Ellerman (powerpc) Signed-off-by: Wolfram Sang Cc: stable@kernel.org # v4.19+ Signed-off-by: Greg Kroah-Hartman

macintosh/windfarm_smu_sat: Fix debug output

2019-12-01T08:16:37Z

[ Upstream commit fc0c8b36d379a046525eacb9c3323ca635283757 ] There's some antiquated debug output that's trying to do a hand-made hexdump and turning into horrible 1-byte-per-line output these days. Use print_hex_dump() instead Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin

macintosh: therm_windtunnel: drop using attach_adapter

2018-08-24T12:42:42Z

As we now have deferred probing, we can use a custom mechanism and finally get rid of the legacy interface from the i2c core. Signed-off-by: Wolfram Sang Acked-by: Michael Ellerman

macintosh/via-pmu: Disambiguate interrupt statistics

2018-07-31T09:56:43Z

Some of the event counters are overloaded which makes it very difficult to interpret their values. Counter 0 is supposed to report CB1 interrupts but it can also count PMU_INT_WAITING_CHARGER events. Counter 1 is supposed to report GPIO interrupts but it can also count other events (depending upon the value of the PMU_INT_ADB bit). Disambiguate these statistics with dedicated counters for GPIO and CB1 interrupts. Comments in the MkLinux source code say that the type 0 and type 1 interrupts are model-specific. Label them as "unknown". This change to the contents of /proc/pmu/interrupts is by necessity visible in userland. However, packages which interact with the PMU (that is, pbbuttonsd, pmac-utils and pmud) don't open this file. AFAIK, user software has no need to poll these counters. Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: Michael Ellerman

macintosh/via-pmu: Clean up interrupt statistics

2018-07-31T09:56:43Z

Replace an open-coded ffs() with the function call. Simplify an if-else cascade using a switch statement. Correct a typo and an indentation issue. Tested-by: Stan Johnson Signed-off-by: Finn Thain Reviewed-by: Geert Uytterhoeven Signed-off-by: Michael Ellerman

macintosh/via-pmu: Replace via-pmu68k driver with via-pmu driver

2018-07-31T09:56:42Z

Now that the PowerMac via-pmu driver supports m68k PowerBooks, switch over to that driver and remove the via-pmu68k driver. Tested-by: Stan Johnson Signed-off-by: Finn Thain Reviewed-by: Geert Uytterhoeven Acked-by: Geert Uytterhoeven Signed-off-by: Michael Ellerman

macintosh/via-pmu68k: Don't load driver on unsupported hardware

2018-07-31T09:56:42Z

Don't load the via-pmu68k driver on early PowerBooks. The M50753 PMU device found in those models was never supported by this driver. Attempting to load the driver usually causes a boot hang. Signed-off-by: Finn Thain Reviewed-by: Michael Schmitz Acked-by: Geert Uytterhoeven Signed-off-by: Michael Ellerman

macintosh/via-pmu: Explicitly specify CONFIG_PPC_PMAC dependencies

2018-07-31T09:56:41Z

At present, CONFIG_ADB_PMU depends on CONFIG_PPC_PMAC. When this gets relaxed to CONFIG_PPC_PMAC || CONFIG_MAC, those Kconfig symbols with implicit deps on PPC_PMAC will need explicit deps. Add them now. No functional change. Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: Michael Ellerman