lkml.org 
[lkml]   [2022]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/3] dt-bindings: hwmon: Add IBM OCC bindings
From

On 8/10/22 02:43, Krzysztof Kozlowski wrote:
> On 09/08/2022 22:42, Eddie James wrote:
>>>> + ibm,inactive-on-init:
>>>> + description: This property describes whether or not the OCC should
>>>> + be marked as active during device initialization. The alternative
>>>> + is for user space to mark the device active based on higher level
>>>> + communications between the BMC and the host processor.
>>> I find the combination property name with this description confusing. It
>>> sounds like init of OCC and somehow it should be inactive? I assume if
>>> you initialize device, it is active. Or maybe the "init" is of something
>>> else? What is more, non-negation is easier to understand, so rather
>>> "ibm,active-on-boot" (or something like that).
>>
>> Well, the host processor initializes the OCC during it's boot, but this
>> document is describing a binding to be used by a service processor
>> talking to the OCC. So the OCC may be in any state. The init meant
>> driver init, but I will simply the description and change the property
>> to be more explicit: ibm,no-poll-on-init since that is what is actually
>> happening. Similar to the FSI binding for no-scan-on-init.
> no-scan-on-init is not a good example. It wasn't even reviewed by Rob
> (looking at commit). In both cases you describe driver behavior which is
> not appropriate for bindings. Instead you should describe the hardware
> characteristics/feature/bug/state which require skipping the initialization.


Yep... there is no such hardware thing. The driver should never poll the
OCC during driver initialization (since host state isn't known), but it
did for the first couple of years of the drivers existence because we
didn't catch that it could cause problems. I submitted a patch to change
the driver behavior, but it does change the user space interface, so the
argument is that the new behavior should be optional.

I suppose one correct way to control that would be a module parameter,
but that really doesn't work well on embedded-like systems like ours.

Thanks very much for your feedback Krzysztof. Joel, any suggestions here?

Eddie


>
>
> Best regards,
> Krzysztof

\
 
 \ /
  Last update: 2022-08-10 15:57    [W:0.075 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site