* Re: [PATCH net-next v2 06/13] phy: add 2.5G SGMII mode to the phy_mode enum
From: Russell King - ARM Linux @ 2018-05-08 12:34 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180504135643.23466-7-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 03:56:36PM +0200, Antoine Tenart wrote:
> This patch adds one more generic PHY mode to the phy_mode enum, to allow
> configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
> callback.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Hi,
Would it be possible to get the 2.5G SGMII comphy support merged
ahead of the rest of this series please - I don't think there's been
any objections to it, and having it in mainline would then mean I can
drop the Marvell Comphy code from my tree and transition to the bootlin
Comphy code instead.
Of course, the perfect solution would be to get the whole series merged,
but I'm just thinking about the situation where we're still discussing
points when the next merge window opens.
Thanks.
> ---
> include/linux/phy/phy.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index c9d14eeee7f5..9713aebdd348 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -36,6 +36,7 @@ enum phy_mode {
> PHY_MODE_USB_DEVICE_SS,
> PHY_MODE_USB_OTG,
> PHY_MODE_SGMII,
> + PHY_MODE_2500SGMII,
> PHY_MODE_10GKR,
> PHY_MODE_UFS_HS_A,
> PHY_MODE_UFS_HS_B,
> --
> 2.17.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given
From: Russell King - ARM Linux @ 2018-05-08 12:30 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180504152103.18152-1-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 05:21:03PM +0200, Antoine Tenart wrote:
> When computing the bitrate using values read from an SFP module EEPROM,
> we use the nominal BR plus BR,min and BR,max to determine the
> boundaries. But in some cases BR,min and BR,max aren't provided, which
> led the SFP code to end up having the nominal value for both the minimum
> and maximum bitrate values. When using a passive cable, the nominal
> value should be used as the maximum one, and there is no minimum one
> so we should use 0.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> ---
>
> Hi Russell,
>
> I'm not completely sure about this patch as this case is not really
> specified in the specification. But the issue is there, and I've discuss
> this with others. It seemed logical (at least to us :)) to use the
> BR,nominal values as br_max and 0 as br_min when using a passive cable
> which only provides BR,nominal as this would be the highest rate at
> which the cable could work. And because it's passive, there should be no
> issues using it at a lower rate.
>
> I've tested this with one passive cable which only reports its
> BR,nominal (which was 10300) while it could be used when using 1000baseX
> or 2500baseX modes.
The electronic engineer in me says that using zero isn't really valid
because there are coupling capacitors in the SFP module that block DC.
These blocking capacitors are required by the SFP+ specs to have a high
pass pole of between 20kHz and 100kHz - in other words, frequencies
below this are attenuated by the coupling capacitors. The relationship
between this and the bit rate will be a function of the encoding, so we
can't come to a definitive figure without some math (and I want to be
lazy about that!)
Practically, we're talking about SerDes Ethernet, where the bit rate is
no lower than 100Mbps [*], which will always have a frequency well above
this cut-off. So, I don't have any problem with your approach to
setting the minimum to zero. Therefore,
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Please send me the EEPROM dump using:
ethtool -m <ethernetdevice> raw on > foo.bin
so I can add it to my database for future testing and validation.
Thanks.
* - 10Mbps SGMII is 1Gbps SGMII with each bit repeated 100 times.
100Mbps SGMII is 1Gbps SGMII with each bit repeated 10 times.
There is a capability bits for transceivers supporting
100base-FX/LX but no one has tested those yet.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net] bridge: netfilter stp fix reference to uninitialized data
From: Pablo Neira Ayuso @ 2018-05-08 12:17 UTC (permalink / raw)
To: Stephen Hemminger
Cc: kadlec, fw, davem, netfilter-devel, bridge, netdev,
Stephen Hemminger
In-Reply-To: <20180427181609.3103-1-sthemmin@microsoft.com>
On Fri, Apr 27, 2018 at 11:16:09AM -0700, Stephen Hemminger wrote:
> The destination mac (destmac) is only valid if EBT_DESTMAC flag
> is set. Fix by changing the order of the comparison to look for
> the flag first.
Applied, thanks Stephen.
^ permalink raw reply
* Re: INFO: rcu detected stall in sctp_generate_heartbeat_event
From: Marcelo Ricardo Leitner @ 2018-05-08 12:06 UTC (permalink / raw)
To: syzbot
Cc: davem, linux-kernel, linux-sctp, netdev, nhorman, syzkaller-bugs,
vyasevich
In-Reply-To: <000000000000062c1c056bacd39f@google.com>
On Tue, May 08, 2018 at 12:35:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 90278871d4b0 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=119a7237800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=aea320d3af5ef99d
> dashboard link: https://syzkaller.appspot.com/bug?extid=e4a5bbd54260c93014f9
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
A reproducer will be welcomed. With just these traces, I don't think
we have enough information.
Marcelo
^ permalink raw reply
* Re: [PATCH net] net: phy: sfp: fix the BR,min computation
From: Russell King - ARM Linux @ 2018-05-08 12:05 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180504151054.17525-1-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 05:10:54PM +0200, Antoine Tenart wrote:
> In an SFP EEPROM values can be read to get information about a given SFP
> module. One of those is the bitrate, which can be determined using a
> nominal bitrate in addition with min and max values (in %). The SFP code
> currently compute both BR,min and BR,max values thanks to this nominal
> and min,max values.
>
> This patch fixes the BR,min computation as the min value should be
> subtracted to the nominal one, not added.
>
> Fixes: 9962acf7fb8c ("sfp: add support for 1000Base-PX and 1000Base-BX10")
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
I know David has already applied it, but for the record, your fix looks
correct, thanks.
> ---
> drivers/net/phy/sfp-bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
> index 0381da78d228..fd6c23f69c2f 100644
> --- a/drivers/net/phy/sfp-bus.c
> +++ b/drivers/net/phy/sfp-bus.c
> @@ -125,7 +125,7 @@ void sfp_parse_support(struct sfp_bus *bus, const struct sfp_eeprom_id *id,
> if (id->base.br_nominal) {
> if (id->base.br_nominal != 255) {
> br_nom = id->base.br_nominal * 100;
> - br_min = br_nom + id->base.br_nominal * id->ext.br_min;
> + br_min = br_nom - id->base.br_nominal * id->ext.br_min;
> br_max = br_nom + id->base.br_nominal * id->ext.br_max;
> } else if (id->ext.br_max) {
> br_nom = 250 * id->ext.br_max;
> --
> 2.17.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [iproute-next v2] tipc: Add support to set and get MTU for UDP bearer
From: GhantaKrishnamurthy MohanKrishna @ 2018-05-08 11:55 UTC (permalink / raw)
To: tipc-discussion, jon.maloy, maloy, ying.xue,
mohan.krishna.ghanta.krishnamurthy, netdev, stephen, dsahern
In this commit we introduce the ability to set and get
MTU for UDP media and bearer.
For set and get properties such as tolerance, window and priority,
we already do:
$ tipc media set PPROPERTY media MEDIA
$ tipc media get PPROPERTY media MEDIA
$ tipc bearer set OPTION media MEDIA ARGS
$ tipc bearer get [OPTION] media MEDIA ARGS
The same has been extended for MTU, with an exception to support
only media type UDP.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: GhantaKrishnamurthy MohanKrishna <mohan.krishna.ghanta.krishnamurthy@ericsson.com>
---
tipc/bearer.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++---------
tipc/media.c | 24 ++++++++++++++++++++++--
2 files changed, 68 insertions(+), 11 deletions(-)
diff --git a/tipc/bearer.c b/tipc/bearer.c
index 0d8457015062..05dc84aa8ded 100644
--- a/tipc/bearer.c
+++ b/tipc/bearer.c
@@ -42,7 +42,8 @@ static void _print_bearer_opts(void)
"OPTIONS\n"
" priority - Bearer link priority\n"
" tolerance - Bearer link tolerance\n"
- " window - Bearer link window\n");
+ " window - Bearer link window\n"
+ " mtu - Bearer link mtu\n");
}
void print_bearer_media(void)
@@ -194,6 +195,21 @@ static int nl_add_udp_enable_opts(struct nlmsghdr *nlh, struct opt *opts,
return 0;
}
+static char *cmd_get_media_type(const struct cmd *cmd, struct cmdl *cmdl,
+ struct opt *opts)
+{
+ struct opt *opt = get_opt(opts, "media");
+
+ if (!opt) {
+ if (help_flag)
+ (cmd->help)(cmdl);
+ else
+ fprintf(stderr, "error, missing bearer media\n");
+ return NULL;
+ }
+ return opt->val;
+}
+
static int nl_add_bearer_name(struct nlmsghdr *nlh, const struct cmd *cmd,
struct cmdl *cmdl, struct opt *opts,
const struct tipc_sup_media *sup_media)
@@ -217,15 +233,8 @@ int cmd_get_unique_bearer_name(const struct cmd *cmd, struct cmdl *cmdl,
struct opt *opt;
const struct tipc_sup_media *entry;
-
- if (!(opt = get_opt(opts, "media"))) {
- if (help_flag)
- (cmd->help)(cmdl);
- else
- fprintf(stderr, "error, missing bearer media\n");
+ if (!(media = cmd_get_media_type(cmd, cmdl, opts)))
return -EINVAL;
- }
- media = opt->val;
for (entry = sup_media; entry->media; entry++) {
if (strcmp(entry->media, media))
@@ -559,6 +568,8 @@ static int cmd_bearer_set_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
prop = TIPC_NLA_PROP_TOL;
else if ((strcmp(cmd->cmd, "window") == 0))
prop = TIPC_NLA_PROP_WIN;
+ else if ((strcmp(cmd->cmd, "mtu") == 0))
+ prop = TIPC_NLA_PROP_MTU;
else
return -EINVAL;
@@ -571,6 +582,17 @@ static int cmd_bearer_set_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
if (parse_opts(opts, cmdl) < 0)
return -EINVAL;
+ if (prop == TIPC_NLA_PROP_MTU) {
+ char *media = cmd_get_media_type(cmd, cmdl, opts);
+
+ if (!media)
+ return -EINVAL;
+ else if (strcmp(media, "udp")) {
+ fprintf(stderr, "error, not supported for media\n");
+ return -EINVAL;
+ }
+ }
+
if (!(nlh = msg_init(buf, TIPC_NL_BEARER_SET))) {
fprintf(stderr, "error, message initialisation failed\n");
return -1;
@@ -597,6 +619,7 @@ static int cmd_bearer_set(struct nlmsghdr *nlh, const struct cmd *cmd,
{ "priority", cmd_bearer_set_prop, cmd_bearer_set_help },
{ "tolerance", cmd_bearer_set_prop, cmd_bearer_set_help },
{ "window", cmd_bearer_set_prop, cmd_bearer_set_help },
+ { "mtu", cmd_bearer_set_prop, cmd_bearer_set_help },
{ NULL }
};
@@ -877,12 +900,25 @@ static int cmd_bearer_get_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
prop = TIPC_NLA_PROP_TOL;
else if ((strcmp(cmd->cmd, "window") == 0))
prop = TIPC_NLA_PROP_WIN;
+ else if ((strcmp(cmd->cmd, "mtu") == 0))
+ prop = TIPC_NLA_PROP_MTU;
else
return -EINVAL;
if (parse_opts(opts, cmdl) < 0)
return -EINVAL;
+ if (prop == TIPC_NLA_PROP_MTU) {
+ char *media = cmd_get_media_type(cmd, cmdl, opts);
+
+ if (!media)
+ return -EINVAL;
+ else if (strcmp(media, "udp")) {
+ fprintf(stderr, "error, not supported for media\n");
+ return -EINVAL;
+ }
+ }
+
if (!(nlh = msg_init(buf, TIPC_NL_BEARER_GET))) {
fprintf(stderr, "error, message initialisation failed\n");
return -1;
@@ -904,6 +940,7 @@ static int cmd_bearer_get(struct nlmsghdr *nlh, const struct cmd *cmd,
{ "priority", cmd_bearer_get_prop, cmd_bearer_get_help },
{ "tolerance", cmd_bearer_get_prop, cmd_bearer_get_help },
{ "window", cmd_bearer_get_prop, cmd_bearer_get_help },
+ { "mtu", cmd_bearer_get_prop, cmd_bearer_get_help },
{ "media", cmd_bearer_get_media, cmd_bearer_get_help },
{ NULL }
};
diff --git a/tipc/media.c b/tipc/media.c
index 6e10c7e5d8e6..969ef6578b3b 100644
--- a/tipc/media.c
+++ b/tipc/media.c
@@ -103,6 +103,8 @@ static int cmd_media_get_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
prop = TIPC_NLA_PROP_TOL;
else if ((strcmp(cmd->cmd, "window") == 0))
prop = TIPC_NLA_PROP_WIN;
+ else if ((strcmp(cmd->cmd, "mtu") == 0))
+ prop = TIPC_NLA_PROP_MTU;
else
return -EINVAL;
@@ -123,6 +125,12 @@ static int cmd_media_get_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
fprintf(stderr, "error, missing media\n");
return -EINVAL;
}
+
+ if ((prop == TIPC_NLA_PROP_MTU) &&
+ (strcmp(opt->val, "udp"))) {
+ fprintf(stderr, "error, not supported for media\n");
+ return -EINVAL;
+ }
nest = mnl_attr_nest_start(nlh, TIPC_NLA_MEDIA);
mnl_attr_put_strz(nlh, TIPC_NLA_MEDIA_NAME, opt->val);
mnl_attr_nest_end(nlh, nest);
@@ -136,7 +144,8 @@ static void cmd_media_get_help(struct cmdl *cmdl)
"PROPERTIES\n"
" tolerance - Get media tolerance\n"
" priority - Get media priority\n"
- " window - Get media window\n",
+ " window - Get media window\n"
+ " mtu - Get media mtu\n",
cmdl->argv[0]);
}
@@ -147,6 +156,7 @@ static int cmd_media_get(struct nlmsghdr *nlh, const struct cmd *cmd,
{ "priority", cmd_media_get_prop, cmd_media_get_help },
{ "tolerance", cmd_media_get_prop, cmd_media_get_help },
{ "window", cmd_media_get_prop, cmd_media_get_help },
+ { "mtu", cmd_media_get_prop, cmd_media_get_help },
{ NULL }
};
@@ -159,7 +169,8 @@ static void cmd_media_set_help(struct cmdl *cmdl)
"PROPERTIES\n"
" tolerance TOLERANCE - Set media tolerance\n"
" priority PRIORITY - Set media priority\n"
- " window WINDOW - Set media window\n",
+ " window WINDOW - Set media window\n"
+ " mtu MTU - Set media mtu\n",
cmdl->argv[0]);
}
@@ -183,6 +194,8 @@ static int cmd_media_set_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
prop = TIPC_NLA_PROP_TOL;
else if ((strcmp(cmd->cmd, "window") == 0))
prop = TIPC_NLA_PROP_WIN;
+ else if ((strcmp(cmd->cmd, "mtu") == 0))
+ prop = TIPC_NLA_PROP_MTU;
else
return -EINVAL;
@@ -210,6 +223,12 @@ static int cmd_media_set_prop(struct nlmsghdr *nlh, const struct cmd *cmd,
fprintf(stderr, "error, missing media\n");
return -EINVAL;
}
+
+ if ((prop == TIPC_NLA_PROP_MTU) &&
+ (strcmp(opt->val, "udp"))) {
+ fprintf(stderr, "error, not supported for media\n");
+ return -EINVAL;
+ }
mnl_attr_put_strz(nlh, TIPC_NLA_MEDIA_NAME, opt->val);
props = mnl_attr_nest_start(nlh, TIPC_NLA_MEDIA_PROP);
@@ -228,6 +247,7 @@ static int cmd_media_set(struct nlmsghdr *nlh, const struct cmd *cmd,
{ "priority", cmd_media_set_prop, cmd_media_set_help },
{ "tolerance", cmd_media_set_prop, cmd_media_set_help },
{ "window", cmd_media_set_prop, cmd_media_set_help },
+ { "mtu", cmd_media_set_prop, cmd_media_set_help },
{ NULL }
};
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available
From: Russell King - ARM Linux @ 2018-05-08 11:53 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180504135643.23466-4-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 03:56:33PM +0200, Antoine Tenart wrote:
> In case no Tx disable pin is available the SFP modules will always be
> emitting. This could be an issue when using modules using laser as their
> light source as we would have no way to disable it when the fiber is
> removed. This patch adds a warning when registering an SFP cage which do
> not have its tx_disable pin wired or available.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Looks fine, thanks.
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> drivers/net/phy/sfp.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> index 8e323a4b70da..d4f503b2e3e2 100644
> --- a/drivers/net/phy/sfp.c
> +++ b/drivers/net/phy/sfp.c
> @@ -1093,6 +1093,15 @@ static int sfp_probe(struct platform_device *pdev)
> if (!sfp->gpio[GPIO_MODDEF0] && !sfp->gpio[GPIO_LOS])
> sfp->sm_dev_state = SFP_DEV_UNKNOWN;
>
> + /* We could have an issue in cases no Tx disable pin is available or
> + * wired as modules using a laser as their light source will continue to
> + * be active when the fiber is removed. This could be a safety issue and
> + * we should at least warn the user about that.
> + */
> + if (!sfp->gpio[GPIO_TX_DISABLE])
> + dev_warn(sfp->dev,
> + "No tx_disable pin: SFP modules will always be emitting.\n");
> +
> return 0;
> }
>
> --
> 2.17.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors
From: Russell King - ARM Linux @ 2018-05-08 11:52 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180504135643.23466-3-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 03:56:32PM +0200, Antoine Tenart wrote:
> SFP connectors can be solder on a board without having any of their pins
> (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed,
> and the overall link status reporting is left to other layers.
>
> In order to achieve this, a new SFP_DEV status is added, named UNKNOWN.
> This mode is set when it is not possible for the SFP code to get the
> link status and as a result the link status is reported to be always UP
> from the SFP point of view.
This looks weird to me. SFP_DEV_* states track the netdevice up/down
state and have little to do with whether LOS or MODDEF0 are implemented.
I think it would be better to have a new SFP_MOD_* and to force
sm_mod_state to that in this circumstance.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [RFC/PATCH] Add a socketoption IPV6_MULTICAST_ALL analogue to the IPV4 version
From: 吉藤英明 @ 2018-05-08 11:48 UTC (permalink / raw)
To: Andre Naujoks; +Cc: David S. Miller, netdev, yoshfuji
In-Reply-To: <3600af24-8938-a55f-f67f-2306c4c3ac2b@gmail.com>
Hi,
2018-05-08 15:41 GMT+09:00 Andre Naujoks <nautsch2@gmail.com>:
> On 08.05.2018 08:31, 吉藤英明 wrote:
>> Hi,
>>
>> 2018-05-08 15:03 GMT+09:00 Andre Naujoks <nautsch2@gmail.com>:
>>> On 11.04.2018 13:02, Andre Naujoks wrote:
>>>> Hi.
>>>
>>> Hi again.
>>>
>>> Since it has been a month now, I'd like to send a little "ping" on this subject.
>>>
>>> Is anything wrong with this? Or was it just bad timing?
>>
>> I'm just curious... What kind of behaviour do you expect?
>>
>> Unless you explicitly join the group, you cannot get traffic for the group
>> because of multicast filtering at device level (multicast fitlering) or at the
>> switch level (MLD).
>>
>> If an application is interested in (several) multicast groups, it should
>> explicitly join the group. So I cannot find valid (or meaningful) use-case.
>
> I expect only to receive the multicast traffic of groups I explicitly joined on that
> socket. This is was the IPv4 version of this socket option already does. The problem
> only exists if multiple groups are joined and the socket therefore has to be bound
> to the "any"-address. Then we get traffic from all multicast groups joined by any(!)
> process on the system (plus anything else on that IP-port).
Okay I agree that we should be able NOT to get such traffic.
Acked-By: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
--yoshfuji
>
> Regards
> Andre
>
>>
>> --yoshfuji
>>
>>>
>>> Regards
>>> Andre
>>>
>>>>
>>>> I was running into a problem, when trying to join multiple multicast groups
>>>> on a single socket and thus binding to the any-address on said socket. I
>>>> received traffic from multicast groups, I did not join on that socket and
>>>> was at first surprised by that. After reading some old e-mails/threads,
>>>> which came to the conclusion "It is, as it is."
>>>> (e.g https://marc.info/?l=linux-kernel&m=115815686626791&w=2), I discovered
>>>> the IPv4 socketoption IP_MULTICAST_ALL, which, when disabled, does exactly
>>>> what I would expect from a socket by default.
>>>>
>>>> I propose a socket option for IPv6, which does the same and has the same
>>>> default as the IPv4 version. My first thought was, to just apply
>>>> IP_MULTICAST_ALL to a ipv6 socket, but that would change the behavior of
>>>> current applications and would probably be a big no-no.
>>>>
>>>> Regards
>>>> Andre
>>>>
>>>>
>>>> From 473653086c05a3de839c3504885053f6254c7bc5 Mon Sep 17 00:00:00 2001
>>>> From: Andre Naujoks <nautsch2@gmail.com>
>>>> Date: Wed, 11 Apr 2018 12:38:28 +0200
>>>> Subject: [PATCH] Add a socketoption IPV6_MULTICAST_ALL analogue to the IPV4
>>>> version
>>>>
>>>> The socket option will be enabled by default to ensure current behaviour
>>>> is not changed. This is the same for the IPv4 version.
>>>>
>>>> A socket bound to in6addr_any and a specific port will receive all traffic
>>>> on that port. Analogue to IP_MULTICAST_ALL, disable this behaviour, if
>>>> one or more multicast groups were joined (using said socket) and only
>>>> pass on multicast traffic from groups, which were explicitly joined via
>>>> this socket.
>>>>
>>>> Without this option disabled a socket (system even) joined to multiple
>>>> multicast groups is very hard to get right. Filtering by destination
>>>> address has to take place in user space to avoid receiving multicast
>>>> traffic from other multicast groups, which might have traffic on the same
>>>> port.
>>>>
>>>> The extension of the IP_MULTICAST_ALL socketoption to just apply to ipv6,
>>>> too, is not done to avoid changing the behaviour of current applications.
>>>>
>>>> Signed-off-by: Andre Naujoks <nautsch2@gmail.com>
>>>> ---
>>>> include/linux/ipv6.h | 3 ++-
>>>> include/uapi/linux/in6.h | 1 +
>>>> net/ipv6/af_inet6.c | 1 +
>>>> net/ipv6/ipv6_sockglue.c | 11 +++++++++++
>>>> net/ipv6/mcast.c | 2 +-
>>>> 5 files changed, 16 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
>>>> index 8415bf1a9776..495e834c1367 100644
>>>> --- a/include/linux/ipv6.h
>>>> +++ b/include/linux/ipv6.h
>>>> @@ -274,7 +274,8 @@ struct ipv6_pinfo {
>>>> */
>>>> dontfrag:1,
>>>> autoflowlabel:1,
>>>> - autoflowlabel_set:1;
>>>> + autoflowlabel_set:1,
>>>> + mc_all:1;
>>>> __u8 min_hopcount;
>>>> __u8 tclass;
>>>> __be32 rcv_flowinfo;
>>>> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
>>>> index ed291e55f024..71d82fe15b03 100644
>>>> --- a/include/uapi/linux/in6.h
>>>> +++ b/include/uapi/linux/in6.h
>>>> @@ -177,6 +177,7 @@ struct in6_flowlabel_req {
>>>> #define IPV6_V6ONLY 26
>>>> #define IPV6_JOIN_ANYCAST 27
>>>> #define IPV6_LEAVE_ANYCAST 28
>>>> +#define IPV6_MULTICAST_ALL 29
>>>>
>>>> /* IPV6_MTU_DISCOVER values */
>>>> #define IPV6_PMTUDISC_DONT 0
>>>> diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
>>>> index 8da0b513f188..7844cd9d2f10 100644
>>>> --- a/net/ipv6/af_inet6.c
>>>> +++ b/net/ipv6/af_inet6.c
>>>> @@ -209,6 +209,7 @@ static int inet6_create(struct net *net, struct socket *sock, int protocol,
>>>> np->hop_limit = -1;
>>>> np->mcast_hops = IPV6_DEFAULT_MCASTHOPS;
>>>> np->mc_loop = 1;
>>>> + np->mc_all = 1;
>>>> np->pmtudisc = IPV6_PMTUDISC_WANT;
>>>> np->repflow = net->ipv6.sysctl.flowlabel_reflect;
>>>> sk->sk_ipv6only = net->ipv6.sysctl.bindv6only;
>>>> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
>>>> index 4d780c7f0130..b2bc1942a2ee 100644
>>>> --- a/net/ipv6/ipv6_sockglue.c
>>>> +++ b/net/ipv6/ipv6_sockglue.c
>>>> @@ -664,6 +664,13 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
>>>> retv = ipv6_sock_ac_drop(sk, mreq.ipv6mr_ifindex, &mreq.ipv6mr_acaddr);
>>>> break;
>>>> }
>>>> + case IPV6_MULTICAST_ALL:
>>>> + if (optlen < sizeof(int))
>>>> + goto e_inval;
>>>> + np->mc_all = valbool;
>>>> + retv = 0;
>>>> + break;
>>>> +
>>>> case MCAST_JOIN_GROUP:
>>>> case MCAST_LEAVE_GROUP:
>>>> {
>>>> @@ -1255,6 +1262,10 @@ static int do_ipv6_getsockopt(struct sock *sk, int level, int optname,
>>>> val = np->mcast_oif;
>>>> break;
>>>>
>>>> + case IPV6_MULTICAST_ALL:
>>>> + val = np->mc_all;
>>>> + break;
>>>> +
>>>> case IPV6_UNICAST_IF:
>>>> val = (__force int)htonl((__u32) np->ucast_oif);
>>>> break;
>>>> diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
>>>> index 793159d77d8a..623ad00eb3c2 100644
>>>> --- a/net/ipv6/mcast.c
>>>> +++ b/net/ipv6/mcast.c
>>>> @@ -622,7 +622,7 @@ bool inet6_mc_check(struct sock *sk, const struct in6_addr *mc_addr,
>>>> }
>>>> if (!mc) {
>>>> rcu_read_unlock();
>>>> - return true;
>>>> + return np->mc_all;
>>>> }
>>>> read_lock(&mc->sflock);
>>>> psl = mc->sflist;
>>>>
>>>
>
^ permalink raw reply
* Re: [PATCH v2] net: dsa: drop some VLAs in switch.c
From: Salvatore Mesoraca @ 2018-05-08 10:32 UTC (permalink / raw)
To: David Laight
Cc: Florian Fainelli, Andrew Lunn, linux-kernel@vger.kernel.org,
Kernel Hardening, netdev@vger.kernel.org, David S. Miller,
Kees Cook, Vivien Didelot
In-Reply-To: <f733e4630e424e0aaf402d5d840cb6e2@AcuMS.aculab.com>
2018-05-08 11:39 GMT+02:00 David Laight <David.Laight@aculab.com>:
> From: Salvatore Mesoraca
>> Sent: 07 May 2018 20:03
> ...
>> This optimization will save us an allocation when number of ports is
>> less than 32 or 64 (depending on arch).
>> IMHO it's useful, if you consider that, right now, DSA works only with
>> 12-ports switches.
>
> Why not just error out if the number of ports is greater than the compile-time
> limit?
>
> Worry about dynamic allocation if you need a lot more than 64 ports.
v1 has been NAK-ed by maintainers because they don't want limits on how
many ports a switch can have.
Salvatore
^ permalink raw reply
* Re: [PATCH v2] net: dsa: drop some VLAs in switch.c
From: Salvatore Mesoraca @ 2018-05-08 10:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, linux-kernel, Kernel Hardening, netdev,
David S. Miller, Kees Cook, Vivien Didelot, David Laight
In-Reply-To: <20180507192641.GD31021@lunn.ch>
2018-05-07 21:26 GMT+02:00 Andrew Lunn <andrew@lunn.ch>:
>> >> +++ b/include/net/dsa.h
>> >> @@ -256,6 +256,9 @@ struct dsa_switch {
>> >> /* Number of switch port queues */
>> >> unsigned int num_tx_queues;
>> >>
>> >> + unsigned long *bitmap;
>> >> + unsigned long _bitmap;
>> >> +
>> >> /* Dynamically allocated ports, keep last */
>> >> size_t num_ports;
>> >> struct dsa_port ports[];
>> >> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
>> >> index adf50fb..cebf35f0 100644
>> >> --- a/net/dsa/dsa2.c
>> >> +++ b/net/dsa/dsa2.c
>> >> @@ -748,6 +748,20 @@ struct dsa_switch *dsa_switch_alloc(struct device *dev, size_t n)
>> >> if (!ds)
>> >> return NULL;
>> >>
>> >> + /* We avoid allocating memory outside dsa_switch
>> >> + * if it is not needed.
>> >> + */
>> >> + if (n <= sizeof(ds->_bitmap) * 8) {
>> >> + ds->bitmap = &ds->_bitmap;
>> >
>> > Should not this be / BITS_PER_BYTE? If the sizeof(unsigned long) is <=
>> > 8, then you don't need to allocate it, otherwise, you have to.
>
>> This optimization will save us an allocation when number of ports is
>> less than 32 or 64 (depending on arch).
>> IMHO it's useful, if you consider that, right now, DSA works only with
>> 12-ports switches.
>
> Do you have a feeling for the savings? I don't see it being very
> large, and given the extra code, it might actually be negative.
I think that a "compare" and a "jump" costs nothing compared to
devm_kmalloc, its eventual free, and, *maybe*, the cache miss you
get every time you access the bitmask.
This is not necessarily relevant if this code it's invoked rarely,
but, IMHO, it seems strange to always go for dynamic allocation for
something that will be, almost always, as big as a pointer.
Salvatore
^ permalink raw reply
* Re: [PATCH net-next] net:sched: add gkprio scheduler
From: Nishanth Devarajan @ 2018-05-08 10:12 UTC (permalink / raw)
To: Cong Wang; +Cc: jiri, jhs, davem, netdev, doucette, michel
In-Reply-To: <CAM_iQpUpVdgQ+ED+Mbzpz6NZLQjzPR+vKcS5Zgv1F+_xysCQcg@mail.gmail.com>
On Mon, May 07, 2018 at 10:24:51PM -0700, Cong Wang wrote:
> On Mon, May 7, 2018 at 2:36 AM, Nishanth Devarajan <ndev2021@gmail.com> wrote:
> > net/sched: add gkprio scheduler
> >
> > Gkprio (Gatekeeper Priority Queue) is a queueing discipline that prioritizes
> > IPv4 and IPv6 packets accordingly to their DSCP field. Although Gkprio can be
> > employed in any QoS scenario in which a higher DSCP field means a higher
> > priority packet, Gkprio was concieved as a solution for denial-of-service
> > defenses that need to route packets with different priorities.
>
>
> Can we give it a better name? "Gatekeeper" is meaningless if we read
> it alone, it ties to your Gatekeeper project which is more than just this
> kernel module. Maybe "DS Priority Queue"?
>
Yes, we should be able to come up with a better name, we'll work on it.
> Overall it looks good to me, just one thing below:
>
> > +struct Qdisc_ops gkprio_qdisc_ops __read_mostly = {
> > + .id = "gkprio",
> > + .priv_size = sizeof(struct gkprio_sched_data),
> > + .enqueue = gkprio_enqueue,
> > + .dequeue = gkprio_dequeue,
> > + .peek = qdisc_peek_dequeued,
> > + .init = gkprio_init,
> > + .reset = gkprio_reset,
> > + .change = gkprio_change,
> > + .dump = gkprio_dump,
> > + .destroy = gkprio_destroy,
> > + .owner = THIS_MODULE,
> > +};
>
> You probably want to add Qdisc_class_ops here so that you can
> dump the stats of each internal queue.
Alright, will make some changes and send in a v2.
Thanks,
Nishanth
^ permalink raw reply
* Re: [RFC PATCH 2/3] arcnet: com20020: Fixup missing SLOWARB bit
From: Andrea Greco @ 2018-05-08 9:52 UTC (permalink / raw)
To: Tobin C. Harding; +Cc: m.grzeschik, Andrea Greco, netdev, linux-kernel
In-Reply-To: <20180507025556.GG4197@eros>
On 05/07/2018 04:55 AM, Tobin C. Harding wrote:
> On Sat, May 05, 2018 at 11:37:54PM +0200, Andrea Greco wrote:
>> From: Andrea Greco <a.greco@4sigma.it>
>>
>> If com20020 clock is major of 40Mhz SLOWARB bit is requested.
>>
>> Signed-off-by: Andrea Greco <a.greco@4sigma.it>
>> ---
>> drivers/net/arcnet/com20020.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
>> index f09ea77dd6a8..abd32ed8ec9b 100644
>> --- a/drivers/net/arcnet/com20020.c
>> +++ b/drivers/net/arcnet/com20020.c
>> @@ -102,6 +102,10 @@ int com20020_check(struct net_device *dev)
>> lp->setup = lp->clockm ? 0 : (lp->clockp << 1);
>> lp->setup2 = (lp->clockm << 4) | 8;
>>
>> + // If clock is major of 40Mhz, SLOWARB bit must be set
>
> /* C89 style comments please :) */
>
Done
>
> Hope this helps,
> Tobin.
>
^ permalink raw reply
* оферта
From: Пламен Маринова @ 2018-05-08 9:06 UTC (permalink / raw)
To: ми
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
Добро утро,
Дайте ни най-добрите цени за приложените материали. бихме искали да
знаем наличността сега.
Благодаря ти !!
Пламен Маринова
Maticskeeline Tradings
+3597469947
София, България
[-- Attachment #2: Scan_оферта_645987645doc.jar --]
[-- Type: application/jar, Size: 866397 bytes --]
^ permalink raw reply
* Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring
From: Tiwei Bie @ 2018-05-08 9:44 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, virtualization, linux-kernel, netdev, wexu,
jfreimann
In-Reply-To: <122277c6-d103-e1f6-d695-4d64e6934a51@redhat.com>
On Tue, May 08, 2018 at 05:34:40PM +0800, Jason Wang wrote:
> On 2018年05月08日 17:16, Tiwei Bie wrote:
> > On Tue, May 08, 2018 at 03:16:53PM +0800, Jason Wang wrote:
> > > On 2018年05月08日 14:44, Tiwei Bie wrote:
> > > > On Tue, May 08, 2018 at 01:40:40PM +0800, Jason Wang wrote:
> > > > > On 2018年05月08日 11:05, Jason Wang wrote:
> > > > > > > Because in virtqueue_enable_cb_delayed(), we may set an
> > > > > > > event_off which is bigger than new and both of them have
> > > > > > > wrapped. And in this case, although new is smaller than
> > > > > > > event_off (i.e. the third param -- old), new shouldn't
> > > > > > > add vq->num, and actually we are expecting a very big
> > > > > > > idx diff.
> > > > > > Yes, so to calculate distance correctly between event and new, we just
> > > > > > need to compare the warp counter and return false if it doesn't match
> > > > > > without the need to try to add vq.num here.
> > > > > >
> > > > > > Thanks
> > > > > Sorry, looks like the following should work, we need add vq.num if
> > > > > used_wrap_counter does not match:
> > > > >
> > > > > static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
> > > > > __u16 off_wrap, __u16 new,
> > > > > __u16 old)
> > > > > {
> > > > > bool wrap = off_wrap >> 15;
> > > > > int off = off_wrap & ~(1 << 15);
> > > > > __u16 d1, d2;
> > > > >
> > > > > if (wrap != vq->used_wrap_counter)
> > > > > d1 = new + vq->num - off - 1;
> > > > Just to draw your attention (maybe you have already
> > > > noticed this).
> > > I miss this, thanks!
> > >
> > > > In this case (i.e. wrap != vq->used_wrap_counter),
> > > > it's also possible that (off < new) is true. Because,
> > > >
> > > > when virtqueue_enable_cb_delayed_packed() is used,
> > > > `off` is calculated in driver in a way like this:
> > > >
> > > > off = vq->last_used_idx + bufs;
> > > > if (off >= vq->vring_packed.num) {
> > > > off -= vq->vring_packed.num;
> > > > wrap_counter ^= 1;
> > > > }
> > > >
> > > > And when `new` (in vhost) is close to vq->num. The
> > > > vq->last_used_idx + bufs (in driver) can be bigger
> > > > than vq->vring_packed.num, and:
> > > >
> > > > 1. `off` will wrap;
> > > > 2. wrap counters won't match;
> > > > 3. off < new;
> > > >
> > > > And d1 (i.e. new + vq->num - off - 1) will be a value
> > > > bigger than vq->num. I'm okay with this, although it's
> > > > a bit weird.
> > >
> > > So I'm considering something more compact by reusing vring_need_event() by
> > > pretending a larger queue size and adding vq->num back when necessary:
> > >
> > > static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
> > > __u16 off_wrap, __u16 new,
> > > __u16 old)
> > > {
> > > bool wrap = vq->used_wrap_counter;
> > If the wrap counter is obtained from the vq,
> > I think `new` should also be obtained from
> > the vq. Or the wrap counter should be carried
> > in `new`.
> >
> > > int off = off_wrap & ~(1 << 15);
> > > __u16 d1, d2;
> > >
> > > if (new < old) {
> > > new += vq->num;
> > > wrap ^= 1;
> > > }
> > >
> > > if (wrap != off_wrap >> 15)
> > > off += vq->num;
> > When `new` and `old` wraps, and `off` doesn't wrap,
> > wrap != (off_wrap >> 15) will be true. In this case,
> > `off` is bigger than `new`, and what we should do
> > is `off -= vq->num` instead of `off += vq->num`.
>
> If I understand this correctly, if we track old correctly, it won't happen
> if guest driver behave correctly. That means it should only happen for a
> buggy driver (e.g trying to move off_wrap back).
If vhost is faster than virtio driver, I guess above
case may happen. The `old` and `new` will be updated
each time we want to notify the driver. If the driver
is slower, `old` and `new` in vhost may wrap before
the `off` which is set by driver wraps.
Best regards,
Tiwei Bie
>
> Thanks
>
> >
> > Best regards,
> > Tiwei Bie
> >
> > > return vring_need_event(off, new, old);
> > > }
> > >
> > >
> > > > Best regards,
> > > > Tiwei Bie
> > > >
> > > > > else
> > > > > d1 = new - off - 1;
> > > > >
> > > > > if (new > old)
> > > > > d2 = new - old;
> > > > > else
> > > > > d2 = new + vq->num - old;
> > > > >
> > > > > return d1 < d2;
> > > > > }
> > > > >
> > > > > Thanks
> > > > >
>
^ permalink raw reply
* RE: [PATCH v2] net: dsa: drop some VLAs in switch.c
From: David Laight @ 2018-05-08 9:39 UTC (permalink / raw)
To: 'Salvatore Mesoraca', Florian Fainelli
Cc: Andrew Lunn, linux-kernel@vger.kernel.org, Kernel Hardening,
netdev@vger.kernel.org, David S. Miller, Kees Cook,
Vivien Didelot
In-Reply-To: <CAJHCu1KsvPEs9vpp5bY04OeVfMtqZzPuO=9c8e2QP-+n+VKUjQ@mail.gmail.com>
From: Salvatore Mesoraca
> Sent: 07 May 2018 20:03
...
> This optimization will save us an allocation when number of ports is
> less than 32 or 64 (depending on arch).
> IMHO it's useful, if you consider that, right now, DSA works only with
> 12-ports switches.
Why not just error out if the number of ports is greater than the compile-time
limit?
Worry about dynamic allocation if you need a lot more than 64 ports.
David
^ permalink raw reply
* Re: [RFC PATCH 1/3] arcnet: com20020: Add memory map of com20020
From: Andrea Greco @ 2018-05-08 9:36 UTC (permalink / raw)
To: Tobin C. Harding
Cc: m.grzeschik, Andrea Greco, Rob Herring, Mark Rutland, netdev,
devicetree, linux-kernel
In-Reply-To: <20180507025503.GF4197@eros>
On 05/07/2018 04:55 AM, Tobin C. Harding wrote:
> On Sat, May 05, 2018 at 11:34:45PM +0200, Andrea Greco wrote:
>> From: Andrea Greco <a.greco@4sigma.it>
>
> Hi Andrea,
>
> Here are some (mostly stylistic) suggestions to help you get your driver merged.
>
>> Add support for com20022I/com20020, memory mapped chip version.
>> Support bus: Intel 80xx and Motorola 68xx.
>> Bus size: Only 8 bit bus size is supported.
>> Added related device tree bindings
>>
>> Signed-off-by: Andrea Greco <a.greco@4sigma.it>
>> ---
>> .../devicetree/bindings/net/smsc-com20020.txt | 23 +++
>> drivers/net/arcnet/Kconfig | 12 +-
>> drivers/net/arcnet/Makefile | 1 +
>> drivers/net/arcnet/arcdevice.h | 27 ++-
>> drivers/net/arcnet/com20020-membus.c | 191 +++++++++++++++++++++
>> drivers/net/arcnet/com20020.c | 9 +-
>> 6 files changed, 253 insertions(+), 10 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/net/smsc-com20020.txt
>> create mode 100644 drivers/net/arcnet/com20020-membus.c
>>
>> diff --git a/Documentation/devicetree/bindings/net/smsc-com20020.txt b/Documentation/devicetree/bindings/net/smsc-com20020.txt
>> new file mode 100644
>> index 000000000000..39c5b19c55af
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/smsc-com20020.txt
>> @@ -0,0 +1,23 @@
>> +SMSC com20020, com20022I
>> +
>> +timeout: Arcnet timeout, checkout datashet
>> +clockp: Clock Prescaler, checkout datashet
>> +clockm: Clock multiplier, checkout datasheet
>> +
>> +phy-reset-gpios: Chip reset ppin
>> +phy-irq-gpios: Chip irq pin
ppin Corrected by my-self.
>> +
>> +com20020_A@0 {
>> + compatible = "smsc,com20020";
>> +
>> + timeout = <0x3>;
>> + backplane = <0x0>;
>> +
>> + clockp = <0x0>;
>> + clockm = <0x3>;
>> +
>> + phy-reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>;
>> + phy-irq-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
>> +
>> + status = "okay";
>> +};
>> diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
>> index 39bd16f3f86d..d39faf45be1e 100644
>> --- a/drivers/net/arcnet/Kconfig
>> +++ b/drivers/net/arcnet/Kconfig
>> @@ -3,7 +3,7 @@
>> #
>>
>> menuconfig ARCNET
>> - depends on NETDEVICES && (ISA || PCI || PCMCIA)
>> + depends on NETDEVICES
>> tristate "ARCnet support"
>> ---help---
>> If you have a network card of this type, say Y and check out the
>> @@ -129,5 +129,15 @@ config ARCNET_COM20020_CS
>>
>> To compile this driver as a module, choose M here: the module will be
>> called com20020_cs. If unsure, say N.
>> +config ARCNET_COM20020_MEMORY_BUS
>> + bool "Support for COM20020 on external memory"
>> + depends on ARCNET_COM20020 && !(ARCNET_COM20020_PCI || ARCNET_COM20020_ISA || ARCNET_COM20020_CS)
>> + help
>> + Say Y here if on your custom board mount com20020 or friends.
>> +
>> + Com20022I support arcnet bus 10Mbitps.
>> + This driver support only 8bit
>
> This driver only supports 8bit bus size.
>
>> , and DMA is not supported is attached on your board at external interface bus.
>
> This bit does not make sense, sorry.
Removed description,
Proposal for v2:
Say Y here if your custom board mount com20020 chipset or friends.
Supported Chipset: com20020, com20022, com20022I-3v3.
If unsure, say N.
>> + Supported bus Intel80xx / Motorola 68xx.
>> + This driver not work with other com20020 module: PCI or PCMCIA compiled as [M].
>
> I'm not sure exactly what you want to say here, perhaps:
>
> This driver does not work with other com20020 modules compiled
> as PCI or PCMCIA [M].
About this, all removed from kconfig
For PCI, PCMCIA, checkout downside
>>
>> endif # ARCNET
>> diff --git a/drivers/net/arcnet/Makefile b/drivers/net/arcnet/Makefile
>> index 53525e8ea130..19425c1e06f4 100644
>> --- a/drivers/net/arcnet/Makefile
>> +++ b/drivers/net/arcnet/Makefile
>> @@ -14,3 +14,4 @@ obj-$(CONFIG_ARCNET_COM20020) += com20020.o
>> obj-$(CONFIG_ARCNET_COM20020_ISA) += com20020-isa.o
>> obj-$(CONFIG_ARCNET_COM20020_PCI) += com20020-pci.o
>> obj-$(CONFIG_ARCNET_COM20020_CS) += com20020_cs.o
>> +obj-$(CONFIG_ARCNET_COM20020_MEMORY_BUS) += com20020-membus.o
>> diff --git a/drivers/net/arcnet/arcdevice.h b/drivers/net/arcnet/arcdevice.h
>> index d09b2b46ab63..16c608269cca 100644
>> --- a/drivers/net/arcnet/arcdevice.h
>> +++ b/drivers/net/arcnet/arcdevice.h
>> @@ -201,7 +201,7 @@ struct ArcProto {
>> void (*rx)(struct net_device *dev, int bufnum,
>> struct archdr *pkthdr, int length);
>> int (*build_header)(struct sk_buff *skb, struct net_device *dev,
>> - unsigned short ethproto, uint8_t daddr);
>> + unsigned short ethproto, uint8_t daddr);
>
> + unsigned short ethproto, uint8_t daddr);
>
> Please use Linux coding style style, parameters continuing on separate
> line are aligned with opening parenthesis.
>
>> /* these functions return '1' if the skb can now be freed */
>> int (*prepare_tx)(struct net_device *dev, struct archdr *pkt,
>> @@ -326,9 +326,9 @@ struct arcnet_local {
>> void (*recontrigger) (struct net_device * dev, int enable);
>>
>> void (*copy_to_card)(struct net_device *dev, int bufnum,
>> - int offset, void *buf, int count);
>> + int offset, void *buf, int count);
>> void (*copy_from_card)(struct net_device *dev, int bufnum,
>> - int offset, void *buf, int count);
>> + int offset, void *buf, int count);
>> } hw;
>>
>> void __iomem *mem_start; /* pointer to ioremap'ed MMIO */
>> @@ -360,7 +360,7 @@ struct net_device *alloc_arcdev(const char *name);
>> int arcnet_open(struct net_device *dev);
>> int arcnet_close(struct net_device *dev);
>> netdev_tx_t arcnet_send_packet(struct sk_buff *skb,
>> - struct net_device *dev);
>> + struct net_device *dev);
>> void arcnet_timeout(struct net_device *dev);
Not required modification then all removed.
>>
>> /* I/O equivalents */
>> @@ -371,7 +371,23 @@ void arcnet_timeout(struct net_device *dev);
>> #define BUS_ALIGN 1
>> #endif
>>
>> -/* addr and offset allow register like names to define the actual IO address.
>> +#ifdef CONFIG_ARCNET_COM20020_MEMORY_BUS
>> +#define arcnet_inb(addr, offset) \
>> + ioread8((void __iomem *)(addr) + BUS_ALIGN * (offset))
>> +
>> +#define arcnet_outb(value, addr, offset) \
>> + iowrite8(value, (void __iomem *)(addr) + BUS_ALIGN * (offset))
>> +
>> +#define arcnet_insb(addr, offset, buffer, count) \
>> + ioread8_rep((void __iomem *) \
>> + (addr) + BUS_ALIGN * (offset), buffer, count)
>> +
>> +#define arcnet_outsb(addr, offset, buffer, count) \
>> + iowrite8_rep((void __iomem *) \
>> + (addr) + BUS_ALIGN * (offset), buffer, count)
>> +#else
>> +/**
>> + * addr and offset allow register like names to define the actual IO address.
>> * A configuration option multiplies the offset for alignment.
>> */
>> #define arcnet_inb(addr, offset) \
>> @@ -388,6 +404,7 @@ void arcnet_timeout(struct net_device *dev);
>> readb((addr) + (offset))
>> #define arcnet_writeb(value, addr, offset) \
>> writeb(value, (addr) + (offset))
>> +#endif
>>
>> #endif /* __KERNEL__ */
>> #endif /* _LINUX_ARCDEVICE_H */
This is most important part where a suggestion will be very appreciated.
This part define how arcnet drivers read and write over physical.
The old driver can always use readb/writeb and friends, this driver rise
big kernel panic.
This driver make a ioreamp with: devm_ioremap.
Then, for r/w operation i use ioread8/iowrite8 and friends.
My quickly solution was make a ugly #ifdef.
With #ifndef all other driver implementation could not be used together
this driver, because break, how driver write over physical.
A proposal could be add a read/write callback to arcdevice.h struct hw.
PROS:
Every driver fill this callback, this is a solution.
CONS:
This solution require a small change for all com20020 driver
implementations. I don't dispose of all hardware for make a accurate
test. I could only test memory bus version.
Any other ideas, will be very appreciated.
>> diff --git a/drivers/net/arcnet/com20020-membus.c b/drivers/net/arcnet/com20020-membus.c
>> new file mode 100644
>> index 000000000000..6e4a2f3a84f7
>> --- /dev/null
>> +++ b/drivers/net/arcnet/com20020-membus.c
>> @@ -0,0 +1,191 @@
>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>> +/* Linux ARCnet driver for com 20020.
>> + *
>> + * This datasheet:
>> + * http://ww1.microchip.com/downloads/en/DeviceDoc/200223vrevc.pdf
>> + * http://ww1.microchip.com/downloads/en/DeviceDoc/20020.pdf
>> + *
>> + * This driver support:
>
> * This driver supports:
>
>> + * - com20020,
>> + * - com20022
>> + * - com20022I-3v3
>> + *
>> + * This driver support only, 8bit read and write.
>
> * This driver supports only 8bit read and write.
>
>> + * DMA is not supported by this driver.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/types.h>
>> +#include <linux/device.h>
>> +#include <linux/kernel.h>
>> +#include <linux/errno.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/netdevice.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_gpio.h>
>> +#include <linux/sizes.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/ioport.h>
>> +#include <linux/random.h>
>> +
>> +#include <linux/delay.h>
>> +#include "arcdevice.h"
>> +#include "com20020.h"
>
> White space line is not needed here, you might have meant to have it one
> line down?
>
Removed
>> +
>> +#define VERSION "arcnet: COM20020 MEMORY BUS support loaded.\n"
>> +
>> +static int com20020_probe(struct platform_device *pdev)
>> +{
>> + struct device_node *np;
>> + struct net_device *dev;
>> + struct arcnet_local *lp;
>> + struct resource res, *iores;
>> + int ret, phy_reset, err;
>> + u32 timeout, backplane, clockp, clockm;
>> + void __iomem *ioaddr;
>> +
>> + np = pdev->dev.of_node;
>> +
>> + iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +
>> + if (of_address_to_resource(np, 0, &res))
>> + return -EINVAL;
>> +
>> + ret = of_property_read_u32(np, "timeout", &timeout);
>> + if (ret) {
>> + dev_err(&pdev->dev, "timeout is required param");
>> + return ret;
>> + }
>> +
>> + ret = of_property_read_u32(np, "backplane", &backplane);
>> + if (ret) {
>> + dev_err(&pdev->dev, "backplane is required param");
>> + return ret;
>> + }
>> +
>> + ret = of_property_read_u32(np, "clockp", &clockp);
>> + if (ret) {
>> + dev_err(&pdev->dev, "clockp is required param");
>> + return ret;
>> + }
>> +
>> + ret = of_property_read_u32(np, "clockm", &clockm);
>> + if (ret) {
>> + dev_err(&pdev->dev, "clockm is required param");
>> + return ret;
>> + }
>> +
>> + phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
>> + if (phy_reset == -EPROBE_DEFER) {
>> + return phy_reset;
>> + } else if (!gpio_is_valid(phy_reset)) {
>> + dev_err(&pdev->dev, "phy-reset-gpios not valid !");
>> + return 0;
>> + }
>> +
>> + err = devm_gpio_request_one(&pdev->dev, phy_reset, GPIOF_OUT_INIT_LOW,
>> + "arcnet-phy-reset");
>> + if (err) {
>> + dev_err(&pdev->dev, "failed to get phy-reset-gpios: %d\n", err);
>> + return err;
>> + }
>> +
>> + dev = alloc_arcdev(NULL);// Let autoassign name arc%d
>
> /* C89 style comments please */
All comment bring to C89
>
>> + dev->netdev_ops = &com20020_netdev_ops;
>> + lp = netdev_priv(dev);
>> +
>> + lp->card_flags = ARC_CAN_10MBIT;/* pretend all of them can 10Mbit */
>> +
>> + // Force address to 0
>
Removed
> Unnecessary, we can see this in the code :) Please don't comment 'what'
> the code does (unless it is obfuscated or difficult to read). You may
> still like to comment 'why' the code does what it does though.
>
>> + // Will be set by user with `ip set dev arc0 address YOUR_NODE_ID`
>> + dev->dev_addr[0] = 0;
>> +
All this become
/* Will be set by userspace during if setup */
>> + // request to system this memory region
>
> Same as above
>
Removed
>> + if (!devm_request_mem_region(&pdev->dev, res.start, resource_size(&res),
>> + lp->card_name))
>> + return -EBUSY;
>> +
>> + ioaddr = devm_ioremap(&pdev->dev, iores->start, resource_size(iores));
>> + if (!ioaddr) {
>> + dev_err(&pdev->dev, "ioremap fallied\n");
>> + return -ENOMEM;
>> + }
>> +
>> + // Reset time is 5 * xTalFreq, minimal xtal is 10Mhz
>> + // (5 * 1000) / 10Mhz = 500ns
>
> perhaps a macro definition
> #define MAX_XTAL_RESET_TIME ??
Macro made, on head of file.
Rereading Datasheet maby that last delay could be removed.
Then become
gpio_set_value_cansleep(phy_reset, 0);
ndelay(RESET_DELAY);
gpio_set_value_cansleep(phy_reset, 1);
>> +
>> + gpio_set_value_cansleep(phy_reset, 0);
>> + ndelay(500);
>> + gpio_set_value_cansleep(phy_reset, 1);
>> + ndelay(500);
>> +
>> + /* Dummy access after Reset
>> + * ARCNET controller needs
>> + * this access to detect bustype
>> + */
>
> nit: Upto 72 characters wide is fine for comments
>
> /* Dummy access after Reset ARCNET controller needs
> * this access to detect bustype
> */
>
>> + arcnet_outb(0x00, ioaddr, COM20020_REG_W_COMMAND);
>> + arcnet_inb(ioaddr, COM20020_REG_R_DIAGSTAT);
>> +
Changed in:
/* ARCNET controller needs this access to detect bustype */
arcnet_outb(0x00, ioaddr, COM20020_REG_W_COMMAND);
arcnet_inb(ioaddr, COM20020_REG_R_DIAGSTAT);
>> + dev->base_addr = (unsigned long)ioaddr;
>> + get_random_bytes(dev->dev_addr, sizeof(u8));
>> +
>> + dev->irq = of_get_named_gpio(np, "phy-irq-gpios", 0);
>> + if (dev->irq == -EPROBE_DEFER) {
>> + return dev->irq;
>> + } else if (!gpio_is_valid(dev->irq)) {
>> + dev_err(&pdev->dev, "phy-irq-gpios not valid !");
>> + return 0;
>> + }
>> + dev->irq = gpio_to_irq(dev->irq);
>> +
>> + lp->backplane = backplane;
>> + lp->clockp = clockp & 7;
>> + lp->clockm = clockm & 3;
>> + lp->timeout = timeout;
>> + lp->hw.owner = THIS_MODULE;
>> +
>> + if (arcnet_inb(ioaddr, COM20020_REG_R_STATUS) == 0xFF) {
>> + ret = -EIO;
>> + goto err_release_mem;
>> + }
>> +
>> + if (com20020_check(dev)) {
>> + ret = -EIO;
>> + goto err_release_mem;
>> + }
>> +
>> + ret = com20020_found(dev, IRQF_TRIGGER_FALLING);
>> + if (ret)
>> + goto err_release_mem;
>> +
>> + dev_dbg(&pdev->dev, "probe Done\n");
>> + return 0;
>> +
>> +err_release_mem:
>> + devm_iounmap(&pdev->dev, (void __iomem *)ioaddr);
>> + devm_release_mem_region(&pdev->dev, res.start, resource_size(&res));
>> + dev_err(&pdev->dev, "probe failed!\n");
>> + return ret;
>> +}
>> +
>> +static const struct of_device_id of_com20020_match[] = {
>> + { .compatible = "smsc,com20020", },
>> + { },
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, of_com20020_match);
>> +
>> +static struct platform_driver of_com20020_driver = {
>> + .driver = {
>> + .name = "com20020-memory-bus",
>> + .of_match_table = of_com20020_match,
>> + },
>> + .probe = com20020_probe,
>> +};
>> +
>> +static int com20020_init(void)
>> +{
>> + return platform_driver_register(&of_com20020_driver);
>> +}
>> +late_initcall(com20020_init);
>> +
>> +MODULE_LICENSE("GPL");
>> diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
>> index 78043a9c5981..f09ea77dd6a8 100644
>> --- a/drivers/net/arcnet/com20020.c
>> +++ b/drivers/net/arcnet/com20020.c
>> @@ -43,7 +43,7 @@
>> #include "com20020.h"
>>
>> static const char * const clockrates[] = {
>> - "XXXXXXX", "XXXXXXXX", "XXXXXX", "2.5 Mb/s",
>> + "10 Mb/s", "XXXXXXXX", "XXXXXX", "2.5 Mb/s",
>> "1.25Mb/s", "625 Kb/s", "312.5 Kb/s", "156.25 Kb/s",
>> "Reserved", "Reserved", "Reserved"
>> };
>> @@ -391,9 +391,10 @@ static void com20020_set_mc_list(struct net_device *dev)
>> }
>> }
>>
>> -#if defined(CONFIG_ARCNET_COM20020_PCI_MODULE) || \
>> - defined(CONFIG_ARCNET_COM20020_ISA_MODULE) || \
>> - defined(CONFIG_ARCNET_COM20020_CS_MODULE)
>> +#if defined(CONFIG_ARCNET_COM20020_PCI_MODULE) || \
>> + defined(CONFIG_ARCNET_COM20020_ISA_MODULE) || \
>> + defined(CONFIG_ARCNET_COM20020_CS_MODULE) || \
>> + defined(CONFIG_ARCNET_COM20020_MEMORY_BUS)
>
> Why the whitespace change?
defined(CONFIG_ARCNET_COM20020_ISA_MODULE) || \
- defined(CONFIG_ARCNET_COM20020_CS_MODULE)
+ defined(CONFIG_ARCNET_COM20020_CS_MODULE) || \
+ defined(CONFIG_ARCNET_COM20020_MEMORY_BUS)
Removed useless withespace
>
> Hope this helps,
> Tobin.
>
Thank you for help,
Andrea
^ permalink raw reply
* Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring
From: Jason Wang @ 2018-05-08 9:34 UTC (permalink / raw)
To: Tiwei Bie; +Cc: Michael S. Tsirkin, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <20180508091628.d7jzpopqopq4abhy@debian>
On 2018年05月08日 17:16, Tiwei Bie wrote:
> On Tue, May 08, 2018 at 03:16:53PM +0800, Jason Wang wrote:
>> On 2018年05月08日 14:44, Tiwei Bie wrote:
>>> On Tue, May 08, 2018 at 01:40:40PM +0800, Jason Wang wrote:
>>>> On 2018年05月08日 11:05, Jason Wang wrote:
>>>>>> Because in virtqueue_enable_cb_delayed(), we may set an
>>>>>> event_off which is bigger than new and both of them have
>>>>>> wrapped. And in this case, although new is smaller than
>>>>>> event_off (i.e. the third param -- old), new shouldn't
>>>>>> add vq->num, and actually we are expecting a very big
>>>>>> idx diff.
>>>>> Yes, so to calculate distance correctly between event and new, we just
>>>>> need to compare the warp counter and return false if it doesn't match
>>>>> without the need to try to add vq.num here.
>>>>>
>>>>> Thanks
>>>> Sorry, looks like the following should work, we need add vq.num if
>>>> used_wrap_counter does not match:
>>>>
>>>> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
>>>> __u16 off_wrap, __u16 new,
>>>> __u16 old)
>>>> {
>>>> bool wrap = off_wrap >> 15;
>>>> int off = off_wrap & ~(1 << 15);
>>>> __u16 d1, d2;
>>>>
>>>> if (wrap != vq->used_wrap_counter)
>>>> d1 = new + vq->num - off - 1;
>>> Just to draw your attention (maybe you have already
>>> noticed this).
>> I miss this, thanks!
>>
>>> In this case (i.e. wrap != vq->used_wrap_counter),
>>> it's also possible that (off < new) is true. Because,
>>>
>>> when virtqueue_enable_cb_delayed_packed() is used,
>>> `off` is calculated in driver in a way like this:
>>>
>>> off = vq->last_used_idx + bufs;
>>> if (off >= vq->vring_packed.num) {
>>> off -= vq->vring_packed.num;
>>> wrap_counter ^= 1;
>>> }
>>>
>>> And when `new` (in vhost) is close to vq->num. The
>>> vq->last_used_idx + bufs (in driver) can be bigger
>>> than vq->vring_packed.num, and:
>>>
>>> 1. `off` will wrap;
>>> 2. wrap counters won't match;
>>> 3. off < new;
>>>
>>> And d1 (i.e. new + vq->num - off - 1) will be a value
>>> bigger than vq->num. I'm okay with this, although it's
>>> a bit weird.
>>
>> So I'm considering something more compact by reusing vring_need_event() by
>> pretending a larger queue size and adding vq->num back when necessary:
>>
>> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
>> __u16 off_wrap, __u16 new,
>> __u16 old)
>> {
>> bool wrap = vq->used_wrap_counter;
> If the wrap counter is obtained from the vq,
> I think `new` should also be obtained from
> the vq. Or the wrap counter should be carried
> in `new`.
>
>> int off = off_wrap & ~(1 << 15);
>> __u16 d1, d2;
>>
>> if (new < old) {
>> new += vq->num;
>> wrap ^= 1;
>> }
>>
>> if (wrap != off_wrap >> 15)
>> off += vq->num;
> When `new` and `old` wraps, and `off` doesn't wrap,
> wrap != (off_wrap >> 15) will be true. In this case,
> `off` is bigger than `new`, and what we should do
> is `off -= vq->num` instead of `off += vq->num`.
If I understand this correctly, if we track old correctly, it won't
happen if guest driver behave correctly. That means it should only
happen for a buggy driver (e.g trying to move off_wrap back).
Thanks
>
> Best regards,
> Tiwei Bie
>
>> return vring_need_event(off, new, old);
>> }
>>
>>
>>> Best regards,
>>> Tiwei Bie
>>>
>>>> else
>>>> d1 = new - off - 1;
>>>>
>>>> if (new > old)
>>>> d2 = new - old;
>>>> else
>>>> d2 = new + vq->num - old;
>>>>
>>>> return d1 < d2;
>>>> }
>>>>
>>>> Thanks
>>>>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Christophe JAILLET @ 2018-05-08 9:34 UTC (permalink / raw)
To: davem, tariqt
Cc: netdev, linux-rdma, linux-kernel, kernel-janitors,
Christophe JAILLET
If the 2nd memory allocation of the loop fails, we must undo the
memory allocation done so far.
Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index e0adac4a9a19..bf078244e467 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -3331,7 +3331,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
if (!priv->tx_cq[t]) {
kfree(priv->tx_ring[t]);
err = -ENOMEM;
- goto out;
+ goto err_free_tx;
}
}
priv->rx_ring_num = prof->rx_ring_num;
--
2.17.0
^ permalink raw reply related
* [PATCH 7/7] DT: net: can: rcar_canfd: document R8A77980 bindings
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Sergei Shtylyov, Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Document the R-Car V3H (R8A77980) SoC support in the R-Car CAN-FD bindings.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 59dd13aab97f..ac71daa46195 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -7,6 +7,7 @@ Required properties:
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
- "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller.
- "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller.
+ - "renesas,r8a77980-canfd" for R8A77980 (R-Car V3H) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
--
2.17.0
^ permalink raw reply related
* [PATCH 5/7] dt-bindings: can: rcar_can: Fix R8A7796 SoC name
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Geert Uytterhoeven, Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Geert Uytterhoeven <geert+renesas@glider.be>
R8A7796 is R-Car M3-W.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 93c3a6ae32f9..1a4ee1d2506d 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -5,7 +5,7 @@ Required properties:
- compatible: Must contain one or more of the following:
- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
- - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3) compatible controller.
+ - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
--
2.17.0
^ permalink raw reply related
* [PATCH 6/7] DT: net: can: rcar_canfd: document R8A77970 bindings
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Sergei Shtylyov, Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Document the R-Car V3M (R8A77970) SoC support in the R-Car CAN-FD bindings.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 1a4ee1d2506d..59dd13aab97f 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -6,6 +6,7 @@ Required properties:
- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
- "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller.
+ - "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
--
2.17.0
^ permalink raw reply related
* [PATCH 2/7] can: flexcan: fix endianess detection
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Uwe Kleine-König, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
In commit 88462d2a7830 ("can: flexcan: Remodel FlexCAN register r/w APIs
for big endian FlexCAN controllers.") the following logic was
implemented:
if the dt property "big-endian" is given or
the device is compatible to "fsl,p1010-flexcan":
use big-endian mode;
else
use little-endian mode;
This relies on commit d50f4630c2e1 ("arm: dts: Remove p1010-flexcan
compatible from imx series dts") which was applied a few commits later.
Without this commit (or an old device tree used for booting a new
kernel) the flexcan devices on i.MX25, i.MX28, i.MX35 and i.MX53 match
the 'the device is compatible to "fsl,p1010-flexcan"' test and so are
switched erroneously to big endian mode.
Instead of the check above put a quirk in devtype data and rely on
of_match_device yielding the most compatible match
Fixes: 88462d2a7830 ("can: flexcan: Remodel FlexCAN register r/w APIs for big endian FlexCAN controllers.")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Gavin Schenk <g.schenk@eckelmann.de>
Cc: linux-stable <stable@vger.kernel.org> # >= v4.16
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/flexcan.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 634c51e6b8ae..d53a45bf2a72 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -200,6 +200,7 @@
#define FLEXCAN_QUIRK_DISABLE_MECR BIT(4) /* Disable Memory error detection */
#define FLEXCAN_QUIRK_USE_OFF_TIMESTAMP BIT(5) /* Use timestamp based offloading */
#define FLEXCAN_QUIRK_BROKEN_PERR_STATE BIT(6) /* No interrupt for error passive */
+#define FLEXCAN_QUIRK_DEFAULT_BIG_ENDIAN BIT(7) /* default to BE register access */
/* Structure of the message buffer */
struct flexcan_mb {
@@ -287,6 +288,12 @@ struct flexcan_priv {
};
static const struct flexcan_devtype_data fsl_p1010_devtype_data = {
+ .quirks = FLEXCAN_QUIRK_BROKEN_WERR_STATE |
+ FLEXCAN_QUIRK_BROKEN_PERR_STATE |
+ FLEXCAN_QUIRK_DEFAULT_BIG_ENDIAN,
+};
+
+static const struct flexcan_devtype_data fsl_imx25_devtype_data = {
.quirks = FLEXCAN_QUIRK_BROKEN_WERR_STATE |
FLEXCAN_QUIRK_BROKEN_PERR_STATE,
};
@@ -1251,9 +1258,9 @@ static void unregister_flexcandev(struct net_device *dev)
static const struct of_device_id flexcan_of_match[] = {
{ .compatible = "fsl,imx6q-flexcan", .data = &fsl_imx6q_devtype_data, },
{ .compatible = "fsl,imx28-flexcan", .data = &fsl_imx28_devtype_data, },
- { .compatible = "fsl,imx53-flexcan", .data = &fsl_p1010_devtype_data, },
- { .compatible = "fsl,imx35-flexcan", .data = &fsl_p1010_devtype_data, },
- { .compatible = "fsl,imx25-flexcan", .data = &fsl_p1010_devtype_data, },
+ { .compatible = "fsl,imx53-flexcan", .data = &fsl_imx25_devtype_data, },
+ { .compatible = "fsl,imx35-flexcan", .data = &fsl_imx25_devtype_data, },
+ { .compatible = "fsl,imx25-flexcan", .data = &fsl_imx25_devtype_data, },
{ .compatible = "fsl,p1010-flexcan", .data = &fsl_p1010_devtype_data, },
{ .compatible = "fsl,vf610-flexcan", .data = &fsl_vf610_devtype_data, },
{ .compatible = "fsl,ls1021ar2-flexcan", .data = &fsl_ls1021a_r2_devtype_data, },
@@ -1337,18 +1344,13 @@ static int flexcan_probe(struct platform_device *pdev)
priv = netdev_priv(dev);
- if (of_property_read_bool(pdev->dev.of_node, "big-endian")) {
+ if (of_property_read_bool(pdev->dev.of_node, "big-endian") ||
+ devtype_data->quirks & FLEXCAN_QUIRK_DEFAULT_BIG_ENDIAN) {
priv->read = flexcan_read_be;
priv->write = flexcan_write_be;
} else {
- if (of_device_is_compatible(pdev->dev.of_node,
- "fsl,p1010-flexcan")) {
- priv->read = flexcan_read_be;
- priv->write = flexcan_write_be;
- } else {
- priv->read = flexcan_read_le;
- priv->write = flexcan_write_le;
- }
+ priv->read = flexcan_read_le;
+ priv->write = flexcan_write_le;
}
priv->can.clock.freq = clock_freq;
--
2.17.0
^ permalink raw reply related
* pull-request: can 2018-05-08
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is a pull request for 7 patches for net/master.
The first patch is by Jakob Unterwurzacher and increases the severity of
bus-off messages in the generic CAN device infrastructure. The next two patches
are by Uwe Kleine-König and fix the endianess detection in the flexcan driver.
Jimmy Assarsson's patch for the kvaser driver corrects the stats counter for
dropped tx-messages. Geert Uytterhoeven provides one patch and Sergei Shtylyov
two patches for the rcan_canfd device tree binding description.
regards,
Marc
---
The following changes since commit 2c5d5b13c6eb79f5677e206b8aad59b3a2097f60:
llc: better deal with too small mtu (2018-05-08 00:11:40 -0400)
are available in the Git repository at:
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-4.17-20180508
for you to fetch changes up to 7a25ac2f71a409e77dd5c85cf3cbe1cbf2ae77f3:
DT: net: can: rcar_canfd: document R8A77980 bindings (2018-05-08 10:41:38 +0200)
----------------------------------------------------------------
linux-can-fixes-for-4.17-20180508
----------------------------------------------------------------
Geert Uytterhoeven (1):
dt-bindings: can: rcar_can: Fix R8A7796 SoC name
Jakob Unterwurzacher (1):
can: dev: increase bus-off message severity
Jimmy Assarsson (1):
can: kvaser_usb: Increase correct stats counter in kvaser_usb_rx_can_msg()
Sergei Shtylyov (2):
DT: net: can: rcar_canfd: document R8A77970 bindings
DT: net: can: rcar_canfd: document R8A77980 bindings
Uwe Kleine-König (2):
can: flexcan: fix endianess detection
arm: dts: imx[35]*: declare flexcan devices to be compatible to imx25's flexcan
.../devicetree/bindings/net/can/rcar_canfd.txt | 4 +++-
arch/arm/boot/dts/imx35.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
drivers/net/can/dev.c | 2 +-
drivers/net/can/flexcan.c | 26 ++++++++++++----------
drivers/net/can/usb/kvaser_usb.c | 2 +-
6 files changed, 23 insertions(+), 19 deletions(-)
^ permalink raw reply
* [PATCH 4/7] can: kvaser_usb: Increase correct stats counter in kvaser_usb_rx_can_msg()
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Jimmy Assarsson, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Jimmy Assarsson <extja@kvaser.com>
Increase rx_dropped, if alloc_can_skb() fails, not tx_dropped.
Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/kvaser_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 63587b8e6825..daed57d3d209 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1179,7 +1179,7 @@ static void kvaser_usb_rx_can_msg(const struct kvaser_usb *dev,
skb = alloc_can_skb(priv->netdev, &cf);
if (!skb) {
- stats->tx_dropped++;
+ stats->rx_dropped++;
return;
}
--
2.17.0
^ 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