On Mon, Jun 10, 2019 at 03:40:10PM +0200, Heiner Kallweit wrote:
> On 06.06.2019 20:36, Andrew Lunn wrote:
> > 65;5402;1c> I don't like too much state changes outside control of the
> > state machine,
> >> like in phy_start / phy_stop / phy_error. I think it would be better
> >> if a state change
On 06.06.2019 20:36, Andrew Lunn wrote:
> 65;5402;1c> I don't like too much state changes outside control of the state
> machine,
>> like in phy_start / phy_stop / phy_error. I think it would be better
>> if a state change request is sent to the state machine, and the state
>> machine decides whet
On Thu, Jun 06, 2019 at 08:36:11PM +0200, Andrew Lunn wrote:
> 65;5402;1c> I don't like too much state changes outside control of the state
> machine,
> > like in phy_start / phy_stop / phy_error. I think it would be better
> > if a state change request is sent to the state machine, and the state
On Thu, Jun 06, 2019 at 08:24:23PM +0200, Heiner Kallweit wrote:
> On 06.06.2019 14:42, Andrew Lunn wrote:
> > On Thu, Jun 06, 2019 at 08:59:19AM +0100, Russell King - ARM Linux admin
> > wrote:
> >> On Wed, Jun 05, 2019 at 06:48:27PM -0700, David Miller wrote:
> >>> From: Russell King
> >>> Date
65;5402;1c> I don't like too much state changes outside control of the state
machine,
> like in phy_start / phy_stop / phy_error. I think it would be better
> if a state change request is sent to the state machine, and the state
> machine decides whether the requested transition is allowed.
Hi He
On 06.06.2019 14:42, Andrew Lunn wrote:
> On Thu, Jun 06, 2019 at 08:59:19AM +0100, Russell King - ARM Linux admin
> wrote:
>> On Wed, Jun 05, 2019 at 06:48:27PM -0700, David Miller wrote:
>>> From: Russell King
>>> Date: Wed, 05 Jun 2019 11:43:16 +0100
>>>
+ (state == PHY_UP || state =
On Thu, Jun 06, 2019 at 08:59:19AM +0100, Russell King - ARM Linux admin wrote:
> On Wed, Jun 05, 2019 at 06:48:27PM -0700, David Miller wrote:
> > From: Russell King
> > Date: Wed, 05 Jun 2019 11:43:16 +0100
> >
> > > + (state == PHY_UP || state == PHY_RESUMING)) {
> >
> > drivers/net/phy/m
> This link notifier change also screws up my long-standing patches
> to add support for SFP for the PHYs on Macchiatobin which I was
> going to post next.
Hi Russell
Is that with the SFP hanging off the Marvell 10G PHY? We are seeing
that sort of chain more often, so it is something i would like
On Wed, Jun 05, 2019 at 06:48:27PM -0700, David Miller wrote:
> From: Russell King
> Date: Wed, 05 Jun 2019 11:43:16 +0100
>
> > + (state == PHY_UP || state == PHY_RESUMING)) {
>
> drivers/net/phy/marvell10g.c: In function ‘mv3310_link_change_notify’:
> drivers/net/phy/marvell10g.c:268:35:
From: Russell King
Date: Wed, 05 Jun 2019 11:43:16 +0100
> + (state == PHY_UP || state == PHY_RESUMING)) {
drivers/net/phy/marvell10g.c: In function ‘mv3310_link_change_notify’:
drivers/net/phy/marvell10g.c:268:35: error: ‘PHY_RESUMING’ undeclared (first
use in this function); did you m
On Wed, Jun 05, 2019 at 11:43:16AM +0100, Russell King wrote:
> Allow the PHY to probe when there is no firmware, but do not allow the
> link to come up by forcing the PHY state to PHY_HALTED in a similar way
> to phy_error().
>
> Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Andrew
Allow the PHY to probe when there is no firmware, but do not allow the
link to come up by forcing the PHY state to PHY_HALTED in a similar way
to phy_error().
Signed-off-by: Russell King
---
Depends on "net: phy: marvell10g: report if the PHY fails to boot firmware"
drivers/net/phy/marvell10g.c
12 matches
Mail list logo
