| Message ID | 20220414083120.22535-2-a-govindraju@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | typec: tipd: Add support for polling | expand |
Hi, On 14/04/2022 11:31, Aswath Govindraju wrote: > Support for polling has been added in the driver, which will be used by > default if interrupts property is not populated. Therefore, remove > interrupts and interrupt-names from the required properties and add a note > under interrupts property describing the above support in driver. > > Suggested-by: Roger Quadros <rogerq@kernel.org> I did not suggest to make interrupts optional by default. What I suggested was that if a DT property exists to explicitly indicate polling mode then interrupts are not required. > Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> > --- > Documentation/devicetree/bindings/usb/ti,tps6598x.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml > index a4c53b1f1af3..1c4b8c6233e5 100644 > --- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml > +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml > @@ -25,6 +25,8 @@ properties: > > interrupts: > maxItems: 1 > + description: > + If interrupts are not populated then by default polling will be used. > > interrupt-names: > items: > @@ -33,8 +35,6 @@ properties: > required: > - compatible > - reg > - - interrupts > - - interrupt-names > > additionalProperties: true > cheers, -roger
Hi Roger, On 14/04/22 23:40, Roger Quadros wrote: > Hi, > > On 14/04/2022 11:31, Aswath Govindraju wrote: >> Support for polling has been added in the driver, which will be used by >> default if interrupts property is not populated. Therefore, remove >> interrupts and interrupt-names from the required properties and add a note >> under interrupts property describing the above support in driver. >> >> Suggested-by: Roger Quadros <rogerq@kernel.org> > > I did not suggest to make interrupts optional by default. > > What I suggested was that if a DT property exists to explicitly > indicate polling mode then interrupts are not required. > ohh okay, got it. However, may I know if adding a dt property to indicate polling for aiding the driver, is the correct approach to model it? In terms of modelling hardware, as interrupts are not connected we are not populating the interrupts property. Shouldn't that be all. If we are adding a property explicitly to indicate polling that can be used by driver, wouldn't that be a software aid being added in the device tree? Thanks, Aswath >> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> >> --- >> Documentation/devicetree/bindings/usb/ti,tps6598x.yaml | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >> index a4c53b1f1af3..1c4b8c6233e5 100644 >> --- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >> +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >> @@ -25,6 +25,8 @@ properties: >> >> interrupts: >> maxItems: 1 >> + description: >> + If interrupts are not populated then by default polling will be used. >> >> interrupt-names: >> items: >> @@ -33,8 +35,6 @@ properties: >> required: >> - compatible >> - reg >> - - interrupts >> - - interrupt-names >> >> additionalProperties: true >> > > cheers, > -roger
Hi, On 18/04/2022 08:19, Aswath Govindraju wrote: > Hi Roger, > > On 14/04/22 23:40, Roger Quadros wrote: >> Hi, >> >> On 14/04/2022 11:31, Aswath Govindraju wrote: >>> Support for polling has been added in the driver, which will be used by >>> default if interrupts property is not populated. Therefore, remove >>> interrupts and interrupt-names from the required properties and add a note >>> under interrupts property describing the above support in driver. >>> >>> Suggested-by: Roger Quadros <rogerq@kernel.org> >> >> I did not suggest to make interrupts optional by default. >> >> What I suggested was that if a DT property exists to explicitly >> indicate polling mode then interrupts are not required. >> > > ohh okay, got it. However, may I know if adding a dt property to > indicate polling for aiding the driver, is the correct approach to model it? > > In terms of modelling hardware, as interrupts are not connected we are > not populating the interrupts property. Shouldn't that be all. If we are > adding a property explicitly to indicate polling that can be used by > driver, wouldn't that be a software aid being added in the device tree? The hardware (tps6598x chip) has an interrupt pin and is expected to be used in normal case. Some buggy boards might have forgot to connect it. We are adding polling mode only for these buggy boards. ;) So polling mode is an exception. cheers, -roger > > Thanks, > Aswath > >>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> >>> --- >>> Documentation/devicetree/bindings/usb/ti,tps6598x.yaml | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>> index a4c53b1f1af3..1c4b8c6233e5 100644 >>> --- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>> +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>> @@ -25,6 +25,8 @@ properties: >>> >>> interrupts: >>> maxItems: 1 >>> + description: >>> + If interrupts are not populated then by default polling will be used. >>> >>> interrupt-names: >>> items: >>> @@ -33,8 +35,6 @@ properties: >>> required: >>> - compatible >>> - reg >>> - - interrupts >>> - - interrupt-names >>> >>> additionalProperties: true >>> >> >> cheers, >> -roger
Hi Roger, On 21/04/22 00:46, Roger Quadros wrote: > Hi, > > On 18/04/2022 08:19, Aswath Govindraju wrote: >> Hi Roger, >> >> On 14/04/22 23:40, Roger Quadros wrote: >>> Hi, >>> >>> On 14/04/2022 11:31, Aswath Govindraju wrote: >>>> Support for polling has been added in the driver, which will be used by >>>> default if interrupts property is not populated. Therefore, remove >>>> interrupts and interrupt-names from the required properties and add a note >>>> under interrupts property describing the above support in driver. >>>> >>>> Suggested-by: Roger Quadros <rogerq@kernel.org> >>> >>> I did not suggest to make interrupts optional by default. >>> >>> What I suggested was that if a DT property exists to explicitly >>> indicate polling mode then interrupts are not required. >>> >> >> ohh okay, got it. However, may I know if adding a dt property to >> indicate polling for aiding the driver, is the correct approach to model it? >> >> In terms of modelling hardware, as interrupts are not connected we are >> not populating the interrupts property. Shouldn't that be all. If we are >> adding a property explicitly to indicate polling that can be used by >> driver, wouldn't that be a software aid being added in the device tree? > > The hardware (tps6598x chip) has an interrupt pin and is expected to be used > in normal case. > > Some buggy boards might have forgot to connect it. We are adding polling mode only for these buggy boards. ;) > So polling mode is an exception. > Yes as you mentioned the interrupt line is expected to connected but there could be cases where there are not enough pins on the SoC and polling is used intentionally. In these cases this would be a feature rather than a bug. Also, I feel like not adding interrupts property in the dt nodes will indicate polling. My question is why are we adding an extra property (which is being used only as an aid in the driver) when this feature can be modeled by making interrupts property optional. Thanks, Aswath > cheers, > -roger > >> >> Thanks, >> Aswath >> >>>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> >>>> --- >>>> Documentation/devicetree/bindings/usb/ti,tps6598x.yaml | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>> index a4c53b1f1af3..1c4b8c6233e5 100644 >>>> --- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>> +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>> @@ -25,6 +25,8 @@ properties: >>>> >>>> interrupts: >>>> maxItems: 1 >>>> + description: >>>> + If interrupts are not populated then by default polling will be used. >>>> >>>> interrupt-names: >>>> items: >>>> @@ -33,8 +35,6 @@ properties: >>>> required: >>>> - compatible >>>> - reg >>>> - - interrupts >>>> - - interrupt-names >>>> >>>> additionalProperties: true >>>> >>> >>> cheers, >>> -roger
Hi, On 22/04/2022 08:07, Aswath Govindraju wrote: > Hi Roger, > > On 21/04/22 00:46, Roger Quadros wrote: >> Hi, >> >> On 18/04/2022 08:19, Aswath Govindraju wrote: >>> Hi Roger, >>> >>> On 14/04/22 23:40, Roger Quadros wrote: >>>> Hi, >>>> >>>> On 14/04/2022 11:31, Aswath Govindraju wrote: >>>>> Support for polling has been added in the driver, which will be used by >>>>> default if interrupts property is not populated. Therefore, remove >>>>> interrupts and interrupt-names from the required properties and add a note >>>>> under interrupts property describing the above support in driver. >>>>> >>>>> Suggested-by: Roger Quadros <rogerq@kernel.org> >>>> >>>> I did not suggest to make interrupts optional by default. >>>> >>>> What I suggested was that if a DT property exists to explicitly >>>> indicate polling mode then interrupts are not required. >>>> >>> >>> ohh okay, got it. However, may I know if adding a dt property to >>> indicate polling for aiding the driver, is the correct approach to model it? >>> >>> In terms of modelling hardware, as interrupts are not connected we are >>> not populating the interrupts property. Shouldn't that be all. If we are >>> adding a property explicitly to indicate polling that can be used by >>> driver, wouldn't that be a software aid being added in the device tree? >> >> The hardware (tps6598x chip) has an interrupt pin and is expected to be used >> in normal case. >> >> Some buggy boards might have forgot to connect it. We are adding polling mode only for these buggy boards. ;) >> So polling mode is an exception. >> > > Yes as you mentioned the interrupt line is expected to connected but > there could be cases where there are not enough pins on the SoC and > polling is used intentionally. In these cases this would be a feature > rather than a bug. I do not agree that this is a feature but a board defect. You can always use a GPIO expander to add more GPIOs than the SoC can provide. Type-C events are asynchronous and polling is a waste of CPU time. What will you do if system suspends and you need to wake up on Type-C status change? So polling mode is just an exception for the defective boards or could be used for debugging. > > Also, I feel like not adding interrupts property in the dt nodes will > indicate polling. My question is why are we adding an extra property > (which is being used only as an aid in the driver) when this feature can > be modeled by making interrupts property optional. Because interrupt property was not originally optional for this driver. I would like to hear what Heikki has to say about this. Any thoughts Heikki? cheers, -roger > > Thanks, > Aswath > >> cheers, >> -roger >> >>> >>> Thanks, >>> Aswath >>> >>>>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> >>>>> --- >>>>> Documentation/devicetree/bindings/usb/ti,tps6598x.yaml | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>>> index a4c53b1f1af3..1c4b8c6233e5 100644 >>>>> --- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>>> +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>>> @@ -25,6 +25,8 @@ properties: >>>>> >>>>> interrupts: >>>>> maxItems: 1 >>>>> + description: >>>>> + If interrupts are not populated then by default polling will be used. >>>>> >>>>> interrupt-names: >>>>> items: >>>>> @@ -33,8 +35,6 @@ properties: >>>>> required: >>>>> - compatible >>>>> - reg >>>>> - - interrupts >>>>> - - interrupt-names >>>>> >>>>> additionalProperties: true >>>>> >>>> >>>> cheers, >>>> -roger > >
On Tue, Apr 26, 2022 at 09:42:31AM +0300, Roger Quadros wrote: > Hi, > > On 22/04/2022 08:07, Aswath Govindraju wrote: > > Hi Roger, > > > > On 21/04/22 00:46, Roger Quadros wrote: > >> Hi, > >> > >> On 18/04/2022 08:19, Aswath Govindraju wrote: > >>> Hi Roger, > >>> > >>> On 14/04/22 23:40, Roger Quadros wrote: > >>>> Hi, > >>>> > >>>> On 14/04/2022 11:31, Aswath Govindraju wrote: > >>>>> Support for polling has been added in the driver, which will be used by > >>>>> default if interrupts property is not populated. Therefore, remove > >>>>> interrupts and interrupt-names from the required properties and add a note > >>>>> under interrupts property describing the above support in driver. > >>>>> > >>>>> Suggested-by: Roger Quadros <rogerq@kernel.org> > >>>> > >>>> I did not suggest to make interrupts optional by default. > >>>> > >>>> What I suggested was that if a DT property exists to explicitly > >>>> indicate polling mode then interrupts are not required. > >>>> > >>> > >>> ohh okay, got it. However, may I know if adding a dt property to > >>> indicate polling for aiding the driver, is the correct approach to model it? > >>> > >>> In terms of modelling hardware, as interrupts are not connected we are > >>> not populating the interrupts property. Shouldn't that be all. If we are > >>> adding a property explicitly to indicate polling that can be used by > >>> driver, wouldn't that be a software aid being added in the device tree? > >> > >> The hardware (tps6598x chip) has an interrupt pin and is expected to be used > >> in normal case. > >> > >> Some buggy boards might have forgot to connect it. We are adding polling mode only for these buggy boards. ;) > >> So polling mode is an exception. > >> > > > > Yes as you mentioned the interrupt line is expected to connected but > > there could be cases where there are not enough pins on the SoC and > > polling is used intentionally. In these cases this would be a feature > > rather than a bug. > > I do not agree that this is a feature but a board defect. You can always use > a GPIO expander to add more GPIOs than the SoC can provide. > > Type-C events are asynchronous and polling is a waste of CPU time. > What will you do if system suspends and you need to wake up on Type-C > status change? > So polling mode is just an exception for the defective boards or could > be used for debugging. > > > > > Also, I feel like not adding interrupts property in the dt nodes will > > indicate polling. My question is why are we adding an extra property > > (which is being used only as an aid in the driver) when this feature can > > be modeled by making interrupts property optional. > > Because interrupt property was not originally optional for this driver. > > I would like to hear what Heikki has to say about this. > > Any thoughts Heikki? I think the question is generic. How should DT describe the connection/lack of connection? Rob should comment on this. thanks, > cheers, > -roger > > > > > Thanks, > > Aswath > > > >> cheers, > >> -roger > >> > >>> > >>> Thanks, > >>> Aswath > >>> > >>>>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> > >>>>> --- > >>>>> Documentation/devicetree/bindings/usb/ti,tps6598x.yaml | 4 ++-- > >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) > >>>>> > >>>>> diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml > >>>>> index a4c53b1f1af3..1c4b8c6233e5 100644 > >>>>> --- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml > >>>>> +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml > >>>>> @@ -25,6 +25,8 @@ properties: > >>>>> > >>>>> interrupts: > >>>>> maxItems: 1 > >>>>> + description: > >>>>> + If interrupts are not populated then by default polling will be used. > >>>>> > >>>>> interrupt-names: > >>>>> items: > >>>>> @@ -33,8 +35,6 @@ properties: > >>>>> required: > >>>>> - compatible > >>>>> - reg > >>>>> - - interrupts > >>>>> - - interrupt-names > >>>>> > >>>>> additionalProperties: true > >>>>> > >>>> > >>>> cheers, > >>>> -roger > > > >
Hi Rob, On 26/04/22 12:27, Heikki Krogerus wrote: > On Tue, Apr 26, 2022 at 09:42:31AM +0300, Roger Quadros wrote: >> Hi, >> >> On 22/04/2022 08:07, Aswath Govindraju wrote: >>> Hi Roger, >>> >>> On 21/04/22 00:46, Roger Quadros wrote: >>>> Hi, >>>> >>>> On 18/04/2022 08:19, Aswath Govindraju wrote: >>>>> Hi Roger, >>>>> >>>>> On 14/04/22 23:40, Roger Quadros wrote: >>>>>> Hi, >>>>>> >>>>>> On 14/04/2022 11:31, Aswath Govindraju wrote: >>>>>>> Support for polling has been added in the driver, which will be used by >>>>>>> default if interrupts property is not populated. Therefore, remove >>>>>>> interrupts and interrupt-names from the required properties and add a note >>>>>>> under interrupts property describing the above support in driver. >>>>>>> >>>>>>> Suggested-by: Roger Quadros <rogerq@kernel.org> >>>>>> >>>>>> I did not suggest to make interrupts optional by default. >>>>>> >>>>>> What I suggested was that if a DT property exists to explicitly >>>>>> indicate polling mode then interrupts are not required. >>>>>> >>>>> >>>>> ohh okay, got it. However, may I know if adding a dt property to >>>>> indicate polling for aiding the driver, is the correct approach to model it? >>>>> >>>>> In terms of modelling hardware, as interrupts are not connected we are >>>>> not populating the interrupts property. Shouldn't that be all. If we are >>>>> adding a property explicitly to indicate polling that can be used by >>>>> driver, wouldn't that be a software aid being added in the device tree? >>>> >>>> The hardware (tps6598x chip) has an interrupt pin and is expected to be used >>>> in normal case. >>>> >>>> Some buggy boards might have forgot to connect it. We are adding polling mode only for these buggy boards. ;) >>>> So polling mode is an exception. >>>> >>> >>> Yes as you mentioned the interrupt line is expected to connected but >>> there could be cases where there are not enough pins on the SoC and >>> polling is used intentionally. In these cases this would be a feature >>> rather than a bug. >> >> I do not agree that this is a feature but a board defect. You can always use >> a GPIO expander to add more GPIOs than the SoC can provide. >> >> Type-C events are asynchronous and polling is a waste of CPU time. >> What will you do if system suspends and you need to wake up on Type-C >> status change? >> So polling mode is just an exception for the defective boards or could >> be used for debugging. >> >>> >>> Also, I feel like not adding interrupts property in the dt nodes will >>> indicate polling. My question is why are we adding an extra property >>> (which is being used only as an aid in the driver) when this feature can >>> be modeled by making interrupts property optional. >> >> Because interrupt property was not originally optional for this driver. >> >> I would like to hear what Heikki has to say about this. >> >> Any thoughts Heikki? > > I think the question is generic. How should DT describe the > connection/lack of connection? Rob should comment on this. > A gentle ping regarding this. Thanks, Aswath > thanks, > > >> cheers, >> -roger >> >>> >>> Thanks, >>> Aswath >>> >>>> cheers, >>>> -roger >>>> >>>>> >>>>> Thanks, >>>>> Aswath >>>>> >>>>>>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> >>>>>>> --- >>>>>>> Documentation/devicetree/bindings/usb/ti,tps6598x.yaml | 4 ++-- >>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>>>>> index a4c53b1f1af3..1c4b8c6233e5 100644 >>>>>>> --- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>>>>> +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>>>>> @@ -25,6 +25,8 @@ properties: >>>>>>> >>>>>>> interrupts: >>>>>>> maxItems: 1 >>>>>>> + description: >>>>>>> + If interrupts are not populated then by default polling will be used. >>>>>>> >>>>>>> interrupt-names: >>>>>>> items: >>>>>>> @@ -33,8 +35,6 @@ properties: >>>>>>> required: >>>>>>> - compatible >>>>>>> - reg >>>>>>> - - interrupts >>>>>>> - - interrupt-names >>>>>>> >>>>>>> additionalProperties: true >>>>>>> >>>>>> >>>>>> cheers, >>>>>> -roger >>> >>> >
Hi Rob, On 02/05/22 11:00, Aswath Govindraju wrote: > Hi Rob, > > On 26/04/22 12:27, Heikki Krogerus wrote: >> On Tue, Apr 26, 2022 at 09:42:31AM +0300, Roger Quadros wrote: >>> Hi, >>> >>> On 22/04/2022 08:07, Aswath Govindraju wrote: >>>> Hi Roger, >>>> >>>> On 21/04/22 00:46, Roger Quadros wrote: >>>>> Hi, >>>>> >>>>> On 18/04/2022 08:19, Aswath Govindraju wrote: >>>>>> Hi Roger, >>>>>> >>>>>> On 14/04/22 23:40, Roger Quadros wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 14/04/2022 11:31, Aswath Govindraju wrote: >>>>>>>> Support for polling has been added in the driver, which will be used by >>>>>>>> default if interrupts property is not populated. Therefore, remove >>>>>>>> interrupts and interrupt-names from the required properties and add a note >>>>>>>> under interrupts property describing the above support in driver. >>>>>>>> >>>>>>>> Suggested-by: Roger Quadros <rogerq@kernel.org> >>>>>>> >>>>>>> I did not suggest to make interrupts optional by default. >>>>>>> >>>>>>> What I suggested was that if a DT property exists to explicitly >>>>>>> indicate polling mode then interrupts are not required. >>>>>>> >>>>>> >>>>>> ohh okay, got it. However, may I know if adding a dt property to >>>>>> indicate polling for aiding the driver, is the correct approach to model it? >>>>>> >>>>>> In terms of modelling hardware, as interrupts are not connected we are >>>>>> not populating the interrupts property. Shouldn't that be all. If we are >>>>>> adding a property explicitly to indicate polling that can be used by >>>>>> driver, wouldn't that be a software aid being added in the device tree? >>>>> >>>>> The hardware (tps6598x chip) has an interrupt pin and is expected to be used >>>>> in normal case. >>>>> >>>>> Some buggy boards might have forgot to connect it. We are adding polling mode only for these buggy boards. ;) >>>>> So polling mode is an exception. >>>>> >>>> >>>> Yes as you mentioned the interrupt line is expected to connected but >>>> there could be cases where there are not enough pins on the SoC and >>>> polling is used intentionally. In these cases this would be a feature >>>> rather than a bug. >>> >>> I do not agree that this is a feature but a board defect. You can always use >>> a GPIO expander to add more GPIOs than the SoC can provide. >>> >>> Type-C events are asynchronous and polling is a waste of CPU time. >>> What will you do if system suspends and you need to wake up on Type-C >>> status change? >>> So polling mode is just an exception for the defective boards or could >>> be used for debugging. >>> >>>> >>>> Also, I feel like not adding interrupts property in the dt nodes will >>>> indicate polling. My question is why are we adding an extra property >>>> (which is being used only as an aid in the driver) when this feature can >>>> be modeled by making interrupts property optional. >>> >>> Because interrupt property was not originally optional for this driver. >>> >>> I would like to hear what Heikki has to say about this. >>> >>> Any thoughts Heikki? >> >> I think the question is generic. How should DT describe the >> connection/lack of connection? Rob should comment on this. >> > > A gentle ping regarding this. > A gentle ping regarding the above question. Thanks, Aswath > Thanks, > Aswath > >> thanks, >> >> >>> cheers, >>> -roger >>> >>>> >>>> Thanks, >>>> Aswath >>>> >>>>> cheers, >>>>> -roger >>>>> >>>>>> >>>>>> Thanks, >>>>>> Aswath >>>>>> >>>>>>>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> >>>>>>>> --- >>>>>>>> Documentation/devicetree/bindings/usb/ti,tps6598x.yaml | 4 ++-- >>>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>>>>> >>>>>>>> diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>>>>>> index a4c53b1f1af3..1c4b8c6233e5 100644 >>>>>>>> --- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>>>>>> +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml >>>>>>>> @@ -25,6 +25,8 @@ properties: >>>>>>>> >>>>>>>> interrupts: >>>>>>>> maxItems: 1 >>>>>>>> + description: >>>>>>>> + If interrupts are not populated then by default polling will be used. >>>>>>>> >>>>>>>> interrupt-names: >>>>>>>> items: >>>>>>>> @@ -33,8 +35,6 @@ properties: >>>>>>>> required: >>>>>>>> - compatible >>>>>>>> - reg >>>>>>>> - - interrupts >>>>>>>> - - interrupt-names >>>>>>>> >>>>>>>> additionalProperties: true >>>>>>>> >>>>>>> >>>>>>> cheers, >>>>>>> -roger >>>> >>>> >>
diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml index a4c53b1f1af3..1c4b8c6233e5 100644 --- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml @@ -25,6 +25,8 @@ properties: interrupts: maxItems: 1 + description: + If interrupts are not populated then by default polling will be used. interrupt-names: items: @@ -33,8 +35,6 @@ properties: required: - compatible - reg - - interrupts - - interrupt-names additionalProperties: true
Support for polling has been added in the driver, which will be used by default if interrupts property is not populated. Therefore, remove interrupts and interrupt-names from the required properties and add a note under interrupts property describing the above support in driver. Suggested-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> --- Documentation/devicetree/bindings/usb/ti,tps6598x.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)