linux-kernel - Re: [PATCH net-next 5/6] net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ea99a19b-3d3e-4a11-01d5-d49f95be36a0@bang-olufsen.dk>
Date:   Thu, 14 Oct 2021 12:11:16 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Alvin Šipraga <alvin@...s.dk>
CC:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Michael Rasmussen <MIR@...g-olufsen.dk>,
        netdev <netdev@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 5/6] net: dsa: realtek-smi: add rtl8365mb
 subdriver for RTL8365MB-VC

On 10/13/21 5:12 PM, Linus Walleij wrote:
> On Tue, Oct 12, 2021 at 2:37 PM Alvin Šipraga <alvin@...s.dk> wrote:
> 
>> This patch adds a realtek-smi subdriver for the RTL8365MB-VC 4+1 port
>> 10/100/1000M switch controller. The driver has been developed based on a
>> GPL-licensed OS-agnostic Realtek vendor driver known as rtl8367c found
>> in the OpenWrt source tree.
> (...)
>> Co-developed-by: Michael Rasmussen <mir@...g-olufsen.dk>
>> Signed-off-by: Michael Rasmussen <mir@...g-olufsen.dk>
>> Signed-off-by: Alvin Šipraga <alsi@...g-olufsen.dk>
> 
> Overall this driver looks very good :)
> 
> Some minor nits below:
> 
>> +static irqreturn_t rtl8365mb_irq(int irq, void *data)
>> +{
> (...)
>> +       if (!line_changes)
>> +               goto out_none;
>> +
>> +       while (line_changes) {
>> +               int line = __ffs(line_changes);
>> +               int child_irq;
>> +
>> +               line_changes &= ~BIT(line);
>> +
>> +               child_irq = irq_find_mapping(smi->irqdomain, line);
>> +               handle_nested_irq(child_irq);
>> +       }
> 
> What about just:
> 
> for_each_set_bit(offset, &line_changes, 32) {
>    child_irq = irq_find_mapping(smi->irqdomain, line);
>    handle_nested_irq(child_irq);
> }
> 
> ?
> 
> I don't know how many or which bits are valid IRQs, 16 maybe rather
> than 32.
> 
>> +static struct irq_chip rtl8365mb_irq_chip = {
>> +       .name = "rtl8365mb",
>> +       /* The hardware doesn't support masking IRQs on a per-port basis */
>> +};
> 
> I would rathe make this a dynamically allocated struct inside
> struct rtl8365mb, so the irqchip lives with the instance of the
> chip. (Which is nice if there would happen to be two of these
> chips in a system.)

Forgive my ignorance, but is it actually necessary? Can't multiple 
instances of the switch still use the same irq_chip structure? That 
seems to be OK for the dummy chip, for example (dummychip.c). I also 
failed to find a driver which does it the way you suggest.

I will incorporate the rest of your feedback into v3. :)

> 
>> +static int _rtl8365mb_irq_enable(struct realtek_smi *smi, bool enable)
> 
> I'm personally a bit allergic to _rand_underscore_naming, as sometimes
> that means "inner function" and sometimes it means "compiler intrinsic"
> I would just name it rtl8365mb_irq_config_commit()
> 
> (no strong opinion)
> 
>> +       /* Configure chip interrupt signal polarity */
>> +       irq_trig = irqd_get_trigger_type(irq_get_irq_data(irq));
> 
> Nice that you preserve this edge trigger config from the machine
> description (DT)!
> 
> With this fixed or not (your preference)
> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
> 
> Yours,
> Linus Walleij
>