All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.