[v3,2/9] dt-bindings: ti-lmu: Remove LM3697

Message ID 20181011165123.32198-3-dmurphy@ti.com
State Changes Requested
Headers show
Series
  • TI LMU common Framework
Related show

Commit Message

Dan Murphy Oct. 11, 2018, 4:51 p.m.
Remove support for the LM3697 LED device
from the ti-lmu.  The LM3697 will be supported
via a stand alone LED driver.

Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
 .../devicetree/bindings/mfd/ti-lmu.txt        | 26 +------------------
 1 file changed, 1 insertion(+), 25 deletions(-)

Comments

Pavel Machek Oct. 11, 2018, 6:27 p.m. | #1
On Thu 2018-10-11 11:51:16, Dan Murphy wrote:
> Remove support for the LM3697 LED device
> from the ti-lmu.  The LM3697 will be supported
> via a stand alone LED driver.
> 
> Signed-off-by: Dan Murphy <dmurphy@ti.com>

NAK.

								Pavel
								
> index c885cf89b8ce..920f910be4e9 100644
> --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> @@ -9,7 +9,6 @@ TI LMU driver supports lighting devices below.
>    LM3632       Backlight and regulator
>    LM3633       Backlight, LED and fault monitor
>    LM3695       Backlight
> -  LM3697       Backlight and fault monitor
>  
>  Required properties:
>    - compatible: Should be one of:
> @@ -18,11 +17,10 @@ Required properties:
>                  "ti,lm3632"
>                  "ti,lm3633"
>                  "ti,lm3695"
> -                "ti,lm3697"
>    - reg: I2C slave address.
>           0x11 for LM3632
>           0x29 for LM3631
> -         0x36 for LM3633, LM3697
> +         0x36 for LM3633
>           0x38 for LM3532
>           0x63 for LM3695
>  
> @@ -38,7 +36,6 @@ Optional nodes:
>      Required properties:
>        - compatible: Should be one of:
>                      "ti,lm3633-fault-monitor"
> -                    "ti,lm3697-fault-monitor"
>    - leds: LED properties for LM3633. Please refer to [2].
>    - regulators: Regulator properties for LM3631 and LM3632.
>                  Please refer to [3].
> @@ -220,24 +217,3 @@ lm3695@63 {
>  		};
>  	};
>  };
> -
> -lm3697@36 {
> -	compatible = "ti,lm3697";
> -	reg = <0x36>;
> -
> -	enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>;
> -
> -	backlight {
> -		compatible = "ti,lm3697-backlight";
> -
> -		lcd {
> -			led-sources = <0 1 2>;
> -			ramp-up-msec = <200>;
> -			ramp-down-msec = <200>;
> -		};
> -	};
> -
> -	fault-monitor {
> -		compatible = "ti,lm3697-fault-monitor";
> -	};
> -};
Dan Murphy Oct. 11, 2018, 6:34 p.m. | #2
Pavel

On 10/11/2018 01:27 PM, Pavel Machek wrote:
> On Thu 2018-10-11 11:51:16, Dan Murphy wrote:
>> Remove support for the LM3697 LED device
>> from the ti-lmu.  The LM3697 will be supported
>> via a stand alone LED driver.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> 
> NAK.

Thanks for the NAK.

This NAK was NAK'd by other maintainer in the V2 RFC patchset

https://lore.kernel.org/patchwork/patch/993171/

> 
> 								Pavel
> 								
>> index c885cf89b8ce..920f910be4e9 100644
>> --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
>> +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
>> @@ -9,7 +9,6 @@ TI LMU driver supports lighting devices below.
>>    LM3632       Backlight and regulator
>>    LM3633       Backlight, LED and fault monitor
>>    LM3695       Backlight
>> -  LM3697       Backlight and fault monitor
>>  
>>  Required properties:
>>    - compatible: Should be one of:
>> @@ -18,11 +17,10 @@ Required properties:
>>                  "ti,lm3632"
>>                  "ti,lm3633"
>>                  "ti,lm3695"
>> -                "ti,lm3697"
>>    - reg: I2C slave address.
>>           0x11 for LM3632
>>           0x29 for LM3631
>> -         0x36 for LM3633, LM3697
>> +         0x36 for LM3633
>>           0x38 for LM3532
>>           0x63 for LM3695
>>  
>> @@ -38,7 +36,6 @@ Optional nodes:
>>      Required properties:
>>        - compatible: Should be one of:
>>                      "ti,lm3633-fault-monitor"
>> -                    "ti,lm3697-fault-monitor"
>>    - leds: LED properties for LM3633. Please refer to [2].
>>    - regulators: Regulator properties for LM3631 and LM3632.
>>                  Please refer to [3].
>> @@ -220,24 +217,3 @@ lm3695@63 {
>>  		};
>>  	};
>>  };
>> -
>> -lm3697@36 {
>> -	compatible = "ti,lm3697";
>> -	reg = <0x36>;
>> -
>> -	enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>;
>> -
>> -	backlight {
>> -		compatible = "ti,lm3697-backlight";
>> -
>> -		lcd {
>> -			led-sources = <0 1 2>;
>> -			ramp-up-msec = <200>;
>> -			ramp-down-msec = <200>;
>> -		};
>> -	};
>> -
>> -	fault-monitor {
>> -		compatible = "ti,lm3697-fault-monitor";
>> -	};
>> -};
>
Jacek Anaszewski Oct. 11, 2018, 7:38 p.m. | #3
On 10/11/2018 08:34 PM, Dan Murphy wrote:
> Pavel
> 
> On 10/11/2018 01:27 PM, Pavel Machek wrote:
>> On Thu 2018-10-11 11:51:16, Dan Murphy wrote:
>>> Remove support for the LM3697 LED device
>>> from the ti-lmu.  The LM3697 will be supported
>>> via a stand alone LED driver.
>>>
>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>
>> NAK.
> 
> Thanks for the NAK.
> 
> This NAK was NAK'd by other maintainer in the V2 RFC patchset
> 
> https://lore.kernel.org/patchwork/patch/993171/

I confirm. LM3697 is a standalone device and not a cell of any
MFD device.

Waiting for DT maintainer's ack.

Best regards,
Jacek Anaszewski
								
>>> index c885cf89b8ce..920f910be4e9 100644
>>> --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
>>> +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
>>> @@ -9,7 +9,6 @@ TI LMU driver supports lighting devices below.
>>>    LM3632       Backlight and regulator
>>>    LM3633       Backlight, LED and fault monitor
>>>    LM3695       Backlight
>>> -  LM3697       Backlight and fault monitor
>>>  
>>>  Required properties:
>>>    - compatible: Should be one of:
>>> @@ -18,11 +17,10 @@ Required properties:
>>>                  "ti,lm3632"
>>>                  "ti,lm3633"
>>>                  "ti,lm3695"
>>> -                "ti,lm3697"
>>>    - reg: I2C slave address.
>>>           0x11 for LM3632
>>>           0x29 for LM3631
>>> -         0x36 for LM3633, LM3697
>>> +         0x36 for LM3633
>>>           0x38 for LM3532
>>>           0x63 for LM3695
>>>  
>>> @@ -38,7 +36,6 @@ Optional nodes:
>>>      Required properties:
>>>        - compatible: Should be one of:
>>>                      "ti,lm3633-fault-monitor"
>>> -                    "ti,lm3697-fault-monitor"
>>>    - leds: LED properties for LM3633. Please refer to [2].
>>>    - regulators: Regulator properties for LM3631 and LM3632.
>>>                  Please refer to [3].
>>> @@ -220,24 +217,3 @@ lm3695@63 {
>>>  		};
>>>  	};
>>>  };
>>> -
>>> -lm3697@36 {
>>> -	compatible = "ti,lm3697";
>>> -	reg = <0x36>;
>>> -
>>> -	enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>;
>>> -
>>> -	backlight {
>>> -		compatible = "ti,lm3697-backlight";
>>> -
>>> -		lcd {
>>> -			led-sources = <0 1 2>;
>>> -			ramp-up-msec = <200>;
>>> -			ramp-down-msec = <200>;
>>> -		};
>>> -	};
>>> -
>>> -	fault-monitor {
>>> -		compatible = "ti,lm3697-fault-monitor";
>>> -	};
>>> -};
>>
> 
>
Lee Jones Oct. 12, 2018, 9:07 a.m. | #4
On Thu, 11 Oct 2018, Dan Murphy wrote:

> Remove support for the LM3697 LED device
> from the ti-lmu.  The LM3697 will be supported
> via a stand alone LED driver.

What's with the odd 50 char line wrapping?

> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>  .../devicetree/bindings/mfd/ti-lmu.txt        | 26 +------------------
>  1 file changed, 1 insertion(+), 25 deletions(-)

For the code:

For my own reference:
  Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
Rob Herring Oct. 12, 2018, 4:26 p.m. | #5
On Thu, Oct 11, 2018 at 09:38:53PM +0200, Jacek Anaszewski wrote:
> On 10/11/2018 08:34 PM, Dan Murphy wrote:
> > Pavel
> > 
> > On 10/11/2018 01:27 PM, Pavel Machek wrote:
> >> On Thu 2018-10-11 11:51:16, Dan Murphy wrote:
> >>> Remove support for the LM3697 LED device
> >>> from the ti-lmu.  The LM3697 will be supported
> >>> via a stand alone LED driver.
> >>>
> >>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> >>
> >> NAK.
> > 
> > Thanks for the NAK.
> > 
> > This NAK was NAK'd by other maintainer in the V2 RFC patchset
> > 
> > https://lore.kernel.org/patchwork/patch/993171/
> 
> I confirm. LM3697 is a standalone device and not a cell of any
> MFD device.
> 
> Waiting for DT maintainer's ack.

You all sort out what you want... I can't follow it all, and I'm not 
going to spend the time trying to figure out what is going on here.

As this is worded, changing the driver is a Linux problem and irrelevant 
to the binding. Now if you want to move documentation to a location that 
makes more sense, then fine. But structure patches that way and make it 
clear that from an binding ABI perspective, nothing is changing.

Rob
Pavel Machek Oct. 12, 2018, 6:03 p.m. | #6
Hi!

> > >>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> > >>
> > >> NAK.
> > > 
> > > Thanks for the NAK.
> > > 
> > > This NAK was NAK'd by other maintainer in the V2 RFC patchset
> > > 
> > > https://lore.kernel.org/patchwork/patch/993171/
> > 
> > I confirm. LM3697 is a standalone device and not a cell of any
> > MFD device.
> > 
> > Waiting for DT maintainer's ack.
> 
> You all sort out what you want... I can't follow it all, and I'm not 
> going to spend the time trying to figure out what is going on here.

This is what I want:

> As this is worded, changing the driver is a Linux problem and irrelevant 
> to the binding. Now if you want to move documentation to a location that 
> makes more sense, then fine. But structure patches that way and make it 
> clear that from an binding ABI perspective, nothing is changing.

...but apparently I did not have enough authority to get it.

(I'm ok with move, and it is possible that binding does need some
fixups besides the move; still it should be done as fixup not as a new
binding).

Thanks,
								Pavel
Jacek Anaszewski Oct. 13, 2018, 6:45 p.m. | #7
On 10/12/2018 08:03 PM, Pavel Machek wrote:
> Hi!
> 
>>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>>>
>>>>> NAK.
>>>>
>>>> Thanks for the NAK.
>>>>
>>>> This NAK was NAK'd by other maintainer in the V2 RFC patchset
>>>>
>>>> https://lore.kernel.org/patchwork/patch/993171/
>>>
>>> I confirm. LM3697 is a standalone device and not a cell of any
>>> MFD device.
>>>
>>> Waiting for DT maintainer's ack.
>>
>> You all sort out what you want... I can't follow it all, and I'm not 
>> going to spend the time trying to figure out what is going on here.
> 
> This is what I want:
> 
>> As this is worded, changing the driver is a Linux problem and irrelevant 
>> to the binding. Now if you want to move documentation to a location that 
>> makes more sense, then fine. But structure patches that way and make it 
>> clear that from an binding ABI perspective, nothing is changing.
> 
> ...but apparently I did not have enough authority to get it.
> 
> (I'm ok with move, and it is possible that binding does need some
> fixups besides the move; still it should be done as fixup not as a new
> binding).

There is a fundamental question - should the bindings be considered
an ABI, even though there is no mainline "*.dts" implementation basing
on these bindings?

This patch fixes the issues of bindings in a way that would change
the ABI, if only it existed. But it apparently doesn't exist in
mainline. Unless a DT documentation itself constitutes an ABI.

I'd like to have it clarified at this occasion, and that's why
I kindly ask for DT maintainer's ack or NACK for this modification
of bindings.

For a reference we have a nice summary of the MFD driver and related
bindings' flaws in [0] and [1].

