linux-kernel - Re: [RFC PATCH net-next 1/6] net: ethernet: implement OPEN Alliance control transaction interface

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <cf23ed3c-d1cb-61fd-a305-e2787ef70cb1@microchip.com>
Date:   Wed, 20 Sep 2023 12:40:31 +0000
From:   <Parthiban.Veerasooran@...rochip.com>
To:     <andrew@...n.ch>
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>, <Ciprian.Regus@...log.com>,
        <jtm@...ingdog.com>
Subject: Re: [RFC PATCH net-next 1/6] net: ethernet: implement OPEN Alliance
 control transaction interface

Hi Andrew,

On 19/09/23 8:43 pm, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>>>> +static void oa_tc6_prepare_ctrl_buf(struct oa_tc6 *tc6, u32 addr, u32 val[],
>>>> +                                 u8 len, bool wnr, u8 *buf, bool ctrl_prot)
>>>> +{
>>>> +     u32 hdr;
>>>> +
>>>> +     /* Prepare the control header with the required details */
>>>> +     hdr = FIELD_PREP(CTRL_HDR_DNC, 0) |
>>>> +           FIELD_PREP(CTRL_HDR_WNR, wnr) |
>>>> +           FIELD_PREP(CTRL_HDR_AID, 0) |
>>>> +           FIELD_PREP(CTRL_HDR_MMS, addr >> 16) |
>>>> +           FIELD_PREP(CTRL_HDR_ADDR, addr) |
>>>> +           FIELD_PREP(CTRL_HDR_LEN, len - 1);
>>>> +     hdr |= FIELD_PREP(CTRL_HDR_P, oa_tc6_get_parity(hdr));
>>>> +     *(u32 *)buf = cpu_to_be32(hdr);
>>>> +
>>>> +     if (wnr) {
>>>
>>> What does wnr mean? Maybe give it a more meaningful name, unless it is
>>> actually something in the standard. Kerneldoc would also help.
>> Ah, it is "write not read". Shall I name it as "write_not_read" ?
> 
> You might want to describe the high level concept as well in this
> file. What i _think_ this is about is that SPI is sort of a full
> duplex bus. While you are sending data to the SPI device, the device
> could also be sending a data to the CPU? And 'write not read' here
> means ignore what we receive from the device?
Ah ok, I think there is a misunderstanding here. This is related to OPEN 
Alliance protocol. Control transactions consist of one or more control 
commands. Control commands are used by the SPI host to read and write 
registers within the MAC-PHY. Each control commands are composed of a 
32-bit control command header followed by register data. WNR (write not 
read) bit in the control command header indicates if data is to be 
written to registers (when set) or read from registers (when clear). so 
basically it indicates the type of the control command on the registers.
> 
>> Ok, as per OA spec, up to 128 consecutive registers read or write can be
>> possible. So the maximum possible size would be 1032. As you suggested
>> will allocate this size of memory in the startup.
> 
> Yes, 1032 bytes it not huge, so allocate it once and keep it for the
> lifetime of the device.
Sure, will do that.
> 
>>>> +void oa_tc6_deinit(struct oa_tc6 *tc6)
>>>> +{
>>>> +     kfree(tc6);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(oa_tc6_deinit);
>>>
>>> Maybe consider a devm_ API to make the MAC driver simpler.
>> Sorry I don't get your point. Could you please explain bit more?
> 
> At least at this stage in the patch series, all you are doing is
> allocating memory. You add more code later, which might invalidate my
> point. But if all you are doing is allocating memory, you could use
> devm_kmalloc(). The driver core will then take care of releasing the
> memory when the driver is unloaded, or probe fails. That makes cleanup
> simpler and memory leaks less likely. There are a lot of devm_
> helpers, see if you can use them.
Sure, noted.

Best Regards,
Parthiban V
> 
>          Andrew
>