* Re: [RFC] net: dsa: mv88e6xxx: ptp: improve phc2sys precision for mv88e6xxx switch in combination with imx6-fec
From: Miroslav Lichvar @ 2019-08-05 10:36 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Hubert Feurstein, Richard Cochran, Andrew Lunn, netdev, lkml,
Vivien Didelot, Florian Fainelli, David S. Miller
In-Reply-To: <CA+h21hr835sdvtgVOA2M9SWeCXDOrDG1S3FnNgJd_9NP2X_TaQ@mail.gmail.com>
On Mon, Aug 05, 2019 at 12:54:49PM +0300, Vladimir Oltean wrote:
> - Along the lines of the above, I wonder how badly would the
> maintainers shout at the proposal of adding a struct
> ptp_system_timestamp pointer and its associated lock in struct device.
> That way at least you don't have to change the API, like you did with
> mdiobus_write_nested_ptp. Relatively speaking, this is the least
> amount of intrusion (although, again, far from beautiful).
That would make sense to me, if there are other drivers that could use
it.
> I also added Miroslav Lichvar, who originally created the
> PTP_SYS_OFFSET_EXTENDED ioctl, maybe he can share some ideas on how it
> is best served.
The idea behind that ioctl was to allow drivers to take the system
timestamps as close to the reading of the HW clock as possible,
excluding delays (and jitter) due to other operations that are
necessary to get that timestamp. In the ethernet drivers that was a
single PCI read. If in this case it's a "write" operation that
triggers the reading of the HW clock, then I think the patch is
using is the ptp_read_system_*ts() calls correctly.
> > --- a/drivers/net/ethernet/freescale/fec_main.c
> > +++ b/drivers/net/ethernet/freescale/fec_main.c
> > @@ -1814,11 +1814,25 @@ static int fec_enet_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
> >
> > reinit_completion(&fep->mdio_done);
> >
> > - /* start a write op */
> > - writel(FEC_MMFR_ST | FEC_MMFR_OP_WRITE |
> > - FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(regnum) |
> > - FEC_MMFR_TA | FEC_MMFR_DATA(value),
> > - fep->hwp + FEC_MII_DATA);
> > + if (bus->ptp_sts) {
> > + unsigned long flags = 0;
> > + local_irq_save(flags);
> > + __iowmb();
> > + /* >Take the timestamp *after* the memory barrier */
> > + ptp_read_system_prets(bus->ptp_sts);
> > + writel_relaxed(FEC_MMFR_ST | FEC_MMFR_OP_WRITE |
> > + FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(regnum) |
> > + FEC_MMFR_TA | FEC_MMFR_DATA(value),
> > + fep->hwp + FEC_MII_DATA);
> > + ptp_read_system_postts(bus->ptp_sts);
> > + local_irq_restore(flags);
> > + } else {
> > + /* start a write op */
> > + writel(FEC_MMFR_ST | FEC_MMFR_OP_WRITE |
> > + FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(regnum) |
> > + FEC_MMFR_TA | FEC_MMFR_DATA(value),
> > + fep->hwp + FEC_MII_DATA);
> > + }
--
Miroslav Lichvar
^ permalink raw reply
* Re: [PATCH] tools: bpftool: fix reading from /proc/config.gz
From: Quentin Monnet @ 2019-08-05 10:41 UTC (permalink / raw)
To: Peter Wu, Alexei Starovoitov, Daniel Borkmann
Cc: netdev, Stanislav Fomichev, Jakub Kicinski
In-Reply-To: <20190805001541.8096-1-peter@lekensteyn.nl>
Hi Peter,
Thanks for looking into this (and for the fixes)! Some comments below.
2019-08-05 01:15 UTC+0100 ~ Peter Wu <peter@lekensteyn.nl>
> /proc/config has never existed as far as I can see, but /proc/config.gz
As far as I understood (from examining Cilium [0]), /proc/config _is_
used by some distributions, such as CoreOS. This is why we look at that
location in bpftool.
[0] https://github.com/cilium/cilium/blob/master/bpf/run_probes.sh#L42
> is present on Arch Linux. Execute an external gunzip program to avoid
> linking to zlib and rework the option scanning code since a pipe is not
> seekable. This also fixes a file handle leak on some error paths.
>
> Fixes: 4567b983f78c ("tools: bpftool: add probes for kernel configuration options")
> Cc: Quentin Monnet <quentin.monnet@netronome.com>
> Signed-off-by: Peter Wu <peter@lekensteyn.nl>
> ---
> tools/bpf/bpftool/feature.c | 92 +++++++++++++++++++++----------------
> 1 file changed, 52 insertions(+), 40 deletions(-)
>
> diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c
> index d672d9086fff..e9e10f582047 100644
> --- a/tools/bpf/bpftool/feature.c
> +++ b/tools/bpf/bpftool/feature.c
> @@ -284,34 +284,34 @@ static void probe_jit_limit(void)
> }
> }
>
> -static char *get_kernel_config_option(FILE *fd, const char *option)
> +static bool get_kernel_config_option(FILE *fd, char **buf_p, size_t *n_p,
> + char **value)
Maybe we could rename this function, and have "next" appear in it
somewhere? After your changes, it does not return the value for a
specific option anymore.
> {
> - size_t line_n = 0, optlen = strlen(option);
> - char *res, *strval, *line = NULL;
> - ssize_t n;
> + char *sep;
> + ssize_t linelen;
Please order the declarations in reverse-Christmas tree style.
>
> - rewind(fd);
> - while ((n = getline(&line, &line_n, fd)) > 0) {
> - if (strncmp(line, option, optlen))
> + while ((linelen = getline(buf_p, n_p, fd)) > 0) {
> + char *line = *buf_p;
Please leave a blank line after declarations.
> + if (strncmp(line, "CONFIG_", 7))
> continue;
> - /* Check we have at least '=', value, and '\n' */
> - if (strlen(line) < optlen + 3)
> - continue;
> - if (*(line + optlen) != '=')
> +
> + sep = memchr(line, '=', linelen);
> + if (!sep)
> continue;
>
> /* Trim ending '\n' */
> - line[strlen(line) - 1] = '\0';
> + line[linelen - 1] = '\0';
> +
> + /* Split on '=' and ensure that a value is present. */
> + *sep = '\0';
> + if (!sep[1])
> + continue;
>
> - /* Copy and return config option value */
> - strval = line + optlen + 1;
> - res = strdup(strval);
> - free(line);
> - return res;
> + *value = sep + 1;
> + return true;
> }
> - free(line);
>
> - return NULL;
> + return false;
> }
>
> static void probe_kernel_image_config(void)
> @@ -386,31 +386,34 @@ static void probe_kernel_image_config(void)
> /* test_bpf module for BPF tests */
> "CONFIG_TEST_BPF",
> };
> + char *values[ARRAY_SIZE(options)] = { };
> char *value, *buf = NULL;
> struct utsname utsn;
> char path[PATH_MAX];
> size_t i, n;
> ssize_t ret;
> - FILE *fd;
> + FILE *fd = NULL;
> + bool is_pipe = false;
Reverse-Christmas-tree style please.
>
> if (uname(&utsn))
> - goto no_config;
> + goto end_parse;
Just thinking, maybe if uname() fails we can skip /boot/config-$(uname
-r) but still attempt to parse /proc/config{,.gz} instead of printing
only NULL options?
>
> snprintf(path, sizeof(path), "/boot/config-%s", utsn.release);
>
> fd = fopen(path, "r");
> if (!fd && errno == ENOENT) {
> - /* Some distributions put the config file at /proc/config, give
> - * it a try.
> - * Sometimes it is also at /proc/config.gz but we do not try
> - * this one for now, it would require linking against libz.
> + /* Some distributions build with CONFIG_IKCONFIG=y and put the
> + * config file at /proc/config.gz. We try to invoke an external
> + * gzip program to avoid linking to libz.
> + * Hide stderr to avoid interference with the JSON output.
Because some distributions do use /proc/config, we should keep this. You
can probably add /proc/config.gz as another attempt below (or even
above) the current case?
> */
> - fd = fopen("/proc/config", "r");
> + fd = popen("gunzip -c /proc/config.gz 2>/dev/null", "r");
> + is_pipe = true;
> }
> if (!fd) {
> p_info("skipping kernel config, can't open file: %s",
> strerror(errno));
> - goto no_config;
> + goto end_parse;
> }
> /* Sanity checks */
> ret = getline(&buf, &n, fd);
> @@ -418,27 +421,36 @@ static void probe_kernel_image_config(void)
> if (!buf || !ret) {
> p_info("skipping kernel config, can't read from file: %s",
> strerror(errno));
> - free(buf);
> - goto no_config;
> + goto end_parse;
> }
> if (strcmp(buf, "# Automatically generated file; DO NOT EDIT.\n")) {
> p_info("skipping kernel config, can't find correct file");
> - free(buf);
> - goto no_config;
> + goto end_parse;
> + }
> +
> + while (get_kernel_config_option(fd, &buf, &n, &value))> + for (i = 0; i < ARRAY_SIZE(options); i++) {
> + if (values[i] || strcmp(buf, options[i]))
Can we have an option set multiple times in the config file? If so,
maybe have a p_info() if values are different to warn users that
conflicting values were found?
(Reading the file just once is a nice improvement over my version, by
the way, thanks!)
> + continue;
> +
> + values[i] = strdup(value);
> + }
> + }
> +
> +end_parse:
> + if (fd) {
> + if (is_pipe) {
> + if (pclose(fd))
> + p_info("failed to read /proc/config.gz");
> + } else
> + fclose(fd);
Please use braces on all branches of the conditional statement (else).
Thanks,
Quentin
^ permalink raw reply
* [PATCH]][next] selftests: nettest: fix spelling mistake: "potocol" -> "protocol"
From: Colin King @ 2019-08-05 10:52 UTC (permalink / raw)
To: David S . Miller, Shuah Khan, netdev, linux-kselftest
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in an error messgae. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
tools/testing/selftests/net/nettest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/nettest.c b/tools/testing/selftests/net/nettest.c
index 9278f8460d75..83515e5ea4dc 100644
--- a/tools/testing/selftests/net/nettest.c
+++ b/tools/testing/selftests/net/nettest.c
@@ -1627,7 +1627,7 @@ int main(int argc, char *argv[])
args.protocol = pe->p_proto;
} else {
if (str_to_uint(optarg, 0, 0xffff, &tmp) != 0) {
- fprintf(stderr, "Invalid potocol\n");
+ fprintf(stderr, "Invalid protocol\n");
return 1;
}
args.protocol = tmp;
--
2.20.1
^ permalink raw reply related
* Re: [v2] net: can: Fix compiling warning
From: Markus Elfring @ 2019-08-05 10:56 UTC (permalink / raw)
To: Mao Wenan, David S. Miller, Oliver Hartkopp, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190805012637.62314-1-maowenan@huawei.com>
> v1->v2: change patch description typo error, …
Will an other commit subject like “[PATCH v3] net: can: Fix compilation warnings
for two functions” be more appropriate here?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH net 1/2] net: sched: police: allow accessing police->params with rtnl
From: Pieter Jansen van Vuuren @ 2019-08-05 11:38 UTC (permalink / raw)
To: Vlad Buslov, netdev; +Cc: jhs, xiyou.wangcong, jiri, davem
In-Reply-To: <20190803133619.10574-2-vladbu@mellanox.com>
On 2019/08/03 14:36, Vlad Buslov wrote:
> Recently implemented support for police action in flow_offload infra leads
> to following rcu usage warning:
>
> [ 1925.881092] =============================
> [ 1925.881094] WARNING: suspicious RCU usage
> [ 1925.881098] 5.3.0-rc1+ #574 Not tainted
> [ 1925.881100] -----------------------------
> [ 1925.881104] include/net/tc_act/tc_police.h:57 suspicious rcu_dereference_check() usage!
> [ 1925.881106]
> other info that might help us debug this:
>
> [ 1925.881109]
> rcu_scheduler_active = 2, debug_locks = 1
> [ 1925.881112] 1 lock held by tc/18591:
> [ 1925.881115] #0: 00000000b03cb918 (rtnl_mutex){+.+.}, at: tc_new_tfilter+0x47c/0x970
> [ 1925.881124]
> stack backtrace:
> [ 1925.881127] CPU: 2 PID: 18591 Comm: tc Not tainted 5.3.0-rc1+ #574
> [ 1925.881130] Hardware name: Supermicro SYS-2028TP-DECR/X10DRT-P, BIOS 2.0b 03/30/2017
> [ 1925.881132] Call Trace:
> [ 1925.881138] dump_stack+0x85/0xc0
> [ 1925.881145] tc_setup_flow_action+0x1771/0x2040
> [ 1925.881155] fl_hw_replace_filter+0x11f/0x2e0 [cls_flower]
> [ 1925.881175] fl_change+0xd24/0x1b30 [cls_flower]
> [ 1925.881200] tc_new_tfilter+0x3e0/0x970
> [ 1925.881231] ? tc_del_tfilter+0x720/0x720
> [ 1925.881243] rtnetlink_rcv_msg+0x389/0x4b0
> [ 1925.881250] ? netlink_deliver_tap+0x95/0x400
> [ 1925.881257] ? rtnl_dellink+0x2d0/0x2d0
> [ 1925.881264] netlink_rcv_skb+0x49/0x110
> [ 1925.881275] netlink_unicast+0x171/0x200
> [ 1925.881284] netlink_sendmsg+0x224/0x3f0
> [ 1925.881299] sock_sendmsg+0x5e/0x60
> [ 1925.881305] ___sys_sendmsg+0x2ae/0x330
> [ 1925.881309] ? task_work_add+0x43/0x50
> [ 1925.881314] ? fput_many+0x45/0x80
> [ 1925.881329] ? __lock_acquire+0x248/0x1930
> [ 1925.881342] ? find_held_lock+0x2b/0x80
> [ 1925.881347] ? task_work_run+0x7b/0xd0
> [ 1925.881359] __sys_sendmsg+0x59/0xa0
> [ 1925.881375] do_syscall_64+0x5c/0xb0
> [ 1925.881381] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 1925.881384] RIP: 0033:0x7feb245047b8
> [ 1925.881388] Code: 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 65 8f 0c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83
> ec 28 89 54
> [ 1925.881391] RSP: 002b:00007ffc2d2a5788 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> [ 1925.881395] RAX: ffffffffffffffda RBX: 000000005d4497ed RCX: 00007feb245047b8
> [ 1925.881398] RDX: 0000000000000000 RSI: 00007ffc2d2a57f0 RDI: 0000000000000003
> [ 1925.881400] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000006
> [ 1925.881403] R10: 0000000000404ec2 R11: 0000000000000246 R12: 0000000000000001
> [ 1925.881406] R13: 0000000000480640 R14: 0000000000000012 R15: 0000000000000001
>
> Change tcf_police_rate_bytes_ps() and tcf_police_tcfp_burst() helpers to
> allow using them from both rtnl and rcu protected contexts.
>
> Fixes: 8c8cfc6ed274 ("net/sched: add police action to the hardware intermediate representation")
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Thank you Vlad.
Reviewed-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
^ permalink raw reply
* Re: [PATCH net 2/2] net: sched: sample: allow accessing psample_group with rtnl
From: Pieter Jansen van Vuuren @ 2019-08-05 11:39 UTC (permalink / raw)
To: Vlad Buslov, netdev; +Cc: jhs, xiyou.wangcong, jiri, davem
In-Reply-To: <20190803133619.10574-3-vladbu@mellanox.com>
On 2019/08/03 14:36, Vlad Buslov wrote:
> Recently implemented support for sample action in flow_offload infra leads
> to following rcu usage warning:
>
> [ 1938.234856] =============================
> [ 1938.234858] WARNING: suspicious RCU usage
> [ 1938.234863] 5.3.0-rc1+ #574 Not tainted
> [ 1938.234866] -----------------------------
> [ 1938.234869] include/net/tc_act/tc_sample.h:47 suspicious rcu_dereference_check() usage!
> [ 1938.234872]
> other info that might help us debug this:
>
> [ 1938.234875]
> rcu_scheduler_active = 2, debug_locks = 1
> [ 1938.234879] 1 lock held by tc/19540:
> [ 1938.234881] #0: 00000000b03cb918 (rtnl_mutex){+.+.}, at: tc_new_tfilter+0x47c/0x970
> [ 1938.234900]
> stack backtrace:
> [ 1938.234905] CPU: 2 PID: 19540 Comm: tc Not tainted 5.3.0-rc1+ #574
> [ 1938.234908] Hardware name: Supermicro SYS-2028TP-DECR/X10DRT-P, BIOS 2.0b 03/30/2017
> [ 1938.234911] Call Trace:
> [ 1938.234922] dump_stack+0x85/0xc0
> [ 1938.234930] tc_setup_flow_action+0xed5/0x2040
> [ 1938.234944] fl_hw_replace_filter+0x11f/0x2e0 [cls_flower]
> [ 1938.234965] fl_change+0xd24/0x1b30 [cls_flower]
> [ 1938.234990] tc_new_tfilter+0x3e0/0x970
> [ 1938.235021] ? tc_del_tfilter+0x720/0x720
> [ 1938.235028] rtnetlink_rcv_msg+0x389/0x4b0
> [ 1938.235038] ? netlink_deliver_tap+0x95/0x400
> [ 1938.235044] ? rtnl_dellink+0x2d0/0x2d0
> [ 1938.235053] netlink_rcv_skb+0x49/0x110
> [ 1938.235063] netlink_unicast+0x171/0x200
> [ 1938.235073] netlink_sendmsg+0x224/0x3f0
> [ 1938.235091] sock_sendmsg+0x5e/0x60
> [ 1938.235097] ___sys_sendmsg+0x2ae/0x330
> [ 1938.235111] ? __handle_mm_fault+0x12cd/0x19e0
> [ 1938.235125] ? __handle_mm_fault+0x12cd/0x19e0
> [ 1938.235138] ? find_held_lock+0x2b/0x80
> [ 1938.235147] ? do_user_addr_fault+0x22d/0x490
> [ 1938.235160] __sys_sendmsg+0x59/0xa0
> [ 1938.235178] do_syscall_64+0x5c/0xb0
> [ 1938.235187] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 1938.235192] RIP: 0033:0x7ff9a4d597b8
> [ 1938.235197] Code: 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 65 8f 0c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83
> ec 28 89 54
> [ 1938.235200] RSP: 002b:00007ffcfe381c48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> [ 1938.235205] RAX: ffffffffffffffda RBX: 000000005d4497f9 RCX: 00007ff9a4d597b8
> [ 1938.235208] RDX: 0000000000000000 RSI: 00007ffcfe381cb0 RDI: 0000000000000003
> [ 1938.235211] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000006
> [ 1938.235214] R10: 0000000000404ec2 R11: 0000000000000246 R12: 0000000000000001
> [ 1938.235217] R13: 0000000000480640 R14: 0000000000000012 R15: 0000000000000001
>
> Change tcf_sample_psample_group() helper to allow using it from both rtnl
> and rcu protected contexts.
>
> Fixes: a7a7be6087b0 ("net/sched: add sample action to the hardware intermediate representation")
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Thanks
Reviewed-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
^ permalink raw reply
* Re: [PATCH 1/2] usb: serial: option: Add the BroadMobi BM818 card
From: Johan Hovold @ 2019-08-05 11:47 UTC (permalink / raw)
To: Angus Ainslie (Purism)
Cc: kernel, Bjørn Mork, David S. Miller, Johan Hovold,
Greg Kroah-Hartman, netdev, linux-usb, linux-kernel, Bob Ham
In-Reply-To: <20190724145227.27169-2-angus@akkea.ca>
On Wed, Jul 24, 2019 at 07:52:26AM -0700, Angus Ainslie (Purism) wrote:
> From: Bob Ham <bob.ham@puri.sm>
>
> Add a VID:PID for the BroadModi BM818 M.2 card
Would you mind posting the output of usb-devices (or lsusb -v) for this
device?
> Signed-off-by: Bob Ham <bob.ham@puri.sm>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> ---
> drivers/usb/serial/option.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index c1582fbd1150..674a68ee9564 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -1975,6 +1975,8 @@ static const struct usb_device_id option_ids[] = {
> .driver_info = RSVD(4) | RSVD(5) },
> { USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x0105, 0xff), /* Fibocom NL678 series */
> .driver_info = RSVD(6) },
> + { USB_DEVICE(0x2020, 0x2060), /* BroadMobi */
Looks like you forgot to include the model in the comment here.
And please move this one after the other 0x2020 (PID 0x2031) entry.
Should you also be using USB_DEVICE_INTERFACE_CLASS() (e.g. to avoid
matching a mass-storage interface)?
> + .driver_info = RSVD(4) },
> { } /* Terminating entry */
> };
> MODULE_DEVICE_TABLE(usb, option_ids);
Johan
^ permalink raw reply
* RE: [PATCH] net: sctp: Rename fallthrough label to unhandled
From: David Laight @ 2019-08-05 11:49 UTC (permalink / raw)
To: 'Joe Perches', Neil Horman
Cc: Vlad Yasevich, Marcelo Ricardo Leitner, David S. Miller,
linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <a9d003ddd0d59fb144db3ecda3453b3d9c0cb139.camel@perches.com>
From: Joe Perches
> Sent: 01 August 2019 18:43
> On Thu, 2019-08-01 at 06:50 -0400, Neil Horman wrote:
> > On Wed, Jul 31, 2019 at 03:23:46PM -0700, Joe Perches wrote:
> []
> > You can say that if you want, but you made the point that your think the macro
> > as you have written is more readable. You example illustrates though that /*
> > fallthrough */ is a pretty common comment, and not prefixing it makes it look
> > like someone didn't add a comment that they meant to. The __ prefix is standard
> > practice for defining macros to attributes (212 instances of it by my count). I
> > don't mind rewriting the goto labels at all, but I think consistency is
> > valuable.
>
> Hey Neil.
>
> Perhaps you want to make this argument on the RFC patch thread
> that introduces the fallthrough pseudo-keyword.
>
> https://lore.kernel.org/patchwork/patch/1108577/
ISTM that the only place where you need something other than the
traditional comment is inside a #define where (almost certainly)
the comments have to get stripped too early.
Adding a 'fallthough' as unknown C keyword sucks...
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* [PATCH net-next v3] net: can: Fix compiling warnings for two functions
From: Mao Wenan @ 2019-08-05 11:57 UTC (permalink / raw)
To: davem, socketcan; +Cc: netdev, linux-kernel, kernel-janitors, maowenan
In-Reply-To: <6fd68e9b-a8ae-4e5e-9b23-c099b5ca9aa4@web.de>
There are two warnings in net/can, fix them by setting bcm_sock_no_ioctlcmd
and raw_sock_no_ioctlcmd as static.
net/can/bcm.c:1683:5: warning: symbol 'bcm_sock_no_ioctlcmd' was not declared. Should it be static?
net/can/raw.c:840:5: warning: symbol 'raw_sock_no_ioctlcmd' was not declared. Should it be static?
Fixes: 473d924d7d46 ("can: fix ioctl function removal")
Signed-off-by: Mao Wenan <maowenan@huawei.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
v1->v2: change patch description typo error, 'warings' to 'warnings'.
v2->v3: change subject of patch.
net/can/bcm.c | 2 +-
net/can/raw.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/can/bcm.c b/net/can/bcm.c
index bf1d0bbecec8..b8a32b4ac368 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -1680,7 +1680,7 @@ static int bcm_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
return size;
}
-int bcm_sock_no_ioctlcmd(struct socket *sock, unsigned int cmd,
+static int bcm_sock_no_ioctlcmd(struct socket *sock, unsigned int cmd,
unsigned long arg)
{
/* no ioctls for socket layer -> hand it down to NIC layer */
diff --git a/net/can/raw.c b/net/can/raw.c
index da386f1fa815..a01848ff9b12 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -837,7 +837,7 @@ static int raw_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
return size;
}
-int raw_sock_no_ioctlcmd(struct socket *sock, unsigned int cmd,
+static int raw_sock_no_ioctlcmd(struct socket *sock, unsigned int cmd,
unsigned long arg)
{
/* no ioctls for socket layer -> hand it down to NIC layer */
--
2.20.1
^ permalink raw reply related
* Re: [drop_monitor] 98ffbd6cd2: will-it-scale.per_thread_ops -17.5% regression
From: Ido Schimmel @ 2019-08-05 11:56 UTC (permalink / raw)
To: kernel test robot
Cc: netdev, davem, nhorman, dsahern, roopa, nikolay, jakub.kicinski,
toke, andy, f.fainelli, andrew, vivien.didelot, mlxsw,
Ido Schimmel, lkp
In-Reply-To: <20190729095213.GQ22106@shao2-debian>
On Mon, Jul 29, 2019 at 05:52:13PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -17.5% regression of will-it-scale.per_thread_ops due to commit:
>
>
> commit: 98ffbd6cd2b25fc6cbb0695e03b4fd43b5e116e6 ("[RFC PATCH net-next 10/12] drop_monitor: Add packet alert mode")
> url: https://github.com/0day-ci/linux/commits/Ido-Schimmel/drop_monitor-Capture-dropped-packets-and-metadata/20190723-135834
>
>
> in testcase: will-it-scale
> on test machine: 288 threads Intel(R) Xeon Phi(TM) CPU 7295 @ 1.50GHz with 80G memory
> with following parameters:
>
> nr_task: 100%
> mode: thread
> test: lock1
> cpufreq_governor: performance
Hi,
Thanks for the report. The test ('lock1') has nothing to do with the
networking subsystem and the commit that you cite is not doing anything
unless you're actually running drop monitor in this newly introduced
mode. I assume you're not running drop monitor at all? Therefore, these
results seem very strange to me.
The only thing I could think of to explain this is that somehow the
addition of 'struct sk_buff_head' to the per-CPU variable might have
affected alignment elsewhere.
I used your kernel config on my system and tried to run the test like
you did [1][2]. Did not get conclusive results [3]. Took measurements on
vanilla net-next and with my entire patchset applied (with some changes
since RFC).
If you look at the operations per seconds in the 'threads' column when
there are 4 tasks you can see that the average before my patchset is
2325577, while the average after is 2340328.
Do you see anything obviously wrong in how I ran the test? If not, in
your experience, how reliable are your results? I found a similar report
[4] that did not make a lot of sense as well.
Thanks
[1]
#!/bin/bash
for cpu_dir in /sys/devices/system/cpu/cpu[0-9]*
do
online_file="$cpu_dir"/online
[ -f "$online_file" ] && [ "$(cat "$online_file")" -eq 0 ] && continue
file="$cpu_dir"/cpufreq/scaling_governor
[ -f "$file" ] && echo "performance" > "$file"
done
[2]
# ./runtest.py lock1
[3]
before1.csv
tasks,processes,processes_idle,threads,threads_idle,linear
0,0,100,0,100,0
1,610132,74.98,594558,74.40,610132
2,1230153,49.95,1184090,49.95,1220264
3,1844832,24.92,1758502,25.07,1830396
4,2454858,0.20,2311086,0.18,2440528
before2.csv
tasks,processes,processes_idle,threads,threads_idle,linear
0,0,100,0,100,0
1,607417,74.92,584035,75.03,607417
2,1227674,50.02,1170271,50.05,1214834
3,1846440,24.91,1761115,25.03,1822251
4,2482559,0.23,2343761,0.20,2429668
before3.csv
tasks,processes,processes_idle,threads,threads_idle,linear
0,0,100,0,100,0
1,609516,74.96,594691,74.85,609516
2,1231126,49.82,1176170,50.07,1219032
3,1858004,24.93,1761192,25.06,1828548
4,2460096,0.29,2321886,0.20,2438064
after1.csv
tasks,processes,processes_idle,threads,threads_idle,linear
0,0,100,0,100,0
1,623846,75.01,598565,75.01,623846
2,1237010,50.01,1163000,50.06,1247692
3,1858541,24.99,1752192,24.98,1871538
4,2477562,0.20,2338462,0.20,2495384
after2.csv
tasks,processes,processes_idle,threads,threads_idle,linear
0,0,100,0,100,0
1,624175,74.98,593229,60.28,624175
2,1237561,45.43,1168572,50.01,1248350
3,1850211,25.03,1744378,24.90,1872525
4,2481224,0.20,2335768,0.20,2496700
after3.csv
tasks,processes,processes_idle,threads,threads_idle,linear
0,0,100,0,100,0
1,617805,74.99,590419,75.02,617805
2,1230908,50.01,1158534,50.06,1235610
3,1851623,25.06,1728419,24.94,1853415
4,2470115,0.20,2346754,0.20,2471220
[4] https://lkml.org/lkml/2019/2/19/351
^ permalink raw reply
* [PATCH] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:25 UTC (permalink / raw)
To: robh+dt
Cc: Neil Armstrong, martin.blumenstingl, devicetree, netdev,
linux-amlogic, linux-arm-kernel, linux-kernel
Now that we have the DT validation in place, let's convert the device tree
bindings for the Synopsys DWMAC Glue for Amlogic SoCs over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Rob,
I keep getting :
.../devicetree/bindings/net/amlogic,meson-dwmac.example.dt.yaml: ethernet@c9410000: reg: [[3376480256, 65536], [3364046144, 8]] is too long
for the example DT
and for the board DT :
../amlogic/meson-gxl-s905x-libretech-cc.dt.yaml: ethernet@c9410000: reg: [[0, 3376480256, 0, 65536, 0, 3364046144, 0, 4]] is too short
../amlogic/meson-gxl-s905x-nexbox-a95x.dt.yaml: soc: ethernet@c9410000:reg:0: [0, 3376480256, 0, 65536, 0, 3364046144, 0, 4] is too long
and I don't know how to get rid of it.
What should I do for reg ?
Neil
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 5 +
3 files changed, 118 insertions(+), 71 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
new file mode 100644
index 000000000000..ae91aa9d8616
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson DWMAC Ethernet controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+# We need a select here so we don't match all nodes with 'snps,dwmac'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: "snps,dwmac.yaml#"
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: First parent clock of the internal mux
+ - description: Second parent clock of the internal mux
+
+ clock-names:
+ minItems: 3
+ maxItems: 3
+ items:
+ - const: stmmaceth
+ - const: clkin0
+ - const: clkin1
+
+ amlogic,tx-delay-ns:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description:
+ The internal RGMII TX clock delay (provided by this driver) in
+ nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
+ When phy-mode is set to "rgmii" then the TX delay should be
+ explicitly configured. When not configured a fallback of 2ns is
+ used. When the phy-mode is set to either "rgmii-id" or "rgmii-txid"
+ the TX clock delay is already provided by the PHY. In that case
+ this property should be set to 0ns (which disables the TX clock
+ delay in the MAC to prevent the clock from going off because both
+ PHY and MAC are adding a delay).
+ Any configuration is ignored when the phy-mode is set to "rmii".
+
+properties:
+ compatible:
+ additionalItems: true
+ maxItems: 3
+ items:
+ - enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ contains:
+ enum:
+ - snps,dwmac-3.70a
+ - snps,dwmac
+
+ reg:
+ items:
+ - description:
+ The first register range should be the one of the DWMAC controller
+ - description:
+ The second range is is for the Amlogic specific configuration
+ (for example the PRG_ETHERNET register range on Meson8b and newer)
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - phy-mode
+
+examples:
+ - |
+ ethmac: ethernet@c9410000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0xc9410000 0x10000>, <0xc8834540 0x8>;
+ interrupts = <8>;
+ interrupt-names = "macirq";
+ clocks = <&clk_eth>, <&clkc_fclk_div2>, <&clk_mpll2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ phy-mode = "rgmii";
+ };
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
deleted file mode 100644
index 1321bb194ed9..000000000000
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Amlogic Meson DWMAC Ethernet controller
-
-The device inherits all the properties of the dwmac/stmmac devices
-described in the file stmmac.txt in the current directory with the
-following changes.
-
-Required properties on all platforms:
-
-- compatible: Depending on the platform this should be one of:
- - "amlogic,meson6-dwmac"
- - "amlogic,meson8b-dwmac"
- - "amlogic,meson8m2-dwmac"
- - "amlogic,meson-gxbb-dwmac"
- - "amlogic,meson-axg-dwmac"
- Additionally "snps,dwmac" and any applicable more
- detailed version number described in net/stmmac.txt
- should be used.
-
-- reg: The first register range should be the one of the DWMAC
- controller. The second range is is for the Amlogic specific
- configuration (for example the PRG_ETHERNET register range
- on Meson8b and newer)
-
-Required properties on Meson8b, Meson8m2, GXBB and newer:
-- clock-names: Should contain the following:
- - "stmmaceth" - see stmmac.txt
- - "clkin0" - first parent clock of the internal mux
- - "clkin1" - second parent clock of the internal mux
-
-Optional properties on Meson8b, Meson8m2, GXBB and newer:
-- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
- by this driver) in nanoseconds. Allowed values
- are: 0ns, 2ns, 4ns, 6ns.
- When phy-mode is set to "rgmii" then the TX
- delay should be explicitly configured. When
- not configured a fallback of 2ns is used.
- When the phy-mode is set to either "rgmii-id"
- or "rgmii-txid" the TX clock delay is already
- provided by the PHY. In that case this
- property should be set to 0ns (which disables
- the TX clock delay in the MAC to prevent the
- clock from going off because both PHY and MAC
- are adding a delay).
- Any configuration is ignored when the phy-mode
- is set to "rmii".
-
-Example for Meson6:
-
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson6-dwmac", "snps,dwmac";
- reg = <0xc9410000 0x10000
- 0xc1108108 0x4>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clk81>;
- clock-names = "stmmaceth";
- }
-
-Example for GXBB:
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
- reg = <0x0 0xc9410000 0x0 0x10000>,
- <0x0 0xc8834540 0x0 0x8>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clkc CLKID_ETH>,
- <&clkc CLKID_FCLK_DIV2>,
- <&clkc CLKID_MPLL2>;
- clock-names = "stmmaceth", "clkin0", "clkin1";
- phy-mode = "rgmii";
- };
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 76fea2be66ac..ff1dc662a4e3 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -50,6 +50,11 @@ properties:
- allwinner,sun8i-r40-emac
- allwinner,sun8i-v3s-emac
- allwinner,sun50i-a64-emac
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
- snps,dwmac
- snps,dwmac-3.50a
- snps,dwmac-3.610
--
2.22.0
^ permalink raw reply related
* memory leak in ppp_write
From: syzbot @ 2019-08-05 12:38 UTC (permalink / raw)
To: ast, bpf, daniel, davem, kafai, linux-kernel, linux-ppp, netdev,
paulus, songliubraving, syzkaller-bugs, yhs
Hello,
syzbot found the following crash on:
HEAD commit: d8778f13 Merge tag 'xtensa-20190803' of git://github.com/j..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17a953d6600000
kernel config: https://syzkaller.appspot.com/x/.config?x=30cef20daf3e9977
dashboard link: https://syzkaller.appspot.com/bug?extid=d9c8bf24e56416d7ce2c
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16da002c600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d9c8bf24e56416d7ce2c@syzkaller.appspotmail.com
2019/08/04 10:45:32 executed programs: 5
2019/08/04 10:45:38 executed programs: 7
2019/08/04 10:45:44 executed programs: 9
2019/08/04 10:45:51 executed programs: 11
BUG: memory leak
unreferenced object 0xffff88811b943200 (size 224):
comm "syz-executor.0", pid 7102, jiffies 4294951426 (age 8.020s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000612bb18c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000612bb18c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000612bb18c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000612bb18c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<00000000f510d7dd>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<0000000064f35f9b>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<0000000064f35f9b>] ppp_write+0x48/0x120
drivers/net/ppp/ppp_generic.c:502
[<000000007d5732a9>] __vfs_write+0x43/0xa0 fs/read_write.c:494
[<00000000b490138e>] vfs_write fs/read_write.c:558 [inline]
[<00000000b490138e>] vfs_write+0xee/0x210 fs/read_write.c:542
[<00000000d20d33e5>] ksys_write+0x7c/0x130 fs/read_write.c:611
[<000000007b61e45c>] __do_sys_write fs/read_write.c:623 [inline]
[<000000007b61e45c>] __se_sys_write fs/read_write.c:620 [inline]
[<000000007b61e45c>] __x64_sys_write+0x1e/0x30 fs/read_write.c:620
[<0000000067600a9b>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000007e48b83c>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* KASAN: use-after-free Read in blkdev_bio_end_io
From: syzbot @ 2019-08-05 12:38 UTC (permalink / raw)
To: arvid.brodin, davem, linux-fsdevel, linux-kernel, netdev,
syzkaller-bugs, viro, xiyou.wangcong
Hello,
syzbot found the following crash on:
HEAD commit: 1e78030e Merge tag 'mmc-v5.3-rc1' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15286cdc600000
kernel config: https://syzkaller.appspot.com/x/.config?x=e397351d2615e10
dashboard link: https://syzkaller.appspot.com/bug?extid=2a99a1bb75e9116ec20c
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=150799e8600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16aaa8c4600000
The bug was bisected to:
commit b9a1e627405d68d475a3c1f35e685ccfb5bbe668
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu Jul 4 00:21:13 2019 +0000
hsr: implement dellink to clean up resources
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15efbeec600000
final crash: https://syzkaller.appspot.com/x/report.txt?x=17efbeec600000
console output: https://syzkaller.appspot.com/x/log.txt?x=13efbeec600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2a99a1bb75e9116ec20c@syzkaller.appspotmail.com
Fixes: b9a1e627405d ("hsr: implement dellink to clean up resources")
==================================================================
BUG: KASAN: use-after-free in blkdev_bio_end_io+0x37e/0x430
fs/block_dev.c:301
Read of size 1 at addr ffff8880a40928d4 by task ksoftirqd/0/9
CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.3.0-rc2+ #59
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+0x1d8/0x2f8 lib/dump_stack.c:113
print_address_description+0x75/0x5b0 mm/kasan/report.c:351
__kasan_report+0x14b/0x1c0 mm/kasan/report.c:482
kasan_report+0x26/0x50 mm/kasan/common.c:612
__asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:129
blkdev_bio_end_io+0x37e/0x430 fs/block_dev.c:301
bio_endio+0x4ff/0x570 block/bio.c:1830
req_bio_endio block/blk-core.c:239 [inline]
blk_update_request+0x385/0xf80 block/blk-core.c:1424
blk_mq_end_request+0x42/0x80 block/blk-mq.c:557
end_cmd+0xeb/0x2d0 drivers/block/null_blk_main.c:622
null_complete_rq+0x1c/0x20 drivers/block/null_blk_main.c:649
blk_done_softirq+0x362/0x3e0 block/blk-softirq.c:37
__do_softirq+0x333/0x7c4 arch/x86/include/asm/paravirt.h:778
run_ksoftirqd+0x64/0xf0 kernel/softirq.c:603
smpboot_thread_fn+0x62c/0xa70 kernel/smpboot.c:165
kthread+0x332/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Allocated by task 9743:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc+0x11c/0x1b0 mm/kasan/common.c:487
kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:495
slab_post_alloc_hook mm/slab.h:520 [inline]
slab_alloc mm/slab.c:3319 [inline]
kmem_cache_alloc+0x1f5/0x2e0 mm/slab.c:3483
mempool_alloc_slab+0x4d/0x70 mm/mempool.c:513
mempool_alloc+0x15f/0x6c0 mm/mempool.c:393
bio_alloc_bioset+0x210/0x670 block/bio.c:477
__blkdev_direct_IO+0x29c/0x1310 fs/block_dev.c:363
blkdev_direct_IO+0xbe/0xd0 fs/block_dev.c:518
generic_file_read_iter+0x1ad3/0x21b0 mm/filemap.c:2323
blkdev_read_iter+0x12e/0x140 fs/block_dev.c:2013
call_read_iter include/linux/fs.h:1864 [inline]
aio_read+0x362/0x4a0 fs/aio.c:1543
__io_submit_one fs/aio.c:1817 [inline]
io_submit_one+0x742/0x1ac0 fs/aio.c:1862
__do_sys_io_submit fs/aio.c:1921 [inline]
__se_sys_io_submit+0x18f/0x2d0 fs/aio.c:1891
__x64_sys_io_submit+0x7b/0x90 fs/aio.c:1891
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 9:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x12a/0x1e0 mm/kasan/common.c:449
kasan_slab_free+0xe/0x10 mm/kasan/common.c:457
__cache_free mm/slab.c:3425 [inline]
kmem_cache_free+0x81/0xf0 mm/slab.c:3693
mempool_free_slab+0x1d/0x30 mm/mempool.c:520
mempool_free+0xd5/0x350 mm/mempool.c:502
bio_put+0x35a/0x420 block/bio.c:253
bio_check_pages_dirty+0x404/0x4e0 block/bio.c:1703
blkdev_bio_end_io+0x345/0x430 fs/block_dev.c:330
bio_endio+0x4ff/0x570 block/bio.c:1830
req_bio_endio block/blk-core.c:239 [inline]
blk_update_request+0x385/0xf80 block/blk-core.c:1424
blk_mq_end_request+0x42/0x80 block/blk-mq.c:557
end_cmd+0xeb/0x2d0 drivers/block/null_blk_main.c:622
null_complete_rq+0x1c/0x20 drivers/block/null_blk_main.c:649
blk_done_softirq+0x362/0x3e0 block/blk-softirq.c:37
__do_softirq+0x333/0x7c4 arch/x86/include/asm/paravirt.h:778
The buggy address belongs to the object at ffff8880a40928c0
which belongs to the cache bio-1 of size 216
The buggy address is located 20 bytes inside of
216-byte region [ffff8880a40928c0, ffff8880a4092998)
The buggy address belongs to the page:
page:ffffea0002902480 refcount:1 mapcount:0 mapping:ffff8880a5ad0c40
index:0x0
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea0002862888 ffffea000264a1c8 ffff8880a5ad0c40
raw: 0000000000000000 ffff8880a4092000 000000010000000c 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880a4092780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880a4092800: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
> ffff8880a4092880: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8880a4092900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880a4092980: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PING 2] [PATCH v5 1/7] nfc: pn533: i2c: "pn532" as dt compatible string
From: Johan Hovold @ 2019-08-05 12:42 UTC (permalink / raw)
To: Lars Poeschel
Cc: devicetree, Samuel Ortiz, open list:NFC SUBSYSTEM, open list,
Johan Hovold, netdev
In-Reply-To: <20190403094735.GA19351@lem-wkst-02.lemonage>
On Wed, Apr 03, 2019 at 11:47:35AM +0200, Lars Poeschel wrote:
> Second Ping.
> On Thu, Feb 28, 2019 at 11:48:01AM +0100, Lars Poeschel wrote:
> > A gentle ping on this whole patch series.
> > On Fri, Jan 11, 2019 at 05:18:04PM +0100, Lars Poeschel wrote:
> > > It is favourable to have one unified compatible string for devices that
> > > have multiple interfaces. So this adds simply "pn532" as the devicetree
> > > binding compatible string and makes a note that the old ones are
> > > deprecated.
> > >
> > > Cc: Johan Hovold <johan@kernel.org>
> > > Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
You may want to resend this series to netdev now. David Miller will be
picking up NFC patches directly from there.
Johan
^ permalink raw reply
* Re: [PATCH 03/14] watchdog: pnx4008_wdt: allow compile-testing
From: Sylvain Lemieux @ 2019-08-05 12:42 UTC (permalink / raw)
To: Guenter Roeck
Cc: Arnd Bergmann, soc, Linux ARM, Vladimir Zapolskiy, Russell King,
Gregory Clement, Linus Walleij, Wim Van Sebroeck, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, David S. Miller,
Greg Kroah-Hartman, Alan Stern, open list:GPIO SUBSYSTEM,
Networking, linux-serial, USB list, LINUXWATCHDOG,
Linux Kernel Mailing List
In-Reply-To: <20190731203646.GB14817@roeck-us.net>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
On Wed, Jul 31, 2019 at 4:36 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Wed, Jul 31, 2019 at 10:26:35PM +0200, Arnd Bergmann wrote:
> > On Wed, Jul 31, 2019 at 10:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > On Wed, Jul 31, 2019 at 09:56:45PM +0200, Arnd Bergmann wrote:
> > > > The only thing that prevents building this driver on other
> > > > platforms is the mach/hardware.h include, which is not actually
> > > > used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
> > > >
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> > >
> > > What is the plan for this patch ? Push through watchdog
> > > or through your branch ?
> >
> > I would prefer my branch so I can apply the final patch without waiting
> > for another release. Not in a hurry though, so if some other maintainer
>
> Ok with me.
>
> Guenter
^ permalink raw reply
* Re: [PATCH 04/14] serial: lpc32xx_hs: allow compile-testing
From: Sylvain Lemieux @ 2019-08-05 12:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, soc, moderated list:ARM PORT, Vladimir Zapolskiy,
Russell King, Gregory Clement, Linus Walleij, Jiri Slaby,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, David S. Miller,
Alan Stern, Guenter Roeck, open list:GPIO SUBSYSTEM, Networking,
linux-serial, USB list, LINUXWATCHDOG, Linux Kernel Mailing List
In-Reply-To: <20190801055840.GC24607@kroah.com>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
On Thu, Aug 1, 2019 at 1:58 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 31, 2019 at 09:56:46PM +0200, Arnd Bergmann wrote:
> > The only thing that prevents building this driver on other
> > platforms is the mach/hardware.h include, which is not actually
> > used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > drivers/tty/serial/Kconfig | 3 ++-
> > drivers/tty/serial/lpc32xx_hs.c | 2 --
> > 2 files changed, 2 insertions(+), 3 deletions(-)
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH 02/14] usb: udc: lpc32xx: allow compile-testing
From: Sylvain Lemieux @ 2019-08-05 12:47 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, soc, moderated list:ARM PORT, Vladimir Zapolskiy,
Russell King, Gregory Clement, Linus Walleij, Felipe Balbi,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, David S. Miller,
Alan Stern, Guenter Roeck, open list:GPIO SUBSYSTEM, Networking,
linux-serial, USB list, LINUXWATCHDOG, Alexandre Belloni,
Linux Kernel Mailing List
In-Reply-To: <20190801055821.GB24607@kroah.com>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
On Thu, Aug 1, 2019 at 1:58 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 31, 2019 at 09:56:44PM +0200, Arnd Bergmann wrote:
> > The only thing that prevents building this driver on other
> > platforms is the mach/hardware.h include, which is not actually
> > used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > drivers/usb/gadget/udc/Kconfig | 3 ++-
> > drivers/usb/gadget/udc/lpc32xx_udc.c | 2 --
> > 2 files changed, 2 insertions(+), 3 deletions(-)
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-08-05 13:14 UTC (permalink / raw)
To: Jes.Sorensen, kvalo, davem
Cc: linux-wireless, netdev, linux-kernel, linux, Chris Chiu,
Daniel Drake
We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets ~1Mbps.
Nevertheless, the signal strength is reported as around -40dBm,
which is quite good. From the wireshark capture, the tx rate for each
data and qos data packet is only 1Mbps. Compare to the Realtek driver
at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
~12Mbps or better. The signal strength is reported similarly around
-40dBm. That's why we want to improve.
After reading the source code of the rtl8xxxu driver and Realtek's, the
major difference is that Realtek's driver has a watchdog which will keep
monitoring the signal quality and updating the rate mask just like the
rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
And this kind of watchdog also exists in rtlwifi driver of some specific
chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
the same member function named dm_watchdog and will invoke the
corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
mask.
With this commit, the tx rate of each data and qos data packet will
be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
to 23th bit means MCS4 to MCS7. It means that the firmware still picks
the lowest rate from the rate mask and explains why the tx rate of
data and qos data is always lowest 1Mbps because the default rate mask
passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
and MCS rate. However, with Realtek's driver, the tx rate observed from
wireshark under the same condition is almost 65Mbps or 72Mbps, which
indicating that rtl8xxxu could still be further improved.
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
---
Notes:
v2:
- Fix errors and warnings complained by checkpatch.pl
- Replace data structure rate_adaptive by 2 member variables
- Make rtl8xxxu_wireless_mode non-static
- Runs refresh_rate_mask() only in station mode
v3:
- Remove ugly rtl8xxxu_watchdog data structure
- Make sure only one vif exists
v4:
- Move cancel_delayed_work from rtl8xxxu_disconnect to rtl8xxxu_stop
- Clear priv->vif in rtl8xxxu_remove_interface
- Add rateid as the function argument of update_rate_mask
- Rephrase the comment for priv->vif more explicit.
v5:
- Make refresh_rate_mask() generic for all sub-drivers.
- Add definitions for SNR related to help determine rssi_level
v6:
- Fix typo of the comment for priv->vif
v7:
- Fix reported bug of watchdog stop
- refer to the RxPWDBAll in vendor driver for SNR calculation
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 55 ++++-
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 229 +++++++++++++++++-
2 files changed, 277 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index ade057d868f7..582c2a346cec 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1187,6 +1187,48 @@ struct rtl8723bu_c2h {
struct rtl8xxxu_fileops;
+/*mlme related.*/
+enum wireless_mode {
+ WIRELESS_MODE_UNKNOWN = 0,
+ /* Sub-Element */
+ WIRELESS_MODE_B = BIT(0),
+ WIRELESS_MODE_G = BIT(1),
+ WIRELESS_MODE_A = BIT(2),
+ WIRELESS_MODE_N_24G = BIT(3),
+ WIRELESS_MODE_N_5G = BIT(4),
+ WIRELESS_AUTO = BIT(5),
+ WIRELESS_MODE_AC = BIT(6),
+ WIRELESS_MODE_MAX = 0x7F,
+};
+
+/* from rtlwifi/wifi.h */
+enum ratr_table_mode_new {
+ RATEID_IDX_BGN_40M_2SS = 0,
+ RATEID_IDX_BGN_40M_1SS = 1,
+ RATEID_IDX_BGN_20M_2SS_BN = 2,
+ RATEID_IDX_BGN_20M_1SS_BN = 3,
+ RATEID_IDX_GN_N2SS = 4,
+ RATEID_IDX_GN_N1SS = 5,
+ RATEID_IDX_BG = 6,
+ RATEID_IDX_G = 7,
+ RATEID_IDX_B = 8,
+ RATEID_IDX_VHT_2SS = 9,
+ RATEID_IDX_VHT_1SS = 10,
+ RATEID_IDX_MIX1 = 11,
+ RATEID_IDX_MIX2 = 12,
+ RATEID_IDX_VHT_3SS = 13,
+ RATEID_IDX_BGN_3SS = 14,
+};
+
+#define RTL8XXXU_RATR_STA_INIT 0
+#define RTL8XXXU_RATR_STA_HIGH 1
+#define RTL8XXXU_RATR_STA_MID 2
+#define RTL8XXXU_RATR_STA_LOW 3
+
+#define RTL8XXXU_NOISE_FLOOR_MIN -100
+#define RTL8XXXU_SNR_THRESH_HIGH 50
+#define RTL8XXXU_SNR_THRESH_LOW 20
+
struct rtl8xxxu_priv {
struct ieee80211_hw *hw;
struct usb_device *udev;
@@ -1291,6 +1333,13 @@ struct rtl8xxxu_priv {
u8 pi_enabled:1;
u8 no_pape:1;
u8 int_buf[USB_INTR_CONTENT_LENGTH];
+ u8 rssi_level;
+ /*
+ * Only one virtual interface permitted because only STA mode
+ * is supported and no iface_combinations are provided.
+ */
+ struct ieee80211_vif *vif;
+ struct delayed_work ra_watchdog;
};
struct rtl8xxxu_rx_urb {
@@ -1326,7 +1375,7 @@ struct rtl8xxxu_fileops {
void (*set_tx_power) (struct rtl8xxxu_priv *priv, int channel,
bool ht40);
void (*update_rate_mask) (struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void (*report_connect) (struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void (*fill_txdesc) (struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
@@ -1411,9 +1460,9 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw);
void rtl8xxxu_gen1_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_gen2_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index c6c41fb962ff..a6f358b9e447 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4304,7 +4304,8 @@ static void rtl8xxxu_sw_scan_complete(struct ieee80211_hw *hw,
rtl8xxxu_write8(priv, REG_BEACON_CTRL, val8);
}
-void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
+void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
+ u32 ramask, u8 rateid, int sgi)
{
struct h2c_cmd h2c;
@@ -4324,7 +4325,7 @@ void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
}
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi)
+ u32 ramask, u8 rateid, int sgi)
{
struct h2c_cmd h2c;
u8 bw = 0;
@@ -4338,7 +4339,7 @@ void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
h2c.b_macid_cfg.ramask3 = (ramask >> 24) & 0xff;
h2c.ramask.arg = 0x80;
- h2c.b_macid_cfg.data1 = 0;
+ h2c.b_macid_cfg.data1 = rateid;
if (sgi)
h2c.b_macid_cfg.data1 |= BIT(7);
@@ -4478,6 +4479,40 @@ static void rtl8xxxu_set_basic_rates(struct rtl8xxxu_priv *priv, u32 rate_cfg)
rtl8xxxu_write8(priv, REG_INIRTS_RATE_SEL, rate_idx);
}
+static u16
+rtl8xxxu_wireless_mode(struct ieee80211_hw *hw, struct ieee80211_sta *sta)
+{
+ u16 network_type = WIRELESS_MODE_UNKNOWN;
+ u32 rate_mask;
+
+ rate_mask = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[0] << 20);
+
+ if (hw->conf.chandef.chan->band == NL80211_BAND_5GHZ) {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_5G;
+
+ network_type |= WIRELESS_MODE_A;
+ } else {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_24G;
+
+ if (sta->supp_rates[0] <= 0xf)
+ network_type |= WIRELESS_MODE_B;
+ else if (sta->supp_rates[0] & 0xf)
+ network_type |= (WIRELESS_MODE_B | WIRELESS_MODE_G);
+ else
+ network_type |= WIRELESS_MODE_G;
+ }
+
+ return network_type;
+}
+
static void
rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_bss_conf *bss_conf, u32 changed)
@@ -4520,7 +4555,10 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
sgi = 1;
rcu_read_unlock();
- priv->fops->update_rate_mask(priv, ramask, sgi);
+ priv->vif = vif;
+ priv->rssi_level = RTL8XXXU_RATR_STA_INIT;
+
+ priv->fops->update_rate_mask(priv, ramask, 0, sgi);
rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
@@ -5464,6 +5502,10 @@ static int rtl8xxxu_add_interface(struct ieee80211_hw *hw,
switch (vif->type) {
case NL80211_IFTYPE_STATION:
+ if (!priv->vif)
+ priv->vif = vif;
+ else
+ return -EOPNOTSUPP;
rtl8xxxu_stop_tx_beacon(priv);
val8 = rtl8xxxu_read8(priv, REG_BEACON_CTRL);
@@ -5487,6 +5529,9 @@ static void rtl8xxxu_remove_interface(struct ieee80211_hw *hw,
struct rtl8xxxu_priv *priv = hw->priv;
dev_dbg(&priv->udev->dev, "%s\n", __func__);
+
+ if (priv->vif)
+ priv->vif = NULL;
}
static int rtl8xxxu_config(struct ieee80211_hw *hw, u32 changed)
@@ -5772,6 +5817,177 @@ rtl8xxxu_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
return 0;
}
+static u8 rtl8xxxu_signal_to_snr(int signal)
+{
+ if (signal < RTL8XXXU_NOISE_FLOOR_MIN)
+ signal = RTL8XXXU_NOISE_FLOOR_MIN;
+ else if (signal > 0)
+ signal = 0;
+ return (u8)(signal - RTL8XXXU_NOISE_FLOOR_MIN);
+}
+
+static void rtl8xxxu_refresh_rate_mask(struct rtl8xxxu_priv *priv,
+ int signal, struct ieee80211_sta *sta)
+{
+ struct ieee80211_hw *hw = priv->hw;
+ u16 wireless_mode;
+ u8 rssi_level, ratr_idx;
+ u8 txbw_40mhz;
+ u8 snr, snr_thresh_high, snr_thresh_low;
+ u8 go_up_gap = 5;
+
+ rssi_level = priv->rssi_level;
+ snr = rtl8xxxu_signal_to_snr(signal);
+ snr_thresh_high = RTL8XXXU_SNR_THRESH_HIGH;
+ snr_thresh_low = RTL8XXXU_SNR_THRESH_LOW;
+ txbw_40mhz = (hw->conf.chandef.width == NL80211_CHAN_WIDTH_40) ? 1 : 0;
+
+ switch (rssi_level) {
+ case RTL8XXXU_RATR_STA_MID:
+ snr_thresh_high += go_up_gap;
+ break;
+ case RTL8XXXU_RATR_STA_LOW:
+ snr_thresh_high += go_up_gap;
+ snr_thresh_low += go_up_gap;
+ break;
+ default:
+ break;
+ }
+
+ if (snr > snr_thresh_high)
+ rssi_level = RTL8XXXU_RATR_STA_HIGH;
+ else if (snr > snr_thresh_low)
+ rssi_level = RTL8XXXU_RATR_STA_MID;
+ else
+ rssi_level = RTL8XXXU_RATR_STA_LOW;
+
+ if (rssi_level != priv->rssi_level) {
+ int sgi = 0;
+ u32 rate_bitmap = 0;
+
+ rcu_read_lock();
+ rate_bitmap = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[1] << 20);
+ if (sta->ht_cap.cap &
+ (IEEE80211_HT_CAP_SGI_40 | IEEE80211_HT_CAP_SGI_20))
+ sgi = 1;
+ rcu_read_unlock();
+
+ wireless_mode = rtl8xxxu_wireless_mode(hw, sta);
+ switch (wireless_mode) {
+ case WIRELESS_MODE_B:
+ ratr_idx = RATEID_IDX_B;
+ if (rate_bitmap & 0x0000000c)
+ rate_bitmap &= 0x0000000d;
+ else
+ rate_bitmap &= 0x0000000f;
+ break;
+ case WIRELESS_MODE_A:
+ case WIRELESS_MODE_G:
+ ratr_idx = RATEID_IDX_G;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else
+ rate_bitmap &= 0x00000ff0;
+ break;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G):
+ ratr_idx = RATEID_IDX_BG;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else if (rssi_level == RTL8XXXU_RATR_STA_MID)
+ rate_bitmap &= 0x00000ff0;
+ else
+ rate_bitmap &= 0x00000ff5;
+ break;
+ case WIRELESS_MODE_N_24G:
+ case WIRELESS_MODE_N_5G:
+ case (WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_A | WIRELESS_MODE_N_5G):
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_GN_N2SS;
+ else
+ ratr_idx = RATEID_IDX_GN_N1SS;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_B | WIRELESS_MODE_N_24G):
+ if (txbw_40mhz) {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_BGN_40M_2SS;
+ else
+ ratr_idx = RATEID_IDX_BGN_40M_1SS;
+ } else {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_BGN_20M_2SS_BN;
+ else
+ ratr_idx = RATEID_IDX_BGN_20M_1SS_BN;
+ }
+
+ if (priv->tx_paths == 2 && priv->rx_paths == 2) {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x0f8f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x0f8ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x0f8ff015;
+ else
+ rate_bitmap &= 0x0f8ff005;
+ }
+ } else {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x000f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x000ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x000ff015;
+ else
+ rate_bitmap &= 0x000ff005;
+ }
+ }
+ break;
+ default:
+ ratr_idx = RATEID_IDX_BGN_40M_2SS;
+ rate_bitmap &= 0x0fffffff;
+ break;
+ }
+
+ priv->rssi_level = rssi_level;
+ priv->fops->update_rate_mask(priv, rate_bitmap, ratr_idx, sgi);
+ }
+}
+
+static void rtl8xxxu_watchdog_callback(struct work_struct *work)
+{
+ struct ieee80211_vif *vif;
+ struct rtl8xxxu_priv *priv;
+
+ priv = container_of(work, struct rtl8xxxu_priv, ra_watchdog.work);
+ vif = priv->vif;
+
+ if (vif && vif->type == NL80211_IFTYPE_STATION) {
+ int signal;
+ struct ieee80211_sta *sta;
+
+ rcu_read_lock();
+ sta = ieee80211_find_sta(vif, vif->bss_conf.bssid);
+ if (!sta) {
+ struct device *dev = &priv->udev->dev;
+
+ dev_info(dev, "%s: no sta found\n", __func__);
+ rcu_read_unlock();
+ goto out;
+ }
+ rcu_read_unlock();
+
+ signal = ieee80211_ave_rssi(vif);
+ rtl8xxxu_refresh_rate_mask(priv, signal, sta);
+ }
+
+out:
+ schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
+}
+
static int rtl8xxxu_start(struct ieee80211_hw *hw)
{
struct rtl8xxxu_priv *priv = hw->priv;
@@ -5828,6 +6044,8 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
ret = rtl8xxxu_submit_rx_urb(priv, rx_urb);
}
+
+ schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
exit:
/*
* Accept all data and mgmt frames
@@ -5879,6 +6097,8 @@ static void rtl8xxxu_stop(struct ieee80211_hw *hw)
if (priv->usb_interrupts)
rtl8xxxu_write32(priv, REG_USB_HIMR, 0);
+ cancel_delayed_work_sync(&priv->ra_watchdog);
+
rtl8xxxu_free_rx_resources(priv);
rtl8xxxu_free_tx_resources(priv);
}
@@ -6051,6 +6271,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
INIT_LIST_HEAD(&priv->rx_urb_pending_list);
spin_lock_init(&priv->rx_urb_lock);
INIT_WORK(&priv->rx_urb_wq, rtl8xxxu_rx_urb_work);
+ INIT_DELAYED_WORK(&priv->ra_watchdog, rtl8xxxu_watchdog_callback);
usb_set_intfdata(interface, hw);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next v3] net: phy: broadcom: add 1000Base-X support for BCM54616S
From: Andrew Lunn @ 2019-08-05 13:15 UTC (permalink / raw)
To: Tao Ren
Cc: Vladimir Oltean, Florian Fainelli, Heiner Kallweit,
David S . Miller, Arun Parameswaran, Justin Chen, netdev, lkml,
openbmc@lists.ozlabs.org
In-Reply-To: <2dd073b2-8495-593f-cd56-c39fd1c38a42@fb.com>
On Mon, Aug 05, 2019 at 06:38:16AM +0000, Tao Ren wrote:
> Hi Andrew,
>
> On 8/4/19 7:51 AM, Andrew Lunn wrote:
> >>> The patchset looks better now. But is it ok, I wonder, to keep
> >>> PHY_BCM_FLAGS_MODE_1000BX in phydev->dev_flags, considering that
> >>> phy_attach_direct is overwriting it?
> >>
> >
> >> I checked ftgmac100 driver (used on my machine) and it calls
> >> phy_connect_direct which passes phydev->dev_flags when calling
> >> phy_attach_direct: that explains why the flag is not cleared in my
> >> case.
> >
> > Yes, that is the way it is intended to be used. The MAC driver can
> > pass flags to the PHY. It is a fragile API, since the MAC needs to
> > know what PHY is being used, since the flags are driver specific.
> >
> > One option would be to modify the assignment in phy_attach_direct() to
> > OR in the flags passed to it with flags which are already in
> > phydev->dev_flags.
>
> It sounds like a reasonable fix/enhancement to replace overriding
> with OR, no matter which direction we are going to (either adding
> 1000bx aneg in genphy or providing phy-specific aneg callback).
> Do you want me to send out the patch (I feel it's better to be in a
> separate patch?) or someone else will take care of it?
Hi Tao
Please send a patch.
Thanks
Andrew
^ permalink raw reply
* Re: [RFC PATCH 1/2] dt-bindings: net: macb: Add new property for PS SGMII only
From: Andrew Lunn @ 2019-08-05 13:20 UTC (permalink / raw)
To: Harini Katakam
Cc: Harini Katakam, Nicolas Ferre, David Miller, Claudiu Beznea,
Rob Herring, Mark Rutland, netdev, linux-kernel, Michal Simek,
devicetree
In-Reply-To: <CAFcVECL6cvCjeo+fn1NDyMDZyZXDrWyhD9djvcVXiLVLiLgGeA@mail.gmail.com>
On Mon, Aug 05, 2019 at 11:45:05AM +0530, Harini Katakam wrote:
> Hi Andrew,
>
> On Sun, Aug 4, 2019 at 8:26 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > On Wed, Jul 31, 2019 at 03:10:32PM +0530, Harini Katakam wrote:
> > > Add a new property to indicate when PS SGMII is used with NO
> > > external PHY on board.
> >
> > Hi Harini
> >
> > What exactly is you use case? Are you connecting to a Ethernet switch?
> > To an SFP cage with a copper module?
>
> Yes, an SFP cage is the common HW target for this patch.
Hi Harini
So you have a copper PHY in the SFP cage. It will talk SGMII
signalling to your PS SGMII. When that signalling is complete i would
expect the MAC to raise an interrupt, just as if the SGMII PHY was
soldered on the board. So i don't see why you need this polling?
Andrew
^ permalink raw reply
* [PATCH] bonding: Add vlan tx offload to hw_enc_features
From: YueHaibing @ 2019-08-05 13:49 UTC (permalink / raw)
To: j.vosburgh, vfalico, andy, davem, jiri; +Cc: linux-kernel, netdev, YueHaibing
As commit 30d8177e8ac7 ("bonding: Always enable vlan tx offload")
said, we should always enable bonding's vlan tx offload, pass the
vlan packets to the slave devices with vlan tci, let them to handle
vlan implementation.
Now if encapsulation protocols like VXLAN is used, skb->encapsulation
may be set, then the packet is passed to vlan devicec which based on
bonding device. However in netif_skb_features(), the check of
hw_enc_features:
if (skb->encapsulation)
features &= dev->hw_enc_features;
clears NETIF_F_HW_VLAN_CTAG_TX/NETIF_F_HW_VLAN_STAG_TX. This results
in same issue in commit 30d8177e8ac7 like this:
vlan_dev_hard_start_xmit
-->dev_queue_xmit
-->validate_xmit_skb
-->netif_skb_features //NETIF_F_HW_VLAN_CTAG_TX is cleared
-->validate_xmit_vlan
-->__vlan_hwaccel_push_inside //skb->tci is cleared
...
--> bond_start_xmit
--> bond_xmit_hash //BOND_XMIT_POLICY_ENCAP34
--> __skb_flow_dissect // nhoff point to IP header
--> case htons(ETH_P_8021Q)
// skb_vlan_tag_present is false, so
vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
//vlan point to ip header wrongly
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/bonding/bond_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 02fd782..931d9d9 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1126,6 +1126,8 @@ static void bond_compute_features(struct bonding *bond)
done:
bond_dev->vlan_features = vlan_features;
bond_dev->hw_enc_features = enc_features | NETIF_F_GSO_ENCAP_ALL |
+ NETIF_F_HW_VLAN_CTAG_TX |
+ NETIF_F_HW_VLAN_STAG_TX |
NETIF_F_GSO_UDP_L4;
bond_dev->mpls_features = mpls_features;
bond_dev->gso_max_segs = gso_max_segs;
--
2.7.4
^ permalink raw reply related
* [PATCH 01/16] net: phy: adin: add support for Analog Devices PHYs
From: Alexandru Ardelean @ 2019-08-05 16:54 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190805165453.3989-1-alexandru.ardelean@analog.com>
This change adds support for Analog Devices Industrial Ethernet PHYs.
Particularly the PHYs this driver adds support for:
* ADIN1200 - Robust, Industrial, Low Power 10/100 Ethernet PHY
* ADIN1300 - Robust, Industrial, Low Latency 10/100/1000 Gigabit
Ethernet PHY
The 2 chips are pin & register compatible with one another. The main
difference being that ADIN1200 doesn't operate in gigabit mode.
The chips can be operated by the Generic PHY driver as well via the
standard IEEE PHY registers (0x0000 - 0x000F) which are supported by the
kernel as well. This assumes that configuration of the PHY has been done
required.
Configuration can also be done via registers, which will be implemented by
the driver in the next changes.
Datasheets:
https://www.analog.com/media/en/technical-documentation/data-sheets/ADIN1300.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/ADIN1200.pdf
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
MAINTAINERS | 7 +++++
drivers/net/phy/Kconfig | 9 ++++++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/adin.c | 59 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 76 insertions(+)
create mode 100644 drivers/net/phy/adin.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ee663e0e2f2e..faf5723610c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -938,6 +938,13 @@ S: Supported
F: drivers/mux/adgs1408.c
F: Documentation/devicetree/bindings/mux/adi,adgs1408.txt
+ANALOG DEVICES INC ADIN DRIVER
+M: Alexandru Ardelean <alexaundru.ardelean@analog.com>
+L: netdev@vger.kernel.org
+W: http://ez.analog.com/community/linux-device-drivers
+S: Supported
+F: drivers/net/phy/adin.c
+
ANALOG DEVICES INC ADIS DRIVER LIBRARY
M: Alexandru Ardelean <alexandru.ardelean@analog.com>
S: Supported
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 206d8650ee7f..5966d3413676 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -257,6 +257,15 @@ config SFP
depends on HWMON || HWMON=n
select MDIO_I2C
+config ADIN_PHY
+ tristate "Analog Devices Industrial Ethernet PHYs"
+ help
+ Adds support for the Analog Devices Industrial Ethernet PHYs.
+ Currently supports the:
+ - ADIN1200 - Robust,Industrial, Low Power 10/100 Ethernet PHY
+ - ADIN1300 - Robust,Industrial, Low Latency 10/100/1000 Gigabit
+ Ethernet PHY
+
config AMD_PHY
tristate "AMD PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index ba07c27e4208..a03437e091f3 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_SFP) += sfp.o
sfp-obj-$(CONFIG_SFP) += sfp-bus.o
obj-y += $(sfp-obj-y) $(sfp-obj-m)
+obj-$(CONFIG_ADIN_PHY) += adin.o
obj-$(CONFIG_AMD_PHY) += amd.o
aquantia-objs += aquantia_main.o
ifdef CONFIG_HWMON
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
new file mode 100644
index 000000000000..6a610d4563c3
--- /dev/null
+++ b/drivers/net/phy/adin.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * Driver for Analog Devices Industrial Ethernet PHYs
+ *
+ * Copyright 2019 Analog Devices Inc.
+ */
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/mii.h>
+#include <linux/phy.h>
+
+#define PHY_ID_ADIN1200 0x0283bc20
+#define PHY_ID_ADIN1300 0x0283bc30
+
+static int adin_config_init(struct phy_device *phydev)
+{
+ int rc;
+
+ rc = genphy_config_init(phydev);
+ if (rc < 0)
+ return rc;
+
+ return 0;
+}
+
+static struct phy_driver adin_driver[] = {
+ {
+ .phy_id = PHY_ID_ADIN1200,
+ .name = "ADIN1200",
+ .phy_id_mask = 0xfffffff0,
+ .features = PHY_BASIC_FEATURES,
+ .config_init = adin_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ },
+ {
+ .phy_id = PHY_ID_ADIN1300,
+ .name = "ADIN1300",
+ .phy_id_mask = 0xfffffff0,
+ .features = PHY_GBIT_FEATURES,
+ .config_init = adin_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ },
+};
+
+module_phy_driver(adin_driver);
+
+static struct mdio_device_id __maybe_unused adin_tbl[] = {
+ { PHY_ID_ADIN1200, 0xfffffff0 },
+ { PHY_ID_ADIN1300, 0xfffffff0 },
+ { }
+};
+
+MODULE_DEVICE_TABLE(mdio, adin_tbl);
+MODULE_DESCRIPTION("Analog Devices Industrial Ethernet PHY driver");
+MODULE_LICENSE("GPL");
--
2.20.1
^ permalink raw reply related
* [PATCH 04/16] net: phy: adin: add {write,read}_mmd hooks
From: Alexandru Ardelean @ 2019-08-05 16:54 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190805165453.3989-1-alexandru.ardelean@analog.com>
Both ADIN1200 & ADIN1300 support Clause 45 access.
The Extended Management Interface (EMI) registers are accessible via both
Clause 45 (at register MDIO_MMD_VEND1) and using Clause 22.
However, the Clause 22 MMD access operations differ from the implementation
in the kernel, in the sense that it uses registers ExtRegPtr (0x10) &
ExtRegData (0x11) to access Clause 45 & EMI registers.
The indirect access is done via the following mechanism (for both R/W):
1. Write the address of the register in the ExtRegPtr
2. Read/write the value of the register (written at ExtRegPtr)
This mechanism is needed to manage configuration of chip settings and to
access EEE registers (via Clause 22).
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 46 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index b75c723bda79..3dd9fe50f4c8 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -14,6 +14,9 @@
#define PHY_ID_ADIN1200 0x0283bc20
#define PHY_ID_ADIN1300 0x0283bc30
+#define ADIN1300_MII_EXT_REG_PTR 0x10
+#define ADIN1300_MII_EXT_REG_DATA 0x11
+
#define ADIN1300_INT_MASK_REG 0x0018
#define ADIN1300_INT_MDIO_SYNC_EN BIT(9)
#define ADIN1300_INT_ANEG_STAT_CHNG_EN BIT(8)
@@ -63,6 +66,45 @@ static int adin_phy_config_intr(struct phy_device *phydev)
ADIN1300_INT_MASK_EN);
}
+static int adin_read_mmd(struct phy_device *phydev, int devad, u16 regnum)
+{
+ struct mii_bus *bus = phydev->mdio.bus;
+ int phy_addr = phydev->mdio.addr;
+ int err;
+
+ if (phydev->is_c45) {
+ u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff);
+
+ return __mdiobus_read(bus, phy_addr, addr);
+ }
+
+ err = __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_PTR, regnum);
+ if (err)
+ return err;
+
+ return __mdiobus_read(bus, phy_addr, ADIN1300_MII_EXT_REG_DATA);
+}
+
+static int adin_write_mmd(struct phy_device *phydev, int devad, u16 regnum,
+ u16 val)
+{
+ struct mii_bus *bus = phydev->mdio.bus;
+ int phy_addr = phydev->mdio.addr;
+ int err;
+
+ if (phydev->is_c45) {
+ u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff);
+
+ return __mdiobus_write(bus, phy_addr, addr, val);
+ }
+
+ err = __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_PTR, regnum);
+ if (err)
+ return err;
+
+ return __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_DATA, val);
+}
+
static struct phy_driver adin_driver[] = {
{
.phy_id = PHY_ID_ADIN1200,
@@ -77,6 +119,8 @@ static struct phy_driver adin_driver[] = {
.config_intr = adin_phy_config_intr,
.resume = genphy_resume,
.suspend = genphy_suspend,
+ .read_mmd = adin_read_mmd,
+ .write_mmd = adin_write_mmd,
},
{
.phy_id = PHY_ID_ADIN1300,
@@ -91,6 +135,8 @@ static struct phy_driver adin_driver[] = {
.config_intr = adin_phy_config_intr,
.resume = genphy_resume,
.suspend = genphy_suspend,
+ .read_mmd = adin_read_mmd,
+ .write_mmd = adin_write_mmd,
},
};
--
2.20.1
^ permalink raw reply related
* [PATCH 09/16] net: phy: adin: add support MDI/MDIX/Auto-MDI selection
From: Alexandru Ardelean @ 2019-08-05 16:54 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190805165453.3989-1-alexandru.ardelean@analog.com>
The ADIN PHYs support automatic MDI/MDIX negotiation. By default this is
disabled, so this is enabled at `config_init`.
This is controlled via the PHY Control 1 register.
The supported modes are:
1. Manual MDI
2. Manual MDIX
3. Auto MDIX - prefer MDIX
4. Auto MDIX - prefer MDI
The phydev mdix & mdix_ctrl fields include modes 3 & 4 into a single
auto-mode. So, the default mode this driver enables is 4 when Auto-MDI mode
is used.
When detecting MDI/MDIX mode, a combination of the PHY Control 1 register
and PHY Status 1 register is used to determine the correct MDI/MDIX mode.
If Auto-MDI mode is not set, then the manual MDI/MDIX mode is returned.
If Auto-MDI mode is set, then MDIX mode is returned differs from the
preferred MDI/MDIX mode.
This covers all cases where:
1. MDI preferred & Pair01Swapped == MDIX
2. MDIX preferred & Pair01Swapped == MDI
3. MDI preferred & ! Pair01Swapped == MDIX
4. MDIX preferred & ! Pair01Swapped == MDI
The preferred MDI/MDIX mode is not configured via SW, but can be configured
via HW pins. Note that the `Pair01Swapped` is the Green-Yellow physical
pairs.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 117 +++++++++++++++++++++++++++++++++++++++--
1 file changed, 113 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index 2e27ffd403b4..31c600b7ec66 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -21,6 +21,10 @@
#define ADIN1300_MII_EXT_REG_PTR 0x10
#define ADIN1300_MII_EXT_REG_DATA 0x11
+#define ADIN1300_PHY_CTRL1 0x0012
+#define ADIN1300_AUTO_MDI_EN BIT(10)
+#define ADIN1300_MAN_MDIX_EN BIT(9)
+
#define ADIN1300_INT_MASK_REG 0x0018
#define ADIN1300_INT_MDIO_SYNC_EN BIT(9)
#define ADIN1300_INT_ANEG_STAT_CHNG_EN BIT(8)
@@ -37,6 +41,9 @@
ADIN1300_INT_HW_IRQ_EN)
#define ADIN1300_INT_STATUS_REG 0x0019
+#define ADIN1300_PHY_STATUS1 0x001a
+#define ADIN1300_PAIR_01_SWAP BIT(11)
+
#define ADIN1300_GE_RGMII_CFG_REG 0xff23
#define ADIN1300_GE_RGMII_RX_MSK GENMASK(8, 6)
#define ADIN1300_GE_RGMII_RX_SEL(x) \
@@ -175,6 +182,8 @@ static int adin_config_init(struct phy_device *phydev)
{
phy_interface_t interface, rc;
+ phydev->mdix_ctrl = ETH_TP_MDI_AUTO;
+
rc = genphy_config_init(phydev);
if (rc < 0)
return rc;
@@ -263,6 +272,106 @@ static int adin_write_mmd(struct phy_device *phydev, int devad, u16 regnum,
return __mdiobus_write(bus, phy_addr, ADIN1300_MII_EXT_REG_DATA, val);
}
+static int adin_config_mdix(struct phy_device *phydev)
+{
+ bool auto_en, mdix_en;
+ int reg;
+
+ mdix_en = false;
+ auto_en = false;
+ switch (phydev->mdix_ctrl) {
+ case ETH_TP_MDI:
+ break;
+ case ETH_TP_MDI_X:
+ mdix_en = true;
+ break;
+ case ETH_TP_MDI_AUTO:
+ auto_en = true;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ reg = phy_read(phydev, ADIN1300_PHY_CTRL1);
+ if (reg < 0)
+ return reg;
+
+ if (mdix_en)
+ reg |= ADIN1300_MAN_MDIX_EN;
+ else
+ reg &= ~ADIN1300_MAN_MDIX_EN;
+
+ if (auto_en)
+ reg |= ADIN1300_AUTO_MDI_EN;
+ else
+ reg &= ~ADIN1300_AUTO_MDI_EN;
+
+ return phy_write(phydev, ADIN1300_PHY_CTRL1, reg);
+}
+
+static int adin_config_aneg(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = adin_config_mdix(phydev);
+ if (ret)
+ return ret;
+
+ return genphy_config_aneg(phydev);
+}
+
+static int adin_mdix_update(struct phy_device *phydev)
+{
+ bool auto_en, mdix_en;
+ bool swapped;
+ int reg;
+
+ reg = phy_read(phydev, ADIN1300_PHY_CTRL1);
+ if (reg < 0)
+ return reg;
+
+ auto_en = !!(reg & ADIN1300_AUTO_MDI_EN);
+ mdix_en = !!(reg & ADIN1300_MAN_MDIX_EN);
+
+ /* If MDI/MDIX is forced, just read it from the control reg */
+ if (!auto_en) {
+ if (mdix_en)
+ phydev->mdix = ETH_TP_MDI_X;
+ else
+ phydev->mdix = ETH_TP_MDI;
+ return 0;
+ }
+
+ /**
+ * Otherwise, we need to deduce it from the PHY status2 reg.
+ * When Auto-MDI is enabled, the ADIN1300_MAN_MDIX_EN bit implies
+ * a preference for MDIX when it is set.
+ */
+ reg = phy_read(phydev, ADIN1300_PHY_STATUS1);
+ if (reg < 0)
+ return reg;
+
+ swapped = !!(reg & ADIN1300_PAIR_01_SWAP);
+
+ if (mdix_en != swapped)
+ phydev->mdix = ETH_TP_MDI_X;
+ else
+ phydev->mdix = ETH_TP_MDI;
+
+ return 0;
+}
+
+static int adin_read_status(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = adin_mdix_update(phydev);
+ if (ret < 0)
+ return ret;
+
+ return genphy_read_status(phydev);
+}
+
static struct phy_driver adin_driver[] = {
{
.phy_id = PHY_ID_ADIN1200,
@@ -271,8 +380,8 @@ static struct phy_driver adin_driver[] = {
.features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = adin_config_init,
- .config_aneg = genphy_config_aneg,
- .read_status = genphy_read_status,
+ .config_aneg = adin_config_aneg,
+ .read_status = adin_read_status,
.ack_interrupt = adin_phy_ack_intr,
.config_intr = adin_phy_config_intr,
.resume = genphy_resume,
@@ -287,8 +396,8 @@ static struct phy_driver adin_driver[] = {
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = adin_config_init,
- .config_aneg = genphy_config_aneg,
- .read_status = genphy_read_status,
+ .config_aneg = adin_config_aneg,
+ .read_status = adin_read_status,
.ack_interrupt = adin_phy_ack_intr,
.config_intr = adin_phy_config_intr,
.resume = genphy_resume,
--
2.20.1
^ permalink raw reply related
* [PATCH 07/16] net: phy: adin: make RGMII internal delays configurable
From: Alexandru Ardelean @ 2019-08-05 16:54 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, hkallweit1, andrew,
Alexandru Ardelean
In-Reply-To: <20190805165453.3989-1-alexandru.ardelean@analog.com>
The internal delays for the RGMII are configurable for both RX & TX. This
change adds support for configuring them via device-tree (or ACPI).
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/net/phy/adin.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index e3d2ff8cc09c..cb96d47d457e 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -5,6 +5,7 @@
* Copyright 2019 Analog Devices Inc.
*/
#include <linux/kernel.h>
+#include <linux/bitfield.h>
#include <linux/errno.h>
#include <linux/init.h>
#include <linux/module.h>
@@ -12,6 +13,8 @@
#include <linux/phy.h>
#include <linux/property.h>
+#include <dt-bindings/net/adin.h>
+
#define PHY_ID_ADIN1200 0x0283bc20
#define PHY_ID_ADIN1300 0x0283bc30
@@ -35,6 +38,12 @@
#define ADIN1300_INT_STATUS_REG 0x0019
#define ADIN1300_GE_RGMII_CFG_REG 0xff23
+#define ADIN1300_GE_RGMII_RX_MSK GENMASK(8, 6)
+#define ADIN1300_GE_RGMII_RX_SEL(x) \
+ FIELD_PREP(ADIN1300_GE_RGMII_RX_MSK, x)
+#define ADIN1300_GE_RGMII_GTX_MSK GENMASK(5, 3)
+#define ADIN1300_GE_RGMII_GTX_SEL(x) \
+ FIELD_PREP(ADIN1300_GE_RGMII_GTX_MSK, x)
#define ADIN1300_GE_RGMII_RXID_EN BIT(2)
#define ADIN1300_GE_RGMII_TXID_EN BIT(1)
#define ADIN1300_GE_RGMII_EN BIT(0)
@@ -67,6 +76,32 @@ static int adin_get_phy_internal_mode(struct phy_device *phydev)
return -EINVAL;
}
+static void adin_config_rgmii_rx_internal_delay(struct phy_device *phydev,
+ int *reg)
+{
+ struct device *dev = &phydev->mdio.dev;
+ u32 val;
+
+ if (device_property_read_u32(dev, "adi,rx-internal-delay", &val))
+ val = ADIN1300_RGMII_2_00_NS;
+
+ *reg &= ADIN1300_GE_RGMII_RX_MSK;
+ *reg |= ADIN1300_GE_RGMII_RX_SEL(val);
+}
+
+static void adin_config_rgmii_tx_internal_delay(struct phy_device *phydev,
+ int *reg)
+{
+ struct device *dev = &phydev->mdio.dev;
+ u32 val;
+
+ if (device_property_read_u32(dev, "adi,tx-internal-delay", &val))
+ val = ADIN1300_RGMII_2_00_NS;
+
+ *reg &= ADIN1300_GE_RGMII_GTX_MSK;
+ *reg |= ADIN1300_GE_RGMII_GTX_SEL(val);
+}
+
static int adin_config_rgmii_mode(struct phy_device *phydev,
phy_interface_t intf)
{
@@ -86,6 +121,7 @@ static int adin_config_rgmii_mode(struct phy_device *phydev,
if (intf == PHY_INTERFACE_MODE_RGMII_ID ||
intf == PHY_INTERFACE_MODE_RGMII_RXID) {
reg |= ADIN1300_GE_RGMII_RXID_EN;
+ adin_config_rgmii_rx_internal_delay(phydev, ®);
} else {
reg &= ~ADIN1300_GE_RGMII_RXID_EN;
}
@@ -93,6 +129,7 @@ static int adin_config_rgmii_mode(struct phy_device *phydev,
if (intf == PHY_INTERFACE_MODE_RGMII_ID ||
intf == PHY_INTERFACE_MODE_RGMII_TXID) {
reg |= ADIN1300_GE_RGMII_TXID_EN;
+ adin_config_rgmii_tx_internal_delay(phydev, ®);
} else {
reg &= ~ADIN1300_GE_RGMII_TXID_EN;
}
--
2.20.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