* net-next is now OPEN
From: David Miller @ 2013-09-20 16:17 UTC (permalink / raw)
To: netdev; +Cc: netfilter-devel, linux-wireless
Please feel free to submit changes against it for the next merge
window.
Thanks.
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: David Miller @ 2013-09-20 16:15 UTC (permalink / raw)
To: jslaby; +Cc: ben, akpm, jeffm, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <523C7464.3070007@suse.cz>
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 20 Sep 2013 18:14:28 +0200
> On 09/20/2013 05:56 PM, David Miller wrote:
>> From: Jiri Slaby <jslaby@suse.cz>
>> Date: Fri, 20 Sep 2013 15:44:33 +0200
>>
>>> On 09/15/2013 01:28 AM, Ben Hutchings wrote:
>>>>> @@ -694,6 +699,10 @@ base_sock_ioctl(struct socket *sock, uns
>>>>> case IMSETDEVNAME: { struct mISDN_devrename dn; + if
>>>>> (!capable(CAP_SYS_ADMIN) && + !gid_eq(misdn_permitted_gid,
>>>>> current_gid()) && + !in_group_p(misdn_permitted_gid)) +
>>>>> return -EPERM; if (copy_from_user(&dn, (void __user *)arg,
>>>>> sizeof(dn))) { err = -EFAULT;
>>>>
>>>> This seems to be the important bit: renaming of devices (if allowed
>>>> at all) ought to be limited to CAP_SYS_ADMIN or possibly
>>>> CAP_NET_ADMIN. But why should the group that is allowed to use
>>>> mISDN data sockets also be allowed to do this?
>>>
>>> This is based on an old patch we are dragging in SUSE since 2009:
>>> http://www.isdn4linux.de/pipermail/isdn4linux/2009-December/004493.html
>>> https://bugzilla.novell.com/show_bug.cgi?id=564423
>>>
>>> The whole point of the gid-based access was to still allow some user
>>> group to manipulate the device in an arbitrary way.
>>>
>>> So if everybody agrees I will just disallow rename to
>>> non-CAP_NET_ADMIN users and we are done?
>>
>> No we are not done, sorry.
>>
>> Having a device specific module parameter for this is wrong on several
>> fundamental levels.
>
> What I'm suggesting is just to put a !capable(CAP_NET_ADMIN) test into
> the rename path and nothing more.
And I'm saying that regardless of such a change, the patch itself
is fundamentally implemented incorrectly and not acceptable for
upstream inclusion until the interface for configuration is changed.
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] xen-netback: handle frontends that fail to transition through Closing
From: Bastian Blank @ 2013-09-20 16:14 UTC (permalink / raw)
To: Paul Durrant; +Cc: netdev, Ian Campbell, Wei Liu, David Vrabel, xen-devel
In-Reply-To: <1379685460-25032-3-git-send-email-paul.durrant@citrix.com>
On Fri, Sep 20, 2013 at 02:57:40PM +0100, Paul Durrant wrote:
> Some old Windows frontends fail to transition through the xenbus Closing
> state and move directly from Connected to Closed. Handle this case properly.
What happens in this case? Are there other state changes that will do
unwanted things?
Bastian
--
If there are self-made purgatories, then we all have to live in them.
-- Spock, "This Side of Paradise", stardate 3417.7
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: Jiri Slaby @ 2013-09-20 16:14 UTC (permalink / raw)
To: David Miller; +Cc: ben, akpm, jeffm, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <20130920.115634.1931451843075283025.davem@davemloft.net>
On 09/20/2013 05:56 PM, David Miller wrote:
> From: Jiri Slaby <jslaby@suse.cz>
> Date: Fri, 20 Sep 2013 15:44:33 +0200
>
>> On 09/15/2013 01:28 AM, Ben Hutchings wrote:
>>>> @@ -694,6 +699,10 @@ base_sock_ioctl(struct socket *sock, uns
>>>> case IMSETDEVNAME: { struct mISDN_devrename dn; + if
>>>> (!capable(CAP_SYS_ADMIN) && + !gid_eq(misdn_permitted_gid,
>>>> current_gid()) && + !in_group_p(misdn_permitted_gid)) +
>>>> return -EPERM; if (copy_from_user(&dn, (void __user *)arg,
>>>> sizeof(dn))) { err = -EFAULT;
>>>
>>> This seems to be the important bit: renaming of devices (if allowed
>>> at all) ought to be limited to CAP_SYS_ADMIN or possibly
>>> CAP_NET_ADMIN. But why should the group that is allowed to use
>>> mISDN data sockets also be allowed to do this?
>>
>> This is based on an old patch we are dragging in SUSE since 2009:
>> http://www.isdn4linux.de/pipermail/isdn4linux/2009-December/004493.html
>> https://bugzilla.novell.com/show_bug.cgi?id=564423
>>
>> The whole point of the gid-based access was to still allow some user
>> group to manipulate the device in an arbitrary way.
>>
>> So if everybody agrees I will just disallow rename to
>> non-CAP_NET_ADMIN users and we are done?
>
> No we are not done, sorry.
>
> Having a device specific module parameter for this is wrong on several
> fundamental levels.
What I'm suggesting is just to put a !capable(CAP_NET_ADMIN) test into
the rename path and nothing more.
--
js
suse labs
^ permalink raw reply
* Re: IPv6 kernel warning
From: Michele Baldessari @ 2013-09-20 16:08 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: netdev, ycheng
In-Reply-To: <20130920131153.GF12758@n2100.arm.linux.org.uk>
Hi Russell,
On Fri, Sep 20, 2013 at 02:11:53PM +0100, Russell King - ARM Linux wrote:
> While running v3.11 on my firewall, I saw this warning. I'm not sure
> what it means or what its implications are:
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at /home/rmk/git/linux-rmk/net/ipv4/tcp_input.c:2711 tcp_fastretrans_alert+0x178/0x840()
> Modules linked in: ipt_REJECT xt_multiport iptable_filter ipt_MASQUERADE xt_nat
> xt_mark iptable_nat nf_nat_ipv4 nf_nat ip6table_mangle xt_LOG xt_limit nf_conntrack_ipv6 nf_defrag_ipv6 xt_state ip6table_filter pata_pcmcia libata scsi_mod 3c589_cs ide_gd_mod ide_cs ide_core sa1111_cs sa1100_cs sa11xx_base soc_common sa11x0_dma virt_dma usbcore usb_common
> CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0+ #15
> Backtrace:
> [<c02111a8>] (dump_backtrace+0x0/0x114) from [<c02115a0>] (show_stack+0x18/0x1c) r6:c0520824 r5:00000009 r4:00000000
> [<c0211588>] (show_stack+0x0/0x1c) from [<c04d65e0>] (dump_stack+0x20/0x28)
> [<c04d65c0>] (dump_stack+0x0/0x28) from [<c021bfb0>] (warn_slowpath_common+0x68/0x88)
> [<c021bf48>] (warn_slowpath_common+0x0/0x88) from [<c021bff4>] (warn_slowpath_null+0x24/0x28)
> r8:00000000 r7:00000001 r6:00000006 r5:00004320 r4:c11c6580
> [<c021bfd0>] (warn_slowpath_null+0x0/0x28) from [<c04515bc>] (tcp_fastretrans_alert+0x178/0x840)
> [<c0451444>] (tcp_fastretrans_alert+0x0/0x840) from [<c045273c>] (tcp_ack+0xa14/0xc18)
> [<c0451d28>] (tcp_ack+0x0/0xc18) from [<c0453138>] (tcp_rcv_established+0x494/0x594)
> [<c0452ca4>] (tcp_rcv_established+0x0/0x594) from [<c04a977c>] (tcp_v6_do_rcv+0xd0/0x428)
> [<c04a96ac>] (tcp_v6_do_rcv+0x0/0x428) from [<c04a9e70>] (tcp_v6_rcv+0x340/0x63c)
> [<c04a9b30>] (tcp_v6_rcv+0x0/0x63c) from [<c048b334>] (ip6_input_finish+0x214/0x3c4)
> [<c048b120>] (ip6_input_finish+0x0/0x3c4) from [<c048ba60>] (ip6_input+0x64/0x74)
> [<c048b9fc>] (ip6_input+0x0/0x74) from [<c048b564>] (ip6_rcv_finish+0x80/0x8c)
> r4:c1c9ee20
> [<c048b4e4>] (ip6_rcv_finish+0x0/0x8c) from [<c048b994>] (ipv6_rcv+0x424/0x48c)
> r4:c1c9ee20
> [<c048b570>] (ipv6_rcv+0x0/0x48c) from [<c0407624>] (__netif_receive_skb_core+0x618/0x688)
> r8:0000dd86 r7:00000000 r6:c11f6800 r5:c05ee6cc r4:c05f1b98
> [<c040700c>] (__netif_receive_skb_core+0x0/0x688) from [<c040770c>] (__netif_receive_skb+0x78/0x80)
> [<c0407694>] (__netif_receive_skb+0x0/0x80) from [<c04077a8>] (process_backlog+0x94/0x14c)
> r5:c06091e0 r4:c0609220
> [<c0407714>] (process_backlog+0x0/0x14c) from [<c0407af4>] (net_rx_action+0x78/0x1ac)
> [<c0407a7c>] (net_rx_action+0x0/0x1ac) from [<c021f500>] (__do_softirq+0xb4/0x198)
> [<c021f44c>] (__do_softirq+0x0/0x198) from [<c021f90c>] (irq_exit+0x74/0xc8)
> [<c021f898>] (irq_exit+0x0/0xc8) from [<c020f1ac>] (handle_IRQ+0x68/0x88)
> r4:0000000b
> [<c020f144>] (handle_IRQ+0x0/0x88) from [<c0208210>] (asm_do_IRQ+0x10/0x14)
> r5:60000013 r4:c0246818
> [<c0208200>] (asm_do_IRQ+0x0/0x14) from [<c0211fcc>] (__irq_svc+0x2c/0x98)
> Exception stack(0xc05e7f54 to 0xc05e7f9c)
> 7f40: 00000000 00000000 00000000
> 7f60: 60000013 c05e6000 c06092a4 c05ee080 00000001 c0204000 6901b115 c05e0800
> 7f80: c05e7fb8 c05e7f9c c05e7f9c c020f348 c0246818 60000013 ffffffff
> [<c0246794>] (cpu_startup_entry+0x0/0xe8) from [<c04d4d70>] (rest_init+0x64/0x7c)
> r7:c05f3940 r6:c0922200 r5:c0609340 r4:c05ee0c0
> [<c04d4d0c>] (rest_init+0x0/0x7c) from [<c05c3acc>] (start_kernel+0x350/0x3ac)
> [<c05c377c>] (start_kernel+0x0/0x3ac) from [<c0208040>] (0xc0208040)
> ---[ end trace ab55f0e3f592fa5e ]---
there's been multiple reports about this one:
https://bugzilla.redhat.com/show_bug.cgi?id=989251
http://bugzilla.kernel.org/show_bug.cgi?id=60779
Could you try Yuchung's debug patch?
http://www.spinics.net/lists/netdev/msg250193.html
thanks,
Michele
--
Michele Baldessari <michele@acksyn.org>
C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D
^ permalink raw reply
* Re: [PATCH] qlge: call ql_core_dump() only if dump memory was allocated.
From: David Miller @ 2013-09-20 16:02 UTC (permalink / raw)
To: malahal; +Cc: netdev
In-Reply-To: <1379691031-28666-1-git-send-email-malahal@us.ibm.com>
From: Malahal Naineni <malahal@us.ibm.com>
Date: Fri, 20 Sep 2013 10:30:31 -0500
> Also changed a log message to indicate that memory was not allocated
> instead of memory not available!
This change is not submitted properly, in particular it is missing
a signoff.
^ permalink raw reply
* Re: [PATCH] stable_kernel_rules.txt: Exclude networking from stable rules
From: David Miller @ 2013-09-20 15:59 UTC (permalink / raw)
To: joe; +Cc: stephen, netdev, mpatocka, gregkh, rob, linux-doc, linux-kernel
In-Reply-To: <1379688880.2021.38.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Fri, 20 Sep 2013 07:54:40 -0700
> On Thu, 2013-09-19 at 11:31 -0700, Joe Perches wrote:
>> Networking is once again "special", so at least document
>> how it's working today in the hope that doing so makes
>> less work for all that actually read the documentation.
>
> David, why did you mark this N/A is patchwork?
> It's your rule, why not document it?
Because it should go through whoever maintains that document, and
that isn't me.
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: David Miller @ 2013-09-20 15:56 UTC (permalink / raw)
To: jslaby; +Cc: ben, akpm, jeffm, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <523C5141.4080608@suse.cz>
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 20 Sep 2013 15:44:33 +0200
> On 09/15/2013 01:28 AM, Ben Hutchings wrote:
>>> @@ -694,6 +699,10 @@ base_sock_ioctl(struct socket *sock, uns
>>> case IMSETDEVNAME: { struct mISDN_devrename dn; + if
>>> (!capable(CAP_SYS_ADMIN) && + !gid_eq(misdn_permitted_gid,
>>> current_gid()) && + !in_group_p(misdn_permitted_gid)) +
>>> return -EPERM; if (copy_from_user(&dn, (void __user *)arg,
>>> sizeof(dn))) { err = -EFAULT;
>>
>> This seems to be the important bit: renaming of devices (if allowed
>> at all) ought to be limited to CAP_SYS_ADMIN or possibly
>> CAP_NET_ADMIN. But why should the group that is allowed to use
>> mISDN data sockets also be allowed to do this?
>
> This is based on an old patch we are dragging in SUSE since 2009:
> http://www.isdn4linux.de/pipermail/isdn4linux/2009-December/004493.html
> https://bugzilla.novell.com/show_bug.cgi?id=564423
>
> The whole point of the gid-based access was to still allow some user
> group to manipulate the device in an arbitrary way.
>
> So if everybody agrees I will just disallow rename to
> non-CAP_NET_ADMIN users and we are done?
No we are not done, sorry.
Having a device specific module parameter for this is wrong on several
fundamental levels.
Module parameters are wrong because you're going to eventually want to
do this for other ISDN or other devices, and nobody is going to make
sure the name of the parameter nor the semantics all match up.
This is the worst possible user experience.
You need to make it so that there is a standard, regular, interface
for performing this task or making this setting. Module parameters
are not it.
The reason this patch has rotted since 2009 is that it really is far
from suitable for upstream inclusion, and I really don't see that much
thought or care has been put into how it is implemented, so I wonder
how much anyone really cares about the change.
^ permalink raw reply
* Re: [PATCH 18/51] DMA-API: staging: et131x: replace dma_set_mask()+dma_set_coherent_mask() with new helper
From: Ben Hutchings @ 2013-09-20 15:42 UTC (permalink / raw)
To: Russell King; +Cc: devel, netdev
In-Reply-To: <E1VMm05-0007hG-5T@rmk-PC.arm.linux.org.uk>
[Trimmed cc's]
On Thu, 2013-09-19 at 22:43 +0100, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/staging/et131x/et131x.c | 17 ++---------------
> 1 files changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
> index f73e58f..98edfa8 100644
> --- a/drivers/staging/et131x/et131x.c
> +++ b/drivers/staging/et131x/et131x.c
> @@ -4797,21 +4797,8 @@ static int et131x_pci_setup(struct pci_dev *pdev,
> pci_set_master(pdev);
>
> /* Check the DMA addressing support of this device */
> - if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64))) {
> - rc = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
> - if (rc < 0) {
> - dev_err(&pdev->dev,
> - "Unable to obtain 64 bit DMA for consistent allocations\n");
> - goto err_release_res;
> - }
> - } else if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(32))) {
> - rc = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> - if (rc < 0) {
> - dev_err(&pdev->dev,
> - "Unable to obtain 32 bit DMA for consistent allocations\n");
> - goto err_release_res;
> - }
> - } else {
> + if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)) ||
> + dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32))) {
Surely we want && here.
Ben.
> dev_err(&pdev->dev, "No usable DMA addressing method\n");
> rc = -EIO;
> goto err_release_res;
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] skge: fix broken driver
From: Igor Gnatenko @ 2013-09-20 15:35 UTC (permalink / raw)
To: Mikulas Patocka; +Cc: Francois Romieu, David Miller, stephen, netdev
In-Reply-To: <alpine.LRH.2.02.1309201030420.30821@file01.intranet.prod.int.rdu2.redhat.com>
On Fri, 2013-09-20 at 10:32 -0400, Mikulas Patocka wrote:
>
>
> On Thu, 19 Sep 2013, Francois Romieu wrote:
>
> > Mikulas Patocka <mpatocka@redhat.com> :
> > [...]
> > > I see. My patch is a bit simpler - it doesn't allocate the structure
> > > skge_element on the stack.
> >
> > Both patches don't behave exactly the same wrt pci_unmap_single.
> >
> > --
> > Ueimor
>
> I see, my patch passes a wrong value to pci_unmap_single. So I made this
> change to make it pass the correct value. Do you agree with this patch?
>
> ---
>
> skge: fix invalid value passed to pci_unmap_sigle
>
> In my patch c194992cbe71c20bb3623a566af8d11b0bfaa721 I didn't fix the skge
> bug correctly. The value of the new mapping (not old) was passed to
> pci_unmap_single.
>
> If we enable CONFIG_DMA_API_DEBUG, it results in this warning:
> WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:986 check_sync+0x4c4/0x580()
> skge 0000:02:07.0: DMA-API: device driver tries to sync DMA memory it has
> not allocated [device address=0x000000023a0096c0] [size=1536 bytes]
>
> This patch makes the skge driver pass the correct value to
> pci_unmap_single and fixes the warning. It copies the old descriptor to
> on-stack variable "ee" and unmaps it if mapping of the new descriptor
> succeeded.
>
> This patch should be backported to 3.11-stable.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Reported-by: Francois Romieu <romieu@fr.zoreil.com>
> Tested-by: Mikulas Patocka <mpatocka@redhat.com>
>
> ---
> drivers/net/ethernet/marvell/skge.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> Index: linux-3.11.1-fast/drivers/net/ethernet/marvell/skge.c
> ===================================================================
> --- linux-3.11.1-fast.orig/drivers/net/ethernet/marvell/skge.c 2013-09-20 16:13:24.000000000 +0200
> +++ linux-3.11.1-fast/drivers/net/ethernet/marvell/skge.c 2013-09-20 16:18:13.000000000 +0200
> @@ -3086,13 +3086,16 @@ static struct sk_buff *skge_rx_get(struc
> PCI_DMA_FROMDEVICE);
> skge_rx_reuse(e, skge->rx_buf_size);
> } else {
> + struct skge_element ee;
> struct sk_buff *nskb;
>
> nskb = netdev_alloc_skb_ip_align(dev, skge->rx_buf_size);
> if (!nskb)
> goto resubmit;
>
> - skb = e->skb;
> + ee = *e;
> +
> + skb = ee.skb;
> prefetch(skb->data);
>
> if (skge_rx_setup(skge, e, nskb, skge->rx_buf_size) < 0) {
> @@ -3101,8 +3104,8 @@ static struct sk_buff *skge_rx_get(struc
> }
>
> pci_unmap_single(skge->hw->pdev,
> - dma_unmap_addr(e, mapaddr),
> - dma_unmap_len(e, maplen),
> + dma_unmap_addr(&ee, mapaddr),
> + dma_unmap_len(&ee, maplen),
> PCI_DMA_FROMDEVICE);
> }
>
Mikulas, I think you should send this patch separate..
--
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.11.1-300.fc20.x86_64
^ permalink raw reply
* [PATCH] qlge: call ql_core_dump() only if dump memory was allocated.
From: Malahal Naineni @ 2013-09-20 15:30 UTC (permalink / raw)
To: netdev
Also changed a log message to indicate that memory was not allocated
instead of memory not available!
---
drivers/net/ethernet/qlogic/qlge/qlge_dbg.c | 4 ++--
drivers/net/ethernet/qlogic/qlge/qlge_mpi.c | 12 +++++++-----
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c b/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
index 10093f0..6bc5db7 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
@@ -740,8 +740,8 @@ int ql_core_dump(struct ql_adapter *qdev, struct ql_mpi_coredump *mpi_coredump)
int i;
if (!mpi_coredump) {
- netif_err(qdev, drv, qdev->ndev, "No memory available\n");
- return -ENOMEM;
+ netif_err(qdev, drv, qdev->ndev, "No memory allocated\n");
+ return -EINVAL;
}
/* Try to get the spinlock, but dont worry if
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c b/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c
index ff2bf8a..99a3e07 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_mpi.c
@@ -1274,11 +1274,13 @@ void ql_mpi_reset_work(struct work_struct *work)
return;
}
- if (!ql_core_dump(qdev, qdev->mpi_coredump)) {
- netif_err(qdev, drv, qdev->ndev, "Core is dumped!\n");
- qdev->core_is_dumped = 1;
- queue_delayed_work(qdev->workqueue,
- &qdev->mpi_core_to_log, 5 * HZ);
+ if (qdev->mpi_coredump) {
+ if (!ql_core_dump(qdev, qdev->mpi_coredump)) {
+ netif_err(qdev, drv, qdev->ndev, "Core is dumped!\n");
+ qdev->core_is_dumped = 1;
+ queue_delayed_work(qdev->workqueue,
+ &qdev->mpi_core_to_log, 5 * HZ);
+ }
}
ql_soft_reset_mpi_risc(qdev);
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
From: Felipe Balbi @ 2013-09-20 15:15 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Felipe Balbi, linux-crypto,
Greg Kroah-Hartman, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130920134938.GO25647@n2100.arm.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1239 bytes --]
Hi,
On Fri, Sep 20, 2013 at 02:49:38PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > > Use platform_device_register_full() for those drivers which can, to
> > > avoid messing directly with DMA masks. This can only be done when
> > > the driver does not need to access the allocated musb platform device
> > > from within its callbacks, which may be called during the musb
> > > device probing.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >
> > you want me to carry this one through my tree or you prefer getting my
> > Acked-by ? Either way works for me:
> >
> > Acked-by: Felipe Balbi <balbi@ti.com>
> >
> > there's also the third option of me setting up a branch with only this
> > patch and we both merge it, that'd also work.
>
> I think this patch is sufficiently stand-alone that it should be fine
> if you want to take it through your tree. That may be better in the
> long run to avoid conflicts with this patch and any future work in
> this area during this cycle.
awesome, i'll take this one early next week.
--
balbi
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* RE: [PATCH net-next 1/2] xen-netback: add a vif-is-connected flag
From: Paul Durrant @ 2013-09-20 15:02 UTC (permalink / raw)
To: David Vrabel, Wei Liu
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org, Ian Campbell
In-Reply-To: <523C5BA7.2010500@citrix.com>
> -----Original Message-----
> From: David Vrabel
> Sent: 20 September 2013 15:29
> To: Wei Liu
> Cc: Paul Durrant; netdev@vger.kernel.org; xen-devel@lists.xen.org; Ian
> Campbell
> Subject: Re: [PATCH net-next 1/2] xen-netback: add a vif-is-connected flag
>
> On 20/09/13 14:31, Wei Liu wrote:
> > On Fri, Sep 20, 2013 at 01:56:30PM +0100, Paul Durrant wrote:
> >> Having applied my patch to separate vif disconnect and free, I ran into a
> >> BUG when testing resume from S3 with a Windows frontend because the
> vif task
> >> pointer was not cleared by xenvif_disconnect() and so a double call to this
> >> function tries to stop the thread twice.
> >> Rather than applying a point fix for that issue it seems better to introduce
> >> a boolean to indicate whether the vif is connected or not such that
> repeated
> >> calls to either xenvif_connect() or xenvif_disconnect() behave
> appropriately.
>
> We already have a backend state of CONNECTED/CLOSED/etc. why do we
> need
> an additional bit of state outside of this?
>
It's not really additional state; we were essentially inferring connected-ness from the value of tx_irq. This patch really just removes that inference and created something with the intended meaning.
> Does something like this in frontend_changed() fix it?
>
It may well do, but it's a far more invasive change and would require more testing. It certainly sounds like a good thing to do in the longer term.
Paul
> case XenbusStateClosing:
> switch (dev->state) {
> case XenbusStateClosed;
> break;
> case XenbusStateConnected:
> disconnect_backend(dev);
> /* fall through */
> default:
> xenbus_switch_state(dev, XenbusStateClosing);
> break;
> }
> break;
>
> case XenbusStateClosed:
> switch (dev->state) {
> case XenbusStateConnected;
> disconnect_backend(dev);
> /* fall through */
> default:
> xenbus_switch_state(dev, XenbusStateClosed);
> break;
> }
> if (xenbus_dev_is_online(dev))
> break;
> /* fall through if not online */
>
> Can you also remove destroy_backend()? It's not needed any more.
>
> I'd also recommend waiting a bit for other review feedback before
> posting an updated series.
>
> David
^ permalink raw reply
* Re: [PATCH] stable_kernel_rules.txt: Exclude networking from stable rules
From: Joe Perches @ 2013-09-20 14:54 UTC (permalink / raw)
To: David Miller
Cc: stephen, netdev, Mikulas Patocka, Greg Kroah-Hartman, Rob Landley,
linux-doc, LKML
In-Reply-To: <1379615474.22168.13.camel@joe-AO722>
On Thu, 2013-09-19 at 11:31 -0700, Joe Perches wrote:
> Networking is once again "special", so at least document
> how it's working today in the hope that doing so makes
> less work for all that actually read the documentation.
David, why did you mark this N/A is patchwork?
It's your rule, why not document it?
^ permalink raw reply
* Re: [PATCH v2] skge: fix broken driver
From: Stephen Hemminger @ 2013-09-20 14:36 UTC (permalink / raw)
To: Mikulas Patocka; +Cc: David Miller, netdev, Vasiliy Glazov
In-Reply-To: <alpine.LRH.2.02.1309191409301.12162@file01.intranet.prod.int.rdu2.redhat.com>
On Thu, 19 Sep 2013 14:13:17 -0400 (EDT)
Mikulas Patocka <mpatocka@redhat.com> wrote:
> The patch 136d8f377e1575463b47840bc5f1b22d94bf8f63 broke the skge driver.
> Note this part of the patch:
> + if (skge_rx_setup(skge, e, nskb, skge->rx_buf_size) < 0) {
> + dev_kfree_skb(nskb);
> + goto resubmit;
> + }
> +
> pci_unmap_single(skge->hw->pdev,
> dma_unmap_addr(e, mapaddr),
> dma_unmap_len(e, maplen),
> PCI_DMA_FROMDEVICE);
> skb = e->skb;
> prefetch(skb->data);
> - skge_rx_setup(skge, e, nskb, skge->rx_buf_size);
>
> The function skge_rx_setup modifies e->skb to point to the new skb. Thus,
> after this change, the new buffer, not the old, is returned to the
> networking stack.
>
> This bug is present in kernels 3.11, 3.11.1 and 3.12-rc1. The patch should
> be queued for 3.11-stable.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Reported-by: Mikulas Patocka <mpatocka@redhat.com>
> Reported-by: Vasiliy Glazov <vascom2@gmail.com>
> Tested-by: Mikulas Patocka <mpatocka@redhat.com>
>
Thanks for fixing this. Maybe I should go on vacation more often.
^ permalink raw reply
* Re: [PATCH] skge: fix broken driver
From: Mikulas Patocka @ 2013-09-20 14:32 UTC (permalink / raw)
To: Francois Romieu; +Cc: Igor Gnatenko, David Miller, stephen, netdev
In-Reply-To: <20130919213218.GA31672@electric-eye.fr.zoreil.com>
On Thu, 19 Sep 2013, Francois Romieu wrote:
> Mikulas Patocka <mpatocka@redhat.com> :
> [...]
> > I see. My patch is a bit simpler - it doesn't allocate the structure
> > skge_element on the stack.
>
> Both patches don't behave exactly the same wrt pci_unmap_single.
>
> --
> Ueimor
I see, my patch passes a wrong value to pci_unmap_single. So I made this
change to make it pass the correct value. Do you agree with this patch?
---
skge: fix invalid value passed to pci_unmap_sigle
In my patch c194992cbe71c20bb3623a566af8d11b0bfaa721 I didn't fix the skge
bug correctly. The value of the new mapping (not old) was passed to
pci_unmap_single.
If we enable CONFIG_DMA_API_DEBUG, it results in this warning:
WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:986 check_sync+0x4c4/0x580()
skge 0000:02:07.0: DMA-API: device driver tries to sync DMA memory it has
not allocated [device address=0x000000023a0096c0] [size=1536 bytes]
This patch makes the skge driver pass the correct value to
pci_unmap_single and fixes the warning. It copies the old descriptor to
on-stack variable "ee" and unmaps it if mapping of the new descriptor
succeeded.
This patch should be backported to 3.11-stable.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reported-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/net/ethernet/marvell/skge.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: linux-3.11.1-fast/drivers/net/ethernet/marvell/skge.c
===================================================================
--- linux-3.11.1-fast.orig/drivers/net/ethernet/marvell/skge.c 2013-09-20 16:13:24.000000000 +0200
+++ linux-3.11.1-fast/drivers/net/ethernet/marvell/skge.c 2013-09-20 16:18:13.000000000 +0200
@@ -3086,13 +3086,16 @@ static struct sk_buff *skge_rx_get(struc
PCI_DMA_FROMDEVICE);
skge_rx_reuse(e, skge->rx_buf_size);
} else {
+ struct skge_element ee;
struct sk_buff *nskb;
nskb = netdev_alloc_skb_ip_align(dev, skge->rx_buf_size);
if (!nskb)
goto resubmit;
- skb = e->skb;
+ ee = *e;
+
+ skb = ee.skb;
prefetch(skb->data);
if (skge_rx_setup(skge, e, nskb, skge->rx_buf_size) < 0) {
@@ -3101,8 +3104,8 @@ static struct sk_buff *skge_rx_get(struc
}
pci_unmap_single(skge->hw->pdev,
- dma_unmap_addr(e, mapaddr),
- dma_unmap_len(e, maplen),
+ dma_unmap_addr(&ee, mapaddr),
+ dma_unmap_len(&ee, maplen),
PCI_DMA_FROMDEVICE);
}
^ permalink raw reply
* Re: [PATCH net-next 1/2] xen-netback: add a vif-is-connected flag
From: David Vrabel @ 2013-09-20 14:28 UTC (permalink / raw)
To: Wei Liu; +Cc: Paul Durrant, netdev, xen-devel, Ian Campbell
In-Reply-To: <20130920133106.GB457@zion.uk.xensource.com>
On 20/09/13 14:31, Wei Liu wrote:
> On Fri, Sep 20, 2013 at 01:56:30PM +0100, Paul Durrant wrote:
>> Having applied my patch to separate vif disconnect and free, I ran into a
>> BUG when testing resume from S3 with a Windows frontend because the vif task
>> pointer was not cleared by xenvif_disconnect() and so a double call to this
>> function tries to stop the thread twice.
>> Rather than applying a point fix for that issue it seems better to introduce
>> a boolean to indicate whether the vif is connected or not such that repeated
>> calls to either xenvif_connect() or xenvif_disconnect() behave appropriately.
We already have a backend state of CONNECTED/CLOSED/etc. why do we need
an additional bit of state outside of this?
Does something like this in frontend_changed() fix it?
case XenbusStateClosing:
switch (dev->state) {
case XenbusStateClosed;
break;
case XenbusStateConnected:
disconnect_backend(dev);
/* fall through */
default:
xenbus_switch_state(dev, XenbusStateClosing);
break;
}
break;
case XenbusStateClosed:
switch (dev->state) {
case XenbusStateConnected;
disconnect_backend(dev);
/* fall through */
default:
xenbus_switch_state(dev, XenbusStateClosed);
break;
}
if (xenbus_dev_is_online(dev))
break;
/* fall through if not online */
Can you also remove destroy_backend()? It's not needed any more.
I'd also recommend waiting a bit for other review feedback before
posting an updated series.
David
^ permalink raw reply
* Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
From: Russell King - ARM Linux @ 2013-09-20 14:12 UTC (permalink / raw)
To: Ben Hutchings
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Dan Williams,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Solarflare linux maintainers, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Vinod Koul,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Rob Landley,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1379640097.2500.4.camel-/LGg1Z1CJKQ+9kgCwbf1HqK4ta4zdZpAajtMo4Cw6ucAvxtiuMwx3w@public.gmane.org>
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
> On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> [...]
> > -dma_set_coherent_mask() will always be able to set the same or a
> > -smaller mask as dma_set_mask(). However for the rare case that a
> > +The coherent coherent mask will always be able to set the same or a
> > +smaller mask as the streaming mask. However for the rare case that a
> [...]
>
> The new wording doesn't make sense; a mask doesn't set itself. I would
> suggest:
>
> "The coherent mask can always be set to the same or a smaller mask than
> the streaming mask."
Yes, the original sentence is not particularly good, but I think even
your modified version can be interpreted as "a mask setting itself"
for all the same reasons that the original can be (which mask does "same"
refer to?)
Even so, I prefer your version. Thanks. :)
^ permalink raw reply
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Russell King - ARM Linux @ 2013-09-20 14:00 UTC (permalink / raw)
To: Tejun Heo
Cc: alsa-devel, linux-doc, David Airlie, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, Joonyoung Shim,
linux-scsi, e1000-devel, Seung-Woo Kim, b43-dev, linux-media,
devicetree, Inki Dae, Kukjin Kim, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Kyungmin Park
In-Reply-To: <20130920121652.GA7630@mtj.dyndns.org>
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code should access this
> > member directly.
> >
> > Convert all direct write accesses to using the correct API.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> The patch is pretty widely spread. I don't mind how it gets routed
> but what's the plan?
The plan is... I'm going to try and avoid going through the hell of
re-posting this patch series to all the recipients another time...
(It's taken some 17 hours and lots of hand holding to get this patch
set out without exim jumping off a cliff into deep OOM - soo deep that
even the OOM killer doesn't run and the CPU is 100% idle because
every single process stuck in an uninterruptible sleep waiting for
every other process to free some memory - ouch!)
I know that dealing with this patch set will be a problem due to how
widespread this is, but much of the driver level changes come down to
depending on a couple of patches. One solution would be if I published
a branch with just the dependencies in, which subsystem maintainers
could pull, and then apply the appropriate patches on top.
Another would be if subsystem maintainers are happy that I carry them,
I can add the acks, and then later on towards the end of the cycle,
provide a branch subsystem maintainers could pull.
Or... if you can think of something easier...
^ permalink raw reply
* [PATCH net-next v2 2/2] xen-netback: handle frontends that fail to transition through Closing
From: Paul Durrant @ 2013-09-20 13:57 UTC (permalink / raw)
To: netdev, xen-devel; +Cc: Paul Durrant, David Vrabel, Wei Liu, Ian Campbell
In-Reply-To: <1379685460-25032-1-git-send-email-paul.durrant@citrix.com>
Some old Windows frontends fail to transition through the xenbus Closing
state and move directly from Connected to Closed. Handle this case properly.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
drivers/net/xen-netback/xenbus.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index a53782e..684b0f6 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -265,6 +265,13 @@ static void frontend_changed(struct xenbus_device *dev,
break;
case XenbusStateClosed:
+ /*
+ * Handle frontends which erroneously transition
+ * directly from Connected to Closed.
+ */
+ if (dev->state == XenbusStateConnected)
+ disconnect_backend(dev);
+
xenbus_switch_state(dev, XenbusStateClosed);
if (xenbus_dev_is_online(dev))
break;
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v2 1/2] xen-netback: add a vif-is-connected flag
From: Paul Durrant @ 2013-09-20 13:57 UTC (permalink / raw)
To: netdev, xen-devel; +Cc: Paul Durrant, David Vrabel, Wei Liu, Ian Campbell
In-Reply-To: <1379685460-25032-1-git-send-email-paul.durrant@citrix.com>
Having applied my patch to separate vif disconnect and free, I ran into a
BUG when testing resume from S3 with a Windows frontend because the vif task
pointer was not cleared by xenvif_disconnect() and so a double call to this
function tries to stop the thread twice.
Rather than applying a point fix for that issue it seems better to introduce
a boolean to indicate whether the vif is connected or not such that repeated
calls to either xenvif_connect() or xenvif_disconnect() behave appropriately.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
drivers/net/xen-netback/common.h | 1 +
drivers/net/xen-netback/interface.c | 24 +++++++++++++-----------
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 5715318..860d92c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -169,6 +169,7 @@ struct xenvif {
/* Miscellaneous private stuff. */
struct net_device *dev;
+ bool connected;
};
static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 01bb854..94b47f5 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -366,7 +366,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
int err = -ENOMEM;
/* Already connected through? */
- if (vif->tx_irq)
+ if (vif->connected)
return 0;
err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
@@ -425,6 +425,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
wake_up_process(vif->task);
+ vif->connected = 1;
return 0;
err_rx_unbind:
@@ -453,23 +454,24 @@ void xenvif_carrier_off(struct xenvif *vif)
void xenvif_disconnect(struct xenvif *vif)
{
+ if (!vif->connected)
+ return;
+
if (netif_carrier_ok(vif->dev))
xenvif_carrier_off(vif);
- if (vif->tx_irq) {
- if (vif->tx_irq == vif->rx_irq)
- unbind_from_irqhandler(vif->tx_irq, vif);
- else {
- unbind_from_irqhandler(vif->tx_irq, vif);
- unbind_from_irqhandler(vif->rx_irq, vif);
- }
- vif->tx_irq = 0;
+ if (vif->tx_irq == vif->rx_irq)
+ unbind_from_irqhandler(vif->tx_irq, vif);
+ else {
+ unbind_from_irqhandler(vif->tx_irq, vif);
+ unbind_from_irqhandler(vif->rx_irq, vif);
}
- if (vif->task)
- kthread_stop(vif->task);
+ kthread_stop(vif->task);
xenvif_unmap_frontend_rings(vif);
+
+ vif->connected = 0;
}
void xenvif_free(struct xenvif *vif)
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next 0/2] xen-netback: windows frontend compatibility fixes
From: Paul Durrant @ 2013-09-20 13:57 UTC (permalink / raw)
To: netdev, xen-devel
The following patches fix a couple more issues found when testing with
Windows frontends.
v2:
- Add comment in 2/2 to note that state transitions from Connected to Closed
are incorrect.
^ permalink raw reply
* Re: [PATCH 13/51] DMA-API: net: sfc/efx.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper
From: Ben Hutchings @ 2013-09-20 13:55 UTC (permalink / raw)
To: Russell King; +Cc: netdev, Solarflare linux maintainers
In-Reply-To: <E1VMlvE-0007gc-B5@rmk-PC.arm.linux.org.uk>
[Trimmed cc's]
On Thu, 2013-09-19 at 22:38 +0100, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> drivers/net/ethernet/sfc/efx.c | 12 +-----------
> 1 files changed, 1 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
> index 07c9bc4..2e27837 100644
> --- a/drivers/net/ethernet/sfc/efx.c
> +++ b/drivers/net/ethernet/sfc/efx.c
> @@ -1121,7 +1121,7 @@ static int efx_init_io(struct efx_nic *efx)
> */
> while (dma_mask > 0x7fffffffUL) {
> if (dma_supported(&pci_dev->dev, dma_mask)) {
> - rc = dma_set_mask(&pci_dev->dev, dma_mask);
> + rc = dma_set_mask_and_coherent(&pci_dev->dev, dma_mask);
> if (rc == 0)
> break;
> }
> @@ -1134,16 +1134,6 @@ static int efx_init_io(struct efx_nic *efx)
> }
> netif_dbg(efx, probe, efx->net_dev,
> "using DMA mask %llx\n", (unsigned long long) dma_mask);
> - rc = dma_set_coherent_mask(&pci_dev->dev, dma_mask);
> - if (rc) {
> - /* dma_set_coherent_mask() is not *allowed* to
> - * fail with a mask that dma_set_mask() accepted,
> - * but just in case...
> - */
> - netif_err(efx, probe, efx->net_dev,
> - "failed to set consistent DMA mask\n");
> - goto fail2;
> - }
>
> efx->membase_phys = pci_resource_start(efx->pci_dev, EFX_MEM_BAR);
> rc = pci_request_region(pci_dev, EFX_MEM_BAR, "sfc");
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
From: Russell King - ARM Linux @ 2013-09-20 13:49 UTC (permalink / raw)
To: Felipe Balbi
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, linux-crypto,
Greg Kroah-Hartman, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130920131125.GO26101@radagast>
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > Use platform_device_register_full() for those drivers which can, to
> > avoid messing directly with DMA masks. This can only be done when
> > the driver does not need to access the allocated musb platform device
> > from within its callbacks, which may be called during the musb
> > device probing.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> you want me to carry this one through my tree or you prefer getting my
> Acked-by ? Either way works for me:
>
> Acked-by: Felipe Balbi <balbi@ti.com>
>
> there's also the third option of me setting up a branch with only this
> patch and we both merge it, that'd also work.
I think this patch is sufficiently stand-alone that it should be fine
if you want to take it through your tree. That may be better in the
long run to avoid conflicts with this patch and any future work in
this area during this cycle.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/2] xen-netback: handle frontends that fail to transition through Closing
From: Wei Liu @ 2013-09-20 13:48 UTC (permalink / raw)
To: David Vrabel; +Cc: Wei Liu, Paul Durrant, netdev, xen-devel, Ian Campbell
In-Reply-To: <523C4FE6.30309@citrix.com>
On Fri, Sep 20, 2013 at 02:38:46PM +0100, David Vrabel wrote:
> On 20/09/13 14:34, Wei Liu wrote:
> > On Fri, Sep 20, 2013 at 01:56:31PM +0100, Paul Durrant wrote:
> >> Some old Windows frontends fail to transition through the xenbus Closing
> >> state and move directly from Connected to Closed. Handle this case properly.
> >>
> >> --- a/drivers/net/xen-netback/xenbus.c
> >> +++ b/drivers/net/xen-netback/xenbus.c
> >> @@ -265,6 +265,8 @@ static void frontend_changed(struct xenbus_device *dev,
> >> break;
> >>
> >> case XenbusStateClosed:
> >> + if (dev->state == XenbusStateConnected)
> >> + disconnect_backend(dev);
> >
> > Could you please add a comment above this change stating that this is a
> > workaround for some old frontend that we cannot fix / upgrade.
>
> Handling frontend CONNECTED -> CLOSED is a sensible thing for a backend
> to do regardless of whether there are old frontends that do this or not.
>
I agree handling connected -> closed is sensible here based on the fact
that old frontends could do such state change. However If the state
machine was documented well enough then I think connected -> closed
would not be considered sensible.
This code snippet without comment will cause confusion / encourage wrong
usage of state machine if someone comes here for reference.
> > We would still like to later frontend goes through the normal connected
> > -> closing -> closed path.
>
> This should be documented as a full description of the two state
> machines in public/io/netif.h in Xen. Not scattered about in comments
Sure.
> in a particular backend implementation.
>
The comment in implementation is still worthwhile in case someone comes
here for reference and gets confused.
Wei.
> David
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox