Re: [PATCH net-next v3 00/10] macb usrio/tsu patches

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

On Thu, Mar 12, 2026 at 11:09:24AM +0100, Théo Lebrun wrote:
> Hello Conor,
> 
> On Tue Mar 10, 2026 at 6:17 PM CET, Conor Dooley wrote:
> > At the very least, it'd be good of the soc vendor folks could check
> > their platforms and see if their usrio stuff actually lines up with what
> > the driver currently calls "macb_default_usrio". Ours didn't and it was
> > a nasty surprise.
> >
> > Theo, you added eyeq5 recently. Does it genuinely have the same usrio
> > bits as the at91 devices?
> 
> Sorry I missed your direct mention. After checking (because I completely
> ignored this part of the code before), the User I/O feature is disabled
> on EyeQ5 & EyeQ6H. It can be seen from DCFG1 BIT(9). It was invisible
> because the USRIO register turns read-only when User I/O is disabled.

Ye, my assumption was that on your platform and sifive it's not enabled
but didn't have the behaviour of np4 where accesses don't complete.

> 
> 1. So I thought about adding runtime detection.
> 
> 2. But then having eyeq5_config->usrio made no sense so I dropped it.
> 
> 3. And then I thought that a config having usrio being NULL should
>    imply MACB_CAPS_USRIO_DISABLED to ensure we don't NULL dereference
>    the bp->usrio pointer.
> 
> #1 is useless for EyeQ combined with #2 and #3, but it should be useful
> for the many compatibles that inherited the wrong default value of
> at91_default_usrio.

Yeah, that's a good shout. I never checked to see if this had a control.

> I am sending those three patches as a reply, feel free to pick them up
> if you consider them useful. They apply on top of your series and have
> been tested on EyeQ5.

Ye, I think they're a good idea. Thanks for sending em :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]