* Re: Fwd: DA850-evm MAC Address is random
From: Sekhar Nori @ 2017-08-29 11:42 UTC (permalink / raw)
To: Adam Ford; +Cc: Tony Lindgren, Grygorii Strashko, linux-omap, netdev
In-Reply-To: <CAHCN7x+-wymsqw96mt7Du=Huxh5rq=Rj9GidWPLXptJSW7taEA@mail.gmail.com>
On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>> * Adam Ford <aford173@gmail.com> [170828 13:33]:
>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>> <grygorii.strashko@ti.com> wrote:
>>>>> Cc: Sekhar
>>>>>
>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>
>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>
>>>>>> The function appears to lookup varions boards using
>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>> am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
>>>>>> what's shown in the da850 device tree.
>>>>>>
>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>
>>>>>
>>>>> Not sure if MAC address can be read from Control module.
>>>>> May be Sekhar can say more?
>>>>
>>>> My understanding is that the MAC address is programmed by Logic PD
>>>> into the SPI flash. The Bootloader reads this from either SPI or its
>>>> env variables. Looking at the partition info listed in the
>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>> Unfortunately, I don't see any code that reads it out. I was hoping
>>
>> This code is present in U-Boot sources at
>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>> its usage in misc_init_r().
>>
>>>> there might be a way to just pass cmdline parameter from the
>>>> bootloader to the kernel to accept the MAC address.
>>>>
>>>>>
>>>>>>
>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>> driver so it doesn't generate a random MAC?
>>>>>
>>>>>
>>>>> "local-mac-address" dt porp
>>>>
>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>> device tree.
>>>
>>> That piece of code exists somewhere in u-boot already. Note how
>>
>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>
>>> we are populating the mac address for USB Ethernet drivers in
>>> u-boot and then the Ethernet driver code parses it. See commit
>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>> the device tree") for some more information.
>>>
>>> I think u-boot needs the ethernet alias for finding the interface.
>>
>> That's exactly what was missing. I have sent a patch for fixing that and
>> copied you there.
>
> Thanks for doing that.
>
>>
>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>> v4.13 itself.
>
> I will test it. Do need to run some instruction or do something
> special in U-Boot to pass this in the proper place for the kernel to
> pull it? Tony's patch reference showed
> command for fdt set, but I am not sure I fully understand the
> parameters that went along with that.
Nope, just applying the patch and booting the with the new dtb should
result in the random mac address going away.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] staging: r8822be: Fix typo for CONFIG_RTLWIFI_DEBUG
From: Andreas Ziegler @ 2017-08-29 11:30 UTC (permalink / raw)
To: Greg KH
Cc: devel, Yan-Hsuan Chuang, Birming Chiu, netdev, Andreas Ziegler,
Steven Ting, Larry Finger
In-Reply-To: <20170829112643.GA14571@kroah.com>
The debugging output in deinit_priv is guarded by an #ifdef using
CONFIG_RTL_DEBUG. This symbol does not exist and should be
CONFIG_RTLWIFI_DEBUG instead.
Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
---
drivers/staging/rtlwifi/halmac/rtl_halmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
index 031bf2c..888ca43 100644
--- a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
+++ b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
@@ -386,7 +386,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
u32 count, size;
count = HALMAC_FEATURE_ALL + 1;
-#ifdef CONFIG_RTL_DEBUG
+#ifdef CONFIG_RTLWIFI_DEBUG
{
struct submit_ctx *sctx;
u32 i;
@@ -405,7 +405,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
rtl_mfree((u8 *)sctx, sizeof(*sctx));
}
}
-#endif /* !CONFIG_RTL_DEBUG */
+#endif /* !CONFIG_RTLWIFI_DEBUG */
size = sizeof(*indicator) * count;
kfree((u8 *)indicator);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/2] addrlabel: add/delete/get can run without rtnl
From: Florian Westphal @ 2017-08-29 11:29 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170829112942.4791-1-fw@strlen.de>
There appears to be no need to use rtnl, addrlabel entries are refcounted
and add/delete is serialized by the addrlabel table spinlock.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/ipv6/addrlabel.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/addrlabel.c b/net/ipv6/addrlabel.c
index cea5eb488013..b055bc79f56d 100644
--- a/net/ipv6/addrlabel.c
+++ b/net/ipv6/addrlabel.c
@@ -405,6 +405,18 @@ static const struct nla_policy ifal_policy[IFAL_MAX+1] = {
[IFAL_LABEL] = { .len = sizeof(u32), },
};
+static bool addrlbl_ifindex_exists(struct net *net, int ifindex)
+{
+
+ struct net_device *dev;
+
+ rcu_read_lock();
+ dev = dev_get_by_index_rcu(net, ifindex);
+ rcu_read_unlock();
+
+ return dev != NULL;
+}
+
static int ip6addrlbl_newdel(struct sk_buff *skb, struct nlmsghdr *nlh,
struct netlink_ext_ack *extack)
{
@@ -439,7 +451,7 @@ static int ip6addrlbl_newdel(struct sk_buff *skb, struct nlmsghdr *nlh,
switch (nlh->nlmsg_type) {
case RTM_NEWADDRLABEL:
if (ifal->ifal_index &&
- !__dev_get_by_index(net, ifal->ifal_index))
+ !addrlbl_ifindex_exists(net, ifal->ifal_index))
return -EINVAL;
err = ip6addrlbl_add(net, pfx, ifal->ifal_prefixlen,
@@ -548,7 +560,7 @@ static int ip6addrlbl_get(struct sk_buff *in_skb, struct nlmsghdr *nlh,
return -EINVAL;
if (ifal->ifal_index &&
- !__dev_get_by_index(net, ifal->ifal_index))
+ !addrlbl_ifindex_exists(net, ifal->ifal_index))
return -EINVAL;
if (!tb[IFAL_ADDRESS])
@@ -593,10 +605,10 @@ static int ip6addrlbl_get(struct sk_buff *in_skb, struct nlmsghdr *nlh,
void __init ipv6_addr_label_rtnl_register(void)
{
__rtnl_register(PF_INET6, RTM_NEWADDRLABEL, ip6addrlbl_newdel,
- NULL, 0);
+ NULL, RTNL_FLAG_DOIT_UNLOCKED);
__rtnl_register(PF_INET6, RTM_DELADDRLABEL, ip6addrlbl_newdel,
- NULL, 0);
+ NULL, RTNL_FLAG_DOIT_UNLOCKED);
__rtnl_register(PF_INET6, RTM_GETADDRLABEL, ip6addrlbl_get,
- ip6addrlbl_dump, 0);
+ ip6addrlbl_dump, RTNL_FLAG_DOIT_UNLOCKED);
}
--
2.13.0
^ permalink raw reply related
* [PATCH net-next 1/2] selftests: add addrlabel add/delete to rtnetlink.sh
From: Florian Westphal @ 2017-08-29 11:29 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170829112942.4791-1-fw@strlen.de>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
tools/testing/selftests/net/rtnetlink.sh | 41 ++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/tools/testing/selftests/net/rtnetlink.sh b/tools/testing/selftests/net/rtnetlink.sh
index 84b4acf5baa9..57b5ff576240 100755
--- a/tools/testing/selftests/net/rtnetlink.sh
+++ b/tools/testing/selftests/net/rtnetlink.sh
@@ -195,6 +195,46 @@ kci_test_route_get()
echo "PASS: route get"
}
+kci_test_addrlabel()
+{
+ ret=0
+
+ ip addrlabel add prefix dead::/64 dev lo label 1
+ check_err $?
+
+ ip addrlabel list |grep -q "prefix dead::/64 dev lo label 1"
+ check_err $?
+
+ ip addrlabel del prefix dead::/64 dev lo label 1 2> /dev/null
+ check_err $?
+
+ ip addrlabel add prefix dead::/64 label 1 2> /dev/null
+ check_err $?
+
+ ip addrlabel del prefix dead::/64 label 1 2> /dev/null
+ check_err $?
+
+ # concurrent add/delete
+ for i in $(seq 1 1000); do
+ ip addrlabel add prefix 1c3::/64 label 12345 2>/dev/null
+ done &
+
+ for i in $(seq 1 1000); do
+ ip addrlabel del prefix 1c3::/64 label 12345 2>/dev/null
+ done
+
+ wait
+
+ ip addrlabel del prefix 1c3::/64 label 12345 2>/dev/null
+
+ if [ $ret -ne 0 ];then
+ echo "FAIL: ipv6 addrlabel"
+ return 1
+ fi
+
+ echo "PASS: ipv6 addrlabel"
+}
+
kci_test_rtnl()
{
kci_add_dummy
@@ -208,6 +248,7 @@ kci_test_rtnl()
kci_test_tc
kci_test_gre
kci_test_bridge
+ kci_test_addrlabel
kci_del_dummy
}
--
2.13.0
^ permalink raw reply related
* [PATCH net-next 0/2] addrlabel: don't use rtnl locking
From: Florian Westphal @ 2017-08-29 11:29 UTC (permalink / raw)
To: netdev
addrlabel doesn't appear to require rtnl lock as the addrlabel
table uses a spinlock to serialize add/delete operations.
Also, entries are reference counted so it should be safe
to call the rtnl ops without the rtnl mutex.
^ permalink raw reply
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: Greg Kroah-Hartman @ 2017-08-29 11:28 UTC (permalink / raw)
To: Stefano Brivio
Cc: Geert Uytterhoeven, driverdevel, Samuel Ortiz,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
David S. Miller
In-Reply-To: <20170829131131.6e11c8f9@elisabeth>
On Tue, Aug 29, 2017 at 01:11:31PM +0200, Stefano Brivio wrote:
> On Tue, 29 Aug 2017 12:59:00 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > Hi Greg,
> >
> > On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > The IRDA code has long been obsolete and broken. So, to keep people
> > > from trying to use it, and to prevent people from having to maintain it,
> > > let's move it to drivers/staging/ so that we can delete it entirely from
> > > the kernel in a few releases.
> >
> > (diving into an early boot crash)
> >
> > Have you tried running this? ;-)
> >
> > irda_init() and net_dev_init() are both subsys_initcall()s.
> > But the former now runs before the latter, leading to:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 00000004
>
> Should be fixed by https://patchwork.ozlabs.org/patch/807006/
> ("[net-next] staging: irda: force to be a kernel module") I guess...
Yup, that's the fix for this issue.
Geert, does that fix the problem for you?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v3 01/13] phy: add sgmii and 10gkr modes to the phy_mode enum
From: Antoine Tenart @ 2017-08-29 11:27 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Antoine Tenart, davem, andrew, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux, linux-kernel,
mw, stefanc, miquel.raynal, netdev
In-Reply-To: <4c66e79f-d385-3cf5-6f24-2a4aec9fb3b4@ti.com>
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
Hi Kishon,
On Tue, Aug 29, 2017 at 04:08:29PM +0530, Kishon Vijay Abraham I wrote:
> On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> > This patch adds more generic PHY modes to the phy_mode enum, to
> > allow configuring generic PHYs to the SGMII and/or the 10GKR mode
> > by using the set_mode callback.
> >
> > Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
>
> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Does this means the generic PHY patches of this series can go through
the net-next tree (once all the comments are taken into account)?
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: staging: r8822be: Add code for halmac sub-driver
From: Greg KH @ 2017-08-29 11:26 UTC (permalink / raw)
To: Andreas Ziegler
Cc: devel, Yan-Hsuan Chuang, Birming Chiu, netdev, Steven Ting,
Larry Finger
In-Reply-To: <0758af1e-f8d5-97be-8308-ba5535ab9415@fau.de>
On Tue, Aug 29, 2017 at 12:59:27PM +0200, Andreas Ziegler wrote:
> Hi Ping-Ke, hi Larry,
>
> I noticed your commit in linux-next today using the in-tree script at
> scripts/checkkconfigsymbols.py [0]. The script showed that it uses
> CONFIG_RTL_DEBUG in an #ifdef statement - this symbol, however, does not exist,
> and should probably be CONFIG_RTLWIFI_DEBUG instead.
>
> I attached a patch which fixes this problem.
Please resend this in a format in which I can apply it in (i.e. in a
proper email, cc: the correct mailing lists, etc.)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver
From: Antoine Tenart @ 2017-08-29 11:23 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Antoine Tenart, davem, andrew, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux, linux-kernel,
mw, stefanc, miquel.raynal, netdev
In-Reply-To: <50072fdd-d370-8518-a9f4-73e121114e67@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]
Hi Kishon,
On Tue, Aug 29, 2017 at 04:34:17PM +0530, Kishon Vijay Abraham I wrote:
> On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> >
> > +config PHY_MVEBU_CP110_COMPHY
> > + tristate "Marvell CP110 comphy driver"
> > + depends on ARCH_MVEBU && OF
>
> (ARCH_MVEBU || COMPILE_TEST) above..
Sure, I'll update.
> > +static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> > + /* lane 0 */
> > + MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
> > + /* lane 1 */
> > + MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
> > + /* lane 2 */
> > + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
> > + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
> > + /* lane 3 */
> > + MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
> > + /* lane 4 */
> > + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
> > + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
> > + MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
> > + /* lane 5 */
> > + MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
> > +};
>
> IMHO all the lane and mode configuration should come from dt. That would make
> it more reusable when comphy is configured differently.
These connexions between engines and the comphy lanes are inside the
SoC. They won't change for a given SoC, and the actual configuration is
at the board level to know what is connected to the output of a given
lane, which is already described into the dt (the lane phandle).
So I think we can keep this inside the driver, and we'll had other
tables if the same comphy is ever used in another SoC.
What do you think?
> > +static const struct phy_ops mvebu_comphy_ops = {
> > + .power_on = mvebu_comphy_power_on,
> > + .power_off = mvebu_comphy_power_off,
> > + .set_mode = mvebu_comphy_set_mode,
>
> missing .owner
I'll fix that.
> > +static struct phy *mvebu_comphy_xlate(struct device *dev,
> > + struct of_phandle_args *args)
> > +{
> > + struct mvebu_comphy_priv *priv = dev_get_drvdata(dev);
> > + struct mvebu_comphy_lane *lane;
> > + int i;
> > +
> > + if (WARN_ON(args->args[0] >= MVEBU_COMPHY_PORTS))
> > + return ERR_PTR(-EINVAL);
> > +
> > + for (i = 0; i < MVEBU_COMPHY_LANES; i++) {
> > + if (!priv->phys[i])
> > + continue;
> > +
> > + lane = phy_get_drvdata(priv->phys[i]);
> > + if (priv->phys[i] && args->np == lane->of_node)
> > + break;
> > + }
>
> You should be able to directly use of_phy_simple_xlate to get the phy pointer.
> (For that to work child node pointer should be passed in devm_phy_create).
Good idea, I'll look into this and update.
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH v2 0/2] enable hires timer to timeout datagram socket
From: David Laight @ 2017-08-29 11:16 UTC (permalink / raw)
To: 'Vallish Vaidyeshwara', David Miller
Cc: shuah@kernel.org, richardcochran@gmail.com,
xiyou.wangcong@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, eduval@amazon.com,
anchalag@amazon.com
In-Reply-To: <20170827204725.GA8625@amazon.com>
From: Vallish Vaidyeshwara
> Sent: 27 August 2017 21:47
...
> I respect the decision not to upstream this patch series, however I
> wanted to provide additional details. Application wanting high
> resolution events with real guarantees is not the case, but the case
> here is regression in system call behavior:
>
> 1) Change in system call behavior:
> strace from 4.4 test run of waiting for 180 seconds on datagram socket:
> 10:25:48.239685 setsockopt(3, SOL_SOCKET, SO_RCVTIMEO, "\264\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
> 10:25:48.239755 recvmsg(3, 0x7ffd0a3beec0, 0) = -1 EAGAIN (Resource temporarily unavailable)
> 10:28:48.236989 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
IMHO you should be complaining to the main kernel group who 'broke' the
timer code, not the networking group.
David
^ permalink raw reply
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: Stefano Brivio @ 2017-08-29 11:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: driverdevel, Samuel Ortiz, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
David S. Miller
In-Reply-To: <CAMuHMdUefXtqv9bFfgrkbu8NZRXeTD6qR-nErf6TCDz4L+OAWw@mail.gmail.com>
On Tue, 29 Aug 2017 12:59:00 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Greg,
>
> On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > The IRDA code has long been obsolete and broken. So, to keep people
> > from trying to use it, and to prevent people from having to maintain it,
> > let's move it to drivers/staging/ so that we can delete it entirely from
> > the kernel in a few releases.
>
> (diving into an early boot crash)
>
> Have you tried running this? ;-)
>
> irda_init() and net_dev_init() are both subsys_initcall()s.
> But the former now runs before the latter, leading to:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
Should be fixed by https://patchwork.ozlabs.org/patch/807006/
("[net-next] staging: irda: force to be a kernel module") I guess...
--
Stefano
^ permalink raw reply
* Re: staging: r8822be: Add code for halmac sub-driver
From: Andreas Ziegler @ 2017-08-29 10:59 UTC (permalink / raw)
To: Ping-Ke Shih, Larry Finger
Cc: gregkh, Yan-Hsuan Chuang, Birming Chiu, Shaofu, Steven Ting,
netdev, devel
In-Reply-To: <20170817174652.17656-5-Larry.Finger@lwfinger.net>
[-- Attachment #1.1: Type: text/plain, Size: 482 bytes --]
Hi Ping-Ke, hi Larry,
I noticed your commit in linux-next today using the in-tree script at
scripts/checkkconfigsymbols.py [0]. The script showed that it uses
CONFIG_RTL_DEBUG in an #ifdef statement - this symbol, however, does not exist,
and should probably be CONFIG_RTLWIFI_DEBUG instead.
I attached a patch which fixes this problem.
Best regards,
Andreas Ziegler
[0]: I called the script like this: './scripts/checkkconfigsymbols.py --force -c
938a0447f094'
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-staging-r8822be-Fix-typo-for-CONFIG_RTLWIFI_DEBUG.patch --]
[-- Type: text/x-patch; name="0001-staging-r8822be-Fix-typo-for-CONFIG_RTLWIFI_DEBUG.patch", Size: 1319 bytes --]
From 6c713900ed877c01f94fb76630f9ffd32c73ec88 Mon Sep 17 00:00:00 2001
From: Andreas Ziegler <andreas.ziegler@fau.de>
Date: Tue, 29 Aug 2017 12:50:37 +0200
Subject: [PATCH] staging: r8822be: Fix typo for CONFIG_RTLWIFI_DEBUG
The debugging output in deinit_priv is guarded by an #ifdef using
CONFIG_RTL_DEBUG. This symbol does not exist and should be
CONFIG_RTLWIFI_DEBUG instead.
Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
---
drivers/staging/rtlwifi/halmac/rtl_halmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
index 031bf2c..888ca43 100644
--- a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
+++ b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
@@ -386,7 +386,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
u32 count, size;
count = HALMAC_FEATURE_ALL + 1;
-#ifdef CONFIG_RTL_DEBUG
+#ifdef CONFIG_RTLWIFI_DEBUG
{
struct submit_ctx *sctx;
u32 i;
@@ -405,7 +405,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
rtl_mfree((u8 *)sctx, sizeof(*sctx));
}
}
-#endif /* !CONFIG_RTL_DEBUG */
+#endif /* !CONFIG_RTLWIFI_DEBUG */
size = sizeof(*indicator) * count;
kfree((u8 *)indicator);
}
--
2.7.4
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5450 bytes --]
^ permalink raw reply related
* Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver
From: Kishon Vijay Abraham I @ 2017-08-29 11:04 UTC (permalink / raw)
To: Antoine Tenart, davem, andrew, jason, sebastian.hesselbarth,
gregory.clement
Cc: thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170828145725.2539-3-antoine.tenart@free-electrons.com>
Hi Antoine,
On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> On the CP110 unit, which can be found on various Marvell platforms such
> as the 7k and 8k (currently), a comphy (common PHYs) hardware block can
> be found. This block provides a number of PHYs which can be used in
> various modes by other controllers (network, SATA ...). These common
> PHYs must be configured for the controllers using them to work correctly
> either at boot time, or when the system runs to switch the mode used.
> This patch adds a driver for this comphy hardware block, providing
> callbacks for the its PHYs so that consumers can configure the modes
> used.
>
> As of this commit, two modes are supported by the comphy driver: sgmii
> and 10gkr.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
> drivers/phy/marvell/Kconfig | 10 +
> drivers/phy/marvell/Makefile | 1 +
> drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 656 +++++++++++++++++++++++++++
> 3 files changed, 667 insertions(+)
> create mode 100644 drivers/phy/marvell/phy-mvebu-cp110-comphy.c
>
> diff --git a/drivers/phy/marvell/Kconfig b/drivers/phy/marvell/Kconfig
> index 048d8893bc2e..26755f3d1a9a 100644
> --- a/drivers/phy/marvell/Kconfig
> +++ b/drivers/phy/marvell/Kconfig
> @@ -21,6 +21,16 @@ config PHY_BERLIN_USB
> help
> Enable this to support the USB PHY on Marvell Berlin SoCs.
>
> +config PHY_MVEBU_CP110_COMPHY
> + tristate "Marvell CP110 comphy driver"
> + depends on ARCH_MVEBU && OF
(ARCH_MVEBU || COMPILE_TEST) above..
> + select GENERIC_PHY
> + help
> + This driver allows to control the comphy, an hardware block providing
> + shared serdes PHYs on Marvell Armada 7k/8k (in the CP110). Its serdes
> + lanes can be used by various controllers (Ethernet, sata, usb,
> + PCIe...).
> +
> config PHY_MVEBU_SATA
> def_bool y
> depends on ARCH_DOVE || MACH_DOVE || MACH_KIRKWOOD
> diff --git a/drivers/phy/marvell/Makefile b/drivers/phy/marvell/Makefile
> index 3fc188f59118..0cf6a7cbaf9f 100644
> --- a/drivers/phy/marvell/Makefile
> +++ b/drivers/phy/marvell/Makefile
> @@ -1,6 +1,7 @@
> obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
> obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
> obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
> +obj-$(CONFIG_PHY_MVEBU_CP110_COMPHY) += phy-mvebu-cp110-comphy.o
> obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
> obj-$(CONFIG_PHY_PXA_28NM_HSIC) += phy-pxa-28nm-hsic.o
> obj-$(CONFIG_PHY_PXA_28NM_USB2) += phy-pxa-28nm-usb2.o
> diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> new file mode 100644
> index 000000000000..41556e790856
> --- /dev/null
> +++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> @@ -0,0 +1,656 @@
> +/*
> + * Copyright (C) 2017 Marvell
> + *
> + * Antoine Tenart <antoine.tenart@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +/* Relative to priv->base */
> +#define MVEBU_COMPHY_SERDES_CFG0(n) (0x0 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_CFG0_PU_PLL BIT(1)
> +#define MVEBU_COMPHY_SERDES_CFG0_GEN_RX(n) ((n) << 3)
> +#define MVEBU_COMPHY_SERDES_CFG0_GEN_TX(n) ((n) << 7)
> +#define MVEBU_COMPHY_SERDES_CFG0_PU_RX BIT(11)
> +#define MVEBU_COMPHY_SERDES_CFG0_PU_TX BIT(12)
> +#define MVEBU_COMPHY_SERDES_CFG0_HALF_BUS BIT(14)
> +#define MVEBU_COMPHY_SERDES_CFG1(n) (0x4 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_CFG1_RESET BIT(3)
> +#define MVEBU_COMPHY_SERDES_CFG1_RX_INIT BIT(4)
> +#define MVEBU_COMPHY_SERDES_CFG1_CORE_RESET BIT(5)
> +#define MVEBU_COMPHY_SERDES_CFG1_RF_RESET BIT(6)
> +#define MVEBU_COMPHY_SERDES_CFG2(n) (0x8 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_CFG2_DFE_EN BIT(4)
> +#define MVEBU_COMPHY_SERDES_STATUS0(n) (0x18 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_STATUS0_TX_PLL_RDY BIT(2)
> +#define MVEBU_COMPHY_SERDES_STATUS0_RX_PLL_RDY BIT(3)
> +#define MVEBU_COMPHY_SERDES_STATUS0_RX_INIT BIT(4)
> +#define MVEBU_COMPHY_PWRPLL_CTRL(n) (0x804 + (n) * 0x1000)
> +#define MVEBU_COMPHY_PWRPLL_CTRL_RFREQ(n) ((n) << 0)
> +#define MVEBU_COMPHY_PWRPLL_PHY_MODE(n) ((n) << 5)
> +#define MVEBU_COMPHY_IMP_CAL(n) (0x80c + (n) * 0x1000)
> +#define MVEBU_COMPHY_IMP_CAL_TX_EXT(n) ((n) << 10)
> +#define MVEBU_COMPHY_IMP_CAL_TX_EXT_EN BIT(15)
> +#define MVEBU_COMPHY_DFE_RES(n) (0x81c + (n) * 0x1000)
> +#define MVEBU_COMPHY_DFE_RES_FORCE_GEN_TBL BIT(15)
> +#define MVEBU_COMPHY_COEF(n) (0x828 + (n) * 0x1000)
> +#define MVEBU_COMPHY_COEF_DFE_EN BIT(14)
> +#define MVEBU_COMPHY_COEF_DFE_CTRL BIT(15)
> +#define MVEBU_COMPHY_GEN1_S0(n) (0x834 + (n) * 0x1000)
> +#define MVEBU_COMPHY_GEN1_S0_TX_AMP(n) ((n) << 1)
> +#define MVEBU_COMPHY_GEN1_S0_TX_EMPH(n) ((n) << 7)
> +#define MVEBU_COMPHY_GEN1_S1(n) (0x838 + (n) * 0x1000)
> +#define MVEBU_COMPHY_GEN1_S1_RX_MUL_PI(n) ((n) << 0)
> +#define MVEBU_COMPHY_GEN1_S1_RX_MUL_PF(n) ((n) << 3)
> +#define MVEBU_COMPHY_GEN1_S1_RX_MUL_FI(n) ((n) << 6)
> +#define MVEBU_COMPHY_GEN1_S1_RX_MUL_FF(n) ((n) << 8)
> +#define MVEBU_COMPHY_GEN1_S1_RX_DFE_EN BIT(10)
> +#define MVEBU_COMPHY_GEN1_S1_RX_DIV(n) ((n) << 11)
> +#define MVEBU_COMPHY_GEN1_S2(n) (0x8f4 + (n) * 0x1000)
> +#define MVEBU_COMPHY_GEN1_S2_TX_EMPH(n) ((n) << 0)
> +#define MVEBU_COMPHY_GEN1_S2_TX_EMPH_EN BIT(4)
> +#define MVEBU_COMPHY_LOOPBACK(n) (0x88c + (n) * 0x1000)
> +#define MVEBU_COMPHY_LOOPBACK_DBUS_WIDTH(n) ((n) << 1)
> +#define MVEBU_COMPHY_VDD_CAL0(n) (0x908 + (n) * 0x1000)
> +#define MVEBU_COMPHY_VDD_CAL0_CONT_MODE BIT(15)
> +#define MVEBU_COMPHY_EXT_SELV(n) (0x914 + (n) * 0x1000)
> +#define MVEBU_COMPHY_EXT_SELV_RX_SAMPL(n) ((n) << 5)
> +#define MVEBU_COMPHY_MISC_CTRL0(n) (0x93c + (n) * 0x1000)
> +#define MVEBU_COMPHY_MISC_CTRL0_ICP_FORCE BIT(5)
> +#define MVEBU_COMPHY_MISC_CTRL0_REFCLK_SEL BIT(10)
> +#define MVEBU_COMPHY_RX_CTRL1(n) (0x940 + (n) * 0x1000)
> +#define MVEBU_COMPHY_RX_CTRL1_RXCLK2X_SEL BIT(11)
> +#define MVEBU_COMPHY_RX_CTRL1_CLK8T_EN BIT(12)
> +#define MVEBU_COMPHY_SPEED_DIV(n) (0x954 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SPEED_DIV_TX_FORCE BIT(7)
> +#define MVEBU_SP_CALIB(n) (0x96c + (n) * 0x1000)
> +#define MVEBU_SP_CALIB_SAMPLER(n) ((n) << 8)
> +#define MVEBU_SP_CALIB_SAMPLER_EN BIT(12)
> +#define MVEBU_COMPHY_TX_SLEW_RATE(n) (0x974 + (n) * 0x1000)
> +#define MVEBU_COMPHY_TX_SLEW_RATE_EMPH(n) ((n) << 5)
> +#define MVEBU_COMPHY_TX_SLEW_RATE_SLC(n) ((n) << 10)
> +#define MVEBU_COMPHY_DLT_CTRL(n) (0x984 + (n) * 0x1000)
> +#define MVEBU_COMPHY_DLT_CTRL_DTL_FLOOP_EN BIT(2)
> +#define MVEBU_COMPHY_FRAME_DETECT0(n) (0xa14 + (n) * 0x1000)
> +#define MVEBU_COMPHY_FRAME_DETECT0_PATN(n) ((n) << 7)
> +#define MVEBU_COMPHY_FRAME_DETECT3(n) (0xa20 + (n) * 0x1000)
> +#define MVEBU_COMPHY_FRAME_DETECT3_LOST_TIMEOUT_EN BIT(12)
> +#define MVEBU_COMPHY_DME(n) (0xa28 + (n) * 0x1000)
> +#define MVEBU_COMPHY_DME_ETH_MODE BIT(7)
> +#define MVEBU_COMPHY_TRAINING0(n) (0xa68 + (n) * 0x1000)
> +#define MVEBU_COMPHY_TRAINING0_P2P_HOLD BIT(15)
> +#define MVEBU_COMPHY_TRAINING5(n) (0xaa4 + (n) * 0x1000)
> +#define MVEBU_COMPHY_TRAINING5_RX_TIMER(n) ((n) << 0)
> +#define MVEBU_COMPHY_TX_TRAIN_PRESET(n) (0xb1c + (n) * 0x1000)
> +#define MVEBU_COMPHY_TX_TRAIN_PRESET_16B_AUTO_EN BIT(8)
> +#define MVEBU_COMPHY_TX_TRAIN_PRESET_PRBS11 BIT(9)
> +#define MVEBU_COMPHY_GEN1_S3(n) (0xc40 + (n) * 0x1000)
> +#define MVEBU_COMPHY_GEN1_S3_FBCK_SEL BIT(9)
> +#define MVEBU_COMPHY_GEN1_S4(n) (0xc44 + (n) * 0x1000)
> +#define MVEBU_COMPHY_GEN1_S4_DFE_RES(n) ((n) << 8)
> +#define MVEBU_COMPHY_TX_PRESET(n) (0xc68 + (n) * 0x1000)
> +#define MVEBU_COMPHY_TX_PRESET_INDEX(n) ((n) << 0)
> +#define MVEBU_COMPHY_GEN1_S5(n) (0xd38 + (n) * 0x1000)
> +#define MVEBU_COMPHY_GEN1_S5_ICP(n) ((n) << 0)
> +
> +/* Relative to priv->regmap */
> +#define MVEBU_COMPHY_CONF1(n) (0x1000 + (n) * 0x28)
> +#define MVEBU_COMPHY_CONF1_PWRUP BIT(1)
> +#define MVEBU_COMPHY_CONF1_USB_PCIE BIT(2) /* 0: Ethernet/SATA */
> +#define MVEBU_COMPHY_CONF6(n) (0x1014 + (n) * 0x28)
> +#define MVEBU_COMPHY_CONF6_40B BIT(18)
> +#define MVEBU_COMPHY_SELECTOR 0x1140
> +#define MVEBU_COMPHY_SELECTOR_PHY(n) ((n) * 0x4)
> +
> +#define MVEBU_COMPHY_LANES 6
> +#define MVEBU_COMPHY_PORTS 3
> +
> +struct mvebu_comhy_conf {
> + enum phy_mode mode;
> + unsigned lane;
> + unsigned port;
> + u32 mux;
> +};
> +
> +#define MVEBU_COMPHY_CONF(_lane, _port, _mode, _mux) \
> + { \
> + .lane = _lane, \
> + .port = _port, \
> + .mode = _mode, \
> + .mux = _mux, \
> + }
> +
> +static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> + /* lane 0 */
> + MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
> + /* lane 1 */
> + MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
> + /* lane 2 */
> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
> + /* lane 3 */
> + MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
> + /* lane 4 */
> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
> + MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
> + /* lane 5 */
> + MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
> +};
IMHO all the lane and mode configuration should come from dt. That would make
it more reusable when comphy is configured differently.
> +
> +struct mvebu_comphy_priv {
> + void __iomem *base;
> + struct regmap *regmap;
> + struct device *dev;
> + struct phy *phys[MVEBU_COMPHY_LANES];
> + int modes[MVEBU_COMPHY_LANES];
> +};
> +
> +struct mvebu_comphy_lane {
> + struct mvebu_comphy_priv *priv;
> + struct device_node *of_node;
> + unsigned id;
> + enum phy_mode mode;
> + int port;
> +};
> +
> +static int mvebu_comphy_get_mux(int lane, int port, enum phy_mode mode)
> +{
> + int i, n = ARRAY_SIZE(mvebu_comphy_cp110_modes);
> +
> + /* Unused PHY mux value is 0x0 */
> + if (mode == PHY_MODE_INVALID)
> + return 0;
> +
> + for (i = 0; i < n; i++) {
> + if (mvebu_comphy_cp110_modes[i].lane == lane &&
> + mvebu_comphy_cp110_modes[i].port == port &&
> + mvebu_comphy_cp110_modes[i].mode == mode)
> + break;
> + }
> +
> + if (i == n)
> + return -EINVAL;
> +
> + return mvebu_comphy_cp110_modes[i].mux;
> +}
> +
> +static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
> + enum phy_mode mode)
> +{
> + struct mvebu_comphy_priv *priv = lane->priv;
> + u32 val;
> +
> + regmap_read(priv->regmap, MVEBU_COMPHY_CONF1(lane->id), &val);
> + val &= ~MVEBU_COMPHY_CONF1_USB_PCIE;
> + val |= MVEBU_COMPHY_CONF1_PWRUP;
> + regmap_write(priv->regmap, MVEBU_COMPHY_CONF1(lane->id), val);
> +
> + /* Select baud rates and PLLs */
> + val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG0(lane->id));
> + val &= ~(MVEBU_COMPHY_SERDES_CFG0_PU_PLL |
> + MVEBU_COMPHY_SERDES_CFG0_PU_RX |
> + MVEBU_COMPHY_SERDES_CFG0_PU_TX |
> + MVEBU_COMPHY_SERDES_CFG0_HALF_BUS |
> + MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xf) |
> + MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xf));
> + if (mode == PHY_MODE_10GKR)
> + val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xe) |
> + MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xe);
> + else if (mode == PHY_MODE_SGMII)
> + val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x6) |
> + MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x6) |
> + MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
> + writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG0(lane->id));
> +
> + /* reset */
> + val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> + val &= ~(MVEBU_COMPHY_SERDES_CFG1_RESET |
> + MVEBU_COMPHY_SERDES_CFG1_CORE_RESET |
> + MVEBU_COMPHY_SERDES_CFG1_RF_RESET);
> + writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> +
> + /* de-assert reset */
> + val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> + val |= MVEBU_COMPHY_SERDES_CFG1_RESET |
> + MVEBU_COMPHY_SERDES_CFG1_CORE_RESET;
> + writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> +
> + /* wait until clocks are ready */
> + mdelay(1);
> +
> + /* exlicitly disable 40B, the bits isn't clear on reset */
> + regmap_read(priv->regmap, MVEBU_COMPHY_CONF6(lane->id), &val);
> + val &= ~MVEBU_COMPHY_CONF6_40B;
> + regmap_write(priv->regmap, MVEBU_COMPHY_CONF6(lane->id), val);
> +
> + /* refclk selection */
> + val = readl(priv->base + MVEBU_COMPHY_MISC_CTRL0(lane->id));
> + val &= ~MVEBU_COMPHY_MISC_CTRL0_REFCLK_SEL;
> + if (mode == PHY_MODE_10GKR)
> + val |= MVEBU_COMPHY_MISC_CTRL0_ICP_FORCE;
> + writel(val, priv->base + MVEBU_COMPHY_MISC_CTRL0(lane->id));
> +
> + /* power and pll selection */
> + val = readl(priv->base + MVEBU_COMPHY_PWRPLL_CTRL(lane->id));
> + val &= ~(MVEBU_COMPHY_PWRPLL_CTRL_RFREQ(0x1f) |
> + MVEBU_COMPHY_PWRPLL_PHY_MODE(0x7));
> + val |= MVEBU_COMPHY_PWRPLL_CTRL_RFREQ(0x1) |
> + MVEBU_COMPHY_PWRPLL_PHY_MODE(0x4);
> + writel(val, priv->base + MVEBU_COMPHY_PWRPLL_CTRL(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_LOOPBACK(lane->id));
> + val &= ~MVEBU_COMPHY_LOOPBACK_DBUS_WIDTH(0x7);
> + val |= MVEBU_COMPHY_LOOPBACK_DBUS_WIDTH(0x1);
> + writel(val, priv->base + MVEBU_COMPHY_LOOPBACK(lane->id));
> +}
> +
> +static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane,
> + enum phy_mode mode)
> +{
> + struct mvebu_comphy_priv *priv = lane->priv;
> + u32 val;
> +
> + /* SERDES external config */
> + val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG0(lane->id));
> + val |= MVEBU_COMPHY_SERDES_CFG0_PU_PLL |
> + MVEBU_COMPHY_SERDES_CFG0_PU_RX |
> + MVEBU_COMPHY_SERDES_CFG0_PU_TX;
> + writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG0(lane->id));
> +
> + /* check rx/tx pll */
> + readl_poll_timeout(priv->base + MVEBU_COMPHY_SERDES_STATUS0(lane->id),
> + val,
> + val & (MVEBU_COMPHY_SERDES_STATUS0_RX_PLL_RDY |
> + MVEBU_COMPHY_SERDES_STATUS0_TX_PLL_RDY),
> + 1000, 150000);
> + if (!(val & (MVEBU_COMPHY_SERDES_STATUS0_RX_PLL_RDY |
> + MVEBU_COMPHY_SERDES_STATUS0_TX_PLL_RDY)))
> + return -ETIMEDOUT;
> +
> + /* rx init */
> + val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> + val |= MVEBU_COMPHY_SERDES_CFG1_RX_INIT;
> + writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> +
> + /* check rx */
> + readl_poll_timeout(priv->base + MVEBU_COMPHY_SERDES_STATUS0(lane->id),
> + val, val & MVEBU_COMPHY_SERDES_STATUS0_RX_INIT,
> + 1000, 10000);
> + if (!(val & MVEBU_COMPHY_SERDES_STATUS0_RX_INIT))
> + return -ETIMEDOUT;
> +
> + val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> + val &= ~MVEBU_COMPHY_SERDES_CFG1_RX_INIT;
> + writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> +
> + return 0;
> +}
> +
> +static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
> +{
> + struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> + struct mvebu_comphy_priv *priv = lane->priv;
> + u32 val;
> +
> + mvebu_comphy_ethernet_init_reset(lane, mode);
> +
> + val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
> + val &= ~MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
> + val |= MVEBU_COMPHY_RX_CTRL1_RXCLK2X_SEL;
> + writel(val, priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_DLT_CTRL(lane->id));
> + val &= ~MVEBU_COMPHY_DLT_CTRL_DTL_FLOOP_EN;
> + writel(val, priv->base + MVEBU_COMPHY_DLT_CTRL(lane->id));
> +
> + regmap_read(priv->regmap, MVEBU_COMPHY_CONF1(lane->id), &val);
> + val &= ~MVEBU_COMPHY_CONF1_USB_PCIE;
> + val |= MVEBU_COMPHY_CONF1_PWRUP;
> + regmap_write(priv->regmap, MVEBU_COMPHY_CONF1(lane->id), val);
> +
> + val = readl(priv->base + MVEBU_COMPHY_GEN1_S0(lane->id));
> + val &= ~MVEBU_COMPHY_GEN1_S0_TX_EMPH(0xf);
> + val |= MVEBU_COMPHY_GEN1_S0_TX_EMPH(0x1);
> + writel(val, priv->base + MVEBU_COMPHY_GEN1_S0(lane->id));
> +
> + return mvebu_comphy_init_plls(lane, mode);
> +}
> +
> +static int mvebu_comphy_set_mode_10gkr(struct phy *phy, enum phy_mode mode)
> +{
> + struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> + struct mvebu_comphy_priv *priv = lane->priv;
> + u32 val;
> +
> + mvebu_comphy_ethernet_init_reset(lane, mode);
> +
> + val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
> + val |= MVEBU_COMPHY_RX_CTRL1_RXCLK2X_SEL |
> + MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
> + writel(val, priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_DLT_CTRL(lane->id));
> + val |= MVEBU_COMPHY_DLT_CTRL_DTL_FLOOP_EN;
> + writel(val, priv->base + MVEBU_COMPHY_DLT_CTRL(lane->id));
> +
> + /* Speed divider */
> + val = readl(priv->base + MVEBU_COMPHY_SPEED_DIV(lane->id));
> + val |= MVEBU_COMPHY_SPEED_DIV_TX_FORCE;
> + writel(val, priv->base + MVEBU_COMPHY_SPEED_DIV(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG2(lane->id));
> + val |= MVEBU_COMPHY_SERDES_CFG2_DFE_EN;
> + writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG2(lane->id));
> +
> + /* DFE resolution */
> + val = readl(priv->base + MVEBU_COMPHY_DFE_RES(lane->id));
> + val |= MVEBU_COMPHY_DFE_RES_FORCE_GEN_TBL;
> + writel(val, priv->base + MVEBU_COMPHY_DFE_RES(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_GEN1_S0(lane->id));
> + val &= ~(MVEBU_COMPHY_GEN1_S0_TX_AMP(0x1f) |
> + MVEBU_COMPHY_GEN1_S0_TX_EMPH(0xf));
> + val |= MVEBU_COMPHY_GEN1_S0_TX_AMP(0x1c) |
> + MVEBU_COMPHY_GEN1_S0_TX_EMPH(0xe);
> + writel(val, priv->base + MVEBU_COMPHY_GEN1_S0(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_GEN1_S2(lane->id));
> + val &= ~MVEBU_COMPHY_GEN1_S2_TX_EMPH(0xf);
> + val |= MVEBU_COMPHY_GEN1_S2_TX_EMPH_EN;
> + writel(val, priv->base + MVEBU_COMPHY_GEN1_S2(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_TX_SLEW_RATE(lane->id));
> + val |= MVEBU_COMPHY_TX_SLEW_RATE_EMPH(0x3) |
> + MVEBU_COMPHY_TX_SLEW_RATE_SLC(0x3f);
> + writel(val, priv->base + MVEBU_COMPHY_TX_SLEW_RATE(lane->id));
> +
> + /* Impedance calibration */
> + val = readl(priv->base + MVEBU_COMPHY_IMP_CAL(lane->id));
> + val &= ~MVEBU_COMPHY_IMP_CAL_TX_EXT(0x1f);
> + val |= MVEBU_COMPHY_IMP_CAL_TX_EXT(0xe) |
> + MVEBU_COMPHY_IMP_CAL_TX_EXT_EN;
> + writel(val, priv->base + MVEBU_COMPHY_IMP_CAL(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_GEN1_S5(lane->id));
> + val &= ~MVEBU_COMPHY_GEN1_S5_ICP(0xf);
> + writel(val, priv->base + MVEBU_COMPHY_GEN1_S5(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_GEN1_S1(lane->id));
> + val &= ~(MVEBU_COMPHY_GEN1_S1_RX_MUL_PI(0x7) |
> + MVEBU_COMPHY_GEN1_S1_RX_MUL_PF(0x7) |
> + MVEBU_COMPHY_GEN1_S1_RX_MUL_FI(0x3) |
> + MVEBU_COMPHY_GEN1_S1_RX_MUL_FF(0x3));
> + val |= MVEBU_COMPHY_GEN1_S1_RX_DFE_EN |
> + MVEBU_COMPHY_GEN1_S1_RX_MUL_PI(0x2) |
> + MVEBU_COMPHY_GEN1_S1_RX_MUL_PF(0x2) |
> + MVEBU_COMPHY_GEN1_S1_RX_MUL_FF(0x1) |
> + MVEBU_COMPHY_GEN1_S1_RX_DIV(0x3);
> + writel(val, priv->base + MVEBU_COMPHY_GEN1_S1(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_COEF(lane->id));
> + val &= ~(MVEBU_COMPHY_COEF_DFE_EN | MVEBU_COMPHY_COEF_DFE_CTRL);
> + writel(val, priv->base + MVEBU_COMPHY_COEF(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_GEN1_S4(lane->id));
> + val &= ~MVEBU_COMPHY_GEN1_S4_DFE_RES(0x3);
> + val |= MVEBU_COMPHY_GEN1_S4_DFE_RES(0x1);
> + writel(val, priv->base + MVEBU_COMPHY_GEN1_S4(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_GEN1_S3(lane->id));
> + val |= MVEBU_COMPHY_GEN1_S3_FBCK_SEL;
> + writel(val, priv->base + MVEBU_COMPHY_GEN1_S3(lane->id));
> +
> + /* rx training timer */
> + val = readl(priv->base + MVEBU_COMPHY_TRAINING5(lane->id));
> + val &= ~MVEBU_COMPHY_TRAINING5_RX_TIMER(0x3ff);
> + val |= MVEBU_COMPHY_TRAINING5_RX_TIMER(0x13);
> + writel(val, priv->base + MVEBU_COMPHY_TRAINING5(lane->id));
> +
> + /* tx train peak to peak hold */
> + val = readl(priv->base + MVEBU_COMPHY_TRAINING0(lane->id));
> + val |= MVEBU_COMPHY_TRAINING0_P2P_HOLD;
> + writel(val, priv->base + MVEBU_COMPHY_TRAINING0(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_TX_PRESET(lane->id));
> + val &= ~MVEBU_COMPHY_TX_PRESET_INDEX(0xf);
> + val |= MVEBU_COMPHY_TX_PRESET_INDEX(0x2); /* preset coeff */
> + writel(val, priv->base + MVEBU_COMPHY_TX_PRESET(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_FRAME_DETECT3(lane->id));
> + val &= ~MVEBU_COMPHY_FRAME_DETECT3_LOST_TIMEOUT_EN;
> + writel(val, priv->base + MVEBU_COMPHY_FRAME_DETECT3(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_TX_TRAIN_PRESET(lane->id));
> + val |= MVEBU_COMPHY_TX_TRAIN_PRESET_16B_AUTO_EN |
> + MVEBU_COMPHY_TX_TRAIN_PRESET_PRBS11;
> + writel(val, priv->base + MVEBU_COMPHY_TX_TRAIN_PRESET(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_FRAME_DETECT0(lane->id));
> + val &= ~MVEBU_COMPHY_FRAME_DETECT0_PATN(0x1ff);
> + val |= MVEBU_COMPHY_FRAME_DETECT0_PATN(0x88);
> + writel(val, priv->base + MVEBU_COMPHY_FRAME_DETECT0(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_DME(lane->id));
> + val |= MVEBU_COMPHY_DME_ETH_MODE;
> + writel(val, priv->base + MVEBU_COMPHY_DME(lane->id));
> +
> + val = readl(priv->base + MVEBU_COMPHY_VDD_CAL0(lane->id));
> + val |= MVEBU_COMPHY_VDD_CAL0_CONT_MODE;
> + writel(val, priv->base + MVEBU_COMPHY_VDD_CAL0(lane->id));
> +
> + val = readl(priv->base + MVEBU_SP_CALIB(lane->id));
> + val &= ~MVEBU_SP_CALIB_SAMPLER(0x3);
> + val |= MVEBU_SP_CALIB_SAMPLER(0x3) |
> + MVEBU_SP_CALIB_SAMPLER_EN;
> + writel(val, priv->base + MVEBU_SP_CALIB(lane->id));
> + val &= ~MVEBU_SP_CALIB_SAMPLER_EN;
> + writel(val, priv->base + MVEBU_SP_CALIB(lane->id));
> +
> + /* External rx regulator */
> + val = readl(priv->base + MVEBU_COMPHY_EXT_SELV(lane->id));
> + val &= ~MVEBU_COMPHY_EXT_SELV_RX_SAMPL(0x1f);
> + val |= MVEBU_COMPHY_EXT_SELV_RX_SAMPL(0x1a);
> + writel(val, priv->base + MVEBU_COMPHY_EXT_SELV(lane->id));
> +
> + return mvebu_comphy_init_plls(lane, mode);
> +}
> +
> +static int mvebu_comphy_power_on(struct phy *phy)
> +{
> + struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> + struct mvebu_comphy_priv *priv = lane->priv;
> + int ret;
> + u32 mux, val;
> +
> + mux = mvebu_comphy_get_mux(lane->id, lane->port, lane->mode);
> + if (mux < 0)
> + return -ENOTSUPP;
> +
> + regmap_read(priv->regmap, MVEBU_COMPHY_SELECTOR, &val);
> + val &= ~(0xf << MVEBU_COMPHY_SELECTOR_PHY(lane->id));
> + val |= mux << MVEBU_COMPHY_SELECTOR_PHY(lane->id);
> + regmap_write(priv->regmap, MVEBU_COMPHY_SELECTOR, val);
> +
> + switch (lane->mode) {
> + case PHY_MODE_SGMII:
> + ret = mvebu_comphy_set_mode_sgmii(phy, lane->mode);
> + break;
> + case PHY_MODE_10GKR:
> + ret = mvebu_comphy_set_mode_10gkr(phy, lane->mode);
> + break;
> + default:
> + return -ENOTSUPP;
> + }
> +
> + /* digital reset */
> + val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> + val |= MVEBU_COMPHY_SERDES_CFG1_RF_RESET;
> + writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> +
> + return ret;
> +}
> +
> +static int mvebu_comphy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> +
> + if (mvebu_comphy_get_mux(lane->id, lane->port, mode) < 0)
> + return -EINVAL;
> +
> + lane->mode = mode;
> + return 0;
> +}
> +
> +static int mvebu_comphy_power_off(struct phy *phy)
> +{
> + struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> + struct mvebu_comphy_priv *priv = lane->priv;
> + u32 val;
> +
> + val = readl(priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> + val &= ~(MVEBU_COMPHY_SERDES_CFG1_RESET |
> + MVEBU_COMPHY_SERDES_CFG1_CORE_RESET |
> + MVEBU_COMPHY_SERDES_CFG1_RF_RESET);
> + writel(val, priv->base + MVEBU_COMPHY_SERDES_CFG1(lane->id));
> +
> + regmap_read(priv->regmap, MVEBU_COMPHY_SELECTOR, &val);
> + val &= ~(0xf << MVEBU_COMPHY_SELECTOR_PHY(lane->id));
> + regmap_write(priv->regmap, MVEBU_COMPHY_SELECTOR, val);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops mvebu_comphy_ops = {
> + .power_on = mvebu_comphy_power_on,
> + .power_off = mvebu_comphy_power_off,
> + .set_mode = mvebu_comphy_set_mode,
missing .owner
> +};
> +
> +static struct phy *mvebu_comphy_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct mvebu_comphy_priv *priv = dev_get_drvdata(dev);
> + struct mvebu_comphy_lane *lane;
> + int i;
> +
> + if (WARN_ON(args->args[0] >= MVEBU_COMPHY_PORTS))
> + return ERR_PTR(-EINVAL);
> +
> + for (i = 0; i < MVEBU_COMPHY_LANES; i++) {
> + if (!priv->phys[i])
> + continue;
> +
> + lane = phy_get_drvdata(priv->phys[i]);
> + if (priv->phys[i] && args->np == lane->of_node)
> + break;
> + }
You should be able to directly use of_phy_simple_xlate to get the phy pointer.
(For that to work child node pointer should be passed in devm_phy_create).
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: Geert Uytterhoeven @ 2017-08-29 10:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David S. Miller, Samuel Ortiz, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, driverdevel
In-Reply-To: <20170827150334.32495-1-gregkh@linuxfoundation.org>
Hi Greg,
On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> The IRDA code has long been obsolete and broken. So, to keep people
> from trying to use it, and to prevent people from having to maintain it,
> let's move it to drivers/staging/ so that we can delete it entirely from
> the kernel in a few releases.
(diving into an early boot crash)
Have you tried running this? ;-)
irda_init() and net_dev_init() are both subsys_initcall()s.
But the former now runs before the latter, leading to:
Unable to handle kernel NULL pointer dereference at virtual address 00000004
pgd = c0004000
[00000004] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted
4.13.0-rc7-kzm9g-05769-g46efec19d1294ece-dirty #954
Hardware name: Generic SH73A0 (Flattened Device Tree)
task: df440040 task.stack: df442000
PC is at __list_add_valid+0x8/0x74
LR is at 0x0
pc : [<c03223ec>] lr : [<00000000>] psr: 60000013
sp : df443ef0 ip : df440630 fp : 00000000
r10: c0828858 r9 : c0937000 r8 : 00000000
r7 : c0908034 r6 : 00000000 r5 : c0908020 r4 : c090862c
r3 : df440040 r2 : 00000000 r1 : c090862c r0 : c0908034
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 4000404a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xdf442210)
Stack: (0xdf443ef0 to 0xdf444000)
3ee0: c090862c c0489ea8 00000000 00000000
3f00: c081c274 00000093 c0836418 c081c2a0 00000004 c0101878 00000000 c0790758
3f20: 00000000 c013fec0 00000001 c078fbf0 00000004 00000004 c079076c dfffce3f
3f40: 00000092 c079076c dfffce3f dfffce47 c0910af0 00000004 c0828844 00000093
3f60: 00000004 c0828848 00000093 c0836418 c0937000 c0800d28 00000004 00000004
3f80: 00000000 c08005b0 00000000 c055cf7c 00000000 00000000 00000000 00000000
3fa0: 00000000 c055cf84 00000000 c0106f90 00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 7fdfffff fff7fdff
[<c03223ec>] (__list_add_valid) from [<c0489ea8>] (dev_add_pack+0x70/0xac)
[<c0489ea8>] (dev_add_pack) from [<c081c2a0>] (irda_init+0x2c/0x84)
[<c081c2a0>] (irda_init) from [<c0101878>] (do_one_initcall+0xa8/0x150)
[<c0101878>] (do_one_initcall) from [<c0800d28>]
(kernel_init_freeable+0x114/0x1d4)
[<c0800d28>] (kernel_init_freeable) from [<c055cf84>] (kernel_init+0x8/0x110)
[<c055cf84>] (kernel_init) from [<c0106f90>] (ret_from_fork+0x14/0x24)
DIsabling CONFIG_IRDA (apparently I wasn't using it anyway), and
continuing my life...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [ethtool] ethtool: Remove UDP Fragmentation Offload use from ethtool
From: Michal Kubecek @ 2017-08-29 10:44 UTC (permalink / raw)
To: Tariq Toukan
Cc: John W. Linville, Eric Dumazet, David Miller, netdev,
Eran Ben Elisha, Shaker Daibes
In-Reply-To: <a1c55136-c534-bcdf-ccc8-3f38affb69e8@mellanox.com>
On Tue, Aug 29, 2017 at 10:50:20AM +0300, Tariq Toukan wrote:
> On 28/08/2017 9:22 PM, John W. Linville wrote:
> > On Mon, Aug 28, 2017 at 08:00:11AM -0700, Eric Dumazet wrote:
> > > On Mon, 2017-08-28 at 15:38 +0300, Tariq Toukan wrote:
> > > > From: Shaker Daibes <shakerd@mellanox.com>
> > > >
> > > > UFO was removed in kernel, here we remove it in ethtool app.
> > > >
> > > > Fixes the following issue:
> > > > Features for ens8:
> > > > Cannot get device udp-fragmentation-offload settings: Operation not supported
>
> But I wonder how the warning removal should be done??
>
> I have some suggestions in mind:
> 1) Have a special condition that does not print a warning only in the case
> of UFO?
> 2) Remove the warning totally? I don't like this option.
> 3) Add a max_kernel_ver field in struct off_flag_def, and use it to not
> print the warning, or to mark the feature 'off [fixed]'.
IMHO there is nothing wrong with not writing a warning for "get"
operation, after all it's just "ethtool -k", i.e. "show me all
offloading flags" and we do not warn about unsupported named features
either. IMHO the only question should be how friendly we should be to
old scripts expecting the line in the output:
(a) omit the "udp-fragmentation-offload:" line (be consistent)
(b) say something like "udp-fragmentation-offload: n/a"
(c) pretend it's there and is off (most careful but misleading)
Personally, I would prefer (a) but some badly written scripts might have
problem with this approach.
On the other hand, an attempt to _set_ the flag with "ethtool -K" should
issue an error.
Michal Kubecek
^ permalink raw reply
* nflog performance ...
From: Akshat Kakkar @ 2017-08-29 10:41 UTC (permalink / raw)
To: netdev
I am using ulogd2 to log iptables activity.
However, when using pgsql as output plugin ... performance is very
very sluggish. (~130-150 entries per second)
To enhance performance I am trying
modprobe ipt_ULOG nlbufsiz=65535 flushtimeout=1000
but this gives error : ipt_ULOG module not found.
On the same lines, I tried
modprobe ipt_NFLOG nlbufsiz=65535 flushtimeout=1000
It didnt give any error !!!
But still there is no increase in performance.
Are these values effective?
I am also using --nflog-threshold 50 in iptables rule.
I am setting buffer_size as
netlink_socket_buffer_size=104857600
netlink_socket_buffer_maxsize=1048576000
When running ulog, it gives message of setting buffer size as
21708600. Though it didnt give any message like
"ulogd_inppkt_NFLOG.c:443 We are losing events, increasing buffer size
to xxxxxx"
but again why it is only setting buffer size as 21708600 though I have
set in config as 104857600?
^ permalink raw reply
* Re: [PATCH net-next v3 01/13] phy: add sgmii and 10gkr modes to the phy_mode enum
From: Kishon Vijay Abraham I @ 2017-08-29 10:38 UTC (permalink / raw)
To: Antoine Tenart, davem, andrew, jason, sebastian.hesselbarth,
gregory.clement
Cc: thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170828145725.2539-2-antoine.tenart@free-electrons.com>
On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> This patch adds more generic PHY modes to the phy_mode enum, to
> allow configuring generic PHYs to the SGMII and/or the 10GKR mode
> by using the set_mode callback.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> include/linux/phy/phy.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 78bb0d7f6b11..e694d4008c4a 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -27,6 +27,8 @@ enum phy_mode {
> PHY_MODE_USB_HOST,
> PHY_MODE_USB_DEVICE,
> PHY_MODE_USB_OTG,
> + PHY_MODE_SGMII,
> + PHY_MODE_10GKR,
> };
>
> /**
>
^ permalink raw reply
* [PATCH 7/7] xfrm_user: fix info leak in build_aevent()
From: Steffen Klassert @ 2017-08-29 10:31 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1504002694-1931-1-git-send-email-steffen.klassert@secunet.com>
From: Mathias Krause <minipli@googlemail.com>
The memory reserved to dump the ID of the xfrm state includes a padding
byte in struct xfrm_usersa_id added by the compiler for alignment. To
prevent the heap info leak, memset(0) the sa_id before filling it.
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Fixes: d51d081d6504 ("[IPSEC]: Sync series - user")
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 2cbdc81..9391ced 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1869,6 +1869,7 @@ static int build_aevent(struct sk_buff *skb, struct xfrm_state *x, const struct
return -EMSGSIZE;
id = nlmsg_data(nlh);
+ memset(&id->sa_id, 0, sizeof(id->sa_id));
memcpy(&id->sa_id.daddr, &x->id.daddr, sizeof(x->id.daddr));
id->sa_id.spi = x->id.spi;
id->sa_id.family = x->props.family;
--
2.7.4
^ permalink raw reply related
* [PATCH 5/7] xfrm_user: fix info leak in xfrm_notify_sa()
From: Steffen Klassert @ 2017-08-29 10:31 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1504002694-1931-1-git-send-email-steffen.klassert@secunet.com>
From: Mathias Krause <minipli@googlemail.com>
The memory reserved to dump the ID of the xfrm state includes a padding
byte in struct xfrm_usersa_id added by the compiler for alignment. To
prevent the heap info leak, memset(0) the whole struct before filling
it.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Fixes: 0603eac0d6b7 ("[IPSEC]: Add XFRMA_SA/XFRMA_POLICY for delete notification")
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 3259555..c33516e 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2715,6 +2715,7 @@ static int xfrm_notify_sa(struct xfrm_state *x, const struct km_event *c)
struct nlattr *attr;
id = nlmsg_data(nlh);
+ memset(id, 0, sizeof(*id));
memcpy(&id->daddr, &x->id.daddr, sizeof(id->daddr));
id->spi = x->id.spi;
id->family = x->props.family;
--
2.7.4
^ permalink raw reply related
* [PATCH 6/7] xfrm_user: fix info leak in build_expire()
From: Steffen Klassert @ 2017-08-29 10:31 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1504002694-1931-1-git-send-email-steffen.klassert@secunet.com>
From: Mathias Krause <minipli@googlemail.com>
The memory reserved to dump the expired xfrm state includes padding
bytes in struct xfrm_user_expire added by the compiler for alignment. To
prevent the heap info leak, memset(0) the remainder of the struct.
Initializing the whole structure isn't needed as copy_to_user_state()
already takes care of clearing the padding bytes within the 'state'
member.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_user.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index c33516e..2cbdc81 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2578,6 +2578,8 @@ static int build_expire(struct sk_buff *skb, struct xfrm_state *x, const struct
ue = nlmsg_data(nlh);
copy_to_user_state(x, &ue->state);
ue->hard = (c->data.hard != 0) ? 1 : 0;
+ /* clear the padding bytes */
+ memset(&ue->hard + 1, 0, sizeof(*ue) - offsetofend(typeof(*ue), hard));
err = xfrm_mark_put(skb, &x->mark);
if (err)
--
2.7.4
^ permalink raw reply related
* [PATCH 2/7] esp: Fix locking on page fragment allocation
From: Steffen Klassert @ 2017-08-29 10:31 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1504002694-1931-1-git-send-email-steffen.klassert@secunet.com>
We allocate the page fragment for the ESP trailer inside
a spinlock, but consume it outside of the lock. This
is racy as some other cou could get the same page fragment
then. Fix this by consuming the page fragment inside the
lock too.
Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible")
Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible")
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/esp4.c | 5 +++--
net/ipv6/esp6.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index dbb31a9..a8ddb95 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -292,8 +292,6 @@ int esp_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info *
kunmap_atomic(vaddr);
- spin_unlock_bh(&x->lock);
-
nfrags = skb_shinfo(skb)->nr_frags;
__skb_fill_page_desc(skb, nfrags, page, pfrag->offset,
@@ -301,6 +299,9 @@ int esp_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info *
skb_shinfo(skb)->nr_frags = ++nfrags;
pfrag->offset = pfrag->offset + allocsize;
+
+ spin_unlock_bh(&x->lock);
+
nfrags++;
skb->len += tailen;
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 392def1..4e3fdc88 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -260,8 +260,6 @@ int esp6_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info
kunmap_atomic(vaddr);
- spin_unlock_bh(&x->lock);
-
nfrags = skb_shinfo(skb)->nr_frags;
__skb_fill_page_desc(skb, nfrags, page, pfrag->offset,
@@ -269,6 +267,9 @@ int esp6_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info
skb_shinfo(skb)->nr_frags = ++nfrags;
pfrag->offset = pfrag->offset + allocsize;
+
+ spin_unlock_bh(&x->lock);
+
nfrags++;
skb->len += tailen;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/7] xfrm_user: fix info leak in copy_user_offload()
From: Steffen Klassert @ 2017-08-29 10:31 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1504002694-1931-1-git-send-email-steffen.klassert@secunet.com>
From: Mathias Krause <minipli@googlemail.com>
The memory reserved to dump the xfrm offload state includes padding
bytes of struct xfrm_user_offload added by the compiler for alignment.
Add an explicit memset(0) before filling the buffer to avoid the heap
info leak.
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API")
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_user.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 2be4c6a..3259555 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -796,7 +796,7 @@ static int copy_user_offload(struct xfrm_state_offload *xso, struct sk_buff *skb
return -EMSGSIZE;
xuo = nla_data(attr);
-
+ memset(xuo, 0, sizeof(*xuo));
xuo->ifindex = xso->dev->ifindex;
xuo->flags = xso->flags;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/7] esp: Fix skb tailroom calculation
From: Steffen Klassert @ 2017-08-29 10:31 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1504002694-1931-1-git-send-email-steffen.klassert@secunet.com>
We use skb_availroom to calculate the skb tailroom for the
ESP trailer. skb_availroom calculates the tailroom and
subtracts this value by reserved_tailroom. However
reserved_tailroom is a union with the skb mark. This means
that we subtract the tailroom by the skb mark if set.
Fix this by using skb_tailroom instead.
Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible")
Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible")
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/esp4.c | 2 +-
net/ipv6/esp6.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index a8ddb95..df68963 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -258,7 +258,7 @@ int esp_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info *
esp_output_udp_encap(x, skb, esp);
if (!skb_cloned(skb)) {
- if (tailen <= skb_availroom(skb)) {
+ if (tailen <= skb_tailroom(skb)) {
nfrags = 1;
trailer = skb;
tail = skb_tail_pointer(trailer);
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 4e3fdc88..ab64f36 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -226,7 +226,7 @@ int esp6_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info
int tailen = esp->tailen;
if (!skb_cloned(skb)) {
- if (tailen <= skb_availroom(skb)) {
+ if (tailen <= skb_tailroom(skb)) {
nfrags = 1;
trailer = skb;
tail = skb_tail_pointer(trailer);
--
2.7.4
^ permalink raw reply related
* pull request (net): ipsec 2017-08-29
From: Steffen Klassert @ 2017-08-29 10:31 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
1) Fix dst_entry refcount imbalance when using socket policies.
From Lorenzo Colitti.
2) Fix locking when adding the ESP trailers.
3) Fix tailroom calculation for the ESP trailer by using
skb_tailroom instead of skb_availroom.
4) Fix some info leaks in xfrm_user.
From Mathias Krause.
Please pull or let me know if there are problems.
Thanks!
The following changes since commit 2b33bc8aa236b75d6e86a8a79126fd9739e4a5bd:
net: dsa: use consume_skb() (2017-08-23 22:13:34 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git master
for you to fetch changes up to 931e79d7a7ddee4709c56b39de169a36804589a1:
xfrm_user: fix info leak in build_aevent() (2017-08-28 10:58:02 +0200)
----------------------------------------------------------------
Lorenzo Colitti (1):
net: xfrm: don't double-hold dst when sk_policy in use.
Mathias Krause (4):
xfrm_user: fix info leak in copy_user_offload()
xfrm_user: fix info leak in xfrm_notify_sa()
xfrm_user: fix info leak in build_expire()
xfrm_user: fix info leak in build_aevent()
Steffen Klassert (2):
esp: Fix locking on page fragment allocation
esp: Fix skb tailroom calculation
net/ipv4/esp4.c | 7 ++++---
net/ipv6/esp6.c | 7 ++++---
net/xfrm/xfrm_policy.c | 1 -
net/xfrm/xfrm_user.c | 6 +++++-
4 files changed, 13 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH 1/7] net: xfrm: don't double-hold dst when sk_policy in use.
From: Steffen Klassert @ 2017-08-29 10:31 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1504002694-1931-1-git-send-email-steffen.klassert@secunet.com>
From: Lorenzo Colitti <lorenzo@google.com>
While removing dst_entry garbage collection, commit 52df157f17e5
("xfrm: take refcnt of dst when creating struct xfrm_dst bundle")
changed xfrm_resolve_and_create_bundle so it returns an xdst with
a refcount of 1 instead of 0.
However, it did not delete the dst_hold performed by xfrm_lookup
when a per-socket policy is in use. This means that when a
socket policy is in use, dst entries returned by xfrm_lookup have
a refcount of 2, and are not freed when no longer in use.
Cc: Wei Wang <weiwan@google.com>
Fixes: 52df157f17 ("xfrm: take refcnt of dst when creating struct xfrm_dst bundle")
Tested: https://android-review.googlesource.com/417481
Tested: https://android-review.googlesource.com/418659
Tested: https://android-review.googlesource.com/424463
Tested: https://android-review.googlesource.com/452776 passes on net-next
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Acked-by: Wei Wang <weiwan@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_policy.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 6f5a0dad..69b16ee 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2226,7 +2226,6 @@ struct dst_entry *xfrm_lookup(struct net *net, struct dst_entry *dst_orig,
goto no_transform;
}
- dst_hold(&xdst->u.dst);
route = xdst->route;
}
}
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox