[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fc36d066-c432-e7d2-312f-a0a592446fe2@fnarfbargle.com>
Date: Thu, 5 Nov 2020 16:05:32 +1100
From: Brad Campbell <brad@...rfbargle.com>
To: Guenter Roeck <linux@...ck-us.net>,
Andreas Kemnade <andreas@...nade.info>,
Jean Delvare <jdelvare@...e.com>
Cc: Arnd Bergmann <arnd@...db.de>, rydberg@...math.org,
linux-hwmon@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
hns@...delico.com
Subject: Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()
On 5/11/20 3:43 pm, Guenter Roeck wrote:
> On 11/4/20 6:18 PM, Brad Campbell wrote:
>> On 5/11/20 12:20 am, Andreas Kemnade wrote:
>>> On Tue, 3 Nov 2020 16:56:32 +1100
>>> Brad Campbell <brad@...rfbargle.com> wrote:
>>
>>>> If anyone with a Mac having a conventional SMC and seeing issues on 5.9 could test this it'd be appreciated. I'm not saying this code is "correct", but it "works for me".
>>>>
>>> Seems to work here.
>>> dmesg | grep applesmc
>>>
>>> [ 1.350782] applesmc: key=561 fan=1 temp=33 index=33 acc=0 lux=2 kbd=1
>>> [ 1.350922] applesmc applesmc.768: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
>>> [ 17.748504] applesmc: wait_status looping 2: 0x4a, 0x4c, 0x4f
>>> [ 212.008952] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
>>> [ 213.033930] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
>>> [ 213.167908] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
>>> [ 219.087854] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
>>>
>>> Tested it on top of 5.9
>>
>> Much appreciated Andreas.
>>
>> I'm not entirely sure where to go from here. I'd really like some wider testing before cleaning this up and submitting it. It puts extra checks & constraints on the comms with the SMC that weren't there previously.
>>
>> I guess given there doesn't appear to have been a major outcry that the driver broke in 5.9 might indicate that nobody is using it, or that it only broke on certain machines?
>>
>> Can we get some guidance from the hwmon maintainers on what direction they'd like to take? I don't really want to push this forward without broader testing only to find it breaks a whole heap of machines on the basis that it fixes mine.
>>
>
> Trick question ;-).
>
> I'd suggest to keep it simple. Your patch seems to be quite complicated
> and checks a lot of bits. Reducing that to a minimum would help limiting
> the risk that some of those bits are interpreted differently on other
> systems.
>
> Guenter
>
>
Appreciate the feedback.
This would be the bare minimum based on the bits use in the original code. If the original code worked "well enough" then this should be relatively safe.
Tested on both machines I have access to.
Regards,
Brad
View attachment "smc.patch.9" of type "text/plain" (5474 bytes)
Powered by blists - more mailing lists