Re: [PATCH v4 4/5] net: rnpgbe: Add basic mbx_fw support

[Andrew Lunn <andrew@lunn.ch>]

> > Using struct_size() makes me think this is supposed to be a flexible
> > array? I've never used them myself, but shouldn't be some markup so
> > the compiler knows priv_len is the len of priv?
> > 
> 
> Maybe link this?
> struct mbx_req_cookie {
> ....
> 	int priv_len;
> 	char priv[] __counted_by(priv_len);
> }

Yes, that looks correct.

> > > +		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()?

> > > +	if ((1 << lane) & le32_to_cpu(reply.mac_addr.lanes))
> > 
> > BIT(). And normally the & would be the other way around.
> > 
> 
> Maybe changed link this?
> ...
> if (le32_to_cpu(reply.mac_addr.ports) & BIT(lane))

Yes, that is better.

> > 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?

> > 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