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: <b6505e78-9dbc-9c97-b4f8-1c9eac24b52e@arm.com>
Date:   Mon, 3 Feb 2020 15:10:23 -0600
From:   Jeremy Linton <jeremy.linton@....com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, opendmb@...il.com, f.fainelli@...il.com,
        davem@...emloft.net, bcm-kernel-feedback-list@...adcom.com,
        linux-kernel@...r.kernel.org, wahrenst@....net,
        hkallweit1@...il.com
Subject: Re: [PATCH 3/6] net: bcmgenet: enable automatic phy discovery

Hi,

On 2/2/20 7:15 PM, Andrew Lunn wrote:
>> I though I should clarify the direct question here about ACPI. ACPI does
>> have the ability to do what you describe, but it a more rigorous way. If you
>> look at the ACPI GenericSerialBus abstraction you will see how ACPI would
>> likely handle this situation. I've been considering making a similar comment
>> in that large fwnode patch set posted the other day.

I should have been a lot more specific here, but I didn't want to write 
a book.

> 
> I know ~0 about ACPI. But it does not seem unreasonable to describe an
> MDIO bus in the same way as an i2c bus, or an spi bus. Each can have
> devices on it, at specific addresses. Each needs common properties
> like interrupts, and each needs bus specific properties like SPI
> polarity. And you need pointers to these devices, so that other
> subsystems can use them.
> 
> So maybe the correct way to describe this is to use ACPI
> GenericSerialBus?

AFAIK, not as the specification stands today.

First its not defined for MDIO (see 6-240 in acpi 6.3) , and secondly 
because its intended to be used from AML (one of the examples IIRC is to 
read battery vendor info). That implies to me, that the ACPI standards 
body's would also have to add some additional methods which configure 
and return state about the phys. AKA some of the linux phy_() functions 
would just redirect to AML equivalents the same way there are AML 
battery functions for returning status/etc.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