* [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
* [PATCH net v3 1/3] gtp: add genl family modules alias
From: Andreas Schultz @ 2017-01-27 9:40 UTC (permalink / raw)
To: Pablo Neira
Cc: netdev, Lionel Gauthier, openbsc, Harald Welte, SF Markus Elfring
In-Reply-To: <20170127094058.7899-1-aschultz@tpip.net>
Auto-load the module when userspace asks for the gtp netlink
family.
Signed-off-by: Andreas Schultz <aschultz@tpip.net>
Acked-by: Harald Welte <laforge@netfilter.org>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
drivers/net/gtp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 8b6810b..7580ccc 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -1376,3 +1376,4 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Harald Welte <hwelte@sysmocom.de>");
MODULE_DESCRIPTION("Interface driver for GTP encapsulated traffic");
MODULE_ALIAS_RTNL_LINK("gtp");
+MODULE_ALIAS_GENL_FAMILY("gtp");
--
2.10.2
^ permalink raw reply related
* [PATCH net v3 2/3] gtp: clear DF bit on GTP packet tx
From: Andreas Schultz @ 2017-01-27 9:40 UTC (permalink / raw)
To: Pablo Neira
Cc: netdev, Lionel Gauthier, openbsc, Harald Welte, SF Markus Elfring
In-Reply-To: <20170127094058.7899-1-aschultz@tpip.net>
3GPP TS 29.281 and 3GPP TS 29.060 imply that GTP-U packets should be
sent with the DF bit cleared. For example 3GPP TS 29.060, Release 8,
Section 13.2.2:
> Backbone router: Any router in the backbone may fragment the GTP
> packet if needed, according to IPv4.
Signed-off-by: Andreas Schultz <aschultz@tpip.net>
Acked-by: Harald Welte <laforge@netfilter.org>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
drivers/net/gtp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 7580ccc..1df54d6 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -612,7 +612,7 @@ static netdev_tx_t gtp_dev_xmit(struct sk_buff *skb, struct net_device *dev)
pktinfo.fl4.saddr, pktinfo.fl4.daddr,
pktinfo.iph->tos,
ip4_dst_hoplimit(&pktinfo.rt->dst),
- htons(IP_DF),
+ 0,
pktinfo.gtph_port, pktinfo.gtph_port,
true, false);
break;
--
2.10.2
^ permalink raw reply related
* [PATCH net v3 3/3] gtp: fix cross netns recv on gtp socket
From: Andreas Schultz @ 2017-01-27 9:40 UTC (permalink / raw)
To: Pablo Neira
Cc: netdev, Lionel Gauthier, openbsc, Harald Welte, SF Markus Elfring
In-Reply-To: <20170127094058.7899-1-aschultz@tpip.net>
The use of the passed through netlink src_net to check for a
cross netns operation was wrong. Using the GTP socket and the
GTP netdevice is always correct (even if the netdev has been
moved to new netns after link creation).
Remove the now obsolete net field from gtp_dev.
Signed-off-by: Andreas Schultz <aschultz@tpip.net>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
drivers/net/gtp.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 1df54d6..99d3df7 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -69,7 +69,6 @@ struct gtp_dev {
struct socket *sock0;
struct socket *sock1u;
- struct net *net;
struct net_device *dev;
unsigned int hash_size;
@@ -316,7 +315,7 @@ static int gtp_encap_recv(struct sock *sk, struct sk_buff *skb)
netdev_dbg(gtp->dev, "encap_recv sk=%p\n", sk);
- xnet = !net_eq(gtp->net, dev_net(gtp->dev));
+ xnet = !net_eq(sock_net(sk), dev_net(gtp->dev));
switch (udp_sk(sk)->encap_type) {
case UDP_ENCAP_GTP0:
@@ -658,7 +657,7 @@ static void gtp_link_setup(struct net_device *dev)
static int gtp_hashtable_new(struct gtp_dev *gtp, int hsize);
static void gtp_hashtable_free(struct gtp_dev *gtp);
static int gtp_encap_enable(struct net_device *dev, struct gtp_dev *gtp,
- int fd_gtp0, int fd_gtp1, struct net *src_net);
+ int fd_gtp0, int fd_gtp1);
static int gtp_newlink(struct net *src_net, struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
@@ -675,7 +674,7 @@ static int gtp_newlink(struct net *src_net, struct net_device *dev,
fd0 = nla_get_u32(data[IFLA_GTP_FD0]);
fd1 = nla_get_u32(data[IFLA_GTP_FD1]);
- err = gtp_encap_enable(dev, gtp, fd0, fd1, src_net);
+ err = gtp_encap_enable(dev, gtp, fd0, fd1);
if (err < 0)
goto out_err;
@@ -821,7 +820,7 @@ static void gtp_hashtable_free(struct gtp_dev *gtp)
}
static int gtp_encap_enable(struct net_device *dev, struct gtp_dev *gtp,
- int fd_gtp0, int fd_gtp1, struct net *src_net)
+ int fd_gtp0, int fd_gtp1)
{
struct udp_tunnel_sock_cfg tuncfg = {NULL};
struct socket *sock0, *sock1u;
@@ -858,7 +857,6 @@ static int gtp_encap_enable(struct net_device *dev, struct gtp_dev *gtp,
gtp->sock0 = sock0;
gtp->sock1u = sock1u;
- gtp->net = src_net;
tuncfg.sk_user_data = gtp;
tuncfg.encap_rcv = gtp_encap_recv;
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 9:43 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: <87tw8lnei3.fsf@codeaurora.org>
On Friday 27 January 2017 09:33:40 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?
It is part of linux-firmware repository. And already part of all
previous versions of linux-firmware packages in lot of linux
distributions. So removing it is not possible...
> Like we discussed earlier, the default nvs file should not be used by
> normal users.
But already is and we need to deal with this fact.
--
Pali Rohár
pali.rohar@gmail.com
^ 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 10:05 UTC (permalink / raw)
To: Pali Rohár, 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: <20170127094342.GC24223@pali>
On 27-1-2017 10:43, Pali Rohár wrote:
> On Friday 27 January 2017 09:33:40 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?
>
> It is part of linux-firmware repository. And already part of all
> previous versions of linux-firmware packages in lot of linux
> distributions. So removing it is not possible...
You are probably saying that on your platform you can not remove
anything from /lib/firmware, right? I don't see how you come from "it is
part of firmware package" to "removing is not possible". Trying to
understand this and it makes no sense.
>> Like we discussed earlier, the default nvs file should not be used by
>> normal users.
>
> But already is and we need to deal with this fact.
Why? Are there other platforms that use the default nvs file and have a
working wifi. So your "removing is not possible" would be about
regression for those?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 0/6 v3] kvmalloc
From: Michal Hocko @ 2017-01-27 10:05 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Andrew Morton, Vlastimil Babka, Mel Gorman,
Johannes Weiner, linux-mm, LKML, netdev@vger.kernel.org,
marcelo.leitner
In-Reply-To: <588A5D3C.4060605@iogearbox.net>
On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
> On 01/26/2017 02:40 PM, Michal Hocko wrote:
[...]
> > But realistically, how big is this problem really? Is it really worth
> > it? You said this is an admin only interface and admin can kill the
> > machine by OOM and other means already.
> >
> > Moreover and I should probably mention it explicitly, your d407bd25a204b
> > reduced the likelyhood of oom for other reason. kmalloc used GPF_USER
> > previously and with order > 0 && order <= PAGE_ALLOC_COSTLY_ORDER this
> > could indeed hit the OOM e.g. due to memory fragmentation. It would be
> > much harder to hit the OOM killer from vmalloc which doesn't issue
> > higher order allocation requests. Or have you ever seen the OOM killer
> > pointing to the vmalloc fallback path?
>
> The case I was concerned about was from vmalloc() path, not kmalloc().
> That was where the stack trace indicating OOM pointed to. As an example,
> there could be really large allocation requests for maps where the map
> has pre-allocated memory for its elements. Thus, if we get to the point
> where we need to kill others due to shortage of mem for satisfying this,
> I'd much much rather prefer to just not let vmalloc() work really hard
> and fail early on instead.
I see, but as already mentioned, chances are that by the time you get
close to the OOM somebody else will hit the OOM before the vmalloc path
manages to free the allocated memory.
> In my (crafted) test case, I was connected
> via ssh and it each time reliably killed my connection, which is really
> suboptimal.
>
> F.e., I could also imagine a buggy or miscalculated map definition for
> a prog that is provisioned to multiple places, which then accidentally
> triggers this. Or if large on purpose, but we crossed the line, it
> could be handled more gracefully, f.e. I could imagine an option to
> falling back to a non-pre-allocated map flavor from the application
> loading the program. Trade-off for sure, but still allowing it to
> operate up to a certain extend. Granted, if vmalloc() succeeded without
> trying hard and we then OOM elsewhere, too bad, but we don't have much
> control over that one anyway, only about our own request. Reason I
> asked above was whether having __GFP_NORETRY in would be fatal
> somewhere down the path, but seems not as you say.
>
> So to answer your second email with the bpf and netfilter hunks, why
> not replacing them with kvmalloc() and __GFP_NORETRY flag and add that
> big fat FIXME comment above there, saying explicitly that __GFP_NORETRY
> is not harmful though has only /partial/ effect right now and that full
> support needs to be implemented in future. That would still be better
> that not having it, imo, and the FIXME would make expectations clear
> to anyone reading that code.
Well, we can do that, I just would like to prevent from this (ab)use
if there is no _real_ and _sensible_ usecase for it. Having a real bug
report or a fallback mechanism you are mentioning above would justify
the (ab)use IMHO. But that abuse would be documented properly and have a
real reason to exist. That sounds like a better approach to me.
But if you absolutely _insist_ I can change that.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 10:10 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, 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: <def4c357-64c0-0681-a5d5-f49a6cb84a92@broadcom.com>
On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
> On 27-1-2017 10:43, Pali Rohár wrote:
> > On Friday 27 January 2017 09:33:40 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?
> >
> > It is part of linux-firmware repository. And already part of all
> > previous versions of linux-firmware packages in lot of linux
> > distributions. So removing it is not possible...
>
> You are probably saying that on your platform you can not remove
> anything from /lib/firmware, right? I don't see how you come from "it is
> part of firmware package" to "removing is not possible". Trying to
> understand this and it makes no sense.
It is already in linux distribution packages. If I remove that file from
file system it will be placed there again by package management or it it
will throw error message about system integrity (missing file, etc...).
Also that file is already in linux-firmware git and so is propagated to
/lib/firmware by anybody who is using linux-firmware.
> >> Like we discussed earlier, the default nvs file should not be used by
> >> normal users.
> >
> > But already is and we need to deal with this fact.
>
> Why?
Because everybody has already installed it.
> Are there other platforms that use the default nvs file and have a
> working wifi.
I do not know.
> So your "removing is not possible" would be about
> regression for those?
Yes, that is possible.
Also you can use wifi on Nokia N900 with this default file. Yes it is
not recommended and probably has performance problems... but more people
use it for SSH and it is working. Pavel could confirm this.
So yes, if you remove that file *now* there is regression for Nokia N900
when you are using SSH over wifi.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
From: Nicolas Ferre @ 2017-01-27 10:12 UTC (permalink / raw)
To: Harini Katakam, Rafal Ozieblo
Cc: tbultel@pixelsurmer.com, boris.brezillon@free-electrons.com,
netdev@vger.kernel.org, alexandre.belloni@free-electrons.com,
linux-kernel@vger.kernel.org, richardcochran@gmail.com,
Andrei Pistirica, michals@xilinx.com, anirudh@xilinx.com,
punnaia@xilinx.com, harini.katakam@xilinx.com,
davem@davemloft.net, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAFcVECLuWM65zXJWtMcwijZ1ZbtH0pvKnTUR=SJagPGHEr9amg@mail.gmail.com>
Le 27/01/2017 à 06:42, Harini Katakam a écrit :
> Hi Rafal,
>
> On Thu, Jan 26, 2017 at 8:45 PM, Rafal Ozieblo <rafalo@cadence.com> wrote:
>>> -----Original Message-----
>>> From: Andrei Pistirica [mailto:andrei.pistirica@microchip.com]
>>> Sent: 19 stycznia 2017 16:56
>>> Subject: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
>>>
>>>
>>> +static inline bool gem_has_ptp(struct macb *bp)
>>> +{
>>> + return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP);
>>> +}
>> Why don't you use hardware capabilities here? Would it be better to read it from hardware instead adding it to many configuration?
>
> If you are referring to TSU bit in DCFG5, then we will be relying on
> Cadence IP's information irrespective of the SoC capability
> and whether the PTP support was adequate.
> I think the capability approach gives better control and
> it is not really much to add.
Yes, absolutely. In fact we already had this discussion and decided that
this capability scheme was giving much more control at low cost.
Regards,
--
Nicolas Ferre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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 10:19 UTC (permalink / raw)
To: Pali Rohár
Cc: Kalle Valo, 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: <20170127101043.GD24223@pali>
On 27-1-2017 11:10, Pali Rohár wrote:
> On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
>> On 27-1-2017 10:43, Pali Rohár wrote:
>>> On Friday 27 January 2017 09:33:40 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?
>>>
>>> It is part of linux-firmware repository. And already part of all
>>> previous versions of linux-firmware packages in lot of linux
>>> distributions. So removing it is not possible...
>>
>> You are probably saying that on your platform you can not remove
>> anything from /lib/firmware, right? I don't see how you come from "it is
>> part of firmware package" to "removing is not possible". Trying to
>> understand this and it makes no sense.
>
> It is already in linux distribution packages. If I remove that file from
> file system it will be placed there again by package management or it it
> will throw error message about system integrity (missing file, etc...).
>
> Also that file is already in linux-firmware git and so is propagated to
> /lib/firmware by anybody who is using linux-firmware.
>
>>>> Like we discussed earlier, the default nvs file should not be used by
>>>> normal users.
>>>
>>> But already is and we need to deal with this fact.
>>
>> Why?
>
> Because everybody has already installed it.
>
>> Are there other platforms that use the default nvs file and have a
>> working wifi.
>
> I do not know.
>
>> So your "removing is not possible" would be about
>> regression for those?
>
> Yes, that is possible.
>
> Also you can use wifi on Nokia N900 with this default file. Yes it is
> not recommended and probably has performance problems... but more people
> use it for SSH and it is working. Pavel could confirm this.
>
> So yes, if you remove that file *now* there is regression for Nokia N900
> when you are using SSH over wifi.
So you are changing the behavior for all platforms using wl1251, but the
user-helper preference is (probably) only applicable for N900, right? So
for those other platforms there will be a delay waiting for user-mode
helper to fail, before trying to get nvs file from /lib/firmware.
Regards,
Arend
^ permalink raw reply
* Re: stmmac: GMAC_RGSMIIIS reports bogus values
From: Alexey Brodkin @ 2017-01-27 10:23 UTC (permalink / raw)
To: peppe.cavallaro@st.com
Cc: fabrice.gasnier@st.com, netdev@vger.kernel.org,
manabian@gmail.com, linux-kernel@vger.kernel.org,
preid@electromag.com.au, davem@davemloft.net,
alexandre.torgue@gmail.com, linux-snps-arc@lists.infradead.org,
Vineet Gupta
In-Reply-To: <1485369563.7117.81.camel@synopsys.com>
Hi Giuseppe,
On Wed, 2017-01-25 at 21:39 +0300, Alexey Brodkin wrote:
> Hi Giuseppe,
>
> On Mon, 2016-11-14 at 09:14 +0100, Giuseppe CAVALLARO wrote:
> >
> > Hello Alexey
> >
> > Sorry for my late reply. In that case, I think that the stmmac
> > is using own RGMII/SGMII support (PCS) to dialog with the
> > transceiver. I think, from the HW capability register
> > this feature is present and the driver is using it as default.
>
> Yep looks like that.
Hm, so I took a look at what am I reading from
"Register 22 (HW Feature Register)" in dwmac1000_get_hw_feature()
and was really surprised to see the register value = 0x100509bf.
See bit 6 "PCSSEL" is zeroed which stands for
"PCS registers (TBI, SGMII, or RTBI PHY interface)".
I.e. PCS doesn't exist in our GMAC so most of the previous comments
below should be discarded.
> > I kindly ask you to verify if this is your setup or if you
> > do not want to use it. In that case, it is likely we need to
> > add some code in the driver.
>
> Well GMAC's databook says:
> --------------------------->8--------------------------
> The DWC_gmac provides an IEEE 802.3z compliant 10-bit
> Physical Coding Sublayer (PCS) interface that you can use
> when the MAC is configured for the TBI, RTBI, or SGMII PHY
> interface.
>
> ...
>
> You can include the optional PCS module in the DWC_gmac by
> selecting the TBI, RTBI, or SGMII interface in coreConsultant
> during configuration.
> --------------------------->8--------------------------
>
> But we use RGMII for communication with the PHY.
> And from the quote above I would conclude that for RGMII we should
> have PCS excluded from GMAC.
>
> I just sent email to GMAC developers here in Synopsys and
> hopefully will get some clarifications from them soon.
>
> Probably correct solution is as simple as:
> --------------------------->8--------------------------
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index a276a32d57f2..f4b67dc7d530 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -803,13 +803,7 @@ static void stmmac_check_pcs_mode(struct stmmac_priv *priv)
> int interface = priv->plat->interface;
>
> if (priv->dma_cap.pcs) {
> - if ((interface == PHY_INTERFACE_MODE_RGMII) ||
> - (interface == PHY_INTERFACE_MODE_RGMII_ID) ||
> - (interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
> - (interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
> - netdev_dbg(priv->dev, "PCS RGMII support enabled\n");
> - priv->hw->pcs = STMMAC_PCS_RGMII;
> - } else if (interface == PHY_INTERFACE_MODE_SGMII) {
> + if (interface == PHY_INTERFACE_MODE_SGMII) {
> netdev_dbg(priv->dev, "PCS SGMII support enabled\n");
> priv->hw->pcs = STMMAC_PCS_SGMII;
> }
> --------------------------->8--------------------------
>
> >
> > Also I wonder if, other version of the stmmac worked on this platform
> > before.
>
> It did work and still works. The only problem is we're getting
> a lot of noise now about bogus link status change. That's because
> this info is now in pr_info() compared to being previously in pr_debug().
So it all really boils down to the following problem:
Link state reported via "Register 54 (SGMII/RGMII/SMII Control and Status Register)"
doesn't match status read via MDIO from the PHY.
That's why my initial proposal was to ignore whatever we read from this register
if we have MDIO bus instantiated already.
-Alexey
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply
* RE: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
From: Rafal Ozieblo @ 2017-01-27 10:26 UTC (permalink / raw)
To: Harini Katakam
Cc: tbultel@pixelsurmer.com, boris.brezillon@free-electrons.com,
netdev@vger.kernel.org, alexandre.belloni@free-electrons.com,
nicolas.ferre@atmel.com, linux-kernel@vger.kernel.org,
richardcochran@gmail.com, Andrei Pistirica, michals@xilinx.com,
anirudh@xilinx.com, punnaia@xilinx.com, harini.katakam@xilinx.com,
davem@davemloft.net, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAFcVECLuWM65zXJWtMcwijZ1ZbtH0pvKnTUR=SJagPGHEr9amg@mail.gmail.com>
>-----Original Message-----
>From: Harini Katakam [mailto:harinikatakamlinux@gmail.com]
>Sent: 27 stycznia 2017 06:43
>Subject: Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
>
>Hi Rafal,
>
>On Thu, Jan 26, 2017 at 8:45 PM, Rafal Ozieblo <rafalo@cadence.com> wrote:
>>> -----Original Message-----
>>> From: Andrei Pistirica [mailto:andrei.pistirica@microchip.com]
>>> Sent: 19 stycznia 2017 16:56
>>> Subject: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
>>>
>>>
>>> +static inline bool gem_has_ptp(struct macb *bp)
>>> +{
>>> + return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP);
>>> +}
>> Why don't you use hardware capabilities here? Would it be better to read it from hardware instead adding it to many configuration?
>
>If you are referring to TSU bit in DCFG5, then we will be relying on
>Cadence IP's information irrespective of the SoC capability
>and whether the PTP support was adequate.
>I think the capability approach gives better control and
>it is not really much to add.
>
>Regards,
>Harini
>
Yes, I'm referring to TSU bit.
What if SoC contains multiple Cadence GEMs, some with PTP support and others without?
Relevant will be checking both, hardware capabilities and SoC capabilities from "caps" field.
^ permalink raw reply
* Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
From: Nicolas Ferre @ 2017-01-27 10:27 UTC (permalink / raw)
To: Rafal Ozieblo, Harini Katakam
Cc: Andrei Pistirica, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, davem@davemloft.net,
harini.katakam@xilinx.com, punnaia@xilinx.com, michals@xilinx.com,
anirudh@xilinx.com, boris.brezillon@free-electrons.com,
alexandre.belloni@free-electrons.com, tbultel@pixelsurmer.com,
richardcochran@gmail.com
In-Reply-To: <BN3PR07MB25163747E1520E4CE1C6164FC9760@BN3PR07MB2516.namprd07.prod.outlook.com>
Le 27/01/2017 à 11:26, Rafal Ozieblo a écrit :
>> -----Original Message-----
>> From: Harini Katakam [mailto:harinikatakamlinux@gmail.com]
>> Sent: 27 stycznia 2017 06:43
>> Subject: Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
>>
>> Hi Rafal,
>>
>> On Thu, Jan 26, 2017 at 8:45 PM, Rafal Ozieblo <rafalo@cadence.com> wrote:
>>>> -----Original Message-----
>>>> From: Andrei Pistirica [mailto:andrei.pistirica@microchip.com]
>>>> Sent: 19 stycznia 2017 16:56
>>>> Subject: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
>>>>
>>>>
>>>> +static inline bool gem_has_ptp(struct macb *bp)
>>>> +{
>>>> + return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP);
>>>> +}
>>> Why don't you use hardware capabilities here? Would it be better to read it from hardware instead adding it to many configuration?
>>
>> If you are referring to TSU bit in DCFG5, then we will be relying on
>> Cadence IP's information irrespective of the SoC capability
>> and whether the PTP support was adequate.
>> I think the capability approach gives better control and
>> it is not really much to add.
>>
>> Regards,
>> Harini
>>
> Yes, I'm referring to TSU bit.
> What if SoC contains multiple Cadence GEMs, some with PTP support and others without?
Simply define different DT compatibility strings and we're good.
> Relevant will be checking both, hardware capabilities and SoC capabilities from "caps" field.
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 10:34 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, 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: <f60cf2c0-bc1e-3a5f-991c-dc6c95a656af@broadcom.com>
On Friday 27 January 2017 11:19:25 Arend Van Spriel wrote:
> On 27-1-2017 11:10, Pali Rohár wrote:
> > On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
> >> On 27-1-2017 10:43, Pali Rohár wrote:
> >>> On Friday 27 January 2017 09:33:40 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?
> >>>
> >>> It is part of linux-firmware repository. And already part of all
> >>> previous versions of linux-firmware packages in lot of linux
> >>> distributions. So removing it is not possible...
> >>
> >> You are probably saying that on your platform you can not remove
> >> anything from /lib/firmware, right? I don't see how you come from "it is
> >> part of firmware package" to "removing is not possible". Trying to
> >> understand this and it makes no sense.
> >
> > It is already in linux distribution packages. If I remove that file from
> > file system it will be placed there again by package management or it it
> > will throw error message about system integrity (missing file, etc...).
> >
> > Also that file is already in linux-firmware git and so is propagated to
> > /lib/firmware by anybody who is using linux-firmware.
> >
> >>>> Like we discussed earlier, the default nvs file should not be used by
> >>>> normal users.
> >>>
> >>> But already is and we need to deal with this fact.
> >>
> >> Why?
> >
> > Because everybody has already installed it.
> >
> >> Are there other platforms that use the default nvs file and have a
> >> working wifi.
> >
> > I do not know.
> >
> >> So your "removing is not possible" would be about
> >> regression for those?
> >
> > Yes, that is possible.
> >
> > Also you can use wifi on Nokia N900 with this default file. Yes it is
> > not recommended and probably has performance problems... but more people
> > use it for SSH and it is working. Pavel could confirm this.
> >
> > So yes, if you remove that file *now* there is regression for Nokia N900
> > when you are using SSH over wifi.
>
> So you are changing the behavior for all platforms using wl1251, but the
> user-helper preference is (probably) only applicable for N900, right?
No. Some wl1251 chips have internal EEPROM where is stored MAC address
and NVS data. And kernel driver already can read it. So this change is
only for platforms without internal EEPROM.
And all platforms without internal EEPROM should use userspace helper to
provide correct NVS data (and ideally also MAC address).
Except Nokia N900 I know just Pandora who has also wl1251 chip. But
Pandora has EEPROM.
Grepping linux source code... and I see only defines for Nokia N900 and
Pandora. There can be also another user with external DTS file, but what
is reality? Is there still really any other user of wl1251 chip with
upstream kernel? If yes, we can prepare userspace helper if he does not
have NVS stored in EEPROM...
> So
> for those other platforms there will be a delay waiting for user-mode
> helper to fail, before trying to get nvs file from /lib/firmware.
Yes, there will be. But there is no easy way to fix this problem that
kernel is trying to use default/example NVS data...
When helper is not available this patch just adds delay, but
functionality is still there and same. With helper support will be
finally fixed.
And I have no idea if those default NVS data are somehow usable on other
platforms...
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* [PATCH 1/8] crypto:chcr-Change flow IDs
From: Harsh Jain @ 2017-01-27 10:39 UTC (permalink / raw)
To: herbert, linux-crypto, hariprasad, netdev, arjun, atul.gupta; +Cc: Harsh Jain
In-Reply-To: <cover.1485501428.git.harsh@chelsio.com>
Change assign flowc id to each outgoing request.Firmware use flowc id
to schedule each request onto HW. FW reply may miss without this change.
Reviewed-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
---
drivers/crypto/chelsio/chcr_algo.c | 18 ++++++++++--------
drivers/crypto/chelsio/chcr_algo.h | 9 +++++----
drivers/crypto/chelsio/chcr_core.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 8 ++++++++
4 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
index d29c2b4..deec7c0 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -542,10 +542,11 @@ static inline void create_wreq(struct chcr_context *ctx,
(calc_tx_flits_ofld(skb) * 8), 16)));
chcr_req->wreq.cookie = cpu_to_be64((uintptr_t)req);
chcr_req->wreq.rx_chid_to_rx_q_id =
- FILL_WR_RX_Q_ID(ctx->dev->tx_channel_id, qid,
- is_iv ? iv_loc : IV_NOP);
+ FILL_WR_RX_Q_ID(ctx->dev->rx_channel_id, qid,
+ is_iv ? iv_loc : IV_NOP, ctx->tx_channel_id);
- chcr_req->ulptx.cmd_dest = FILL_ULPTX_CMD_DEST(ctx->dev->tx_channel_id);
+ chcr_req->ulptx.cmd_dest = FILL_ULPTX_CMD_DEST(ctx->dev->tx_channel_id,
+ qid);
chcr_req->ulptx.len = htonl((DIV_ROUND_UP((calc_tx_flits_ofld(skb) * 8),
16) - ((sizeof(chcr_req->wreq)) >> 4)));
@@ -606,7 +607,7 @@ static inline void create_wreq(struct chcr_context *ctx,
chcr_req = (struct chcr_wr *)__skb_put(skb, transhdr_len);
memset(chcr_req, 0, transhdr_len);
chcr_req->sec_cpl.op_ivinsrtofst =
- FILL_SEC_CPL_OP_IVINSR(ctx->dev->tx_channel_id, 2, 1);
+ FILL_SEC_CPL_OP_IVINSR(ctx->dev->rx_channel_id, 2, 1);
chcr_req->sec_cpl.pldlen = htonl(ivsize + req->nbytes);
chcr_req->sec_cpl.aadstart_cipherstop_hi =
@@ -782,6 +783,7 @@ static int chcr_device_init(struct chcr_context *ctx)
spin_lock(&ctx->dev->lock_chcr_dev);
ctx->tx_channel_id = rxq_idx;
ctx->dev->tx_channel_id = !ctx->dev->tx_channel_id;
+ ctx->dev->rx_channel_id = 0;
spin_unlock(&ctx->dev->lock_chcr_dev);
}
out:
@@ -874,7 +876,7 @@ static struct sk_buff *create_hash_wr(struct ahash_request *req,
memset(chcr_req, 0, transhdr_len);
chcr_req->sec_cpl.op_ivinsrtofst =
- FILL_SEC_CPL_OP_IVINSR(ctx->dev->tx_channel_id, 2, 0);
+ FILL_SEC_CPL_OP_IVINSR(ctx->dev->rx_channel_id, 2, 0);
chcr_req->sec_cpl.pldlen = htonl(param->bfr_len + param->sg_len);
chcr_req->sec_cpl.aadstart_cipherstop_hi =
@@ -1425,7 +1427,7 @@ static struct sk_buff *create_authenc_wr(struct aead_request *req,
* to the hardware spec
*/
chcr_req->sec_cpl.op_ivinsrtofst =
- FILL_SEC_CPL_OP_IVINSR(ctx->dev->tx_channel_id, 2,
+ FILL_SEC_CPL_OP_IVINSR(ctx->dev->rx_channel_id, 2,
(ivsize ? (assoclen + 1) : 0));
chcr_req->sec_cpl.pldlen = htonl(assoclen + ivsize + req->cryptlen);
chcr_req->sec_cpl.aadstart_cipherstop_hi = FILL_SEC_CPL_CIPHERSTOP_HI(
@@ -1601,7 +1603,7 @@ static void fill_sec_cpl_for_aead(struct cpl_tx_sec_pdu *sec_cpl,
unsigned int ivsize = AES_BLOCK_SIZE;
unsigned int cipher_mode = CHCR_SCMD_CIPHER_MODE_AES_CCM;
unsigned int mac_mode = CHCR_SCMD_AUTH_MODE_CBCMAC;
- unsigned int c_id = chcrctx->dev->tx_channel_id;
+ unsigned int c_id = chcrctx->dev->rx_channel_id;
unsigned int ccm_xtra;
unsigned char tag_offset = 0, auth_offset = 0;
unsigned char hmac_ctrl = get_hmac(crypto_aead_authsize(tfm));
@@ -1877,7 +1879,7 @@ static struct sk_buff *create_gcm_wr(struct aead_request *req,
tag_offset = (op_type == CHCR_ENCRYPT_OP) ? 0 : authsize;
chcr_req->sec_cpl.op_ivinsrtofst = FILL_SEC_CPL_OP_IVINSR(
- ctx->dev->tx_channel_id, 2, (ivsize ?
+ ctx->dev->rx_channel_id, 2, (ivsize ?
(req->assoclen + 1) : 0));
chcr_req->sec_cpl.pldlen = htonl(req->assoclen + ivsize + crypt_len);
chcr_req->sec_cpl.aadstart_cipherstop_hi = FILL_SEC_CPL_CIPHERSTOP_HI(
diff --git a/drivers/crypto/chelsio/chcr_algo.h b/drivers/crypto/chelsio/chcr_algo.h
index 3c7c51f..ba38bae 100644
--- a/drivers/crypto/chelsio/chcr_algo.h
+++ b/drivers/crypto/chelsio/chcr_algo.h
@@ -185,20 +185,21 @@
FW_CRYPTO_LOOKASIDE_WR_CCTX_LOC_V(1) | \
FW_CRYPTO_LOOKASIDE_WR_CCTX_SIZE_V((ctx_len)))
-#define FILL_WR_RX_Q_ID(cid, qid, wr_iv) \
+#define FILL_WR_RX_Q_ID(cid, qid, wr_iv, fid) \
htonl( \
FW_CRYPTO_LOOKASIDE_WR_RX_CHID_V((cid)) | \
FW_CRYPTO_LOOKASIDE_WR_RX_Q_ID_V((qid)) | \
FW_CRYPTO_LOOKASIDE_WR_LCB_V(0) | \
- FW_CRYPTO_LOOKASIDE_WR_IV_V((wr_iv)))
+ FW_CRYPTO_LOOKASIDE_WR_IV_V((wr_iv)) | \
+ FW_CRYPTO_LOOKASIDE_WR_FQIDX_V(fid))
-#define FILL_ULPTX_CMD_DEST(cid) \
+#define FILL_ULPTX_CMD_DEST(cid, qid) \
htonl(ULPTX_CMD_V(ULP_TX_PKT) | \
ULP_TXPKT_DEST_V(0) | \
ULP_TXPKT_DATAMODIFY_V(0) | \
ULP_TXPKT_CHANNELID_V((cid)) | \
ULP_TXPKT_RO_V(1) | \
- ULP_TXPKT_FID_V(0))
+ ULP_TXPKT_FID_V(qid))
#define KEYCTX_ALIGN_PAD(bs) ({unsigned int _bs = (bs);\
_bs == SHA1_DIGEST_SIZE ? 12 : 0; })
diff --git a/drivers/crypto/chelsio/chcr_core.h b/drivers/crypto/chelsio/chcr_core.h
index c7088a4..79da22b 100644
--- a/drivers/crypto/chelsio/chcr_core.h
+++ b/drivers/crypto/chelsio/chcr_core.h
@@ -75,6 +75,7 @@ struct chcr_dev {
spinlock_t lock_chcr_dev;
struct uld_ctx *u_ctx;
unsigned char tx_channel_id;
+ unsigned char rx_channel_id;
};
struct uld_ctx {
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 8d9e4b7..ccc05f8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -3385,6 +3385,14 @@ struct fw_crypto_lookaside_wr {
#define FW_CRYPTO_LOOKASIDE_WR_IV_G(x) \
(((x) >> FW_CRYPTO_LOOKASIDE_WR_IV_S) & FW_CRYPTO_LOOKASIDE_WR_IV_M)
+#define FW_CRYPTO_LOOKASIDE_WR_FQIDX_S 15
+#define FW_CRYPTO_LOOKASIDE_WR_FQIDX_M 0xff
+#define FW_CRYPTO_LOOKASIDE_WR_FQIDX_V(x) \
+ ((x) << FW_CRYPTO_LOOKASIDE_WR_FQIDX_S)
+#define FW_CRYPTO_LOOKASIDE_WR_FQIDX_G(x) \
+ (((x) >> FW_CRYPTO_LOOKASIDE_WR_FQIDX_S) & \
+ FW_CRYPTO_LOOKASIDE_WR_FQIDX_M)
+
#define FW_CRYPTO_LOOKASIDE_WR_TX_CH_S 10
#define FW_CRYPTO_LOOKASIDE_WR_TX_CH_M 0x3
#define FW_CRYPTO_LOOKASIDE_WR_TX_CH_V(x) \
--
1.8.2.3
^ permalink raw reply related
* [PATCH 5/8] crypto:chcr: Change cra_flags for cipher algos
From: Harsh Jain @ 2017-01-27 10:39 UTC (permalink / raw)
To: herbert, linux-crypto, hariprasad, netdev, arjun, atul.gupta; +Cc: Harsh Jain
In-Reply-To: <cover.1485501428.git.harsh@chelsio.com>
Change cipher algos flags to CRYPTO_ALG_TYPE_ABLKCIPHER.
Signed-off-by: Harsh Jain <harsh@chelsio.com>
---
drivers/crypto/chelsio/chcr_algo.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
index d335943..21fc04c 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -171,7 +171,7 @@ int chcr_handle_resp(struct crypto_async_request *req, unsigned char *input,
}
break;
- case CRYPTO_ALG_TYPE_BLKCIPHER:
+ case CRYPTO_ALG_TYPE_ABLKCIPHER:
ctx_req.req.ablk_req = (struct ablkcipher_request *)req;
ctx_req.ctx.ablk_ctx =
ablkcipher_request_ctx(ctx_req.req.ablk_req);
@@ -2492,7 +2492,7 @@ static int chcr_aead_op(struct aead_request *req,
.cra_name = "cbc(aes)",
.cra_driver_name = "cbc-aes-chcr",
.cra_priority = CHCR_CRA_PRIORITY,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_ASYNC,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct chcr_context)
@@ -2519,7 +2519,7 @@ static int chcr_aead_op(struct aead_request *req,
.cra_name = "xts(aes)",
.cra_driver_name = "xts-aes-chcr",
.cra_priority = CHCR_CRA_PRIORITY,
- .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_ASYNC,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct chcr_context) +
--
1.8.2.3
^ permalink raw reply related
* [PATCH 7/8] crypto:chcr- Fix wrong typecasting
From: Harsh Jain @ 2017-01-27 10:39 UTC (permalink / raw)
To: herbert, linux-crypto, hariprasad, netdev, arjun, atul.gupta; +Cc: Harsh Jain
In-Reply-To: <cover.1485501428.git.harsh@chelsio.com>
Typecast the pointer with correct structure.
Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
---
drivers/crypto/chelsio/chcr_core.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_core.c b/drivers/crypto/chelsio/chcr_core.c
index 2bfd61a..c28e018 100644
--- a/drivers/crypto/chelsio/chcr_core.c
+++ b/drivers/crypto/chelsio/chcr_core.c
@@ -151,18 +151,17 @@ int chcr_uld_rx_handler(void *handle, const __be64 *rsp,
{
struct uld_ctx *u_ctx = (struct uld_ctx *)handle;
struct chcr_dev *dev = u_ctx->dev;
- const struct cpl_act_establish *rpl = (struct cpl_act_establish
- *)rsp;
+ const struct cpl_fw6_pld *rpl = (struct cpl_fw6_pld *)rsp;
- if (rpl->ot.opcode != CPL_FW6_PLD) {
+ if (rpl->opcode != CPL_FW6_PLD) {
pr_err("Unsupported opcode\n");
return 0;
}
if (!pgl)
- work_handlers[rpl->ot.opcode](dev, (unsigned char *)&rsp[1]);
+ work_handlers[rpl->opcode](dev, (unsigned char *)&rsp[1]);
else
- work_handlers[rpl->ot.opcode](dev, pgl->va);
+ work_handlers[rpl->opcode](dev, pgl->va);
return 0;
}
--
1.8.2.3
^ permalink raw reply related
* [PATCH 8/8] crypto:chcr-Fix Smatch Complaint
From: Harsh Jain @ 2017-01-27 10:39 UTC (permalink / raw)
To: herbert, linux-crypto, hariprasad, netdev, arjun, atul.gupta; +Cc: Harsh Jain
In-Reply-To: <cover.1485501428.git.harsh@chelsio.com>
Initialise variable after null check.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Harsh Jain <harsh@chelsio.com>
---
drivers/crypto/chelsio/chcr_algo.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
mode change 100644 => 100755 drivers/crypto/chelsio/chcr_algo.c
diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
old mode 100644
new mode 100755
index 21fc04c..41bc7f4
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -2456,13 +2456,14 @@ static int chcr_aead_op(struct aead_request *req,
{
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct chcr_context *ctx = crypto_aead_ctx(tfm);
- struct uld_ctx *u_ctx = ULD_CTX(ctx);
+ struct uld_ctx *u_ctx;
struct sk_buff *skb;
- if (ctx && !ctx->dev) {
+ if (!ctx->dev) {
pr_err("chcr : %s : No crypto device.\n", __func__);
return -ENXIO;
}
+ u_ctx = ULD_CTX(ctx);
if (cxgb4_is_crypto_q_full(u_ctx->lldi.ports[0],
ctx->tx_channel_id)) {
if (!(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
--
1.8.2.3
^ permalink raw reply related
* [PATCH 6/8] crypto:chcr- Change algo priority
From: Harsh Jain @ 2017-01-27 10:39 UTC (permalink / raw)
To: herbert, linux-crypto, hariprasad, netdev, arjun, atul.gupta; +Cc: Harsh Jain
In-Reply-To: <cover.1485501428.git.harsh@chelsio.com>
Update priorities to 3000
Signed-off-by: Harsh Jain <harsh@chelsio.com>
---
drivers/crypto/chelsio/chcr_crypto.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/chelsio/chcr_crypto.h b/drivers/crypto/chelsio/chcr_crypto.h
index 7ec0a8f..81cfd0b 100644
--- a/drivers/crypto/chelsio/chcr_crypto.h
+++ b/drivers/crypto/chelsio/chcr_crypto.h
@@ -48,7 +48,7 @@
* giving the processed data
*/
-#define CHCR_CRA_PRIORITY 300
+#define CHCR_CRA_PRIORITY 3000
#define CHCR_AES_MAX_KEY_LEN (2 * (AES_MAX_KEY_SIZE)) /* consider xts */
#define CHCR_MAX_CRYPTO_IV_LEN 16 /* AES IV len */
--
1.8.2.3
^ permalink raw reply related
* [PATCH 4/8] crypto:chcr- Use cipher instead of Block Cipher in gcm setkey
From: Harsh Jain @ 2017-01-27 10:39 UTC (permalink / raw)
To: herbert, linux-crypto, hariprasad, netdev, arjun, atul.gupta; +Cc: Harsh Jain
In-Reply-To: <cover.1485501428.git.harsh@chelsio.com>
1 Block of encrption can be done with aes-generic. no need of
cbc(aes). This patch replaces cbc(aes-generic) with aes-generic.
Signed-off-by: Harsh Jain <harsh@chelsio.com>
---
drivers/crypto/chelsio/chcr_algo.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
index 6c2dea3..d335943 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -2189,8 +2189,7 @@ static int chcr_gcm_setkey(struct crypto_aead *aead, const u8 *key,
struct chcr_context *ctx = crypto_aead_ctx(aead);
struct chcr_aead_ctx *aeadctx = AEAD_CTX(ctx);
struct chcr_gcm_ctx *gctx = GCM_CTX(aeadctx);
- struct blkcipher_desc h_desc;
- struct scatterlist src[1];
+ struct crypto_cipher *cipher;
unsigned int ck_size;
int ret = 0, key_ctx_size = 0;
@@ -2223,27 +2222,26 @@ static int chcr_gcm_setkey(struct crypto_aead *aead, const u8 *key,
CHCR_KEYCTX_MAC_KEY_SIZE_128,
0, 0,
key_ctx_size >> 4);
- /* Calculate the H = CIPH(K, 0 repeated 16 times) using sync aes
- * blkcipher It will go on key context
+ /* Calculate the H = CIPH(K, 0 repeated 16 times).
+ * It will go in key context
*/
- h_desc.tfm = crypto_alloc_blkcipher("cbc(aes-generic)", 0, 0);
- if (IS_ERR(h_desc.tfm)) {
+ cipher = crypto_alloc_cipher("aes-generic", 0, 0);
+ if (IS_ERR(cipher)) {
aeadctx->enckey_len = 0;
ret = -ENOMEM;
goto out;
}
- h_desc.flags = 0;
- ret = crypto_blkcipher_setkey(h_desc.tfm, key, keylen);
+
+ ret = crypto_cipher_setkey(cipher, key, keylen);
if (ret) {
aeadctx->enckey_len = 0;
goto out1;
}
memset(gctx->ghash_h, 0, AEAD_H_SIZE);
- sg_init_one(&src[0], gctx->ghash_h, AEAD_H_SIZE);
- ret = crypto_blkcipher_encrypt(&h_desc, &src[0], &src[0], AEAD_H_SIZE);
+ crypto_cipher_encrypt_one(cipher, gctx->ghash_h, gctx->ghash_h);
out1:
- crypto_free_blkcipher(h_desc.tfm);
+ crypto_free_cipher(cipher);
out:
return ret;
}
--
1.8.2.3
^ permalink raw reply related
* [PATCH 0/8] Bug fixes
From: Harsh Jain @ 2017-01-27 10:39 UTC (permalink / raw)
To: herbert, linux-crypto, hariprasad, netdev, arjun, atul.gupta; +Cc: Harsh Jain
This patch series is based on Herbert's cryptodev-2.6 tree and depends on
patch series "Bug Fixes for 4.10". It includes Bug Fixes.
Atul Gupta (2)
crypto:chcr-Change flow IDs
crypto:chcr- Fix wrong typecasting
Harsh Jain (8):
crypto:chcr- Fix key length for RFC4106
crypto:chcr-fix itnull.cocci warnings
crypto:chcr- Use cipher instead of Block Cipher in gcm setkey
crypto:chcr: Change cra_flags for cipher algos
crypto:chcr- Change algo priority
crypto:chcr-Fix Smatch Complaint
drivers/crypto/chelsio/chcr_algo.c | 53 ++++++++++++++-------------
drivers/crypto/chelsio/chcr_algo.h | 9 +++--
drivers/crypto/chelsio/chcr_core.c | 11 +++---
drivers/crypto/chelsio/chcr_core.h | 1 +
drivers/crypto/chelsio/chcr_crypto.h | 2 +-
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 8 ++++
6 files changed, 47 insertions(+), 37 deletions(-)
mode change 100644 => 100755 drivers/crypto/chelsio/chcr_algo.c
--
1.8.2.3
^ permalink raw reply
* [PATCH 2/8] crypto:chcr- Fix key length for RFC4106
From: Harsh Jain @ 2017-01-27 10:39 UTC (permalink / raw)
To: herbert, linux-crypto, hariprasad, netdev, arjun, atul.gupta; +Cc: Harsh Jain
In-Reply-To: <cover.1485501428.git.harsh@chelsio.com>
Check keylen before copying salt to avoid wrap around of Integer.
Signed-off-by: Harsh Jain <harsh@chelsio.com>
---
drivers/crypto/chelsio/chcr_algo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
index deec7c0..6c2dea3 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -2194,8 +2194,8 @@ static int chcr_gcm_setkey(struct crypto_aead *aead, const u8 *key,
unsigned int ck_size;
int ret = 0, key_ctx_size = 0;
- if (get_aead_subtype(aead) ==
- CRYPTO_ALG_SUB_TYPE_AEAD_RFC4106) {
+ if (get_aead_subtype(aead) == CRYPTO_ALG_SUB_TYPE_AEAD_RFC4106 &&
+ keylen > 3) {
keylen -= 4; /* nonce/salt is present in the last 4 bytes */
memcpy(aeadctx->salt, key + keylen, 4);
}
--
1.8.2.3
^ permalink raw reply related
* [PATCH 3/8] crypto:chcr-fix itnull.cocci warnings
From: Harsh Jain @ 2017-01-27 10:39 UTC (permalink / raw)
To: herbert, linux-crypto, hariprasad, netdev, arjun, atul.gupta
Cc: Harsh Jain, Julia Lawall, Fengguang Wu
In-Reply-To: <cover.1485501428.git.harsh@chelsio.com>
The first argument to list_for_each_entry cannot be NULL.
Generated by: scripts/coccinelle/iterators/itnull.cocci
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Harsh Jain <harsh@chelsio.com>
---
drivers/crypto/chelsio/chcr_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/chelsio/chcr_core.c b/drivers/crypto/chelsio/chcr_core.c
index 1c65f07..2bfd61a 100644
--- a/drivers/crypto/chelsio/chcr_core.c
+++ b/drivers/crypto/chelsio/chcr_core.c
@@ -61,7 +61,7 @@ int assign_chcr_device(struct chcr_dev **dev)
*/
mutex_lock(&dev_mutex); /* TODO ? */
list_for_each_entry(u_ctx, &uld_ctx_list, entry)
- if (u_ctx && u_ctx->dev) {
+ if (u_ctx->dev) {
*dev = u_ctx->dev;
ret = 0;
break;
--
1.8.2.3
^ permalink raw reply related
* [PATCH] net: phy: broadcom: add support for BCM54210E
From: Rafał Miłecki @ 2017-01-27 10:47 UTC (permalink / raw)
To: David S . Miller, Florian Fainelli
Cc: Xo Wang, Joel Stanley, Jon Mason, Jaedon Shin, netdev,
Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
It's Broadcom PHY simply described as single-port
RGMII 10/100/1000BASE-T PHY. It requires disabling delay skew and GTXCLK
bits.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/phy/broadcom.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 97d1c057c0a1..794b9ec81ba5 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -30,6 +30,22 @@ MODULE_DESCRIPTION("Broadcom PHY driver");
MODULE_AUTHOR("Maciej W. Rozycki");
MODULE_LICENSE("GPL");
+static int bcm54210e_config_init(struct phy_device *phydev)
+{
+ int val;
+
+ val = bcm54xx_auxctl_read(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC);
+ val &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
+ val |= MII_BCM54XX_AUXCTL_MISC_WREN;
+ bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC, val);
+
+ val = bcm_phy_read_shadow(phydev, BCM54810_SHD_CLK_CTL);
+ val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
+ bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, val);
+
+ return 0;
+}
+
static int bcm54810_config(struct phy_device *phydev)
{
int rc, val;
@@ -230,7 +246,11 @@ static int bcm54xx_config_init(struct phy_device *phydev)
(phydev->dev_flags & PHY_BRCM_AUTO_PWRDWN_ENABLE))
bcm54xx_adjust_rxrefclk(phydev);
- if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
+ if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E) {
+ err = bcm54210e_config_init(phydev);
+ if (err)
+ return err;
+ } else if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
err = bcm54810_config(phydev);
if (err)
return err;
@@ -542,6 +562,17 @@ static struct phy_driver broadcom_drivers[] = {
.ack_interrupt = bcm_phy_ack_intr,
.config_intr = bcm_phy_config_intr,
}, {
+ .phy_id = PHY_ID_BCM54210E,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM54210E",
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = bcm54xx_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = bcm_phy_ack_intr,
+ .config_intr = bcm_phy_config_intr,
+}, {
.phy_id = PHY_ID_BCM5461,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5461",
@@ -680,6 +711,7 @@ module_phy_driver(broadcom_drivers);
static struct mdio_device_id __maybe_unused broadcom_tbl[] = {
{ PHY_ID_BCM5411, 0xfffffff0 },
{ PHY_ID_BCM5421, 0xfffffff0 },
+ { PHY_ID_BCM54210E, 0xfffffff0 },
{ PHY_ID_BCM5461, 0xfffffff0 },
{ PHY_ID_BCM54612E, 0xfffffff0 },
{ PHY_ID_BCM54616S, 0xfffffff0 },
--
2.11.0
^ permalink raw reply related
* RE: [PATCH net-next] net: adjust skb->truesize in pskb_expand_head()
From: David Laight @ 2017-01-27 10:49 UTC (permalink / raw)
To: 'Eric Dumazet', David Miller; +Cc: netdev, Slava Shwartsman
In-Reply-To: <1485476480.5145.194.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet
> Sent: 27 January 2017 00:21
> Slava Shwartsman reported a warning in skb_try_coalesce(), when we
> detect skb->truesize is completely wrong.
>
> In his case, issue came from IPv6 reassembly coping with malicious
> datagrams, that forced various pskb_may_pull() to reallocate a bigger
> skb->head than the one allocated by NIC driver before entering GRO
> layer.
>
> Current code does not change skb->truesize, leaving this burden to
> callers if they care enough.
>
> Blindly changing skb->truesize in pskb_expand_head() is not
> easy, as some producers might track skb->truesize, for example
> in xmit path for back pressure feedback (sk->sk_wmem_alloc)
>
> We can detect the cases where it should be safe to change
> skb->truesize :
>
> 1) skb is not attached to a socket.
> 2) If it is attached to a socket, destructor is sock_edemux()
...
> int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
> gfp_t gfp_mask)
> {
> + int i, osize = skb_end_offset(skb);
> + int size = osize + nhead + ntail;
> long off;
> + u8 *data;
>
> BUG_ON(nhead < 0);
>
> @@ -1257,6 +1257,14 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
> skb->hdr_len = 0;
> skb->nohdr = 0;
> atomic_set(&skb_shinfo(skb)->dataref, 1);
> +
> + /* It is not generally safe to change skb->truesize.
> + * For the moment, we really care of rx path, or
> + * when skb is orphaned (not attached to a socket)
> + */
> + if (!skb->sk || skb->destructor == sock_edemux)
> + skb->truesize += size - osize;
That calculation doesn't look right to me at all.
Isn't 'truesize' supposed to reflect the amount of memory allocated to the skb.
So you need the difference between the size of the new and old memory blocks.
I'm also guessing that extra headroom can be generated by stealing unused tailroom.
David
^ 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