netdev - Re: [PATCH net-next 0/5] Modernize bitbanged GPIO MDIO

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

Date:   Fri, 2 Mar 2018 10:44:08 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH net-next 0/5] Modernize bitbanged GPIO MDIO

On Tue, Feb 27, 2018 at 3:00 PM, Florian Fainelli <f.fainelli@...il.com> wrote:
> On 02/25/2018 04:51 AM, Linus Walleij wrote:
>> This kills off the platform data support from the bitbanged
>> GPIO-based MDIO driver and moves it over to using GPIO
>> descriptors exclusively.
>>
>> We are certainly not going to merge any more platforms into
>> the kernel using platform data, and nothing is using it at the
>> moment. The only concern would be out-of-tree platforms, and
>> those are not the concern of the kernel community. They need
>> to move to use device tree (or ACPI etc) like everyone else.
>
> Please refrain from making statements like those because there are
> perfectly valid use cases for never seeing ACPI or Device Tree for a
> given platform, yes there will be push back, and yes, if DT or ACPI is
> possible, it should be used but I can guarantee you there are platforms
> out there that won't be converted to DT (e.g: tons of MIPS-based router,
> x86 add-on modules etc.).
>
> Nack on patches 1 and 3, because I am slowly resuming work on an x86
> platform driver that uses the mdio-gpio driver with platform data, and
> DT is not an option there, and I would rather not have to revert your
> changes.

OK fair enough, there are some platform data use cases that
remain or are on their way in.

I will try to rewrite the series a bit as Andrew suggested to just do
descriptor conversion and take it from there, and also
try to make sure that it will work fine with any descriptor also if
it is coming from a board file.

Anyway, the platform data we have is:

struct mdio_gpio_platform_data {
        /* GPIO numbers for bus pins */
        unsigned int mdc;
        unsigned int mdio;
        unsigned int mdo;

        bool mdc_active_low;
        bool mdio_active_low;
        bool mdo_active_low;

        u32 phy_mask;
        u32 phy_ignore_ta_mask;
        int irqs[PHY_MAX_ADDR];
        /* reset callback */
        int (*reset)(struct mii_bus *bus);
};

So moving to using descriptors will get rid of the six first
platform data entries.

What about the last four things, phy_mask, phy_ignore_ta_mask,
irqs[] and the .reset() callback? None of this is documented or
used anywhere so I was a bit confused about what to do with it...
Does boardfiles adding GPIO MDIO need all this?

Yours,
Linus Walleij