From: Rafał Miłecki <rafal@xxxxxxxxxx>
This patchset (V4) differs by only a tiny fix in 1/2 changing property used
in the DT example.
I'd epxect both patches to go through Greg's usb.git if accepted.
For a reference (and before someome comes with already rejected solution) see
below history of this work:
1) [PATCH V2] leds: trigger: Introduce an USB port trigger
My initial try of adding "usb-ports" property. Rob said it should be more
generic.
2) [PATCH 1/2] dt-bindings: leds: document new usb-ports property
Rob still didn't like it due to being USB specific.
3) [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property
Jacek didn't like it's more generic than what Linux can already support. Later
we agreed (?) that Linux limitations shouldn't influence DT structure.
Jacek still wanted a specific trigger but Rob said he won't accept something
specific to the USB.
Jacek suggested "trigger-sources" and Rob agreed on the name.
Jacek suggested trying triggers as separated nodes.
4) [PATCH 1/4] dt-bindings: leds: document property for LED triggers
This patch was trying to use separated nodes for triggers, e.g.:
foo-trigger { trigger-type = "foo"; };
Rob didn't like this extra level of indirection. He said Linux drivers shouldn't
define/influence the binding.
So finally I came with this patchset. It doesn't try to use separated nodes for
triggers anymore and it uses the name that was mostly accepted I think. It
should be generic and not influenced by Linux design.
Rafał Miłecki (3):
dt-bindings: leds: document new trigger-sources property
usb: core: read USB ports from DT in the usbport LED trigger driver
ARM: BCM53573: Specify ports for USB LED for Tenda AC9
Documentation/devicetree/bindings/leds/common.txt | 18 ++++++++
arch/arm/boot/dts/bcm47189-tenda-ac9.dts | 1 +
arch/arm/boot/dts/bcm53573.dtsi | 4 ++
drivers/usb/core/ledtrig-usbport.c | 55 +++++++++++++++++++++++
4 files changed, 78 insertions(+)
--
2.11.0
--
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
