* [PATCH net-next] tipc: correct structure parameter comments for topsrv
From: Zhenbo Gao @ 2018-09-03 6:08 UTC (permalink / raw)
To: jon.maloy, davem; +Cc: netdev, tipc-discussion, yue.tao
Remove the following obsolete parameter comments of tipc_topsrv struct:
@rcvbuf_cache
@tipc_conn_new
@tipc_conn_release
@tipc_conn_recvmsg
@imp
@type
Add the comments for the missing parameters below of tipc_topsrv struct:
@awork
@listener
Remove the unused or duplicated parameter comments of tipc_conn struct:
@outqueue_lock
@rx_action
Signed-off-by: Zhenbo Gao <zhenbo.gao@windriver.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
---
net/tipc/topsrv.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/net/tipc/topsrv.c b/net/tipc/topsrv.c
index c8e34ef..c782b35 100644
--- a/net/tipc/topsrv.c
+++ b/net/tipc/topsrv.c
@@ -57,16 +57,12 @@
* @idr_lock: protect the connection identifier set
* @idr_in_use: amount of allocated identifier entry
* @net: network namspace instance
- * @rcvbuf_cache: memory cache of server receive buffer
+ * @awork: accept work item
* @rcv_wq: receive workqueue
* @send_wq: send workqueue
* @max_rcvbuf_size: maximum permitted receive message length
- * @tipc_conn_new: callback will be called when new connection is incoming
- * @tipc_conn_release: callback will be called before releasing the connection
- * @tipc_conn_recvmsg: callback will be called when message arrives
+ * @listener: topsrv listener socket
* @name: server name
- * @imp: message importance
- * @type: socket type
*/
struct tipc_topsrv {
struct idr conn_idr;
@@ -90,9 +86,7 @@ struct tipc_topsrv {
* @server: pointer to connected server
* @sub_list: lsit to all pertaing subscriptions
* @sub_lock: lock protecting the subscription list
- * @outqueue_lock: control access to the outqueue
* @rwork: receive work item
- * @rx_action: what to do when connection socket is active
* @outqueue: pointer to first outbound message in queue
* @outqueue_lock: control access to the outqueue
* @swork: send work item
--
1.9.1
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply related
* RE: [EXT] [BUG] net: wireless: mwifiex: A possible sleep-in-atomic-context bug in mwifiex_wait_queue_complete()
From: Ganapathi Bhat @ 2018-09-03 6:41 UTC (permalink / raw)
To: Jia-Ju Bai, amitkarwar@gmail.com, nishants@marvell.com,
huxinming820@gmail.com, kvalo@codeaurora.org
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <35980039-f268-2db3-5c7d-19ab0c917d44@gmail.com>
Hi Jia-Ju,
>
> [FUNC] schedule_timeout
> drivers/net/wireless/marvell/mwifiex/sta_ioctl.c, 63:
> schedule_timeout in mwifiex_wait_queue_complete
> drivers/net/wireless/marvell/mwifiex/cmdevt.c, 673:
> mwifiex_wait_queue_complete in mwifiex_send_cmd
Here, mwifiex_send_cmd does not call mwifiex_wait_queue_complete, because the sync parameter is false.
Note that the function mwifiex_multi_chan_resync did call mwifiex_send_cmd with sync = false.
> drivers/net/wireless/marvell/mwifiex/main.c, 1046:
> mwifiex_send_cmd in mwifiex_multi_chan_resync
> drivers/net/wireless/marvell/mwifiex/usb.c, 288:
> mwifiex_multi_chan_resync in mwifiex_usb_tx_complete
>
Thanks,
Ganapathi
^ permalink raw reply
* Re: [PATCH v2] Optimize lookup of /0 xfrm policies
From: Steffen Klassert @ 2018-09-03 6:56 UTC (permalink / raw)
To: Yannick Brosseau; +Cc: herbert, davem, netdev, linux-kernel, kernel-team
In-Reply-To: <20180831221838.25597-1-scientist@fb.com>
On Fri, Aug 31, 2018 at 06:18:38PM -0400, Yannick Brosseau wrote:
> Currently, all the xfrm policies that are not /32 end up in
> the inexact policies linked list which take a long time to lookup.
It is possible to configure which policies are going to the
hashtable and the inexact list.
You can do:
ip x p set hthresh4 0 0
This sets the hash threshold to local /0 and remote /0 netmasks.
With this configuration, all policies should go to the hashtable.
To view the configuration:
ip -s -s x p count
Can you please do your tests with this too?
I'd really like to avoid to add new code to the policy lookup
if we can get similar results with this configuration option.
^ permalink raw reply
* [PATCH v2] net/ibm/emac: wrong emac_calc_base call was used by typo
From: Ivan Mikhaylov @ 2018-09-03 7:26 UTC (permalink / raw)
To: netdev; +Cc: David Miller, linux-kernel, Christian Lamparter
__emac_calc_base_mr1 was used instead of __emac4_calc_base_mr1
by copy-paste mistake for emac4syn.
Fixes: 45d6e545505fd32edb812f085be7de45b6a5c0af ("net/ibm/emac: add 8192 rx/tx fifo size")
Signed-off-by: Ivan Mikhaylov <ivan@de.ibm.com>
---
drivers/net/ethernet/ibm/emac/core.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index 354c098..3726646 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -494,9 +494,6 @@ static u32 __emac_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_s
case 16384:
ret |= EMAC_MR1_RFS_16K;
break;
- case 8192:
- ret |= EMAC4_MR1_RFS_8K;
- break;
case 4096:
ret |= EMAC_MR1_RFS_4K;
break;
@@ -537,6 +534,9 @@ static u32 __emac4_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_
case 16384:
ret |= EMAC4_MR1_RFS_16K;
break;
+ case 8192:
+ ret |= EMAC4_MR1_RFS_8K;
+ break;
case 4096:
ret |= EMAC4_MR1_RFS_4K;
break;
--
1.7.1
^ permalink raw reply related
* Re: [EXT] [BUG] net: wireless: mwifiex: A possible sleep-in-atomic-context bug in mwifiex_wait_queue_complete()
From: Jia-Ju Bai @ 2018-09-03 7:35 UTC (permalink / raw)
To: Ganapathi Bhat, amitkarwar@gmail.com, nishants@marvell.com,
huxinming820@gmail.com, kvalo@codeaurora.org
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <5fbe17917c344f318c25a688f2e94823@SC-EXCH02.marvell.com>
On 2018/9/3 14:41, Ganapathi Bhat wrote:
> Hi Jia-Ju,
>
>> [FUNC] schedule_timeout
>> drivers/net/wireless/marvell/mwifiex/sta_ioctl.c, 63:
>> schedule_timeout in mwifiex_wait_queue_complete
>> drivers/net/wireless/marvell/mwifiex/cmdevt.c, 673:
>> mwifiex_wait_queue_complete in mwifiex_send_cmd
> Here, mwifiex_send_cmd does not call mwifiex_wait_queue_complete, because the sync parameter is false.
> Note that the function mwifiex_multi_chan_resync did call mwifiex_send_cmd with sync = false.
Thanks for the reply.
I check the code again, and find my report it false, sorry for that.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH net-next 0/5] rtnetlink: add IFA_IF_NETNSID for RTM_GETADDR
From: Nicolas Dichtel @ 2018-09-03 7:50 UTC (permalink / raw)
To: Jiri Benc, Christian Brauner
Cc: David Miller, ktkhai, netdev, linux-kernel, kuznet, yoshfuji,
pombredanne, kstewart, gregkh, dsahern, fw, lucien.xin,
jakub.kicinski
In-Reply-To: <20180902115851.2b224c23@redhat.com>
Le 02/09/2018 à 11:58, Jiri Benc a écrit :
> On Sat, 1 Sep 2018 20:47:05 +0200, Christian Brauner wrote:
>> Sorry for the late reply. Yup, sounds good to me.
>> But maybe IFA_TARGET_NETNSID to indicate that we're talking network
>> namespaces here? Seems to me that NSID might give the wrong impression.
>> I'll send v1 soon. I expect tomorrow or sometime next week.
>
> On the other hand, we currently have IFLA_IF_NETNSID for the link
> operations. IFA_IF_NETNSID is more consistent with the existing
> attribute. It may be confusing to authors of user space programs to
> have attribute names doing the same thing constructed differently for
> different calls (IFLA_IF_NETNSID and IFA_TARGET_NETNSID).
Yep, I also thought to this. It had sense because it was the link family.
What about adding an alias (#define IFLA_TARGET_NETNSID IFLA_IF_NETNSID) in the
uapi to better document this?
^ permalink raw reply
* Re: [PATCH] mac80211: fix TX status reporting for ieee80211s
From: Johannes Berg @ 2018-09-03 8:33 UTC (permalink / raw)
To: Yuan-Chi Pang; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <1535699575-5672-1-git-send-email-fu3mo6goo@gmail.com>
On Fri, 2018-08-31 at 15:12 +0800, Yuan-Chi Pang wrote:
> void ieee80211s_init(void);
> void ieee80211s_update_metric(struct ieee80211_local *local,
> - struct sta_info *sta, struct sk_buff *skb);
> + struct sta_info *sta, struct ieee80211_tx_status *st);
please keep things indented properly
> void ieee80211s_update_metric(struct ieee80211_local *local,
> - struct sta_info *sta, struct sk_buff *skb)
> + struct sta_info *sta, struct ieee80211_tx_status *st)
and maybe fix the indentation here while you're changing it
> {
> - struct ieee80211_tx_info *txinfo = IEEE80211_SKB_CB(skb);
> - struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
> + struct ieee80211_tx_info *txinfo = st->info;
> int failed;
>
> - if (!ieee80211_is_data(hdr->frame_control))
> - return;
Why are you removing this condition? You didn't say anything about that.
I sort of see why (you no longer even have the skb/hdr), but you should
indicate why this is OK.
> rate_control_tx_status(local, sband, status);
> + if (ieee80211_vif_is_mesh(&sta->sdata->vif))
> + ieee80211s_update_metric(local, sta, status)
This is the only "real" change I guess, some more description about it
would be good.
I can sort of reverse engineer it from your commit log, but you should
be more explicit.
johannes
^ permalink raw reply
* [PATCH net-next 1/2] tipc: correct spelling errors for struct tipc_bc_base's comment
From: Zhenbo Gao @ 2018-09-03 8:36 UTC (permalink / raw)
To: jon.maloy, davem; +Cc: netdev, tipc-discussion, yue.tao
Trivial fix for two spelling mistakes.
Signed-off-by: Zhenbo Gao <zhenbo.gao@windriver.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
---
net/tipc/bcast.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index 9ee6cfe..d802654 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -51,12 +51,12 @@
* struct tipc_bc_base - base structure for keeping broadcast send state
* @link: broadcast send link structure
* @inputq: data input queue; will only carry SOCK_WAKEUP messages
- * @dest: array keeping number of reachable destinations per bearer
+ * @dests: array keeping number of reachable destinations per bearer
* @primary_bearer: a bearer having links to all broadcast destinations, if any
* @bcast_support: indicates if primary bearer, if any, supports broadcast
* @rcast_support: indicates if all peer nodes support replicast
* @rc_ratio: dest count as percentage of cluster size where send method changes
- * @bc_threshold: calculated drom rc_ratio; if dests > threshold use broadcast
+ * @bc_threshold: calculated from rc_ratio; if dests > threshold use broadcast
*/
struct tipc_bc_base {
struct tipc_link *link;
--
1.9.1
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply related
* [PATCH net-next 2/2] tipc: correct spelling errors for tipc_topsrv_queue_evt() comments
From: Zhenbo Gao @ 2018-09-03 8:36 UTC (permalink / raw)
To: jon.maloy, davem; +Cc: netdev, tipc-discussion, yue.tao
In-Reply-To: <1535963806-27142-1-git-send-email-zhenbo.gao@windriver.com>
tipc_conn_queue_evt -> tipc_topsrv_queue_evt
tipc_send_work -> tipc_conn_send_work
tipc_send_to_sock -> tipc_conn_send_to_sock
Signed-off-by: Zhenbo Gao <zhenbo.gao@windriver.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
---
net/tipc/topsrv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/topsrv.c b/net/tipc/topsrv.c
index c782b35..d8956f7 100644
--- a/net/tipc/topsrv.c
+++ b/net/tipc/topsrv.c
@@ -307,8 +307,8 @@ static void tipc_conn_send_work(struct work_struct *work)
conn_put(con);
}
-/* tipc_conn_queue_evt() - interrupt level call from a subscription instance
- * The queued work is launched into tipc_send_work()->tipc_send_to_sock()
+/* tipc_topsrv_queue_evt() - interrupt level call from a subscription instance
+ * The queued work is launched into tipc_conn_send_work()->tipc_conn_send_to_sock()
*/
void tipc_topsrv_queue_evt(struct net *net, int conid,
u32 event, struct tipc_event *evt)
--
1.9.1
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply related
* [PATCH net-next v2 1/7] net: phy: mscc: factorize code for LEDs mode
From: Quentin Schulz @ 2018-09-03 8:48 UTC (permalink / raw)
To: davem, robh+dt, mark.rutland, andrew, f.fainelli
Cc: allan.nielsen, netdev, devicetree, linux-kernel, thomas.petazzoni,
Quentin Schulz
LEDs modes are set the same way, except they are offset by 4 times the
index of the LED.
Let's factorize all the code so that it's easier to add support for the
4 LEDs of the VSC8584 PHY.
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
drivers/net/phy/mscc.c | 75 ++++++++++++++++++++++--------------------
1 file changed, 39 insertions(+), 36 deletions(-)
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index 84ca9ff40ae0..af433f226ef4 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -54,9 +54,9 @@ enum rgmii_rx_clock_delay {
#define HP_AUTO_MDIX_X_OVER_IND_MASK 0x2000
#define MSCC_PHY_LED_MODE_SEL 29
-#define LED_1_MODE_SEL_MASK 0x00F0
-#define LED_0_MODE_SEL_MASK 0x000F
-#define LED_1_MODE_SEL_POS 4
+#define LED_MODE_SEL_POS(x) ((x) * 4)
+#define LED_MODE_SEL_MASK(x) (GENMASK(3, 0) << LED_MODE_SEL_POS(x))
+#define LED_MODE_SEL(x, mode) (((mode) << LED_MODE_SEL_POS(x)) & LED_MODE_SEL_MASK(x))
#define MSCC_EXT_PAGE_ACCESS 31
#define MSCC_PHY_PAGE_STANDARD 0x0000 /* Standard registers */
@@ -103,10 +103,11 @@ enum rgmii_rx_clock_delay {
#define DOWNSHIFT_COUNT_MAX 5
+#define MAX_LEDS 4
struct vsc8531_private {
int rate_magic;
- u8 led_0_mode;
- u8 led_1_mode;
+ u8 leds_mode[MAX_LEDS];
+ u8 nleds;
};
#ifdef CONFIG_OF_MDIO
@@ -140,14 +141,8 @@ static int vsc85xx_led_cntl_set(struct phy_device *phydev,
mutex_lock(&phydev->lock);
reg_val = phy_read(phydev, MSCC_PHY_LED_MODE_SEL);
- if (led_num) {
- reg_val &= ~LED_1_MODE_SEL_MASK;
- reg_val |= (((u16)mode << LED_1_MODE_SEL_POS) &
- LED_1_MODE_SEL_MASK);
- } else {
- reg_val &= ~LED_0_MODE_SEL_MASK;
- reg_val |= ((u16)mode & LED_0_MODE_SEL_MASK);
- }
+ reg_val &= ~LED_MODE_SEL_MASK(led_num);
+ reg_val |= LED_MODE_SEL(led_num, (u16)mode);
rc = phy_write(phydev, MSCC_PHY_LED_MODE_SEL, reg_val);
mutex_unlock(&phydev->lock);
@@ -438,6 +433,27 @@ static int vsc85xx_dt_led_mode_get(struct phy_device *phydev,
}
#endif /* CONFIG_OF_MDIO */
+static int vsc85xx_dt_led_modes_get(struct phy_device *phydev, u8 *default_mode)
+{
+ struct vsc8531_private *priv = phydev->priv;
+ char led_dt_prop[19];
+ int i, ret;
+
+ for (i = 0; i < priv->nleds; i++) {
+ ret = sprintf(led_dt_prop, "vsc8531,led-%d-mode", i);
+ if (ret < 0)
+ return ret;
+
+ ret = vsc85xx_dt_led_mode_get(phydev, led_dt_prop,
+ default_mode[i]);
+ if (ret < 0)
+ return ret;
+ priv->leds_mode[i] = ret;
+ }
+
+ return 0;
+}
+
static int vsc85xx_edge_rate_cntl_set(struct phy_device *phydev, u8 edge_rate)
{
int rc;
@@ -545,7 +561,7 @@ static int vsc85xx_set_tunable(struct phy_device *phydev,
static int vsc85xx_config_init(struct phy_device *phydev)
{
- int rc;
+ int rc, i;
struct vsc8531_private *vsc8531 = phydev->priv;
rc = vsc85xx_default_config(phydev);
@@ -560,13 +576,11 @@ static int vsc85xx_config_init(struct phy_device *phydev)
if (rc)
return rc;
- rc = vsc85xx_led_cntl_set(phydev, 1, vsc8531->led_1_mode);
- if (rc)
- return rc;
-
- rc = vsc85xx_led_cntl_set(phydev, 0, vsc8531->led_0_mode);
- if (rc)
- return rc;
+ for (i = 0; i < vsc8531->nleds; i++) {
+ rc = vsc85xx_led_cntl_set(phydev, i, vsc8531->leds_mode[i]);
+ if (rc)
+ return rc;
+ }
rc = genphy_config_init(phydev);
@@ -626,7 +640,8 @@ static int vsc85xx_probe(struct phy_device *phydev)
{
struct vsc8531_private *vsc8531;
int rate_magic;
- int led_mode;
+ u8 default_mode[2] = {VSC8531_LINK_1000_ACTIVITY,
+ VSC8531_LINK_100_ACTIVITY};
rate_magic = vsc85xx_edge_rate_magic_get(phydev);
if (rate_magic < 0)
@@ -639,21 +654,9 @@ static int vsc85xx_probe(struct phy_device *phydev)
phydev->priv = vsc8531;
vsc8531->rate_magic = rate_magic;
+ vsc8531->nleds = 2;
- /* LED[0] and LED[1] mode */
- led_mode = vsc85xx_dt_led_mode_get(phydev, "vsc8531,led-0-mode",
- VSC8531_LINK_1000_ACTIVITY);
- if (led_mode < 0)
- return led_mode;
- vsc8531->led_0_mode = led_mode;
-
- led_mode = vsc85xx_dt_led_mode_get(phydev, "vsc8531,led-1-mode",
- VSC8531_LINK_100_ACTIVITY);
- if (led_mode < 0)
- return led_mode;
- vsc8531->led_1_mode = led_mode;
-
- return 0;
+ return vsc85xx_dt_led_modes_get(phydev, default_mode);
}
/* Microsemi VSC85xx PHYs */
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 3/7] net: phy: mscc: read 'vsc8531,vddmac' as an u32
From: Quentin Schulz @ 2018-09-03 8:48 UTC (permalink / raw)
To: davem, robh+dt, mark.rutland, andrew, f.fainelli
Cc: allan.nielsen, netdev, devicetree, linux-kernel, thomas.petazzoni,
Quentin Schulz
In-Reply-To: <20180903084853.18092-1-quentin.schulz@bootlin.com>
In the DT binding, it is specified nowhere that 'vsc8531,vddmac' is an
u16, even though it's read as an u16 in the driver.
Let's update the driver to take into consideration that the
'vsc8531,vddmac' property is of the default type u32.
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
added in v2
drivers/net/phy/mscc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index aa37e8547cd0..49dc23117732 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -128,7 +128,7 @@ struct vsc8531_private {
#ifdef CONFIG_OF_MDIO
struct vsc8531_edge_rate_table {
- u16 vddmac;
+ u32 vddmac;
u8 slowdown[8];
};
@@ -387,7 +387,7 @@ static void vsc85xx_wol_get(struct phy_device *phydev,
static int vsc85xx_edge_rate_magic_get(struct phy_device *phydev)
{
u8 sd;
- u16 vdd;
+ u32 vdd;
int rc, i, j;
struct device *dev = &phydev->mdio.dev;
struct device_node *of_node = dev->of_node;
@@ -396,7 +396,7 @@ static int vsc85xx_edge_rate_magic_get(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
- rc = of_property_read_u16(of_node, "vsc8531,vddmac", &vdd);
+ rc = of_property_read_u32(of_node, "vsc8531,vddmac", &vdd);
if (rc != 0)
vdd = MSCC_VDDMAC_3300;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 4/7] net: phy: mscc: read 'vsc8531,edge-slowdown' as an u32
From: Quentin Schulz @ 2018-09-03 8:48 UTC (permalink / raw)
To: davem, robh+dt, mark.rutland, andrew, f.fainelli
Cc: allan.nielsen, netdev, devicetree, linux-kernel, thomas.petazzoni,
Quentin Schulz
In-Reply-To: <20180903084853.18092-1-quentin.schulz@bootlin.com>
In the DT binding, it is specified nowhere that 'vsc8531,edge-slowdown'
is an u8, even though it's read as an u8 in the driver.
Let's update the driver to take into consideration that the
'vsc8531,edge-slowdown' property is of the default type u32.
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
added in v2
drivers/net/phy/mscc.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index 49dc23117732..3c7b02bb5c38 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -129,7 +129,7 @@ struct vsc8531_private {
#ifdef CONFIG_OF_MDIO
struct vsc8531_edge_rate_table {
u32 vddmac;
- u8 slowdown[8];
+ u32 slowdown[8];
};
static const struct vsc8531_edge_rate_table edge_table[] = {
@@ -386,8 +386,7 @@ static void vsc85xx_wol_get(struct phy_device *phydev,
#ifdef CONFIG_OF_MDIO
static int vsc85xx_edge_rate_magic_get(struct phy_device *phydev)
{
- u8 sd;
- u32 vdd;
+ u32 vdd, sd;
int rc, i, j;
struct device *dev = &phydev->mdio.dev;
struct device_node *of_node = dev->of_node;
@@ -400,7 +399,7 @@ static int vsc85xx_edge_rate_magic_get(struct phy_device *phydev)
if (rc != 0)
vdd = MSCC_VDDMAC_3300;
- rc = of_property_read_u8(of_node, "vsc8531,edge-slowdown", &sd);
+ rc = of_property_read_u32(of_node, "vsc8531,edge-slowdown", &sd);
if (rc != 0)
sd = 0;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 5/7] net: phy: mscc: read 'vsc8531,led-%d-mode' as an u32
From: Quentin Schulz @ 2018-09-03 8:48 UTC (permalink / raw)
To: davem, robh+dt, mark.rutland, andrew, f.fainelli
Cc: allan.nielsen, netdev, devicetree, linux-kernel, thomas.petazzoni,
Quentin Schulz
In-Reply-To: <20180903084853.18092-1-quentin.schulz@bootlin.com>
In the DT binding, it is specified nowhere that 'vsc8531,led-%d-mode' is
an u8, even though it's read as an u8 in the driver.
Let's update the driver to take into consideration that the
'vsc8531,led-%d-mode' property is of the default type u32.
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
added in v2 in lieu of the DT binding patch for adding /bits 8/ to the
vsc8531,led-N-mode property
drivers/net/phy/mscc.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index 3c7b02bb5c38..2d9676d78d3f 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -122,7 +122,7 @@ enum rgmii_rx_clock_delay {
struct vsc8531_private {
int rate_magic;
u16 supp_led_modes;
- u8 leds_mode[MAX_LEDS];
+ u32 leds_mode[MAX_LEDS];
u8 nleds;
};
@@ -414,19 +414,19 @@ static int vsc85xx_edge_rate_magic_get(struct phy_device *phydev)
static int vsc85xx_dt_led_mode_get(struct phy_device *phydev,
char *led,
- u8 default_mode)
+ u32 default_mode)
{
struct vsc8531_private *priv = phydev->priv;
struct device *dev = &phydev->mdio.dev;
struct device_node *of_node = dev->of_node;
- u8 led_mode;
+ u32 led_mode;
int err;
if (!of_node)
return -ENODEV;
led_mode = default_mode;
- err = of_property_read_u8(of_node, led, &led_mode);
+ err = of_property_read_u32(of_node, led, &led_mode);
if (!err && !(BIT(led_mode) & priv->supp_led_modes)) {
phydev_err(phydev, "DT %s invalid\n", led);
return -EINVAL;
@@ -449,7 +449,8 @@ static int vsc85xx_dt_led_mode_get(struct phy_device *phydev,
}
#endif /* CONFIG_OF_MDIO */
-static int vsc85xx_dt_led_modes_get(struct phy_device *phydev, u8 *default_mode)
+static int vsc85xx_dt_led_modes_get(struct phy_device *phydev,
+ u32 *default_mode)
{
struct vsc8531_private *priv = phydev->priv;
char led_dt_prop[19];
@@ -656,7 +657,7 @@ static int vsc85xx_probe(struct phy_device *phydev)
{
struct vsc8531_private *vsc8531;
int rate_magic;
- u8 default_mode[2] = {VSC8531_LINK_1000_ACTIVITY,
+ u32 default_mode[2] = {VSC8531_LINK_1000_ACTIVITY,
VSC8531_LINK_100_ACTIVITY};
rate_magic = vsc85xx_edge_rate_magic_get(phydev);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 7/7] dt-bindings: net: phy: mscc: vsc8531: factorize vsc8531,led-N-mode
From: Quentin Schulz @ 2018-09-03 8:48 UTC (permalink / raw)
To: davem, robh+dt, mark.rutland, andrew, f.fainelli
Cc: allan.nielsen, netdev, devicetree, linux-kernel, thomas.petazzoni,
Quentin Schulz
In-Reply-To: <20180903084853.18092-1-quentin.schulz@bootlin.com>
VSC8584 supports 4 LEDs while VSC8531 only supports 2. Let's factorize
the documentation for LED mode properties and give the 4 default values
(the first two being shared between VSC8531 and VSC8584).
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
.../devicetree/bindings/net/mscc-phy-vsc8531.txt | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
index 664d9d0543fc..5ff37c68c941 100644
--- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
+++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
@@ -22,14 +22,16 @@ Optional properties:
'vddmac'.
Default value is 0%.
Ref: Table:1 - Edge rate change (below).
-- vsc8531,led-0-mode : LED mode. Specify how the LED[0] should behave.
- Allowed values are define in
+- vsc8531,led-[N]-mode : LED mode. Specify how the LED[N] should behave.
+ N depends on the number of LEDs supported by a
+ PHY.
+ Allowed values are defined in
"include/dt-bindings/net/mscc-phy-vsc8531.h".
- Default value is VSC8531_LINK_1000_ACTIVITY (1).
-- vsc8531,led-1-mode : LED mode. Specify how the LED[1] should behave.
- Allowed values are define in
- "include/dt-bindings/net/mscc-phy-vsc8531.h".
- Default value is VSC8531_LINK_100_ACTIVITY (2).
+ Default values are VSC8531_LINK_1000_ACTIVITY (1),
+ VSC8531_LINK_100_ACTIVITY (2),
+ VSC8531_LINK_ACTIVITY (0) and
+ VSC8531_DUPLEX_COLLISION (8).
+
Table: 1 - Edge rate change
----------------------------------------------------------------|
--
2.17.1
^ permalink raw reply related
* Re: WARNING: suspicious RCU usage in pid_task
From: Dmitry Vyukov @ 2018-09-03 4:56 UTC (permalink / raw)
To: syzbot, David Miller, Hideaki YOSHIFUJI, Alexei Starovoitov,
weiyongjun1, netdev
Cc: Andrew Morton, David Howells, Eric W. Biederman, Gargi Sharma,
LKML, Oleg Nesterov, Pavel Tatashin, Rik van Riel, Mike Rapoport,
syzkaller-bugs, Kefeng Wang
In-Reply-To: <000000000000f0c659056f7af058@google.com>
On Mon, Jun 25, 2018 at 7:45 PM, syzbot
<syzbot+c2d4c3ae3fd90bbaf059@syzkaller.appspotmail.com> wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit: 6f0d349d922b Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14c04304400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=a63be0c83e84d370
> dashboard link: https://syzkaller.appspot.com/bug?extid=c2d4c3ae3fd90bbaf059
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=14f0a814400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16ce574c400000
Probably bpfilter problem, +bpfilter maintainers.
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+c2d4c3ae3fd90bbaf059@syzkaller.appspotmail.com
>
> bpfilter: read fail -512
>
> =============================
> WARNING: suspicious RCU usage
> 4.18.0-rc2+ #117 Not tainted
> -----------------------------
> kernel/pid.c:323 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 1
> 1 lock held by syz-executor106/7744:
> #0: 00000000bee82115 (bpfilter_lock){+.+.}, at:
> __bpfilter_process_sockopt+0x1c5/0x39b net/bpfilter/bpfilter_kern.c:67
>
> stack backtrace:
> CPU: 1 PID: 7744 Comm: syz-executor106 Not tainted 4.18.0-rc2+ #117
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> lockdep_rcu_suspicious+0x14a/0x153 kernel/locking/lockdep.c:4562
> pid_task+0x1ce/0x200 kernel/pid.c:322
> shutdown_umh.constprop.0+0x33/0x7c net/bpfilter/bpfilter_kern.c:29
> __stop_umh net/bpfilter/bpfilter_kern.c:41 [inline]
> __bpfilter_process_sockopt.cold.1+0x9b/0xa0 net/bpfilter/bpfilter_kern.c:81
> bpfilter_mbox_request+0x4d/0xb0 net/ipv4/bpfilter/sockopt.c:25
> bpfilter_ip_set_sockopt+0x33/0x40 net/ipv4/bpfilter/sockopt.c:31
> ip_setsockopt+0x124/0x140 net/ipv4/ip_sockglue.c:1250
> dccp_setsockopt+0x96/0xf0 net/dccp/proto.c:565
> sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3040
> __sys_setsockopt+0x1c5/0x3b0 net/socket.c:1947
> __do_sys_setsockopt net/socket.c:1958 [inline]
> __se_sys_setsockopt net/socket.c:1955 [inline]
> __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1955
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x44cdb9
> Code: e8 6c bd 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
> 0f 83 cb d2 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f63b04a8d18 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
> RAX: ffffffffffffffda RBX: 00000000006dfce4 RCX: 000000000044cdb9
> RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000027
> RBP: 00000000006dfce0 R08: 0000000000000000 R09: 65732f636f72702f
> R10: 0000000020000000 R11: 0000000000000246 R12: 00007f63b04a8d20
> R13: 0100000000000000 R14: 6273752f7665642f R15: 0000000000000034
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000f0c659056f7af058%40google.com.
>
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH net-next 0/5] rtnetlink: add IFA_IF_NETNSID for RTM_GETADDR
From: Christian Brauner @ 2018-09-03 9:32 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: Jiri Benc, David Miller, ktkhai, netdev, linux-kernel, kuznet,
yoshfuji, pombredanne, kstewart, gregkh, dsahern, fw, lucien.xin,
jakub.kicinski
In-Reply-To: <d9efff32-4138-5645-c610-7f2051085d7b@6wind.com>
On Mon, Sep 03, 2018 at 09:50:00AM +0200, Nicolas Dichtel wrote:
> Le 02/09/2018 à 11:58, Jiri Benc a écrit :
> > On Sat, 1 Sep 2018 20:47:05 +0200, Christian Brauner wrote:
> >> Sorry for the late reply. Yup, sounds good to me.
> >> But maybe IFA_TARGET_NETNSID to indicate that we're talking network
> >> namespaces here? Seems to me that NSID might give the wrong impression.
> >> I'll send v1 soon. I expect tomorrow or sometime next week.
> >
> > On the other hand, we currently have IFLA_IF_NETNSID for the link
> > operations. IFA_IF_NETNSID is more consistent with the existing
> > attribute. It may be confusing to authors of user space programs to
> > have attribute names doing the same thing constructed differently for
> > different calls (IFLA_IF_NETNSID and IFA_TARGET_NETNSID).
> Yep, I also thought to this. It had sense because it was the link family.
> What about adding an alias (#define IFLA_TARGET_NETNSID IFLA_IF_NETNSID) in the
> uapi to better document this?
Sounds good to me.
^ permalink raw reply
* [PATCH v2 00/11] mscc: ocelot: add support for SerDes muxing configuration
From: Quentin Schulz @ 2018-09-03 9:32 UTC (permalink / raw)
To: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, f.fainelli
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni, Quentin Schulz
The Ocelot switch has currently an hardcoded SerDes muxing that suits only
a particular use case. Any other board setup will fail to work.
To prepare for upcoming boards' support that do not have the same muxing,
create a PHY driver that will handle all possible cases.
A SerDes can work in SGMII, QSGMII or PCIe and is also muxed to use a
given port depending on the selected mode or board design.
The SerDes configuration is in the middle of an address space (HSIO) that
is used to configure some parts in the MAC controller driver, that is why
we need to use a syscon so that we can write to the same address space from
different drivers safely using regmap.
Patches from generic PHY and net should be safe to be merged separately.
This breaks backward compatibility but it's fine because there's only one
board at the moment that is using what's modified in this patch series.
This will break git bisect.
Even though this patch series is about SerDes __muxing__ configuration, the
DT node is named serdes for the simple reason that I couldn't find any
mention to SerDes anywhere else from the address space handled by this
driver.
I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through
net while the others (6, 7, 9 and 10) go through the generic PHY subsystem.
Thanks,
Quentin
v2:
- use a switch case for setting the phy_mode in the SerDes driver as
suggested by Andrew,
- stop replacing the value of the error pointer in the SerDes driver,
- use a dev_dbg for the deferring of the probe in the SerDes driver,
- use constants in the Device Tree to select the SerDes macro in use with
a port,
- adapt the SerDes driver to use those constants,
- add a header file in include/dt-bindings for the constants,
- fix space/tab issue,
Quentin Schulz (11):
MIPS: mscc: ocelot: make HSIO registers address range a syscon
dt-bindings: net: ocelot: remove hsio from the list of register
address spaces
net: mscc: ocelot: get HSIO regmap from syscon
net: mscc: ocelot: move the HSIO header to include/soc
net: mscc: ocelot: simplify register access for PLL5 configuration
phy: add QSGMII and PCIE modes
dt-bindings: phy: add DT binding for Microsemi Ocelot SerDes muxing
MIPS: mscc: ocelot: add SerDes mux DT node
dt-bindings: add constants for Microsemi Ocelot SerDes driver
phy: add driver for Microsemi Ocelot SerDes muxing
net: mscc: ocelot: make use of SerDes PHYs for handling their
configuration
.../devicetree/bindings/mips/mscc.txt | 16 +
.../devicetree/bindings/net/mscc-ocelot.txt | 9 +-
.../bindings/phy/phy-ocelot-serdes.txt | 40 +++
arch/mips/boot/dts/mscc/ocelot.dtsi | 19 +-
drivers/net/ethernet/mscc/Kconfig | 2 +
drivers/net/ethernet/mscc/ocelot.c | 16 +-
drivers/net/ethernet/mscc/ocelot.h | 79 +----
drivers/net/ethernet/mscc/ocelot_board.c | 61 +++-
drivers/net/ethernet/mscc/ocelot_regs.c | 93 +-----
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/mscc/Kconfig | 11 +
drivers/phy/mscc/Makefile | 5 +
drivers/phy/mscc/phy-ocelot-serdes.c | 288 ++++++++++++++++++
include/dt-bindings/phy/phy-ocelot-serdes.h | 19 ++
include/linux/phy/phy.h | 2 +
.../soc}/mscc/ocelot_hsio.h | 74 +++++
17 files changed, 556 insertions(+), 180 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
create mode 100644 drivers/phy/mscc/Kconfig
create mode 100644 drivers/phy/mscc/Makefile
create mode 100644 drivers/phy/mscc/phy-ocelot-serdes.c
create mode 100644 include/dt-bindings/phy/phy-ocelot-serdes.h
rename {drivers/net/ethernet => include/soc}/mscc/ocelot_hsio.h (95%)
--
2.17.1
^ permalink raw reply
* [PATCH v2 01/11] MIPS: mscc: ocelot: make HSIO registers address range a syscon
From: Quentin Schulz @ 2018-09-03 9:32 UTC (permalink / raw)
To: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, f.fainelli
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni, Quentin Schulz
In-Reply-To: <20180903093308.24366-1-quentin.schulz@bootlin.com>
HSIO contains registers for PLL5 configuration, SerDes/switch port
muxing and a thermal sensor, hence we can't keep it in the switch DT
node.
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
arch/mips/boot/dts/mscc/ocelot.dtsi | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/mips/boot/dts/mscc/ocelot.dtsi b/arch/mips/boot/dts/mscc/ocelot.dtsi
index f7eb612b46ba..149b1a7e7091 100644
--- a/arch/mips/boot/dts/mscc/ocelot.dtsi
+++ b/arch/mips/boot/dts/mscc/ocelot.dtsi
@@ -107,7 +107,6 @@
reg = <0x1010000 0x10000>,
<0x1030000 0x10000>,
<0x1080000 0x100>,
- <0x10d0000 0x10000>,
<0x11e0000 0x100>,
<0x11f0000 0x100>,
<0x1200000 0x100>,
@@ -121,10 +120,10 @@
<0x1280000 0x100>,
<0x1800000 0x80000>,
<0x1880000 0x10000>;
- reg-names = "sys", "rew", "qs", "hsio", "port0",
- "port1", "port2", "port3", "port4", "port5",
- "port6", "port7", "port8", "port9", "port10",
- "qsys", "ana";
+ reg-names = "sys", "rew", "qs", "port0", "port1",
+ "port2", "port3", "port4", "port5", "port6",
+ "port7", "port8", "port9", "port10", "qsys",
+ "ana";
interrupts = <21 22>;
interrupt-names = "xtr", "inj";
@@ -231,5 +230,10 @@
pinctrl-0 = <&miim1>;
status = "disabled";
};
+
+ hsio: syscon@10d0000 {
+ compatible = "mscc,ocelot-hsio", "syscon", "simple-mfd";
+ reg = <0x10d0000 0x10000>;
+ };
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 02/11] dt-bindings: net: ocelot: remove hsio from the list of register address spaces
From: Quentin Schulz @ 2018-09-03 9:32 UTC (permalink / raw)
To: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, f.fainelli
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni, Quentin Schulz
In-Reply-To: <20180903093308.24366-1-quentin.schulz@bootlin.com>
HSIO register address space should be handled outside of the MAC
controller as there are some registers for PLL5 configuring,
SerDes/switch port muxing and a thermal sensor IP, so let's remove it.
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
Documentation/devicetree/bindings/mips/mscc.txt | 16 ++++++++++++++++
.../devicetree/bindings/net/mscc-ocelot.txt | 9 +++------
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mips/mscc.txt b/Documentation/devicetree/bindings/mips/mscc.txt
index ae15ec333542..bc817e984628 100644
--- a/Documentation/devicetree/bindings/mips/mscc.txt
+++ b/Documentation/devicetree/bindings/mips/mscc.txt
@@ -41,3 +41,19 @@ Example:
compatible = "mscc,ocelot-cpu-syscon", "syscon";
reg = <0x70000000 0x2c>;
};
+
+o HSIO regs:
+
+The SoC has a few registers (HSIO) handling miscellaneous functionalities:
+configuration and status of PLL5, RCOMP, SyncE, SerDes configurations and
+status, SerDes muxing and a thermal sensor.
+
+Required properties:
+- compatible: Should be "mscc,ocelot-hsio", "syscon", "simple-mfd"
+- reg : Should contain registers location and length
+
+Example:
+ syscon@10d0000 {
+ compatible = "mscc,ocelot-hsio", "syscon", "simple-mfd";
+ reg = <0x10d0000 0x10000>;
+ };
diff --git a/Documentation/devicetree/bindings/net/mscc-ocelot.txt b/Documentation/devicetree/bindings/net/mscc-ocelot.txt
index 0a84711abece..9e5c17d426ce 100644
--- a/Documentation/devicetree/bindings/net/mscc-ocelot.txt
+++ b/Documentation/devicetree/bindings/net/mscc-ocelot.txt
@@ -12,7 +12,6 @@ Required properties:
- "sys"
- "rew"
- "qs"
- - "hsio"
- "qsys"
- "ana"
- "portX" with X from 0 to the number of last port index available on that
@@ -45,7 +44,6 @@ Example:
reg = <0x1010000 0x10000>,
<0x1030000 0x10000>,
<0x1080000 0x100>,
- <0x10d0000 0x10000>,
<0x11e0000 0x100>,
<0x11f0000 0x100>,
<0x1200000 0x100>,
@@ -59,10 +57,9 @@ Example:
<0x1280000 0x100>,
<0x1800000 0x80000>,
<0x1880000 0x10000>;
- reg-names = "sys", "rew", "qs", "hsio", "port0",
- "port1", "port2", "port3", "port4", "port5",
- "port6", "port7", "port8", "port9", "port10",
- "qsys", "ana";
+ reg-names = "sys", "rew", "qs", "port0", "port1", "port2",
+ "port3", "port4", "port5", "port6", "port7",
+ "port8", "port9", "port10", "qsys", "ana";
interrupts = <21 22>;
interrupt-names = "xtr", "inj";
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 03/11] net: mscc: ocelot: get HSIO regmap from syscon
From: Quentin Schulz @ 2018-09-03 9:33 UTC (permalink / raw)
To: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, f.fainelli
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni, Quentin Schulz
In-Reply-To: <20180903093308.24366-1-quentin.schulz@bootlin.com>
HSIO address space was moved to a syscon, hence we need to get the
regmap of this address space from there and no more from the device
node.
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
drivers/net/ethernet/mscc/ocelot_board.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
index 26bb3b18f3be..b7d755b90117 100644
--- a/drivers/net/ethernet/mscc/ocelot_board.c
+++ b/drivers/net/ethernet/mscc/ocelot_board.c
@@ -9,6 +9,7 @@
#include <linux/netdevice.h>
#include <linux/of_mdio.h>
#include <linux/of_platform.h>
+#include <linux/mfd/syscon.h>
#include <linux/skbuff.h>
#include "ocelot.h"
@@ -162,6 +163,7 @@ static int mscc_ocelot_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct device_node *ports, *portnp;
struct ocelot *ocelot;
+ struct regmap *hsio;
u32 val;
struct {
@@ -173,7 +175,6 @@ static int mscc_ocelot_probe(struct platform_device *pdev)
{ QSYS, "qsys" },
{ ANA, "ana" },
{ QS, "qs" },
- { HSIO, "hsio" },
};
if (!np && !pdev->dev.platform_data)
@@ -196,6 +197,14 @@ static int mscc_ocelot_probe(struct platform_device *pdev)
ocelot->targets[res[i].id] = target;
}
+ hsio = syscon_regmap_lookup_by_compatible("mscc,ocelot-hsio");
+ if (IS_ERR(hsio)) {
+ dev_err(&pdev->dev, "missing hsio syscon\n");
+ return PTR_ERR(hsio);
+ }
+
+ ocelot->targets[HSIO] = hsio;
+
err = ocelot_chip_init(ocelot);
if (err)
return err;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 04/11] net: mscc: ocelot: move the HSIO header to include/soc
From: Quentin Schulz @ 2018-09-03 9:33 UTC (permalink / raw)
To: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, f.fainelli
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni, Quentin Schulz
In-Reply-To: <20180903093308.24366-1-quentin.schulz@bootlin.com>
Since HSIO address space can be used by different drivers (PLL, SerDes
muxing, temperature sensor), let's move it somewhere it can be included
by all drivers.
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
drivers/net/ethernet/mscc/ocelot.h | 1 -
drivers/net/ethernet/mscc/ocelot_regs.c | 1 +
{drivers/net/ethernet => include/soc}/mscc/ocelot_hsio.h | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename {drivers/net/ethernet => include/soc}/mscc/ocelot_hsio.h (100%)
diff --git a/drivers/net/ethernet/mscc/ocelot.h b/drivers/net/ethernet/mscc/ocelot.h
index 616bec30dfa3..2da20a352120 100644
--- a/drivers/net/ethernet/mscc/ocelot.h
+++ b/drivers/net/ethernet/mscc/ocelot.h
@@ -16,7 +16,6 @@
#include "ocelot_ana.h"
#include "ocelot_dev.h"
-#include "ocelot_hsio.h"
#include "ocelot_qsys.h"
#include "ocelot_rew.h"
#include "ocelot_sys.h"
diff --git a/drivers/net/ethernet/mscc/ocelot_regs.c b/drivers/net/ethernet/mscc/ocelot_regs.c
index e334b406c40c..bf0c609caea5 100644
--- a/drivers/net/ethernet/mscc/ocelot_regs.c
+++ b/drivers/net/ethernet/mscc/ocelot_regs.c
@@ -5,6 +5,7 @@
* Copyright (c) 2017 Microsemi Corporation
*/
#include "ocelot.h"
+#include <soc/mscc/ocelot_hsio.h>
static const u32 ocelot_ana_regmap[] = {
REG(ANA_ADVLEARN, 0x009000),
diff --git a/drivers/net/ethernet/mscc/ocelot_hsio.h b/include/soc/mscc/ocelot_hsio.h
similarity index 100%
rename from drivers/net/ethernet/mscc/ocelot_hsio.h
rename to include/soc/mscc/ocelot_hsio.h
--
2.17.1
^ permalink raw reply related
* [PATCH v2 06/11] phy: add QSGMII and PCIE modes
From: Quentin Schulz @ 2018-09-03 9:33 UTC (permalink / raw)
To: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, f.fainelli
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni, Quentin Schulz
In-Reply-To: <20180903093308.24366-1-quentin.schulz@bootlin.com>
Prepare for upcoming phys that'll handle QSGMII or PCIe.
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
include/linux/phy/phy.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 9713aebdd348..03b319f89a34 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -37,9 +37,11 @@ enum phy_mode {
PHY_MODE_USB_OTG,
PHY_MODE_SGMII,
PHY_MODE_2500SGMII,
+ PHY_MODE_QSGMII,
PHY_MODE_10GKR,
PHY_MODE_UFS_HS_A,
PHY_MODE_UFS_HS_B,
+ PHY_MODE_PCIE,
};
/**
--
2.17.1
^ permalink raw reply related
* [PATCH v2 07/11] dt-bindings: phy: add DT binding for Microsemi Ocelot SerDes muxing
From: Quentin Schulz @ 2018-09-03 9:33 UTC (permalink / raw)
To: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, f.fainelli
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni, Quentin Schulz
In-Reply-To: <20180903093308.24366-1-quentin.schulz@bootlin.com>
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
.../bindings/phy/phy-ocelot-serdes.txt | 40 +++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt b/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
new file mode 100644
index 000000000000..2a88cc346162
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
@@ -0,0 +1,40 @@
+Microsemi Ocelot SerDes muxing driver
+-------------------------------------
+
+On Microsemi Ocelot, there is a handful of registers in HSIO address
+space for setting up the SerDes to switch port muxing.
+
+A SerDes X can be "muxed" to work with switch port Y or Z for example.
+One specific SerDes can also be used as a PCIe interface.
+
+Hence, a SerDes represents an interface, be it an Ethernet or a PCIe one.
+
+There are two kinds of SerDes: SERDES1G supports 10/100Mbps in
+half/full-duplex and 1000Mbps in full-duplex mode while SERDES6G supports
+10/100Mbps in half/full-duplex and 1000/2500Mbps in full-duplex mode.
+
+Also, SERDES6G number (aka "macro") 0 is the only interface supporting
+QSGMII.
+
+Required properties:
+
+- compatible: should be "mscc,vsc7514-serdes"
+- #phy-cells : from the generic phy bindings, must be 2.
+ The first number defines the input port to use for a given
+ SerDes macro. The second defines the macro to use. They are
+ defined in dt-bindings/phy/phy-ocelot-serdes.h
+
+Example:
+
+ serdes: serdes {
+ compatible = "mscc,vsc7514-serdes";
+ #phy-cells = <2>;
+ };
+
+ ethernet {
+ port1 {
+ phy-handle = <&phy_foo>;
+ /* Link SERDES1G_5 to port1 */
+ phys = <&serdes 1 SERDES1G_5>;
+ };
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH v2 08/11] MIPS: mscc: ocelot: add SerDes mux DT node
From: Quentin Schulz @ 2018-09-03 9:33 UTC (permalink / raw)
To: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, f.fainelli
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni, Quentin Schulz
In-Reply-To: <20180903093308.24366-1-quentin.schulz@bootlin.com>
The Microsemi Ocelot has a set of register for SerDes/switch port muxing
as well as PCIe muxing for a specific SerDes, so let's add the device
and all SerDes in the Device Tree.
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
arch/mips/boot/dts/mscc/ocelot.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/mips/boot/dts/mscc/ocelot.dtsi b/arch/mips/boot/dts/mscc/ocelot.dtsi
index 149b1a7e7091..8ce317c5b9ed 100644
--- a/arch/mips/boot/dts/mscc/ocelot.dtsi
+++ b/arch/mips/boot/dts/mscc/ocelot.dtsi
@@ -234,6 +234,11 @@
hsio: syscon@10d0000 {
compatible = "mscc,ocelot-hsio", "syscon", "simple-mfd";
reg = <0x10d0000 0x10000>;
+
+ serdes: serdes {
+ compatible = "mscc,vsc7514-serdes";
+ #phy-cells = <2>;
+ };
};
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH v2 09/11] dt-bindings: add constants for Microsemi Ocelot SerDes driver
From: Quentin Schulz @ 2018-09-03 9:33 UTC (permalink / raw)
To: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, andrew, f.fainelli
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni, Quentin Schulz
In-Reply-To: <20180903093308.24366-1-quentin.schulz@bootlin.com>
The Microsemi Ocelot has multiple SerDes and requires that the SerDes be
muxed accordingly to the hardware representation.
Let's add a constant for each SerDes available in the Microsemi Ocelot.
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---
include/dt-bindings/phy/phy-ocelot-serdes.h | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 include/dt-bindings/phy/phy-ocelot-serdes.h
diff --git a/include/dt-bindings/phy/phy-ocelot-serdes.h b/include/dt-bindings/phy/phy-ocelot-serdes.h
new file mode 100644
index 000000000000..cf111baa87c8
--- /dev/null
+++ b/include/dt-bindings/phy/phy-ocelot-serdes.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+/* Copyright (c) 2018 Microsemi Corporation */
+#ifndef __PHY_OCELOT_SERDES_H__
+#define __PHY_OCELOT_SERDES_H__
+
+#define SERDES1G_0 0
+#define SERDES1G_1 1
+#define SERDES1G_2 2
+#define SERDES1G_3 3
+#define SERDES1G_4 4
+#define SERDES1G_5 5
+#define SERDES1G_MAX 6
+#define SERDES6G_0 SERDES1G_MAX
+#define SERDES6G_1 (SERDES1G_MAX + 1)
+#define SERDES6G_2 (SERDES1G_MAX + 2)
+#define SERDES6G_MAX (SERDES1G_MAX + 3)
+#define SERDES_MAX (SERDES1G_MAX + SERDES6G_MAX)
+
+#endif
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox