From: andrew@lunn.ch (Andrew Lunn)
To: linus-amlogic@lists.infradead.org
Subject: [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
Date: Mon, 21 Nov 2016 17:47:33 +0100 [thread overview]
Message-ID: <20161121164733.GG1922@lunn.ch> (raw)
In-Reply-To: <1479744993.17538.85.camel@baylibre.com>
> What I did not realize when doing this patch for the realtek driver is
> that there is already 6 valid modes defined in the kernel
>
> #define MDIO_EEE_100TX MDIO_AN_EEE_ADV_100TX /*
> 100TX EEE cap */
> #define MDIO_EEE_1000T MDIO_AN_EEE_ADV_1000T /*
> 1000T EEE cap */
> #define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
> #define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap
> */
> #define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap
> */
> #define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap
> */
>
> I took care of only 2 in the case of realtek.c since it only support
> MDIO_EEE_100TX and MDIO_EEE_1000T.
>
> Defining a property for each is certainly doable but it does not look
> very nice either. If it extends in the future, it will get even more
> messier, especially if you want to disable everything.
Yes, agreed.
> What do you think about keeping a single mask value but use the define
> above in the DT ? It would be more readable than hex and easy to
> extend, don't you think ?
>
> These defines are already part of the uapi so I guess we can use those
> in the DT bindings ?
I don't think they are accessible from the dtc include path. You will
need to make a copy, in include/dt-bindings/net/phy.h
But yes, using these defines is a good idea.
Andrew
WARNING: multiple messages have this Message-ID (diff)
From: andrew@lunn.ch (Andrew Lunn)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
Date: Mon, 21 Nov 2016 17:47:33 +0100 [thread overview]
Message-ID: <20161121164733.GG1922@lunn.ch> (raw)
In-Reply-To: <1479744993.17538.85.camel@baylibre.com>
> What I did not realize when doing this patch for the realtek driver is
> that there is already 6 valid modes defined in the kernel
>
> #define MDIO_EEE_100TX MDIO_AN_EEE_ADV_100TX /*
> 100TX EEE cap */
> #define MDIO_EEE_1000T MDIO_AN_EEE_ADV_1000T /*
> 1000T EEE cap */
> #define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
> #define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap
> */
> #define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap
> */
> #define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap
> */
>
> I took care of only 2 in the case of realtek.c since it only support
> MDIO_EEE_100TX and MDIO_EEE_1000T.
>
> Defining a property for each is certainly doable but it does not look
> very nice either. If it extends in the future, it will get even more
> messier, especially if you want to disable everything.
Yes, agreed.
> What do you think about keeping a single mask value but use the define
> above in the DT ? It would be more readable than hex and easy to
> extend, don't you think ?
>
> These defines are already part of the uapi so I guess we can use those
> in the DT bindings ?
I don't think they are accessible from the dtc include path. You will
need to make a copy, in include/dt-bindings/net/phy.h
But yes, using these defines is a good idea.
Andrew
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
To: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Florian Fainelli
<f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>,
Neil Armstrong
<narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
Martin Blumenstingl
<martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>,
Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andre Roth <neolynx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>,
Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
Date: Mon, 21 Nov 2016 17:47:33 +0100 [thread overview]
Message-ID: <20161121164733.GG1922@lunn.ch> (raw)
In-Reply-To: <1479744993.17538.85.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> What I did not realize when doing this patch for the realtek driver is
> that there is already 6 valid modes defined in the kernel
>
> #define MDIO_EEE_100TX MDIO_AN_EEE_ADV_100TX /*
> 100TX EEE cap */
> #define MDIO_EEE_1000T MDIO_AN_EEE_ADV_1000T /*
> 1000T EEE cap */
> #define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
> #define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap
> */
> #define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap
> */
> #define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap
> */
>
> I took care of only 2 in the case of realtek.c since it only support
> MDIO_EEE_100TX and MDIO_EEE_1000T.
>
> Defining a property for each is certainly doable but it does not look
> very nice either. If it extends in the future, it will get even more
> messier, especially if you want to disable everything.
Yes, agreed.
> What do you think about keeping a single mask value but use the define
> above in the DT ? It would be more readable than hex and easy to
> extend, don't you think ?
>
> These defines are already part of the uapi so I guess we can use those
> in the DT bindings ?
I don't think they are accessible from the dtc include path. You will
need to make a copy, in include/dt-bindings/net/phy.h
But yes, using these defines is a good idea.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: Jerome Brunet <jbrunet@baylibre.com>
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
Florian Fainelli <f.fainelli@gmail.com>,
Alexandre TORGUE <alexandre.torgue@st.com>,
Neil Armstrong <narmstrong@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Kevin Hilman <khilman@baylibre.com>,
linux-kernel@vger.kernel.org, Andre Roth <neolynx@gmail.com>,
linux-amlogic@lists.infradead.org,
Carlo Caione <carlo@caione.org>,
Giuseppe Cavallaro <peppe.cavallaro@st.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
Date: Mon, 21 Nov 2016 17:47:33 +0100 [thread overview]
Message-ID: <20161121164733.GG1922@lunn.ch> (raw)
In-Reply-To: <1479744993.17538.85.camel@baylibre.com>
> What I did not realize when doing this patch for the realtek driver is
> that there is already 6 valid modes defined in the kernel
>
> #define MDIO_EEE_100TX MDIO_AN_EEE_ADV_100TX /*
> 100TX EEE cap */
> #define MDIO_EEE_1000T MDIO_AN_EEE_ADV_1000T /*
> 1000T EEE cap */
> #define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
> #define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap
> */
> #define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap
> */
> #define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap
> */
>
> I took care of only 2 in the case of realtek.c since it only support
> MDIO_EEE_100TX and MDIO_EEE_1000T.
>
> Defining a property for each is certainly doable but it does not look
> very nice either. If it extends in the future, it will get even more
> messier, especially if you want to disable everything.
Yes, agreed.
> What do you think about keeping a single mask value but use the define
> above in the DT ? It would be more readable than hex and easy to
> extend, don't you think ?
>
> These defines are already part of the uapi so I guess we can use those
> in the DT bindings ?
I don't think they are accessible from the dtc include path. You will
need to make a copy, in include/dt-bindings/net/phy.h
But yes, using these defines is a good idea.
Andrew
next prev parent reply other threads:[~2016-11-21 16:47 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-21 15:35 [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` [RFC PATCH net v2 1/3] net: phy: add an option to disable EEE advertisement Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-22 5:04 ` Anand Moon
2016-11-22 5:04 ` Anand Moon
2016-11-22 5:04 ` Anand Moon
2016-11-22 5:04 ` Anand Moon
2016-11-21 15:35 ` [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 16:01 ` Andrew Lunn
2016-11-21 16:01 ` Andrew Lunn
2016-11-21 16:01 ` Andrew Lunn
2016-11-21 16:16 ` Jerome Brunet
2016-11-21 16:16 ` Jerome Brunet
2016-11-21 16:16 ` Jerome Brunet
2016-11-21 16:16 ` Jerome Brunet
2016-11-21 16:47 ` Andrew Lunn [this message]
2016-11-21 16:47 ` Andrew Lunn
2016-11-21 16:47 ` Andrew Lunn
2016-11-21 16:47 ` Andrew Lunn
2016-11-22 5:35 ` Florian Fainelli
2016-11-22 5:35 ` Florian Fainelli
2016-11-22 5:35 ` Florian Fainelli
2016-11-22 10:13 ` Jerome Brunet
2016-11-22 10:13 ` Jerome Brunet
2016-11-22 10:13 ` Jerome Brunet
2016-11-22 10:13 ` Jerome Brunet
2016-11-21 15:35 ` [RFC PATCH net v2 3/3] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-24 14:40 ` [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue Martin Blumenstingl
2016-11-24 14:40 ` Martin Blumenstingl
2016-11-24 14:40 ` Martin Blumenstingl
2016-11-24 16:01 ` Jerome Brunet
2016-11-24 16:01 ` Jerome Brunet
2016-11-24 16:01 ` Jerome Brunet
2016-11-24 16:01 ` Jerome Brunet
2016-11-24 17:10 ` Martin Blumenstingl
2016-11-24 17:10 ` Martin Blumenstingl
2016-11-24 17:10 ` Martin Blumenstingl
2016-11-24 17:10 ` Martin Blumenstingl
2016-11-25 9:55 ` Jerome Brunet
2016-11-25 9:55 ` Jerome Brunet
2016-11-25 9:55 ` Jerome Brunet
2016-11-25 9:55 ` Jerome Brunet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161121164733.GG1922@lunn.ch \
--to=andrew@lunn.ch \
--cc=linus-amlogic@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.