* RE: [patch net-next v2 2/4] net/sched: Introduce sample tc action
From: Yotam Gigi @ 2017-01-27 6:09 UTC (permalink / raw)
To: Cong Wang, Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Ido Schimmel,
Elad Raz, Nogah Frankel, Or Gerlitz, Jamal Hadi Salim,
geert+renesas@glider.be, Stephen Hemminger, Guenter Roeck,
Roopa Prabhu, John Fastabend, Simon Horman, Roman Mashak
In-Reply-To: <CAM_iQpUHrhkVtgrA37btQ9sn0UPeYgkqnRx=3HZoLan-soT8hg@mail.gmail.com>
>-----Original Message-----
>From: Cong Wang [mailto:xiyou.wangcong@gmail.com]
>Sent: Thursday, January 26, 2017 1:30 AM
>To: Jiri Pirko <jiri@resnulli.us>
>Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>; David Miller
><davem@davemloft.net>; Yotam Gigi <yotamg@mellanox.com>; Ido Schimmel
><idosch@mellanox.com>; Elad Raz <eladr@mellanox.com>; Nogah Frankel
><nogahf@mellanox.com>; Or Gerlitz <ogerlitz@mellanox.com>; Jamal Hadi Salim
><jhs@mojatatu.com>; geert+renesas@glider.be; Stephen Hemminger
><stephen@networkplumber.org>; Guenter Roeck <linux@roeck-us.net>; Roopa
>Prabhu <roopa@cumulusnetworks.com>; John Fastabend
><john.fastabend@gmail.com>; Simon Horman <simon.horman@netronome.com>;
>Roman Mashak <mrv@mojatatu.com>
>Subject: Re: [patch net-next v2 2/4] net/sched: Introduce sample tc action
>
>On Mon, Jan 23, 2017 at 2:07 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> +
>> +static int tcf_sample_init(struct net *net, struct nlattr *nla,
>> + struct nlattr *est, struct tc_action **a, int ovr,
>> + int bind)
>> +{
>> + struct tc_action_net *tn = net_generic(net, sample_net_id);
>> + struct nlattr *tb[TCA_SAMPLE_MAX + 1];
>> + struct psample_group *psample_group;
>> + struct tc_sample *parm;
>> + struct tcf_sample *s;
>> + bool exists = false;
>> + int ret;
>> +
>> + if (!nla)
>> + return -EINVAL;
>> + ret = nla_parse_nested(tb, TCA_SAMPLE_MAX, nla, sample_policy);
>> + if (ret < 0)
>> + return ret;
>> + if (!tb[TCA_SAMPLE_PARMS] || !tb[TCA_SAMPLE_RATE] ||
>> + !tb[TCA_SAMPLE_PSAMPLE_GROUP])
>> + return -EINVAL;
>> +
>> + parm = nla_data(tb[TCA_SAMPLE_PARMS]);
>> +
>> + exists = tcf_hash_check(tn, parm->index, a, bind);
>> + if (exists && bind)
>> + return 0;
>> +
>> + if (!exists) {
>> + ret = tcf_hash_create(tn, parm->index, est, a,
>> + &act_sample_ops, bind, false);
>> + if (ret)
>> + return ret;
>> + ret = ACT_P_CREATED;
>> + } else {
>> + tcf_hash_release(*a, bind);
>> + if (!ovr)
>> + return -EEXIST;
>> + }
>> + s = to_sample(*a);
>> +
>> + ASSERT_RTNL();
>
>Copy-n-paste from mirred aciton? This is not needed for you, mirred
>needs it because of target netdevice.
Ho, you are right. I will remove it.
>
>
>> + s->tcf_action = parm->action;
>> + s->rate = nla_get_u32(tb[TCA_SAMPLE_RATE]);
>> + s->psample_group_num =
>nla_get_u32(tb[TCA_SAMPLE_PSAMPLE_GROUP]);
>> + psample_group = psample_group_get(net, s->psample_group_num);
>> + if (!psample_group)
>> + return -ENOMEM;
>
>I don't think you can just return here, needs tcf_hash_cleanup() for create
>case, right?
Will fix.
>
>
>> + RCU_INIT_POINTER(s->psample_group, psample_group);
>> +
>> + if (tb[TCA_SAMPLE_TRUNC_SIZE]) {
>> + s->truncate = true;
>> + s->trunc_size = nla_get_u32(tb[TCA_SAMPLE_TRUNC_SIZE]);
>> + }
>
>
>Do you need tcf_lock here if RCU only protects ->psample_group??
>
You are right. I need to protect in case of update.
I will send a fixup patch in the following days. Thanks!
>
>> +
>> + if (ret == ACT_P_CREATED)
>> + tcf_hash_insert(tn, *a);
>> + return ret;
>> +}
>> +
>
>
>Thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/4] mlx5: Make building tc hardware offload configurable
From: kbuild test robot @ 2017-01-27 6:29 UTC (permalink / raw)
To: Tom Herbert; +Cc: kbuild-all, saeedm, davem, netdev, kernel-team
In-Reply-To: <20170126233241.2268449-4-tom@herbertland.com>
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
Hi Tom,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Tom-Herbert/mlx5-Create-build-configuration-options/20170127-084348
config: x86_64-randconfig-s3-01271208 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: the linux-review/Tom-Herbert/mlx5-Create-build-configuration-options/20170127-084348 HEAD fe8939265468a7204ffc5b1c6c878b39bae7e7d0 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `mlx5e_configure_flower':
>> (.text+0x22a6a1): undefined reference to `mlx5e_vxlan_lookup_port'
---
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: 31256 bytes --]
^ permalink raw reply
* Re: fs, net: deadlock between bind/splice on af_unix
From: Mateusz Guzik @ 2017-01-27 6:41 UTC (permalink / raw)
To: Cong Wang
Cc: Dmitry Vyukov, Al Viro, linux-fsdevel@vger.kernel.org, LKML,
David Miller, Rainer Weikusat, Hannes Frederic Sowa, netdev,
Eric Dumazet, syzkaller
In-Reply-To: <CAM_iQpXqqmAGPbo6jNJV4bOco9sfvXukNAxYPp4tfL=CNwF-RA@mail.gmail.com>
On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote:
> On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik <mguzik@redhat.com> wrote:
> > On Tue, Jan 17, 2017 at 01:21:48PM -0800, Cong Wang wrote:
> >> On Mon, Jan 16, 2017 at 1:32 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> >> > On Fri, Dec 9, 2016 at 7:41 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >> >> On Thu, Dec 08, 2016 at 10:32:00PM -0800, Cong Wang wrote:
> >> >>
> >> >>> > Why do we do autobind there, anyway, and why is it conditional on
> >> >>> > SOCK_PASSCRED? Note that e.g. for SOCK_STREAM we can bloody well get
> >> >>> > to sending stuff without autobind ever done - just use socketpair()
> >> >>> > to create that sucker and we won't be going through the connect()
> >> >>> > at all.
> >> >>>
> >> >>> In the case Dmitry reported, unix_dgram_sendmsg() calls unix_autobind(),
> >> >>> not SOCK_STREAM.
> >> >>
> >> >> Yes, I've noticed. What I'm asking is what in there needs autobind triggered
> >> >> on sendmsg and why doesn't the same need affect the SOCK_STREAM case?
> >> >>
> >> >>> I guess some lock, perhaps the u->bindlock could be dropped before
> >> >>> acquiring the next one (sb_writer), but I need to double check.
> >> >>
> >> >> Bad idea, IMO - do you *want* autobind being able to come through while
> >> >> bind(2) is busy with mknod?
> >> >
> >> >
> >> > Ping. This is still happening on HEAD.
> >> >
> >>
> >> Thanks for your reminder. Mind to give the attached patch (compile only)
> >> a try? I take another approach to fix this deadlock, which moves the
> >> unix_mknod() out of unix->bindlock. Not sure if there is any unexpected
> >> impact with this way.
> >>
> >
> > I don't think this is the right approach.
> >
> > Currently the file creation is potponed until unix_bind can no longer
> > fail otherwise. With it reordered, it may be someone races you with a
> > different path and now you are left with a file to clean up. Except it
> > is quite unclear for me if you can unlink it.
>
> What races do you mean here? If you mean someone could get a
> refcount of that file, it could happen no matter we have bindlock or not
> since it is visible once created. The filesystem layer should take care of
> the file refcount so all we need to do here is calling path_put() as in my
> patch. Or if you mean two threads calling unix_bind() could race without
> binlock, only one of them should succeed the other one just fails out.
Two threads can race and one fails with EINVAL.
With your patch there is a new file created and it is unclear what to
do with it - leaving it as it is sounds like the last resort and
unlinking it sounds extremely fishy as it opens you to games played by
the user.
^ permalink raw reply
* Re: [PATCH RFC ipsec-next 2/2] xfrm: Add a device independent napi instance
From: Steffen Klassert @ 2017-01-27 6:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David Miller, Sowmini Varadhan, Ilan Tayari
In-Reply-To: <1485443422.5145.132.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, Jan 26, 2017 at 07:10:22AM -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 06:26 -0800, Eric Dumazet wrote:
>
> >
> > Alternative would be to use a
> >
> > static struct net_device xfrm_napi_anchor_device;
> >
> > and use gro_cell
>
> Also take a look at init_dummy_netdev()
I already thought about using some dummy net_device for this,
but was not sure what I need to initialize. So it seemed
to be safer to use a private napi instance.
init_dummy_netdev() is exactly what I need for that, thanks a lot!
^ permalink raw reply
* Re: [PATCH net-next] net: Fix ndo_setup_tc comment
From: Jiri Pirko @ 2017-01-27 7:12 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, davem, john.r.fastabend, jiri, jhs
In-Reply-To: <20170126224417.10327-1-f.fainelli@gmail.com>
Thu, Jan 26, 2017 at 11:44:17PM CET, f.fainelli@gmail.com wrote:
>Commit 16e5cc647173 ("net: rework setup_tc ndo op to consume
>general tc operand") changed the ndo_setup_tc() signature, but did not
>update the comments in netdevice.h, so do that now.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* [PATCH RFC ipsec-next 1/2] net: Drop secpath on free after gro merge.
From: Steffen Klassert @ 2017-01-27 7:19 UTC (permalink / raw)
To: netdev, Eric Dumazet, David Miller
Cc: Steffen Klassert, Sowmini Varadhan, Ilan Tayari
In-Reply-To: <1485501572-20908-1-git-send-email-steffen.klassert@secunet.com>
With a followup patch, a gro merged skb can have a secpath.
So drop it before freeing or reusing the skb.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/core/dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 56818f7..ef3a969 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4623,6 +4623,7 @@ static gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
case GRO_MERGED_FREE:
if (NAPI_GRO_CB(skb)->free == NAPI_GRO_FREE_STOLEN_HEAD) {
skb_dst_drop(skb);
+ secpath_reset(skb);
kmem_cache_free(skbuff_head_cache, skb);
} else {
__kfree_skb(skb);
@@ -4663,6 +4664,7 @@ static void napi_reuse_skb(struct napi_struct *napi, struct sk_buff *skb)
skb->encapsulation = 0;
skb_shinfo(skb)->gso_type = 0;
skb->truesize = SKB_TRUESIZE(skb_end_offset(skb));
+ secpath_reset(skb);
napi->skb = skb;
}
--
1.9.1
^ permalink raw reply related
* [PATCH RFC ipsec-next v2] IPsec GRO
From: Steffen Klassert @ 2017-01-27 7:19 UTC (permalink / raw)
To: netdev, Eric Dumazet, David Miller
Cc: Steffen Klassert, Sowmini Varadhan, Ilan Tayari
This adds a dummy network device so that we can use gro_cells
for IPsec GRO. We now may have a secpath at a GRO merged skb,
so we need to drop it. This is the only change to the generic
networking code.
The packet still travels two times through the stack,
but might be aggregated in the second round. We can
avoid the second round with implementing GRO callbacks
for the IPsec protocols. This will be a separate patchset
as this needs some more generic networking changes because
of the asynchronous nature of IPsec.
^ permalink raw reply
* [PATCH RFC ipsec-next 2/2] xfrm: Add a dummy network device for napi.
From: Steffen Klassert @ 2017-01-27 7:19 UTC (permalink / raw)
To: netdev, Eric Dumazet, David Miller
Cc: Steffen Klassert, Sowmini Varadhan, Ilan Tayari
In-Reply-To: <1485501572-20908-1-git-send-email-steffen.klassert@secunet.com>
This patch adds a dummy network device so that we can
use gro_cells for IPsec GRO. With this, we handle IPsec
GRO with no impact on the generic networking code.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_input.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 6e3f025..3213fe8 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -21,6 +21,9 @@
static DEFINE_SPINLOCK(xfrm_input_afinfo_lock);
static struct xfrm_input_afinfo __rcu *xfrm_input_afinfo[NPROTO];
+static struct gro_cells gro_cells;
+static struct net_device xfrm_napi_dev;
+
int xfrm_input_register_afinfo(struct xfrm_input_afinfo *afinfo)
{
int err = 0;
@@ -371,7 +374,7 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
if (decaps) {
skb_dst_drop(skb);
- netif_rx(skb);
+ gro_cells_receive(&gro_cells, skb);
return 0;
} else {
return x->inner_mode->afinfo->transport_finish(skb, async);
@@ -394,6 +397,13 @@ int xfrm_input_resume(struct sk_buff *skb, int nexthdr)
void __init xfrm_input_init(void)
{
+ int err;
+
+ init_dummy_netdev(&xfrm_napi_dev);
+ err = gro_cells_init(&gro_cells, &xfrm_napi_dev);
+ if (err)
+ gro_cells.cells = NULL;
+
secpath_cachep = kmem_cache_create("secpath_cache",
sizeof(struct sec_path),
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-27 7:33 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <1482598381-16513-3-git-send-email-pali.rohar@gmail.com>
Pali Rohár <pali.rohar@gmail.com> writes:
> NVS calibration data for wl1251 are model specific. Every one device with
> wl1251 chip has different and calibrated in factory.
>
> Not all wl1251 chips have own EEPROM where are calibration data stored. And
> in that case there is no "standard" place. Every device has stored them on
> different place (some in rootfs file, some in dedicated nand partition,
> some in another proprietary structure).
>
> Kernel wl1251 driver cannot support every one different storage decided by
> device manufacture so it will use request_firmware_prefer_user() call for
> loading NVS calibration data and userspace helper will be responsible to
> prepare correct data.
>
> In case userspace helper fails request_firmware_prefer_user() still try to
> load data file directly from VFS as fallback mechanism.
>
> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
> devices.
>
> With this patch it is finally possible to load correct model specific NVS
> calibration data for Nokia N900.
>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
> drivers/net/wireless/ti/wl1251/main.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
> index 7142ccf..affe154 100644
> --- a/drivers/net/wireless/ti/wl1251/Kconfig
> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
> @@ -2,6 +2,7 @@ config WL1251
> tristate "TI wl1251 driver support"
> depends on MAC80211
> select FW_LOADER
> + select FW_LOADER_USER_HELPER
> select CRC7
> ---help---
> This will enable TI wl1251 driver support. The drivers make
> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
> index 208f062..24f8866 100644
> --- a/drivers/net/wireless/ti/wl1251/main.c
> +++ b/drivers/net/wireless/ti/wl1251/main.c
> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> struct device *dev = wiphy_dev(wl->hw->wiphy);
> int ret;
>
> - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
> + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
I don't see the need for this. Just remove the default nvs file from
filesystem and the fallback user helper will be always used, right?
Like we discussed earlier, the default nvs file should not be used by
normal users.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 0/4] USB support for Broadcom NSP SoC
From: Kishon Vijay Abraham I @ 2017-01-27 7:39 UTC (permalink / raw)
To: Florian Fainelli, Yendapally Reddy Dhananjaya Reddy, Rob Herring,
Mark Rutland, Russell King, Ray Jui, Scott Branden, Jon Mason
Cc: devicetree, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <241009ca-4b34-b160-2de1-4752d3ff114b@gmail.com>
Hi,
On Thursday 26 January 2017 10:57 PM, Florian Fainelli wrote:
> On 01/26/2017 07:34 AM, Kishon Vijay Abraham I wrote:
>>
>>
>> On Tuesday 17 January 2017 09:44 PM, Yendapally Reddy Dhananjaya Reddy wrote:
>>> This patch set contains the usb support for Broadcom NSP SoC. The
>>> usb3 phy is internal to the SoC and is accessed through mdio interface.
>>> The mdio interface can be used to access either internal usb3 phy or
>>> external ethernet phy using a multiplexer.
>>>
>>> The first patch provides the documentation details for usb3 phy. The
>>> second patch provides the changes to the mdio bus driver. The third
>>> patch provides the phy driver and fourth patch provides the enable
>>> method for usb.
>>
>> merged the 1st and 4th patch to linux-phy.
>
> You mean 1st and 3rd here, right? 4th is a Device Tree change that I
> should take, and Patch 2 should be merged by David.
yeah, sorry!
>
> What branch in your tree should we be looking at?
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git next
Thanks
Kishon
^ permalink raw reply
* [PATCH v2] net: phy: micrel: add support for KSZ8795
From: Sean Nyekjaer @ 2017-01-27 7:46 UTC (permalink / raw)
To: netdev; +Cc: Sean Nyekjaer, andrew
This is adds support for the PHYs in the KSZ8795 5port managed switch.
It will allow to detect the link between the switch and the soc
and uses the same read_status functions as the KSZ8873MLL switch.
Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
---
Changes in v2:
- Removed "switch" name
drivers/net/phy/micrel.c | 14 ++++++++++++++
include/linux/micrel_phy.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index ea92d524d5a8..fab56c9350cf 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -1014,6 +1014,20 @@ static struct phy_driver ksphy_driver[] = {
.get_stats = kszphy_get_stats,
.suspend = genphy_suspend,
.resume = genphy_resume,
+}, {
+ .phy_id = PHY_ID_KSZ8795,
+ .phy_id_mask = MICREL_PHY_ID_MASK,
+ .name = "Micrel KSZ8795",
+ .features = (SUPPORTED_Pause | SUPPORTED_Asym_Pause),
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = kszphy_config_init,
+ .config_aneg = ksz8873mll_config_aneg,
+ .read_status = ksz8873mll_read_status,
+ .get_sset_count = kszphy_get_sset_count,
+ .get_strings = kszphy_get_strings,
+ .get_stats = kszphy_get_stats,
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
} };
module_phy_driver(ksphy_driver);
diff --git a/include/linux/micrel_phy.h b/include/linux/micrel_phy.h
index 257173e0095e..f541da68d1e7 100644
--- a/include/linux/micrel_phy.h
+++ b/include/linux/micrel_phy.h
@@ -35,6 +35,8 @@
#define PHY_ID_KSZ886X 0x00221430
#define PHY_ID_KSZ8863 0x00221435
+#define PHY_ID_KSZ8795 0x00221550
+
/* struct phy_device dev_flags definitions */
#define MICREL_PHY_50MHZ_CLK 0x00000001
#define MICREL_PHY_FXEN 0x00000002
--
2.11.0
^ permalink raw reply related
* Re: netvsc NAPI patch process
From: Greg KH @ 2017-01-27 7:54 UTC (permalink / raw)
To: David Miller; +Cc: stephen, kys, netdev
In-Reply-To: <20170126.130646.2180422281199593870.davem@davemloft.net>
On Thu, Jan 26, 2017 at 01:06:46PM -0500, David Miller wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Thu, 26 Jan 2017 10:04:05 -0800
>
> > I have a working set of patches to enable NAPI in the netvsc driver.
> > The problem is that it requires a set of patches to vmbus layer as well.
> > Since vmbus patches have been going through char-misc-next tree rather
> > than net-next, it is difficult to stage these.
> >
> > How about if I send the vmbus patches through normal driver-devel upstream
> > and during the 4.10 merge window send the last 3 patches for NAPI for linux-net
> > tree to get into 4.10?
>
> Another option is that the char-misc-next folks create a branch with just
> the commits you need for NAPI, I pull that into net-next, and then you
> can submit the NAPI changes to me.
I can easily do that, or I have no problem with the vmbus changes going
through the net-next tree, if they are sane (i.e. let me review them
please...) Which ever is easier for the networking developers, their
tree is much crazier than the tiny char-misc tree is :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 5/6] wl1251: Parse and use MAC address from supplied NVS data
From: Kalle Valo @ 2017-01-27 7:54 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <1482598381-16513-6-git-send-email-pali.rohar@gmail.com>
Pali Rohár <pali.rohar@gmail.com> writes:
> This patch implements parsing MAC address from NVS data which are sent to
> wl1251 chip. Calibration NVS data could contain valid MAC address and it
> will be used instead randomly generated.
>
> This patch also move code for requesting NVS data from userspace to driver
> initialization code to make sure that NVS data will be there at time when
> permanent MAC address is needed.
>
> Calibration NVS data for wl1251 are model specific. Every one device with
> wl1251 chip should have been calibrated in factory and needs to provide own
> calibration data.
>
> Default example wl1251-nvs.bin data found in linux-firmware repository and
> contains MAC address 00:00:20:07:03:09. So this MAC address is marked as
> invalid as it is not real device specific address, just example one.
>
> Format of calibration NVS data can be found at:
> http://notaz.gp2x.de/misc/pnd/wl1251/nvs_map.txt
>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
[...]
> +static int wl1251_read_nvs_mac(struct wl1251 *wl)
> +{
> + u8 mac[ETH_ALEN];
> + int i;
> +
> + if (wl->nvs_len < 0x24)
> + return -ENODATA;
> +
> + /* length is 2 and data address is 0x546c (mask is 0xfffe) */
> + if (wl->nvs[0x19] != 2 || wl->nvs[0x1a] != 0x6d || wl->nvs[0x1b] != 0x54)
> + return -EINVAL;
> +
> + /* MAC is stored in reverse order */
> + for (i = 0; i < ETH_ALEN; i++)
> + mac[i] = wl->nvs[0x1c + ETH_ALEN - i - 1];
No magic numbers, please. Replace all nvs offsets with proper defines to
make the code more readable.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
From: Kalle Valo @ 2017-01-27 7:56 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <1482598381-16513-7-git-send-email-pali.rohar@gmail.com>
Pali Rohár <pali.rohar@gmail.com> writes:
> In case there is no valid MAC address kernel generates random one. This
> patch propagate this generated MAC address back to NVS data which will be
> uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
> uses.
>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Why? What issue does this fix?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 net] net: free ip_vs_dest structs when refcnt=0
From: Simon Horman @ 2017-01-27 8:07 UTC (permalink / raw)
To: Julian Anastasov, Pablo Neira Ayuso
Cc: David Windsor, netdev, kernel-hardening, netfilter-devel,
lvs-devel, wensong, pablo, keescook, elena.reshetova, ishkamiel
In-Reply-To: <alpine.LFD.2.11.1701262241280.3892@ja.home.ssi.bg>
On Thu, Jan 26, 2017 at 10:49:10PM +0200, Julian Anastasov wrote:
>
> Hello,
>
> On Mon, 23 Jan 2017, David Windsor wrote:
>
> > Currently, the ip_vs_dest cache frees ip_vs_dest objects when their
> > reference count becomes < 0. Aside from not being semantically sound,
> > this is problematic for the new type refcount_t, which will be introduced
> > shortly in a separate patch. refcount_t is the new kernel type for
> > holding reference counts, and provides overflow protection and a
> > constrained interface relative to atomic_t (the type currently being
> > used for kernel reference counts).
> >
> > Per Julian Anastasov: "The problem is that dest_trash currently holds
> > deleted dests (unlinked from RCU lists) with refcnt=0." Changing
> > dest_trash to hold dest with refcnt=1 will allow us to free ip_vs_dest
> > structs when their refcnt=0, in ip_vs_dest_put_and_free().
> >
> > Signed-off-by: David Windsor <dwindsor@gmail.com>
>
> Thanks! I tested the first version and this one
> just adds the needed changes in comments, so
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
>
> Simon and Pablo, this is more appropriate for
> ipvs-next/nf-next. Please apply!
Pablo, would you mind taking this one directly into nf-next?
Signed-off-by: Simon Horman <horms@verge.net.au>
>
> > ---
> > include/net/ip_vs.h | 2 +-
> > net/netfilter/ipvs/ip_vs_ctl.c | 8 +++-----
> > 2 files changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> > index cd6018a..a3e78ad 100644
> > --- a/include/net/ip_vs.h
> > +++ b/include/net/ip_vs.h
> > @@ -1421,7 +1421,7 @@ static inline void ip_vs_dest_put(struct ip_vs_dest *dest)
> >
> > static inline void ip_vs_dest_put_and_free(struct ip_vs_dest *dest)
> > {
> > - if (atomic_dec_return(&dest->refcnt) < 0)
> > + if (atomic_dec_and_test(&dest->refcnt))
> > kfree(dest);
> > }
> >
> > diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> > index 55e0169..5fc4836 100644
> > --- a/net/netfilter/ipvs/ip_vs_ctl.c
> > +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> > @@ -711,7 +711,6 @@ ip_vs_trash_get_dest(struct ip_vs_service *svc, int dest_af,
> > dest->vport == svc->port))) {
> > /* HIT */
> > list_del(&dest->t_list);
> > - ip_vs_dest_hold(dest);
> > goto out;
> > }
> > }
> > @@ -741,7 +740,7 @@ static void ip_vs_dest_free(struct ip_vs_dest *dest)
> > * When the ip_vs_control_clearup is activated by ipvs module exit,
> > * the service tables must have been flushed and all the connections
> > * are expired, and the refcnt of each destination in the trash must
> > - * be 0, so we simply release them here.
> > + * be 1, so we simply release them here.
> > */
> > static void ip_vs_trash_cleanup(struct netns_ipvs *ipvs)
> > {
> > @@ -1080,11 +1079,10 @@ static void __ip_vs_del_dest(struct netns_ipvs *ipvs, struct ip_vs_dest *dest,
> > if (list_empty(&ipvs->dest_trash) && !cleanup)
> > mod_timer(&ipvs->dest_trash_timer,
> > jiffies + (IP_VS_DEST_TRASH_PERIOD >> 1));
> > - /* dest lives in trash without reference */
> > + /* dest lives in trash with reference */
> > list_add(&dest->t_list, &ipvs->dest_trash);
> > dest->idle_start = 0;
> > spin_unlock_bh(&ipvs->dest_trash_lock);
> > - ip_vs_dest_put(dest);
> > }
> >
> >
> > @@ -1160,7 +1158,7 @@ static void ip_vs_dest_trash_expire(unsigned long data)
> >
> > spin_lock(&ipvs->dest_trash_lock);
> > list_for_each_entry_safe(dest, next, &ipvs->dest_trash, t_list) {
> > - if (atomic_read(&dest->refcnt) > 0)
> > + if (atomic_read(&dest->refcnt) > 1)
> > continue;
> > if (dest->idle_start) {
> > if (time_before(now, dest->idle_start +
> > --
> > 2.7.4
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
^ permalink raw reply
* Re: [PATCH v1] net: phy: micrel: add KSZ8795 ethernet switch
From: Sean Nyekjær @ 2017-01-27 7:42 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20170126181207.GF5656@lunn.ch>
On 2017-01-26 19:12, Andrew Lunn wrote:
>> I remove the word "Switch" from the commit message and phy name.
>> The rest is okay?
> Yes.
>
>> What is generally being done when to phy's have the same id, micrel
>> have done this many times...
> It should not be a problem. When you write a switch driver for the
> switch, it will be in device tree. Look at the Marvell Switches as an
> example. Switches don't probe based on the ID in registers 2 and 3,
> because switches often respond to many different addresses, or don't
> have an ID in register 2 and 3.
>
> So it should not matter if the switch and the PHYs embedded in the
> switch have the same ID.
>
> When do you plan to post your switch driver?
>
> Andrew
I was not planning on doing that, the managed part of the switch is not
needed in the project i'm working on.
Maybe i will do it when i have some spare time, it could be fun :-)
/Sean
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Arend Van Spriel @ 2017-01-27 8:58 UTC (permalink / raw)
To: Kalle Valo, Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <87tw8lnei3.fsf@codeaurora.org>
On 27-1-2017 8:33, Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
>> NVS calibration data for wl1251 are model specific. Every one device with
>> wl1251 chip has different and calibrated in factory.
>>
>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
>> in that case there is no "standard" place. Every device has stored them on
>> different place (some in rootfs file, some in dedicated nand partition,
>> some in another proprietary structure).
>>
>> Kernel wl1251 driver cannot support every one different storage decided by
>> device manufacture so it will use request_firmware_prefer_user() call for
>> loading NVS calibration data and userspace helper will be responsible to
>> prepare correct data.
>>
>> In case userspace helper fails request_firmware_prefer_user() still try to
>> load data file directly from VFS as fallback mechanism.
>>
>> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
>> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
>> devices.
>>
>> With this patch it is finally possible to load correct model specific NVS
>> calibration data for Nokia N900.
>>
>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>> ---
>> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
>> drivers/net/wireless/ti/wl1251/main.c | 2 +-
>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
>> index 7142ccf..affe154 100644
>> --- a/drivers/net/wireless/ti/wl1251/Kconfig
>> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
>> @@ -2,6 +2,7 @@ config WL1251
>> tristate "TI wl1251 driver support"
>> depends on MAC80211
>> select FW_LOADER
>> + select FW_LOADER_USER_HELPER
>> select CRC7
>> ---help---
>> This will enable TI wl1251 driver support. The drivers make
>> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
>> index 208f062..24f8866 100644
>> --- a/drivers/net/wireless/ti/wl1251/main.c
>> +++ b/drivers/net/wireless/ti/wl1251/main.c
>> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
>> struct device *dev = wiphy_dev(wl->hw->wiphy);
>> int ret;
>>
>> - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
>> + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
>
> I don't see the need for this. Just remove the default nvs file from
> filesystem and the fallback user helper will be always used, right?
Indeed. The only remaining issue would be that an error message is
logged. Also note the fallback is only used if selected in Kconfig.
> Like we discussed earlier, the default nvs file should not be used by
> normal users.
Yup.
Regards,
Arend
^ permalink raw reply
* pull-request: can-next 2017-01-24
From: Marc Kleine-Budde @ 2017-01-27 9:02 UTC (permalink / raw)
To: netdev; +Cc: David Miller, kernel@pengutronix.de, linux-can@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 2071 bytes --]
Hello David,
this is a pull request of 4 patches for net-next/master.
The first patch by Oliver Hartkopp adds a netlink API to configure the
interface termination of a CAN card. The next two patches are by me and
add a netlink API to query and configure CAN interfaces that only
support fixed bitrates. The last patch by Colin Ian King simplifies the
return path in the softing_cs driver's softingcs_probe() function.
regards,
Marc
---
The following changes since commit d140199af510ad4749dc5e38b7922135258ba5fd:
bpf, lpm: fix kfree of im_node in trie_update_elem (2017-01-23 21:17:35 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git tags/linux-can-next-for-4.11-20170124
for you to fetch changes up to 1e9bbb9bc2aa549d31fa0a0496ec33df0b3ae7a8:
can: softing_cs: ret is never non-zero, so remove non-zero check and -ENODEV return (2017-01-24 13:52:00 +0100)
----------------------------------------------------------------
linux-can-next-for-4.11-20170124
----------------------------------------------------------------
Colin Ian King (1):
can: softing_cs: ret is never non-zero, so remove non-zero check and -ENODEV return
Marc Kleine-Budde (2):
can: dev: can_changelink: allow to set bitrate on devices not providing {data_,}bittiming_const
can: dev: add CAN interface API for fixed bitrates
Oliver Hartkopp (1):
can: dev: add CAN interface termination API
drivers/net/can/dev.c | 136 ++++++++++++++++++++++++++++++++---
drivers/net/can/softing/softing_cs.c | 2 +-
include/linux/can/dev.h | 8 +++
include/uapi/linux/can/netlink.h | 7 ++
4 files changed, 142 insertions(+), 11 deletions(-)
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
From: Pali Rohár @ 2017-01-27 9:05 UTC (permalink / raw)
To: Kalle Valo
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <87inp1ndgm.fsf@codeaurora.org>
On Friday 27 January 2017 09:56:09 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > In case there is no valid MAC address kernel generates random one. This
> > patch propagate this generated MAC address back to NVS data which will be
> > uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
> > uses.
> >
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>
> Why? What issue does this fix?
Send permanent MAC address to wl1251 chip, same what is doing wl12xx
driver.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* [PATCH 0/3] net-next: use one struct bgmac & add PHY support
From: Rafał Miłecki @ 2017-01-27 9:20 UTC (permalink / raw)
To: David S . Miller
Cc: Jon Mason, Florian Fainelli, Felix Fietkau, netdev,
Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
This patchset adds support for initializing PHY using PHY subsystem.
It's required e.g. for wireless access point devices that use bgmac
supported Ethernet device connected to some external PHY.
Implementing this required accessing phydev in bcma specific code which
wasn't possible with core code allocating struct bgmac on its own. This
is why I needed to modify alloc_etherdev usage first.
Rafał Miłecki (3):
net: bgmac: allocate struct bgmac just once & don't copy it
net: bgmac: drop struct bcma_mdio we don't need anymore
net: bgmac: use PHY subsystem for initializing PHY
drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c | 108 +++++++++++-------------
drivers/net/ethernet/broadcom/bgmac-bcma.c | 2 +-
drivers/net/ethernet/broadcom/bgmac-platform.c | 2 +-
drivers/net/ethernet/broadcom/bgmac.c | 24 +++---
drivers/net/ethernet/broadcom/bgmac.h | 2 +-
5 files changed, 64 insertions(+), 74 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/3] net: bgmac: allocate struct bgmac just once & don't copy it
From: Rafał Miłecki @ 2017-01-27 9:20 UTC (permalink / raw)
To: David S . Miller
Cc: Jon Mason, Florian Fainelli, Felix Fietkau, netdev,
Rafał Miłecki
In-Reply-To: <20170127092043.17413-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
To share as much code as possible in bgmac we call alloc_etherdev from
bgmac.c which is used by both: platform and bcma code. The easiest
solution was to use it for allocating whole struct bgmac but it doesn't
work well as we already get early-filled struct bgmac as an argument.
So far we were solving this by copying received struct into newly
allocated one. The problem is it means storing 2 allocated structs,
using only 1 of them and non-shared code not having access to it.
This patch solves it by using alloc_etherdev to allocate *pointer* for
the already allocated struct. The only downside of this is we have to be
careful when using netdev_priv.
Another solution was to call alloc_etherdev in platform/bcma specific
code but Jon advised against it due to sharing less code that way.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/ethernet/broadcom/bgmac-platform.c | 2 +-
drivers/net/ethernet/broadcom/bgmac.c | 24 +++++++++++-------------
2 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
index 6f736c19872f..4fefd1a74fcb 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -98,7 +98,7 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
static void bgmac_nicpm_speed_set(struct net_device *net_dev)
{
- struct bgmac *bgmac = netdev_priv(net_dev);
+ struct bgmac *bgmac = *(struct bgmac **)netdev_priv(net_dev);
u32 val;
if (!bgmac->plat.nicpm_base)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 0e066dc6b8cc..73d679337903 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -777,7 +777,7 @@ static void bgmac_write_mac_address(struct bgmac *bgmac, u8 *addr)
static void bgmac_set_rx_mode(struct net_device *net_dev)
{
- struct bgmac *bgmac = netdev_priv(net_dev);
+ struct bgmac *bgmac = *(struct bgmac **)netdev_priv(net_dev);
if (net_dev->flags & IFF_PROMISC)
bgmac_cmdcfg_maskset(bgmac, ~0, BGMAC_CMDCFG_PROM, true);
@@ -1112,7 +1112,7 @@ static void bgmac_chip_init(struct bgmac *bgmac)
static irqreturn_t bgmac_interrupt(int irq, void *dev_id)
{
- struct bgmac *bgmac = netdev_priv(dev_id);
+ struct bgmac *bgmac = *(struct bgmac **)netdev_priv(dev_id);
u32 int_status = bgmac_read(bgmac, BGMAC_INT_STATUS);
int_status &= bgmac->int_mask;
@@ -1161,7 +1161,7 @@ static int bgmac_poll(struct napi_struct *napi, int weight)
static int bgmac_open(struct net_device *net_dev)
{
- struct bgmac *bgmac = netdev_priv(net_dev);
+ struct bgmac *bgmac = *(struct bgmac **)netdev_priv(net_dev);
int err = 0;
bgmac_chip_reset(bgmac);
@@ -1191,7 +1191,7 @@ static int bgmac_open(struct net_device *net_dev)
static int bgmac_stop(struct net_device *net_dev)
{
- struct bgmac *bgmac = netdev_priv(net_dev);
+ struct bgmac *bgmac = *(struct bgmac **)netdev_priv(net_dev);
netif_carrier_off(net_dev);
@@ -1210,7 +1210,7 @@ static int bgmac_stop(struct net_device *net_dev)
static netdev_tx_t bgmac_start_xmit(struct sk_buff *skb,
struct net_device *net_dev)
{
- struct bgmac *bgmac = netdev_priv(net_dev);
+ struct bgmac *bgmac = *(struct bgmac **)netdev_priv(net_dev);
struct bgmac_dma_ring *ring;
/* No QOS support yet */
@@ -1220,7 +1220,7 @@ static netdev_tx_t bgmac_start_xmit(struct sk_buff *skb,
static int bgmac_set_mac_address(struct net_device *net_dev, void *addr)
{
- struct bgmac *bgmac = netdev_priv(net_dev);
+ struct bgmac *bgmac = *(struct bgmac **)netdev_priv(net_dev);
int ret;
ret = eth_prepare_mac_addr_change(net_dev, addr);
@@ -1356,7 +1356,7 @@ static void bgmac_get_strings(struct net_device *dev, u32 stringset,
static void bgmac_get_ethtool_stats(struct net_device *dev,
struct ethtool_stats *ss, uint64_t *data)
{
- struct bgmac *bgmac = netdev_priv(dev);
+ struct bgmac *bgmac = *(struct bgmac **)netdev_priv(dev);
const struct bgmac_stat *s;
unsigned int i;
u64 val;
@@ -1396,7 +1396,7 @@ static const struct ethtool_ops bgmac_ethtool_ops = {
void bgmac_adjust_link(struct net_device *net_dev)
{
- struct bgmac *bgmac = netdev_priv(net_dev);
+ struct bgmac *bgmac = *(struct bgmac **)netdev_priv(net_dev);
struct phy_device *phy_dev = net_dev->phydev;
bool update = false;
@@ -1446,21 +1446,19 @@ int bgmac_phy_connect_direct(struct bgmac *bgmac)
}
EXPORT_SYMBOL_GPL(bgmac_phy_connect_direct);
-int bgmac_enet_probe(struct bgmac *info)
+int bgmac_enet_probe(struct bgmac *bgmac)
{
struct net_device *net_dev;
- struct bgmac *bgmac;
int err;
/* Allocation and references */
- net_dev = alloc_etherdev(sizeof(*bgmac));
+ net_dev = alloc_etherdev(sizeof(struct bgmac **));
if (!net_dev)
return -ENOMEM;
net_dev->netdev_ops = &bgmac_netdev_ops;
net_dev->ethtool_ops = &bgmac_ethtool_ops;
- bgmac = netdev_priv(net_dev);
- memcpy(bgmac, info, sizeof(*bgmac));
+ *(struct bgmac **)netdev_priv(net_dev) = bgmac;
bgmac->net_dev = net_dev;
net_dev->irq = bgmac->irq;
SET_NETDEV_DEV(net_dev, bgmac->dev);
--
2.11.0
^ permalink raw reply related
* [PATCH 3/3] net: bgmac: use PHY subsystem for initializing PHY
From: Rafał Miłecki @ 2017-01-27 9:20 UTC (permalink / raw)
To: David S . Miller
Cc: Jon Mason, Florian Fainelli, Felix Fietkau, netdev,
Rafał Miłecki
In-Reply-To: <20170127092043.17413-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
This adds support for using bgmac with PHYs supported by standalone PHY
drivers. Having any PHY initialization in bgmac is hacky and shouldn't
be extended but rather removed if anyone has hardware to test it.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c b/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
index 9d9984999dce..6ce80cbcb48e 100644
--- a/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
@@ -132,6 +132,10 @@ static void bcma_mdio_phy_init(struct bgmac *bgmac)
struct bcma_chipinfo *ci = &bgmac->bcma.core->bus->chipinfo;
u8 i;
+ /* For some legacy hardware we do chipset-based PHY initialization here
+ * without even detecting PHY ID. It's hacky and should be cleaned as
+ * soon as someone can test it.
+ */
if (ci->id == BCMA_CHIP_ID_BCM5356) {
for (i = 0; i < 5; i++) {
bcma_mdio_phy_write(bgmac, i, 0x1f, 0x008b);
@@ -140,6 +144,7 @@ static void bcma_mdio_phy_init(struct bgmac *bgmac)
bcma_mdio_phy_write(bgmac, i, 0x12, 0x2aaa);
bcma_mdio_phy_write(bgmac, i, 0x1f, 0x000b);
}
+ return;
}
if ((ci->id == BCMA_CHIP_ID_BCM5357 && ci->pkg != 10) ||
(ci->id == BCMA_CHIP_ID_BCM4749 && ci->pkg != 10) ||
@@ -161,7 +166,12 @@ static void bcma_mdio_phy_init(struct bgmac *bgmac)
bcma_mdio_phy_write(bgmac, i, 0x17, 0x9273);
bcma_mdio_phy_write(bgmac, i, 0x1f, 0x000b);
}
+ return;
}
+
+ /* For all other hw do initialization using PHY subsystem. */
+ if (bgmac->net_dev && bgmac->net_dev->phydev)
+ phy_init_hw(bgmac->net_dev->phydev);
}
/* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipphyreset */
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] net: bgmac: drop struct bcma_mdio we don't need anymore
From: Rafał Miłecki @ 2017-01-27 9:20 UTC (permalink / raw)
To: David S . Miller
Cc: Jon Mason, Florian Fainelli, Felix Fietkau, netdev,
Rafał Miłecki
In-Reply-To: <20170127092043.17413-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
Adding struct bcma_mdio was a workaround for bcma code not having access
to the struct bgmac used in the core code. Now we don't duplicate this
struct we can just use it internally in bcma code.
This simplifies code & allows access to all bgmac driver details from
all places in bcma code.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c | 98 ++++++++++---------------
drivers/net/ethernet/broadcom/bgmac-bcma.c | 2 +-
drivers/net/ethernet/broadcom/bgmac.h | 2 +-
3 files changed, 42 insertions(+), 60 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c b/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
index 7c19c8e2bf91..9d9984999dce 100644
--- a/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
@@ -12,11 +12,6 @@
#include <linux/brcmphy.h>
#include "bgmac.h"
-struct bcma_mdio {
- struct bcma_device *core;
- u8 phyaddr;
-};
-
static bool bcma_mdio_wait_value(struct bcma_device *core, u16 reg, u32 mask,
u32 value, int timeout)
{
@@ -37,7 +32,7 @@ static bool bcma_mdio_wait_value(struct bcma_device *core, u16 reg, u32 mask,
* PHY ops
**************************************************/
-static u16 bcma_mdio_phy_read(struct bcma_mdio *bcma_mdio, u8 phyaddr, u8 reg)
+static u16 bcma_mdio_phy_read(struct bgmac *bgmac, u8 phyaddr, u8 reg)
{
struct bcma_device *core;
u16 phy_access_addr;
@@ -56,12 +51,12 @@ static u16 bcma_mdio_phy_read(struct bcma_mdio *bcma_mdio, u8 phyaddr, u8 reg)
BUILD_BUG_ON(BGMAC_PC_MCT_SHIFT != BCMA_GMAC_CMN_PC_MCT_SHIFT);
BUILD_BUG_ON(BGMAC_PC_MTE != BCMA_GMAC_CMN_PC_MTE);
- if (bcma_mdio->core->id.id == BCMA_CORE_4706_MAC_GBIT) {
- core = bcma_mdio->core->bus->drv_gmac_cmn.core;
+ if (bgmac->bcma.core->id.id == BCMA_CORE_4706_MAC_GBIT) {
+ core = bgmac->bcma.core->bus->drv_gmac_cmn.core;
phy_access_addr = BCMA_GMAC_CMN_PHY_ACCESS;
phy_ctl_addr = BCMA_GMAC_CMN_PHY_CTL;
} else {
- core = bcma_mdio->core;
+ core = bgmac->bcma.core;
phy_access_addr = BGMAC_PHY_ACCESS;
phy_ctl_addr = BGMAC_PHY_CNTL;
}
@@ -87,7 +82,7 @@ static u16 bcma_mdio_phy_read(struct bcma_mdio *bcma_mdio, u8 phyaddr, u8 reg)
}
/* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipphywr */
-static int bcma_mdio_phy_write(struct bcma_mdio *bcma_mdio, u8 phyaddr, u8 reg,
+static int bcma_mdio_phy_write(struct bgmac *bgmac, u8 phyaddr, u8 reg,
u16 value)
{
struct bcma_device *core;
@@ -95,12 +90,12 @@ static int bcma_mdio_phy_write(struct bcma_mdio *bcma_mdio, u8 phyaddr, u8 reg,
u16 phy_ctl_addr;
u32 tmp;
- if (bcma_mdio->core->id.id == BCMA_CORE_4706_MAC_GBIT) {
- core = bcma_mdio->core->bus->drv_gmac_cmn.core;
+ if (bgmac->bcma.core->id.id == BCMA_CORE_4706_MAC_GBIT) {
+ core = bgmac->bcma.core->bus->drv_gmac_cmn.core;
phy_access_addr = BCMA_GMAC_CMN_PHY_ACCESS;
phy_ctl_addr = BCMA_GMAC_CMN_PHY_CTL;
} else {
- core = bcma_mdio->core;
+ core = bgmac->bcma.core;
phy_access_addr = BGMAC_PHY_ACCESS;
phy_ctl_addr = BGMAC_PHY_CNTL;
}
@@ -110,8 +105,8 @@ static int bcma_mdio_phy_write(struct bcma_mdio *bcma_mdio, u8 phyaddr, u8 reg,
tmp |= phyaddr;
bcma_write32(core, phy_ctl_addr, tmp);
- bcma_write32(bcma_mdio->core, BGMAC_INT_STATUS, BGMAC_IS_MDIO);
- if (bcma_read32(bcma_mdio->core, BGMAC_INT_STATUS) & BGMAC_IS_MDIO)
+ bcma_write32(bgmac->bcma.core, BGMAC_INT_STATUS, BGMAC_IS_MDIO);
+ if (bcma_read32(bgmac->bcma.core, BGMAC_INT_STATUS) & BGMAC_IS_MDIO)
dev_warn(&core->dev, "Error setting MDIO int\n");
tmp = BGMAC_PA_START;
@@ -132,39 +127,39 @@ static int bcma_mdio_phy_write(struct bcma_mdio *bcma_mdio, u8 phyaddr, u8 reg,
}
/* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipphyinit */
-static void bcma_mdio_phy_init(struct bcma_mdio *bcma_mdio)
+static void bcma_mdio_phy_init(struct bgmac *bgmac)
{
- struct bcma_chipinfo *ci = &bcma_mdio->core->bus->chipinfo;
+ struct bcma_chipinfo *ci = &bgmac->bcma.core->bus->chipinfo;
u8 i;
if (ci->id == BCMA_CHIP_ID_BCM5356) {
for (i = 0; i < 5; i++) {
- bcma_mdio_phy_write(bcma_mdio, i, 0x1f, 0x008b);
- bcma_mdio_phy_write(bcma_mdio, i, 0x15, 0x0100);
- bcma_mdio_phy_write(bcma_mdio, i, 0x1f, 0x000f);
- bcma_mdio_phy_write(bcma_mdio, i, 0x12, 0x2aaa);
- bcma_mdio_phy_write(bcma_mdio, i, 0x1f, 0x000b);
+ bcma_mdio_phy_write(bgmac, i, 0x1f, 0x008b);
+ bcma_mdio_phy_write(bgmac, i, 0x15, 0x0100);
+ bcma_mdio_phy_write(bgmac, i, 0x1f, 0x000f);
+ bcma_mdio_phy_write(bgmac, i, 0x12, 0x2aaa);
+ bcma_mdio_phy_write(bgmac, i, 0x1f, 0x000b);
}
}
if ((ci->id == BCMA_CHIP_ID_BCM5357 && ci->pkg != 10) ||
(ci->id == BCMA_CHIP_ID_BCM4749 && ci->pkg != 10) ||
(ci->id == BCMA_CHIP_ID_BCM53572 && ci->pkg != 9)) {
- struct bcma_drv_cc *cc = &bcma_mdio->core->bus->drv_cc;
+ struct bcma_drv_cc *cc = &bgmac->bcma.core->bus->drv_cc;
bcma_chipco_chipctl_maskset(cc, 2, ~0xc0000000, 0);
bcma_chipco_chipctl_maskset(cc, 4, ~0x80000000, 0);
for (i = 0; i < 5; i++) {
- bcma_mdio_phy_write(bcma_mdio, i, 0x1f, 0x000f);
- bcma_mdio_phy_write(bcma_mdio, i, 0x16, 0x5284);
- bcma_mdio_phy_write(bcma_mdio, i, 0x1f, 0x000b);
- bcma_mdio_phy_write(bcma_mdio, i, 0x17, 0x0010);
- bcma_mdio_phy_write(bcma_mdio, i, 0x1f, 0x000f);
- bcma_mdio_phy_write(bcma_mdio, i, 0x16, 0x5296);
- bcma_mdio_phy_write(bcma_mdio, i, 0x17, 0x1073);
- bcma_mdio_phy_write(bcma_mdio, i, 0x17, 0x9073);
- bcma_mdio_phy_write(bcma_mdio, i, 0x16, 0x52b6);
- bcma_mdio_phy_write(bcma_mdio, i, 0x17, 0x9273);
- bcma_mdio_phy_write(bcma_mdio, i, 0x1f, 0x000b);
+ bcma_mdio_phy_write(bgmac, i, 0x1f, 0x000f);
+ bcma_mdio_phy_write(bgmac, i, 0x16, 0x5284);
+ bcma_mdio_phy_write(bgmac, i, 0x1f, 0x000b);
+ bcma_mdio_phy_write(bgmac, i, 0x17, 0x0010);
+ bcma_mdio_phy_write(bgmac, i, 0x1f, 0x000f);
+ bcma_mdio_phy_write(bgmac, i, 0x16, 0x5296);
+ bcma_mdio_phy_write(bgmac, i, 0x17, 0x1073);
+ bcma_mdio_phy_write(bgmac, i, 0x17, 0x9073);
+ bcma_mdio_phy_write(bgmac, i, 0x16, 0x52b6);
+ bcma_mdio_phy_write(bgmac, i, 0x17, 0x9273);
+ bcma_mdio_phy_write(bgmac, i, 0x1f, 0x000b);
}
}
}
@@ -172,17 +167,17 @@ static void bcma_mdio_phy_init(struct bcma_mdio *bcma_mdio)
/* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipphyreset */
static int bcma_mdio_phy_reset(struct mii_bus *bus)
{
- struct bcma_mdio *bcma_mdio = bus->priv;
- u8 phyaddr = bcma_mdio->phyaddr;
+ struct bgmac *bgmac = bus->priv;
+ u8 phyaddr = bgmac->phyaddr;
- if (bcma_mdio->phyaddr == BGMAC_PHY_NOREGS)
+ if (phyaddr == BGMAC_PHY_NOREGS)
return 0;
- bcma_mdio_phy_write(bcma_mdio, phyaddr, MII_BMCR, BMCR_RESET);
+ bcma_mdio_phy_write(bgmac, phyaddr, MII_BMCR, BMCR_RESET);
udelay(100);
- if (bcma_mdio_phy_read(bcma_mdio, phyaddr, MII_BMCR) & BMCR_RESET)
- dev_err(&bcma_mdio->core->dev, "PHY reset failed\n");
- bcma_mdio_phy_init(bcma_mdio);
+ if (bcma_mdio_phy_read(bgmac, phyaddr, MII_BMCR) & BMCR_RESET)
+ dev_err(bgmac->dev, "PHY reset failed\n");
+ bcma_mdio_phy_init(bgmac);
return 0;
}
@@ -202,16 +197,12 @@ static int bcma_mdio_mii_write(struct mii_bus *bus, int mii_id, int regnum,
return bcma_mdio_phy_write(bus->priv, mii_id, regnum, value);
}
-struct mii_bus *bcma_mdio_mii_register(struct bcma_device *core, u8 phyaddr)
+struct mii_bus *bcma_mdio_mii_register(struct bgmac *bgmac)
{
- struct bcma_mdio *bcma_mdio;
+ struct bcma_device *core = bgmac->bcma.core;
struct mii_bus *mii_bus;
int err;
- bcma_mdio = kzalloc(sizeof(*bcma_mdio), GFP_KERNEL);
- if (!bcma_mdio)
- return ERR_PTR(-ENOMEM);
-
mii_bus = mdiobus_alloc();
if (!mii_bus) {
err = -ENOMEM;
@@ -221,15 +212,12 @@ struct mii_bus *bcma_mdio_mii_register(struct bcma_device *core, u8 phyaddr)
mii_bus->name = "bcma_mdio mii bus";
sprintf(mii_bus->id, "%s-%d-%d", "bcma_mdio", core->bus->num,
core->core_unit);
- mii_bus->priv = bcma_mdio;
+ mii_bus->priv = bgmac;
mii_bus->read = bcma_mdio_mii_read;
mii_bus->write = bcma_mdio_mii_write;
mii_bus->reset = bcma_mdio_phy_reset;
mii_bus->parent = &core->dev;
- mii_bus->phy_mask = ~(1 << phyaddr);
-
- bcma_mdio->core = core;
- bcma_mdio->phyaddr = phyaddr;
+ mii_bus->phy_mask = ~(1 << bgmac->phyaddr);
err = mdiobus_register(mii_bus);
if (err) {
@@ -242,23 +230,17 @@ struct mii_bus *bcma_mdio_mii_register(struct bcma_device *core, u8 phyaddr)
err_free_bus:
mdiobus_free(mii_bus);
err:
- kfree(bcma_mdio);
return ERR_PTR(err);
}
EXPORT_SYMBOL_GPL(bcma_mdio_mii_register);
void bcma_mdio_mii_unregister(struct mii_bus *mii_bus)
{
- struct bcma_mdio *bcma_mdio;
-
if (!mii_bus)
return;
- bcma_mdio = mii_bus->priv;
-
mdiobus_unregister(mii_bus);
mdiobus_free(mii_bus);
- kfree(bcma_mdio);
}
EXPORT_SYMBOL_GPL(bcma_mdio_mii_unregister);
diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c b/drivers/net/ethernet/broadcom/bgmac-bcma.c
index 4a4ffc0c4c65..bcd565ba9661 100644
--- a/drivers/net/ethernet/broadcom/bgmac-bcma.c
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
@@ -178,7 +178,7 @@ static int bgmac_probe(struct bcma_device *core)
if (!bgmac_is_bcm4707_family(core) &&
!(ci->id == BCMA_CHIP_ID_BCM53573 && core->core_unit == 1)) {
- mii_bus = bcma_mdio_mii_register(core, bgmac->phyaddr);
+ mii_bus = bcma_mdio_mii_register(bgmac);
if (IS_ERR(mii_bus)) {
err = PTR_ERR(mii_bus);
goto err;
diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
index 71f493f2451f..36b782b4b959 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -522,7 +522,7 @@ void bgmac_enet_remove(struct bgmac *bgmac);
void bgmac_adjust_link(struct net_device *net_dev);
int bgmac_phy_connect_direct(struct bgmac *bgmac);
-struct mii_bus *bcma_mdio_mii_register(struct bcma_device *core, u8 phyaddr);
+struct mii_bus *bcma_mdio_mii_register(struct bgmac *bgmac);
void bcma_mdio_mii_unregister(struct mii_bus *mii_bus);
static inline u32 bgmac_read(struct bgmac *bgmac, u16 offset)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
From: Kalle Valo @ 2017-01-27 9:30 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127090538.GB24223@pali>
Pali Rohár <pali.rohar@gmail.com> writes:
> On Friday 27 January 2017 09:56:09 Kalle Valo wrote:
>> Pali Rohár <pali.rohar@gmail.com> writes:
>>
>> > In case there is no valid MAC address kernel generates random one. This
>> > patch propagate this generated MAC address back to NVS data which will be
>> > uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
>> > uses.
>> >
>> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>>
>> Why? What issue does this fix?
>
> Send permanent MAC address to wl1251 chip, same what is doing wl12xx
> driver.
Ok, so this doesn't change functionality in any way and you are adding
it only because wl12xx does the same? You should document that in the
the commit log.
If there's no change I don't really see the point of this. But if
there's harm, hopefully, I guess it's ok.
--
Kalle Valo
^ permalink raw reply
* [PATCH net v3 0/3] various gtp fixes
From: Andreas Schultz @ 2017-01-27 9:40 UTC (permalink / raw)
To: Pablo Neira
Cc: netdev, Lionel Gauthier, openbsc, Harald Welte, SF Markus Elfring
I'm sorry for the compile error mess up in the last version.
It's no excuse for not test compiling, but the hunks got lost in
a rebase.
This is the part of the previous "simple gtp improvements" series
that Pablo indicated should go into net.
The addition of the module alias fixes genl family autoloading,
clearing the DF bit fixes a protocol violation in regard to the
specification and the netns comparison fixes a corner case of
cross netns recv.
Andreas
v2->v3: fix compiler error introduced in rebase
^ 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