On 08/10/2020 15:47, Calvin Johnson wrote:
Better place for of_mdio.c is drivers/net/mdio.
Move of_mdio.c from drivers/of to drivers/net/mdio
Signed-off-by: Calvin Johnson
In-Principle-Acked-By: Grant Likely
... but I've not tested or compiled *anything*!
g.
---
MAINTA
On 30/09/2020 17:04, Calvin Johnson wrote:
Modify dpaa2_mac_connect() to support ACPI along with DT.
Modify dpaa2_mac_get_node() to get the dpmac fwnode from either
DT or ACPI.
Replace of_get_phy_mode with fwnode_get_phy_mode to get
phy-mode for a dpmac_node.
Use helper function phylink_fwno
On 30/09/2020 17:37, Rafael J. Wysocki wrote:
On Wed, Sep 30, 2020 at 6:05 PM Calvin Johnson
wrote:
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson
---
On 30/09/2020 17:04, 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
---
drivers/net/phy/phy_device.c | 32 +++-
include/linux/
On 01/10/2020 05:00, Calvin Johnson wrote:
On Wed, Sep 30, 2020 at 08:19:02PM +0200, Andrew Lunn wrote:
On Wed, Sep 30, 2020 at 07:07:25PM +0100, Russell King - ARM Linux admin wrote:
On Wed, Sep 30, 2020 at 06:34:40PM +0200, Andrew Lunn wrote:
@@ -2866,7 +2888,15 @@ EXPORT_SYMBOL_GPL(devic
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 15/07/2020 10:03, Calvin Johnson wrote:
This patch series provides ACPI support for dpaa2 MAC driver.
This also introduces ACPI mechanism to get PHYs registered on a
MDIO bus and provide them to be connected to MAC.
Patch "net: dpaa2-mac: Add ACPI support for DPAA2 MAC driver" depends
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.
: Jon Smirl <[EMAIL PROTECTED]>
Acked-by: Domen Puncer <[EMAIL PROTECTED]>
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
Jeff, this one hasn't been picked up for 2.6.24 yet and in needs to go in.
Thanks,
g.
drivers/net/fec_mpc52xx.c |4 ++--
1 files changed, 2 i
From: Grant Likely <[EMAIL PROTECTED]>
This patch eliminates the warning of unused return values when the driver
registers it sysfs files. Now the driver will print an error if it is
unable to register the sysfs files.
It also eliminates the macros used to wrap the DEVICE_ATTR macro a
From: Grant Likely <[EMAIL PROTECTED]>
Eliminate an uninitialized variable warning. The code is correct, but
a pointer to the automatic variable 'addr' is passed to dma_alloc_coherent.
Since addr has never been initialized, and the compiler doesn't know
what dma_alloc_coh
ting memory. This patch fixes two bugs
> > where the wrong skb buffer was being referenced.
> >
> > Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
>
> Acked-by: Domen Puncer <[EMAIL PROTECTED]>
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Jeff, can you plea
On 11/1/07, Ingo Oeser <[EMAIL PROTECTED]> wrote:
> Hi Grant,
>
> Grant Likely schrieb:
> > From: Grant Likely <[EMAIL PROTECTED]>
> >
> > Driver shouldn't complain if the register range is larger than what
> > it expects. This works around fail
From: Grant Likely <[EMAIL PROTECTED]>
Driver shouldn't complain if the register range is larger than what
it expects. This works around failures with some device trees.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/net/fec_mpc52xx.c |4 ++--
1 files chan
From: Grant Likely <[EMAIL PROTECTED]>
When not building an arch/powerpc kernel, the mpc5200 FEC driver depends
on some symbols which are not defined (BESTCOMM & BESTCOMM_FEC).
This patch flips around the dependancy logic so that it cannot be
selected unless BESTCOMM_FEC is sele
Oops, send this series yesterday but forgot to include jgarzik, domen
and netdev to the 'to:' list.
These are fixes which should go in for .24
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
-
To unsubscribe from this list: send the line "unsubscribe netdev&
; drivers/net/fec_mpc52xx.h | 313 +++
> > drivers/net/fec_mpc52xx_phy.c | 198 +++
> > 5 files changed, 1651 insertions(+)
>
> applied to #upstream-fixes
>
> it's not strictly a fix, but I did not want to hold this back until
> 2.6.25 either
Fa
re now in
Linus' tree. That clears the way for the FEC driver when Domen
reposts it. (In other words; there is nothing left in arch land
blocking this driver)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
-
To unsubscribe from t
From: Grant Likely <[EMAIL PROTECTED]>
Eliminate an uninitialized variable warning. The code is correct, but
a pointer to the automatic variable 'addr' is passed to dma_alloc_coherent.
Since addr has never been initialized, and the compiler doesn't know
what dma_alloc_coh
From: Grant Likely <[EMAIL PROTECTED]>
Fixes compile error from commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0.
Also eliminates an unused variable and eliminates an uninitialized variable
warning.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/net/gianfar.c |6 ++-
- device tree
> > 2 - small bestcomm change
> > 3 - the actual driver
> > 4 - phy part of the driver
>
> patches #3 and #4 need to be combined together.
>
> Are the arch people OK with patches #1 and #2?
Yes, I'll be pushing both to Paulus shortly.
Cheers,
g.
--
On 10/15/07, Domen Puncer <[EMAIL PROTECTED]> wrote:
> On 14/10/07 16:05 -0600, Grant Likely wrote:
> > On 10/14/07, Domen Puncer <[EMAIL PROTECTED]> wrote:
> > > PHY part of the driver for mpc5200(b) ethernet.
> >
> > Assuming I understand correctly, this
er with
> + an external MII PHY chip or 10 Mbps 7-wire interface
> + (Motorola? industry standard).
> + If your board uses an external PHY, enable this.
Not strictly true. This enables talking to a PHY using the internal
MDIO controller. PHY register access could j
ot;PPC_MPC52xx"
> + select PPC_BESTCOMM
> + select PPC_BESTCOMM_FEC
> + select CRC32
> + select PHYLIB
> + ---help---
> + This option enables support for the MPC5200's on-chip
> + Fast Ethernet Controller
> +
> +endm
On 9/3/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 9/3/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On 9/2/07, Domen Puncer <[EMAIL PROTECTED]> wrote:
> > > Hi!
> > >
> > > new in this version:
> > > - fixed stuff that was c
unsigned char *mac)
> +{
> + int i;
> + u64 val64;
> +
> + val64 = simple_strtoull(str, NULL, 16);
> +
> + for (i = 0; i < 6; i++)
> + mac[5-i] = val64 >> (i*8);
> +}
> +
> +static int __init mpc52xx_fec_mac_setup(char *mac_address)
> +{
> + fec_str2mac(mac_address, mpc52xx_fec_mac_addr);
> + return 0;
> +}
fec_str2mac is called in *1* place. I'd roll it into mpc52xx_fec_mac_setup.
> +
> +__setup("mpc52xx-mac=", mpc52xx_fec_mac_setup);
> +
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
28 matches
Mail list logo
