* 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
* 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: [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
* 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: 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: 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: [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: 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: 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: 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: 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 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] 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] 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
* [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
* [PATCH 2/3] net: phy: sunxi: Add new compatibles
From: Maxime Ripard @ 2014-02-02 13:49 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-arm-kernel, Maxime Ripard
In-Reply-To: <1391348953-10662-1-git-send-email-maxime.ripard@free-electrons.com>
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 mdio 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-mdio.txt | 5 +++--
drivers/net/phy/mdio-sun4i.c | 3 +++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
index 00b9f9a..4ec5641 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
@@ -1,7 +1,8 @@
* Allwinner A10 MDIO Ethernet Controller interface
Required properties:
-- compatible: should be "allwinner,sun4i-mdio".
+- compatible: should be "allwinner,sun4i-a10-mdio"
+ (Deprecated: "allwinner,sun4i-mdio").
- reg: address and length of the register set for the device.
Optional properties:
@@ -9,7 +10,7 @@ Optional properties:
Example at the SoC level:
mdio@01c0b080 {
- compatible = "allwinner,sun4i-mdio";
+ compatible = "allwinner,sun4i-a10-mdio";
reg = <0x01c0b080 0x14>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/drivers/net/phy/mdio-sun4i.c b/drivers/net/phy/mdio-sun4i.c
index 18969b3..7f4a66d 100644
--- a/drivers/net/phy/mdio-sun4i.c
+++ b/drivers/net/phy/mdio-sun4i.c
@@ -171,6 +171,9 @@ static int sun4i_mdio_remove(struct platform_device *pdev)
}
static const struct of_device_id sun4i_mdio_dt_ids[] = {
+ { .compatible = "allwinner,sun4i-a10-mdio" },
+
+ /* Deprecated */
{ .compatible = "allwinner,sun4i-mdio" },
{ }
};
--
1.8.4.2
^ permalink raw reply related
* [PATCH 3/3] ARM: sunxi: dt: Convert to the new net compatibles
From: Maxime Ripard @ 2014-02-02 13:49 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-arm-kernel, Maxime Ripard
In-Reply-To: <1391348953-10662-1-git-send-email-maxime.ripard@free-electrons.com>
Switch the device tree to the new compatibles introduced in the ethernet and
mdio drivers to have a common pattern accross all Allwinner SoCs.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 4 ++--
arch/arm/boot/dts/sun5i-a10s.dtsi | 4 ++--
arch/arm/boot/dts/sun7i-a20.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 040bb0e..10666ca 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -315,7 +315,7 @@
ranges;
emac: ethernet@01c0b000 {
- compatible = "allwinner,sun4i-emac";
+ compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
interrupts = <55>;
clocks = <&ahb_gates 17>;
@@ -323,7 +323,7 @@
};
mdio@01c0b080 {
- compatible = "allwinner,sun4i-mdio";
+ compatible = "allwinner,sun4i-a10-mdio";
reg = <0x01c0b080 0x14>;
status = "disabled";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
index ea16054..6496159 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -278,7 +278,7 @@
ranges;
emac: ethernet@01c0b000 {
- compatible = "allwinner,sun4i-emac";
+ compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
interrupts = <55>;
clocks = <&ahb_gates 17>;
@@ -286,7 +286,7 @@
};
mdio@01c0b080 {
- compatible = "allwinner,sun4i-mdio";
+ compatible = "allwinner,sun4i-a10-mdio";
reg = <0x01c0b080 0x14>;
status = "disabled";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 119f066..9ff0948 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -340,7 +340,7 @@
ranges;
emac: ethernet@01c0b000 {
- compatible = "allwinner,sun4i-emac";
+ compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
interrupts = <0 55 4>;
clocks = <&ahb_gates 17>;
@@ -348,7 +348,7 @@
};
mdio@01c0b080 {
- compatible = "allwinner,sun4i-mdio";
+ compatible = "allwinner,sun4i-a10-mdio";
reg = <0x01c0b080 0x14>;
status = "disabled";
#address-cells = <1>;
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH v2 5/6] Documentation: devicetree: sja1000: add reg-io-width binding
From: Florian Vaussard @ 2014-02-03 8:11 UTC (permalink / raw)
To: Marc Kleine-Budde, Wolfgang Grandegger
Cc: linux-can, netdev, linux-kernel, Grant Likely, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree
In-Reply-To: <52EB9723.3080008@pengutronix.de>
On 01/31/2014 01:29 PM, Marc Kleine-Budde wrote:
> On 01/31/2014 11:35 AM, Florian Vaussard wrote:
>> Add the reg-io-width property to describe the width of the memory
>> accesses.
>>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> Cc: devicetree@vger.kernel.org
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
>
> I think it makes sense to squash into patch 6.
>
According to recent guidelines from the DT maintainers [1], the
documentation part should be a separate patch. I guess it makes sense to
ease the review process for new bindings.
Regards
Florian
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.txt
^ permalink raw reply
* Re: [PATCH net-stable 3.3..3.12] inet_diag: fix inet_diag_dump_icsk() timewait socket state logic
From: David Miller @ 2014-02-03 7:30 UTC (permalink / raw)
To: eric.dumazet; +Cc: ncardwell, netdev, edumazet
In-Reply-To: <1391399657.28432.93.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 02 Feb 2014 19:54:17 -0800
> On Sun, 2014-02-02 at 20:40 -0500, Neal Cardwell wrote:
> ...
>> An analogous fix is in v3.13: 70315d22d3c7383f9a508d0aab21e2eb35b2303a
>> ("inet_diag: fix inet_diag_dump_icsk() to use correct state for
>> timewait sockets") but that patch is quite different because 3.13 code
>> is very different in this area due to the unification of TCP hash
>> tables in 05dbc7b ("tcp/dccp: remove twchain") in v3.13-rc1.
> ...
>> Signed-off-by: Neal Cardwell <ncardwell@google.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> ---
>> net/ipv4/inet_diag.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Queued up, thanks Neal.
^ permalink raw reply
* Re: [PATCH] ipv6: default route for link local address is not added while assigning a address
From: Sohny Thomas @ 2014-02-03 7:19 UTC (permalink / raw)
To: Nicolas Dichtel, netdev, linux-kernel, yoshfuji, davem, kumuda
In-Reply-To: <20140130232909.GH25336@order.stressinduktion.org>
> Actually I am not so sure, there is no defined semantic of flush. I would
> be ok with all three solutions: leave it as is, always add link-local
> address (it does not matter if we don't have a link-local address on
> that interface, as a global scoped one is just fine enough) or make flush not
> remove the link-local address (but this seems a bit too special cased for me).
1) In case if we leave it as it is, there is rfc 6724 rule 2 to be
considered ( previously rfc 3484)
Rule 2: Prefer appropriate scope.
If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If
Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
Test:
Destination: fe80::2(LS)
Candidate Source Addresses: 3ffe::1(GS) or fec0::1(SS) or LLA(LS)
Result: LLA(LS)
Scope(LLA) < Scope(fec0::1): If Scope(LLA) < Scope(fe80::2), no,
prefer LLA
Scope(LLA) < Scope(3ffe::1): If Scope(LLA) < Scope(fe80::2), no,
prefer LLA
Now the above test fails since the route itself is not present, and the
test assumes that the route gets added since the LLA is not removed
during the test
2) having a LLA always helps in NDP i think
3) making flush not remove link-local address will be chnaging
functionality of ip flush command
Regards,
Sohny
>
> Greetings,
>
> Hannes
>
>
>
^ permalink raw reply
* Re: [PATCH] ipv6: default route for link local address is not added while assigning a address
From: Sohny Thomas @ 2014-02-03 7:02 UTC (permalink / raw)
To: nicolas.dichtel, netdev, linux-kernel, yoshfuji, davem, kumuda
In-Reply-To: <52E8DA37.7010208@6wind.com>
On Wednesday 29 January 2014 04:08 PM, Nicolas Dichtel wrote:
> Le 29/01/2014 07:41, Sohny Thomas a écrit :
>> Resending this on netdev mailing list:
>> Default route for link local address is configured automatically if
>> NETWORKING_IPV6=yes is in ifcfg-eth*.
>> When the route table for the interface is flushed and a new address is
>> added to
>> the same device with out removing linklocal addr, default route for
>> link local
>> address has to added by default.
>>
>> I have found the issue to be caused by this checkin
>>
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/ipv6?id=62b54dd91567686a1cb118f76a72d5f4764a86dd
>>
>>
>>
>> According to this change :
>> He removes adding a link local route if any other address is added ,
>> applicable
>> across all interfaces though there's mentioned only lo interface
>> So below patch fixes for other devices
>>
>> Signed-off-by: Sohny THomas <sohthoma@linux.vnet.ibm.com>
> Your email client has corrupted the patch, it cannot be applied.
> Please read Documentation/email-clients.txt
Sorry about that. Will resend again
>
> About the patch, I still think that the flush is too agressive. Link local
> routes are marked as 'proto kernel', removing them without the link local
> address is wrong.
>
> With this patch, you will add a link local route even if you don't have
> a link local address.
I think it wouldn't hurt to have a Link local route for NDP in case a
the routes become unreachable
-Regards,
Sohny
>
>
>
^ permalink raw reply
* [RFC PATCH] openvswitch: Use net_ratelimit in OVS_NLERR
From: Joe Perches @ 2014-02-03 6:55 UTC (permalink / raw)
To: Jesse Gross
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller,
dev-yBygre7rU0SM8Zsap4Y0gw
In-Reply-To: <1391389686-34303-6-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Perhaps it'd make sense to use net_ratelimit()
instead of printk_once for OVS_NLERR
---
net/openvswitch/datapath.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
index 6be9fbb..0f5e77c 100644
--- a/net/openvswitch/datapath.h
+++ b/net/openvswitch/datapath.h
@@ -194,7 +194,9 @@ struct sk_buff *ovs_vport_cmd_build_info(struct vport *, u32 pid, u32 seq,
int ovs_execute_actions(struct datapath *dp, struct sk_buff *skb);
void ovs_dp_notify_wq(struct work_struct *work);
-#define OVS_NLERR(fmt, ...) \
- pr_info_once("netlink: " fmt, ##__VA_ARGS__)
-
+#define OVS_NLERR(fmt, ...) \
+do { \
+ if (net_ratelimit()) \
+ pr_info("netlink: " fmt, ##__VA_ARGS__); \
+} while (0)
#endif /* datapath.h */
^ permalink raw reply related
* RE: [PATCH 11/34] benet: Use pci_enable_msix_range()
From: Sathya Perla @ 2014-02-03 6:21 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel@vger.kernel.org
Cc: Subramanian Seetharaman, Ajit Khaparde, netdev@vger.kernel.org,
linux-pci@vger.kernel.org
In-Reply-To: <0ab74b1142006d2e7a8065ec8a2d3ba48fc3ec0c.1391172839.git.agordeev@redhat.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf
> Of Alexander Gordeev
>
> As result of deprecation of MSI-X/MSI enablement functions
> pci_enable_msix() and pci_enable_msi_block() all drivers
> using these two interfaces need to be updated to use the
> new pci_enable_msi_range() and pci_enable_msix_range()
> interfaces.
>
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Acked-by: Sathya Perla < sathya.perla@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 31 +++++++++++---------------
> 1 files changed, 13 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
> b/drivers/net/ethernet/emulex/benet/be_main.c
> index 04ac9c6..f55c09b 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -2505,7 +2505,7 @@ static void be_msix_disable(struct be_adapter *adapter)
>
> static int be_msix_enable(struct be_adapter *adapter)
> {
> - int i, status, num_vec;
> + int i, num_vec;
> struct device *dev = &adapter->pdev->dev;
>
> /* If RoCE is supported, program the max number of NIC vectors that
> @@ -2521,24 +2521,11 @@ static int be_msix_enable(struct be_adapter *adapter)
> for (i = 0; i < num_vec; i++)
> adapter->msix_entries[i].entry = i;
>
> - status = pci_enable_msix(adapter->pdev, adapter->msix_entries, num_vec);
> - if (status == 0) {
> - goto done;
> - } else if (status >= MIN_MSIX_VECTORS) {
> - num_vec = status;
> - status = pci_enable_msix(adapter->pdev, adapter->msix_entries,
> - num_vec);
> - if (!status)
> - goto done;
> - }
> + num_vec = pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
> + MIN_MSIX_VECTORS, num_vec);
> + if (num_vec < 0)
> + goto fail;
>
> - dev_warn(dev, "MSIx enable failed\n");
> -
> - /* INTx is not supported in VFs, so fail probe if enable_msix fails */
> - if (!be_physfn(adapter))
> - return status;
> - return 0;
> -done:
> if (be_roce_supported(adapter) && num_vec > MIN_MSIX_VECTORS) {
> adapter->num_msix_roce_vec = num_vec / 2;
> dev_info(dev, "enabled %d MSI-x vector(s) for RoCE\n",
> @@ -2550,6 +2537,14 @@ done:
> dev_info(dev, "enabled %d MSI-x vector(s) for NIC\n",
> adapter->num_msix_vec);
> return 0;
> +
> +fail:
> + dev_warn(dev, "MSIx enable failed\n");
> +
> + /* INTx is not supported in VFs, so fail probe if enable_msix fails */
> + if (!be_physfn(adapter))
> + return num_vec;
> + return 0;
> }
>
> static inline int be_msix_vec_get(struct be_adapter *adapter,
> --
> 1.7.7.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* I want to invest this fund.
From: Ms.Sarah Angus @ 2014-02-03 4:33 UTC (permalink / raw)
Hi,
Can you assist me to invest funds in your Country? if yes, then get back to
me, so I can give you details and areas you can
participate by being my partner.
Ms. Sarah
^ permalink raw reply
* [PATCH V2] staging: r8188eu: Fix typo in USB_DEVICE list
From: Larry Finger @ 2014-02-03 4:23 UTC (permalink / raw)
To: gregkh; +Cc: netdev, devel, Larry Finger
There is a typo in the device list that interchanges the vendor and
product codes for one of the entries. This exchange was determined
by noticing that the vendor code is 0x07b8 for Abocom at
http://www.linux-usb.org/usb.ids.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
V2 - fix typo in revised version that was spotted by Randy Dunlap.
---
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..a70dcef 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(0x07b8, 0x8179)}, /* Abocom - Abocom */
{USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
{} /* Terminating entry */
};
--
1.8.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