[0] https://lkml.org/lkml/2018/9/7/774
[1] https://lkml.org/lkml/2018/9/11/984
Rob Herring Oct. 15, 2018, 12:56 a.m. | #8
On Sat, Oct 13, 2018 at 1:46 PM Jacek Anaszewski
<jacek.anaszewski@gmail.com> wrote:
>
> On 10/12/2018 08:03 PM, Pavel Machek wrote:
> > Hi!
> >
> >>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> >>>>>
> >>>>> NAK.
> >>>>
> >>>> Thanks for the NAK.
> >>>>
> >>>> This NAK was NAK'd by other maintainer in the V2 RFC patchset
> >>>>
> >>>> https://lore.kernel.org/patchwork/patch/993171/
> >>>
> >>> I confirm. LM3697 is a standalone device and not a cell of any
> >>> MFD device.
> >>>
> >>> Waiting for DT maintainer's ack.
> >>
> >> You all sort out what you want... I can't follow it all, and I'm not
> >> going to spend the time trying to figure out what is going on here.
> >
> > This is what I want:
> >
> >> As this is worded, changing the driver is a Linux problem and irrelevant
> >> to the binding. Now if you want to move documentation to a location that
> >> makes more sense, then fine. But structure patches that way and make it
> >> clear that from an binding ABI perspective, nothing is changing.
> >
> > ...but apparently I did not have enough authority to get it.
> >
> > (I'm ok with move, and it is possible that binding does need some
> > fixups besides the move; still it should be done as fixup not as a new
> > binding).
>
> There is a fundamental question - should the bindings be considered
> an ABI, even though there is no mainline "*.dts" implementation basing
> on these bindings?

In theory there could be out of tree users. Having a dts file using it
in tree shouldn't be a requirement to maintain the ABI IMO. However, a
lack of dts is one piece of determining whether this is in use or not.

> This patch fixes the issues of bindings in a way that would change
> the ABI, if only it existed. But it apparently doesn't exist in
> mainline. Unless a DT documentation itself constitutes an ABI.
>
> I'd like to have it clarified at this occasion, and that's why
> I kindly ask for DT maintainer's ack or NACK for this modification
> of bindings.
>
> For a reference we have a nice summary of the MFD driver and related
> bindings' flaws in [0] and [1].
>
> [0] https://lkml.org/lkml/2018/9/7/774
> [1] https://lkml.org/lkml/2018/9/11/984

Given this one seems to have not really been finished, it's probably
okay to make changes in this case. Still, it would be good to see
patches structured so that it's obvious we're breaking things. But how
the patches are structured doesn't matter until there's some agreement
on the end result.

Rob
Jacek Anaszewski Oct. 15, 2018, 7:13 p.m. | #9
On 10/15/2018 02:56 AM, Rob Herring wrote:
> On Sat, Oct 13, 2018 at 1:46 PM Jacek Anaszewski
> <jacek.anaszewski@gmail.com> wrote:
>>
>> On 10/12/2018 08:03 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>>>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>>>>>
>>>>>>> NAK.
>>>>>>
>>>>>> Thanks for the NAK.
>>>>>>
>>>>>> This NAK was NAK'd by other maintainer in the V2 RFC patchset
>>>>>>
>>>>>> https://lore.kernel.org/patchwork/patch/993171/
>>>>>
>>>>> I confirm. LM3697 is a standalone device and not a cell of any
>>>>> MFD device.
>>>>>
>>>>> Waiting for DT maintainer's ack.
>>>>
>>>> You all sort out what you want... I can't follow it all, and I'm not
>>>> going to spend the time trying to figure out what is going on here.
>>>
>>> This is what I want:
>>>
>>>> As this is worded, changing the driver is a Linux problem and irrelevant
>>>> to the binding. Now if you want to move documentation to a location that
>>>> makes more sense, then fine. But structure patches that way and make it
>>>> clear that from an binding ABI perspective, nothing is changing.
>>>
>>> ...but apparently I did not have enough authority to get it.
>>>
>>> (I'm ok with move, and it is possible that binding does need some
>>> fixups besides the move; still it should be done as fixup not as a new
>>> binding).
>>
>> There is a fundamental question - should the bindings be considered
>> an ABI, even though there is no mainline "*.dts" implementation basing
>> on these bindings?
> 
> In theory there could be out of tree users. Having a dts file using it
> in tree shouldn't be a requirement to maintain the ABI IMO. However, a
> lack of dts is one piece of determining whether this is in use or not.
> 
>> This patch fixes the issues of bindings in a way that would change
>> the ABI, if only it existed. But it apparently doesn't exist in
>> mainline. Unless a DT documentation itself constitutes an ABI.
>>
>> I'd like to have it clarified at this occasion, and that's why
>> I kindly ask for DT maintainer's ack or NACK for this modification
>> of bindings.
>>
>> For a reference we have a nice summary of the MFD driver and related
>> bindings' flaws in [0] and [1].
>>
>> [0] https://lkml.org/lkml/2018/9/7/774
>> [1] https://lkml.org/lkml/2018/9/11/984
> 
> Given this one seems to have not really been finished, it's probably
> okay to make changes in this case. Still, it would be good to see
> patches structured so that it's obvious we're breaking things. But how
> the patches are structured doesn't matter until there's some agreement
> on the end result.

