netdev - Re: [PATCH v4 4/5] net: rnpgbe: Add basic mbx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <955130413833E341+20250818021424.GA1385422@nic-Precision-5820-Tower>
Date: Mon, 18 Aug 2025 10:14:24 +0800
From: Yibo Dong <dong100@...se.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
	corbet@....net, gur.stavi@...wei.com, maddy@...ux.ibm.com,
	mpe@...erman.id.au, danishanwar@...com, lee@...ger.us,
	gongfan1@...wei.com, lorenzo@...nel.org, geert+renesas@...der.be,
	Parthiban.Veerasooran@...rochip.com, lukas.bulwahn@...hat.com,
	alexanderduyck@...com, richardcochran@...il.com,
	netdev@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 4/5] net: rnpgbe: Add basic mbx_fw support

On Fri, Aug 15, 2025 at 03:21:33PM +0200, Andrew Lunn wrote:
> > > > +		return err;
> > > > +	}
> > > > +	do {
> > > > +		err = wait_event_interruptible_timeout(cookie->wait,
> > > > +						       cookie->done == 1,
> > > > +						       cookie->timeout_jiffes);
> > > > +	} while (err == -ERESTARTSYS);
> > > 
> > > This needs a comment, because i don't understand it.
> > > 
> > > 
> > 
> > wait_event_interruptible_timeout return -ERESTARTSYS if it was interrupted
> > by a signal, which will cause misjudgement about cookie->done is timeout. 
> > In this case, just wait for timeout.
> > Maybe comment link this?
> > /* If it was interrupted by a signal (-ERESTARTSYS), it is not true timeout,
> >  * just wait again.
> >  */
> 
> But why use wait_event_interruptible_timout() if you are going to
> ignore all interrupts, a.k.a. signals? Why not use
> wait_event_timeout()?
> 

Yes, I should use wait_event_timeout, I will fix it.

> > > What exactly is a lane here? Normally we would think of a lane is
> > > -KR4, 4 SERDES lanes making one port. But the MAC address is a
> > > property of the port, not the lane within a port.
> > > 
> > 
> > lane is the valid bit in 'reply.mac_addr.ports'.
> > Maybe change it to 'port', that is more appropriate.
> 
> You need to be careful with your terms. I read in another patch, that
> there is a dual version and a quad version. I've not yet seen how you
> handle this, but i assume they are identical, and appear on the PCI
> bus X number of times, and this driver will probe X times, once per
> instance. We would normally refer to each instance as an
> interface. But this driver also mentions PF, so i assume you also have
> VFs? And if you have VF, i assume you have an embedded switch which
> each of the VFs are connected to. Each VF would normally be connected
> to a port of the switch.
> 
> So even though you don't have VF support yet, you should be thinking
> forward. In the big picture architecture, what does this lane/port
> represent? What do other drivers call it?
> 

"lane/port" in the code does not refer to SERDES physical lanes (like KR4’s
4 lanes per port). It is for physical network ports (or a PF). We use
it as a valid bit since fw cmd support multiple physical network ports
within a pci device (with one mbx handler). So, for each PCI bus X, 'port'
is started from 0. 

PCI bus X -- port0
	  |
	  -- port1

PCI bus Y -- port0
	  |
	  -- port1

> > > Another example of a bad structure layout. It would of been much
> > > better to put the two u8 after speed.
> > > 
> > > > +} __packed;
> > > 
> > > And because this is packed, and badly aligned, you are forcing the
> > > compiler to do a lot more work accessing these members.
> > > 
> > 
> > Yes, It is bad. But FW use this define, I can only follow the define...
> > Maybe I can add comment here?
> > /* Must follow FW define here */ 
> 
> No need. When somebody sees __packed, it becomes obvious this is ABI
> and cannot be changed. Just think about it for any future extensions
> to the firmware ABI.
> 
> > 
> > > > +
> > > > +static inline void ability_update_host_endian(struct hw_abilities *abi)
> > > > +{
> > > > +	u32 host_val = le32_to_cpu(abi->ext_ability);
> > > > +
> > > > +	abi->e_host = *(typeof(abi->e_host) *)&host_val;
> > > > +}
> > > 
> > > Please add a comment what this is doing, it is not obvious.
> > > 
> > > 
> > 
> > Maybe link this?
> > /* Converts the little-endian ext_ability field to host byte order,
> >  * then copies the value into the e_host field by reinterpreting the
> >  * memory as the type of e_host (likely a bitfield or structure that
> >  * represents the extended abilities in a host-friendly format).
> >  */
> 
> This explains what you are doing, but why? Why do you do this only to
> this field? What about all the others?
> 
>      Andrew
> 

FW stores extended ability information in `ext_ability` as a 32-bit
little-endian value. To make these flags easily accessible in the kernel
(via named 'bitfields' instead of raw bitmask operations), we use the union's
`e_host` struct, which provides named bits (e.g., `wol_en`, `smbus_en`).
Others 'not bitfields' is just use 'lexx_to_cpu' when value is used.

Thanks for your feedback.