On Mon, May 11, 2020 at 03:04:57PM +0200, Andrew Lunn wrote:
> > NXP's LX2160ARDB platform currently has the following MDIO-PHY connection.
> >
> > MDIO-1 ==> one 40G PHY, two 1G PHYs(C45), two 10G PHYs(C22)
> > MDIO-2 ==> one 25G PHY
>
> It has been suggested that ACPI only support a one to one
On Mon, May 11, 2020 at 03:04:57PM +0200, Andrew Lunn wrote:
> > NXP's LX2160ARDB platform currently has the following MDIO-PHY connection.
> >
> > MDIO-1 ==> one 40G PHY, two 1G PHYs(C45), two 10G PHYs(C22)
> > MDIO-2 ==> one 25G PHY
>
> It has been suggested that ACPI only support a one to one
> NXP's LX2160ARDB platform currently has the following MDIO-PHY connection.
>
> MDIO-1 ==> one 40G PHY, two 1G PHYs(C45), two 10G PHYs(C22)
> MDIO-2 ==> one 25G PHY
It has been suggested that ACPI only support a one to one
mapping. Each MAC has one MDIO bus, with one PHY on it. KISS.
This
On Mon, May 11, 2020 at 11:22:31AM +0530, Calvin Johnson wrote:
> Thanks Andrew and Jeremy for the detailed discussion!
>
> On Fri, May 08, 2020 at 08:13:01PM +0200, Andrew Lunn wrote:
> > > > It does have a numeric version defined for EISA types. OTOH I suspect
> > > > that
> > > > your right.
On Mon, May 11, 2020 at 11:48:17AM +0100, Russell King - ARM Linux admin wrote:
> On Mon, May 11, 2020 at 03:59:30PM +0530, Calvin Johnson wrote:
> > On Mon, May 11, 2020 at 10:38:49AM +0100, Russell King - ARM Linux admin
> > wrote:
> > > On Mon, May 11, 2020 at 01:30:40PM +0530, Calvin Johnson
On Mon, May 11, 2020 at 03:59:30PM +0530, Calvin Johnson wrote:
> On Mon, May 11, 2020 at 10:38:49AM +0100, Russell King - ARM Linux admin
> wrote:
> > On Mon, May 11, 2020 at 01:30:40PM +0530, Calvin Johnson wrote:
> > > On Sat, May 09, 2020 at 01:42:57AM +0200, Andrew Lunn wrote:
> > > > On
On Mon, May 11, 2020 at 10:38:49AM +0100, Russell King - ARM Linux admin wrote:
> On Mon, May 11, 2020 at 01:30:40PM +0530, Calvin Johnson wrote:
> > On Sat, May 09, 2020 at 01:42:57AM +0200, Andrew Lunn wrote:
> > > On Fri, May 08, 2020 at 05:48:33PM -0500, Jeremy Linton wrote:
> > > > Hi,
> > >
On Mon, May 11, 2020 at 01:30:40PM +0530, Calvin Johnson wrote:
> On Sat, May 09, 2020 at 01:42:57AM +0200, Andrew Lunn wrote:
> > On Fri, May 08, 2020 at 05:48:33PM -0500, Jeremy Linton wrote:
> > > Hi,
> > >
> > > On 5/8/20 3:27 PM, Andrew Lunn wrote:
> > > > > > There is a very small number of
On Sat, May 09, 2020 at 01:42:57AM +0200, Andrew Lunn wrote:
> On Fri, May 08, 2020 at 05:48:33PM -0500, Jeremy Linton wrote:
> > Hi,
> >
> > On 5/8/20 3:27 PM, Andrew Lunn wrote:
> > > > > There is a very small number of devices where the vendor messed up,
> > > > > and did not put valid
On Fri, May 08, 2020 at 05:48:33PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/8/20 3:27 PM, Andrew Lunn wrote:
> > > > There is a very small number of devices where the vendor messed up,
> > > > and did not put valid contents in the ID registers. In such cases, we
> > > > can read the IDs from
Thanks Andrew and Jeremy for the detailed discussion!
On Fri, May 08, 2020 at 08:13:01PM +0200, Andrew Lunn wrote:
> > > It does have a numeric version defined for EISA types. OTOH I suspect that
> > > your right. If there were a "PHY\VEN_ID_" definition, it may
> > > not
> > > be ideal
On 5/8/20 6:42 PM, Andrew Lunn wrote:
On Fri, May 08, 2020 at 05:48:33PM -0500, Jeremy Linton wrote:
Hi,
On 5/8/20 3:27 PM, Andrew Lunn wrote:
There is a very small number of devices where the vendor messed up,
and did not put valid contents in the ID registers. In such cases, we
can read the
On Fri, May 08, 2020 at 05:48:33PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/8/20 3:27 PM, Andrew Lunn wrote:
> > > > There is a very small number of devices where the vendor messed up,
> > > > and did not put valid contents in the ID registers. In such cases, we
> > > > can read the IDs from
Hi,
On 5/8/20 3:27 PM, Andrew Lunn wrote:
There is a very small number of devices where the vendor messed up,
and did not put valid contents in the ID registers. In such cases, we
can read the IDs from device tree. These are then used in exactly the
same way as if they were read from the
> > There is a very small number of devices where the vendor messed up,
> > and did not put valid contents in the ID registers. In such cases, we
> > can read the IDs from device tree. These are then used in exactly the
> > same way as if they were read from the device.
> >
>
> Is that the case
Hi,
On 5/8/20 1:13 PM, Andrew Lunn wrote:
It does have a numeric version defined for EISA types. OTOH I suspect that
your right. If there were a "PHY\VEN_ID_" definition, it may not
be ideal to parse it. Instead the normal ACPI model of exactly matching the
complete string in the phy
> > It does have a numeric version defined for EISA types. OTOH I suspect that
> > your right. If there were a "PHY\VEN_ID_" definition, it may not
> > be ideal to parse it. Instead the normal ACPI model of exactly matching the
> > complete string in the phy driver might be more
On Thu, May 07, 2020 at 02:54:09PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/7/20 12:27 PM, Andy Shevchenko wrote:
> > On Thu, May 7, 2020 at 4:26 PM Jeremy Linton wrote:
> > > On 5/5/20 8:29 AM, Calvin Johnson wrote:
> >
> > > > + if (sscanf(cp, "ethernet-phy-id%4x.%4x",
> > > > +
Hi,
On 5/7/20 12:27 PM, Andy Shevchenko wrote:
On Thu, May 7, 2020 at 4:26 PM Jeremy Linton wrote:
On 5/5/20 8:29 AM, Calvin Johnson wrote:
+ if (sscanf(cp, "ethernet-phy-id%4x.%4x",
+, ) == 2) {
+ *phy_id = ((upper & 0x) << 16) |
On Thu, May 7, 2020 at 4:26 PM Jeremy Linton wrote:
> On 5/5/20 8:29 AM, Calvin Johnson wrote:
> > + if (sscanf(cp, "ethernet-phy-id%4x.%4x",
> > +, ) == 2) {
> > + *phy_id = ((upper & 0x) << 16) | (lower & 0x);
> > +
Hi,
On 5/5/20 8:29 AM, Calvin Johnson wrote:
Extract phy_id from compatible string. This will be used by
fwnode_mdiobus_register_phy() to create phy device using the
phy_id.
Signed-off-by: Calvin Johnson
---
Changes in v3: None
Changes in v2: None
drivers/net/phy/phy_device.c | 21
On Tue, May 05, 2020 at 05:15:16PM +0300, Andy Shevchenko wrote:
> On Tue, May 5, 2020 at 4:29 PM Calvin Johnson
> > + if (sscanf(cp, "ethernet-phy-id%4x.%4x",
> > + , ) == 2) {
>
> > + *phy_id = ((upper & 0x) << 16) | (lower &
> >
On Tue, May 5, 2020 at 4:29 PM Calvin Johnson
wrote:
>
> Extract phy_id from compatible string. This will be used by
> fwnode_mdiobus_register_phy() to create phy device using the
> phy_id.
> +int fwnode_get_phy_id(struct fwnode_handle *fwnode, u32 *phy_id)
> +{
> + const char *cp;
> +
Extract phy_id from compatible string. This will be used by
fwnode_mdiobus_register_phy() to create phy device using the
phy_id.
Signed-off-by: Calvin Johnson
---
Changes in v3: None
Changes in v2: None
drivers/net/phy/phy_device.c | 21 +
include/linux/phy.h | 5
24 matches
Mail list logo
