Eric Lee / smarc-fsl-linux-kernel

02 Nov, 2017

1 commit

  • b24413180   License cleanup: add SPDX GPL-2.0 license identifier to files with no license ... Browse Code »

    Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

08 Aug, 2017

1 commit

27 Jul, 2017

1 commit

21 Mar, 2017

3 commits

08 Mar, 2017

1 commit

03 Feb, 2017

1 commit

31 Jan, 2017

2 commits

17 Jan, 2017

1 commit

  • 7195439d1   Revert "bcma: init serial console directly from ChipCommon code" ... Browse Code »

    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
    Cc: stable@vger.kernel.org # 4.6+
    Signed-off-by: Rafał Miłecki
    Signed-off-by: Kalle Valo

    Rafał Miłecki
     

29 Nov, 2016

1 commit

  • 59391a96d   bcma: add Dell Inspiron 3148 ... Browse Code »

    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: Jiri Slaby
    Cc: Rafał Miłecki
    Cc:
    Signed-off-by: Kalle Valo

    Jiri Slaby
     

09 Sep, 2016

1 commit

  • defb893ff   bcma: use of_dma_configure() to set initial dma mask ... Browse Code »

    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: Arnd Bergmann
    Signed-off-by: Kalle Valo

    Arnd Bergmann
     

03 Sep, 2016

1 commit

  • 3f37ec79d   bcma: support BCM53573 series of wireless SoCs ... Browse Code »

    BCM53573 seems to be the first series of Northstar family with wireless
    on the chip. The base models are BCM53573-s (A0, A1) and there is also
    BCM47189B0 which seems to be some small modification.

    The only problem with these chipsets seems to be watchdog. It's totally
    unavailable on 53573A0 / 53573A1 and preferable PMU watchdog is broken
    on 53573B0 / 53573B1.

    Signed-off-by: Rafał Miłecki
    Signed-off-by: Kalle Valo

    Rafał Miłecki
     

26 Jul, 2016

1 commit

  • d5b160d34   Merge tag 'wireless-drivers-next-for-davem-2016-07-22' of git://git.kernel.org/p… ... Browse Code »

    …ub/scm/linux/kernel/git/kvalo/wireless-drivers-next

    Kalle Valo says:

    ====================
    pull-request: wireless-drivers-next 2016-07-22

    I'm sick so I have to keep this short, but here's the last pull request
    to net-next. This time there's a trivial conflict with mtd tree:

    http://lkml.kernel.org/g/20160720123133.44dab209@canb.auug.org.au

    We concluded with Brian (CCed) that it's best that we ask Linus to fix
    this. The patches have been in linux-next for a couple of days. This
    time I haven't done any merge tests so I don't know if there are any
    other conflicts etc.

    Please let me know if there are any problems.

    wireless-drivers-next patches for 4.8

    Major changes:

    wl18xx

    * add initial mesh support

    bcma

    * serial flash support on non-MIPS SoCs

    ath10k

    * enable support for QCA9888
    * disable wake_tx_queue() mac80211 op for older devices to workaround
    throughput regression

    ath9k

    * implement temperature compensation support for AR9003+
    ====================

    Signed-off-by: David S. Miller <davem@davemloft.net>

    David S. Miller
     

20 Jul, 2016

1 commit

19 Jul, 2016

2 commits

  • 57d8f7dd2   bcma: allow enabling serial flash support on non-MIPS SoCs ... Browse Code »

    So far we had only MIPS devices with serial flash connected to the SoC's
    ChipCommon. ARM devices got a separated SPI controller and weere using
    standard SPI drivers.
    This has changed with the wireless SoC BCM47189B0. It's ARM based but
    has serial flash attached just like older devices. This allows using
    existing driver with these devices.

    Signed-off-by: Rafał Miłecki
    Signed-off-by: Kalle Valo

    Rafał Miłecki
     
  • 1bea0512c   bcma: add PCI ID for Foxconn's BCM43142 device ... Browse Code »

    After discovering there are 2 very different 14e4:4365 PCI devices we
    made ID tables less generic. Back then we believed there are only 2 such
    devices:
    1) 14e4:4365 1028:0016 with SoftMAC BCM43142 chipset
    2) 14e4:4365 14e4:4365 with FullMAC BCM4366 chipset

    >From the recent report it appears there is also 14e4:4365 105b:e092
    which should be claimed by bcma. Add back support for it.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=121881
    Fixes: 515b399c9a20 ("bcma: claim only 14e4:4365 PCI Dell card with SoftMAC BCM43142")
    Reported-by: Igor Mammedov
    Signed-off-by: Rafał Miłecki
    Cc: Stable [4.6+]
    Tested-by: Igor Mammedov
    Signed-off-by: Kalle Valo

    Rafał Miłecki
     

