netdev - Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

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]

Date:   Fri, 19 Jan 2018 19:07:29 +0100
From:   Marcin Wojtas <mw@...ihalf.com>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc:     Graeme Gregory <graeme.gregory@...aro.org>,
        Andrew Lunn <andrew@...n.ch>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "<netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Russell King - ARM Linux <linux@....linux.org.uk>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "Antoine T?nart" <antoine.tenart@...e-electrons.com>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Gregory CLEMENT <gregory.clement@...e-electrons.com>,
        Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
        Nadav Haklai <nadavh@...vell.com>,
        Neta Zur Hershkovits <neta@...vell.com>,
        Grzegorz Jaszczyk <jaz@...ihalf.com>,
        Tomasz Nowicki <tn@...ihalf.com>,
        Hanjun Guo <hanjun.guo@...aro.org>,
        Sudeep Holla <sudeep.holla@....com>,
        mika.westerberg@...ux.intel.com
Subject: Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

Hi Mika,

2018-01-18 14:00 GMT+01:00 Andrew Lunn <andrew@...n.ch>:
>> I CC'ed Mika since he is more familiar with handling these bits of ACPI
>> specs - I wonder whether this is a problem that cropped up on x86
>> systems too.
>
> Hi Lorenzo
>
> There is nothing about MDIO, PHYs, Ethernet switches, etc in version
> 6.2 of the spec. If x86 has this, it must be after 6.2 was released.
> I would not be too surprised if x86 has none of this. If you look at
> the typical drives used on x86, i210, e1000e, ixgb, r8169, etc. They
> are all PCI devices, and hide all this.
>
>> I do not think there is one and only answer but there must be a single
>> set of bindings and if the ACPI specs already cater for some of them
>> we have to reuse them.
>
> Agreed. Due diligence so far suggests there is nothing already
> defined. But im a newbie to ACPI, so could be looking in the wrong
> place. I really hope there is somebody like Rob Herring, the DT
> maintainer, who keeps an eye on all ACPI talk and would tell us if we
> are heading off in the wrong direction.
>

My initial approach with MDIO bus with PHYs as child nodes was super
easy to describe and handle in Linux - please refer to:
- typical representation of mdio bus with the phys -
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/mdio.txt?h=v4.15-rc8
- my patches in the initial series
However I guess it would be more proper to use the
GenericSerialBus-based description, as advised in ACPI Spec. The
question is, whether we should define new type of a bus or not
(MdioSerialBus, similar to e.g. I2cSerialBus).

Since I have a code that can be tested and easily modified to use
different ACPI approaches with real platform MDIO controller
(mvmdio.c) and NIC (mvpp2.c), in coming weeks I may be able to find
some time to prepare a proof of concept based on GenericSerialBus.
Please expect some RFC patches hopefully right after the coming merge
window is closed.

Of course, if I come up on some ACPI - specific implementation
questions, I won't hesitate to ask in this thred. I will also
appreciate any hints. For now my two main concerns are:
- The PHY address on the mdio bus - should it be put into _CRS ->
GenericSerialBus() field or separate _ADR? I'd lean towards first
option.
- The PHY type - in Linux it's resolved basing on two generic
compatible strings
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/phy.txt?h=v4.15-rc8).
I'd put it as a sort of ID into GenericSerialBus(). If you agree - any
specific filed that you would try to use?

Do I understand correctly that the MDIO controller node should
comprise OperationRegion() definition of the GenericSerialBus?

I'm looking forward to your feedback.

Thanks,
Marcin