* Re: [patch iproute2 1/2] devlink: introduce cmdline option to switch to a different namespace
From: Jiri Pirko @ 2019-07-30 6:07 UTC (permalink / raw)
To: David Ahern
Cc: Toke Høiland-Jørgensen, netdev, davem, jakub.kicinski,
sthemmin, mlxsw
In-Reply-To: <d590ac7b-9dc7-41e2-e411-79ac4654c709@gmail.com>
Mon, Jul 29, 2019 at 10:21:11PM CEST, dsahern@gmail.com wrote:
>On 7/27/19 4:21 AM, Jiri Pirko wrote:
>>>> diff --git a/devlink/devlink.c b/devlink/devlink.c
>>>> index d8197ea3a478..9242cc05ad0c 100644
>>>> --- a/devlink/devlink.c
>>>> +++ b/devlink/devlink.c
>>>> @@ -32,6 +32,7 @@
>>>> #include "mnlg.h"
>>>> #include "json_writer.h"
>>>> #include "utils.h"
>>>> +#include "namespace.h"
>>>>
>>>> #define ESWITCH_MODE_LEGACY "legacy"
>>>> #define ESWITCH_MODE_SWITCHDEV "switchdev"
>>>> @@ -6332,7 +6333,7 @@ static int cmd_health(struct dl *dl)
>>>> static void help(void)
>>>> {
>>>> pr_err("Usage: devlink [ OPTIONS ] OBJECT { COMMAND | help }\n"
>>>> - " devlink [ -f[orce] ] -b[atch] filename\n"
>>>> + " devlink [ -f[orce] ] -b[atch] filename -N[etns]
>>>> netnsname\n"
>>>
>>> 'ip' uses lower-case n for this; why not be consistent?
>>
>> Because "n" is taken :/
>
>that's really unfortunate. commands within a package should have similar
>syntax and -n/N are backwards between ip/tc and devlink. That's the
>stuff that drives users crazy.
I agree. But this particular ship has sailed :(
^ permalink raw reply
* Re: [patch net-next 3/3] netdevsim: create devlink and netdev instances in namespace
From: Jiri Pirko @ 2019-07-30 6:06 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, davem, sthemmin, dsahern, mlxsw
In-Reply-To: <20190729115906.6bc2176d@cakuba.netronome.com>
Mon, Jul 29, 2019 at 08:59:06PM CEST, jakub.kicinski@netronome.com wrote:
>On Sat, 27 Jul 2019 11:44:59 +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> When user does create new netdevsim instance using sysfs bus file,
>> create the devlink instance and related netdev instance in the namespace
>> of the caller.
>>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>
>> diff --git a/drivers/net/netdevsim/bus.c b/drivers/net/netdevsim/bus.c
>> index 1a0ff3d7747b..6aeed0c600f8 100644
>> --- a/drivers/net/netdevsim/bus.c
>> +++ b/drivers/net/netdevsim/bus.c
>> @@ -283,6 +283,7 @@ nsim_bus_dev_new(unsigned int id, unsigned int port_count)
>> nsim_bus_dev->dev.bus = &nsim_bus;
>> nsim_bus_dev->dev.type = &nsim_bus_dev_type;
>> nsim_bus_dev->port_count = port_count;
>> + nsim_bus_dev->initial_net = current->nsproxy->net_ns;
>>
>> err = device_register(&nsim_bus_dev->dev);
>> if (err)
>
>The saved initial_net is only to carry the net info from the adding
>process to the probe callback, because probe can be asynchronous?
Exactly.
>I'm not entirely sure netdevsim can probe asynchronously in practice
>given we never return EPROBE_DEFER, but would you mind at least adding
>a comment stating that next to the definition of the field, otherwise
>I worry someone may mistakenly use this field instead of the up-to-date
>devlink's netns.
Will do.
>
>> diff --git a/drivers/net/netdevsim/netdevsim.h b/drivers/net/netdevsim/netdevsim.h
>> index 79c05af2a7c0..cdf53d0e0c49 100644
>> --- a/drivers/net/netdevsim/netdevsim.h
>> +++ b/drivers/net/netdevsim/netdevsim.h
>> @@ -19,6 +19,7 @@
>> #include <linux/netdevice.h>
>> #include <linux/u64_stats_sync.h>
>> #include <net/devlink.h>
>> +#include <net/net_namespace.h>
>
>You can just do a forward declaration, no need to pull in the header.
Sure, but why?
>
>> #include <net/xdp.h>
>>
>> #define DRV_NAME "netdevsim"
>
>> @@ -213,6 +215,7 @@ struct nsim_bus_dev {
>> struct device dev;
>> struct list_head list;
>> unsigned int port_count;
>> + struct net *initial_net;
>> unsigned int num_vfs;
>> struct nsim_vf_config *vfconfigs;
>> };
>
>Otherwise makes perfect sense, with the above nits addressed feel free
>to add:
>
>Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* Re: [patch net-next 1/3] net: devlink: allow to change namespaces
From: Jiri Pirko @ 2019-07-30 6:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jakub.kicinski, sthemmin, dsahern, mlxsw
In-Reply-To: <20190729.105216.2073541569967891866.davem@davemloft.net>
Mon, Jul 29, 2019 at 07:52:16PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Sat, 27 Jul 2019 11:44:57 +0200
>
>> + if ((netns_pid_attr && (netns_fd_attr || netns_id_attr)) ||
>> + (netns_fd_attr && (netns_pid_attr || netns_id_attr)) ||
>> + (netns_id_attr && (netns_pid_attr || netns_fd_attr))) {
>> + NL_SET_ERR_MSG(info->extack, "multiple netns identifying attributes specified");
>> + return ERR_PTR(-EINVAL);
>> + }
>
>How about:
>
> if (!!a + !!b + !!c > 1) {
> ...
I just copied the logic from the existing code. But sure :)
>
>> +
>> + if (netns_pid_attr) {
>> + net = get_net_ns_by_pid(nla_get_u32(netns_pid_attr));
>> + } else if (netns_fd_attr) {
>> + net = get_net_ns_by_fd(nla_get_u32(netns_fd_attr));
>> + } else if (netns_id_attr) {
>> + net = get_net_ns_by_id(sock_net(skb->sk),
>> + nla_get_u32(netns_id_attr));
>> + if (!net)
>> + net = ERR_PTR(-EINVAL);
>> + }
>> + if (IS_ERR(net)) {
>
>I think this is going to be one of those cases where a compiler won't be able
>to prove that 'net' is guaranteed to be initialized at this spot. Please
>rearrange this code somehow so that is unlikely to happen.
It does not complain though. The function cannot be entered unless at
least one is. I'll check again.
>
>Thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S
From: Heiner Kallweit @ 2019-07-30 6:00 UTC (permalink / raw)
To: Tao Ren, Andrew Lunn
Cc: Florian Fainelli, David S . Miller, Arun Parameswaran,
Justin Chen, Vladimir Oltean, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Andrew Jeffery,
openbmc@lists.ozlabs.org
In-Reply-To: <aff2728d-5db1-50fd-767c-29b355890323@fb.com>
On 30.07.2019 07:05, Tao Ren wrote:
> On 7/29/19 8:35 PM, Andrew Lunn wrote:
>> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote:
>>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc
>>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic
>>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber
>>> mode (different sets of MII Control/Status registers being used), let's
>>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly.
>>
>> Hi Tao
>>
>> What exactly does it get wrong?
>>
>> Thanks
>> Andrew
>
> Hi Andrew,
>
> BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of the features (1000BaseT/100BaseT/10BaseT) can be detected by genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half ability in this mode.
>
Are you going to use the PHY in copper or fibre mode?
In case you use fibre mode, why do you need the copper modes set as supported?
Or does the PHY just start in fibre mode and you want to switch it to copper mode?
>
> Thanks,
>
> Tao
>
Heiner
^ permalink raw reply
* Re: [PATCH bpf-next 00/10] CO-RE offset relocations
From: Song Liu @ 2019-07-30 5:27 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Song Liu, Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Yonghong Song, Kernel Team
In-Reply-To: <CAEf4BzbKYi53TdF9nAB3i3gAuca8FjM_P3F5aHp1uQ6coMgZ9A@mail.gmail.com>
> On Jul 29, 2019, at 4:09 PM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Mon, Jul 29, 2019 at 1:37 PM Song Liu <liu.song.a23@gmail.com> wrote:
>>
>> On Mon, Jul 29, 2019 at 1:20 PM Song Liu <liu.song.a23@gmail.com> wrote:
>>>
>>> On Wed, Jul 24, 2019 at 1:34 PM Andrii Nakryiko <andriin@fb.com> wrote:
>>>>
>>>> This patch set implements central part of CO-RE (Compile Once - Run
>>>> Everywhere, see [0] and [1] for slides and video): relocating field offsets.
>>>> Most of the details are written down as comments to corresponding parts of the
>>>> code.
>>>>
>>>> Patch #1 adds loading of .BTF.ext offset relocations section and macros to
>>>> work with its contents.
>>>> Patch #2 implements CO-RE relocations algorithm in libbpf.
>>>> Patches #3-#10 adds selftests validating various parts of relocation handling,
>>>> type compatibility, etc.
>>>>
>>>> For all tests to work, you'll need latest Clang/LLVM supporting
>>>> __builtin_preserve_access_index intrinsic, used for recording offset
>>>> relocations. Kernel on which selftests run should have BTF information built
>>>> in (CONFIG_DEBUG_INFO_BTF=y).
>>>>
>>>> [0] http://vger.kernel.org/bpfconf2019.html#session-2
>>>> [1] http://vger.kernel.org/lpc-bpf2018.html#session-2CO-RE relocations
>>>>
>>>> This patch set implements central part of CO-RE (Compile Once - Run
>>>> Everywhere, see [0] and [1] for slides and video): relocating field offsets.
>>>> Most of the details are written down as comments to corresponding parts of the
>>>> code.
>>>>
>>>> Patch #1 adds loading of .BTF.ext offset relocations section and macros to
>>>> work with its contents.
>>>> Patch #2 implements CO-RE relocations algorithm in libbpf.
>>>> Patches #3-#10 adds selftests validating various parts of relocation handling,
>>>> type compatibility, etc.
>>>>
>>>> For all tests to work, you'll need latest Clang/LLVM supporting
>>>> __builtin_preserve_access_index intrinsic, used for recording offset
>>>> relocations. Kernel on which selftests run should have BTF information built
>>>> in (CONFIG_DEBUG_INFO_BTF=y).
>>>>
>>>> [0] http://vger.kernel.org/bpfconf2019.html#session-2
>>>> [1] http://vger.kernel.org/lpc-bpf2018.html#session-2
>>>>
>>>> Andrii Nakryiko (10):
>>>> libbpf: add .BTF.ext offset relocation section loading
>>>> libbpf: implement BPF CO-RE offset relocation algorithm
>>>> selftests/bpf: add CO-RE relocs testing setup
>>>> selftests/bpf: add CO-RE relocs struct flavors tests
>>>> selftests/bpf: add CO-RE relocs nesting tests
>>>> selftests/bpf: add CO-RE relocs array tests
>>>> selftests/bpf: add CO-RE relocs enum/ptr/func_proto tests
>>>> selftests/bpf: add CO-RE relocs modifiers/typedef tests
>>>> selftest/bpf: add CO-RE relocs ptr-as-array tests
>>>> selftests/bpf: add CO-RE relocs ints tests
>>>>
>>>> tools/lib/bpf/btf.c | 64 +-
>>>> tools/lib/bpf/btf.h | 4 +
>>>> tools/lib/bpf/libbpf.c | 866 +++++++++++++++++-
>>>> tools/lib/bpf/libbpf.h | 1 +
>>>> tools/lib/bpf/libbpf_internal.h | 91 ++
>>>> .../selftests/bpf/prog_tests/core_reloc.c | 363 ++++++++
>>>> .../bpf/progs/btf__core_reloc_arrays.c | 3 +
>>>> .../btf__core_reloc_arrays___diff_arr_dim.c | 3 +
>>>> ...btf__core_reloc_arrays___diff_arr_val_sz.c | 3 +
>>>> .../btf__core_reloc_arrays___err_non_array.c | 3 +
>>>> ...btf__core_reloc_arrays___err_too_shallow.c | 3 +
>>>> .../btf__core_reloc_arrays___err_too_small.c | 3 +
>>>> ..._core_reloc_arrays___err_wrong_val_type1.c | 3 +
>>>> ..._core_reloc_arrays___err_wrong_val_type2.c | 3 +
>>>> .../bpf/progs/btf__core_reloc_flavors.c | 3 +
>>>> .../btf__core_reloc_flavors__err_wrong_name.c | 3 +
>>>> .../bpf/progs/btf__core_reloc_ints.c | 3 +
>>>> .../bpf/progs/btf__core_reloc_ints___bool.c | 3 +
>>>> .../btf__core_reloc_ints___err_bitfield.c | 3 +
>>>> .../btf__core_reloc_ints___err_wrong_sz_16.c | 3 +
>>>> .../btf__core_reloc_ints___err_wrong_sz_32.c | 3 +
>>>> .../btf__core_reloc_ints___err_wrong_sz_64.c | 3 +
>>>> .../btf__core_reloc_ints___err_wrong_sz_8.c | 3 +
>>>> .../btf__core_reloc_ints___reverse_sign.c | 3 +
>>>> .../bpf/progs/btf__core_reloc_mods.c | 3 +
>>>> .../progs/btf__core_reloc_mods___mod_swap.c | 3 +
>>>> .../progs/btf__core_reloc_mods___typedefs.c | 3 +
>>>> .../bpf/progs/btf__core_reloc_nesting.c | 3 +
>>>> .../btf__core_reloc_nesting___anon_embed.c | 3 +
>>>> ...f__core_reloc_nesting___dup_compat_types.c | 5 +
>>>> ...core_reloc_nesting___err_array_container.c | 3 +
>>>> ...tf__core_reloc_nesting___err_array_field.c | 3 +
>>>> ...e_reloc_nesting___err_dup_incompat_types.c | 4 +
>>>> ...re_reloc_nesting___err_missing_container.c | 3 +
>>>> ...__core_reloc_nesting___err_missing_field.c | 3 +
>>>> ..._reloc_nesting___err_nonstruct_container.c | 3 +
>>>> ...e_reloc_nesting___err_partial_match_dups.c | 4 +
>>>> .../btf__core_reloc_nesting___err_too_deep.c | 3 +
>>>> .../btf__core_reloc_nesting___extra_nesting.c | 3 +
>>>> ..._core_reloc_nesting___struct_union_mixup.c | 3 +
>>>> .../bpf/progs/btf__core_reloc_primitives.c | 3 +
>>>> ...f__core_reloc_primitives___diff_enum_def.c | 3 +
>>>> ..._core_reloc_primitives___diff_func_proto.c | 3 +
>>>> ...f__core_reloc_primitives___diff_ptr_type.c | 3 +
>>>> ...tf__core_reloc_primitives___err_non_enum.c | 3 +
>>>> ...btf__core_reloc_primitives___err_non_int.c | 3 +
>>>> ...btf__core_reloc_primitives___err_non_ptr.c | 3 +
>>>> .../bpf/progs/btf__core_reloc_ptr_as_arr.c | 3 +
>>>> .../btf__core_reloc_ptr_as_arr___diff_sz.c | 3 +
>>>> .../selftests/bpf/progs/core_reloc_types.h | 642 +++++++++++++
>>>> .../bpf/progs/test_core_reloc_arrays.c | 58 ++
>>>> .../bpf/progs/test_core_reloc_flavors.c | 65 ++
>>>> .../bpf/progs/test_core_reloc_ints.c | 48 +
>>>> .../bpf/progs/test_core_reloc_kernel.c | 39 +
>>>> .../bpf/progs/test_core_reloc_mods.c | 68 ++
>>>> .../bpf/progs/test_core_reloc_nesting.c | 48 +
>>>> .../bpf/progs/test_core_reloc_primitives.c | 50 +
>>>> .../bpf/progs/test_core_reloc_ptr_as_arr.c | 34 +
>>>> 58 files changed, 2527 insertions(+), 47 deletions(-)
>>>> create mode 100644 tools/testing/selftests/bpf/prog_tests/core_reloc.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_arrays.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_arrays___diff_arr_dim.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_arrays___diff_arr_val_sz.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_arrays___err_non_array.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_arrays___err_too_shallow.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_arrays___err_too_small.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_arrays___err_wrong_val_type1.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_arrays___err_wrong_val_type2.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_flavors.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_flavors__err_wrong_name.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_ints.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_ints___bool.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_ints___err_bitfield.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_ints___err_wrong_sz_16.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_ints___err_wrong_sz_32.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_ints___err_wrong_sz_64.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_ints___err_wrong_sz_8.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_ints___reverse_sign.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_mods.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_mods___mod_swap.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_mods___typedefs.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___anon_embed.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___dup_compat_types.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___err_array_container.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___err_array_field.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___err_dup_incompat_types.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___err_missing_container.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___err_missing_field.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___err_nonstruct_container.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___err_partial_match_dups.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___err_too_deep.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___extra_nesting.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_nesting___struct_union_mixup.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_primitives.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_primitives___diff_enum_def.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_primitives___diff_func_proto.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_primitives___diff_ptr_type.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_primitives___err_non_enum.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_primitives___err_non_int.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_primitives___err_non_ptr.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_ptr_as_arr.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_ptr_as_arr___diff_sz.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/core_reloc_types.h
>>>> create mode 100644 tools/testing/selftests/bpf/progs/test_core_reloc_arrays.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/test_core_reloc_flavors.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/test_core_reloc_ints.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/test_core_reloc_kernel.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/test_core_reloc_mods.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/test_core_reloc_nesting.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/test_core_reloc_primitives.c
>>>> create mode 100644 tools/testing/selftests/bpf/progs/test_core_reloc_ptr_as_arr.c
>>>
>>> We have created a lot of small files. Would it be cleaner if we can
>>> somehow put these
>>> data in one file (maybe different sections?).
>>
>> After reading more, I guess you have tried this and end up with current
>> design: keep most struct defines in core_reloc_types.h.
>
> Yeah, I have all the definition in one header file, but then I need
> individual combinations as separate BTFs, so I essentially "pick"
> desired types using function declarations. Creating those BTFs by hand
> would be a nightmare to create and maintain.
>
>>
>>>
>>> Alternatively, maybe create a folder for these files:
>>> tools/testing/selftests/bpf/progs/core/
>>
>> I guess this would still make it cleaner.
>
> There is nothing too special about core tests to split them. Also it
> would require Makefile changes and would deviate test_progs
> definitions from analogous test_maps, test_verifier, test_btf, etc, so
> I'm not sure about that. I though about putting those btf__* files
> under separate directory, but I'm on the fence there as well, as I'd
> rather have related files to stay together...
>
I guess we can defer this decision to later. So I am OK with current
approach for now.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Song Liu @ 2019-07-30 5:07 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, Kees Cook, linux-security@vger.kernel.org,
Networking, bpf, Alexei Starovoitov, Daniel Borkmann, Kernel Team,
Lorenz Bauer, Jann Horn, Greg KH, Linux API
In-Reply-To: <77354A95-4107-41A7-8936-D144F01C3CA4@fb.com>
Hi Andy,
> On Jul 27, 2019, at 11:20 AM, Song Liu <songliubraving@fb.com> wrote:
>
> Hi Andy,
>
>>>>>
>>>>
>>>> Well, yes. sys_bpf() is pretty powerful.
>>>>
>>>> The goal of /dev/bpf is to enable special users to call sys_bpf(). In
>>>> the meanwhile, such users should not take down the whole system easily
>>>> by accident, e.g., with rm -rf /.
>>>
>>> That’s easy, though — bpftool could learn to read /etc/bpfusers before allowing ruid != 0.
>>
>> This is a great idea! fscaps + /etc/bpfusers should do the trick.
>
> After some discussions and more thinking on this, I have some concerns
> with the user space only approach.
>
> IIUC, your proposal for user space only approach is like:
>
> 1. bpftool (and other tools) check /etc/bpfusers and only do
> setuid for allowed users:
>
> int main()
> {
> if (/* uid in /etc/bpfusers */)
> setuid(0);
> sys_bpf(...);
> }
>
> 2. bpftool (and other tools) is installed with CAP_SETUID:
>
> setcap cap_setuid=e+p /bin/bpftool
>
> 3. sys admin maintains proper /etc/bpfusers.
>
> This approach is not ideal, because we need to trust the tool to give
> it CAP_SETUID. A hacked tool could easily bypass /etc/bpfusers check
> or use other root only sys calls after setuid(0).
>
I would like more comments on this.
Currently, bpf permission is more or less "root or nothing", which we
would like to change.
The short term goal is to separate bpf from root, in other words, it is
"all or nothing". Special user space utilities, such as systemd, would
benefit from this. Once this is implemented, systemd can call sys_bpf()
when it is not running as root.
In longer term, it may be useful to provide finer grain permission of
sys_bpf(). For example, sys_bpf() should be aware of containers; and
user may only have access to certain bpf maps. Let's call this
"fine grain" capability.
Since we are seeing new use cases every year, we will need many
iterations to implement the fine grain permission. I think we need an
API that is flexible enough to cover different types of permission
control.
For example, bpf_with_cap() can be flexible:
bpf_with_cap(cmd, attr, size, perm_fd);
We can get different types of permission via different combinations of
arguments:
A perm_fd to /dev/bpf gives access to all sys_bpf() commands, so
this is "all or nothing" permission.
A perm_fd to /sys/fs/cgroup/.../bpf.xxx would only allow some
commands to this specific cgroup.
Alexei raised another idea in offline discussions: instead of adding
bpf_with_cap(), we add a command LOAD_PERM_FD, which enables special
permission for the _next_ sys_bpf() from current task:
bpf(LOAD_PERM_FD, perm_fd);
/* the next sys_bpf() uses permission from perm_fd */
bpf(cmd, attr, size);
This is equivalent to bpf_with_cap(cmd, attr, size, perm_fd), but
doesn't require the new sys call.
For both these ideas, we will start with /dev/bpf. As we grow the
fine grain permission control, fewer users/processes will need access
to /dev/bpf.
Please let us know your thought on this. Would this make /dev/bpf
more reasonable? :-)
A few notes for previous discussions:
1. User space only approach doesn't work, even for "all or nothing"
permission control. I expanded the discussion in the previous
email. Please let me know if I missed anything there.
2. Permission control only at BPF_PROG_ATTACH time is not sufficient.
We need permission control during BPF_PROG_LOAD, e.g., is_priv in
the verifier.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S
From: Tao Ren @ 2019-07-30 5:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Heiner Kallweit, David S . Miller,
Arun Parameswaran, Justin Chen, Vladimir Oltean,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Jeffery, openbmc@lists.ozlabs.org
In-Reply-To: <20190730033558.GB20628@lunn.ch>
On 7/29/19 8:35 PM, Andrew Lunn wrote:
> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote:
>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc
>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic
>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber
>> mode (different sets of MII Control/Status registers being used), let's
>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly.
>
> Hi Tao
>
> What exactly does it get wrong?
>
> Thanks
> Andrew
Hi Andrew,
BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of the features (1000BaseT/100BaseT/10BaseT) can be detected by genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half ability in this mode.
Thanks,
Tao
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S
From: Tao Ren @ 2019-07-30 4:52 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S . Miller,
Arun Parameswaran, Justin Chen, netdev, lkml, Andrew Jeffery,
openbmc@lists.ozlabs.org
In-Reply-To: <CA+h21hq1+E6-ScFx425hXwTPTZHTVZbBuAm7RROFZTBOFvD8vQ@mail.gmail.com>
On 7/29/19 6:32 PM, Vladimir Oltean wrote:
> Hi Tao,
>
> On Tue, 30 Jul 2019 at 03:31, Tao Ren <taoren@fb.com> wrote:
>>
>> Configure the BCM54616S for 1000Base-X mode when "brcm-phy-mode-1000bx"
>> is set in device tree. This is needed when the PHY is used for fiber and
>> backplane connections.
>>
>> The patch is inspired by commit cd9af3dac6d1 ("PHYLIB: Add 1000Base-X
>> support for Broadcom bcm5482").
>
> As far as I can see, for the commit you referenced,
> PHY_BCM_FLAGS_MODE_1000BX is referenced from nowhere in the entire
> mainline kernel:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__elixir.bootlin.com_linux_latest_ident_PHY-5FBCM-5FFLAGS-5FMODE-5F1000BX&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=iYElT7HC77pRZ3byVvW8ng&m=gy6Y-3Ylme-_GQcGF4fvOX10irgAT4xh253Weo0np38&s=KL__E2bvsmvUL-hBL9hUmOS5vyPQ92EMj6fEfByn8t8&e=
> (it is supposed to be put by the MAC driver in phydev->dev_flags prior
> to calling phy_connect). But I don't see the point to this - can't you
> check for phydev->interface == PHY_INTERFACE_MODE_1000BASEX?
> This has the advantage that no MAC driver will need to know that it's
> talking to a Broadcom PHY. Additionally, no custom DT bindings are
> needed.
> Also, for backplane connections you probably want 1000Base-KX which
> has its own AN/LT, not plain 1000Base-X.
Thank you Vladimir for the quick review!
Perhaps I misunderstood the purpose of phydev->interface, and I thought it was usually used to defined the interface between MAC and PHY. For example, if I need to pass both "rgmii-id" and "1000base-x" from MAC to PHY driver, what would be the preferred way?
>> Signed-off-by: Tao Ren <taoren@fb.com>
>> ---
>> drivers/net/phy/broadcom.c | 58 +++++++++++++++++++++++++++++++++++---
>> include/linux/brcmphy.h | 4 +--
>> 2 files changed, 56 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
>> index 2b4e41a9d35a..6c22ac3a844b 100644
>> --- a/drivers/net/phy/broadcom.c
>> +++ b/drivers/net/phy/broadcom.c
>> @@ -383,9 +383,9 @@ static int bcm5482_config_init(struct phy_device *phydev)
>> /*
>> * Select 1000BASE-X register set (primary SerDes)
>> */
>> - reg = bcm_phy_read_shadow(phydev, BCM5482_SHD_MODE);
>> - bcm_phy_write_shadow(phydev, BCM5482_SHD_MODE,
>> - reg | BCM5482_SHD_MODE_1000BX);
>> + reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
>> + bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
>> + reg | BCM54XX_SHD_MODE_1000BX);
>>
>> /*
>> * LED1=ACTIVITYLED, LED3=LINKSPD[2]
>> @@ -451,6 +451,34 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
>> return ret;
>> }
>>
>> +static int bcm54616s_config_init(struct phy_device *phydev)
>> +{
>> + int err, reg;
>> + struct device_node *np = phydev->mdio.dev.of_node;
>> +
>> + err = bcm54xx_config_init(phydev);
>> +
>> + if (of_property_read_bool(np, "brcm-phy-mode-1000bx")) {
>> + /* Select 1000BASE-X register set. */
>> + reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
>> + bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
>> + reg | BCM54XX_SHD_MODE_1000BX);
>> +
>> + /* Auto-negotiation doesn't seem to work quite right
>> + * in this mode, so we disable it and force it to the
>> + * right speed/duplex setting. Only 'link status'
>> + * is important.
>> + */
>> + phydev->autoneg = AUTONEG_DISABLE;
>> + phydev->speed = SPEED_1000;
>> + phydev->duplex = DUPLEX_FULL;
>> +
>
> 1000Base-X AN does not include speed negotiation, so hardcoding
> SPEED_1000 is probably correct.
> What is wrong with the AN of duplex settings?
FULL_DUPLEX bit is set on my platform by default. Let me enable AN and test it out; will share you results tomorrow.
>> + phydev->dev_flags |= PHY_BCM_FLAGS_MODE_1000BX;
>> + }
>> +
>> + return err;
>> +}
>> +
>> static int bcm54616s_config_aneg(struct phy_device *phydev)
>> {
>> int ret;
>> @@ -464,6 +492,27 @@ static int bcm54616s_config_aneg(struct phy_device *phydev)
>> return ret;
>> }
>>
>> +static int bcm54616s_read_status(struct phy_device *phydev)
>> +{
>> + int ret;
>> +
>> + ret = genphy_read_status(phydev);
>> + if (ret < 0)
>> + return ret;
>> +
>> + if (phydev->dev_flags & PHY_BCM_FLAGS_MODE_1000BX) {
>> + /* Only link status matters for 1000Base-X mode, so force
>> + * 1000 Mbit/s full-duplex status.
>> + */
>> + if (phydev->link) {
>> + phydev->speed = SPEED_1000;
>> + phydev->duplex = DUPLEX_FULL;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int brcm_phy_setbits(struct phy_device *phydev, int reg, int set)
>> {
>> int val;
>> @@ -651,8 +700,9 @@ static struct phy_driver broadcom_drivers[] = {
>> .phy_id_mask = 0xfffffff0,
>> .name = "Broadcom BCM54616S",
>> .features = PHY_GBIT_FEATURES,
>> - .config_init = bcm54xx_config_init,
>> + .config_init = bcm54616s_config_init,
>> .config_aneg = bcm54616s_config_aneg,
>> + .read_status = bcm54616s_read_status,
>> .ack_interrupt = bcm_phy_ack_intr,
>> .config_intr = bcm_phy_config_intr,
>> }, {
>> diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
>> index 6db2d9a6e503..82030155558c 100644
>> --- a/include/linux/brcmphy.h
>> +++ b/include/linux/brcmphy.h
>> @@ -200,8 +200,8 @@
>> #define BCM5482_SHD_SSD 0x14 /* 10100: Secondary SerDes control */
>> #define BCM5482_SHD_SSD_LEDM 0x0008 /* SSD LED Mode enable */
>> #define BCM5482_SHD_SSD_EN 0x0001 /* SSD enable */
>> -#define BCM5482_SHD_MODE 0x1f /* 11111: Mode Control Register */
>> -#define BCM5482_SHD_MODE_1000BX 0x0001 /* Enable 1000BASE-X registers */
>> +#define BCM54XX_SHD_MODE 0x1f /* 11111: Mode Control Register */
>> +#define BCM54XX_SHD_MODE_1000BX 0x0001 /* Enable 1000BASE-X registers */
>
> These registers are also present on my BCM5464, probably safe to
> assume they're generic for the entire family.
> So if you make the registers definitions common, you can probably make
> the 1000Base-X configuration common as well.
If I understand correctly, your recommendation is to add a common function (such as "bcm54xx_config_1000bx") so it can be used by other BCM chips? Sure, I will take care of it.
Thanks,
Tao
^ permalink raw reply
* Re: [RFC] net: phy: read link status twice when phy_check_link_status()
From: liuyonglong @ 2019-07-30 4:03 UTC (permalink / raw)
To: Heiner Kallweit, andrew, davem
Cc: netdev, linux-kernel, linuxarm, salil.mehta, yisen.zhuang,
shiju.jose
In-Reply-To: <a0b26e4b-e288-cf44-049a-7d0b7f5696eb@gmail.com>
On 2019/7/30 4:57, Heiner Kallweit wrote:
> On 29.07.2019 05:59, liuyonglong wrote:
>>
>>
>> On 2019/7/27 2:14, Heiner Kallweit wrote:
>>> On 26.07.2019 11:53, Yonglong Liu wrote:
>>>> According to the datasheet of Marvell phy and Realtek phy, the
>>>> copper link status should read twice, or it may get a fake link
>>>> up status, and cause up->down->up at the first time when link up.
>>>> This happens more oftem at Realtek phy.
>>>>
>>> This is not correct, there is no fake link up status.
>>> Read the comment in genphy_update_link, only link-down events
>>> are latched. Means if the first read returns link up, then there
>>> is no need for a second read. And in polling mode we don't do a
>>> second read because we want to detect also short link drops.
>>>
>>> It would be helpful if you could describe your actual problem
>>> and whether you use polling or interrupt mode.
>>>
>>
>> [ 44.498633] hns3 0000:bd:00.1 eth5: net open
>> [ 44.504273] hns3 0000:bd:00.1: reg=0x1, data=0x79ad -> called from phy_start_aneg
>> [ 44.532348] hns3 0000:bd:00.1: reg=0x1, data=0x798d -> called from phy_state_machine,update link.
>
> This should not happen. The PHY indicates link up w/o having aneg finished.
>
>>
>> According to the datasheet:
>> reg 1.5=0 now, means copper auto-negotiation not complete
>> reg 1.2=1 now, means link is up
>>
>> We can see that, when we read the link up, the auto-negotiation
>> is not complete yet, so the speed is invalid.
>>
>> I don't know why this happen, maybe this state is keep from bios?
>> Or we may do something else in the phy initialize to fix it?
>> And also confuse that why read twice can fix it?
>>
> I suppose that basically any delay would do.
>
>> [ 44.554063] hns3 0000:bd:00.1: invalid speed (-1)
>> [ 44.560412] hns3 0000:bd:00.1 eth5: failed to adjust link.
>> [ 45.194870] hns3 0000:bd:00.1 eth5: link up
>> [ 45.574095] hns3 0000:bd:00.1: phyid=3, reg=0x1, data=0x7989
>> [ 46.150051] hns3 0000:bd:00.1 eth5: link down
>> [ 46.598074] hns3 0000:bd:00.1: phyid=3, reg=0x1, data=0x7989
>> [ 47.622075] hns3 0000:bd:00.1: phyid=3, reg=0x1, data=0x79a9
>> [ 48.646077] hns3 0000:bd:00.1: phyid=3, reg=0x1, data=0x79ad
>> [ 48.934050] hns3 0000:bd:00.1 eth5: link up
>> [ 49.702140] hns3 0000:bd:00.1: phyid=3, reg=0x1, data=0x79ad
>>
>>>> I add a fake status read, and can solve this problem.
>>>>
>>>> I also see that in genphy_update_link(), had delete the fake
>>>> read in polling mode, so I don't know whether my solution is
>>>> correct.
>>>>
>
> Can you test whether the following fixes the issue for you?
> Also it would be interesting which exact PHY models you tested
> and whether you built the respective PHY drivers or whether you
> rely on the genphy driver. Best use the second patch to get the
> needed info. It may make sense anyway to add the call to
> phy_attached_info() to the hns3 driver.
>
[ 40.100716] RTL8211F Gigabit Ethernet mii-0000:bd:00.3:07: attached PHY driver [RTL8211F Gigabit Ethernet] (mii_bus:phy_addr=mii-0000:bd:00.3:07, irq=POLL)
[ 40.932133] hns3 0000:bd:00.3 eth7: net open
[ 40.932458] hns3 0000:bd:00.3: invalid speed (-1)
[ 40.932541] 8021q: adding VLAN 0 to HW filter on device eth7
[ 40.937149] hns3 0000:bd:00.3 eth7: failed to adjust link.
[ 40.662050] Generic PHY mii-0000:bd:00.2:05: attached PHY driver [Generic PHY] (mii_bus:phy_addr=mii-0000:bd:00.2:05, irq=POLL)
[ 41.563511] hns3 0000:bd:00.2 eth6: net open
[ 41.563853] hns3 0000:bd:00.2: invalid speed (-1)
[ 41.563943] 8021q: adding VLAN 0 to HW filter on device eth6
[ 41.568578] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready
[ 41.568898] hns3 0000:bd:00.2 eth6: failed to adjust link.
I am using RTL8211F, but you can see that, both genphy driver and
RTL8211F driver have the same issue.
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 6b5cb87f3..fbecfe210 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1807,7 +1807,8 @@ int genphy_read_status(struct phy_device *phydev)
>
> linkmode_zero(phydev->lp_advertising);
>
> - if (phydev->autoneg == AUTONEG_ENABLE && phydev->autoneg_complete) {
> + if (phydev->autoneg == AUTONEG_ENABLE &&
> + (phydev->autoneg_complete || phydev->link)) {
> if (phydev->is_gigabit_capable) {
> lpagb = phy_read(phydev, MII_STAT1000);
> if (lpagb < 0)
>
I have try this patch, have no effect. I suppose that at this time,
the autoneg actually not complete yet.
Maybe the wrong phy state is passed from bios? Invalid speed just
happen at the first time when ethX up, after that, repeat the
ifconfig down/ifconfig up command can not see that again.
So I think the bios should power off the phy(writing reg 1.11 to 1)
before it starts the OS? Or any other way to fix this in the OS?
^ permalink raw reply
* Re: [PATCH v4 13/13] ARM: dts: sunxi: Switch from phy to phy-handle
From: Chen-Yu Tsai @ 2019-07-30 3:51 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Rob Herring, Frank Rowand, David S . Miller,
Maxime Coquelin, Alexandre Torgue, netdev, linux-arm-kernel,
devicetree, linux-stm32, Maxime Chevallier, Antoine Ténart,
Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <a1a33392c64c71099021fb49cc811a30790d40a8.1561649505.git-series.maxime.ripard@bootlin.com>
On Thu, Jun 27, 2019 at 11:32 PM Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
>
> The phy device tree property has been deprecated in favor of phy-handle,
> let's replace it.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
This patch breaks Ethernet on all my dwmac-sunxi, i.e. old GMAC, boards, with
the following error messages:
sun7i-dwmac 1c50000.ethernet eth0: no phy at addr -1
sun7i-dwmac 1c50000.ethernet eth0: stmmac_open: Cannot attach to
PHY (error: -19)
Reverting this patch fixes it.
It also breaks the A10/A10s, but that's probably because the sun4i-emac
driver doesn't recognize the "phy-handle" property.
ChenYu
^ permalink raw reply
* Re: [PATCH] net: phy: phy_led_triggers: Fix a possible null-pointer dereference in phy_led_trigger_change_speed()
From: David Miller @ 2019-07-30 3:41 UTC (permalink / raw)
To: andrew; +Cc: baijiaju1990, f.fainelli, hkallweit1, netdev, linux-kernel
In-Reply-To: <20190730033229.GA20628@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Tue, 30 Jul 2019 05:32:29 +0200
> On Tue, Jul 30, 2019 at 10:25:36AM +0800, Jia-Ju Bai wrote:
>>
>>
>> On 2019/7/29 21:45, Andrew Lunn wrote:
>> >On Mon, Jul 29, 2019 at 05:24:24PM +0800, Jia-Ju Bai wrote:
>> >>In phy_led_trigger_change_speed(), there is an if statement on line 48
>> >>to check whether phy->last_triggered is NULL:
>> >> if (!phy->last_triggered)
>> >>
>> >>When phy->last_triggered is NULL, it is used on line 52:
>> >> led_trigger_event(&phy->last_triggered->trigger, LED_OFF);
>> >>
>> >>Thus, a possible null-pointer dereference may occur.
>> >>
>> >>To fix this bug, led_trigger_event(&phy->last_triggered->trigger,
>> >>LED_OFF) is called when phy->last_triggered is not NULL.
>> >>
>> >>This bug is found by a static analysis tool STCheck written by us.
>> >Who is 'us'?
>>
>> Me and my colleague...
>
> Well, we can leave it very vague, giving no idea who 'us' is. But
> often you want to name the company behind it, or the university, or
> the sponsor, etc.
I agree, if you are going to mention that there is a tool you should be
clear exactly who and what organization are behind it.
Thank you.
^ permalink raw reply
* RE: [PATCH net-next v3 2/2] qed: Add driver API for flashing the config attributes.
From: Sudarsana Reddy Kalluru @ 2019-07-30 3:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Michal Kalderon, Ariel Elior
In-Reply-To: <20190729.110342.703558396264560468.davem@davemloft.net>
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Monday, July 29, 2019 11:34 PM
> To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Cc: netdev@vger.kernel.org; Michal Kalderon <mkalderon@marvell.com>;
> Ariel Elior <aelior@marvell.com>
> Subject: Re: [PATCH net-next v3 2/2] qed: Add driver API for flashing the
> config attributes.
>
> From: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Date: Sat, 27 Jul 2019 18:55:49 -0700
>
> > @@ -2268,6 +2330,9 @@ static int qed_nvm_flash(struct qed_dev *cdev,
> const char *name)
> > rc = qed_nvm_flash_image_access(cdev, &data,
> > &check_resp);
> > break;
> > + case QED_NVM_FLASH_CMD_NVM_CFG_ID:
> > + rc = qed_nvm_flash_cfg_write(cdev, &data);
> > + break;
> > default:
> > DP_ERR(cdev, "Unknown command %08x\n",
> cmd_type);
>
> I don't see how any existing portable interface can cause this new code to
> actually be used.
>
> You have to explain this to me.
The API qed_nvm_flash() is used to flash the user provided data (e.g., Management FW) to the required partitions of the adapter.
- Format of the input file would be - file signature info, followed by one or more data sets.
- Each data set is represented with the header followed by its contents. Header captures info such as command name (e.g., FILE_START), data size etc., which specifies how to handle the data.
The API qed_nvm_flash() validates the user provided input file, parses the data sets and handles each accordingly. Here one of the data sets (preferably the last one) could be nvm-attributes page (with cmd-id = QED_NVM_FLASH_CMD_NVM_CHANGE).
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S
From: Andrew Lunn @ 2019-07-30 3:35 UTC (permalink / raw)
To: Tao Ren
Cc: Florian Fainelli, Heiner Kallweit, David S . Miller,
Arun Parameswaran, Justin Chen, Vladimir Oltean, netdev,
linux-kernel, Andrew Jeffery, openbmc
In-Reply-To: <20190730002532.85509-1-taoren@fb.com>
On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote:
> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc
> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic
> feature detection doesn't work when BCM54616S is working in RGMII-Fiber
> mode (different sets of MII Control/Status registers being used), let's
> set "PHY_GBIT_FEATURES" for BCM54616S explicitly.
Hi Tao
What exactly does it get wrong?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH] net: phy: phy_led_triggers: Fix a possible null-pointer dereference in phy_led_trigger_change_speed()
From: Andrew Lunn @ 2019-07-30 3:32 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: f.fainelli, hkallweit1, davem, netdev, linux-kernel
In-Reply-To: <f603f3c3-f7c9-8dff-5f30-74174282819c@gmail.com>
On Tue, Jul 30, 2019 at 10:25:36AM +0800, Jia-Ju Bai wrote:
>
>
> On 2019/7/29 21:45, Andrew Lunn wrote:
> >On Mon, Jul 29, 2019 at 05:24:24PM +0800, Jia-Ju Bai wrote:
> >>In phy_led_trigger_change_speed(), there is an if statement on line 48
> >>to check whether phy->last_triggered is NULL:
> >> if (!phy->last_triggered)
> >>
> >>When phy->last_triggered is NULL, it is used on line 52:
> >> led_trigger_event(&phy->last_triggered->trigger, LED_OFF);
> >>
> >>Thus, a possible null-pointer dereference may occur.
> >>
> >>To fix this bug, led_trigger_event(&phy->last_triggered->trigger,
> >>LED_OFF) is called when phy->last_triggered is not NULL.
> >>
> >>This bug is found by a static analysis tool STCheck written by us.
> >Who is 'us'?
>
> Me and my colleague...
Well, we can leave it very vague, giving no idea who 'us' is. But
often you want to name the company behind it, or the university, or
the sponsor, etc.
Andrew
^ permalink raw reply
* RE: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
From: Tony Chuang @ 2019-07-30 3:11 UTC (permalink / raw)
To: Jian-Hong Pan, David Laight
Cc: Kalle Valo, David S . Miller, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux@endlessm.com, stable@vger.kernel.org
In-Reply-To: <CAPpJ_eey7+KCMFj2YVQD8ziWR_xf-==k9MYb49-32Z5E6vTdHA@mail.gmail.com>
> > > > While allocating all 512 buffers in one block (just over 4MB)
> > > > is probably not a good idea, you may need to allocated (and dma map)
> > > > then in groups.
> > >
> > > Thanks for reviewing. But got questions here to double confirm the
> idea.
> > > According to original code, it allocates 512 skbs for RX ring and dma
> > > mapping one by one. So, the new code allocates memory buffer 512
> > > times to get 512 buffer arrays. Will the 512 buffers arrays be in one
> > > block? Do you mean aggregate the buffers as a scatterlist and use
> > > dma_map_sg?
> >
> > If you malloc a buffer of size (8192+32) the allocator will either
> > round it up to a whole number of (often 4k) pages or to a power of
> > 2 of pages - so either 12k of 16k.
> > I think the Linux allocator does the latter.
> > Some of the allocators also 'steal' a bit from the front of the buffer
> > for 'red tape'.
> >
> > OTOH malloc the space 15 buffers and the allocator will round the
> > 15*(8192 + 32) up to 32*4k - and you waste under 8k across all the
> > buffers.
> >
> > You then dma_map the large buffer and split into the actual rx buffers.
> > Repeat until you've filled the entire ring.
> > The only complication is remembering the base address (and size) for
> > the dma_unmap and free.
> > Although there is plenty of padding to extend the buffer structure
> > significantly without using more memory.
> > Allocate in 15's and you (probably) have 512 bytes per buffer.
> > Allocate in 31's and you have 256 bytes.
> >
> > The problem is that larger allocates are more likely to fail
> > (especially if the system has been running for some time).
> > So you almost certainly want to be able to fall back to smaller
> > allocates even though they use more memory.
> >
> > I also wonder if you actually need 512 8k rx buffers to cover
> > interrupt latency?
> > I've not done any measurements for 20 years!
>
> Thanks for the explanation.
> I am not sure the combination of 512 8k RX buffers. Maybe Realtek
> folks can give us some idea.
> Tony Chuang any comment?
>
> Jian-Hong Pan
>
512 RX buffers is not necessary I think. But I haven't had a chance to
test if reduce the number of RX SKBs could affect the latency.
I can run some throughput tests and then decide a minimum numbers
that RX ring requires. Or if you can try it.
Thanks.
Yan-Hsuan
^ permalink raw reply
* Re: [PATCH v3] net: dsa: qca8k: enable port flow control
From: xiaofeis @ 2019-07-30 3:01 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, vkoul, netdev, linux-arm-msm, bjorn.andersson,
vivien.didelot, f.fainelli, niklas.cassel, xiazha
In-Reply-To: <20190729132342.GA4110@lunn.ch>
On 2019-07-29 21:23, Andrew Lunn wrote:
>> But our qca8k HW can auto sync the pause status to MAC from phy with
>> the
>> auto-negotiated result.
>> So no need to set in qca8k_adjust_link, since there is one setting in
>> qca8k_port_set_status: mask |= QCA8K_PORT_STATUS_LINK_AUTO;
>
> How does the auto-sync actually work? Does the MAC make MDIO reads to
> the PHY? That is generally unsafe, since some PHYs support pages, and
> the PHY driver might be using a different page while the MAC tries to
> access the auto-neg results.
>
> Do any of the ports support an external PHY? The auto-sync might not
> work in that condition as well. Different register layout, c45 not
> c22, etc.
>
> The safest option is to explicitly set the MAC flow configuration
> based on the values in phydev.
>
Hi Andrew
To explicitly set the configuration is one option, but then we need
disable QCA8K_PORT_STATUS_LINK_AUTO, and not only flow control,
speed/duplex all need to be set explicitly.
Here the qca8k driver is only support qca,qca8337/qca8334 switch family.
The phy is internal phy. There is signals internaly
to sync the status from phy to mac directly which is HW specific
implementation, it doesn't support to connect external phy.
Thanks
Xiaofeis
^ permalink raw reply
* [PATCH V2] can: flexcan: fix deadlock when using self wakeup
From: Joakim Zhang @ 2019-07-30 2:51 UTC (permalink / raw)
To: mkl@pengutronix.de, linux-can@vger.kernel.org, sean@geanix.com
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx,
Joakim Zhang
As reproted by Sean Nyekjaer below:
When suspending, when there is still can traffic on the interfaces the
flexcan immediately wakes the platform again. As it should :-). But it
throws this error msg:
[ 3169.378661] PM: noirq suspend of devices failed
On the way down to suspend the interface that throws the error message does
call flexcan_suspend but fails to call flexcan_noirq_suspend. That means the
flexcan_enter_stop_mode is called, but on the way out of suspend the driver
only calls flexcan_resume and skips flexcan_noirq_resume, thus it doesn't call
flexcan_exit_stop_mode. This leaves the flexcan in stop mode, and with the
current driver it can't recover from this even with a soft reboot, it requires
a hard reboot.
The best way to exit stop mode is in Wake Up interrupt context, and then
suspend() and resume() functions can be symmetric. However, stop mode
request and ack will be controlled by SCU(System Control Unit) firmware(manage
clock,power,stop mode, etc. by Cortex-M4 core) in coming i.MX8(QM/QXP). And SCU
firmware interface can't be available in interrupt context.
For compatibillity, the wake up mechanism can't be symmetric, so we need
in_stop_mode hack.
Fixes: de3578c198c6 ("can: flexcan: add self wakeup support")
Reported-by: Sean Nyekjaer <sean@geanix.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Changelog:
V1->V2:
* add Reported-by tag.
* rebase on patch: can:flexcan:fix stop mode acknowledgment.
---
drivers/net/can/flexcan.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index fcec8bcb53d6..1dbec868d3ea 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -282,6 +282,7 @@ struct flexcan_priv {
const struct flexcan_devtype_data *devtype_data;
struct regulator *reg_xceiver;
struct flexcan_stop_mode stm;
+ bool in_stop_mode;
/* Read and Write APIs */
u32 (*read)(void __iomem *addr);
@@ -1635,6 +1636,8 @@ static int __maybe_unused flexcan_suspend(struct device *device)
err = flexcan_enter_stop_mode(priv);
if (err)
return err;
+
+ priv->in_stop_mode = true;
} else {
err = flexcan_chip_disable(priv);
if (err)
@@ -1659,6 +1662,15 @@ static int __maybe_unused flexcan_resume(struct device *device)
netif_device_attach(dev);
netif_start_queue(dev);
if (device_may_wakeup(device)) {
+ if (priv->in_stop_mode) {
+ flexcan_enable_wakeup_irq(priv, false);
+ err = flexcan_exit_stop_mode(priv);
+ if (err)
+ return err;
+
+ priv->in_stop_mode = false;
+ }
+
disable_irq_wake(dev->irq);
} else {
err = flexcan_chip_enable(priv);
@@ -1674,6 +1686,11 @@ static int __maybe_unused flexcan_noirq_suspend(struct device *device)
struct net_device *dev = dev_get_drvdata(device);
struct flexcan_priv *priv = netdev_priv(dev);
+ /* Need to enable wakeup interrupt in noirq suspend stage. Otherwise,
+ * it will trigger continuously wakeup interrupt if the wakeup event
+ * comes before noirq suspend stage, and simultaneously it has enter
+ * the stop mode.
+ */
if (netif_running(dev) && device_may_wakeup(device))
flexcan_enable_wakeup_irq(priv, true);
@@ -1686,11 +1703,17 @@ static int __maybe_unused flexcan_noirq_resume(struct device *device)
struct flexcan_priv *priv = netdev_priv(dev);
int err;
+ /* Need to exit stop mode in noirq resume stage. Otherwise, it will
+ * trigger continuously wakeup interrupt if the wakeup event comes,
+ * and simultaneously it has still in stop mode.
+ */
if (netif_running(dev) && device_may_wakeup(device)) {
flexcan_enable_wakeup_irq(priv, false);
err = flexcan_exit_stop_mode(priv);
if (err)
return err;
+
+ priv->in_stop_mode = false;
}
return 0;
--
2.17.1
^ permalink raw reply related
* [PATCH v2] Fix typo reigster to register
From: Pei-Hsuan Hung @ 2019-07-30 2:42 UTC (permalink / raw)
Cc: Pei-Hsuan Hung, trivial, Russell Currey, Sam Bobroff,
Oliver O'Halloran, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Jeremy Kerr, Arnd Bergmann, MyungJoo Ham,
Chanwoo Choi, Liviu Dudau, Brian Starkey, David Airlie,
Daniel Vetter, Ping-Ke Shih, Kalle Valo, David S. Miller,
James Smart, Dick Kennedy, James E.J. Bottomley,
Martin K. Petersen, Alexander Viro, Larry Finger, linuxppc-dev,
linux-kernel, dri-devel, linux-wireless, netdev, linux-scsi,
linux-fsdevel
Signed-off-by: Pei-Hsuan Hung <afcidk@gmail.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Cc: trivial@kernel.org
---
Hi Liviu, thanks for your reply.
This patch is generated by a script so at first I didn't notice there is
also a typo in the word coefficient. I've fixed the typo in this
version.
arch/powerpc/kernel/eeh.c | 2 +-
arch/powerpc/platforms/cell/spufs/switch.c | 4 ++--
drivers/extcon/extcon-rt8973a.c | 2 +-
drivers/gpu/drm/arm/malidp_regs.h | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h | 2 +-
drivers/scsi/lpfc/lpfc_hbadisc.c | 2 +-
fs/userfaultfd.c | 2 +-
7 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index c0e4b73191f3..d75c9c24ec4d 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1030,7 +1030,7 @@ int __init eeh_ops_register(struct eeh_ops *ops)
}
/**
- * eeh_ops_unregister - Unreigster platform dependent EEH operations
+ * eeh_ops_unregister - Unregister platform dependent EEH operations
* @name: name of EEH platform operations
*
* Unregister the platform dependent EEH operation callback
diff --git a/arch/powerpc/platforms/cell/spufs/switch.c b/arch/powerpc/platforms/cell/spufs/switch.c
index 5c3f5d088c3b..9548a086937b 100644
--- a/arch/powerpc/platforms/cell/spufs/switch.c
+++ b/arch/powerpc/platforms/cell/spufs/switch.c
@@ -574,7 +574,7 @@ static inline void save_mfc_rag(struct spu_state *csa, struct spu *spu)
{
/* Save, Step 38:
* Save RA_GROUP_ID register and the
- * RA_ENABLE reigster in the CSA.
+ * RA_ENABLE register in the CSA.
*/
csa->priv1.resource_allocation_groupID_RW =
spu_resource_allocation_groupID_get(spu);
@@ -1227,7 +1227,7 @@ static inline void restore_mfc_rag(struct spu_state *csa, struct spu *spu)
{
/* Restore, Step 29:
* Restore RA_GROUP_ID register and the
- * RA_ENABLE reigster from the CSA.
+ * RA_ENABLE register from the CSA.
*/
spu_resource_allocation_groupID_set(spu,
csa->priv1.resource_allocation_groupID_RW);
diff --git a/drivers/extcon/extcon-rt8973a.c b/drivers/extcon/extcon-rt8973a.c
index 40c07f4d656e..e75c03792398 100644
--- a/drivers/extcon/extcon-rt8973a.c
+++ b/drivers/extcon/extcon-rt8973a.c
@@ -270,7 +270,7 @@ static int rt8973a_muic_get_cable_type(struct rt8973a_muic_info *info)
}
cable_type = adc & RT8973A_REG_ADC_MASK;
- /* Read Device 1 reigster to identify correct cable type */
+ /* Read Device 1 register to identify correct cable type */
ret = regmap_read(info->regmap, RT8973A_REG_DEV1, &dev1);
if (ret) {
dev_err(info->dev, "failed to read DEV1 register\n");
diff --git a/drivers/gpu/drm/arm/malidp_regs.h b/drivers/gpu/drm/arm/malidp_regs.h
index 993031542fa1..9b4f95d8ccec 100644
--- a/drivers/gpu/drm/arm/malidp_regs.h
+++ b/drivers/gpu/drm/arm/malidp_regs.h
@@ -145,7 +145,7 @@
#define MALIDP_SE_COEFFTAB_DATA_MASK 0x3fff
#define MALIDP_SE_SET_COEFFTAB_DATA(x) \
((x) & MALIDP_SE_COEFFTAB_DATA_MASK)
-/* Enhance coeffents reigster offset */
+/* Enhance coefficients register offset */
#define MALIDP_SE_IMAGE_ENH 0x3C
/* ENH_LIMITS offset 0x0 */
#define MALIDP_SE_ENH_LOW_LEVEL 24
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h
index 99c6f7eefd85..d03c8f12a15c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h
@@ -58,7 +58,7 @@ struct fw_priv {
/* 0x81: PCI-AP, 01:PCIe, 02: 92S-U,
* 0x82: USB-AP, 0x12: 72S-U, 03:SDIO */
u8 hci_sel;
- /* the same value as reigster value */
+ /* the same value as register value */
u8 chip_version;
/* customer ID low byte */
u8 customer_id_0;
diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c
index 28ecaa7fc715..42b125602d72 100644
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -6551,7 +6551,7 @@ lpfc_sli4_unregister_fcf(struct lpfc_hba *phba)
* lpfc_unregister_fcf_rescan - Unregister currently registered fcf and rescan
* @phba: Pointer to hba context object.
*
- * This function unregisters the currently reigstered FCF. This function
+ * This function unregisters the currently registered FCF. This function
* also tries to find another FCF for discovery by rescan the HBA FCF table.
*/
void
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index ccbdbd62f0d8..612dc1240f90 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -267,7 +267,7 @@ static inline bool userfaultfd_huge_must_wait(struct userfaultfd_ctx *ctx,
#endif /* CONFIG_HUGETLB_PAGE */
/*
- * Verify the pagetables are still not ok after having reigstered into
+ * Verify the pagetables are still not ok after having registered into
* the fault_pending_wqh to avoid userland having to UFFDIO_WAKE any
* userfault that has already been resolved, if userfaultfd_read and
* UFFDIO_COPY|ZEROPAGE are being run simultaneously on two different
--
2.17.1
^ permalink raw reply related
* [PATCH net v2] net: ipv6: Fix a bug in ndisc_send_ns when netdev only has a global address
From: Su Yanjun @ 2019-07-30 2:35 UTC (permalink / raw)
To: davem, kuznet, yoshfuji; +Cc: netdev, linux-kernel, suyj.fnst
When the egress interface does not have a link local address, it can
not communicate with other hosts.
In RFC4861, 7.2.2 says
"If the source address of the packet prompting the solicitation is the
same as one of the addresses assigned to the outgoing interface, that
address SHOULD be placed in the IP Source Address of the outgoing
solicitation. Otherwise, any one of the addresses assigned to the
interface should be used."
In this patch we try get a global address if we get ll address failed.
Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
---
Changes since V1:
- Change patch description and code optimization at
David Ahern's suggestion
---
include/net/addrconf.h | 2 ++
net/ipv6/addrconf.c | 34 ++++++++++++++++++++++++++++++++++
net/ipv6/ndisc.c | 9 ++++++---
3 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index becdad5..ce1561e 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -107,6 +107,8 @@ int __ipv6_get_lladdr(struct inet6_dev *idev, struct in6_addr *addr,
u32 banned_flags);
int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr,
u32 banned_flags);
+int ipv6_get_addr(struct net_device *dev, struct in6_addr *addr,
+ u32 banned_flags);
bool inet_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
bool match_wildcard);
bool inet_rcv_saddr_any(const struct sock *sk);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 521e320..9467457 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1870,6 +1870,40 @@ int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr,
return err;
}
+int __ipv6_get_addr(struct inet6_dev *idev, struct in6_addr *addr,
+ u32 banned_flags)
+{
+ struct inet6_ifaddr *ifp;
+ int err = -EADDRNOTAVAIL;
+
+ list_for_each_entry(ifp, &idev->addr_list, if_list) {
+ if (ifp->scope == 0 &&
+ !(ifp->flags & banned_flags)) {
+ *addr = ifp->addr;
+ err = 0;
+ break;
+ }
+ }
+ return err;
+}
+
+int ipv6_get_addr(struct net_device *dev, struct in6_addr *addr,
+ u32 banned_flags)
+{
+ struct inet6_dev *idev;
+ int err = -EADDRNOTAVAIL;
+
+ rcu_read_lock();
+ idev = __in6_dev_get(dev);
+ if (idev) {
+ read_lock_bh(&idev->lock);
+ err = __ipv6_get_addr(idev, addr, banned_flags);
+ read_unlock_bh(&idev->lock);
+ }
+ rcu_read_unlock();
+ return err;
+}
+
static int ipv6_count_addresses(const struct inet6_dev *idev)
{
const struct inet6_ifaddr *ifp;
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 083cc1c..156c027 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -603,11 +603,14 @@ void ndisc_send_ns(struct net_device *dev, const struct in6_addr *solicit,
int inc_opt = dev->addr_len;
int optlen = 0;
struct nd_msg *msg;
+ u32 banned_flags = IFA_F_TENTATIVE | IFA_F_OPTIMISTIC;
if (!saddr) {
- if (ipv6_get_lladdr(dev, &addr_buf,
- (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)))
- return;
+ if (ipv6_get_lladdr(dev, &addr_buf, banned_flags)) {
+ /* try global address */
+ if (ipv6_get_addr(dev, &addr_buf, banned_flags))
+ return;
+ }
saddr = &addr_buf;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: phy: phy_led_triggers: Fix a possible null-pointer dereference in phy_led_trigger_change_speed()
From: Jia-Ju Bai @ 2019-07-30 2:25 UTC (permalink / raw)
To: Andrew Lunn; +Cc: f.fainelli, hkallweit1, davem, netdev, linux-kernel
In-Reply-To: <20190729134553.GC4110@lunn.ch>
On 2019/7/29 21:45, Andrew Lunn wrote:
> On Mon, Jul 29, 2019 at 05:24:24PM +0800, Jia-Ju Bai wrote:
>> In phy_led_trigger_change_speed(), there is an if statement on line 48
>> to check whether phy->last_triggered is NULL:
>> if (!phy->last_triggered)
>>
>> When phy->last_triggered is NULL, it is used on line 52:
>> led_trigger_event(&phy->last_triggered->trigger, LED_OFF);
>>
>> Thus, a possible null-pointer dereference may occur.
>>
>> To fix this bug, led_trigger_event(&phy->last_triggered->trigger,
>> LED_OFF) is called when phy->last_triggered is not NULL.
>>
>> This bug is found by a static analysis tool STCheck written by us.
> Who is 'us'?
Me and my colleague...
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH 2/4] net: phy: Add mdio-aspeed
From: Andrew Jeffery @ 2019-07-30 2:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, David Miller, Rob Herring, mark.rutland, Joel Stanley,
Florian Fainelli, Heiner Kallweit, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
In-Reply-To: <20190729133250.GB4110@lunn.ch>
On Mon, 29 Jul 2019, at 23:03, Andrew Lunn wrote:
> On Mon, Jul 29, 2019 at 02:09:24PM +0930, Andrew Jeffery wrote:
> > The AST2600 design separates the MDIO controllers from the MAC, which is
> > where they were placed in the AST2400 and AST2500. Further, the register
> > interface is reworked again, so now we have three possible different
> > interface implementations, however this driver only supports the
> > interface provided by the AST2600. The AST2400 and AST2500 will continue
> > to be supported by the MDIO support embedded in the FTGMAC100 driver.
> >
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > ---
> > drivers/net/phy/Kconfig | 13 +++
> > drivers/net/phy/Makefile | 1 +
> > drivers/net/phy/mdio-aspeed.c | 159 ++++++++++++++++++++++++++++++++++
> > 3 files changed, 173 insertions(+)
> > create mode 100644 drivers/net/phy/mdio-aspeed.c
> >
> > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> > index 20f14c5fbb7e..206d8650ee7f 100644
> > --- a/drivers/net/phy/Kconfig
> > +++ b/drivers/net/phy/Kconfig
> > @@ -21,6 +21,19 @@ config MDIO_BUS
> >
> > if MDIO_BUS
> >
> > +config MDIO_ASPEED
> > + tristate "ASPEED MDIO bus controller"
> > + depends on ARCH_ASPEED || COMPILE_TEST
> > + depends on OF_MDIO && HAS_IOMEM
> > + help
> > + This module provides a driver for the independent MDIO bus
> > + controllers found in the ASPEED AST2600 SoC. This is a driver for the
> > + third revision of the ASPEED MDIO register interface - the first two
> > + revisions are the "old" and "new" interfaces found in the AST2400 and
> > + AST2500, embedded in the MAC. For legacy reasons, FTGMAC100 driver
> > + continues to drive the embedded MDIO controller for the AST2400 and
> > + AST2500 SoCs, so say N if AST2600 support is not required.
> > +
> > config MDIO_BCM_IPROC
> > tristate "Broadcom iProc MDIO bus controller"
> > depends on ARCH_BCM_IPROC || COMPILE_TEST
> > diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> > index 839acb292c38..ba07c27e4208 100644
> > --- a/drivers/net/phy/Makefile
> > +++ b/drivers/net/phy/Makefile
> > @@ -22,6 +22,7 @@ libphy-$(CONFIG_LED_TRIGGER_PHY) += phy_led_triggers.o
> > obj-$(CONFIG_PHYLINK) += phylink.o
> > obj-$(CONFIG_PHYLIB) += libphy.o
> >
> > +obj-$(CONFIG_MDIO_ASPEED) += mdio-aspeed.o
> > obj-$(CONFIG_MDIO_BCM_IPROC) += mdio-bcm-iproc.o
> > obj-$(CONFIG_MDIO_BCM_UNIMAC) += mdio-bcm-unimac.o
> > obj-$(CONFIG_MDIO_BITBANG) += mdio-bitbang.o
> > diff --git a/drivers/net/phy/mdio-aspeed.c b/drivers/net/phy/mdio-aspeed.c
> > new file mode 100644
> > index 000000000000..71496a9ff54a
> > --- /dev/null
> > +++ b/drivers/net/phy/mdio-aspeed.c
> > @@ -0,0 +1,159 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/* Copyright (C) 2019 IBM Corp. */
> > +
> > +#include <linux/bitfield.h>
> > +#include <linux/delay.h>
> > +#include <linux/mdio.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_mdio.h>
> > +#include <linux/phy.h>
> > +#include <linux/platform_device.h>
> > +
> > +#define DRV_NAME "mdio-aspeed"
> > +
> > +#define ASPEED_MDIO_CTRL 0x0
> > +#define ASPEED_MDIO_CTRL_FIRE BIT(31)
> > +#define ASPEED_MDIO_CTRL_ST BIT(28)
> > +#define ASPEED_MDIO_CTRL_ST_C45 0
> > +#define ASPEED_MDIO_CTRL_ST_C22 1
> > +#define ASPEED_MDIO_CTRL_OP GENMASK(27, 26)
> > +#define MDIO_C22_OP_WRITE 0b01
> > +#define MDIO_C22_OP_READ 0b10
> > +#define ASPEED_MDIO_CTRL_PHYAD GENMASK(25, 21)
> > +#define ASPEED_MDIO_CTRL_REGAD GENMASK(20, 16)
> > +#define ASPEED_MDIO_CTRL_MIIWDATA GENMASK(15, 0)
> > +
> > +#define ASPEED_MDIO_DATA 0x4
> > +#define ASPEED_MDIO_DATA_MDC_THRES GENMASK(31, 24)
> > +#define ASPEED_MDIO_DATA_MDIO_EDGE BIT(23)
> > +#define ASPEED_MDIO_DATA_MDIO_LATCH GENMASK(22, 20)
> > +#define ASPEED_MDIO_DATA_IDLE BIT(16)
> > +#define ASPEED_MDIO_DATA_MIIRDATA GENMASK(15, 0)
> > +
> > +#define ASPEED_MDIO_RETRIES 10
> > +
> > +struct aspeed_mdio {
> > + void __iomem *base;
> > +};
> > +
> > +static int aspeed_mdio_read(struct mii_bus *bus, int addr, int regnum)
> > +{
> > + struct aspeed_mdio *ctx = bus->priv;
> > + u32 ctrl;
> > + int i;
> > +
> > + dev_dbg(&bus->dev, "%s: addr: %d, regnum: %d\n", __func__, addr,
> > + regnum);
> > +
> > + /* Just clause 22 for the moment */
> > + ctrl = ASPEED_MDIO_CTRL_FIRE
>
> Hi Andrew
>
> In the binding, you say C45 is supported. Here you don't. It would be
> nice to be consistent.
Right - but the bindings describe the hardware, and the hardware is capable.
Just that the driver as it stands can't drive it that way.
Having said that I do need to do more digging to understand how to cater to
C45 PHYs wrt the read/write calls.
>
>
> > + | FIELD_PREP(ASPEED_MDIO_CTRL_ST, ASPEED_MDIO_CTRL_ST_C22)
> > + | FIELD_PREP(ASPEED_MDIO_CTRL_OP, MDIO_C22_OP_READ)
> > + | FIELD_PREP(ASPEED_MDIO_CTRL_PHYAD, addr)
> > + | FIELD_PREP(ASPEED_MDIO_CTRL_REGAD, regnum);
> > +
> > + iowrite32(ctrl, ctx->base + ASPEED_MDIO_CTRL);
> > +
> > + for (i = 0; i < ASPEED_MDIO_RETRIES; i++) {
> > + u32 data;
> > +
> > + data = ioread32(ctx->base + ASPEED_MDIO_DATA);
> > + if (data & ASPEED_MDIO_DATA_IDLE)
> > + return FIELD_GET(ASPEED_MDIO_DATA_MIIRDATA, data);
> > +
> > + udelay(100);
> > + }
>
> One of the readx_poll_timeout functions could be used.
Thanks, I'll take a look.
>
> > +
> > + dev_err(&bus->dev, "MDIO read failed\n");
> > + return -EIO;
> > +}
> > +
> > +static int aspeed_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 val)
> > +{
> > + struct aspeed_mdio *ctx = bus->priv;
> > + u32 ctrl;
> > + int i;
> > +
> > + dev_dbg(&bus->dev, "%s: addr: %d, regnum: %d, val: 0x%x\n",
> > + __func__, addr, regnum, val);
> > +
> > + /* Just clause 22 for the moment */
> > + ctrl = ASPEED_MDIO_CTRL_FIRE
> > + | FIELD_PREP(ASPEED_MDIO_CTRL_ST, ASPEED_MDIO_CTRL_ST_C22)
> > + | FIELD_PREP(ASPEED_MDIO_CTRL_OP, MDIO_C22_OP_WRITE)
> > + | FIELD_PREP(ASPEED_MDIO_CTRL_PHYAD, addr)
> > + | FIELD_PREP(ASPEED_MDIO_CTRL_REGAD, regnum)
> > + | FIELD_PREP(ASPEED_MDIO_CTRL_MIIWDATA, val);
> > +
> > + iowrite32(ctrl, ctx->base + ASPEED_MDIO_CTRL);
> > +
> > + for (i = 0; i < ASPEED_MDIO_RETRIES; i++) {
> > + ctrl = ioread32(ctx->base + ASPEED_MDIO_CTRL);
> > + if (!(ctrl & ASPEED_MDIO_CTRL_FIRE))
> > + return 0;
> > +
> > + udelay(100);
> > + }
>
> readx_poll_timeout() here as well.
>
> Otherwise this looks good.
Thanks for the review!
Andrew
^ permalink raw reply
* [net-next:master 57/61] arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of 'pip_sft_rst' isn't known
From: kbuild test robot @ 2019-07-29 23:23 UTC (permalink / raw)
To: Matthew Wilcox (Oracle); +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 33791 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/davem/net-next.git master
head: 85fd8011475e86265beff7b7617c493c247f5356
commit: 171a9bae68c72f2d1260c3825203760856e6793b [57/61] staging/octeon: Allow test build on !MIPS
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 171a9bae68c72f2d1260c3825203760856e6793b
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
In file included from arch/mips/include/asm/octeon/octeon.h:11:0,
from drivers/staging/octeon/octeon-ethernet.h:19,
from drivers/staging/octeon/ethernet.c:22:
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_writeq_csr':
>> arch/mips/include/asm/octeon/cvmx.h:282:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cvmx_write_csr((__force uint64_t)csr_addr, val);
^
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_readq_csr':
arch/mips/include/asm/octeon/cvmx.h:299:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
return cvmx_read_csr((__force uint64_t) csr_addr);
^
In file included from drivers/staging/octeon/octeon-ethernet.h:27:0,
from drivers/staging/octeon/ethernet.c:22:
arch/mips/include/asm/octeon/cvmx-ipd.h: In function 'cvmx_ipd_free_ptr':
>> arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of 'pip_sft_rst' isn't known
union cvmx_pip_sft_rst pip_sft_rst;
^~~~~~~~~~~
>> arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: error: 'CVMX_PIP_SFT_RST' undeclared (first use in this function); did you mean 'CVMX_CIU_SOFT_RST'?
pip_sft_rst.u64 = cvmx_read_csr(CVMX_PIP_SFT_RST);
^~~~~~~~~~~~~~~~
CVMX_CIU_SOFT_RST
arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: note: each undeclared identifier is reported only once for each function it appears in
arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: warning: unused variable 'pip_sft_rst' [-Wunused-variable]
union cvmx_pip_sft_rst pip_sft_rst;
^~~~~~~~~~~
--
In file included from arch/mips/include/asm/octeon/octeon.h:11:0,
from drivers/staging/octeon/octeon-ethernet.h:19,
from drivers/staging/octeon/ethernet-rx.c:26:
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_writeq_csr':
>> arch/mips/include/asm/octeon/cvmx.h:282:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cvmx_write_csr((__force uint64_t)csr_addr, val);
^
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_readq_csr':
arch/mips/include/asm/octeon/cvmx.h:299:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
return cvmx_read_csr((__force uint64_t) csr_addr);
^
In file included from drivers/staging/octeon/octeon-ethernet.h:27:0,
from drivers/staging/octeon/ethernet-rx.c:26:
arch/mips/include/asm/octeon/cvmx-ipd.h: In function 'cvmx_ipd_free_ptr':
>> arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of 'pip_sft_rst' isn't known
union cvmx_pip_sft_rst pip_sft_rst;
^~~~~~~~~~~
>> arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: error: 'CVMX_PIP_SFT_RST' undeclared (first use in this function); did you mean 'CVMX_CIU_SOFT_RST'?
pip_sft_rst.u64 = cvmx_read_csr(CVMX_PIP_SFT_RST);
^~~~~~~~~~~~~~~~
CVMX_CIU_SOFT_RST
arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: note: each undeclared identifier is reported only once for each function it appears in
arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: warning: unused variable 'pip_sft_rst' [-Wunused-variable]
union cvmx_pip_sft_rst pip_sft_rst;
^~~~~~~~~~~
In file included from drivers/staging/octeon/ethernet-rx.c:27:0:
drivers/staging/octeon/ethernet-rx.c: In function 'cvm_oct_poll':
>> drivers/staging/octeon/ethernet-defines.h:30:38: error: 'CONFIG_CAVIUM_OCTEON_CVMSEG_SIZE' undeclared (first use in this function); did you mean 'CONFIG_MDIO_OCTEON_MODULE'?
#define USE_ASYNC_IOBDMA (CONFIG_CAVIUM_OCTEON_CVMSEG_SIZE > 0)
^
>> drivers/staging/octeon/ethernet-rx.c:190:6: note: in expansion of macro 'USE_ASYNC_IOBDMA'
if (USE_ASYNC_IOBDMA) {
^~~~~~~~~~~~~~~~
drivers/staging/octeon/ethernet-rx.c: In function 'cvm_oct_rx_initialize':
>> drivers/staging/octeon/ethernet-rx.c:472:25: error: 'OCTEON_IRQ_WORKQ0' undeclared (first use in this function); did you mean 'OCTEON_IS_MODEL'?
oct_rx_group[i].irq = OCTEON_IRQ_WORKQ0 + i;
^~~~~~~~~~~~~~~~~
OCTEON_IS_MODEL
--
In file included from arch/mips/include/asm/octeon/octeon.h:11:0,
from drivers/staging/octeon/octeon-ethernet.h:19,
from drivers/staging/octeon/ethernet-spi.c:13:
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_writeq_csr':
>> arch/mips/include/asm/octeon/cvmx.h:282:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cvmx_write_csr((__force uint64_t)csr_addr, val);
^
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_readq_csr':
arch/mips/include/asm/octeon/cvmx.h:299:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
return cvmx_read_csr((__force uint64_t) csr_addr);
^
In file included from drivers/staging/octeon/octeon-ethernet.h:27:0,
from drivers/staging/octeon/ethernet-spi.c:13:
arch/mips/include/asm/octeon/cvmx-ipd.h: In function 'cvmx_ipd_free_ptr':
>> arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of 'pip_sft_rst' isn't known
union cvmx_pip_sft_rst pip_sft_rst;
^~~~~~~~~~~
>> arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: error: 'CVMX_PIP_SFT_RST' undeclared (first use in this function); did you mean 'CVMX_CIU_SOFT_RST'?
pip_sft_rst.u64 = cvmx_read_csr(CVMX_PIP_SFT_RST);
^~~~~~~~~~~~~~~~
CVMX_CIU_SOFT_RST
arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: note: each undeclared identifier is reported only once for each function it appears in
arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: warning: unused variable 'pip_sft_rst' [-Wunused-variable]
union cvmx_pip_sft_rst pip_sft_rst;
^~~~~~~~~~~
drivers/staging/octeon/ethernet-spi.c: In function 'cvm_oct_spi_init':
>> drivers/staging/octeon/ethernet-spi.c:198:19: error: 'OCTEON_IRQ_RML' undeclared (first use in this function); did you mean 'OCTEON_IS_MODEL'?
r = request_irq(OCTEON_IRQ_RML, cvm_oct_spi_rml_interrupt,
^~~~~~~~~~~~~~
OCTEON_IS_MODEL
drivers/staging/octeon/ethernet-spi.c: In function 'cvm_oct_spi_uninit':
drivers/staging/octeon/ethernet-spi.c:224:12: error: 'OCTEON_IRQ_RML' undeclared (first use in this function); did you mean 'OCTEON_IS_MODEL'?
free_irq(OCTEON_IRQ_RML, &number_spi_ports);
^~~~~~~~~~~~~~
OCTEON_IS_MODEL
--
In file included from arch/mips/include/asm/octeon/octeon.h:11:0,
from drivers/staging/octeon/octeon-ethernet.h:19,
from drivers/staging/octeon/ethernet-tx.c:25:
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_writeq_csr':
>> arch/mips/include/asm/octeon/cvmx.h:282:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cvmx_write_csr((__force uint64_t)csr_addr, val);
^
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_readq_csr':
arch/mips/include/asm/octeon/cvmx.h:299:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
return cvmx_read_csr((__force uint64_t) csr_addr);
^
In file included from drivers/staging/octeon/octeon-ethernet.h:27:0,
from drivers/staging/octeon/ethernet-tx.c:25:
arch/mips/include/asm/octeon/cvmx-ipd.h: In function 'cvmx_ipd_free_ptr':
>> arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of 'pip_sft_rst' isn't known
union cvmx_pip_sft_rst pip_sft_rst;
^~~~~~~~~~~
>> arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: error: 'CVMX_PIP_SFT_RST' undeclared (first use in this function); did you mean 'CVMX_CIU_SOFT_RST'?
pip_sft_rst.u64 = cvmx_read_csr(CVMX_PIP_SFT_RST);
^~~~~~~~~~~~~~~~
CVMX_CIU_SOFT_RST
arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: note: each undeclared identifier is reported only once for each function it appears in
arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: warning: unused variable 'pip_sft_rst' [-Wunused-variable]
union cvmx_pip_sft_rst pip_sft_rst;
^~~~~~~~~~~
In file included from drivers/staging/octeon/ethernet-tx.c:26:0:
drivers/staging/octeon/ethernet-tx.c: In function 'cvm_oct_xmit':
>> drivers/staging/octeon/ethernet-defines.h:30:38: error: 'CONFIG_CAVIUM_OCTEON_CVMSEG_SIZE' undeclared (first use in this function); did you mean 'CONFIG_MDIO_OCTEON_MODULE'?
#define USE_ASYNC_IOBDMA (CONFIG_CAVIUM_OCTEON_CVMSEG_SIZE > 0)
^
>> drivers/staging/octeon/ethernet-tx.c:169:6: note: in expansion of macro 'USE_ASYNC_IOBDMA'
if (USE_ASYNC_IOBDMA) {
^~~~~~~~~~~~~~~~
In file included from arch/mips/include/asm/barrier.h:11:0,
from include/linux/compiler.h:256,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/staging/octeon/ethernet-tx.c:8:
drivers/staging/octeon/ethernet-tx.c:264:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
hw_buffer.s.addr = XKPHYS_TO_PHYS((u64)skb->data);
^
arch/mips/include/asm/addrspace.h:128:30: note: in definition of macro 'XKPHYS_TO_PHYS'
#define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK)
^
drivers/staging/octeon/ethernet-tx.c:268:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
hw_buffer.s.addr = XKPHYS_TO_PHYS((u64)skb->data);
^
arch/mips/include/asm/addrspace.h:128:30: note: in definition of macro 'XKPHYS_TO_PHYS'
#define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK)
^
drivers/staging/octeon/ethernet-tx.c:276:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
XKPHYS_TO_PHYS((u64)skb_frag_address(fs));
^
arch/mips/include/asm/addrspace.h:128:30: note: in definition of macro 'XKPHYS_TO_PHYS'
#define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK)
^
drivers/staging/octeon/ethernet-tx.c:280:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
hw_buffer.s.addr = XKPHYS_TO_PHYS((u64)CVM_OCT_SKB_CB(skb));
^
arch/mips/include/asm/addrspace.h:128:30: note: in definition of macro 'XKPHYS_TO_PHYS'
#define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK)
^
drivers/staging/octeon/ethernet-tx.c: In function 'cvm_oct_tx_initialize':
>> drivers/staging/octeon/ethernet-tx.c:706:18: error: 'OCTEON_IRQ_TIMER1' undeclared (first use in this function); did you mean 'OCTEON_IS_MODEL'?
i = request_irq(OCTEON_IRQ_TIMER1,
^~~~~~~~~~~~~~~~~
OCTEON_IS_MODEL
drivers/staging/octeon/ethernet-tx.c: In function 'cvm_oct_tx_shutdown':
drivers/staging/octeon/ethernet-tx.c:717:11: error: 'OCTEON_IRQ_TIMER1' undeclared (first use in this function); did you mean 'OCTEON_IS_MODEL'?
free_irq(OCTEON_IRQ_TIMER1, cvm_oct_device);
^~~~~~~~~~~~~~~~~
OCTEON_IS_MODEL
vim +330 arch/mips/include/asm/octeon/cvmx-ipd.h
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 154
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 155 /**
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 156 * Supportive function for cvmx_fpa_shutdown_pool.
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 157 */
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 158 static inline void cvmx_ipd_free_ptr(void)
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 159 {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 160 /* Only CN38XXp{1,2} cannot read pointer out of the IPD */
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 161 if (!OCTEON_IS_MODEL(OCTEON_CN38XX_PASS1)
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 162 && !OCTEON_IS_MODEL(OCTEON_CN38XX_PASS2)) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 163 int no_wptr = 0;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 164 union cvmx_ipd_ptr_count ipd_ptr_count;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 165 ipd_ptr_count.u64 = cvmx_read_csr(CVMX_IPD_PTR_COUNT);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 166
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 167 /* Handle Work Queue Entry in cn56xx and cn52xx */
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 168 if (octeon_has_feature(OCTEON_FEATURE_NO_WPTR)) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 169 union cvmx_ipd_ctl_status ipd_ctl_status;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 170 ipd_ctl_status.u64 = cvmx_read_csr(CVMX_IPD_CTL_STATUS);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 171 if (ipd_ctl_status.s.no_wptr)
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 172 no_wptr = 1;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 173 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 174
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 175 /* Free the prefetched WQE */
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 176 if (ipd_ptr_count.s.wqev_cnt) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 177 union cvmx_ipd_wqe_ptr_valid ipd_wqe_ptr_valid;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 178 ipd_wqe_ptr_valid.u64 =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 179 cvmx_read_csr(CVMX_IPD_WQE_PTR_VALID);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 180 if (no_wptr)
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 181 cvmx_fpa_free(cvmx_phys_to_ptr
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 182 ((uint64_t) ipd_wqe_ptr_valid.s.
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 183 ptr << 7), CVMX_FPA_PACKET_POOL,
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 184 0);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 185 else
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 186 cvmx_fpa_free(cvmx_phys_to_ptr
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 187 ((uint64_t) ipd_wqe_ptr_valid.s.
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 188 ptr << 7), CVMX_FPA_WQE_POOL, 0);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 189 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 190
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 191 /* Free all WQE in the fifo */
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 192 if (ipd_ptr_count.s.wqe_pcnt) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 193 int i;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 194 union cvmx_ipd_pwp_ptr_fifo_ctl ipd_pwp_ptr_fifo_ctl;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 195 ipd_pwp_ptr_fifo_ctl.u64 =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 196 cvmx_read_csr(CVMX_IPD_PWP_PTR_FIFO_CTL);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 197 for (i = 0; i < ipd_ptr_count.s.wqe_pcnt; i++) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 198 ipd_pwp_ptr_fifo_ctl.s.cena = 0;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 199 ipd_pwp_ptr_fifo_ctl.s.raddr =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 200 ipd_pwp_ptr_fifo_ctl.s.max_cnts +
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 201 (ipd_pwp_ptr_fifo_ctl.s.wraddr +
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 202 i) % ipd_pwp_ptr_fifo_ctl.s.max_cnts;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 203 cvmx_write_csr(CVMX_IPD_PWP_PTR_FIFO_CTL,
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 204 ipd_pwp_ptr_fifo_ctl.u64);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 205 ipd_pwp_ptr_fifo_ctl.u64 =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 206 cvmx_read_csr(CVMX_IPD_PWP_PTR_FIFO_CTL);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 207 if (no_wptr)
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 208 cvmx_fpa_free(cvmx_phys_to_ptr
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 209 ((uint64_t)
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 210 ipd_pwp_ptr_fifo_ctl.s.
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 211 ptr << 7),
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 212 CVMX_FPA_PACKET_POOL, 0);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 213 else
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 214 cvmx_fpa_free(cvmx_phys_to_ptr
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 215 ((uint64_t)
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 216 ipd_pwp_ptr_fifo_ctl.s.
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 217 ptr << 7),
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 218 CVMX_FPA_WQE_POOL, 0);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 219 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 220 ipd_pwp_ptr_fifo_ctl.s.cena = 1;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 221 cvmx_write_csr(CVMX_IPD_PWP_PTR_FIFO_CTL,
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 222 ipd_pwp_ptr_fifo_ctl.u64);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 223 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 224
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 225 /* Free the prefetched packet */
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 226 if (ipd_ptr_count.s.pktv_cnt) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 227 union cvmx_ipd_pkt_ptr_valid ipd_pkt_ptr_valid;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 228 ipd_pkt_ptr_valid.u64 =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 229 cvmx_read_csr(CVMX_IPD_PKT_PTR_VALID);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 230 cvmx_fpa_free(cvmx_phys_to_ptr
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 231 (ipd_pkt_ptr_valid.s.ptr << 7),
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 232 CVMX_FPA_PACKET_POOL, 0);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 233 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 234
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 235 /* Free the per port prefetched packets */
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 236 if (1) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 237 int i;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 238 union cvmx_ipd_prc_port_ptr_fifo_ctl
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 239 ipd_prc_port_ptr_fifo_ctl;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 240 ipd_prc_port_ptr_fifo_ctl.u64 =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 241 cvmx_read_csr(CVMX_IPD_PRC_PORT_PTR_FIFO_CTL);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 242
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 243 for (i = 0; i < ipd_prc_port_ptr_fifo_ctl.s.max_pkt;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 244 i++) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 245 ipd_prc_port_ptr_fifo_ctl.s.cena = 0;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 246 ipd_prc_port_ptr_fifo_ctl.s.raddr =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 247 i % ipd_prc_port_ptr_fifo_ctl.s.max_pkt;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 248 cvmx_write_csr(CVMX_IPD_PRC_PORT_PTR_FIFO_CTL,
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 249 ipd_prc_port_ptr_fifo_ctl.u64);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 250 ipd_prc_port_ptr_fifo_ctl.u64 =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 251 cvmx_read_csr
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 252 (CVMX_IPD_PRC_PORT_PTR_FIFO_CTL);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 253 cvmx_fpa_free(cvmx_phys_to_ptr
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 254 ((uint64_t)
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 255 ipd_prc_port_ptr_fifo_ctl.s.
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 256 ptr << 7), CVMX_FPA_PACKET_POOL,
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 257 0);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 258 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 259 ipd_prc_port_ptr_fifo_ctl.s.cena = 1;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 260 cvmx_write_csr(CVMX_IPD_PRC_PORT_PTR_FIFO_CTL,
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 261 ipd_prc_port_ptr_fifo_ctl.u64);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 262 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 263
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 264 /* Free all packets in the holding fifo */
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 265 if (ipd_ptr_count.s.pfif_cnt) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 266 int i;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 267 union cvmx_ipd_prc_hold_ptr_fifo_ctl
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 268 ipd_prc_hold_ptr_fifo_ctl;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 269
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 270 ipd_prc_hold_ptr_fifo_ctl.u64 =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 271 cvmx_read_csr(CVMX_IPD_PRC_HOLD_PTR_FIFO_CTL);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 272
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 273 for (i = 0; i < ipd_ptr_count.s.pfif_cnt; i++) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 274 ipd_prc_hold_ptr_fifo_ctl.s.cena = 0;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 275 ipd_prc_hold_ptr_fifo_ctl.s.raddr =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 276 (ipd_prc_hold_ptr_fifo_ctl.s.praddr +
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 277 i) % ipd_prc_hold_ptr_fifo_ctl.s.max_pkt;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 278 cvmx_write_csr(CVMX_IPD_PRC_HOLD_PTR_FIFO_CTL,
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 279 ipd_prc_hold_ptr_fifo_ctl.u64);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 280 ipd_prc_hold_ptr_fifo_ctl.u64 =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 281 cvmx_read_csr
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 282 (CVMX_IPD_PRC_HOLD_PTR_FIFO_CTL);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 283 cvmx_fpa_free(cvmx_phys_to_ptr
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 284 ((uint64_t)
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 285 ipd_prc_hold_ptr_fifo_ctl.s.
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 286 ptr << 7), CVMX_FPA_PACKET_POOL,
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 287 0);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 288 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 289 ipd_prc_hold_ptr_fifo_ctl.s.cena = 1;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 290 cvmx_write_csr(CVMX_IPD_PRC_HOLD_PTR_FIFO_CTL,
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 291 ipd_prc_hold_ptr_fifo_ctl.u64);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 292 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 293
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 294 /* Free all packets in the fifo */
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 295 if (ipd_ptr_count.s.pkt_pcnt) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 296 int i;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 297 union cvmx_ipd_pwp_ptr_fifo_ctl ipd_pwp_ptr_fifo_ctl;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 298 ipd_pwp_ptr_fifo_ctl.u64 =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 299 cvmx_read_csr(CVMX_IPD_PWP_PTR_FIFO_CTL);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 300
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 301 for (i = 0; i < ipd_ptr_count.s.pkt_pcnt; i++) {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 302 ipd_pwp_ptr_fifo_ctl.s.cena = 0;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 303 ipd_pwp_ptr_fifo_ctl.s.raddr =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 304 (ipd_pwp_ptr_fifo_ctl.s.praddr +
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 305 i) % ipd_pwp_ptr_fifo_ctl.s.max_cnts;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 306 cvmx_write_csr(CVMX_IPD_PWP_PTR_FIFO_CTL,
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 307 ipd_pwp_ptr_fifo_ctl.u64);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 308 ipd_pwp_ptr_fifo_ctl.u64 =
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 309 cvmx_read_csr(CVMX_IPD_PWP_PTR_FIFO_CTL);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 310 cvmx_fpa_free(cvmx_phys_to_ptr
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 311 ((uint64_t) ipd_pwp_ptr_fifo_ctl.
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 312 s.ptr << 7),
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 313 CVMX_FPA_PACKET_POOL, 0);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 314 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 315 ipd_pwp_ptr_fifo_ctl.s.cena = 1;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 316 cvmx_write_csr(CVMX_IPD_PWP_PTR_FIFO_CTL,
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 317 ipd_pwp_ptr_fifo_ctl.u64);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 318 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 319
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 320 /* Reset the IPD to get all buffers out of it */
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 321 {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 322 union cvmx_ipd_ctl_status ipd_ctl_status;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 323 ipd_ctl_status.u64 = cvmx_read_csr(CVMX_IPD_CTL_STATUS);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 324 ipd_ctl_status.s.reset = 1;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 325 cvmx_write_csr(CVMX_IPD_CTL_STATUS, ipd_ctl_status.u64);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 326 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 327
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 328 /* Reset the PIP */
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 329 {
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 @330 union cvmx_pip_sft_rst pip_sft_rst;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 @331 pip_sft_rst.u64 = cvmx_read_csr(CVMX_PIP_SFT_RST);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 332 pip_sft_rst.s.rst = 1;
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 333 cvmx_write_csr(CVMX_PIP_SFT_RST, pip_sft_rst.u64);
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 334 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 335 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 336 }
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 337
80ff0fd3ab64514 drivers/staging/octeon/cvmx-ipd.h David Daney 2009-05-05 338 #endif /* __CVMX_IPD_H__ */
:::::: The code at line 330 was first introduced by commit
:::::: 80ff0fd3ab6451407a20c19b80c1643c4a6d6434 Staging: Add octeon-ethernet driver files.
:::::: TO: David Daney <ddaney@caviumnetworks.com>
:::::: CC: Ralf Baechle <ralf@linux-mips.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 61515 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S
From: Vladimir Oltean @ 2019-07-30 1:32 UTC (permalink / raw)
To: Tao Ren
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S . Miller,
Arun Parameswaran, Justin Chen, netdev, lkml, Andrew Jeffery,
openbmc
In-Reply-To: <20190730002549.86824-1-taoren@fb.com>
Hi Tao,
On Tue, 30 Jul 2019 at 03:31, Tao Ren <taoren@fb.com> wrote:
>
> Configure the BCM54616S for 1000Base-X mode when "brcm-phy-mode-1000bx"
> is set in device tree. This is needed when the PHY is used for fiber and
> backplane connections.
>
> The patch is inspired by commit cd9af3dac6d1 ("PHYLIB: Add 1000Base-X
> support for Broadcom bcm5482").
As far as I can see, for the commit you referenced,
PHY_BCM_FLAGS_MODE_1000BX is referenced from nowhere in the entire
mainline kernel:
https://elixir.bootlin.com/linux/latest/ident/PHY_BCM_FLAGS_MODE_1000BX
(it is supposed to be put by the MAC driver in phydev->dev_flags prior
to calling phy_connect). But I don't see the point to this - can't you
check for phydev->interface == PHY_INTERFACE_MODE_1000BASEX?
This has the advantage that no MAC driver will need to know that it's
talking to a Broadcom PHY. Additionally, no custom DT bindings are
needed.
Also, for backplane connections you probably want 1000Base-KX which
has its own AN/LT, not plain 1000Base-X.
>
> Signed-off-by: Tao Ren <taoren@fb.com>
> ---
> drivers/net/phy/broadcom.c | 58 +++++++++++++++++++++++++++++++++++---
> include/linux/brcmphy.h | 4 +--
> 2 files changed, 56 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
> index 2b4e41a9d35a..6c22ac3a844b 100644
> --- a/drivers/net/phy/broadcom.c
> +++ b/drivers/net/phy/broadcom.c
> @@ -383,9 +383,9 @@ static int bcm5482_config_init(struct phy_device *phydev)
> /*
> * Select 1000BASE-X register set (primary SerDes)
> */
> - reg = bcm_phy_read_shadow(phydev, BCM5482_SHD_MODE);
> - bcm_phy_write_shadow(phydev, BCM5482_SHD_MODE,
> - reg | BCM5482_SHD_MODE_1000BX);
> + reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
> + bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
> + reg | BCM54XX_SHD_MODE_1000BX);
>
> /*
> * LED1=ACTIVITYLED, LED3=LINKSPD[2]
> @@ -451,6 +451,34 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
> return ret;
> }
>
> +static int bcm54616s_config_init(struct phy_device *phydev)
> +{
> + int err, reg;
> + struct device_node *np = phydev->mdio.dev.of_node;
> +
> + err = bcm54xx_config_init(phydev);
> +
> + if (of_property_read_bool(np, "brcm-phy-mode-1000bx")) {
> + /* Select 1000BASE-X register set. */
> + reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
> + bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
> + reg | BCM54XX_SHD_MODE_1000BX);
> +
> + /* Auto-negotiation doesn't seem to work quite right
> + * in this mode, so we disable it and force it to the
> + * right speed/duplex setting. Only 'link status'
> + * is important.
> + */
> + phydev->autoneg = AUTONEG_DISABLE;
> + phydev->speed = SPEED_1000;
> + phydev->duplex = DUPLEX_FULL;
> +
1000Base-X AN does not include speed negotiation, so hardcoding
SPEED_1000 is probably correct.
What is wrong with the AN of duplex settings?
> + phydev->dev_flags |= PHY_BCM_FLAGS_MODE_1000BX;
> + }
> +
> + return err;
> +}
> +
> static int bcm54616s_config_aneg(struct phy_device *phydev)
> {
> int ret;
> @@ -464,6 +492,27 @@ static int bcm54616s_config_aneg(struct phy_device *phydev)
> return ret;
> }
>
> +static int bcm54616s_read_status(struct phy_device *phydev)
> +{
> + int ret;
> +
> + ret = genphy_read_status(phydev);
> + if (ret < 0)
> + return ret;
> +
> + if (phydev->dev_flags & PHY_BCM_FLAGS_MODE_1000BX) {
> + /* Only link status matters for 1000Base-X mode, so force
> + * 1000 Mbit/s full-duplex status.
> + */
> + if (phydev->link) {
> + phydev->speed = SPEED_1000;
> + phydev->duplex = DUPLEX_FULL;
> + }
> + }
> +
> + return 0;
> +}
> +
> static int brcm_phy_setbits(struct phy_device *phydev, int reg, int set)
> {
> int val;
> @@ -651,8 +700,9 @@ static struct phy_driver broadcom_drivers[] = {
> .phy_id_mask = 0xfffffff0,
> .name = "Broadcom BCM54616S",
> .features = PHY_GBIT_FEATURES,
> - .config_init = bcm54xx_config_init,
> + .config_init = bcm54616s_config_init,
> .config_aneg = bcm54616s_config_aneg,
> + .read_status = bcm54616s_read_status,
> .ack_interrupt = bcm_phy_ack_intr,
> .config_intr = bcm_phy_config_intr,
> }, {
> diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
> index 6db2d9a6e503..82030155558c 100644
> --- a/include/linux/brcmphy.h
> +++ b/include/linux/brcmphy.h
> @@ -200,8 +200,8 @@
> #define BCM5482_SHD_SSD 0x14 /* 10100: Secondary SerDes control */
> #define BCM5482_SHD_SSD_LEDM 0x0008 /* SSD LED Mode enable */
> #define BCM5482_SHD_SSD_EN 0x0001 /* SSD enable */
> -#define BCM5482_SHD_MODE 0x1f /* 11111: Mode Control Register */
> -#define BCM5482_SHD_MODE_1000BX 0x0001 /* Enable 1000BASE-X registers */
> +#define BCM54XX_SHD_MODE 0x1f /* 11111: Mode Control Register */
> +#define BCM54XX_SHD_MODE_1000BX 0x0001 /* Enable 1000BASE-X registers */
These registers are also present on my BCM5464, probably safe to
assume they're generic for the entire family.
So if you make the registers definitions common, you can probably make
the 1000Base-X configuration common as well.
>
>
> /*
> --
> 2.17.1
>
Regards,
-Vladimir
^ permalink raw reply
* Re: [PATCH stable 4.9] tcp: reset sk_send_head in tcp_write_queue_purge
From: maowenan @ 2019-07-30 1:31 UTC (permalink / raw)
To: Sasha Levin; +Cc: gregkh, stable, netdev, linux-kernel
In-Reply-To: <20190729153218.GA29162@sasha-vm>
On 2019/7/29 23:32, Sasha Levin wrote:
> On Mon, Jul 29, 2019 at 09:21:08PM +0800, Mao Wenan wrote:
>> From: Soheil Hassas Yeganeh <soheil@google.com>
>>
>> tcp_write_queue_purge clears all the SKBs in the write queue
>> but does not reset the sk_send_head. As a result, we can have
>> a NULL pointer dereference anywhere that we use tcp_send_head
>> instead of the tcp_write_queue_tail.
>>
>> For example, after a27fd7a8ed38 (tcp: purge write queue upon RST),
>> we can purge the write queue on RST. Prior to
>> 75c119afe14f (tcp: implement rb-tree based retransmit queue),
>> tcp_push will only check tcp_send_head and then accesses
>> tcp_write_queue_tail to send the actual SKB. As a result, it will
>> dereference a NULL pointer.
>>
>> This has been reported twice for 4.14 where we don't have
>> 75c119afe14f:
>>
>> By Timofey Titovets:
>>
>> [ 422.081094] BUG: unable to handle kernel NULL pointer dereference
>> at 0000000000000038
>> [ 422.081254] IP: tcp_push+0x42/0x110
>> [ 422.081314] PGD 0 P4D 0
>> [ 422.081364] Oops: 0002 [#1] SMP PTI
>>
>> By Yongjian Xu:
>>
>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
>> IP: tcp_push+0x48/0x120
>> PGD 80000007ff77b067 P4D 80000007ff77b067 PUD 7fd989067 PMD 0
>> Oops: 0002 [#18] SMP PTI
>> Modules linked in: tcp_diag inet_diag tcp_bbr sch_fq iTCO_wdt
>> iTCO_vendor_support pcspkr ixgbe mdio i2c_i801 lpc_ich joydev input_leds shpchp
>> e1000e igb dca ptp pps_core hwmon mei_me mei ipmi_si ipmi_msghandler sg ses
>> scsi_transport_sas enclosure ext4 jbd2 mbcache sd_mod ahci libahci megaraid_sas
>> wmi ast ttm dm_mirror dm_region_hash dm_log dm_mod dax
>> CPU: 6 PID: 14156 Comm: [ET_NET 6] Tainted: G D 4.14.26-1.el6.x86_64 #1
>> Hardware name: LENOVO ThinkServer RD440 /ThinkServer RD440, BIOS A0TS80A
>> 09/22/2014
>> task: ffff8807d78d8140 task.stack: ffffc9000e944000
>> RIP: 0010:tcp_push+0x48/0x120
>> RSP: 0018:ffffc9000e947a88 EFLAGS: 00010246
>> RAX: 00000000000005b4 RBX: ffff880f7cce9c00 RCX: 0000000000000000
>> RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff8807d00f5000
>> RBP: ffffc9000e947aa8 R08: 0000000000001c84 R09: 0000000000000000
>> R10: ffff8807d00f5158 R11: 0000000000000000 R12: ffff8807d00f5000
>> R13: 0000000000000020 R14: 00000000000256d4 R15: 0000000000000000
>> FS: 00007f5916de9700(0000) GS:ffff88107fd00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000000000038 CR3: 00000007f8226004 CR4: 00000000001606e0
>> Call Trace:
>> tcp_sendmsg_locked+0x33d/0xe50
>> tcp_sendmsg+0x37/0x60
>> inet_sendmsg+0x39/0xc0
>> sock_sendmsg+0x49/0x60
>> sock_write_iter+0xb6/0x100
>> do_iter_readv_writev+0xec/0x130
>> ? rw_verify_area+0x49/0xb0
>> do_iter_write+0x97/0xd0
>> vfs_writev+0x7e/0xe0
>> ? __wake_up_common_lock+0x80/0xa0
>> ? __fget_light+0x2c/0x70
>> ? __do_page_fault+0x1e7/0x530
>> do_writev+0x60/0xf0
>> ? inet_shutdown+0xac/0x110
>> SyS_writev+0x10/0x20
>> do_syscall_64+0x6f/0x140
>> ? prepare_exit_to_usermode+0x8b/0xa0
>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> RIP: 0033:0x3135ce0c57
>> RSP: 002b:00007f5916de4b00 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
>> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000003135ce0c57
>> RDX: 0000000000000002 RSI: 00007f5916de4b90 RDI: 000000000000606f
>> RBP: 0000000000000000 R08: 0000000000000000 R09: 00007f5916de8c38
>> R10: 0000000000000000 R11: 0000000000000293 R12: 00000000000464cc
>> R13: 00007f5916de8c30 R14: 00007f58d8bef080 R15: 0000000000000002
>> Code: 48 8b 97 60 01 00 00 4c 8d 97 58 01 00 00 41 b9 00 00 00 00 41 89 f3 4c 39
>> d2 49 0f 44 d1 41 81 e3 00 80 00 00 0f 85 b0 00 00 00 <80> 4a 38 08 44 8b 8f 74
>> 06 00 00 44 89 8f 7c 06 00 00 83 e6 01
>> RIP: tcp_push+0x48/0x120 RSP: ffffc9000e947a88
>> CR2: 0000000000000038
>> ---[ end trace 8d545c2e93515549 ]---
>>
>> There is other scenario which found in stable 4.4:
>> Allocated:
>> [<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
>> [<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
>> [<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
>> [<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
>> [<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
>> Freed:
>> [<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
>> [<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
>> [<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
>> [<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
>> [<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
>> [<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246
>>
>> BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
>> BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
>> BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
>> [<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
>> [<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
>> [<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
>> [<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
>> [<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
>> [<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307
>>
>> stable 4.4 and stable 4.9 don't have the commit abb4a8b870b5 ("tcp: purge write queue upon RST")
>> which is referred in dbbf2d1e4077,
>> in tcp_connect_init, it calls tcp_write_queue_purge, and does not reset sk_send_head, then UAF.
>>
>> stable 4.14 have the commit abb4a8b870b5 ("tcp: purge write queue upon RST"),
>> in tcp_reset, it calls tcp_write_queue_purge(sk), and does not reset sk_send_head, then UAF.
>>
>> So this patch can be used to fix stable 4.4 and 4.9.
>>
>> Fixes: a27fd7a8ed38 (tcp: purge write queue upon RST)
>> Reported-by: Timofey Titovets <nefelim4ag@gmail.com>
>> Reported-by: Yongjian Xu <yongjianchn@gmail.com>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
>> Tested-by: Yongjian Xu <yongjianchn@gmail.com>
>>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Mao Wenan <maowenan@huawei.com>
>
> So the "Fixes:" commit in the commit message is wrong? What's the actual
> commit that this fixes?
Upstream commit is 7f582b248d0a ("tcp: purge write queue in tcp_connect_init()")
linux-4.4.y
Fixes: 5bbe138a250e ("tcp: purge write queue in tcp_connect_init()")
linux-4.9.y
Fixes: 74a4c09d4b05 ("tcp: purge write queue in tcp_connect_init()")
linux-4.14.y
Fixes: a27fd7a8ed38 ("tcp: purge write queue upon RST")
>
> --
> Thanks,
> Sasha
>
> .
>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: net: Add aspeed,ast2600-mdio binding
From: Andrew Jeffery @ 2019-07-30 0:47 UTC (permalink / raw)
To: Rob Herring
Cc: netdev, David Miller, Mark Rutland, Joel Stanley, Andrew Lunn,
Florian Fainelli, Heiner Kallweit, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-aspeed, linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqLytwfsoyS6TSnpPgTjRTOR0TeQwroX21AHqj3A1mPJ5Q@mail.gmail.com>
On Tue, 30 Jul 2019, at 09:07, Rob Herring wrote:
> On Sun, Jul 28, 2019 at 10:39 PM Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > The AST2600 splits out the MDIO bus controller from the MAC into its own
> > IP block and rearranges the register layout. Add a new binding to
> > describe the new hardware.
> >
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > ---
> > .../bindings/net/aspeed,ast2600-mdio.yaml | 61 +++++++++++++++++++
> > 1 file changed, 61 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
> > new file mode 100644
> > index 000000000000..fa86f6438473
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
> > @@ -0,0 +1,61 @@
> > +# SPDX-License-Identifier: GPL-2.0-or-later
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/aspeed,ast2600-mdio.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ASPEED AST2600 MDIO Controller
> > +
> > +maintainers:
> > + - Andrew Jeffery <andrew@aj.id.au>
> > +
> > +description: |+
> > + The ASPEED AST2600 MDIO controller is the third iteration of ASPEED's MDIO
> > + bus register interface, this time also separating out the controller from the
> > + MAC.
> > +
>
> Should have a:
>
> allOf:
> - $ref: "mdio.yaml#"
Ack.
>
> > +properties:
> > + compatible:
> > + const: aspeed,ast2600-mdio
> > + reg:
> > + maxItems: 1
> > + description: The register range of the MDIO controller instance
>
> > + "#address-cells":
> > + const: 1
> > + "#size-cells":
> > + const: 0
>
> Then you can drop these 2.
Great.
>
> > +
> > +patternProperties:
> > + "^ethernet-phy@[a-f0-9]$":
> > + properties:
> > + reg:
> > + description:
> > + The MDIO bus index of the PHY
>
> And this.
>
> > + compatible:
> > + enum:
> > + - ethernet-phy-ieee802.3-c22
> > + - ethernet-phy-ieee802.3-c45
>
> This isn't specific to ASpeed either and is already covered by
> ethernet-phy.yaml.
>
> So that means none of the child node schema is needed here.
Bah, I'd developed the patches on v5.2 while waiting for v5.3-rc1 to come
out.
>
> > + required:
> > + - reg
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - "#address-cells"
> > + - "#size-cells"
> > +
> > +examples:
> > + - |
> > + mdio0: mdio@1e650000 {
> > + compatible = "aspeed,ast2600-mdio";
> > + reg = <0x1e650000 0x8>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + status = "okay";
>
> Don't show status in examples.
Sorry, copy/paste at fault.
Thanks for the feedback.
Andrew
>
> > +
> > + ethphy0: ethernet-phy@0 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <0>;
> > + };
> > + };
> > --
> > 2.20.1
> >
>
^ permalink raw reply
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