11 Jul, 2016

1 commit

  • abb2bafd2   x86/quirks: Add early quirk to reset Apple AirPort card ... Browse Code »

    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:
    [] pcie_isr
    [] sdhci_irq [sdhci] threaded [] sdhci_thread_irq [sdhci]
    [] 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 # [MacBookPro8,1]
    Tested-by: Lukas Wunner # [MacBookPro9,1]
    Tested-by: Bryan Paradis # [MacBookPro9,2]
    Tested-by: Andrew Worsley # [MacBookPro10,1]
    Tested-by: Chris Bainbridge # [MacBookPro10,2]
    Signed-off-by: Lukas Wunner
    Acked-by: Rafał Miłecki
    Acked-by: Matt Fleming
    Cc: Andy Lutomirski
    Cc: Bjorn Helgaas
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Chris Milsted
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Matthew Garrett
    Cc: Michael Buesch
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: Yinghai Lu
    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

    Lukas Wunner
     

25 May, 2016

1 commit

  • 8bc4d5f39   Merge tag 'for-linus-20160523' of git://git.infradead.org/linux-mtd ... Browse Code »

    Pull MTD updates from Brian Norris:
    "First cycle with Boris as NAND maintainer! Many (most) bullets stolen
    from him.

    Generic:
    - Migrated NAND LED trigger to be a generic MTD trigger

    NAND:
    - Introduction of the "ECC algorithm" concept, to avoid overloading
    the ECC mode field too much more
    - Replaced the nand_ecclayout infrastructure with something a little
    more flexible (finally!) and future proof
    - Rework of the OMAP GPMC and NAND drivers; the TI folks pulled some
    of this into their own tree as well
    - Prepare the sunxi NAND driver to receive DMA support
    - Handle bitflips in erased pages on GPMI revisions that do not
    support this in hardware.

    SPI NOR:
    - Start using the spi_flash_read() API for SPI drivers that support
    it (i.e., SPI drivers with special memory-mapped flash modes)

    And other small scattered improvments"

    * tag 'for-linus-20160523' of git://git.infradead.org/linux-mtd: (155 commits)
    mtd: spi-nor: support GigaDevice gd25lq64c
    mtd: nand_bch: fix spelling of "probably"
    mtd: brcmnand: respect ECC algorithm set by NAND subsystem
    gpmi-nand: Handle ECC Errors in erased pages
    Documentation: devicetree: deprecate "soft_bch" nand-ecc-mode value
    mtd: nand: add support for "nand-ecc-algo" DT property
    mtd: mtd: drop NAND_ECC_SOFT_BCH enum value
    mtd: drop support for NAND_ECC_SOFT_BCH as "soft_bch" mapping
    mtd: nand: read ECC algorithm from the new field
    mtd: nand: fsmc: validate ECC setup by checking algorithm directly
    mtd: nand: set ECC algorithm to Hamming on fallback
    staging: mt29f_spinand: set ECC algorithm explicitly
    CRIS v32: nand: set ECC algorithm explicitly
    mtd: nand: atmel: set ECC algorithm explicitly
    mtd: nand: davinci: set ECC algorithm explicitly
    mtd: nand: bf5xx: set ECC algorithm explicitly
    mtd: nand: omap2: Fix high memory dma prefetch transfer
    mtd: nand: omap2: Start dma request before enabling prefetch
    mtd: nandsim: add __init attribute
    mtd: nand: move of_get_nand_xxx() helpers into nand_base.c
    ...

    Linus Torvalds
     

04 Apr, 2016

