[PATCH v3 4/5] dt-bindings: usb/ti,am62-usb.yaml: Add PHY2 register space

Conor Dooley conor at kernel.org
Fri Feb 2 08:39:16 PST 2024


On Fri, Feb 02, 2024 at 12:13:22PM +0200, Roger Quadros wrote:
> 
> 
> On 02/02/2024 11:53, Conor Dooley wrote:
> > On Fri, Feb 02, 2024 at 11:36:55AM +0200, Roger Quadros wrote:
> >>
> >>
> >> On 01/02/2024 21:13, Conor Dooley wrote:
> >>> On Thu, Feb 01, 2024 at 12:35:22PM -0600, Bin Liu wrote:
> >>>> On Thu, Feb 01, 2024 at 06:18:05PM +0000, Conor Dooley wrote:
> >>>>> On Thu, Feb 01, 2024 at 06:15:20PM +0000, Conor Dooley wrote:
> >>>>>> On Thu, Feb 01, 2024 at 02:03:31PM +0200, Roger Quadros wrote:
> >>>>>>> So far this was not required but due to the newly identified
> >>>>>>> Errata i2409 [1] we need to poke this register space.
> >>>>>>>
> >>>>>>> [1] https://www.ti.com/lit/er/sprz487d/sprz487d.pdf
> >>>>>>>
> >>>>>>> Signed-off-by: Roger Quadros <rogerq at kernel.org>
> >>>>>>
> >>>>>> Acked-by: Conor Dooley <conor.dooley at microchip.com>
> >>>>>
> >>>>> Actually, where is the user for this that actually pokes the register
> >>>>> space?
> >>
> >> https://lore.kernel.org/all/20240201121220.5523-5-rogerq@kernel.org/
> >>
> >>>>> You're adding another register region, so I went to check how you were
> >>>>> handling that in drivers, but there's no driver patch.
> >>>>
> >>>> See Roger's another patch set 'Add workaround for Errata i2409' posted
> >>>> on 16th.
> >>>
> >>> This patch should be with that series, not with these dts patches.
> >>>
> >>
> >> Why not? There should be no dependency between DTS and driver implementation.
> >>
> >> As DTS and driver will be merged by separate maintainers I thought it
> >> would be easier for maintainers this way.
> > 
> > dts and driver might be merged by different people, but dt-bindings and
> > drivers are merged by the same people. This is a bindings patch, not a
> 
> If we do that then I get a bunch of dtbs_check warnings
> 
> dwc3-usb at f900000: reg: [[0, 261095424, 0, 2048], [0, 261128192, 0, 1024]] is too long

I don't know what your platform maintainers view is, but to me it is fine
as long as linux-next is clean.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240202/7217cbf3/attachment.sig>


More information about the linux-arm-kernel mailing list