On Sunday, June 17, 2018 09:52 PM, Daniel Mack wrote:
On Sunday, June 17, 2018 09:39 PM, Jacek Anaszewski wrote:
Please do not make an excuse for a single LED. Let's keep the bindings
consistent across all LED class drivers, i.e. each LED should have
a dedicated child node. Even there is a single output available.
Okay, I can do that. But you do agree with the decision to only support
one single LED in the driver and the binding? The hardware chip can only
drive one single LED, but of course, the driver could support multiple
chips with a single device node and different sub-nodes. In fact the
driver did support this via pdata before this series.
I believe, however, that this is against the principles of how
device-trees are supposed to describe the hardware, so I changed it. And
as I wrote in the commit log, the only mainline user only uses one LED
anyway, so the change won't cause any regression.
And btw, that one user of the driver is soon to be replaced by a
device-tree based version, and once that's finished, I'll send another
patch to kill pdata handling from this driver entirely.
So the question is only how the DT bindings should look like, the pdata
bits are just kept around for legacy compat and don't matter.
Thanks,
Daniel
--
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