OK, so if I'm getting it right, the correct patch structure in this case
means that changes removing bindings from MFD and moving them along
with the modifications to the LED subsystem should be placed in a single
patch.

Dan, could you please arrange the next patch set version accordingly?
Dan Murphy Oct. 15, 2018, 7:14 p.m. | #10
Jacek

On 10/15/2018 02:13 PM, Jacek Anaszewski wrote:
> On 10/15/2018 02:56 AM, Rob Herring wrote:
>> On Sat, Oct 13, 2018 at 1:46 PM Jacek Anaszewski
>> <jacek.anaszewski@gmail.com> wrote:
>>>
>>> On 10/12/2018 08:03 PM, Pavel Machek wrote:
>>>> Hi!
>>>>
>>>>>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>>>>>>
>>>>>>>> NAK.
>>>>>>>
>>>>>>> Thanks for the NAK.
>>>>>>>
>>>>>>> This NAK was NAK'd by other maintainer in the V2 RFC patchset
>>>>>>>
>>>>>>> https://lore.kernel.org/patchwork/patch/993171/
>>>>>>
>>>>>> I confirm. LM3697 is a standalone device and not a cell of any
>>>>>> MFD device.
>>>>>>
>>>>>> Waiting for DT maintainer's ack.
>>>>>
>>>>> You all sort out what you want... I can't follow it all, and I'm not
>>>>> going to spend the time trying to figure out what is going on here.
>>>>
>>>> This is what I want:
>>>>
>>>>> As this is worded, changing the driver is a Linux problem and irrelevant
>>>>> to the binding. Now if you want to move documentation to a location that
>>>>> makes more sense, then fine. But structure patches that way and make it
>>>>> clear that from an binding ABI perspective, nothing is changing.
>>>>
>>>> ...but apparently I did not have enough authority to get it.
>>>>
>>>> (I'm ok with move, and it is possible that binding does need some
>>>> fixups besides the move; still it should be done as fixup not as a new
>>>> binding).
>>>
>>> There is a fundamental question - should the bindings be considered
>>> an ABI, even though there is no mainline "*.dts" implementation basing
>>> on these bindings?
>>
>> In theory there could be out of tree users. Having a dts file using it
>> in tree shouldn't be a requirement to maintain the ABI IMO. However, a
>> lack of dts is one piece of determining whether this is in use or not.
>>
>>> This patch fixes the issues of bindings in a way that would change
>>> the ABI, if only it existed. But it apparently doesn't exist in
>>> mainline. Unless a DT documentation itself constitutes an ABI.
>>>
>>> I'd like to have it clarified at this occasion, and that's why
>>> I kindly ask for DT maintainer's ack or NACK for this modification
>>> of bindings.
>>>
>>> For a reference we have a nice summary of the MFD driver and related
>>> bindings' flaws in [0] and [1].
>>>
>>> [0] https://lkml.org/lkml/2018/9/7/774
>>> [1] https://lkml.org/lkml/2018/9/11/984
>>
>> Given this one seems to have not really been finished, it's probably
>> okay to make changes in this case. Still, it would be good to see
>> patches structured so that it's obvious we're breaking things. But how
>> the patches are structured doesn't matter until there's some agreement
>> on the end result.
> 
> OK, so if I'm getting it right, the correct patch structure in this case
> means that changes removing bindings from MFD and moving them along
> with the modifications to the LED subsystem should be placed in a single
> patch.
> 
> Dan, could you please arrange the next patch set version accordingly?

