On 10/31/24 1:16 PM, Conor Dooley wrote: > On Sat, Oct 26, 2024 at 04:18:37PM +0100, Jonathan Cameron wrote: >> On Wed, 23 Oct 2024 15:59:12 -0500 >> David Lechner <dlechner@xxxxxxxxxxxx> wrote: >> >>> Add a new binding for using a PWM signal as a trigger for SPI offloads. >> >> I don't have a better suggestion for this, but it does smell rather like >> other bridge binding (iio-hwmon for example) where we have had push back on >> representing something that doesn't really exist but is just a way to >> tie two bits of hardware together. Those kind of exist because we snuck >> them in a long time back when no one was paying attention. > > I dunno. iio-hwmon to me is a particularly strange one, because it is > the exact same device being used in different subsystems. Like that > voltage monitoring device with 10000 compatibles that I CCed you and > Peter on the other day feels like it should really in your subsytem. A > "hwmon" isn't a class of device at all. > > This however, I think is more like pwm-clock (or clk-pwm, they both > exist and are opposites) where the node is used to change the type of > device rather than the subsystem using it. Yes, this is the key reason for the binding. When I was looking at the trigger bindings in the leds subsystem, I came to the realization that we need some way to get the underlying type of the trigger. In the leds bindings, I don't think this was intentional, but effectively this is done with the linux,default-trigger property. So unless there is a reason why copying the clk-pwm/pwm-clock style bindings is not a good idea, that seems the preferable way to do it to me and I'll stick with that. > >> So this one may need more explanation and justification and I'd definitely >> like some DT maintainer review on this at a fairly early stage! > > Ye, /shrug. Maybe the others have dissenting opinions. I'd like to hear > from them, but I don't personally have a problem with this.
