Thu, Mar 28, 2019 at 08:51:34PM CET, and...@lunn.ch wrote:
>On Thu, Mar 28, 2019 at 05:59:50PM +, Petr Machata wrote:
>
>Hi Petr
>
>> - PHY driver: dev->phydev->drv->get_link_down_reason
>> Certain PHY drivers might want to have a custom handling for some
>> PHY-specific insight. Something
On Thu, Mar 28, 2019 at 05:59:50PM +, Petr Machata wrote:
Hi Petr
> - PHY driver: dev->phydev->drv->get_link_down_reason
> Certain PHY drivers might want to have a custom handling for some
> PHY-specific insight. Something like:
>
> modified include/linux/phy.h
> @@ -636,4 +636
Andrew Lunn writes:
> I argued this is a PHY layer status information. We don't really want
> to have to modify every MAC driver to call into phylib/phylink. Yes,
> we can have a netdev_ops for those drivers which ignore the Linux PHY
> layer, but ideally we want to transparently call into the
Stephen Hemminger writes:
> On Tue, 19 Mar 2019 10:18:00 +
> Petr Machata wrote:
>
>> Stephen Hemminger writes:
>>
>> > On Mon, 18 Mar 2019 15:02:53 +0100
>> > Andrew Lunn wrote:
>> >
>> >> On Mon, Mar 18, 2019 at 01:15:41PM +, Petr Machata wrote:
>> >> >
>> >> > Andrew Lunn wr
On Tue, 19 Mar 2019 10:18:00 +
Petr Machata wrote:
> Stephen Hemminger writes:
>
> > On Mon, 18 Mar 2019 15:02:53 +0100
> > Andrew Lunn wrote:
> >
> >> On Mon, Mar 18, 2019 at 01:15:41PM +, Petr Machata wrote:
> >> >
> >> > Andrew Lunn writes:
> >> >
> >> > >> +enum rtnl_link_do
On Tue, Mar 19, 2019 at 10:18:00AM +, Petr Machata wrote:
> Stephen Hemminger writes:
> > Gut feel is that enumerated values are going to grow and grow and be
> > long term API headache.
> >
> > Would it be possible to use a string like the external ack error
> > message?
>
> It would, but th
Stephen Hemminger writes:
> On Mon, 18 Mar 2019 15:02:53 +0100
> Andrew Lunn wrote:
>
>> On Mon, Mar 18, 2019 at 01:15:41PM +, Petr Machata wrote:
>> >
>> > Andrew Lunn writes:
>> >
>> > >> +enum rtnl_link_down_reason_major {
>> > >> + RTNL_LDR_OTHER,
>> > >
>> > > Does 'other' make
On Mon, 18 Mar 2019 15:02:53 +0100
Andrew Lunn wrote:
> On Mon, Mar 18, 2019 at 01:15:41PM +, Petr Machata wrote:
> >
> > Andrew Lunn writes:
> >
> > >> +enum rtnl_link_down_reason_major {
> > >> +RTNL_LDR_OTHER,
> > >
> > > Does 'other' make any sense? Seem better to just not
On Mon, Mar 18, 2019 at 01:15:41PM +, Petr Machata wrote:
>
> Andrew Lunn writes:
>
> >> +enum rtnl_link_down_reason_major {
> >> + RTNL_LDR_OTHER,
> >
> > Does 'other' make any sense? Seem better to just not report anything
> > at all, or add a comment that more reasons should be added at
Andrew Lunn writes:
> On Mon, Mar 18, 2019 at 01:15:41PM +, Petr Machata wrote:
>>
>> Andrew Lunn writes:
>>
>> >> +enum rtnl_link_down_reason_major {
>> >> + RTNL_LDR_OTHER,
>> >
>> > Does 'other' make any sense? Seem better to just not report anything
>> > at all, or add a comment that
On Mon, Mar 18, 2019 at 01:15:41PM +, Petr Machata wrote:
>
> Andrew Lunn writes:
>
> >> +enum rtnl_link_down_reason_major {
> >> + RTNL_LDR_OTHER,
> >
> > Does 'other' make any sense? Seem better to just not report anything
> > at all, or add a comment that more reasons should be added at
Andrew Lunn writes:
>> +enum rtnl_link_down_reason_major {
>> +RTNL_LDR_OTHER,
>
> Does 'other' make any sense? Seem better to just not report anything
> at all, or add a comment that more reasons should be added at the end
> to reflect whatever the hardware or software can determine.
You
> This copies how other fill APIs are done, in that the responsibility for
> filling up the message is deferred to the driver. I think it makes the
> API easier to extend: if there ever is richer information available, the
> drivers that want to support it just opt in and provide those attributes.
On Mon, Mar 18, 2019 at 12:34:55PM +, Petr Machata wrote:
> Jakub Kicinski writes:
> > Also perhaps this would be a ethtool-nl candidate (which would
> > hopefully land soon after the merge window)?
>
> Is this the repository with the patches? I'll take a look.
>
> https://github.com/mku
Jakub Kicinski writes:
> On Fri, 15 Mar 2019 17:56:07 +, Petr Machata wrote:
>> diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
>> index e2091bb2b3a8..cfd9e86ff0ca 100644
>> --- a/include/net/rtnetlink.h
>> +++ b/include/net/rtnetlink.h
>> @@ -110,6 +110,9 @@ struct rtnl_link
Roopa Prabhu writes:
> This looks good and will be use-full. But i have some comments on the
> implementation below.
> Also, carrier can go down due to protocol down (IFLA_PROTODOWN). And I
> get asked about supporting
> reason codes or protocol owner for such protodown reason (I have not
> giv
> Can't we use netdev_ops for this ?. That will allow any driver to just
> support this readily.
Hi Roopa
I argued this is a PHY layer status information. We don't really want
to have to modify every MAC driver to call into phylib/phylink. Yes,
we can have a netdev_ops for those drivers which ign
On Fri, Mar 15, 2019 at 10:56 AM Petr Machata wrote:
>
> In general, after a port is put administratively up, certain handshake
> protocols have to finish successfully, otherwise the port is left in a
> NO-CARRIER or DORMANT state. When that happens, it would be useful to
> communicate the reasons
On Fri, Mar 15, 2019 at 07:26:11PM -0700, Jakub Kicinski wrote:
> On Fri, 15 Mar 2019 17:56:07 +, Petr Machata wrote:
> > diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
> > index e2091bb2b3a8..cfd9e86ff0ca 100644
> > --- a/include/net/rtnetlink.h
> > +++ b/include/net/rtnetlink.
Hi Petr
> +enum rtnl_link_down_reason_major {
> + RTNL_LDR_OTHER,
Does 'other' make any sense? Seem better to just not report anything
at all, or add a comment that more reasons should be added at the end
to reflect whatever the hardware or software can determine.
> + RTNL_LDR_NO_CABLE,
On Fri, 15 Mar 2019 17:56:07 +, Petr Machata wrote:
> diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
> index e2091bb2b3a8..cfd9e86ff0ca 100644
> --- a/include/net/rtnetlink.h
> +++ b/include/net/rtnetlink.h
> @@ -110,6 +110,9 @@ struct rtnl_link_ops {
> int
In general, after a port is put administratively up, certain handshake
protocols have to finish successfully, otherwise the port is left in a
NO-CARRIER or DORMANT state. When that happens, it would be useful to
communicate the reasons to the administrator, so that the problem that
prevents the lin
22 matches
Mail list logo
