<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/bcma/bcma_private.h, branch v4.9.75</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Revert "bcma: init serial console directly from ChipCommon code"</title>
<updated>2017-02-09T07:08:28+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>rafal@milecki.pl</email>
</author>
<published>2017-01-13T11:23:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=16f61dee7e7cb378216ff59ffeacf157efad6c82'/>
<id>16f61dee7e7cb378216ff59ffeacf157efad6c82</id>
<content type='text'>
commit 7195439d1d71bc4a6c33cfb57bc669a7cd041041 upstream.

This reverts commit 4c81acab3816 ("bcma: init serial console directly
from ChipCommon code") as it broke IRQ assignment. Getting IRQ with
bcma_core_irq helper on SoC requires MIPS core to be set. It happens
*after* ChipCommon initialization so we can't do this so early.

This fixes a user reported regression. It wasn't critical as serial was
still somehow working but lack of IRQs was making in unreliable.

Fixes: 4c81acab3816 ("bcma: init serial console directly from ChipCommon code")
Reported-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Rafał Miłecki &lt;rafal@milecki.pl&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7195439d1d71bc4a6c33cfb57bc669a7cd041041 upstream.

This reverts commit 4c81acab3816 ("bcma: init serial console directly
from ChipCommon code") as it broke IRQ assignment. Getting IRQ with
bcma_core_irq helper on SoC requires MIPS core to be set. It happens
*after* ChipCommon initialization so we can't do this so early.

This fixes a user reported regression. It wasn't critical as serial was
still somehow working but lack of IRQs was making in unreliable.

Fixes: 4c81acab3816 ("bcma: init serial console directly from ChipCommon code")
Reported-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Rafał Miłecki &lt;rafal@milecki.pl&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/quirks: Add early quirk to reset Apple AirPort card</title>
<updated>2016-07-10T18:13:53+00:00</updated>
<author>
<name>Lukas Wunner</name>
<email>lukas@wunner.de</email>
</author>
<published>2016-06-12T10:31:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=abb2bafd295fe962bbadc329dbfb2146457283ac'/>
<id>abb2bafd295fe962bbadc329dbfb2146457283ac</id>
<content type='text'>
The EFI firmware on Macs contains a full-fledged network stack for
downloading OS X images from osrecovery.apple.com. Unfortunately
on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331
wireless card on every boot and leaves it enabled even after
ExitBootServices has been called. The card continues to assert its IRQ
line, causing spurious interrupts if the IRQ is shared. It also corrupts
memory by DMAing received packets, allowing for remote code execution
over the air. This only stops when a driver is loaded for the wireless
card, which may be never if the driver is not installed or blacklisted.

The issue seems to be constrained to the Broadcom 4331. Chris Milsted
has verified that the newer Broadcom 4360 built into the MacBookPro11,3
(2013/2014) does not exhibit this behaviour. The chances that Apple will
ever supply a firmware fix for the older machines appear to be zero.

The solution is to reset the card on boot by writing to a reset bit in
its mmio space. This must be done as an early quirk and not as a plain
vanilla PCI quirk to successfully combat memory corruption by DMAed
packets: Matthew Garrett found out in 2012 that the packets are written
to EfiBootServicesData memory (http://mjg59.dreamwidth.org/11235.html).
This type of memory is made available to the page allocator by
efi_free_boot_services(). Plain vanilla PCI quirks run much later, in
subsys initcall level. In-between a time window would be open for memory
corruption. Random crashes occurring in this time window and attributed
to DMAed packets have indeed been observed in the wild by Chris
Bainbridge.

When Matthew Garrett analyzed the memory corruption issue in 2012, he
sought to fix it with a grub quirk which transitions the card to D3hot:
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=9d34bb85da56

This approach does not help users with other bootloaders and while it
may prevent DMAed packets, it does not cure the spurious interrupts
emanating from the card. Unfortunately the card's mmio space is
inaccessible in D3hot, so to reset it, we have to undo the effect of
Matthew's grub patch and transition the card back to D0.

Note that the quirk takes a few shortcuts to reduce the amount of code:
The size of BAR 0 and the location of the PM capability is identical
on all affected machines and therefore hardcoded. Only the address of
BAR 0 differs between models. Also, it is assumed that the BCMA core
currently mapped is the 802.11 core. The EFI driver seems to always take
care of this.

Michael Büsch, Bjorn Helgaas and Matt Fleming contributed feedback
towards finding the best solution to this problem.

The following should be a comprehensive list of affected models:
    iMac13,1        2012  21.5"       [Root Port 00:1c.3 = 8086:1e16]
    iMac13,2        2012  27"         [Root Port 00:1c.3 = 8086:1e16]
    Macmini5,1      2011  i5 2.3 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini5,2      2011  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini5,3      2011  i7 2.0 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini6,1      2012  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1e12]
    Macmini6,2      2012  i7 2.3 GHz  [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro8,1   2011  13"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro8,2   2011  15"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro8,3   2011  17"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro9,1   2012  15"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro9,2   2012  13"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro10,1  2012  15"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro10,2  2012  13"         [Root Port 00:1c.1 = 8086:1e12]

For posterity, spurious interrupts caused by the Broadcom 4331 wireless
card resulted in splats like this (stacktrace omitted):

    irq 17: nobody cared (try booting with the "irqpoll" option)
    handlers:
    [&lt;ffffffff81374370&gt;] pcie_isr
    [&lt;ffffffffc0704550&gt;] sdhci_irq [sdhci] threaded [&lt;ffffffffc07013c0&gt;] sdhci_thread_irq [sdhci]
    [&lt;ffffffffc0a0b960&gt;] azx_interrupt [snd_hda_codec]
    Disabling IRQ #17

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111781
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=728916
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951#c16
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1098621
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632#c5
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1279130
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1332732
Tested-by: Konstantin Simanov &lt;k.simanov@stlk.ru&gt;        # [MacBookPro8,1]
Tested-by: Lukas Wunner &lt;lukas@wunner.de&gt;                # [MacBookPro9,1]
Tested-by: Bryan Paradis &lt;bryan.paradis@gmail.com&gt;       # [MacBookPro9,2]
Tested-by: Andrew Worsley &lt;amworsley@gmail.com&gt;          # [MacBookPro10,1]
Tested-by: Chris Bainbridge &lt;chris.bainbridge@gmail.com&gt; # [MacBookPro10,2]
Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Acked-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Acked-by: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Brian Gerst &lt;brgerst@gmail.com&gt;
Cc: Chris Milsted &lt;cmilsted@redhat.com&gt;
Cc: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Matthew Garrett &lt;mjg59@srcf.ucam.org&gt;
Cc: Michael Buesch &lt;m@bues.ch&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Yinghai Lu &lt;yinghai@kernel.org&gt;
Cc: b43-dev@lists.infradead.org
Cc: linux-pci@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Apply nvidia_bugs quirk only on root bus
Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Reintroduce scanning of secondary buses
Link: http://lkml.kernel.org/r/48d0972ac82a53d460e5fce77a07b2560db95203.1465690253.git.lukas@wunner.de
[ Did minor readability edits. ]
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The EFI firmware on Macs contains a full-fledged network stack for
downloading OS X images from osrecovery.apple.com. Unfortunately
on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331
wireless card on every boot and leaves it enabled even after
ExitBootServices has been called. The card continues to assert its IRQ
line, causing spurious interrupts if the IRQ is shared. It also corrupts
memory by DMAing received packets, allowing for remote code execution
over the air. This only stops when a driver is loaded for the wireless
card, which may be never if the driver is not installed or blacklisted.

The issue seems to be constrained to the Broadcom 4331. Chris Milsted
has verified that the newer Broadcom 4360 built into the MacBookPro11,3
(2013/2014) does not exhibit this behaviour. The chances that Apple will
ever supply a firmware fix for the older machines appear to be zero.

The solution is to reset the card on boot by writing to a reset bit in
its mmio space. This must be done as an early quirk and not as a plain
vanilla PCI quirk to successfully combat memory corruption by DMAed
packets: Matthew Garrett found out in 2012 that the packets are written
to EfiBootServicesData memory (http://mjg59.dreamwidth.org/11235.html).
This type of memory is made available to the page allocator by
efi_free_boot_services(). Plain vanilla PCI quirks run much later, in
subsys initcall level. In-between a time window would be open for memory
corruption. Random crashes occurring in this time window and attributed
to DMAed packets have indeed been observed in the wild by Chris
Bainbridge.

When Matthew Garrett analyzed the memory corruption issue in 2012, he
sought to fix it with a grub quirk which transitions the card to D3hot:
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=9d34bb85da56

This approach does not help users with other bootloaders and while it
may prevent DMAed packets, it does not cure the spurious interrupts
emanating from the card. Unfortunately the card's mmio space is
inaccessible in D3hot, so to reset it, we have to undo the effect of
Matthew's grub patch and transition the card back to D0.

Note that the quirk takes a few shortcuts to reduce the amount of code:
The size of BAR 0 and the location of the PM capability is identical
on all affected machines and therefore hardcoded. Only the address of
BAR 0 differs between models. Also, it is assumed that the BCMA core
currently mapped is the 802.11 core. The EFI driver seems to always take
care of this.

Michael Büsch, Bjorn Helgaas and Matt Fleming contributed feedback
towards finding the best solution to this problem.

The following should be a comprehensive list of affected models:
    iMac13,1        2012  21.5"       [Root Port 00:1c.3 = 8086:1e16]
    iMac13,2        2012  27"         [Root Port 00:1c.3 = 8086:1e16]
    Macmini5,1      2011  i5 2.3 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini5,2      2011  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini5,3      2011  i7 2.0 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini6,1      2012  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1e12]
    Macmini6,2      2012  i7 2.3 GHz  [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro8,1   2011  13"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro8,2   2011  15"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro8,3   2011  17"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro9,1   2012  15"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro9,2   2012  13"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro10,1  2012  15"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro10,2  2012  13"         [Root Port 00:1c.1 = 8086:1e12]

For posterity, spurious interrupts caused by the Broadcom 4331 wireless
card resulted in splats like this (stacktrace omitted):

    irq 17: nobody cared (try booting with the "irqpoll" option)
    handlers:
    [&lt;ffffffff81374370&gt;] pcie_isr
    [&lt;ffffffffc0704550&gt;] sdhci_irq [sdhci] threaded [&lt;ffffffffc07013c0&gt;] sdhci_thread_irq [sdhci]
    [&lt;ffffffffc0a0b960&gt;] azx_interrupt [snd_hda_codec]
    Disabling IRQ #17

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111781
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=728916
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951#c16
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1098621
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632#c5
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1279130
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1332732
Tested-by: Konstantin Simanov &lt;k.simanov@stlk.ru&gt;        # [MacBookPro8,1]
Tested-by: Lukas Wunner &lt;lukas@wunner.de&gt;                # [MacBookPro9,1]
Tested-by: Bryan Paradis &lt;bryan.paradis@gmail.com&gt;       # [MacBookPro9,2]
Tested-by: Andrew Worsley &lt;amworsley@gmail.com&gt;          # [MacBookPro10,1]
Tested-by: Chris Bainbridge &lt;chris.bainbridge@gmail.com&gt; # [MacBookPro10,2]
Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Acked-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Acked-by: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Brian Gerst &lt;brgerst@gmail.com&gt;
Cc: Chris Milsted &lt;cmilsted@redhat.com&gt;
Cc: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Matthew Garrett &lt;mjg59@srcf.ucam.org&gt;
Cc: Michael Buesch &lt;m@bues.ch&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Yinghai Lu &lt;yinghai@kernel.org&gt;
Cc: b43-dev@lists.infradead.org
Cc: linux-pci@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Apply nvidia_bugs quirk only on root bus
Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Reintroduce scanning of secondary buses
Link: http://lkml.kernel.org/r/48d0972ac82a53d460e5fce77a07b2560db95203.1465690253.git.lukas@wunner.de
[ Did minor readability edits. ]
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bcma: move parallel flash support to separated file</title>
<updated>2016-03-07T12:41:08+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>zajec5@gmail.com</email>
</author>
<published>2016-02-12T09:15:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d6a3b51ada68c2bd3e184f4729ce626a1721cf74'/>
<id>d6a3b51ada68c2bd3e184f4729ce626a1721cf74</id>
<content type='text'>
This follows the way of handling other flashes and cleans code a bit. As
next task we will want to move flash code to ChipCommon driver as:
1) Flash controllers are accesible using ChipCommon registers
2) This code isn't MIPS specific
This change prepares bcma for that.

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This follows the way of handling other flashes and cleans code a bit. As
next task we will want to move flash code to ChipCommon driver as:
1) Flash controllers are accesible using ChipCommon registers
2) This code isn't MIPS specific
This change prepares bcma for that.

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bcma: init serial console directly from ChipCommon code</title>
<updated>2016-02-06T11:45:04+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>zajec5@gmail.com</email>
</author>
<published>2016-01-22T17:02:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4c81acab3816c6941900c2abdb412df6cf34bc74'/>
<id>4c81acab3816c6941900c2abdb412df6cf34bc74</id>
<content type='text'>
UART is connected to and controlled over ChipCommon core. It doesn't
have much to do with MIPS core (where we initialize it currently)
except just existing on embedded systemms. There isn't point of such
cross-core initialization (and we needed #ifdef anyway) so just handle
it in ChipCommon.

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
UART is connected to and controlled over ChipCommon core. It doesn't
have much to do with MIPS core (where we initialize it currently)
except just existing on embedded systemms. There isn't point of such
cross-core initialization (and we needed #ifdef anyway) so just handle
it in ChipCommon.

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bcma: fix access to host_pdev for PCIe devices</title>
<updated>2015-08-10T19:20:46+00:00</updated>
<author>
<name>Hauke Mehrtens</name>
<email>hauke@hauke-m.de</email>
</author>
<published>2015-08-02T18:26:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=53cd2fdb00aab34f91762f6345f83625a30480f0'/>
<id>53cd2fdb00aab34f91762f6345f83625a30480f0</id>
<content type='text'>
bus-&gt;host_pdev is part of a union so bus-&gt;host_pdev != NULL is probably
also true for PCIe devices, because there it accesses bus-&gt;host_pci. If
we access the dev member at the offset defined in struct
platform_device in struct pci_dev instead we probably get something
else.

This patch adds a new function which returns the host dev struct and
NULL if we do not have a host dev. When this gets registered on MIPS
brcm47xx we do not have a host dev in some situations.
This function could also be used in other places.

This problem was introduced in this commit:
commit cae761b5a6bdc597ba476a040fdcd5b4bc559b85
Author: Rafa? Mi?ecki &lt;zajec5@gmail.com&gt;
Date:   Sun Jun 28 17:17:13 2015 +0200

    bcma: populate bus DT subnodes as platform_device-s

Signed-off-by: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
bus-&gt;host_pdev is part of a union so bus-&gt;host_pdev != NULL is probably
also true for PCIe devices, because there it accesses bus-&gt;host_pci. If
we access the dev member at the offset defined in struct
platform_device in struct pci_dev instead we probably get something
else.

This patch adds a new function which returns the host dev struct and
NULL if we do not have a host dev. When this gets registered on MIPS
brcm47xx we do not have a host dev in some situations.
This function could also be used in other places.

This problem was introduced in this commit:
commit cae761b5a6bdc597ba476a040fdcd5b4bc559b85
Author: Rafa? Mi?ecki &lt;zajec5@gmail.com&gt;
Date:   Sun Jun 28 17:17:13 2015 +0200

    bcma: populate bus DT subnodes as platform_device-s

Signed-off-by: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bcma: allow disabling (not building) PCI driver</title>
<updated>2015-03-13T14:25:50+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>zajec5@gmail.com</email>
</author>
<published>2015-03-05T17:25:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=982a40f5c0bb03368989a6b1ae833b474854e931'/>
<id>982a40f5c0bb03368989a6b1ae833b474854e931</id>
<content type='text'>
It isn't required for bcma bus on SoCs, so provide some empty functions
and allow disabling it.

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It isn't required for bcma bus on SoCs, so provide some empty functions
and allow disabling it.

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bcma: move internal function declarations to private header</title>
<updated>2015-03-05T12:11:43+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>zajec5@gmail.com</email>
</author>
<published>2015-03-04T13:24:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0a4e699a41f767dff76ca7dc1019b9ca6de3eb42'/>
<id>0a4e699a41f767dff76ca7dc1019b9ca6de3eb42</id>
<content type='text'>
These functions are not exported nor used anywhere, so there is no
reason to put them in public headers.
Also drop unused bcma_chipco_(suspend|resume).

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These functions are not exported nor used anywhere, so there is no
reason to put them in public headers.
Also drop unused bcma_chipco_(suspend|resume).

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bcma: enable support for PCIe Gen 2 host devices</title>
<updated>2015-03-02T14:59:45+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>zajec5@gmail.com</email>
</author>
<published>2015-02-08T16:11:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9b6cc9a807c79c3c356af6f4e6c55e62c6554226'/>
<id>9b6cc9a807c79c3c356af6f4e6c55e62c6554226</id>
<content type='text'>
Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bcma: support bringing up bus hosted on PCIe Gen 2</title>
<updated>2015-03-02T14:59:45+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>zajec5@gmail.com</email>
</author>
<published>2015-02-08T16:11:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=804e27dee49e20c0addd1b7276654220cc3768ae'/>
<id>804e27dee49e20c0addd1b7276654220cc3768ae</id>
<content type='text'>
Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bcma: add helpers bringing PCIe hosted bus up / down</title>
<updated>2015-03-02T14:59:45+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>zajec5@gmail.com</email>
</author>
<published>2015-02-08T16:11:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4186721d02b71ae943e60bbf50d3488fd5fd6adb'/>
<id>4186721d02b71ae943e60bbf50d3488fd5fd6adb</id>
<content type='text'>
Bringing PCIe hosted bus up requires operating on host-related core.
Since we plan to support PCIe Gen 2 devices we should provide a helper
picking the correct one (PCIE or PCIE2).

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Bringing PCIe hosted bus up requires operating on host-related core.
Since we plan to support PCIe Gen 2 devices we should provide a helper
picking the correct one (PCIE or PCIE2).

Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