Yes I can squash the DT bindings patches and call it a "move and modify"

Dan

>
Pavel Machek Oct. 15, 2018, 9:45 p.m. | #11
Hi!

> >> Given this one seems to have not really been finished, it's probably
> >> okay to make changes in this case. Still, it would be good to see
> >> patches structured so that it's obvious we're breaking things. But how
> >> the patches are structured doesn't matter until there's some agreement
> >> on the end result.
> > 
> > OK, so if I'm getting it right, the correct patch structure in this case
> > means that changes removing bindings from MFD and moving them along
> > with the modifications to the LED subsystem should be placed in a single
> > patch.
> > 
> > Dan, could you please arrange the next patch set version accordingly?
> 
> Yes I can squash the DT bindings patches and call it a "move and modify"

You can do move without problems. But if you plan to modify them,
please try to change as little as possible, make it separate patch and
explain why new version is better than old one.

Thanks,
									Pavel
Dan Murphy Oct. 16, 2018, 1:25 p.m. | #12
Thanks

On 10/15/2018 04:45 PM, Pavel Machek wrote:
> Hi!
> 
>>>> Given this one seems to have not really been finished, it's probably
>>>> okay to make changes in this case. Still, it would be good to see
>>>> patches structured so that it's obvious we're breaking things. But how
>>>> the patches are structured doesn't matter until there's some agreement
>>>> on the end result.
>>>
>>> OK, so if I'm getting it right, the correct patch structure in this case
>>> means that changes removing bindings from MFD and moving them along
>>> with the modifications to the LED subsystem should be placed in a single
>>> patch.
>>>
>>> Dan, could you please arrange the next patch set version accordingly?
>>
>> Yes I can squash the DT bindings patches and call it a "move and modify"
> 
> You can do move without problems. But if you plan to modify them,
> please try to change as little as possible, make it separate patch and
> explain why new version is better than old one.
> 

I have been thinking of how to do this.  Since the 2 devices are part of the current
binding there really is not a way to move them.  Since there are still MFD capable
devices available.

I would still need to remove the current active binding and create a new binding in the LED
bindings directory.

I would have to remove and create in the same patch.

Dan

> Thanks,
> 									Pavel
>
Pavel Machek Oct. 18, 2018, 10:10 p.m. | #13
Hi!

> >>>> Given this one seems to have not really been finished, it's probably
> >>>> okay to make changes in this case. Still, it would be good to see
> >>>> patches structured so that it's obvious we're breaking things. But how
> >>>> the patches are structured doesn't matter until there's some agreement
> >>>> on the end result.
> >>>
> >>> OK, so if I'm getting it right, the correct patch structure in this case
> >>> means that changes removing bindings from MFD and moving them along
> >>> with the modifications to the LED subsystem should be placed in a single
> >>> patch.
> >>>
> >>> Dan, could you please arrange the next patch set version accordingly?
> >>
> >> Yes I can squash the DT bindings patches and call it a "move and modify"
> > 
> > You can do move without problems. But if you plan to modify them,
> > please try to change as little as possible, make it separate patch and
> > explain why new version is better than old one.
> > 
> 
> I have been thinking of how to do this.  Since the 2 devices are part of the current
> binding there really is not a way to move them.  Since there are still MFD capable
> devices available.
> 
> I would still need to remove the current active binding and create a new binding in the LED
> bindings directory.
> 
> I would have to remove and create in the same patch.

Yeah, and this all is a sign that you should just keep the current
binding, and make your code use it, see?

You are free to use Sebastian's updated binding. It has "suggested by:
Rob" or something like that on it, so it should be fine.

You can add note to bindings/leds pointing to mfd binding.

Now... this is what I've suggested before. If you don't agree, you may
want to contact Tony Lindgren, IIRC he works for TI, too, and might be
willing to help.

Thank you,
									Pavel
