Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 08 3月, 2017 1 次提交
  3. 31 1月, 2017 2 次提交
  5. 17 1月, 2017 1 次提交
  7. 29 11月, 2016 1 次提交
    • J
      bcma: add Dell Inspiron 3148 · 59391a96
      由 Jiri Slaby 提交于 
      This is what is in the laptop:
01:00.0 Network controller [0280]: Broadcom Limited BCM43142 802.11b/g/n [14e4:4365] (rev 01)
        Subsystem: Dell Device [1028:0018]
        Flags: bus master, fast devsel, latency 0, IRQ 18
        Memory at b0400000 (64-bit, non-prefetchable) [size=32K]
        Capabilities: [40] Power Management version 3
        Capabilities: [58] Vendor Specific Information: Len=78 <?>
        Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [d0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [13c] Virtual Channel
        Capabilities: [160] Device Serial Number 00-00-9a-ff-ff-f3-40-b8
        Capabilities: [16c] Power Budgeting <?>

With the patch, I can see:
bcma: bus0: Found chip with id 43142, rev 0x01 and package 0x08
bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x28, class 0x0)
bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x21, class 0x0)
bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x16, class 0x0)
bcma: bus0: Core 3 found: UNKNOWN (manuf 0x43B, id 0x368, rev 0x00, class 0x0)
bcma: bus0: Bus registered

The wifi is not currently supported by brcmsmac yet:
brcmsmac bcma1:1: mfg 4bf core 812 rev 33 class 0 irq 18
brcmsmac: unknown device id 4365

So don't expect a working wifi from this patch :).
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: <linux-wireless@vger.kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      59391a96
  9. 09 9月, 2016 1 次提交
    • A
      bcma: use of_dma_configure() to set initial dma mask · defb893f
      由 Arnd Bergmann 提交于 
      While fixing another bug, I noticed that bcma manually sets up
a dma_mask pointer for its child devices. We have a generic
helper for that now, which should be able to cope better with
any variations that might be needed to deal with cache coherency,
unusual DMA address offsets, iommus, or limited DMA masks, none
of which are currently handled here.

This changes the core to use the of_dma_configure(), like
we do for platform devices that are probed directly from
DT.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      defb893f
  11. 03 9月, 2016 1 次提交
  13. 20 7月, 2016 1 次提交
  15. 19 7月, 2016 2 次提交
  17. 11 7月, 2016 1 次提交
    • L
      x86/quirks: Add early quirk to reset Apple AirPort card · abb2bafd
      由 Lukas Wunner 提交于 
      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:
    [<ffffffff81374370>] pcie_isr
    [<ffffffffc0704550>] sdhci_irq [sdhci] threaded [<ffffffffc07013c0>] sdhci_thread_irq [sdhci]
    [<ffffffffc0a0b960>] 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 <k.simanov@stlk.ru>        # [MacBookPro8,1]
Tested-by: Lukas Wunner <lukas@wunner.de>                # [MacBookPro9,1]
Tested-by: Bryan Paradis <bryan.paradis@gmail.com>       # [MacBookPro9,2]
Tested-by: Andrew Worsley <amworsley@gmail.com>          # [MacBookPro10,1]
Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> # [MacBookPro10,2]
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Acked-by: NRafał Miłecki <zajec5@gmail.com>
Acked-by: NMatt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Chris Milsted <cmilsted@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Michael Buesch <m@bues.ch>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
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: NIngo Molnar <mingo@kernel.org>
      abb2bafd
  19. 04 4月, 2016 1 次提交
    • B
      mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR() · 5651d6aa
      由 Brian Norris 提交于 
      Using KSEG0ADDR makes code highly MIPS dependent and not portable.
Thanks to the fix a68f3768 ("MIPS: io.h: Define `ioremap_cache'") we can
use ioremap_cache which is generic and supported on MIPS as well now.

KSEG0ADDR was translating 0x1c000000 into 0x9c000000. With ioremap_cache
we use MIPS's __ioremap (and then remap_area_pages). This results in
different address (e.g. 0xc0080000) but it still should be cached as
expected and it was successfully tested with BCM47186B0.

