On Tue, Sep 29, 2020 at 04:53:47PM +0100, Grant Likely wrote:
>
>
> On 29/09/2020 14:43, Andrew Lunn wrote:
> > On Tue, Sep 29, 2020 at 10:47:03AM +0530, Calvin Johnson wrote:
> > > Hi Grant,
> > >
> > > On Fri, Sep 25, 2020 at 02:34:21PM +0100, Grant Likely wrote:
> > > > > +DSDT entry for MDIO
On 29/09/2020 15:59, Andrew Lunn wrote:
IIRC both UEFI and ACPI define only little-endian data structures.
The code does not attempt to convert these into CPU endianness
at the moment. In theory it could be changed to support either, but
this seems non-practical for the UEFI runtime services
On 29/09/2020 14:43, Andrew Lunn wrote:
On Tue, Sep 29, 2020 at 10:47:03AM +0530, Calvin Johnson wrote:
Hi Grant,
On Fri, Sep 25, 2020 at 02:34:21PM +0100, Grant Likely wrote:
+DSDT entry for MDIO node
+
+a) Silicon Component
+
+ Scope(_SB)
On Tue, Sep 29, 2020 at 4:49 PM Andy Shevchenko
wrote:
> On Tue, Sep 29, 2020 at 5:32 PM Andrew Lunn wrote:
> > On Tue, Sep 29, 2020 at 04:55:40PM +0300, Andy Shevchenko wrote:
> > Does Tianocore, or any
> > other implementations, have the needed le32_to_cpu() calls so that
> > they can boot on
> > Does it have a standardized way of
> > saying a device is big endian, swap words around if appropriate when
> > doing IO?
>
> I guess this is not applicable to ACPI. Does Linux have a standardized way?
DT does. You add the property 'little-endian' to indicate you should
do IO to the device us
> IIRC both UEFI and ACPI define only little-endian data structures.
> The code does not attempt to convert these into CPU endianness
> at the moment. In theory it could be changed to support either, but
> this seems non-practical for the UEFI runtime services that require
> calling into firmware
On Tue, Sep 29, 2020 at 5:32 PM Andrew Lunn wrote:
>
> On Tue, Sep 29, 2020 at 04:55:40PM +0300, Andy Shevchenko wrote:
> > On Tue, Sep 29, 2020 at 4:43 PM Andrew Lunn wrote:
> > > On Tue, Sep 29, 2020 at 10:47:03AM +0530, Calvin Johnson wrote:
> > > > On Fri, Sep 25, 2020 at 02:34:21PM +0100, Gr
On Tue, Sep 29, 2020 at 3:44 PM Andrew Lunn wrote:
> On Tue, Sep 29, 2020 at 10:47:03AM +0530, Calvin Johnson wrote:
> > On Fri, Sep 25, 2020 at 02:34:21PM +0100, Grant Likely wrote:
> > > > +DSDT entry for MDIO node
> > > > +
> > > > +a) Silicon Component
> > > > +
On Tue, Sep 29, 2020 at 04:55:40PM +0300, Andy Shevchenko wrote:
> On Tue, Sep 29, 2020 at 4:43 PM Andrew Lunn wrote:
> > On Tue, Sep 29, 2020 at 10:47:03AM +0530, Calvin Johnson wrote:
> > > On Fri, Sep 25, 2020 at 02:34:21PM +0100, Grant Likely wrote:
>
> ...
>
> > Newbie ACPI question: Does A
On Tue, Sep 29, 2020 at 4:43 PM Andrew Lunn wrote:
> On Tue, Sep 29, 2020 at 10:47:03AM +0530, Calvin Johnson wrote:
> > On Fri, Sep 25, 2020 at 02:34:21PM +0100, Grant Likely wrote:
...
> Newbie ACPI question: Does ACPI even support big endian CPUs, given
> its x86 origins?
I understand the ne
On Tue, Sep 29, 2020 at 10:47:03AM +0530, Calvin Johnson wrote:
> Hi Grant,
>
> On Fri, Sep 25, 2020 at 02:34:21PM +0100, Grant Likely wrote:
> > > +DSDT entry for MDIO node
> > > +
> > > +a) Silicon Component
> > > +
> > > + Scope(_SB)
> > > + {
> > > +
Hi Grant,
On Fri, Sep 25, 2020 at 02:34:21PM +0100, Grant Likely wrote:
> > +DSDT entry for MDIO node
> > +
> > +a) Silicon Component
> > +
> > + Scope(_SB)
> > + {
> > + Device(MDI0) {
> > + Name(_HID, "NXP0006")
> > + Name(_CCA, 1)
On Fri, Sep 25, 2020 at 02:34:21PM +0100, Grant Likely wrote:
> On 15/07/2020 10:03, Calvin Johnson wrote:
> > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
> > provide them to be connected to MAC.
> >
> > An ACPI node property "mdio-handle" is introduced to reference the
> > M
On 15/07/2020 10:03, Calvin Johnson wrote:
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
An ACPI node property "mdio-handle" is introduced to reference the
MDIO bus on which PHYs are registered with autoprobing method used
by mdiobus_regis
On 31/07/2020 16:14, Andrew Lunn wrote:
DT can be used on x86, and i suspect it is a much easier path of least
resistance.
And you can easily overlay Device Tree to an existing system by using
either a full Device Tree overlay (dtbo) or using CONFIG_OF_DYNAMIC and
creating nodes on the fly.
> > > DT can be used on x86, and i suspect it is a much easier path of least
> > > resistance.
> >
> > And you can easily overlay Device Tree to an existing system by using
> > either a full Device Tree overlay (dtbo) or using CONFIG_OF_DYNAMIC and
> > creating nodes on the fly.
>
> Why do you nee
> However, if those properties are never going to be supplied via ACPI
> on any production systems, the code added in order to be able to
> process them will turn out to be useless and I don't think anyone
> wants useless code in the kernel.
>
> So the real question is whether or not there will be
Hi Andrew,
On Tue, Jul 28, 2020 at 10:34 PM Andrew Lunn wrote:
>
> Hi Everybody
>
> So i think it is time to try to bring this discussion to some sort of
> conclusion.
>
> No ACPI maintainer is willing to ACK any of these patches. Nor are
> they willing to NACK them.
Let's first clarify one thin
On Wed, Jul 29, 2020 at 10:43:34AM +0200, Jon Nettleton wrote:
> On Wed, Jul 29, 2020 at 4:53 AM Jeremy Linton wrote:
> >
> > Hi,
> >
> > On 7/28/20 7:39 PM, Florian Fainelli wrote:
> > > On 7/28/2020 3:30 PM, Jeremy Linton wrote:
> > >> Hi,
> > >>
> > >> On 7/28/20 3:06 AM, Dan Callaghan wrote:
>
On Wed, Jul 29, 2020 at 4:53 AM Jeremy Linton wrote:
>
> Hi,
>
> On 7/28/20 7:39 PM, Florian Fainelli wrote:
> > On 7/28/2020 3:30 PM, Jeremy Linton wrote:
> >> Hi,
> >>
> >> On 7/28/20 3:06 AM, Dan Callaghan wrote:
> >>> Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00:
> No
On 7/28/2020 7:53 PM, Jeremy Linton wrote:
> Hi,
>
> On 7/28/20 7:39 PM, Florian Fainelli wrote:
>> On 7/28/2020 3:30 PM, Jeremy Linton wrote:
>>> Hi,
>>>
>>> On 7/28/20 3:06 AM, Dan Callaghan wrote:
Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00:
> Now i could be wr
Hi,
On 7/28/20 7:39 PM, Florian Fainelli wrote:
On 7/28/2020 3:30 PM, Jeremy Linton wrote:
Hi,
On 7/28/20 3:06 AM, Dan Callaghan wrote:
Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00:
Now i could be wrong, but are Ethernet switches something you expect
to see on ACPI/SBSA
On 7/28/2020 3:30 PM, Jeremy Linton wrote:
> Hi,
>
> On 7/28/20 3:06 AM, Dan Callaghan wrote:
>> Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00:
>>> Now i could be wrong, but are Ethernet switches something you expect
>>> to see on ACPI/SBSA platforms? Or is this a legitimate us
Hi,
On 7/28/20 3:06 AM, Dan Callaghan wrote:
Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00:
Now i could be wrong, but are Ethernet switches something you expect
to see on ACPI/SBSA platforms? Or is this a legitimate use of the
escape hatch?
As an extra data point: right no
On 7/28/2020 2:28 PM, Andy Shevchenko wrote:
> On Tue, Jul 28, 2020 at 11:56 PM Florian Fainelli
> wrote:
>> On 7/28/2020 1:45 PM, Andrew Lunn wrote:
>>> On Tue, Jul 28, 2020 at 06:06:26PM +1000, Dan Callaghan wrote:
Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00:
>
On Tue, Jul 28, 2020 at 11:56 PM Florian Fainelli wrote:
> On 7/28/2020 1:45 PM, Andrew Lunn wrote:
> > On Tue, Jul 28, 2020 at 06:06:26PM +1000, Dan Callaghan wrote:
> >> Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00:
> >>> Now i could be wrong, but are Ethernet switches somet
On Tue, Jul 28, 2020 at 11:59 PM Russell King - ARM Linux admin
wrote:
>
> On Tue, Jul 28, 2020 at 10:34:37PM +0200, Andrew Lunn wrote:
> > Hi Everybody
> >
> > So i think it is time to try to bring this discussion to some sort of
> > conclusion.
> >
> > No ACPI maintainer is willing to ACK any of
On Tue, Jul 28, 2020 at 10:34:37PM +0200, Andrew Lunn wrote:
> Hi Everybody
>
> So i think it is time to try to bring this discussion to some sort of
> conclusion.
>
> No ACPI maintainer is willing to ACK any of these patches. Nor are
> they willing to NACK them. ACPI maintainers simply don't wan
On 7/28/2020 1:45 PM, Andrew Lunn wrote:
> On Tue, Jul 28, 2020 at 06:06:26PM +1000, Dan Callaghan wrote:
>> Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00:
>>> Now i could be wrong, but are Ethernet switches something you expect
>>> to see on ACPI/SBSA platforms? Or is this a
On Tue, Jul 28, 2020 at 06:06:26PM +1000, Dan Callaghan wrote:
> Excerpts from Andrew Lunn's message of 2020-07-24 21:14:36 +02:00:
> > Now i could be wrong, but are Ethernet switches something you expect
> > to see on ACPI/SBSA platforms? Or is this a legitimate use of the
> > escape hatch?
>
> A
Hi Everybody
So i think it is time to try to bring this discussion to some sort of
conclusion.
No ACPI maintainer is willing to ACK any of these patches. Nor are
they willing to NACK them. ACPI maintainers simply don't want to get
involved in making use of ACPI in networking.
I personally don't
On Fri, Jul 24, 2020 at 9:14 PM Andrew Lunn wrote:
>
> > Hence my previous comment that we should consider this an escape
> > hatch rather than the last word in how to describe networking on
> > ACPI/SBSA platforms.
>
> One problem i have is that this patch set suggests ACPI can be used to
> descr
On Fri, Jul 24, 2020 at 09:14:36PM +0200, Andrew Lunn wrote:
> > Hence my previous comment that we should consider this an escape
> > hatch rather than the last word in how to describe networking on
> > ACPI/SBSA platforms.
>
> One problem i have is that this patch set suggests ACPI can be used to
On Fri, Jul 24, 2020 at 09:20:08PM +0200, Andrew Lunn wrote:
> > We are at v7 of this patch series, and no authoritative ACPI Linux
> > maintainer appears to have reviewed this, so there is no clear sign of
> > this converging anywhere. This is looking a lot like busy work for
> > nothing. Given th
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
An ACPI node property "mdio-handle" is introduced to reference the
MDIO bus on which PHYs are registered with autoprobing method used
by mdiobus_register().
Describe properties "phy-channel" and
On Sat, Jul 25, 2020 at 10:37 AM Calvin Johnson
wrote:
> On Fri, Jul 24, 2020 at 11:20:04PM +0300, Andy Shevchenko wrote:
> > On Fri, Jul 24, 2020 at 11:13 PM Florian Fainelli
> > wrote:
> > > On 7/24/20 1:12 PM, Andy Shevchenko wrote:
> > > > On Fri, Jul 24, 2020 at 10:20 PM Andrew Lunn wrote:
On Fri, Jul 24, 2020 at 11:20:04PM +0300, Andy Shevchenko wrote:
> On Fri, Jul 24, 2020 at 11:13 PM Florian Fainelli
> wrote:
> > On 7/24/20 1:12 PM, Andy Shevchenko wrote:
> > > On Fri, Jul 24, 2020 at 10:20 PM Andrew Lunn wrote:
> > >
> > >> I think we need to NACK all attempts to add ACPI sup
On Fri, Jul 24, 2020 at 11:12:15PM +0300, Andy Shevchenko wrote:
> On Fri, Jul 24, 2020 at 10:20 PM Andrew Lunn wrote:
>
> > I think we need to NACK all attempts to add ACPI support to phylib and
> > phylink until an authoritative ACPI Linux maintainer makes an
> > appearance and actively steers
On Fri, Jul 24, 2020 at 11:13 PM Florian Fainelli wrote:
> On 7/24/20 1:12 PM, Andy Shevchenko wrote:
> > On Fri, Jul 24, 2020 at 10:20 PM Andrew Lunn wrote:
> >
> >> I think we need to NACK all attempts to add ACPI support to phylib and
> >> phylink until an authoritative ACPI Linux maintainer m
On 7/24/20 1:12 PM, Andy Shevchenko wrote:
> On Fri, Jul 24, 2020 at 10:20 PM Andrew Lunn wrote:
>
>> I think we need to NACK all attempts to add ACPI support to phylib and
>> phylink until an authoritative ACPI Linux maintainer makes an
>> appearance and actively steers the work. And not just th
On Fri, Jul 24, 2020 at 10:20 PM Andrew Lunn wrote:
> I think we need to NACK all attempts to add ACPI support to phylib and
> phylink until an authoritative ACPI Linux maintainer makes an
> appearance and actively steers the work. And not just this patchset,
> but all patchsets in the networking
> We are at v7 of this patch series, and no authoritative ACPI Linux
> maintainer appears to have reviewed this, so there is no clear sign of
> this converging anywhere. This is looking a lot like busy work for
> nothing. Given that the representation appears to be wildly
> misunderstood and no one
> Hence my previous comment that we should consider this an escape
> hatch rather than the last word in how to describe networking on
> ACPI/SBSA platforms.
One problem i have is that this patch set suggests ACPI can be used to
describe complex network hardware. It is opening the door for others
t
On 7/24/20 10:26 AM, Jeremy Linton wrote:
> Hi,
>
> On 7/24/20 8:39 AM, Andrew Lunn wrote:
>>> Otherwise the MDIO bus and its phy should be a
>>> child of the nic/mac using it, with standardized behaviors/etc left
>>> up to
>>> the OSPM when it comes to MDIO bus enumeration/etc.
>>
>> Hi Jeremy
>>
Hi,
On 7/24/20 8:39 AM, Andrew Lunn wrote:
Otherwise the MDIO bus and its phy should be a
child of the nic/mac using it, with standardized behaviors/etc left up to
the OSPM when it comes to MDIO bus enumeration/etc.
Hi Jeremy
Could you be a bit more specific here please.
DT allows
> Otherwise the MDIO bus and its phy should be a
> child of the nic/mac using it, with standardized behaviors/etc left up to
> the OSPM when it comes to MDIO bus enumeration/etc.
Hi Jeremy
Could you be a bit more specific here please.
DT allows
macb0: ethernet@fffc4000 {
Hi,
On 7/15/20 4:03 AM, Calvin Johnson wrote:
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
An ACPI node property "mdio-handle" is introduced to reference the
MDIO bus on which PHYs are registered with autoprobing method used
by mdiobus_r
On Wed, Jul 15, 2020 at 08:04:36PM -0700, Florian Fainelli wrote:
>
>
> On 7/15/2020 2:03 AM, Calvin Johnson wrote:
> > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
> > provide them to be connected to MAC.
> >
> > An ACPI node property "mdio-handle" is introduced to referenc
On 7/15/2020 2:03 AM, Calvin Johnson wrote:
> Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
> provide them to be connected to MAC.
>
> An ACPI node property "mdio-handle" is introduced to reference the
> MDIO bus on which PHYs are registered with autoprobing method used
> by
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
An ACPI node property "mdio-handle" is introduced to reference the
MDIO bus on which PHYs are registered with autoprobing method used
by mdiobus_register().
Describe properties "phy-channel" and
50 matches
Mail list logo