Dan Murphy Oct. 19, 2018, 11:42 a.m. | #14
On 10/18/2018 05:10 PM, Pavel Machek wrote:
> Hi!
> 
>>>>>> Given this one seems to have not really been finished, it's probably
>>>>>> okay to make changes in this case. Still, it would be good to see
>>>>>> patches structured so that it's obvious we're breaking things. But how
>>>>>> the patches are structured doesn't matter until there's some agreement
>>>>>> on the end result.
>>>>>
>>>>> OK, so if I'm getting it right, the correct patch structure in this case
>>>>> means that changes removing bindings from MFD and moving them along
>>>>> with the modifications to the LED subsystem should be placed in a single
>>>>> patch.
>>>>>
>>>>> Dan, could you please arrange the next patch set version accordingly?
>>>>
>>>> Yes I can squash the DT bindings patches and call it a "move and modify"
>>>
>>> You can do move without problems. But if you plan to modify them,
>>> please try to change as little as possible, make it separate patch and
>>> explain why new version is better than old one.
>>>
>>
>> I have been thinking of how to do this.  Since the 2 devices are part of the current
>> binding there really is not a way to move them.  Since there are still MFD capable
>> devices available.
>>
>> I would still need to remove the current active binding and create a new binding in the LED
>> bindings directory.
>>
>> I would have to remove and create in the same patch.
> 
> Yeah, and this all is a sign that you should just keep the current
> binding, and make your code use it, see?


No I don't actually see this as a sign.  This is just operational issues
nothing to do with actually correcting the incomplete unused bindings.

And actually moving and creating the bindings in the same patch makes
sense as the change is self contained in a single patch and is easier to
track.

> 
> You are free to use Sebastian's updated binding. It has "suggested by:
> Rob" or something like that on it, so it should be fine.
> 
> You can add note to bindings/leds pointing to mfd binding.
> 
> Now... this is what I've suggested before. If you don't agree, you may
> want to contact Tony Lindgren, IIRC he works for TI, too, and might be
> willing to help.

I will ping Tony just to close the loop.  I will be posting v4 today after making the changes.
I was hoping to have some code review prior to posting v4 but have not received any comments so
v4 will just be a patch rearrangement.

Dan

> 
> Thank you,
> 									Pavel
>
Tony Lindgren Oct. 19, 2018, 2:58 p.m. | #15
* Dan Murphy <dmurphy@ti.com> [181019 11:42]:
> On 10/18/2018 05:10 PM, Pavel Machek wrote:
> > 
> > Now... this is what I've suggested before. If you don't agree, you may
> > want to contact Tony Lindgren, IIRC he works for TI, too, and might be
> > willing to help.
>
> I will ping Tony just to close the loop.  I will be posting v4 today after making the changes.
> I was hoping to have some code review prior to posting v4 but have not received any comments so
> v4 will just be a patch rearrangement.

I guess not much to ping here though as I know little about these
chips :) As long as Rob is happy with the binding changes I'll be
happy too.

Regards,

Tony

Patch

diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
index c885cf89b8ce..920f910be4e9 100644
--- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
+++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
@@ -9,7 +9,6 @@  TI LMU driver supports lighting devices below.
   LM3632       Backlight and regulator
   LM3633       Backlight, LED and fault monitor
   LM3695       Backlight
-  LM3697       Backlight and fault monitor
 
 Required properties:
   - compatible: Should be one of:
@@ -18,11 +17,10 @@  Required properties:
                 "ti,lm3632"
                 "ti,lm3633"
                 "ti,lm3695"
-                "ti,lm3697"
   - reg: I2C slave address.
          0x11 for LM3632
          0x29 for LM3631
-         0x36 for LM3633, LM3697
+         0x36 for LM3633
          0x38 for LM3532
          0x63 for LM3695
 
@@ -38,7 +36,6 @@  Optional nodes:
     Required properties:
       - compatible: Should be one of:
                     "ti,lm3633-fault-monitor"
-                    "ti,lm3697-fault-monitor"
   - leds: LED properties for LM3633. Please refer to [2].
   - regulators: Regulator properties for LM3631 and LM3632.
                 Please refer to [3].
@@ -220,24 +217,3 @@  lm3695@63 {
 		};
 	};
 };
-
-lm3697@36 {
-	compatible = "ti,lm3697";
-	reg = <0x36>;
-
-	enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>;
-
-	backlight {
-		compatible = "ti,lm3697-backlight";
-
-		lcd {
-			led-sources = <0 1 2>;
-			ramp-up-msec = <200>;
-			ramp-down-msec = <200>;
-		};
-	};
-
-	fault-monitor {
-		compatible = "ti,lm3697-fault-monitor";
-	};
-};