Hi,
On 9/24/20 10:12 AM, Jamie Iles wrote:
Hi Andrew,
On Thu, Sep 24, 2020 at 05:04:53PM +0200, Andrew Lunn wrote:
On Thu, Sep 24, 2020 at 03:56:45PM +0100, Jamie Iles wrote:
MDIO reads can happen during PHY probing, and printing an error with
dev_err can result in a large number of error mes
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
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
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
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
Hi,
On 6/17/20 12:34 PM, Andrew Lunn wrote:
On Wed, Jun 17, 2020 at 10:45:34PM +0530, Calvin Johnson wrote:
From: Jeremy Linton
+static const struct acpi_device_id xgmac_acpi_match[] = {
+ { "NXP0006", (kernel_ulong_t)NULL },
Hi Jeremy
What exactly does NXP0006 represent
Hi,
On 5/26/20 12:14 PM, Russell King - ARM Linux admin wrote:
On Tue, May 26, 2020 at 03:31:16PM +0100, Russell King wrote:
Add support for probing MMDs above 7 for a valid devices-in-package
specifier.
Signed-off-by: Russell King
---
drivers/net/phy/phy_device.c | 39 +
Hi,
On 5/26/20 9:31 AM, Russell King wrote:
Only set the devices_in_package to a non-zero value if we find a valid
value for this field, so we avoid leaving it set to e.g. 0x1fff.
Signed-off-by: Russell King
---
drivers/net/phy/phy_device.c | 17 ++---
1 file changed, 10 ins
Hi,
On 5/26/20 9:31 AM, Russell King wrote:
We have two competing requirements for the devices_in_package field.
We want to use it as a bit array indicating which MMDs are present, but
we also want to know if the Clause 22 registers are present.
Since "devices in package" is a term used in the
Hi,
On 5/26/20 9:31 AM, Russell King wrote:
Rearrange the code to read the PHY IDs, so we don't call get_phy_id()
only to immediately call get_phy_c45_ids(). Move that logic into
get_phy_device(), which results in better readability.
Signed-off-by: Russell King
---
drivers/net/phy/phy_devic
Hi,
On 5/26/20 9:31 AM, Russell King wrote:
Expand the device_ids[] array to allow all MMD IDs to be read rather
than just the first 8 MMDs, but only read the ID if the MDIO_STAT2
register reports that a device really is present here for these new
devices to maintain compatibility with our curre
Hi,
On 5/25/20 6:12 PM, Andrew Lunn wrote:
arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible = "ethernet-phy-id13e5.1002";
arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible = "ethernet-phy-id13e5.1002";
arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible = "ethernet-phy-id13e5.1002";
arch/powe
Hi,
On 5/25/20 6:33 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 06:22:19PM -0500, Jeremy Linton wrote:
On 5/25/20 6:09 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 05:22:07PM -0500, Jeremy Linton wrote:
On 5/25/20 5:01 PM, Russell King - ARM Linux
On 5/25/20 6:09 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 05:22:07PM -0500, Jeremy Linton wrote:
On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux
Hi,
On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
Hi,
On 5/23/20 1:37 PM, Russell King
On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
Hi,
On 5/23/20 1:37 PM, Russell King - ARM
Hi,
On 5/25/20 5:06 PM, Andrew Lunn wrote:
Yes, we know even for the NXP reference hardware, one of the phy's doesn't
probe out correctly because it doesn't respond to the ieee defined
registers. I think at this point, there really isn't anything we can do
about that unless we involve the (ACPI)
Hi,
On 5/25/20 3:25 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 11:28:52PM -0500, Jeremy Linton wrote:
Hi,
On 5/24/20 9:44 AM, Andrew Lunn wrote:
+++ b/include/linux/phy.h
@@ -275,6 +275,11 @@ struct mii_bus {
int reset_delay_us;
/* RESET GPIO descriptor
Hi,
On 5/25/20 4:07 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:02:13PM -0500, Jeremy Linton wrote:
So, I think you're going to have to add a work-around to ignore bit 0,
which brings up the question whether this is worth it or not.
It does ignore bit 0, it
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
Hi,
On 5/23/20 1:37 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:52PM -0500, Jeremy Linton wrote:
Until this point, we have been sanitizing
Hi,
On 5/25/20 4:45 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 09:46:55PM -0500, Jeremy Linton wrote:
Hi,
Thanks for taking a look at this.
On 5/23/20 1:20 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:49PM -0500, Jeremy Linton wrote:
C45
Hi,
On 5/24/20 9:44 AM, Andrew Lunn wrote:
+++ b/include/linux/phy.h
@@ -275,6 +275,11 @@ struct mii_bus {
int reset_delay_us;
/* RESET GPIO descriptor pointer */
struct gpio_desc *reset_gpiod;
+ /* bus capabilities, used for probing */
+ enum {
+
Hi,
On 5/23/20 1:44 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:55PM -0500, Jeremy Linton wrote:
MMD's in the device list sometimes return 0 for their id.
When that happens lets reset the id back to 0xfff so
that we don't get a stub device created for
Hi,
On 5/23/20 1:37 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:52PM -0500, Jeremy Linton wrote:
Until this point, we have been sanitizing the c22
regs presence bit out of all the MMD device lists.
This is incorrect as it causes the 0x checks
to incorrectly
Hi,
On 5/23/20 1:36 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:50PM -0500, Jeremy Linton wrote:
Since we are already checking for *devs == 0 after
the loop terminates, we can add a mostly F's check
as well. With that change we can simplify the return/break
seq
Hi,
Thanks for taking a look at this.
On 5/23/20 1:20 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:49PM -0500, Jeremy Linton wrote:
C45 devices are to return 0 for registers they haven't
implemented. This means in theory we can terminate the
device search
Hi,
On 5/23/20 3:01 PM, Russell King - ARM Linux admin wrote:
On Sat, May 23, 2020 at 09:51:31PM +0200, Andrew Lunn wrote:
static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
struct phy_c45_device_ids *c45_ids) {
- int phy_reg;
- int i
Hi,
On 5/23/20 10:28 AM, Andrew Lunn wrote:
On Fri, May 22, 2020 at 04:30:51PM -0500, Jeremy Linton wrote:
Lets factor out the phy id logic, and make it generic
so that it can be used for c22 and c45.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 65
Hi,
Thanks for taking a look at this!
On 5/23/20 10:28 AM, Andrew Lunn wrote:
On Fri, May 22, 2020 at 04:30:51PM -0500, Jeremy Linton wrote:
Lets factor out the phy id logic, and make it generic
so that it can be used for c22 and c45.
Signed-off-by: Jeremy Linton
---
drivers/net/phy
ff-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 245899b58a7d..7746c07b97fe 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_dev
r the ACPI case, we don't really have a good way to match
them, and since it hasn't been working I think its perfectly
reasonable at this point to expect phy's to implement enough
of the standard that we can detect them and attach a phy
specific driver.
Signed-off-by: Jeremy Linto
Lets factor out the phy id logic, and make it generic
so that it can be used for c22 and c45.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 65 +++-
1 file changed, 35 insertions(+), 30 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b
state at the bottom.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index ac2784192472..245899b58a7d 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/ne
Default initializing the phy_id to "invalid" allows
us to avoid setting it on the error returns.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drive
location and we should
be accessing it using c22.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index f0761fa5e40b..2d677490ecab 100644
--- a
for fully compliant MDIO/PHY
combinations or are we ok with extra stub devices? The 3rd to last
set is just using the C45_FIRST flag for it.
What have I missed?
Jeremy Linton (11):
net: phy: Don't report success if devices weren't found
net: phy: Simplify MMD device list termi
rning
0x) we are just going to ignore anything
that doesn't look like a valid return.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 8 +++-
include/linux/phy.h | 2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/phy_device.c
e use.
At the moment its a yes/no option, but in the future
it may be useful to extend this to c45 only policy, or
add additional classes and policies.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/mdio_bus.c | 9 +++--
include/linux/phy.h| 5 +
2 files changed, 12 insert
Since we know the xgmac hardware always has a c45
complaint bus, lets try scanning for c45 capable
phys first. If we fail to find any, then it with
fall back to c22 automatically.
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/freescale/xgmac_mdio.c | 1 +
1 file changed, 1 insertion
we just ignore it and accept that the probe logic as it
stands potentially creates bogus phy devices, to avoid the
case where an actual phy exists but isn't responding correctly.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 8 +++-
1 file changed, 7 insertions(+), 1 del
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/freescale/xgmac_mdio.c | 27 +
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/freescale/xgmac_mdio.c
b/drivers/net/ethernet/freescale/xgmac_mdio.c
index c82c85ef5fb3..96ee3bd89983
Hi,
On 5/14/20 12:00 PM, Jeremy Linton wrote:
The commit "disregard Clause 22 registers present bit..." clears
the low bit of the devices_in_package data which is being used
in get_phy_c45_ids() to determine if a phy/register is responding
correctly. That check is against 0x1FFF,
Hi,
On 5/14/20 2:59 PM, Heiner Kallweit wrote:
On 14.05.2020 19:00, Jeremy Linton wrote:
The commit "disregard Clause 22 registers present bit..." clears
the low bit of the devices_in_package data which is being used
in get_phy_c45_ids() to determine if a phy/register is responding
("net: phy: disregard "Clause 22 registers present" bit in
get_phy_c45_devs_in_pkg")
Cc: Heiner Kallweit
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/driv
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
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 device.
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&ID_" definition, it may not
be ideal to parse it. Instead the normal ACPI model of exactly matching the
complete string in the phy
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",
+&upper, &lower) == 2) {
+
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
ev is deregistered.
Reported-by: Matt Sealey
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/smsc/smsc911x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index 012fb66eed8d..f0afb88d7bc2 1
ter_netdev() calling close()
To fix this, we delay the mdiobus teardown until after
the netdev is deregistered.
Reported-by: Matt Sealey
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/smsc/smsc911x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/eth
Hi,
First, thanks for taking a look at this.
On 01/23/2018 01:53 AM, Antoine Tenart wrote:
Hi Jeremy,
On Mon, Jan 22, 2018 at 05:14:27PM -0600, Jeremy Linton wrote:
I'm running 4.15rc7 and hitting the following crash on the MACCHIATObin.
This is 100% reproducible once the adapter is
this in anyway.
Tested-by: Jeremy Linton
Reported-by: Jeremy Linton
Signed-off-by: Tom Lendacky
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
b/drivers/net/ethernet/amd/xgbe/x
Hi,
On 03/09/2017 03:39 PM, Tom Lendacky wrote:
On 3/9/2017 3:26 PM, Jeremy Linton wrote:
Hi,
Hi Jeremy,
I'll have a look at it. Can you send me your kernel config just in
case?
Sure, i will send it to you off list to avoid spamming everyone with a
43k gziped file.
Thanks,
T
Hi,
I have a softiron 3k and under network load (nfs copies, vnc with gnome,
etc) it is now throwing these messages as fast as the console will
accept them. This is booted DT mode.
[ 430.111324] Unbalanced enable for IRQ 33
[ 430.115239] [ cut here ]
[ 430.119849]
://lkml.org/lkml/2016/4/12/410
An alternative fix is to assure that IFF_UP gets cleared by
calling dev_close() during shutdown. This is similar to what the
bnx2/tg3/xgene and maybe others are doing to assure that the driver
isn't being called following _shutdown().
Signed-off-by: Jeremy L
Hi,
On 10/27/2016 06:23 AM, Ulf Hansson wrote:
The smsc911c driver puts its device into low power state when entering
system suspend. Although it doesn't update the device's runtime PM status
to RPM_SUSPENDED, which causes problems for a parent device.
In particular, when the runtime PM status
On 10/10/2016 12:41 PM, Kyle Roeschley wrote:
Because the SMSC PHY completes auto-negotiation before the driver is
ready to handle interrupts, the PHY state machine never realizes that we
have a link. Clear the ANENABLE bit on initialization, which lets
genphy_config_aneg do its thing when that c
Hi Robert,
On 10/03/2016 04:05 AM, Robert Jarzmik wrote:
Add a workaround for mainstone, idp and stargate2 boards, for u16 writes
which must be aligned on 32 bits addresses.
Signed-off-by: Robert Jarzmik
---
Documentation/devicetree/bindings/net/smsc911x.txt | 2 ++
1 file changed, 2 insertio
riven high, taking
the device out of reset.
Cc: Jeremy Linton
Signed-off-by: Linus Walleij
Thanks for clarifying the GPIO_ACTIVE_LOW state on this pin. I've
reviewed this patch, and tested that it doesn't have any affect on a
JunoR2 (ACPI or DT) system. I've got some personal r
The /proc/irq/xx information is incorrect for smsc911x because
the request_irq is happening before the register_netdev has the
proper device name. Moving it to the open also fixes the case
of when the device is renamed.
Reported-by: Will Deacon
Signed-off-by: Jeremy Linton
---
drivers/net
Rework the error handling in smsc911x open in preparation
for the mdio startup being moved here.
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/smsc/smsc911x.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b
stale state.
Errors caused by the net device being opened before the mdio/phy was
configured. There is also a potential power savings as the phy's don't
remain powered when the interface isn't running.
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/smsc/
interrupt
configuration into the smsc911x_open routine.
Jeremy Linton (4):
net: smsc911x: Remove multiple exit points from smsc911x_open
net: smsc911x: Fix register_netdev, phy startup, driver unload
ordering
net: smsc911x: Move interrupt handler before open
net: smsc911x: Move interrupt all
In preparation for the allocating/enabling interrupts
in the ndo_open routine move the irq handler before it.
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/smsc/smsc911x.c | 122 +--
1 file changed, 61 insertions(+), 61 deletions(-)
diff --git a/drivers
On 09/01/2016 11:58 AM, Andrew Lunn wrote:
@@ -1520,17 +1513,22 @@ static int smsc911x_open(struct net_device *dev)
unsigned int timeout;
unsigned int temp;
unsigned int intcfg;
+ int retval;
- /* if the phy is not yet registered, retry later*/
+ /* find
Hi Andrew,
Thanks for taking a look at this!
On 09/01/2016 12:06 PM, Andrew Lunn wrote:
Hi Jeremy
Please don't add forward references. Move the function earlier in the
file.
Ok, but I thought it was a fairly large move due to further dependent
functions..
static inline u32 __s
Hi,
On 09/01/2016 02:45 PM, Andrew Lunn wrote:
On Thu, Sep 01, 2016 at 01:47:44PM -0500, Jeremy Linton wrote:
Hi Andrew,
Thanks for taking a look at this!
On 09/01/2016 12:06 PM, Andrew Lunn wrote:
Hi Jeremy
Please don't add forward references. Move the function earlier in the
stale state.
Errors caused by the net device being opened before the mdio/phy was
configured. There is also a potential power savings as the phy's don't
remain powered when the interface isn't running.
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/smsc/
ng network configuration problems, and
the /proc/irq nodes are incorrectly named.
Clean up a number of these problems by moving the mdio and interrupt
configuration into the smsc911x_open routine.
Jeremy Linton (2):
net: smsc911x: Fix register_netdev, phy startup, driver unload
ordering
net/smsc
The /proc/irq/xx information is incorrect for smsc911x because
the request_irq is happening before the register_netdev has the
proper device name. Moving it to the open also fixes the case
of when the device is renamed.
Reported-by: Will Deacon
Signed-off-by: Jeremy Linton
---
drivers/net
Hi,
On 08/24/2016 07:59 AM, Linus Walleij wrote:
The SMSC911x have a line out of the chip called "PME",
Power Management Event. When connected to an asynchronous
interrupt controller this is able to wake the system up
from sleep in response to certain network events.
This is the first attempt t
Hi Linus,
On 08/24/2016 07:59 AM, Linus Walleij wrote:
The SMSC911x have a line out of the chip called "PME",
Power Management Event. When connected to an asynchronous
interrupt controller this is able to wake the system up
from sleep in response to certain network events.
This is the first at
Hi Linus,
On 08/24/2016 07:59 AM, Linus Walleij wrote:
On some systems (such as the Qualcomm APQ8060 Dragonboard) the
RESET signal of the SMSC911x is not pulled up by a resistor but
connected to a GPIO line, so that the operating system must
explicitly deassert RESET before use.
Support this in
Enable lan91x adapters in some ARM machines and models
when booted with an ACPI kernel.
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/smsc/smc91x.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smc91x.c
b/drivers/net
On 07/05/2016 01:45 PM, Sergei Shtylyov wrote:
The patch has been merged to 4.7-rc6, why resend it?
Sorry, I must have missed the merge.
Thanks,
emcpy and the now unused phy_irq member to
force the SMSC911x PHYs into polling mode 100% of the time.
Fixes: e7f4dc3536a4 ("mdio: Move allocation of interrupts into core")
Signed-off-by: Jeremy Linton
Reviewed-by: Andrew Lunn
Acked-by: Sergei Shtylyov
---
drivers/net/ethernet/smsc
Enable lan91x adapters in some ARM machines and models
when booted with an ACPI kernel.
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/smsc/smc91x.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smc91x.c
b/drivers/net/ethernet
emcpy and the now unused phy_irq member to
force the SMSC911x PHYs into polling mode 100% of the time.
Fixes: e7f4dc3536a4 ("mdio: Move allocation of interrupts into core")
Signed-off-by: Jeremy Linton
Reviewed-by: Andrew Lunn
Acked-by: Sergei Shtylyov
---
drivers/net/ethernet/smsc
of ethtool changes a little if the interface is stopped. Before the
phy's would remain up, and their last state would be displayed with
ethtool. Now ethtool reports link has been severed/Link detected: no
when the net dev is stopped.
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/smsc/
ation on the mdio
bus. Remove that memcpy and the now unused phy_irq member to force
SMSC911x PHY's into polling mode 100% of the time.
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/smsc/smsc911x.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/smsc/sms
On 06/14/2016 04:56 PM, Sergei Shtylyov wrote:
On 06/15/2016 12:53 AM, Jeremy Linton wrote:
If the interrupt configuration isn't set and we are using the
It's never set, judging by the driver code.
internal phy, then we need to poll the phy to reliably detect
phy sta
On 06/14/2016 05:26 PM, Andrew Lunn wrote:
This was DT as well with a recent fedora/NetworkManager. It
actually seems to be timing related to how fast the device gets
configured after the initial phy probe. There is something like a 1
second window or so where it will work, but if network
On 06/14/2016 04:42 PM, Sergei Shtylyov wrote:
On 06/15/2016 12:40 AM, Jeremy Linton wrote:
If the interrupt configuration isn't set and we are using the
It's never set, judging by the driver code.
internal phy, then we need to poll the phy to reliably detect
phy sta
On 06/14/2016 04:34 PM, Sergei Shtylyov wrote:
On 06/15/2016 12:29 AM, Jeremy Linton wrote:
If the interrupt configuration isn't set and we are using the
It's never set, judging by the driver code.
internal phy, then we need to poll the phy to reliably detect
phy sta
On 06/14/2016 03:44 PM, Sergei Shtylyov wrote:
On 06/14/2016 07:16 PM, Jeremy Linton wrote:
If the interrupt configuration isn't set and we are using the
It's never set, judging by the driver code.
internal phy, then we need to poll the phy to reliably detect
phy sta
On 06/14/2016 03:44 PM, Sergei Shtylyov wrote:
On 06/14/2016 07:16 PM, Jeremy Linton wrote:
If the interrupt configuration isn't set and we are using the
It's never set, judging by the driver code.
AFAIK, I think that its set when the device is configured as a platform
On 06/14/2016 03:44 PM, Sergei Shtylyov wrote:
On 06/14/2016 07:16 PM, Jeremy Linton wrote:
If the interrupt configuration isn't set and we are using the
It's never set, judging by the driver code.
internal phy, then we need to poll the phy to reliably detect
phy sta
On 06/14/2016 03:44 PM, Sergei Shtylyov wrote:
On 06/14/2016 07:16 PM, Jeremy Linton wrote:
If the interrupt configuration isn't set and we are using the
It's never set, judging by the driver code.
internal phy, then we need to poll the phy to reliably detect
phy sta
On 06/14/2016 01:42 PM, Andrew Lunn wrote:
On Tue, Jun 14, 2016 at 11:16:02AM -0500, Jeremy Linton wrote:
If the interrupt configuration isn't set and we are using the
internal phy, then we need to poll the phy to reliably detect
phy state changes.
Hi Jeremy
Why does the external ph
On 06/14/2016 02:49 PM, Sergei Shtylyov wrote:
On 06/14/2016 10:27 PM, Sergei Shtylyov wrote:
If the interrupt configuration isn't set and we are using the
internal phy, then we need to poll the phy to reliably detect
phy state changes.
Signed-off-by: Jeremy Linton
---
drivers/net/eth
If the interrupt configuration isn't set and we are using the
internal phy, then we need to poll the phy to reliably detect
phy state changes.
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/smsc/smsc911x.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet
On 09/09/2015 11:10 AM, Marc Zyngier wrote:
Jeremy,
I can see two issues here: we have a screaming interrupt, and
we seem to corrupt some workqueue.
How did you get this to work? Firmware release?
Marc,
I'm responding because its been a month or so since my last response,
and I haven't forg
Marc,
|FWIW, mainline booting with this patch on Juno r1 with ACPI enabled dies a
|horrible death:
Sorry about the delay, I didn't see this message.
|How did you get this to work? Firmware release?
Yes, it's a firmware problem with the ACPI tables. It is likely you need _DSD
changes for the
is not found, the next property will
be read using a NULL buffer.
Thanks for catching that! I checked the OF version to see if it has the
same problem, but of course it doesn't because I added the logic to pass
the buffer into the routine.
Reviewed-by: Jeremy Linton
--
To unsubscribe
this.
Tested-by: Jeremy Linton
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the reg-io-width ahead of the
device_get_phy_mode() and removed the phy checks, but I don't imagine
there is much functional difference at this point.
Tested-by: Jeremy Linton
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...
On 08/26/2015 12:04 PM, Tony Lindgren wrote:
* Guenter Roeck [150817 13:48]:
Commit 0b50dc4fc971 ("Convert smsc911x to use ACPI as well as DT") makes
Looks like this change makes at least omap boards using smsc911x
fail with -22 for me in Linux next.
Do any of the the device tree configured s
Convert the xgene_get_mac_address to device_get_mac_address(), and
xgene_get_phy_mode() to device_get_phy_mode().
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 38 ++--
1 file changed, 2 insertions(+), 36 deletions(-)
diff --git a
This patch converts the xgene driver to use some common ACPI/DT agnostic
functions for retrieving MAC and PHY settings. I don't have a way to test
them at the moment, so if someone can verify they work that would be great.
BTW: These patches are against net-next.
Thanks,
Jeremy Lint
1 - 100 of 110 matches
Mail list logo
