On Fri, Mar 21, 2025 at 03:41:18PM +0200, Matti Vaittinen wrote: > On 21/03/2025 15:16, Andy Shevchenko wrote: > > On Fri, Mar 21, 2025 at 02:17:16PM +0200, Matti Vaittinen wrote: > > > On 21/03/2025 14:06, Andy Shevchenko wrote: > > > > On Fri, Mar 21, 2025 at 10:01:00AM +0200, Matti Vaittinen wrote: > > > > > On 20/03/2025 15:16, Andy Shevchenko wrote: > > > > > > On Thu, Mar 20, 2025 at 10:22:00AM +0200, Matti Vaittinen wrote: > > > > > > > > You can get rid of all of these by simply using __le16. I do not understand why > > > > it's not used so far. I thought that bits are mirrored, that may explain the > > > > case, but now I do not see any problem to use __le16 directly. > > > > > > This discussion is going in circles now. That was discussed in the RFC > > > review with Jonathan, which I did also tell to you during the v7 review: > > > > Yes, because I think we all were confused by the bits representations, > > but now I see it clearly and I do not understand why should we go the way > > you suggested as it makes things a bit tangled in my opinion. > > > > Jonathan, do you still think the two separate bytes are better than __le16? > > If so, what are the pros of this solution? > > I don't think Jonathan thought this is better. I'm not sure if you read the > RFC conversation. > > I told this is easier for me to understand. Jonathan merely told he can live > with that. For this particular driver it matters because I'm expecting to be > maintaining it. It's easier to maintain code which one can understand, and > if subsystem maintainer can live with it, then I suppose it's the pro you > are looking for. What if the maintainer will be hit by a bus? The point is we should also think for unfamiliar possible maintainers and strange readers. But sure, not my call right now. -- With Best Regards, Andy Shevchenko
