From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: keystone: add bus notifier to set dma_pfn_offset for pci devices
Date: Fri, 10 Oct 2014 11:46:50 -0400 [thread overview]
Message-ID: <5437FF6A.9030203@ti.com> (raw)
In-Reply-To: <20141010154258.GN5182@n2100.arm.linux.org.uk>
On 10/10/14 11:42 AM, Russell King - ARM Linux wrote:
> On Fri, Oct 10, 2014 at 11:29:03AM -0400, Santosh Shilimkar wrote:
>>
>>
>> On 10/10/14 11:15 AM, Murali Karicheri wrote:
>>> When PCI device driver such as that for e1000e tries to set dma mask
>>> using dma_set_mask_and_coherent(), it fails because the dma_pfn_offset
>>> is incorrect on a Keystone SoC. This patch fix this by adding a bus
>>> notifier to set this correctly for PCI devices.
>>>
>>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>>> ---
>> Looks good. I will pick this up after the merge window.
>
> No it doesn't, this patch is crap. Really. Let's look again at what the
> patch is doing:
>
> if (platform_nb.notifier_call)
> bus_register_notifier(&platform_bus_type, &platform_nb);
> + if (platform_nb.notifier_call)
> + bus_register_notifier(&pci_bus_type, &platform_nb);
>
> Notice that both calls are using the same platform_nb structure, which is:
>
> static struct notifier_block platform_nb;
>
> and in turn this is:
>
> struct notifier_block {
> notifier_fn_t notifier_call;
> struct notifier_block __rcu *next;
> int priority;
> };
>
> Notice that "next" pointer - these blocks are used as a single-linked list.
> So, this block gets registered for the platform bus, and is inserted into
> that bus notifier chain. That means "next" may be set to a non-NULL
> next notifier block.
>
> Then it gets registered against the PCI bus, which *will* overwrite the
> next pointer in platform_nb.
>
Err.... You are dead right. I missed completely that it is using the
same notifier block. Sorry for oversight and thanks for spotting it.
Regards,
Santosh
WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Murali Karicheri <m-karicheri2@ti.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: keystone: add bus notifier to set dma_pfn_offset for pci devices
Date: Fri, 10 Oct 2014 11:46:50 -0400 [thread overview]
Message-ID: <5437FF6A.9030203@ti.com> (raw)
In-Reply-To: <20141010154258.GN5182@n2100.arm.linux.org.uk>
On 10/10/14 11:42 AM, Russell King - ARM Linux wrote:
> On Fri, Oct 10, 2014 at 11:29:03AM -0400, Santosh Shilimkar wrote:
>>
>>
>> On 10/10/14 11:15 AM, Murali Karicheri wrote:
>>> When PCI device driver such as that for e1000e tries to set dma mask
>>> using dma_set_mask_and_coherent(), it fails because the dma_pfn_offset
>>> is incorrect on a Keystone SoC. This patch fix this by adding a bus
>>> notifier to set this correctly for PCI devices.
>>>
>>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>>> ---
>> Looks good. I will pick this up after the merge window.
>
> No it doesn't, this patch is crap. Really. Let's look again at what the
> patch is doing:
>
> if (platform_nb.notifier_call)
> bus_register_notifier(&platform_bus_type, &platform_nb);
> + if (platform_nb.notifier_call)
> + bus_register_notifier(&pci_bus_type, &platform_nb);
>
> Notice that both calls are using the same platform_nb structure, which is:
>
> static struct notifier_block platform_nb;
>
> and in turn this is:
>
> struct notifier_block {
> notifier_fn_t notifier_call;
> struct notifier_block __rcu *next;
> int priority;
> };
>
> Notice that "next" pointer - these blocks are used as a single-linked list.
> So, this block gets registered for the platform bus, and is inserted into
> that bus notifier chain. That means "next" may be set to a non-NULL
> next notifier block.
>
> Then it gets registered against the PCI bus, which *will* overwrite the
> next pointer in platform_nb.
>
Err.... You are dead right. I missed completely that it is using the
same notifier block. Sorry for oversight and thanks for spotting it.
Regards,
Santosh
next prev parent reply other threads:[~2014-10-10 15:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-10 15:15 [PATCH] ARM: keystone: add bus notifier to set dma_pfn_offset for pci devices Murali Karicheri
2014-10-10 15:15 ` Murali Karicheri
2014-10-10 15:29 ` Santosh Shilimkar
2014-10-10 15:29 ` Santosh Shilimkar
2014-10-10 15:42 ` Russell King - ARM Linux
2014-10-10 15:42 ` Russell King - ARM Linux
2014-10-10 15:46 ` Santosh Shilimkar [this message]
2014-10-10 15:46 ` Santosh Shilimkar
2014-10-10 15:53 ` Murali Karicheri
2014-10-10 15:53 ` Murali Karicheri
2014-10-10 18:22 ` Arnd Bergmann
2014-10-10 18:22 ` Arnd Bergmann
2014-10-10 21:37 ` Murali Karicheri
2014-10-10 21:37 ` Murali Karicheri
2014-10-11 0:04 ` Santosh Shilimkar
2014-10-11 0:04 ` Santosh Shilimkar
2014-10-11 20:37 ` Arnd Bergmann
2014-10-11 20:37 ` Arnd Bergmann
2014-10-13 14:13 ` Murali Karicheri
2014-10-13 14:13 ` Murali Karicheri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5437FF6A.9030203@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.