Other than that drivers/bcma/driver_chipcommon_sflash.c nicely setups a
struct resource for access window, but we wren't using it. Use it now
and drop duplicated info.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      5651d6aa
  21. 23 3月, 2016 1 次提交
    • A
      bcma: fix building without OF_IRQ · c58d900c
      由 Arnd Bergmann 提交于 
      The bcma driver core can be built with or without DT support, but
it fails to build when CONFIG_OF=y and CONFIG_OF_IRQ=n, which
can happen on platforms that do not support IRQ domains.

ERROR: "irq_create_of_mapping" [drivers/bcma/bcma.ko] undefined!
ERROR: "of_irq_parse_raw" [drivers/bcma/bcma.ko] undefined!
ERROR: "of_irq_parse_one" [drivers/bcma/bcma.ko] undefined!

This adds another compile-time check for OF_IRQ, but also
gets rid of now unneeded #ifdef checks: Using the simpler
IS_ENABLED() check for OF_IRQ also covers the case of not
having CONFIG_OF enabled. The check for CONFIG_OF_ADDRESS
was added to allow building on architectures without
OF_ADDRESS, but that has been addressed already in
b1d06b60 ("of: Provide static inline function for
of_translate_address if needed").
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      c58d900c
  23. 07 3月, 2016 3 次提交
  25. 06 2月, 2016 8 次提交
  27. 07 1月, 2016 1 次提交
  29. 31 12月, 2015 1 次提交
    • R
      bcma: use module_init for the main part of bus initialization · 0510931e
      由 Rafał Miłecki 提交于 
      So far we were using fs_initcall. It was (and still is) needed because
struct bus_type has to be registered early. However main bus
initialization has to happen later as it requires SPROM which depends on
NVRAM which depends on mtd.
Solve it by using fs_initcall only for bus_register call and module_init
for the rest. It affects bcma only when built-in obviously.

This was tested with BCM4706 and BCM5357C0 (BCM47XX), BCM4708A0
(ARCH_BCM_5301X) and BCM43225 (PCIe card with bcma as module).
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      0510931e
  31. 19 11月, 2015 1 次提交
    • L
      gpio: change member .dev to .parent · 58383c78
      由 Linus Walleij 提交于 
      The name .dev in a struct is normally reserved for a struct device
that is let us say a superclass to the thing described by the struct.
struct gpio_chip stands out by confusingly using a struct device *dev
to point to the parent device (such as a platform_device) that
represents the hardware. As we want to give gpio_chip:s real devices,
this is not working. We need to rename this member to parent.

This was done by two coccinelle scripts, I guess it is possible to
combine them into one, but I don't know such stuff. They look like
this:

@@
struct gpio_chip *var;
@@
-var->dev
+var->parent

and:

@@
struct gpio_chip var;
@@
-var.dev
+var.parent

and:

@@
struct bgpio_chip *var;
@@
-var->gc.dev
+var->gc.parent

Plus a few instances of bgpio that I couldn't figure out how
to teach Coccinelle to rewrite.

This patch hits all over the place, but I *strongly* prefer this
solution to any piecemal approaches that just exercise patch
mechanics all over the place. It mainly hits drivers/gpio and
drivers/pinctrl which is my own backyard anyway.

Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Alek Du <alek.du@intel.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      58383c78
  33. 29 9月, 2015 1 次提交
  35. 18 8月, 2015 1 次提交
  37. 11 8月, 2015 1 次提交
    • H
      bcma: fix access to host_pdev for PCIe devices · 53cd2fdb
      由 Hauke Mehrtens 提交于 
      bus->host_pdev is part of a union so bus->host_pdev != NULL is probably
also true for PCIe devices, because there it accesses bus->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 cae761b5
Author: Rafa? Mi?ecki <zajec5@gmail.com>
Date:   Sun Jun 28 17:17:13 2015 +0200

    bcma: populate bus DT subnodes as platform_device-s
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      53cd2fdb
  39. 26 7月, 2015 1 次提交
  41. 21 7月, 2015 1 次提交
  43. 08 6月, 2015 1 次提交
  45. 09 5月, 2015 2 次提交
  47. 01 4月, 2015 1 次提交
  49. 20 3月, 2015 1 次提交
  51. 13 3月, 2015 3 次提交