1 commit

  • 5651d6aaf   mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR() ... Browse Code »

    Using KSEG0ADDR makes code highly MIPS dependent and not portable.
    Thanks to the fix a68f376 ("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: Brian Norris
    Signed-off-by: Rafał Miłecki

    Brian Norris
     

23 Mar, 2016

1 commit

  • c58d900cc   bcma: fix building without OF_IRQ ... Browse Code »

    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
    b1d06b60e90c ("of: Provide static inline function for
    of_translate_address if needed").

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Kalle Valo

    Arnd Bergmann
     

07 Mar, 2016

3 commits

17 Feb, 2016

1 commit

  • 6cd21d794   Merge tag 'wireless-drivers-next-for-davem-2016-02-12' of git://git.kernel.org/p… ... Browse Code »

    …ub/scm/linux/kernel/git/kvalo/wireless-drivers-next

    Kalle Valo says:

    ====================
    Major changes:

    wl12xx

    * add device tree support for SPI

    mwifiex

    * add debugfs file to read chip information
    * add MSIx support for newer pcie chipsets (8997 onwards)
    * add schedule scan support
    * add WoWLAN net-detect support
    * firmware dump support for w8997 chipset

    iwlwifi

    * continue the work on multiple Rx queues
    * add support for beacon storing used in low power states
    * use the regular firmware image of WoWLAN
    * fix 8000 devices for Big Endian machines
    * more firmware debug hooks
    * add support for P2P Client snoozing
    * make the beacon filtering for AP mode configurable
    * fix transmit queues overflow with LSO

    libertas

    * add support for setting power save via cfg80211
    ====================

    Signed-off-by: David S. Miller <davem@davemloft.net>

    David S. Miller
     

06 Feb, 2016

8 commits

18 Jan, 2016

1 commit

  • 58cf279ac   Merge tag 'gpio-v4.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio ... Browse Code »

    Pull GPIO updates from Linus Walleij:
    "Here is the bulk of GPIO changes for v4.5.

    Notably there are big refactorings mostly by myself, aimed at getting
    the gpio_chip into a shape that makes me believe I can proceed to
    preserve state for a proper userspace ABI (character device) that has
    already been proposed once, but resulted in the feedback that I need
    to go back and restructure stuff. So I've been restructuring stuff.
    On the way I ran into brokenness (return code from the get_value()
    callback) and had to fix it. Also, refactored generic GPIO to be
    simpler.

    Some of that is still waiting to trickle down from the subsystems all
    over the kernel that provide random gpio_chips, I've touched every
    single GPIO driver in the kernel now, oh man I didn't know I was
    responsible for so much...

    Apart from that we're churning along as usual.

    I took some effort to test and retest so it should merge nicely and we
    shook out a couple of bugs in -next.

    Infrastructural changes:

    - In struct gpio_chip, rename the .dev node to .parent to better
    reflect the fact that this is not the GPIO struct device
    abstraction. We will add that soon so this would be totallt
    confusing.

    - It was noted that the driver .get_value() callbacks was sometimes
    reporting negative -ERR values to the gpiolib core, expecting them
    to be propagated to consumer gpiod_get_value() and gpio_get_value()
    calls. This was not happening, so as there was a mess of drivers
    returning negative errors and some returning "anything else than
    zero" to indicate that a line was active. As some would have bit
    31 set to indicate "line active" it clashed with negative error
    codes. This is fixed by the largeish series clamping values in all
    drivers with !!value to [0,1] and then augmenting the code to
    propagate error codes to consumers. (Includes some ACKed patches
    in other subsystems.)

    - Add a void *data pointer to struct gpio_chip. The container_of()
    design pattern is indeed very nice, but we want to reform the
    struct gpio_chip to be a non-volative, stateless business, and keep
    states internal to the gpiolib to be able to hold on to the state
    when adding a proper userspace ABI (character device) further down
    the road. To achieve this, drivers need a handle at the internal
    state that is not dependent on their struct gpio_chip() so we add
    gpiochip_add_data() and gpiochip_get_data() following the pattern
    of many other subsystems. All the "use gpiochip data pointer"
    patches transforms drivers to this scheme.

    - The Generic GPIO chip header has been merged into the general
    header, and the custom header for that
    removed. Instead of having a separate mm_gpio_chip struct for
    these generic drivers, merge that into struct gpio_chip,
    simplifying the code and removing the need for separate and
    confusing includes.

    Misc improvements:

    - Stabilize the way GPIOs are looked up from the ACPI legacy
    specification.

    - Incremental driver features for PXA, PCA953X, Lantiq (patches from
    the OpenWRT community), RCAR, Zynq, PL061, 104-idi-48

    New drivers:

    - Add a GPIO chip to the ALSA SoC AC97 driver.

    - Add a new Broadcom NSP SoC driver (this lands in the pinctrl dir,
    but the branch is merged here too to account for infrastructural
    changes).

    - The sx150x driver now supports the sx1502"

    * tag 'gpio-v4.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (220 commits)
    gpio: generic: make bgpio_pdata always visible
    gpiolib: fix chip order in gpio list
    gpio: mpc8xxx: Do not use gpiochip_get_data() in mpc8xxx_gpio_save_regs()
    gpio: mm-lantiq: Do not use gpiochip_get_data() in ltq_mm_save_regs()
    gpio: brcmstb: Allow building driver for BMIPS_GENERIC
    gpio: brcmstb: Set endian flags for big-endian MIPS
    gpio: moxart: fix build regression
    gpio: xilinx: Do not use gpiochip_get_data() in xgpio_save_regs()
    leds: pca9532: use gpiochip data pointer
    leds: tca6507: use gpiochip data pointer
    hid: cp2112: use gpiochip data pointer
    bcma: gpio: use gpiochip data pointer
    avr32: gpio: use gpiochip data pointer
    video: fbdev: via: use gpiochip data pointer
    gpio: pch: Optimize pch_gpio_get()
    Revert "pinctrl: lantiq: Implement gpio_chip.to_irq"
    pinctrl: nsp-gpio: use gpiochip data pointer
    pinctrl: vt8500-wmt: use gpiochip data pointer
    pinctrl: exynos5440: use gpiochip data pointer
    pinctrl: at91-pio4: use gpiochip data pointer
    ...

    Linus Torvalds
     

07 Jan, 2016

1 commit

  • 78d455a2e   bcma: gpio: use gpiochip data pointer ... Browse Code »

    This makes the driver use the data pointer added to the gpio_chip
    to store a pointer to the state container instead of relying on
    container_of().

    Cc: Kalle Valo
    Cc: linux-wireless@vger.kernel.org
    Acked-by: Hauke Mehrtens
    Acked-by: Rafał Miłecki
    Signed-off-by: Linus Walleij

    Linus Walleij
     

31 Dec, 2015

1 commit

  • 0510931ef   bcma: use module_init for the main part of bus initialization ... Browse Code »

    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: Rafał Miłecki
    Signed-off-by: Kalle Valo

    Rafał Miłecki
     

19 Nov, 2015

1 commit

  • 58383c784   gpio: change member .dev to .parent ... Browse Code »

    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
    Cc: Rafał Miłecki
    Cc: Richard Purdie
    Cc: Mauro Carvalho Chehab
    Cc: Alek Du
    Cc: Jaroslav Kysela
    Cc: Takashi Iwai
    Acked-by: Dmitry Torokhov
    Acked-by: Greg Kroah-Hartman
    Acked-by: Lee Jones
    Acked-by: Jiri Kosina
    Acked-by: Hans-Christian Egtvedt
    Acked-by: Jacek Anaszewski
    Signed-off-by: Linus Walleij

    Linus Walleij
     

29 Sep, 2015

1 commit

  • 69b5f4da2   bcma: add support for population subnodes also when build as module ... Browse Code »

    of_default_bus_match_table was not exported earlier, so it could only
    be accessed by code compiled into the kernel. A new function
    of_platform_default_populate() was added which uses
    of_default_bus_match_table and this function is also exported. This way
    it is possible to create a bus with the content of
    of_default_bus_match_table and we can remove the hacks from bcma.

    Signed-off-by: Hauke Mehrtens
    Signed-off-by: Kalle Valo

    Hauke Mehrtens
     

18 Aug, 2015

1 commit