[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4c1d0d38-c459-4722-bead-7660d85f4925@lunn.ch>
Date: Tue, 19 Sep 2023 14:58:29 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Parthiban.Veerasooran@...rochip.com
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
corbet@....net, Steen.Hegelund@...rochip.com,
rdunlap@...radead.org, horms@...nel.org, casper.casan@...il.com,
netdev@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
Horatiu.Vultur@...rochip.com, Woojung.Huh@...rochip.com,
Nicolas.Ferre@...rochip.com, UNGLinuxDriver@...rochip.com,
Thorsten.Kummermehr@...rochip.com
Subject: Re: [RFC PATCH net-next 1/6] net: ethernet: implement OPEN Alliance
control transaction interface
On Tue, Sep 19, 2023 at 11:13:13AM +0000, Parthiban.Veerasooran@...rochip.com wrote:
> Hi Andrew,
>
> On 13/09/23 7:46 am, Andrew Lunn wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> >> +struct oa_tc6 {
> >> + struct spi_device *spi;
> >> + bool ctrl_prot;
> >> +};
> >
> > Should this be considered an opaque structure which the MAC driver
> > should not access the members?
Opaque vs not opaque is an important design decision. If the MAC
driver is allowed to directly access this structure, you should
document the locking concept. If the MAC is not supposed to access it
directly, only uses getters/setters, that also needs documenting, and
maybe even make it a void * in the MAC driver.
Andrew
Powered by blists - more mailing lists