Date: Wed, 5 Jun 2019 16:21:18 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Ian Lepore <ian@freebsd.org>, Michael Zhilin <mizhka@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: setting driver properties for a particular device Message-ID: <5ac39749-3aca-c4c9-56d2-b17d77ca318b@FreeBSD.org> In-Reply-To: <def5460b7e07b24d119320d65d72532950791615.camel@freebsd.org> References: <201905231115.x4NBFMSu037564@repo.freebsd.org> <523f92fe-c106-db6b-00d9-356913fdca5d@FreeBSD.org> <CAF19XBJws3ESf9voiW655PH=z1a-rVEgF903=bm7oJ4DGWNy5w@mail.gmail.com> <1a8fe3f8-a4d7-44f9-2b90-8b70e158f661@FreeBSD.org> <def5460b7e07b24d119320d65d72532950791615.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org >>> <mailto:avg@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5ac39749-3aca-c4c9-56d2-b17d77ca318b>