* [PATCH 1/3] net: ethernet: sunxi: Add new compatibles
From: Maxime Ripard @ 2014-02-02 13:49 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-arm-kernel, Maxime Ripard
The Allwinner A10 compatibles were following a slightly different compatible
patterns than the rest of the SoCs for historical reasons. Add compatibles
matching the other pattern to the ethernet driver for consistency, and keep the
older one for backward compatibility.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt | 5 +++--
drivers/net/ethernet/allwinner/sun4i-emac.c | 3 +++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
index b90bfcd..863d5b81 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
@@ -1,7 +1,8 @@
* Allwinner EMAC ethernet controller
Required properties:
-- compatible: should be "allwinner,sun4i-emac".
+- compatible: should be "allwinner,sun4i-a10-emac" (Deprecated:
+ "allwinner,sun4i-emac")
- reg: address and length of the register set for the device.
- interrupts: interrupt for the device
- phy: A phandle to a phy node defining the PHY address (as the reg
@@ -14,7 +15,7 @@ Optional properties:
Example:
emac: ethernet@01c0b000 {
- compatible = "allwinner,sun4i-emac";
+ compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
interrupts = <55>;
clocks = <&ahb_gates 17>;
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c b/drivers/net/ethernet/allwinner/sun4i-emac.c
index 46dfb13..6673106 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -930,6 +930,9 @@ static int emac_resume(struct platform_device *dev)
}
static const struct of_device_id emac_of_match[] = {
+ {.compatible = "allwinner,sun4i-a10-emac",},
+
+ /* Deprecated */
{.compatible = "allwinner,sun4i-emac",},
{},
};
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union
From: Dan Carpenter @ 2014-02-03 8:58 UTC (permalink / raw)
To: Chen Gang
Cc: devel, James Hogan, andreas.dilger, jinshan.xiong, Greg KH,
bergwolf, linux-kernel@vger.kernel.org, linux-metag, oleg.drokin,
jacques-charles.lafoucriere, Antonio Quartulli, netdev,
David Miller
In-Reply-To: <52ECFD53.7010401@gmail.com>
On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
> It seems, our kernel still stick to treate 'pack' region have effect
> with both 'align' and 'sizeof'.
>
It's not about packed regions. It's about unions. It's saying the
sizeof() a union is a multiple of 4 unless it's packed.
union foo {
short x;
short y;
};
The author intended the sizeof(union foo) to be 2 but on metag arch then
it is 4.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] staging: r8188eu: Fix typo in USB_DEVICE list
From: Dan Carpenter @ 2014-02-03 9:17 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, gregkh, netdev
In-Reply-To: <1391371626-13551-1-git-send-email-Larry.Finger@lwfinger.net>
On Sun, Feb 02, 2014 at 02:07:06PM -0600, Larry Finger wrote:
> There is a typo in the device list that interchanges the vendor and
> product codes for one of the entries.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> index 0a341d6..e9e3c76 100644
> --- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> +++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> @@ -53,7 +53,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
> {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x0179)}, /* 8188ETV */
> /*=== Customer ID ===*/
> /****** 8188EUS ********/
> - {USB_DEVICE(0x8179, 0x07B8)}, /* Abocom - Abocom */
> + {USB_DEVICE(0x07bb, 0x8179)}, /* Abocom - Abocom */
^^^^^^
Should this be 0x07b8?
regards,
dan carpenter
> {USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
> {} /* Terminating entry */
> };
> --
> 1.8.4
>
> _______________________________________________
> devel mailing list
> devel@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* RE: [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned
From: David Laight @ 2014-02-03 9:54 UTC (permalink / raw)
To: 'Mark Lord', Ming Lei
Cc: Sarah Sharp, Bjørn Mork,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Greg Kroah-Hartman, David Miller, Dan Williams, Nyman, Mathias,
Alan Stern, Freddy Xin
In-Reply-To: <52ED5381.2010106-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1359 bytes --]
From: Mark Lord
> On 14-02-01 09:18 AM, Ming Lei wrote:
> >
> > Even real regressions are easily/often introduced, and we are discussing
> > how to fix that. I suggest to unset the flag only for the known buggy
> > controllers.
>
> It is not the controllers that are particularly "buggy" here.
> But rather the drivers and design of parts of the kernel.
I suspect that the documentation is describing the actual implementation
of a specific hardware implementation, not necessarily how the hardware was
intended to behave.
The requirement for two 32bit accesses to a 64bit register is very similar.
This also means that implementations of the hardware that claim conformance
to the 0.96 specification might have similar issues.
Given the small number of xhci controllers and the even smaller number of
VHDL (or similar) sources they will be based on, it really ought to be
possible to tabulate the controller versions and families to get a much
better idea of their behaviour.
I've got two systems with Intel USB3 controllers, linux reports one as
'panther point', the other as '7 Series/C210 Series' (seems to be a Xeon
chipset). I've no idea how the latter relates to the former.
David
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±ºÆâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br šê+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹\x1e®w¥¢¸?™¨èÚ&¢)ߢ^[f
^ permalink raw reply
* Re: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union
From: Chen Gang @ 2014-02-03 10:03 UTC (permalink / raw)
To: Dan Carpenter
Cc: devel, James Hogan, andreas.dilger, jinshan.xiong, Greg KH,
bergwolf, linux-kernel@vger.kernel.org, linux-metag, oleg.drokin,
jacques-charles.lafoucriere, Antonio Quartulli, netdev,
David Miller
In-Reply-To: <20140203085855.GA26722@mwanda>
On 02/03/2014 04:58 PM, Dan Carpenter wrote:
> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
>> It seems, our kernel still stick to treate 'pack' region have effect
>> with both 'align' and 'sizeof'.
>>
>
> It's not about packed regions. It's about unions. It's saying the
> sizeof() a union is a multiple of 4 unless it's packed.
>
> union foo {
> short x;
> short y;
> };
>
> The author intended the sizeof(union foo) to be 2 but on metag arch then
> it is 4.
>
Yeah, just like your original discussion. :-)
Hmm... can we say: "for metag compiler, in a pack region, it considers
variables alignment, but does not consider about struct/union alignment
(except append packed to each related struct/union)".
For compatible (consider about its ABI), it has to keep this features,
but for kernel, it needs be changed.
So, I suggest to add one parameter to compiler to switch this feature,
and append this parameter to KBUILD_CFLAGS in "arch/metag/Makefile"
which can satisfy both ABI and kernel.
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
^ permalink raw reply
* RE: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union
From: David Laight @ 2014-02-03 10:05 UTC (permalink / raw)
To: 'Dan Carpenter', Chen Gang
Cc: James Hogan, devel@driverdev.osuosl.org, andreas.dilger@intel.com,
Antonio Quartulli, Greg KH, bergwolf@gmail.com,
linux-kernel@vger.kernel.org, David Miller, oleg.drokin@intel.com,
jacques-charles.lafoucriere@cea.fr, jinshan.xiong@intel.com,
netdev, linux-metag@vger.kernel.org
In-Reply-To: <20140203085855.GA26722@mwanda>
From: Dan Carpenter
> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
> > It seems, our kernel still stick to treate 'pack' region have effect
> > with both 'align' and 'sizeof'.
>
> It's not about packed regions. It's about unions. It's saying the
> sizeof() a union is a multiple of 4 unless it's packed.
>
> union foo {
> short x;
> short y;
> };
>
> The author intended the sizeof(union foo) to be 2 but on metag arch then
> it is 4.
The same is probably be true of: struct foo { _u16 bar; };
Architectures that define such alignment rules are a right PITA.
You either need to get the size to 2 without using 'packed', or
just not define such structures.
It is worth seeing if adding aligned(2) will change the size - I'm
not sure.
David
^ permalink raw reply
* Re: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union
From: James Hogan @ 2014-02-03 10:22 UTC (permalink / raw)
To: David Laight
Cc: devel@driverdev.osuosl.org, andreas.dilger@intel.com, Chen Gang,
Greg KH, bergwolf@gmail.com, linux-kernel@vger.kernel.org,
linux-metag@vger.kernel.org, oleg.drokin@intel.com,
jacques-charles.lafoucriere@cea.fr, Antonio Quartulli, netdev,
jinshan.xiong@intel.com, David Miller, 'Dan Carpenter'
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6B772B@AcuExch.aculab.com>
On 03/02/14 10:05, David Laight wrote:
> From: Dan Carpenter
>> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
>>> It seems, our kernel still stick to treate 'pack' region have effect
>>> with both 'align' and 'sizeof'.
>>
>> It's not about packed regions. It's about unions. It's saying the
>> sizeof() a union is a multiple of 4 unless it's packed.
>>
>> union foo {
>> short x;
>> short y;
>> };
>>
>> The author intended the sizeof(union foo) to be 2 but on metag arch then
>> it is 4.
>
> The same is probably be true of: struct foo { _u16 bar; };
Yes indeed.
> Architectures that define such alignment rules are a right PITA.
> You either need to get the size to 2 without using 'packed', or
> just not define such structures.
> It is worth seeing if adding aligned(2) will change the size - I'm
> not sure.
__aligned(2) alone doesn't seem to have any effect on sizeof() or
__alignof__() unless it is accompanied by __packed. x86_64 is similar in
that respect (it just packs sanely in the first place).
Combining __packed with __aligned(2) does the trick though (__packed
alone sets __aligned(1) which is obviously going to be suboptimal).
Cheers
James
^ permalink raw reply
* Re: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union
From: Chen Gang @ 2014-02-03 10:25 UTC (permalink / raw)
To: David Laight
Cc: 'Dan Carpenter', James Hogan,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org,
andreas.dilger-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Antonio Quartulli, Greg KH,
bergwolf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Miller, oleg.drokin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
jacques-charles.lafoucriere-KCE40YydGKI@public.gmane.org,
jinshan.xiong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, netdev,
linux-metag-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6B772B-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
On 02/03/2014 06:05 PM, David Laight wrote:
> From: Dan Carpenter
>> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
>>> It seems, our kernel still stick to treate 'pack' region have effect
>>> with both 'align' and 'sizeof'.
>>
>> It's not about packed regions. It's about unions. It's saying the
>> sizeof() a union is a multiple of 4 unless it's packed.
>>
>> union foo {
>> short x;
>> short y;
>> };
>>
>> The author intended the sizeof(union foo) to be 2 but on metag arch then
>> it is 4.
>
> The same is probably be true of: struct foo { _u16 bar; };
>
I guess so.
> Architectures that define such alignment rules are a right PITA.
Sorry, I do not know about PITA (after google or wiki, I can not get
more related information).
Could you provide more information about PITA, thanks?
> You either need to get the size to 2 without using 'packed', or
> just not define such structures.
Excuse me, I don't quite understand your meaning. I guess your meaning
is:
"normally, we should not use a struct/union like that, no matter what it is (2 or 4)".
Is it correct.
> It is worth seeing if adding aligned(2) will change the size - I'm
> not sure.
>
Yes, it will/should make sure that it must be 2.
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union
From: Chen Gang @ 2014-02-03 10:30 UTC (permalink / raw)
To: James Hogan
Cc: devel@driverdev.osuosl.org, andreas.dilger@intel.com,
jinshan.xiong@intel.com, Greg KH, bergwolf@gmail.com,
linux-kernel@vger.kernel.org, linux-metag@vger.kernel.org,
oleg.drokin@intel.com, David Laight,
jacques-charles.lafoucriere@cea.fr, Antonio Quartulli, netdev,
David Miller, 'Dan Carpenter'
In-Reply-To: <52EF6DCC.6040807@imgtec.com>
On 02/03/2014 06:22 PM, James Hogan wrote:
> On 03/02/14 10:05, David Laight wrote:
>> From: Dan Carpenter
>>> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
>>>> It seems, our kernel still stick to treate 'pack' region have effect
>>>> with both 'align' and 'sizeof'.
>>>
>>> It's not about packed regions. It's about unions. It's saying the
>>> sizeof() a union is a multiple of 4 unless it's packed.
>>>
>>> union foo {
>>> short x;
>>> short y;
>>> };
>>>
>>> The author intended the sizeof(union foo) to be 2 but on metag arch then
>>> it is 4.
>>
>> The same is probably be true of: struct foo { _u16 bar; };
>
> Yes indeed.
>
>> Architectures that define such alignment rules are a right PITA.
>> You either need to get the size to 2 without using 'packed', or
>> just not define such structures.
>> It is worth seeing if adding aligned(2) will change the size - I'm
>> not sure.
>
> __aligned(2) alone doesn't seem to have any effect on sizeof() or
> __alignof__() unless it is accompanied by __packed. x86_64 is similar in
> that respect (it just packs sanely in the first place).
>
> Combining __packed with __aligned(2) does the trick though (__packed
> alone sets __aligned(1) which is obviously going to be suboptimal).
>
Oh, thank you for your explanation.
And hope this feature issue can be fixed, and satisfy both kernel and
ABI. :-)
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
^ permalink raw reply
* RE: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union
From: David Laight @ 2014-02-03 10:35 UTC (permalink / raw)
To: 'James Hogan'
Cc: 'Dan Carpenter', Chen Gang,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org,
andreas.dilger-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Antonio Quartulli, Greg KH,
bergwolf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Miller, oleg.drokin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
jacques-charles.lafoucriere-KCE40YydGKI@public.gmane.org,
jinshan.xiong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, netdev,
linux-metag-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <52EF6DCC.6040807-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
From: James Hogan
> On 03/02/14 10:05, David Laight wrote:
> > From: Dan Carpenter
> >> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
> >>> It seems, our kernel still stick to treate 'pack' region have effect
> >>> with both 'align' and 'sizeof'.
> >>
> >> It's not about packed regions. It's about unions. It's saying the
> >> sizeof() a union is a multiple of 4 unless it's packed.
> >>
> >> union foo {
> >> short x;
> >> short y;
> >> };
> >>
> >> The author intended the sizeof(union foo) to be 2 but on metag arch then
> >> it is 4.
> >
> > The same is probably be true of: struct foo { _u16 bar; };
>
> Yes indeed.
>
> > Architectures that define such alignment rules are a right PITA.
> > You either need to get the size to 2 without using 'packed', or
> > just not define such structures.
> > It is worth seeing if adding aligned(2) will change the size - I'm
> > not sure.
>
> __aligned(2) alone doesn't seem to have any effect on sizeof() or
> __alignof__() unless it is accompanied by __packed. x86_64 is similar in
> that respect (it just packs sanely in the first place).
>
> Combining __packed with __aligned(2) does the trick though (__packed
> alone sets __aligned(1) which is obviously going to be suboptimal).
Compile some code for a cpu that doesn't support misaligned transfers
(probably one of sparc, arm, ppc) and see if the compiler generates a
single 16bit request or two 8 bits ones.
You don't want the compiler generating multiple byte-sized memory transfers.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Xen-devel] [PATCH v6] xen/grant-table: Avoid m2p_override during mapping
From: David Vrabel @ 2014-02-03 10:57 UTC (permalink / raw)
To: Zoltan Kiss
Cc: Julien Grall, Stefano Stabellini, jonathan.davies, wei.liu2,
ian.campbell, netdev, linux-kernel, David Vrabel, xen-devel
In-Reply-To: <52EE93F0.1020508@citrix.com>
On 02/02/14 18:52, Zoltan Kiss wrote:
> On 02/02/14 11:29, Julien Grall wrote:
>> Hello,
>>
>> This patch is breaking Linux compilation on ARM:
>>
>> drivers/xen/grant-table.c: In function ‘__gnttab_map_refs’:
>> drivers/xen/grant-table.c:989:3: error: implicit declaration of
>> function ‘FOREIGN_FRAME’ [-Werror=implicit-function-declaration]
>> if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) {
>> ^
>> drivers/xen/grant-table.c: In function ‘__gnttab_unmap_refs’:
>> drivers/xen/grant-table.c:1054:3: error: implicit declaration of
>> function ‘get_phys_to_machine’ [-Werror=implicit-function-declaration]
>> mfn = get_phys_to_machine(pfn);
>> ^
>> drivers/xen/grant-table.c:1055:43: error: ‘FOREIGN_FRAME_BIT’
>> undeclared (first use in this function)
>> if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
>> ^
>> drivers/xen/grant-table.c:1055:43: note: each undeclared identifier is
>> reported only once for each function it appears in
>> drivers/xen/grant-table.c:1068:9: error: too many arguments to
>> function ‘m2p_remove_override’
>> mfn);
>> ^
>> In file included from include/xen/page.h:4:0,
>> from drivers/xen/grant-table.c:48:
>> /local/home/julien/works/midway/linux/arch/arm/include/asm/xen/page.h:106:19:
>> note: declared here
>> static inline int m2p_remove_override(struct page *page, bool
>> clear_pte)
>> ^
>> cc1: some warnings being treated as errors
>
> Hi,
>
> That's bad indeed. I think the best solution is to put those parts
> behind an #ifdef x86. The ones moved from x86/p2m.c to grant-table.c.
> David, Stefano, what do you think?
I don't think we want (more) #ifdef CONFIG_X86 in grant-table.c and the
arch-specific bits will have to factored out into their own functions
with suitable stubs provided for ARM.
But, this patch went in late and it's clearly not ready. So I think it
should be reverted and we should aim to get it sorted out for 3.15.
Konrad/Stefano (if you agree) please revert
08ece5bb2312b4510b161a6ef6682f37f4eac8a1 and send a pull request.
Konrad, I also think you should look at adding an ARM build to your test
system (I thought you had this already).
David
^ permalink raw reply
* Re: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union
From: James Hogan @ 2014-02-03 11:02 UTC (permalink / raw)
To: David Laight
Cc: devel@driverdev.osuosl.org, andreas.dilger@intel.com, Chen Gang,
Greg KH, bergwolf@gmail.com, linux-kernel@vger.kernel.org,
linux-metag@vger.kernel.org, oleg.drokin@intel.com,
jacques-charles.lafoucriere@cea.fr, Antonio Quartulli, netdev,
jinshan.xiong@intel.com, David Miller, 'Dan Carpenter'
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6B777A@AcuExch.aculab.com>
On 03/02/14 10:35, David Laight wrote:
> From: James Hogan
>> On 03/02/14 10:05, David Laight wrote:
>>> Architectures that define such alignment rules are a right PITA.
>>> You either need to get the size to 2 without using 'packed', or
>>> just not define such structures.
>>> It is worth seeing if adding aligned(2) will change the size - I'm
>>> not sure.
>>
>> __aligned(2) alone doesn't seem to have any effect on sizeof() or
>> __alignof__() unless it is accompanied by __packed. x86_64 is similar in
>> that respect (it just packs sanely in the first place).
>>
>> Combining __packed with __aligned(2) does the trick though (__packed
>> alone sets __aligned(1) which is obviously going to be suboptimal).
>
> Compile some code for a cpu that doesn't support misaligned transfers
> (probably one of sparc, arm, ppc) and see if the compiler generates a
> single 16bit request or two 8 bits ones.
> You don't want the compiler generating multiple byte-sized memory transfers.
Meta is also one of those arches, and according to my quick tests,
__packed alone does correctly make it fall back to byte loads/stores,
but with __packed __aligned(2) it uses 16bit loads/stores. I've also
confirmed that with an ARM toolchain (see below for example).
Cheers
James
input:
#define __aligned(x) __attribute__((aligned(x)))
#define __packed __attribute__((packed))
union a {
short x, y;
} __aligned(2) __packed;
struct b {
short x;
} __aligned(2) __packed;
unsigned int soa = sizeof(union a);
unsigned int aoa = __alignof__(union a);
unsigned int sob = sizeof(struct b);
unsigned int aob = __alignof__(struct b);
void t(struct b *x, union a *y)
{
++x->x;
++y->x;
}
ARM output (-O2):
.cpu arm10tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file "alignment4.c"
.text
.align 2
.global t
.type t, %function
t:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrh r3, [r0, #0]
add r3, r3, #1
strh r3, [r0, #0] @ movhi
ldrh r3, [r1, #0]
add r3, r3, #1
strh r3, [r1, #0] @ movhi
bx lr
.size t, .-t
.global aob
.global sob
.global aoa
.global soa
.data
.align 2
.type aob, %object
.size aob, 4
aob:
.word 2
.type sob, %object
.size sob, 4
sob:
.word 2
.type aoa, %object
.size aoa, 4
aoa:
.word 2
.type soa, %object
.size soa, 4
soa:
.word 2
.ident "GCC: (GNU) 4.7.1 20120606 (Red Hat 4.7.1-0.1.20120606)"
.section .note.GNU-stack,"",%progbits
^ permalink raw reply
* Re: [Xen-devel] [PATCH v6] xen/grant-table: Avoid m2p_override during mapping
From: Stefano Stabellini @ 2014-02-03 11:13 UTC (permalink / raw)
To: David Vrabel
Cc: Zoltan Kiss, Julien Grall, Stefano Stabellini, jonathan.davies,
wei.liu2, ian.campbell, netdev, linux-kernel, xen-devel
In-Reply-To: <52EF7618.7030402@citrix.com>
[-- Attachment #1: Type: text/plain, Size: 2936 bytes --]
On Mon, 3 Feb 2014, David Vrabel wrote:
> On 02/02/14 18:52, Zoltan Kiss wrote:
> > On 02/02/14 11:29, Julien Grall wrote:
> >> Hello,
> >>
> >> This patch is breaking Linux compilation on ARM:
> >>
> >> drivers/xen/grant-table.c: In function ‘__gnttab_map_refs’:
> >> drivers/xen/grant-table.c:989:3: error: implicit declaration of
> >> function ‘FOREIGN_FRAME’ [-Werror=implicit-function-declaration]
> >> if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) {
> >> ^
> >> drivers/xen/grant-table.c: In function ‘__gnttab_unmap_refs’:
> >> drivers/xen/grant-table.c:1054:3: error: implicit declaration of
> >> function ‘get_phys_to_machine’ [-Werror=implicit-function-declaration]
> >> mfn = get_phys_to_machine(pfn);
> >> ^
> >> drivers/xen/grant-table.c:1055:43: error: ‘FOREIGN_FRAME_BIT’
> >> undeclared (first use in this function)
> >> if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
> >> ^
> >> drivers/xen/grant-table.c:1055:43: note: each undeclared identifier is
> >> reported only once for each function it appears in
> >> drivers/xen/grant-table.c:1068:9: error: too many arguments to
> >> function ‘m2p_remove_override’
> >> mfn);
> >> ^
> >> In file included from include/xen/page.h:4:0,
> >> from drivers/xen/grant-table.c:48:
> >> /local/home/julien/works/midway/linux/arch/arm/include/asm/xen/page.h:106:19:
> >> note: declared here
> >> static inline int m2p_remove_override(struct page *page, bool
> >> clear_pte)
> >> ^
> >> cc1: some warnings being treated as errors
> >
> > Hi,
> >
> > That's bad indeed. I think the best solution is to put those parts
> > behind an #ifdef x86. The ones moved from x86/p2m.c to grant-table.c.
> > David, Stefano, what do you think?
>
> I don't think we want (more) #ifdef CONFIG_X86 in grant-table.c and the
> arch-specific bits will have to factored out into their own functions
> with suitable stubs provided for ARM.
We certainly don't want more ifdefs like that.
> But, this patch went in late and it's clearly not ready. So I think it
> should be reverted and we should aim to get it sorted out for 3.15.
>
> Konrad/Stefano (if you agree) please revert
> 08ece5bb2312b4510b161a6ef6682f37f4eac8a1 and send a pull request.
Unfortunately I have to agree: fixing the prototype of
m2p_remove_override and replacing get_phys_to_machine with pfn_to_mfn is
easy.
However FOREIGN_FRAME is an x86-ism and I don't feel confortable with
adding yet another #define under arch/arm/xen just to deal with x86
stuff that spill on common code.
Sorry for not spotting this earlier.
> Konrad, I also think you should look at adding an ARM build to your test
> system (I thought you had this already).
Let's talk about how to set it up offline.
^ permalink raw reply
* Bug in IPv4 version of ping...
From: Vic @ 2014-02-03 10:31 UTC (permalink / raw)
To: netdev
Hi All.
I hope this is the right place to post this - this list is mentioned as
the mailing list for iputils.
I believe I've found a bug in ping.c - there is an ancient work-around for
an IP_RECVERR bug in raw sockets. The problem is as follows :-
ping_common.c defines a variable working_recverr
ping.c uses this variable to work out what it should do under certain
failure circumstances.
As far as I can see, working_recverr is undefined when first used; the
initial response to it could be either way. This leads to an erroneous
report that the kernel is "not very fresh", and needs to be upgraded.
I have seen this in the current builds for RHEL5 and 6 (s20071127) and in
the current release (s20121221).
I suspect this variable should be set somewhere after option parsing...
HTH
Vic.
^ permalink raw reply
* Re: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union
From: Chen Gang @ 2014-02-03 11:35 UTC (permalink / raw)
To: Dan Carpenter
Cc: James Hogan, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
andreas.dilger-ral2JQCrhuEAvxtiuMwx3w, Antonio Quartulli, Greg KH,
bergwolf-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Miller, oleg.drokin-ral2JQCrhuEAvxtiuMwx3w,
jacques-charles.lafoucriere-KCE40YydGKI,
jinshan.xiong-ral2JQCrhuEAvxtiuMwx3w, netdev,
linux-metag-u79uwXL29TY76Z2rM5mHXA, David Laight
In-Reply-To: <52EF6965.6040406-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 02/03/2014 06:03 PM, Chen Gang wrote:
> On 02/03/2014 04:58 PM, Dan Carpenter wrote:
>> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
>>> It seems, our kernel still stick to treate 'pack' region have effect
>>> with both 'align' and 'sizeof'.
>>>
>>
>> It's not about packed regions. It's about unions. It's saying the
>> sizeof() a union is a multiple of 4 unless it's packed.
>>
>> union foo {
>> short x;
>> short y;
>> };
>>
>> The author intended the sizeof(union foo) to be 2 but on metag arch then
>> it is 4.
>>
>
> Yeah, just like your original discussion. :-)
>
>
> Hmm... can we say: "for metag compiler, in a pack region, it considers
> variables alignment, but does not consider about struct/union alignment
> (except append packed to each related struct/union)".
>
> For compatible (consider about its ABI), it has to keep this features,
> but for kernel, it needs be changed.
>
> So, I suggest to add one parameter to compiler to switch this feature,
> and append this parameter to KBUILD_CFLAGS in "arch/metag/Makefile"
> which can satisfy both ABI and kernel.
>
After append the parameter to KBUILD_CFLAGS in "arch/metag/Makefile",
- I guess/assume "include/uapi/*" should/will not need be modified.
- but need check all files in "arch/metag/include/uapi/*".
(add padding data for packed struct/union when __KERNEL__ defined)
- maybe we have to process metag related ABI which not in "*/uapi/*"
(add padding data for packed struct/union when __KERNEL__ defined)
and when we find them, recommend to move all of them to "*/uapi/*".
Sorry, I don't know whether this way is the best way or not, but for me
it is an executable way to solve this feature issue and satisfy both
kernel and ABI.
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Xen-devel] [PATCH v6] xen/grant-table: Avoid m2p_override during mapping
From: Konrad Rzeszutek Wilk @ 2014-02-03 11:50 UTC (permalink / raw)
To: David Vrabel
Cc: Zoltan Kiss, jonathan.davies, wei.liu2, ian.campbell,
Stefano Stabellini, netdev, Julien Grall, linux-kernel, xen-devel
In-Reply-To: <52EF7618.7030402@citrix.com>
On Mon, Feb 03, 2014 at 10:57:28AM +0000, David Vrabel wrote:
> On 02/02/14 18:52, Zoltan Kiss wrote:
> > On 02/02/14 11:29, Julien Grall wrote:
> >> Hello,
> >>
> >> This patch is breaking Linux compilation on ARM:
> >>
> >> drivers/xen/grant-table.c: In function ‘__gnttab_map_refs’:
> >> drivers/xen/grant-table.c:989:3: error: implicit declaration of
> >> function ‘FOREIGN_FRAME’ [-Werror=implicit-function-declaration]
> >> if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) {
> >> ^
> >> drivers/xen/grant-table.c: In function ‘__gnttab_unmap_refs’:
> >> drivers/xen/grant-table.c:1054:3: error: implicit declaration of
> >> function ‘get_phys_to_machine’ [-Werror=implicit-function-declaration]
> >> mfn = get_phys_to_machine(pfn);
> >> ^
> >> drivers/xen/grant-table.c:1055:43: error: ‘FOREIGN_FRAME_BIT’
> >> undeclared (first use in this function)
> >> if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
> >> ^
> >> drivers/xen/grant-table.c:1055:43: note: each undeclared identifier is
> >> reported only once for each function it appears in
> >> drivers/xen/grant-table.c:1068:9: error: too many arguments to
> >> function ‘m2p_remove_override’
> >> mfn);
> >> ^
> >> In file included from include/xen/page.h:4:0,
> >> from drivers/xen/grant-table.c:48:
> >> /local/home/julien/works/midway/linux/arch/arm/include/asm/xen/page.h:106:19:
> >> note: declared here
> >> static inline int m2p_remove_override(struct page *page, bool
> >> clear_pte)
> >> ^
> >> cc1: some warnings being treated as errors
> >
> > Hi,
> >
> > That's bad indeed. I think the best solution is to put those parts
> > behind an #ifdef x86. The ones moved from x86/p2m.c to grant-table.c.
> > David, Stefano, what do you think?
>
> I don't think we want (more) #ifdef CONFIG_X86 in grant-table.c and the
> arch-specific bits will have to factored out into their own functions
> with suitable stubs provided for ARM.
>
> But, this patch went in late and it's clearly not ready. So I think it
> should be reverted and we should aim to get it sorted out for 3.15.
>
> Konrad/Stefano (if you agree) please revert
> 08ece5bb2312b4510b161a6ef6682f37f4eac8a1 and send a pull request.
OK, queued up. I also put on the xen/cr4 patch on the queue - just sent
an email with it.
>
> Konrad, I also think you should look at adding an ARM build to your test
> system (I thought you had this already).
>
> David
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply
* RE: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union
From: David Laight @ 2014-02-03 11:54 UTC (permalink / raw)
To: 'James Hogan'
Cc: devel@driverdev.osuosl.org, andreas.dilger@intel.com, Chen Gang,
Greg KH, bergwolf@gmail.com, linux-kernel@vger.kernel.org,
linux-metag@vger.kernel.org, oleg.drokin@intel.com,
jacques-charles.lafoucriere@cea.fr, Antonio Quartulli, netdev,
jinshan.xiong@intel.com, David Miller, 'Dan Carpenter'
In-Reply-To: <52EF7762.2060809@imgtec.com>
From: James Hogan
> On 03/02/14 10:35, David Laight wrote:
> > From: James Hogan
> >> Combining __packed with __aligned(2) does the trick though (__packed
> >> alone sets __aligned(1) which is obviously going to be suboptimal).
...
>
> Meta is also one of those arches, and according to my quick tests,
> __packed alone does correctly make it fall back to byte loads/stores,
> but with __packed __aligned(2) it uses 16bit loads/stores. I've also
> confirmed that with an ARM toolchain (see below for example).
I would either:
1a) Add explicit padding to the relevant structures so that they are
multiple of 4 bytes.
or:
1b) #define some token to "__packed __aligned(2)" before all the structures
that require changing, and use that in there definitions.
This lets you comment on WHY you are doing it.
and:
2) Add a compile-time assert that the structures are the correct size.
Clearly you don't want to mark anything that contains a 32bit value
with __packed __aligned(2).
I'm not at all clear whether you are sometimes using a different compiler.
David
^ permalink raw reply
* [PATCH v1 0/3] net: stmmac: Add STi GMAC ethernet
From: srinivas.kandagatla @ 2014-02-03 11:59 UTC (permalink / raw)
To: netdev
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, Srinivas Kandagatla, linux-doc, linux-kernel,
Stuart Menefy, Rob Herring, Rob Landley, Kumar Gala,
Giuseppe Cavallaro, davem, linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Hi All,
This patch series adds Ethernet support to STi series SOCs STiH415 and STiH416.
STi SOC series integrates dwmac IP from synopsis, however there is a hardware
glue on top of this standard IP, this glue needs to configured before the
actual dwmac can be used. Also the glue logic needs re-configuring when the
link speed changes, This is because the clk source can change as the link
speed.
This patch just adds STi specific callbacks into of_data for configuring the
glue layer.
I have rebased my original patches (http://lkml.org/lkml/2013/11/12/243)
to latest stmmac which updates callbacks to suit glue drivers like this.
These patches are tested on b2000 and B2020 with STiH415 and STiH416.
Thanks,
srini
Srinivas Kandagatla (3):
net: stmmac:sti: Add STi SOC glue driver.
ARM: STi: Add STiH415 ethernet support.
ARM: STi: Add STiH416 ethernet support.
.../devicetree/bindings/net/sti-dwmac.txt | 58 ++++
arch/arm/boot/dts/stih415-clock.dtsi | 14 +
arch/arm/boot/dts/stih415-pinctrl.dtsi | 121 +++++++
arch/arm/boot/dts/stih415.dtsi | 48 +++
arch/arm/boot/dts/stih416-clock.dtsi | 14 +
arch/arm/boot/dts/stih416-pinctrl.dtsi | 109 +++++++
arch/arm/boot/dts/stih416.dtsi | 44 +++
arch/arm/boot/dts/stih41x-b2000.dtsi | 22 ++
arch/arm/boot/dts/stih41x-b2020.dtsi | 26 ++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 331 ++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 +
14 files changed, 807 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/sti-dwmac.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
--
1.7.9.5
^ permalink raw reply
* [PATCH v1 1/3] net: stmmac:sti: Add STi SOC glue driver.
From: srinivas.kandagatla @ 2014-02-03 12:01 UTC (permalink / raw)
To: netdev
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, Srinivas Kandagatla, linux-doc, linux-kernel,
Stuart Menefy, Rob Herring, Rob Landley, Kumar Gala,
Giuseppe Cavallaro, davem, linux-arm-kernel
In-Reply-To: <1391428787-27143-1-git-send-email-srinivas.kandagatla@st.com>
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
STi series SOCs have a glue layer on top of the synopsis gmac IP, this
glue layer needs to be configured before the gmac driver starts using
the IP.
This patch adds a support to this glue layer which is configured via
stmmac setup, init, exit callbacks.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
.../devicetree/bindings/net/sti-dwmac.txt | 58 ++++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 331 ++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 +
6 files changed, 409 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/sti-dwmac.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
diff --git a/Documentation/devicetree/bindings/net/sti-dwmac.txt b/Documentation/devicetree/bindings/net/sti-dwmac.txt
new file mode 100644
index 0000000..3dd3d0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/sti-dwmac.txt
@@ -0,0 +1,58 @@
+STMicroelectronics SoC DWMAC glue layer controller
+
+The device node has following properties.
+
+Required properties:
+ - compatible : Can be "st,stih415-dwmac", "st,stih416-dwmac" or
+ "st,stid127-dwmac".
+ - reg : Offset of the glue configuration register map in system
+ configuration regmap pointed by st,syscon property and size.
+
+ - reg-names : Should be "sti-ethconf".
+
+ - st,syscon : Should be phandle to system configuration node which
+ encompases this glue registers.
+
+ - st,tx-retime-src: On STi Parts for Giga bit speeds, 125Mhz clocks can be
+ wired up in from different sources. One via TXCLK pin and other via CLK_125
+ pin. This wiring is totally board dependent. However the retiming glue
+ logic should be configured accordingly. Possible values for this property
+
+ "txclk" - if 125Mhz clock is wired up via txclk line.
+ "clk_125" - if 125Mhz clock is wired up via clk_125 line.
+
+ This property is only valid for Giga bit setup( GMII, RGMII), and it is
+ un-used for non-giga bit (MII and RMII) setups. Also note that internal
+ clockgen can not generate stable 125Mhz clock.
+
+ - st,ext-phyclk: This boolean property indicates who is generating the clock
+ for tx and rx. This property is only valid for RMII case where the clock can
+ be generated from the MAC or PHY.
+
+ - clock-names: should be "sti-ethclk".
+ - clocks: Should point to ethernet clockgen which can generate phyclk.
+
+
+Example:
+
+ethernet0: dwmac@fe810000 {
+ device_type = "network";
+ compatible = "st,stih416-dwmac", "snps,dwmac", "snps,dwmac-3.710";
+ reg = <0xfe810000 0x8000>, <0x8bc 0x4>;
+ reg-names = "stmmaceth", "sti-ethconf";
+ interrupts = <0 133 0>, <0 134 0>, <0 135 0>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ phy-mode = "mii";
+
+ st,syscon = <&syscfg_rear>;
+
+ snps,pbl = <32>;
+ snps,mixed-burst;
+
+ resets = <&softreset STIH416_ETH0_SOFTRESET>;
+ reset-names = "stmmaceth";
+ pinctrl-0 = <&pinctrl_mii0>;
+ pinctrl-names = "default";
+ clocks = <&CLK_S_GMAC0_PHY>;
+ clock-names = "stmmaceth";
+};
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index e2f202e..f2d7c70 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -37,6 +37,17 @@ config DWMAC_SUNXI
stmmac device driver. This driver is used for A20/A31
GMAC ethernet controller.
+config DWMAC_STI
+ bool "STi GMAC support"
+ depends on STMMAC_PLATFORM && ARCH_STI
+ default y
+ ---help---
+ Support for ethernet controller on STi SOCs.
+
+ This selects STi SoC glue layer support for the stmmac
+ device driver. This driver is used on for the STi series
+ SOCs GMAC ethernet controller.
+
config STMMAC_PCI
bool "STMMAC PCI bus support"
depends on STMMAC_ETH && PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index ecadece..dcef287 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_STMMAC_ETH) += stmmac.o
stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o
stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
stmmac-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
+stmmac-$(CONFIG_DWMAC_STI) += dwmac-sti.o
stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o \
chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
new file mode 100644
index 0000000..d87584cb
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
@@ -0,0 +1,331 @@
+/**
+ * dwmac-sti.c - STMicroelectronics DWMAC Specific Glue layer
+ *
+ * Copyright (C) 2003-2014 STMicroelectronics (R&D) Limited
+ * Author: Srinivas Kandagatla <srinivas.kandagatla@st.com>
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+#include <linux/stmmac.h>
+#include <linux/phy.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/clk.h>
+#include <linux/of.h>
+#include <linux/of_net.h>
+
+/**
+ * STi GMAC glue logic.
+ * --------------------
+ *
+ * _
+ * | \
+ * --------|0 \ ETH_SEL_INTERNAL_NOTEXT_PHYCLK
+ * phyclk | |___________________________________________
+ * | | | (phyclk-in)
+ * --------|1 / |
+ * int-clk |_ / |
+ * | _
+ * | | \
+ * |_______|0 \ ETH_SEL_TX_RETIME_CLK
+ * | |___________________________
+ * | | (tx-retime-clk)
+ * _______|1 /
+ * | |_ /
+ * _ |
+ * | \ |
+ * --------|0 \ |
+ * clk_125 | |__|
+ * | | ETH_SEL_TXCLK_NOT_CLK125
+ * --------|1 /
+ * txclk |_ /
+ *
+ *
+ * ETH_SEL_INTERNAL_NOTEXT_PHYCLK is valid only for RMII where PHY can
+ * generate 50MHz clock or MAC can generate it.
+ * This bit is configured by "st,ext-phyclk" property.
+ *
+ * ETH_SEL_TXCLK_NOT_CLK125 is only valid for gigabit modes, where the 125Mhz
+ * clock either comes from clk-125 pin or txclk pin. This configuration is
+ * totally driven by the board wiring. This bit is configured by
+ * "st,tx-retime-src" property.
+ *
+ * TXCLK configuration is different for different phy interface modes
+ * and changes according to link speed in modes like RGMII.
+ *
+ * Below table summarizes the clock requirement and clock sources for
+ * supported phy interface modes with link speeds.
+ * ________________________________________________
+ *| PHY_MODE | 1000 Mbit Link | 100 Mbit Link |
+ * ------------------------------------------------
+ *| MII | n/a | 25Mhz |
+ *| | | txclk |
+ * ------------------------------------------------
+ *| GMII | 125Mhz | 25Mhz |
+ *| | clk-125/txclk | txclk |
+ * ------------------------------------------------
+ *| RGMII | 125Mhz | 25Mhz |
+ *| | clk-125/txclk | clkgen |
+ * ------------------------------------------------
+ *| RMII | n/a | 25Mhz |
+ *| | |clkgen/phyclk-in |
+ * ------------------------------------------------
+ *
+ * TX lines are always retimed with a clk, which can vary depending
+ * on the board configuration. Below is the table of these bits
+ * in eth configuration register depending on source of retime clk.
+ *
+ *---------------------------------------------------------------
+ * src | tx_rt_clk | int_not_ext_phyclk | txclk_n_clk125|
+ *---------------------------------------------------------------
+ * txclk | 0 | n/a | 1 |
+ *---------------------------------------------------------------
+ * ck_125| 0 | n/a | 0 |
+ *---------------------------------------------------------------
+ * phyclk| 1 | 0 | n/a |
+ *---------------------------------------------------------------
+ * clkgen| 1 | 1 | n/a |
+ *---------------------------------------------------------------
+ */
+
+ /* Register definition */
+
+ /* 3 bits [8:6]
+ * [6:6] ETH_SEL_TXCLK_NOT_CLK125
+ * [7:7] ETH_SEL_INTERNAL_NOTEXT_PHYCLK
+ * [8:8] ETH_SEL_TX_RETIME_CLK
+ *
+ */
+
+#define TX_RETIME_SRC_MASK GENMASK(8, 6)
+#define ETH_SEL_TX_RETIME_CLK BIT(8)
+#define ETH_SEL_INTERNAL_NOTEXT_PHYCLK BIT(7)
+#define ETH_SEL_TXCLK_NOT_CLK125 BIT(6)
+
+#define ENMII_MASK GENMASK(5, 5)
+#define ENMII BIT(5)
+
+/**
+ * 3 bits [4:2]
+ * 000-GMII/MII
+ * 001-RGMII
+ * 010-SGMII
+ * 100-RMII
+*/
+#define MII_PHY_SEL_MASK GENMASK(4, 2)
+#define ETH_PHY_SEL_RMII BIT(4)
+#define ETH_PHY_SEL_SGMII BIT(3)
+#define ETH_PHY_SEL_RGMII BIT(2)
+#define ETH_PHY_SEL_GMII 0x0
+#define ETH_PHY_SEL_MII 0x0
+
+#define IS_PHY_IF_MODE_RGMII(iface) (iface == PHY_INTERFACE_MODE_RGMII || \
+ iface == PHY_INTERFACE_MODE_RGMII_ID || \
+ iface == PHY_INTERFACE_MODE_RGMII_RXID || \
+ iface == PHY_INTERFACE_MODE_RGMII_TXID)
+
+#define IS_PHY_IF_MODE_GBIT(iface) (IS_PHY_IF_MODE_RGMII(iface) || \
+ iface == PHY_INTERFACE_MODE_GMII)
+
+struct sti_dwmac {
+ int interface;
+ bool ext_phyclk;
+ bool is_tx_retime_src_clk_125;
+ struct clk *clk;
+ int reg;
+ struct device *dev;
+ struct regmap *regmap;
+};
+
+static u32 phy_intf_sels[] = {
+ [PHY_INTERFACE_MODE_MII] = ETH_PHY_SEL_MII,
+ [PHY_INTERFACE_MODE_GMII] = ETH_PHY_SEL_GMII,
+ [PHY_INTERFACE_MODE_RGMII] = ETH_PHY_SEL_RGMII,
+ [PHY_INTERFACE_MODE_RGMII_ID] = ETH_PHY_SEL_RGMII,
+ [PHY_INTERFACE_MODE_SGMII] = ETH_PHY_SEL_SGMII,
+ [PHY_INTERFACE_MODE_RMII] = ETH_PHY_SEL_RMII,
+};
+
+enum {
+ TX_RETIME_SRC_NA = 0,
+ TX_RETIME_SRC_TXCLK = 1,
+ TX_RETIME_SRC_CLK_125,
+ TX_RETIME_SRC_PHYCLK,
+ TX_RETIME_SRC_CLKGEN,
+};
+
+static const char * const tx_retime_srcs[] = {
+ [TX_RETIME_SRC_NA] = "",
+ [TX_RETIME_SRC_TXCLK] = "txclk",
+ [TX_RETIME_SRC_CLK_125] = "clk_125",
+ [TX_RETIME_SRC_PHYCLK] = "phyclk",
+ [TX_RETIME_SRC_CLKGEN] = "clkgen",
+};
+
+static u32 tx_retime_val[] = {
+ [TX_RETIME_SRC_TXCLK] = ETH_SEL_TXCLK_NOT_CLK125,
+ [TX_RETIME_SRC_CLK_125] = 0x0,
+ [TX_RETIME_SRC_PHYCLK] = ETH_SEL_TX_RETIME_CLK,
+ [TX_RETIME_SRC_CLKGEN] = ETH_SEL_TX_RETIME_CLK |
+ ETH_SEL_INTERNAL_NOTEXT_PHYCLK,
+};
+
+static void setup_retime_src(struct sti_dwmac *dwmac, u32 spd)
+{
+ u32 src = 0, freq = 0;
+
+ if (spd == SPEED_100) {
+ if (dwmac->interface == PHY_INTERFACE_MODE_MII ||
+ dwmac->interface == PHY_INTERFACE_MODE_GMII) {
+ src = TX_RETIME_SRC_TXCLK;
+ } else if (dwmac->interface == PHY_INTERFACE_MODE_RMII) {
+ if (dwmac->ext_phyclk) {
+ src = TX_RETIME_SRC_PHYCLK;
+ } else {
+ src = TX_RETIME_SRC_CLKGEN;
+ freq = 50000000;
+ }
+
+ } else if (IS_PHY_IF_MODE_RGMII(dwmac->interface)) {
+ src = TX_RETIME_SRC_CLKGEN;
+ freq = 25000000;
+ }
+
+ if (src == TX_RETIME_SRC_CLKGEN && dwmac->clk)
+ clk_set_rate(dwmac->clk, freq);
+
+ } else if (spd == SPEED_1000) {
+ if (dwmac->is_tx_retime_src_clk_125)
+ src = TX_RETIME_SRC_CLK_125;
+ else
+ src = TX_RETIME_SRC_TXCLK;
+ }
+
+ regmap_update_bits(dwmac->regmap, dwmac->reg,
+ TX_RETIME_SRC_MASK, tx_retime_val[src]);
+}
+
+static void sti_dwmac_exit(struct platform_device *pdev, void *priv)
+{
+ struct sti_dwmac *dwmac = priv;
+
+ if (dwmac->clk)
+ clk_disable_unprepare(dwmac->clk);
+}
+
+static void sti_fix_mac_speed(void *priv, unsigned int spd)
+{
+ struct sti_dwmac *dwmac = priv;
+ setup_retime_src(dwmac, spd);
+ return;
+}
+
+static int sti_dwmac_parse_data(struct sti_dwmac *dwmac,
+ struct platform_device *pdev)
+{
+ struct resource *res;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct regmap *regmap;
+ int err;
+
+ if (!np)
+ return -EINVAL;
+
+ res = platform_get_resource_byname(pdev,
+ IORESOURCE_MEM, "sti-ethconf");
+ if (!res)
+ return -ENODATA;
+
+ regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ dwmac->dev = dev;
+ dwmac->interface = of_get_phy_mode(np);
+ dwmac->regmap = regmap;
+ dwmac->reg = res->start;
+ dwmac->ext_phyclk = of_property_read_bool(np, "st,ext-phyclk");
+
+ dwmac->is_tx_retime_src_clk_125 = false;
+
+ if (IS_PHY_IF_MODE_GBIT(dwmac->interface)) {
+ const char *rs;
+ err = of_property_read_string(np, "st,tx-retime-src", &rs);
+ if (err < 0) {
+ dev_err(dev, "st,tx-retime-src not specified\n");
+ return err;
+ }
+
+ if (!strcasecmp(rs, "clk_125"))
+ dwmac->is_tx_retime_src_clk_125 = true;
+
+ }
+
+ dwmac->clk = devm_clk_get(dev, "sti-ethclk");
+
+ if (IS_ERR(dwmac->clk))
+ dwmac->clk = NULL;
+
+ return 0;
+}
+
+static int sti_dwmac_init(struct platform_device *pdev, void *priv)
+{
+ struct sti_dwmac *dwmac = priv;
+ struct regmap *regmap = dwmac->regmap;
+ int iface = dwmac->interface;
+ u32 reg = dwmac->reg;
+ u32 val, spd;
+
+ if (dwmac->clk)
+ clk_prepare_enable(dwmac->clk);
+
+ regmap_update_bits(regmap, reg, MII_PHY_SEL_MASK,
+ phy_intf_sels[iface]);
+
+ val = (iface == PHY_INTERFACE_MODE_REVMII) ? 0 : ENMII;
+ regmap_update_bits(regmap, reg, ENMII_MASK, val);
+
+ if (IS_PHY_IF_MODE_GBIT(iface))
+ spd = SPEED_1000;
+ else
+ spd = SPEED_100;
+
+ setup_retime_src(dwmac, spd);
+
+ return 0;
+}
+
+static void *sti_dwmac_setup(struct platform_device *pdev)
+{
+ struct sti_dwmac *dwmac;
+ int ret;
+
+ dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
+ if (!dwmac)
+ return ERR_PTR(-ENOMEM);
+
+ ret = sti_dwmac_parse_data(dwmac, pdev);
+ if (ret) {
+ dev_err(&pdev->dev, "Unable to parse OF data\n");
+ return ERR_PTR(ret);
+ }
+
+ return dwmac;
+}
+
+const struct stmmac_of_data sti_gmac_data = {
+ .fix_mac_speed = sti_fix_mac_speed,
+ .setup = sti_dwmac_setup,
+ .init = sti_dwmac_init,
+ .exit = sti_dwmac_exit,
+};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index d9af26e..f9e60d7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -133,6 +133,9 @@ bool stmmac_eee_init(struct stmmac_priv *priv);
#ifdef CONFIG_DWMAC_SUNXI
extern const struct stmmac_of_data sun7i_gmac_data;
#endif
+#ifdef CONFIG_DWMAC_STI
+extern const struct stmmac_of_data sti_gmac_data;
+#endif
extern struct platform_driver stmmac_pltfr_driver;
static inline int stmmac_register_platform(void)
{
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 5884a7d..c61bc72b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -33,6 +33,11 @@ static const struct of_device_id stmmac_dt_ids[] = {
#ifdef CONFIG_DWMAC_SUNXI
{ .compatible = "allwinner,sun7i-a20-gmac", .data = &sun7i_gmac_data},
#endif
+#ifdef CONFIG_DWMAC_STI
+ { .compatible = "st,stih415-dwmac", .data = &sti_gmac_data},
+ { .compatible = "st,stih416-dwmac", .data = &sti_gmac_data},
+ { .compatible = "st,stih127-dwmac", .data = &sti_gmac_data},
+#endif
/* SoC specific glue layers should come before generic bindings */
{ .compatible = "st,spear600-gmac"},
{ .compatible = "snps,dwmac-3.610"},
--
1.7.9.5
^ permalink raw reply related
* [PATCH v1 2/3] ARM: STi: Add STiH415 ethernet support.
From: srinivas.kandagatla @ 2014-02-03 12:01 UTC (permalink / raw)
To: netdev
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Rob Landley, Russell King, Srinivas Kandagatla, Stuart Menefy,
Giuseppe Cavallaro, devicetree, linux-doc, linux-kernel,
linux-arm-kernel, kernel, davem
In-Reply-To: <1391428787-27143-1-git-send-email-srinivas.kandagatla@st.com>
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch adds support to STiH415 SOC, which has two ethernet
snps,dwmac controllers version 3.610. With this patch B2000 and B2020
boards can boot with ethernet in MII and RGMII modes.
Tested on both B2020 and B2000.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/boot/dts/stih415-clock.dtsi | 14 ++++
arch/arm/boot/dts/stih415-pinctrl.dtsi | 121 ++++++++++++++++++++++++++++++++
arch/arm/boot/dts/stih415.dtsi | 48 +++++++++++++
arch/arm/boot/dts/stih41x-b2000.dtsi | 22 ++++++
arch/arm/boot/dts/stih41x-b2020.dtsi | 26 +++++++
5 files changed, 231 insertions(+)
diff --git a/arch/arm/boot/dts/stih415-clock.dtsi b/arch/arm/boot/dts/stih415-clock.dtsi
index 174c799..d047dbc 100644
--- a/arch/arm/boot/dts/stih415-clock.dtsi
+++ b/arch/arm/boot/dts/stih415-clock.dtsi
@@ -34,5 +34,19 @@
compatible = "fixed-clock";
clock-frequency = <100000000>;
};
+
+ CLKS_GMAC0_PHY: clockgenA1@7 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <25000000>;
+ clock-output-names = "CLKS_GMAC0_PHY";
+ };
+
+ CLKS_ETH1_PHY: clockgenA0@7 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <25000000>;
+ clock-output-names = "CLKS_ETH1_PHY";
+ };
};
};
diff --git a/arch/arm/boot/dts/stih415-pinctrl.dtsi b/arch/arm/boot/dts/stih415-pinctrl.dtsi
index 887c5e5..9ca20aa 100644
--- a/arch/arm/boot/dts/stih415-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih415-pinctrl.dtsi
@@ -119,6 +119,56 @@
};
};
};
+
+ gmac1 {
+ pinctrl_mii1: mii1 {
+ st,pins {
+ txd0 = <&PIO0 0 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txd1 = <&PIO0 1 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txd2 = <&PIO0 2 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txd3 = <&PIO0 3 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txer = <&PIO0 4 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txen = <&PIO0 5 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txclk = <&PIO0 6 ALT1 IN NICLK 0 CLK_A>;
+ col = <&PIO0 7 ALT1 IN BYPASS 1000>;
+ mdio = <&PIO1 0 ALT1 OUT BYPASS 0>;
+ mdc = <&PIO1 1 ALT1 OUT NICLK 0 CLK_A>;
+ crs = <&PIO1 2 ALT1 IN BYPASS 1000>;
+ mdint = <&PIO1 3 ALT1 IN BYPASS 0>;
+ rxd0 = <&PIO1 4 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxd1 = <&PIO1 5 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxd2 = <&PIO1 6 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxd3 = <&PIO1 7 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxdv = <&PIO2 0 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rx_er = <&PIO2 1 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxclk = <&PIO2 2 ALT1 IN NICLK 0 CLK_A>;
+ phyclk = <&PIO2 3 ALT1 IN NICLK 1000 CLK_A>;
+ };
+ };
+
+ pinctrl_rgmii1: rgmii1-0 {
+ st,pins {
+ txd0 = <&PIO0 0 ALT1 OUT DE_IO 1000 CLK_A>;
+ txd1 = <&PIO0 1 ALT1 OUT DE_IO 1000 CLK_A>;
+ txd2 = <&PIO0 2 ALT1 OUT DE_IO 1000 CLK_A>;
+ txd3 = <&PIO0 3 ALT1 OUT DE_IO 1000 CLK_A>;
+ txen = <&PIO0 5 ALT1 OUT DE_IO 0 CLK_A>;
+ txclk = <&PIO0 6 ALT1 IN NICLK 0 CLK_A>;
+ mdio = <&PIO1 0 ALT1 OUT BYPASS 0>;
+ mdc = <&PIO1 1 ALT1 OUT NICLK 0 CLK_A>;
+ rxd0 = <&PIO1 4 ALT1 IN DE_IO 0 CLK_A>;
+ rxd1 = <&PIO1 5 ALT1 IN DE_IO 0 CLK_A>;
+ rxd2 = <&PIO1 6 ALT1 IN DE_IO 0 CLK_A>;
+ rxd3 = <&PIO1 7 ALT1 IN DE_IO 0 CLK_A>;
+
+ rxdv = <&PIO2 0 ALT1 IN DE_IO 500 CLK_A>;
+ rxclk = <&PIO2 2 ALT1 IN NICLK 0 CLK_A>;
+ phyclk = <&PIO2 3 ALT4 OUT NICLK 0 CLK_B>;
+
+ clk125= <&PIO3 7 ALT4 IN NICLK 0 CLK_A>;
+ };
+ };
+ };
};
pin-controller-front {
@@ -284,6 +334,77 @@
};
};
};
+
+ gmac0{
+ pinctrl_mii0: mii0 {
+ st,pins {
+ mdint = <&PIO13 6 ALT2 IN BYPASS 0>;
+ txen = <&PIO13 7 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+
+ txd0 = <&PIO14 0 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+ txd1 = <&PIO14 1 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+ txd2 = <&PIO14 2 ALT2 OUT SE_NICLK_IO 0 CLK_B>;
+ txd3 = <&PIO14 3 ALT2 OUT SE_NICLK_IO 0 CLK_B>;
+
+ txclk = <&PIO15 0 ALT2 IN NICLK 0 CLK_A>;
+ txer = <&PIO15 1 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+ crs = <&PIO15 2 ALT2 IN BYPASS 1000>;
+ col = <&PIO15 3 ALT2 IN BYPASS 1000>;
+ mdio = <&PIO15 4 ALT2 OUT BYPASS 3000>;
+ mdc = <&PIO15 5 ALT2 OUT NICLK 0 CLK_B>;
+
+ rxd0 = <&PIO16 0 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxd1 = <&PIO16 1 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxd2 = <&PIO16 2 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxd3 = <&PIO16 3 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxdv = <&PIO15 6 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rx_er = <&PIO15 7 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxclk = <&PIO17 0 ALT2 IN NICLK 0 CLK_A>;
+ phyclk = <&PIO13 5 ALT2 OUT NICLK 1000 CLK_A>;
+
+ };
+ };
+
+ pinctrl_gmii0: gmii0 {
+ st,pins {
+ mdint = <&PIO13 6 ALT2 IN BYPASS 0>;
+ mdio = <&PIO15 4 ALT2 OUT BYPASS 3000>;
+ mdc = <&PIO15 5 ALT2 OUT NICLK 0 CLK_B>;
+ txen = <&PIO13 7 ALT2 OUT SE_NICLK_IO 3000 CLK_A>;
+
+ txd0 = <&PIO14 0 ALT2 OUT SE_NICLK_IO 3000 CLK_A>;
+ txd1 = <&PIO14 1 ALT2 OUT SE_NICLK_IO 3000 CLK_A>;
+ txd2 = <&PIO14 2 ALT2 OUT SE_NICLK_IO 3000 CLK_B>;
+ txd3 = <&PIO14 3 ALT2 OUT SE_NICLK_IO 3000 CLK_B>;
+ txd4 = <&PIO14 4 ALT2 OUT SE_NICLK_IO 3000 CLK_B>;
+ txd5 = <&PIO14 5 ALT2 OUT SE_NICLK_IO 3000 CLK_B>;
+ txd6 = <&PIO14 6 ALT2 OUT SE_NICLK_IO 3000 CLK_B>;
+ txd7 = <&PIO14 7 ALT2 OUT SE_NICLK_IO 3000 CLK_B>;
+
+ txclk = <&PIO15 0 ALT2 IN NICLK 0 CLK_A>;
+ txer = <&PIO15 1 ALT2 OUT SE_NICLK_IO 3000 CLK_A>;
+ crs = <&PIO15 2 ALT2 IN BYPASS 1000>;
+ col = <&PIO15 3 ALT2 IN BYPASS 1000>;
+ rxdv = <&PIO15 6 ALT2 IN SE_NICLK_IO 1500 CLK_A>;
+ rx_er = <&PIO15 7 ALT2 IN SE_NICLK_IO 1500 CLK_A>;
+
+ rxd0 = <&PIO16 0 ALT2 IN SE_NICLK_IO 1500 CLK_A>;
+ rxd1 = <&PIO16 1 ALT2 IN SE_NICLK_IO 1500 CLK_A>;
+ rxd2 = <&PIO16 2 ALT2 IN SE_NICLK_IO 1500 CLK_A>;
+ rxd3 = <&PIO16 3 ALT2 IN SE_NICLK_IO 1500 CLK_A>;
+ rxd4 = <&PIO16 4 ALT2 IN SE_NICLK_IO 1500 CLK_A>;
+ rxd5 = <&PIO16 5 ALT2 IN SE_NICLK_IO 1500 CLK_A>;
+ rxd6 = <&PIO16 6 ALT2 IN SE_NICLK_IO 1500 CLK_A>;
+ rxd7 = <&PIO16 7 ALT2 IN SE_NICLK_IO 1500 CLK_A>;
+
+ rxclk = <&PIO17 0 ALT2 IN NICLK 0 CLK_A>;
+ clk125 = <&PIO17 6 ALT1 IN NICLK 0 CLK_A>;
+ phyclk = <&PIO13 5 ALT4 OUT NICLK 0 CLK_B>;
+
+
+ };
+ };
+ };
};
pin-controller-left {
diff --git a/arch/arm/boot/dts/stih415.dtsi b/arch/arm/boot/dts/stih415.dtsi
index d52207c..cc9b22b 100644
--- a/arch/arm/boot/dts/stih415.dtsi
+++ b/arch/arm/boot/dts/stih415.dtsi
@@ -147,5 +147,53 @@
status = "disabled";
};
+
+ ethernet0: dwmac@fe810000 {
+ device_type = "network";
+ compatible = "st,stih415-dwmac", "snps,dwmac", "snps,dwmac-3.610";
+ status = "disabled";
+
+ reg = <0xfe810000 0x8000>, <0x148 0x4>;
+ reg-names = "stmmaceth", "sti-ethconf";
+
+ interrupts = <0 147 0>, <0 148 0>, <0 149 0>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ resets = <&softreset STIH415_ETH0_SOFTRESET>;
+ reset-names = "stmmaceth";
+
+ snps,pbl = <32>;
+ snps,mixed-burst;
+ snps,force_sf_dma_mode;
+
+ st,syscon = <&syscfg_rear>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mii0>;
+ clock-names = "stmmaceth";
+ clocks = <&CLKS_GMAC0_PHY>;
+ };
+
+ ethernet1: dwmac@fef08000 {
+ device_type = "network";
+ compatible = "st,stih415-dwmac", "snps,dwmac", "snps,dwmac-3.610";
+ status = "disabled";
+ reg = <0xfef08000 0x8000>, <0x74 0x4>;
+ reg-names = "stmmaceth", "sti-ethconf";
+ interrupts = <0 150 0>, <0 151 0>, <0 152 0>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+
+ snps,pbl = <32>;
+ snps,mixed-burst;
+ snps,force_sf_dma_mode;
+
+ st,syscon = <&syscfg_sbc>;
+
+ resets = <&softreset STIH415_ETH1_SOFTRESET>;
+ reset-names = "stmmaceth";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mii1>;
+ clock-names = "stmmaceth";
+ clocks = <&CLKS_ETH1_PHY>;
+ };
};
};
diff --git a/arch/arm/boot/dts/stih41x-b2000.dtsi b/arch/arm/boot/dts/stih41x-b2000.dtsi
index 1e6aa92..bf65c49 100644
--- a/arch/arm/boot/dts/stih41x-b2000.dtsi
+++ b/arch/arm/boot/dts/stih41x-b2000.dtsi
@@ -20,6 +20,8 @@
aliases {
ttyAS0 = &serial2;
+ ethernet0 = ðernet0;
+ ethernet1 = ðernet1;
};
soc {
@@ -46,5 +48,25 @@
status = "okay";
};
+
+ ethernet0: dwmac@fe810000 {
+ status = "okay";
+ phy-mode = "mii";
+ pinctrl-0 = <&pinctrl_mii0>;
+
+ snps,reset-gpio = <&PIO106 2>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 10000>;
+ };
+
+ ethernet1: dwmac@fef08000 {
+ status = "disabled";
+ phy-mode = "mii";
+ st,tx-retime-src = "txclk";
+
+ snps,reset-gpio = <&PIO4 7>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 10000>;
+ };
};
};
diff --git a/arch/arm/boot/dts/stih41x-b2020.dtsi b/arch/arm/boot/dts/stih41x-b2020.dtsi
index 0ef0a69..6c9a2ab 100644
--- a/arch/arm/boot/dts/stih41x-b2020.dtsi
+++ b/arch/arm/boot/dts/stih41x-b2020.dtsi
@@ -19,6 +19,7 @@
aliases {
ttyAS0 = &sbc_serial1;
+ ethernet1 = ðernet1;
};
soc {
sbc_serial1: serial@fe531000 {
@@ -60,5 +61,30 @@
i2c@fe541000 {
status = "okay";
};
+
+ /**
+ * ethernet clk routing:
+ * for
+ * max-speed = <1000>;
+ * set
+ * st,tx-retime-src = "clk_125";
+ *
+ * for
+ * max-speed = <100>;
+ * set
+ * st,tx-retime-src = "clkgen";
+ */
+
+ ethernet1: dwmac@fef08000 {
+ status = "okay";
+ phy-mode = "rgmii-id";
+ max-speed = <1000>;
+ st,tx-retime-src = "clk_125";
+ snps,reset-gpio = <&PIO3 0>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 10000>;
+
+ pinctrl-0 = <&pinctrl_rgmii1>;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v1 3/3] ARM: STi: Add STiH416 ethernet support.
From: srinivas.kandagatla @ 2014-02-03 12:02 UTC (permalink / raw)
To: netdev
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Rob Landley, Russell King, Srinivas Kandagatla, Stuart Menefy,
Giuseppe Cavallaro, devicetree, linux-doc, linux-kernel,
linux-arm-kernel, kernel, davem
In-Reply-To: <1391428787-27143-1-git-send-email-srinivas.kandagatla@st.com>
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch adds support to STiH416 SOC, which has two ethernet
snps,dwmac controllers version 3.710. With this patch B2000 and B2020
boards can boot with ethernet in MII and RGMII modes.
Tested on both B2020 and B2000.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/boot/dts/stih416-clock.dtsi | 14 ++++
arch/arm/boot/dts/stih416-pinctrl.dtsi | 109 ++++++++++++++++++++++++++++++++
arch/arm/boot/dts/stih416.dtsi | 44 +++++++++++++
3 files changed, 167 insertions(+)
diff --git a/arch/arm/boot/dts/stih416-clock.dtsi b/arch/arm/boot/dts/stih416-clock.dtsi
index 7026bf1..a6942c7 100644
--- a/arch/arm/boot/dts/stih416-clock.dtsi
+++ b/arch/arm/boot/dts/stih416-clock.dtsi
@@ -37,5 +37,19 @@
clock-frequency = <100000000>;
clock-output-names = "CLK_S_ICN_REG_0";
};
+
+ CLK_S_GMAC0_PHY: clockgenA1@7 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <25000000>;
+ clock-output-names = "CLK_S_GMAC0_PHY";
+ };
+
+ CLK_S_ETH1_PHY: clockgenA0@7 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <25000000>;
+ clock-output-names = "CLK_S_ETH1_PHY";
+ };
};
};
diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi b/arch/arm/boot/dts/stih416-pinctrl.dtsi
index 8863c38..c4beef2 100644
--- a/arch/arm/boot/dts/stih416-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih416-pinctrl.dtsi
@@ -132,6 +132,58 @@
};
};
};
+
+ gmac1 {
+ pinctrl_mii1: mii1 {
+ st,pins {
+ txd0 = <&PIO0 0 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txd1 = <&PIO0 1 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txd2 = <&PIO0 2 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txd3 = <&PIO0 3 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txer = <&PIO0 4 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txen = <&PIO0 5 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txclk = <&PIO0 6 ALT1 IN NICLK 0 CLK_A>;
+ col = <&PIO0 7 ALT1 IN BYPASS 1000>;
+
+ mdio = <&PIO1 0 ALT1 OUT BYPASS 1500>;
+ mdc = <&PIO1 1 ALT1 OUT NICLK 0 CLK_A>;
+ crs = <&PIO1 2 ALT1 IN BYPASS 1000>;
+ mdint = <&PIO1 3 ALT1 IN BYPASS 0>;
+ rxd0 = <&PIO1 4 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxd1 = <&PIO1 5 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxd2 = <&PIO1 6 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxd3 = <&PIO1 7 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+
+ rxdv = <&PIO2 0 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rx_er = <&PIO2 1 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxclk = <&PIO2 2 ALT1 IN NICLK 0 CLK_A>;
+ phyclk = <&PIO2 3 ALT1 OUT NICLK 0 CLK_A>;
+ };
+ };
+ pinctrl_rgmii1: rgmii1-0 {
+ st,pins {
+ txd0 = <&PIO0 0 ALT1 OUT DE_IO 500 CLK_A>;
+ txd1 = <&PIO0 1 ALT1 OUT DE_IO 500 CLK_A>;
+ txd2 = <&PIO0 2 ALT1 OUT DE_IO 500 CLK_A>;
+ txd3 = <&PIO0 3 ALT1 OUT DE_IO 500 CLK_A>;
+ txen = <&PIO0 5 ALT1 OUT DE_IO 0 CLK_A>;
+ txclk = <&PIO0 6 ALT1 IN NICLK 0 CLK_A>;
+
+ mdio = <&PIO1 0 ALT1 OUT BYPASS 0>;
+ mdc = <&PIO1 1 ALT1 OUT NICLK 0 CLK_A>;
+ rxd0 = <&PIO1 4 ALT1 IN DE_IO 500 CLK_A>;
+ rxd1 = <&PIO1 5 ALT1 IN DE_IO 500 CLK_A>;
+ rxd2 = <&PIO1 6 ALT1 IN DE_IO 500 CLK_A>;
+ rxd3 = <&PIO1 7 ALT1 IN DE_IO 500 CLK_A>;
+
+ rxdv = <&PIO2 0 ALT1 IN DE_IO 500 CLK_A>;
+ rxclk = <&PIO2 2 ALT1 IN NICLK 0 CLK_A>;
+ phyclk = <&PIO2 3 ALT4 OUT NICLK 0 CLK_B>;
+
+ clk125= <&PIO3 7 ALT4 IN NICLK 0 CLK_A>;
+ };
+ };
+ };
};
pin-controller-front {
@@ -322,6 +374,63 @@
};
};
};
+
+ gmac0 {
+ pinctrl_mii0: mii0 {
+ st,pins {
+ mdint = <&PIO13 6 ALT2 IN BYPASS 0>;
+ txen = <&PIO13 7 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+ txd0 = <&PIO14 0 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+ txd1 = <&PIO14 1 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+ txd2 = <&PIO14 2 ALT2 OUT SE_NICLK_IO 0 CLK_B>;
+ txd3 = <&PIO14 3 ALT2 OUT SE_NICLK_IO 0 CLK_B>;
+
+ txclk = <&PIO15 0 ALT2 IN NICLK 0 CLK_A>;
+ txer = <&PIO15 1 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+ crs = <&PIO15 2 ALT2 IN BYPASS 1000>;
+ col = <&PIO15 3 ALT2 IN BYPASS 1000>;
+ mdio= <&PIO15 4 ALT2 OUT BYPASS 1500>;
+ mdc = <&PIO15 5 ALT2 OUT NICLK 0 CLK_B>;
+
+ rxd0 = <&PIO16 0 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxd1 = <&PIO16 1 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxd2 = <&PIO16 2 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxd3 = <&PIO16 3 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxdv = <&PIO15 6 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rx_er = <&PIO15 7 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxclk = <&PIO17 0 ALT2 IN NICLK 0 CLK_A>;
+ phyclk = <&PIO13 5 ALT2 OUT NICLK 0 CLK_B>;
+ };
+ };
+
+ pinctrl_gmii0: gmii0 {
+ st,pins {
+ };
+ };
+ pinctrl_rgmii0: rgmii0 {
+ st,pins {
+ phyclk = <&PIO13 5 ALT4 OUT NICLK 0 CLK_B>;
+ txen = <&PIO13 7 ALT2 OUT DE_IO 0 CLK_A>;
+ txd0 = <&PIO14 0 ALT2 OUT DE_IO 500 CLK_A>;
+ txd1 = <&PIO14 1 ALT2 OUT DE_IO 500 CLK_A>;
+ txd2 = <&PIO14 2 ALT2 OUT DE_IO 500 CLK_B>;
+ txd3 = <&PIO14 3 ALT2 OUT DE_IO 500 CLK_B>;
+ txclk = <&PIO15 0 ALT2 IN NICLK 0 CLK_A>;
+
+ mdio = <&PIO15 4 ALT2 OUT BYPASS 0>;
+ mdc = <&PIO15 5 ALT2 OUT NICLK 0 CLK_B>;
+
+ rxdv = <&PIO15 6 ALT2 IN DE_IO 500 CLK_A>;
+ rxd0 =<&PIO16 0 ALT2 IN DE_IO 500 CLK_A>;
+ rxd1 =<&PIO16 1 ALT2 IN DE_IO 500 CLK_A>;
+ rxd2 =<&PIO16 2 ALT2 IN DE_IO 500 CLK_A>;
+ rxd3 =<&PIO16 3 ALT2 IN DE_IO 500 CLK_A>;
+ rxclk =<&PIO17 0 ALT2 IN NICLK 0 CLK_A>;
+
+ clk125=<&PIO17 6 ALT1 IN NICLK 0 CLK_A>;
+ };
+ };
+ };
};
pin-controller-fvdp-fe {
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 788ba5b..a96055b 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -156,5 +156,49 @@
status = "disabled";
};
+
+ ethernet0: dwmac@fe810000 {
+ device_type = "network";
+ compatible = "st,stih416-dwmac", "snps,dwmac", "snps,dwmac-3.710";
+ status = "disabled";
+ reg = <0xfe810000 0x8000>, <0x8bc 0x4>;
+ reg-names = "stmmaceth", "sti-ethconf";
+
+ interrupts = <0 133 0>, <0 134 0>, <0 135 0>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+
+ snps,pbl = <32>;
+ snps,mixed-burst;
+
+ st,syscon = <&syscfg_rear>;
+ resets = <&softreset STIH416_ETH0_SOFTRESET>;
+ reset-names = "stmmaceth";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mii0>;
+ clock-names = "stmmaceth";
+ clocks = <&CLK_S_GMAC0_PHY>;
+ };
+
+ ethernet1: dwmac@fef08000 {
+ device_type = "network";
+ compatible = "st,stih416-dwmac", "snps,dwmac", "snps,dwmac-3.710";
+ status = "disabled";
+ reg = <0xfef08000 0x8000>, <0x7f0 0x4>;
+ reg-names = "stmmaceth", "sti-ethconf";
+ interrupts = <0 136 0>, <0 137 0>, <0 138 0>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+
+ snps,pbl = <32>;
+ snps,mixed-burst;
+
+ st,syscon = <&syscfg_sbc>;
+
+ resets = <&softreset STIH416_ETH1_SOFTRESET>;
+ reset-names = "stmmaceth";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mii1>;
+ clock-names = "stmmaceth";
+ clocks = <&CLK_S_ETH1_PHY>;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* Re: OOPS in nf_ct_unlink_expect_report using Polycom RealPresence Mobile
From: Pablo Neira Ayuso @ 2014-02-03 12:14 UTC (permalink / raw)
To: astx; +Cc: linux-kernel, netdev, netfilter, Alexey Dobriyan, netfilter-devel
In-Reply-To: <20140131170402.Horde.yIFUeQVjLycuS_8PGQoKmg5@aws-it.at>
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
On Fri, Jan 31, 2014 at 05:04:02PM +0100, astx wrote:
> Dear Alexey,
>
> seems to help. Thank you for your quick response. Kernel 3.10.28 is
> now stable using h323 / Polycom.
Thanks, if no objection, will pass this patch to David.
[-- Attachment #2: 0001-netfilter-nf_nat_h323-fix-crash-in-nf_ct_unlink_expe.patch --]
[-- Type: text/x-diff, Size: 2377 bytes --]
>From d98506139d6e192705422ffba13bc2ff476ac513 Mon Sep 17 00:00:00 2001
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Mon, 3 Feb 2014 13:07:24 +0100
Subject: [PATCH] netfilter: nf_nat_h323: fix crash in
nf_ct_unlink_expect_report()
Similar bug fixed in SIP module in 3f509c6 ("netfilter: nf_nat_sip: fix
incorrect handling of EBUSY for RTCP expectation").
BUG: unable to handle kernel paging request at 00100104
IP: [<f8214f07>] nf_ct_unlink_expect_report+0x57/0xf0 [nf_conntrack]
...
Call Trace:
[<c0244bd8>] ? del_timer+0x48/0x70
[<f8215687>] nf_ct_remove_expectations+0x47/0x60 [nf_conntrack]
[<f8211c99>] nf_ct_delete_from_lists+0x59/0x90 [nf_conntrack]
[<f8212e5e>] death_by_timeout+0x14e/0x1c0 [nf_conntrack]
[<f8212d10>] ? nf_conntrack_set_hashsize+0x190/0x190 [nf_conntrack]
[<c024442d>] call_timer_fn+0x1d/0x80
[<c024461e>] run_timer_softirq+0x18e/0x1a0
[<f8212d10>] ? nf_conntrack_set_hashsize+0x190/0x190 [nf_conntrack]
[<c023e6f3>] __do_softirq+0xa3/0x170
[<c023e650>] ? __local_bh_enable+0x70/0x70
<IRQ>
[<c023e587>] ? irq_exit+0x67/0xa0
[<c0202af6>] ? do_IRQ+0x46/0xb0
[<c027ad05>] ? clockevents_notify+0x35/0x110
[<c066ac6c>] ? common_interrupt+0x2c/0x40
[<c056e3c1>] ? cpuidle_enter_state+0x41/0xf0
[<c056e6fb>] ? cpuidle_idle_call+0x8b/0x100
[<c02085f8>] ? arch_cpu_idle+0x8/0x30
[<c027314b>] ? cpu_idle_loop+0x4b/0x140
[<c0273258>] ? cpu_startup_entry+0x18/0x20
[<c066056d>] ? rest_init+0x5d/0x70
[<c0813ac8>] ? start_kernel+0x2ec/0x2f2
[<c081364f>] ? repair_env_string+0x5b/0x5b
[<c0813269>] ? i386_start_kernel+0x33/0x35
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/nf_nat_h323.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/netfilter/nf_nat_h323.c b/net/ipv4/netfilter/nf_nat_h323.c
index 9eea059d..574f7eb 100644
--- a/net/ipv4/netfilter/nf_nat_h323.c
+++ b/net/ipv4/netfilter/nf_nat_h323.c
@@ -229,7 +229,10 @@ static int nat_rtp_rtcp(struct sk_buff *skb, struct nf_conn *ct,
ret = nf_ct_expect_related(rtcp_exp);
if (ret == 0)
break;
- else if (ret != -EBUSY) {
+ else if (ret == -EBUSY) {
+ nf_ct_unexpect_related(rtp_exp);
+ continue;
+ } else if (ret < 0) {
nf_ct_unexpect_related(rtp_exp);
nated_port = 0;
break;
--
1.7.10.4
^ permalink raw reply related
* Re: [Xen-devel] [PATCH v6] xen/grant-table: Avoid m2p_override during mapping
From: Zoltan Kiss @ 2014-02-03 13:27 UTC (permalink / raw)
To: David Vrabel
Cc: Julien Grall, Stefano Stabellini, jonathan.davies, wei.liu2,
ian.campbell, netdev, linux-kernel, xen-devel
In-Reply-To: <52EF7618.7030402@citrix.com>
On 03/02/14 11:57, David Vrabel wrote:
>>
>> Hi,
>>
>> That's bad indeed. I think the best solution is to put those parts
>> behind an #ifdef x86. The ones moved from x86/p2m.c to grant-table.c.
>> David, Stefano, what do you think?
> I don't think we want (more) #ifdef CONFIG_X86 in grant-table.c and the
> arch-specific bits will have to factored out into their own functions
> with suitable stubs provided for ARM.
>
I've just sent in v7 with stubs, I guess that's something you suggested.
Please review it, I'm especially curious about your thoughts regarding
the new function name.
Zoli
^ permalink raw reply
* Re: [PATCH] [RFC] netfilter: nf_conntrack: don't relase a conntrack with non-zero refcnt
From: Andrew Vagin @ 2014-02-03 13:59 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Florian Westphal, Andrey Vagin, netfilter-devel, Eric Dumazet,
netfilter, netdev, linux-kernel, vvs, Cyrill Gorcunov,
Vasiliy Averin
In-Reply-To: <20140202233046.GA4137@localhost>
On Mon, Feb 03, 2014 at 12:30:46AM +0100, Pablo Neira Ayuso wrote:
> On Thu, Jan 16, 2014 at 10:23:01AM +0100, Florian Westphal wrote:
> > Andrew Vagin <avagin@parallels.com> wrote:
> > > > I think it would be nice if we could keep it that way.
> > > > If everything fails we could proably intoduce a 'larval' dummy list
> > > > similar to the one used by template conntracks?
> > >
> > > I'm not sure, that this is required. Could you elaborate when this can
> > > be useful?
> >
> > You can dump the lists via ctnetlink. Its meant as a debugging aid in
> > case one suspects refcnt leaks.
> >
> > Granted, in this situation there should be no leak since we put the newly
> > allocated entry in the error case.
> >
> > > Now I see only overhead, because we need to take the nf_conntrack_lock
> > > lock to add conntrack in a list.
> >
> > True. I don't have any preference, I guess I'd just do the insertion into the
> > unconfirmed list when we know we cannot track to keep the "unhashed"
> > bug trap in the destroy function.
> >
> > Pablo, any preference?
>
> I think we can initially set to zero the refcount and bump it once it
> gets into any of the lists, so Eric's golden rule also stands for
> conntracks that are released without being inserted in any list via
> nf_conntrack_free().
>
> My idea was to use dying list to detect possible runtime leaks (ie.
> missing nf_ct_put somewhere), not simple leaks the initialization
> path, as you said, it would add too much overhead to catch them with
> the dying list, so we can skip those.
>
> Please, let me know if you find any issue with this approach.
Hello Pablo,
I don't see any problem with this approach and I like it.
Thank you for the patch.
> diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
> index 01ea6ee..b2ac624 100644
> --- a/include/net/netfilter/nf_conntrack.h
> +++ b/include/net/netfilter/nf_conntrack.h
> @@ -284,6 +284,8 @@ extern unsigned int nf_conntrack_max;
> extern unsigned int nf_conntrack_hash_rnd;
> void init_nf_conntrack_hash_rnd(void);
>
> +void nf_conntrack_tmpl_insert(struct net *net, struct nf_conn *tmpl);
> +
> #define NF_CT_STAT_INC(net, count) __this_cpu_inc((net)->ct.stat->count)
> #define NF_CT_STAT_INC_ATOMIC(net, count) this_cpu_inc((net)->ct.stat->count)
>
> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> index 4d1fb5d..bd5ec5a 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -448,7 +448,8 @@ nf_conntrack_hash_check_insert(struct nf_conn *ct)
> goto out;
>
> add_timer(&ct->timeout);
> - nf_conntrack_get(&ct->ct_general);
> + /* The caller holds a reference to this object */
> + atomic_set(&ct->ct_general.use, 2);
> __nf_conntrack_hash_insert(ct, hash, repl_hash);
> NF_CT_STAT_INC(net, insert);
> spin_unlock_bh(&nf_conntrack_lock);
> @@ -462,6 +463,21 @@ out:
> }
> EXPORT_SYMBOL_GPL(nf_conntrack_hash_check_insert);
>
> +/* deletion from this larval template list happens via nf_ct_put() */
> +void nf_conntrack_tmpl_insert(struct net *net, struct nf_conn *tmpl)
> +{
> + __set_bit(IPS_TEMPLATE_BIT, &tmpl->status);
> + __set_bit(IPS_CONFIRMED_BIT, &tmpl->status);
> + nf_conntrack_get(&tmpl->ct_general);
> +
> + spin_lock_bh(&nf_conntrack_lock);
> + /* Overload tuple linked list to put us in template list. */
> + hlist_nulls_add_head_rcu(&tmpl->tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
> + &net->ct.tmpl);
> + spin_unlock_bh(&nf_conntrack_lock);
> +}
> +EXPORT_SYMBOL_GPL(nf_conntrack_tmpl_insert);
> +
> /* Confirm a connection given skb; places it in hash table */
> int
> __nf_conntrack_confirm(struct sk_buff *skb)
> @@ -733,11 +749,11 @@ __nf_conntrack_alloc(struct net *net, u16 zone,
> nf_ct_zone->id = zone;
> }
> #endif
> - /*
> - * changes to lookup keys must be done before setting refcnt to 1
> + /* Because we use RCU lookups, we set ct_general.use to zero before
> + * this is inserted in any list.
> */
> smp_wmb();
> - atomic_set(&ct->ct_general.use, 1);
> + atomic_set(&ct->ct_general.use, 0);
> return ct;
>
> #ifdef CONFIG_NF_CONNTRACK_ZONES
> @@ -761,6 +777,11 @@ void nf_conntrack_free(struct nf_conn *ct)
> {
> struct net *net = nf_ct_net(ct);
>
> + /* A freed object has refcnt == 0, thats
> + * the golden rule for SLAB_DESTROY_BY_RCU
> + */
> + NF_CT_ASSERT(atomic_read(&ct->ct_general.use) == 0);
> +
> nf_ct_ext_destroy(ct);
> nf_ct_ext_free(ct);
> kmem_cache_free(net->ct.nf_conntrack_cachep, ct);
> @@ -856,6 +877,9 @@ init_conntrack(struct net *net, struct nf_conn *tmpl,
> NF_CT_STAT_INC(net, new);
> }
>
> + /* Now it is inserted into the hashes, bump refcount */
> + nf_conntrack_get(&ct->ct_general);
> +
> /* Overload tuple linked list to put us in unconfirmed list. */
> hlist_nulls_add_head_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
> &net->ct.unconfirmed);
> diff --git a/net/netfilter/nf_synproxy_core.c b/net/netfilter/nf_synproxy_core.c
> index 9858e3e..52e20c9 100644
> --- a/net/netfilter/nf_synproxy_core.c
> +++ b/net/netfilter/nf_synproxy_core.c
> @@ -363,9 +363,8 @@ static int __net_init synproxy_net_init(struct net *net)
> goto err2;
> if (!nfct_synproxy_ext_add(ct))
> goto err2;
> - __set_bit(IPS_TEMPLATE_BIT, &ct->status);
> - __set_bit(IPS_CONFIRMED_BIT, &ct->status);
>
> + nf_conntrack_tmpl_insert(net, ct);
> snet->tmpl = ct;
>
> snet->stats = alloc_percpu(struct synproxy_stats);
> @@ -390,7 +389,7 @@ static void __net_exit synproxy_net_exit(struct net *net)
> {
> struct synproxy_net *snet = synproxy_pernet(net);
>
> - nf_conntrack_free(snet->tmpl);
> + nf_ct_put(snet->tmpl);
> synproxy_proc_exit(net);
> free_percpu(snet->stats);
> }
> diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c
> index 5929be6..75747ae 100644
> --- a/net/netfilter/xt_CT.c
> +++ b/net/netfilter/xt_CT.c
> @@ -228,12 +228,7 @@ static int xt_ct_tg_check(const struct xt_tgchk_param *par,
> goto err3;
> }
>
> - __set_bit(IPS_TEMPLATE_BIT, &ct->status);
> - __set_bit(IPS_CONFIRMED_BIT, &ct->status);
> -
> - /* Overload tuple linked list to put us in template list. */
> - hlist_nulls_add_head_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
> - &par->net->ct.tmpl);
> + nf_conntrack_tmpl_insert(par->net, ct);
> out:
> info->ct = ct;
> return 0;
^ permalink raw reply
* Requeues and ECN marking
From: Greg Kuperman @ 2014-02-03 14:50 UTC (permalink / raw)
To: netdev
Hi all,
I am testing a new congestion control protocol that relies on explicit
congestion notifications (ECN) to notify the receiver of a congestion
event. I have a rate limited link of 1 Mbps, and I am using the RED
queuing discipline with ECN enabled. What I have noticed is that no
matter how small I set my queue size, or how low I set my minimum
marking level, the first ECN marked packet does not get sent out for
about 10 seconds after the input rate exceeds the output rate. Further
examination shows that ECN marking does not occur until the number or
requeues hits 1000. Below are two queries of tc -s -d qdisc ls dev
eth1.
qdisc red 8028: root refcnt 2 limit 10000000b min 1b max 0b ecn ewma
30 Plog 21 Scell_log 31
Sent 1307892 bytes 1247 pkt (dropped 0, overlimits 0 requeues 960)
backlog 1052118b 962p requeues 960
marked 0 early 0 pdrop 0 other 0
qdisc red 8028: root refcnt 2 limit 10000000b min 1b max 0b ecn ewma
30 Plog 21 Scell_log 31
Sent 1379262 bytes 1312 pkt (dropped 0, overlimits 72 requeues 1024)
backlog 1122468b 1027p requeues 1024
marked 72 early 0 pdrop 0 other 0
The txqueuelen defaults to 1000 for the interface, so I figured that
packets maybe buffering there, and then dequeuing, before any packets
are marked. I set txqueuelen to lower values (all the way down to 1),
but the exact same behavior occurs (no marked packets until number of
dequeues hits 1000). In contrast, if I set txqueuele to something very
high, I get no requeues, drops, or marked packets.
My goal is for packets to be marked as soon as the ingress rate
exceeds the egress. Am I correct in thinking that the requeuing
operation is the culprit? Can I eliminate requeues? Is there something
else I can do to get the behavior I am looking for?
Thank you all for the help. And please cc me in your replies; I'm not
100% sure if I get all the messages from this mailing list.
Best,
Greg
^ 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