setting driver properties for a particular device

[Andriy Gapon]

On 30/05/2019 00:40, Ian Lepore wrote:
> On Wed, 2019-05-29 at 13:31 +0300, Andriy Gapon wrote:
>> On 29/05/2019 13:29, Michael Zhilin wrote:
>>> Hi,
>>>
>>> There are kenv and sysctl. Is it far from what you are looking for?
>>
>> No.  When I said programmatically, I meant programmatically from
>> within the kernel.
>>
> 
> Hmmm.  Whatever you do, it's going to amount to a conspiracy of
> agreement between the driver that wants to set this info and the driver
> that is expected to act on it.  So if you don't use the existing hints
> mechanism, then you'll have to invent something new, and the gpioled
> driver will have to be updated to also check that new mechanism to see
> if there is any config info there that affects it.  I'm not sure that's
> a big win over the slight inelegance of crafting a hint string at
> runtime.

I think you are right.
Probably, I am going to add a helper function to make that job easier.
E.g., something like
  set_dev_hint(device_t dev, const char *name, const char *val);
or perhaps
  set_dev_hint(device_t dev, const char *name, const char *fmt, ...);

>>> On Wed, May 29, 2019 at 1:19 PM Andriy Gapon <avg at freebsd.org
>>> <mailto:avg at freebsd.org>> wrote:
>>>
>>>     On 23/05/2019 14:15, Andriy Gapon wrote:
>>>     > Author: avg
>>>     > Date: Thu May 23 11:15:22 2019
>>>     > New Revision: 348153
>>>     > URL: https://svnweb.freebsd.org/changeset/base/348153
>>>     >
>>>     > Log:
>>>     >   gpioled: add a new hint for initial state
>>>     >   
>>>     >   hint.gpioled.%d.state determines the initial state of the
>>> LED when the
>>>     >   driver takes control over it:
>>>     >     0 - the LED is off
>>>     >     1 - the LED is on
>>>     >    -1 - the LED is kept as it was
>>>
>>>     By the way, can anyone suggest a mechanism to set device
>>> properties like this
>>>     one _programmatically_ ?
>>>
>>>     I am thinking of a case where I know exactly how everything is
>>> wired on a
>>>     platform.  And there is no FDT or alike support for it.  And
>>> hints are not
>>>     possible to set up correctly (e.g., bus numbers may float). 
>>> So, I want to
>>>     create a gpioled child on a specific bus and I want to set some
>>> properties for
>>>     the device.
>>>     Of course, I can probably do something like
>>> kern_setenv("hints.foo.X.bar", ...)
>>>     using the child's name and unit number.  But that feels a bit
>>> cumbersome.
>>>
>>>     And this question is not about gpioled specifically.
>>>
>>>     IVARs is definitely not the right mechanism, because it is
>>> about bus-specific
>>>     properties of devices on the bus.  So, it is not aware of
>>> properties specific to
>>>     a driver that attaches to a child device.


-- 
Andriy Gapon