On Mon, Feb 27, 2017 at 3:48 AM, Jan Lübbe <jlu@xxxxxxxxxxxxxx> wrote:
> On Di, 2017-02-21 at 15:57 +0100, Richard Leitner wrote:
>> >>> This is a lot of properties. Are you really finding a need for all of
>> >>> them? Is this to handle h/w designers too cheap to put down the EEPROM?
>> >>> Maybe better to just define an eeprom property in the format the h/w
>> >>> expects.
>> >>
>> >>
>> >> I need about 15 of these properties. I just exposed them all to dt because I
>> >> thought they could be useful for somebody.
>> >>
>> >> Yes, these are a subset of the settings which can be configured via an
>> >> external EEPROM (By strapping some pins of the hub you can select if it
>> >> loads its configuration from an EEPROM or receives it via SMBus).
>> >>
>> >> My first thought was also to define only a byte array in dt, but IMHO these
>> >> options are much more readable and convenient for everybody. I'd also be
>> >> fine with removing the properties I don't need from dt. But that may lead to
>> >> future patches where somebody needs some of the options not already exposed
>> >> to dt.
>> >
>> > Okay. It's really a judgement call. If this is most of the settings,
>> > then it's fine. If it was only a fraction of them, then maybe we'd
>> > want to do just a byte array. Sounds like it is the former.
>>
>> In fact there are 6 more parameters available according to the
>> datasheet. So how should I proceed here? Remove the one's I'm not using
>> at the moment, leave them as they are or add the missing 6 too?
>
> Rob, several of these properties look more like configuration rather
> than HW description ('skip-config', '*-id', 'manufacturer', 'product',
> 'serial'). Is DT the right place for this? I would expect userspace to
> provide the configuration.
Configuration can be okay. The test I use is more who needs to
set/control these properties? Would an end-user want to control them?
If so, then they should be sysfs controls. If they are configuration
for a particular design, then DT is fine. Given these are all
typically EEPROM properties, then they aren't really end-user controls
and belong in DT.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
