Eric Lee / smarc-fsl-linux-kernel

17 Aug, 2020

1 commit

  • 6bfa31756   HID: cp2112: Use irqchip template ... Browse Code »

    This makes the driver use the irqchip template to assign
    properties to the gpio_irq_chip instead of using the
    explicit calls to gpiochip_irqchip_add(). The irqchip is
    instead added while adding the gpiochip.

    Cc: Eudean Sun
    Cc: Benjamin Tissoires
    Cc: Sébastien Szymanski
    Signed-off-by: Linus Walleij
    Signed-off-by: Jiri Kosina

    Linus Walleij
     

20 Jul, 2020

1 commit

  • b1631b84f   HID: Replace HTTP links with HTTPS ones ... Browse Code »

    Rationale:
    Reduces attack surface on kernel devs opening the links for MITM
    as HTTPS traffic is much harder to manipulate.

    Deterministic algorithm:
    For each file:
    If not .svg:
    For each line:
    If doesn't contain `\bxmlns\b`:
    For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
    If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
    If both the HTTP and HTTPS versions
    return 200 OK and serve the same content:
    Replace HTTP with HTTPS.

    Signed-off-by: Alexander A. Klimov
    Signed-off-by: Jiri Kosina

    Alexander A. Klimov
     

19 Aug, 2019

1 commit

10 Jul, 2019

1 commit

  • 2ec98f567   Merge tag 'gpio-v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio ... Browse Code »

    Pull GPIO updates from Linus Walleij:
    "This is the big slew of GPIO changes for the v5.3 kernel cycle. This
    is mostly incremental work this time.

    Three important things:

    - The FMC subsystem is deleted through my tree. This happens through
    GPIO as its demise was discussed in relation to a patch decoupling
    its GPIO implementation from the standard way of handling GPIO. As
    it turns out, that is not the only subsystem it reimplements and
    the authors think it is better do scratch it and start over using
    the proper kernel subsystems than try to polish the rust shiny. See
    the commit (ACKed by the maintainers) for details.

    - Arnd made a small devres patch that was ACKed by Greg and goes into
    the device core.

    - SPDX header change colissions may happen, because at times I've
    seen that quite a lot changed during the -rc:s in regards to SPDX.
    (It is good stuff, tglx has me convinced, and it is worth the
    occasional pain.)

    Apart from this is is nothing controversial or problematic.

    Summary:

    Core:

    - When a gpio_chip request GPIOs from itself, it can now fully
    control the line characteristics, both machine and consumer flags.
    This makes a lot of sense, but took some time before I figured out
    that this is how it has to work.

    - Several smallish documentation fixes.

    New drivers:

    - The PCA953x driver now supports the TI TCA9539.

    - The DaVinci driver now supports the K3 AM654 SoCs.

    Driver improvements:

    - Major overhaul and hardening of the OMAP driver by Russell King.

    - Starting to move some drivers to the new API passing irq_chip along
    with the gpio_chip when adding the gpio_chip instead of adding it
    separately.

    Unrelated:

    - Delete the FMC subsystem"

    * tag 'gpio-v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (87 commits)
    Revert "gpio: tegra: Clean-up debugfs initialisation"
    gpiolib: Use spinlock_t instead of struct spinlock
    gpio: stp-xway: allow compile-testing
    gpio: stp-xway: get rid of the #include dependency
    gpio: stp-xway: improve module clock error handling
    gpio: stp-xway: simplify error handling in xway_stp_probe()
    gpiolib: Clarify use of non-sleeping functions
    gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants
    gpiolib: Document new gpio_chip.init_valid_mask field
    Documentation: gpio: Fix reference to gpiod_get_array()
    gpio: pl061: drop duplicate printing of device name
    gpio: altera: Pass irqchip when adding gpiochip
    gpio: siox: Use devm_ managed gpiochip
    gpio: siox: Add struct device *dev helper variable
    gpio: siox: Pass irqchip when adding gpiochip
    drivers: gpio: amd-fch: make resource struct const
    devres: allow const resource arguments
    gpio: ath79: Pass irqchip when adding gpiochip
    gpio: tegra: Clean-up debugfs initialisation
    gpio: siox: Switch to IRQ_TYPE_NONE
    ...

    Linus Torvalds
     

08 Jun, 2019

1 commit

  • 5923ea6c2   gpio: pass lookup and descriptor flags to request_own ... Browse Code »

    When a gpio_chip wants to request a descriptor from itself
    using gpiochip_request_own_desc() it needs to be able to specify
    fully how to use the descriptor, notably line inversion
    semantics. The workaround in the gpiolib.c can be removed
    and cases (such as SPI CS) where we need at times to request
    a GPIO with line inversion semantics directly on a chip for
    workarounds, can be fully supported with this call.

    Fix up some users of the API that weren't really using the
    last flag to set up the line as input or output properly
    but instead just calling direction setting explicitly
    after requesting the line.

    Cc: Martin Sperl
    Signed-off-by: Linus Walleij

    Linus Walleij
     

05 Jun, 2019

1 commit

  • 2025cf9e1   treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 288 ... Browse Code »

    Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms and conditions of the gnu general public license
    version 2 as published by the free software foundation this program
    is distributed in the hope it will be useful but without any
    warranty without even the implied warranty of merchantability or
    fitness for a particular purpose see the gnu general public license
    for more details

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 263 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Alexios Zavras
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190529141901.208660670@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

14 Dec, 2018

1 commit

  • 21abf1038   gpio: Pass a flag to gpiochip_request_own_desc() ... Browse Code »

    Before things go out of hand, make it possible to pass
    flags when requesting "own" descriptors from a gpio_chip.
    This is necessary if the chip wants to request a GPIO with
    active low semantics, for example.

    Cc: Janusz Krzysztofik
    Cc: Thomas Petazzoni
    Cc: Jason Cooper
    Cc: Jiri Kosina
    Cc: Roger Quadros
    Reviewed-by: Gregory CLEMENT
    Signed-off-by: Linus Walleij

    Linus Walleij
     

22 Nov, 2017

1 commit

  • 542134c03   HID: cp2112: Fix I2C_BLOCK_DATA transactions ... Browse Code »

    The existing driver erroneously treats I2C_BLOCK_DATA and BLOCK_DATA
    commands the same.

    For I2C_BLOCK_DATA reads, the length of the read is provided in
    data->block[0], but the length itself should not be sent to the slave. In
    contrast, for BLOCK_DATA reads no length is specified since the length
    will be the first byte returned from the slave. When copying data back
    to the data buffer, for an I2C_BLOCK_DATA read we have to take care not to
    overwrite data->block[0] to avoid overwriting the length. A BLOCK_DATA
    read doesn't have this concern since the first byte returned by the device
    is the length and belongs in data->block[0].

    For I2C_BLOCK_DATA writes, the length is also provided in data->block[0],
    but the length itself is not sent to the slave (in contrast to BLOCK_DATA
    writes where the length prefixes the data sent to the slave).

    This was tested on physical hardware using i2cdump with the i and s flags
    to test the behavior of I2C_BLOCK_DATA reads and BLOCK_DATA reads,
    respectively. Writes were not tested but the I2C_BLOCK_DATA write change
    is pretty simple to verify by inspection.

    Signed-off-by: Eudean Sun
    Signed-off-by: Jiri Kosina

    Eudean Sun
     

10 Nov, 2017

2 commits

21 Mar, 2017

1 commit

31 Jan, 2017

2 commits

  • 8e9faa154   HID: cp2112: fix gpio-callback error handling ... Browse Code »

    In case of a zero-length report, the gpio direction_input callback would
    currently return success instead of an errno.

    Fixes: 1ffb3c40ffb5 ("HID: cp2112: make transfer buffers DMA capable")
    Cc: stable # 4.9
    Signed-off-by: Johan Hovold
    Reviewed-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Johan Hovold
     
  • 7a7b5df84   HID: cp2112: fix sleep-while-atomic ... Browse Code »

    A recent commit fixing DMA-buffers on stack added a shared transfer
    buffer protected by a spinlock. This is broken as the USB HID request
    callbacks can sleep. Fix this up by replacing the spinlock with a mutex.

    Fixes: 1ffb3c40ffb5 ("HID: cp2112: make transfer buffers DMA capable")
    Cc: stable # 4.9
    Signed-off-by: Johan Hovold
    Reviewed-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Johan Hovold
     

28 Nov, 2016

1 commit

24 Nov, 2016

1 commit

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

28 Dec, 2015

1 commit

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
     

15 Jul, 2015

1 commit

14 Jul, 2015

1 commit

  • 6d00d153f   HID: cp2112: fix I2C_SMBUS_BYTE write ... Browse Code »

    When doing an I2C_SMBUS_BYTE write (one byte write, no address),
    the data to be written is in "command" not "data->byte".

    Signed-off-by: Ellen Wang
    Acked-by: Wolfram Sang
    Reviewed-by: Antonio Borneo
    Cc: stable@vger.kernel.org
    Signed-off-by: Jiri Kosina

    Ellen Wang
     

10 Jul, 2015

1 commit

  • 44eda784a   HID: cp2112: support i2c write-read transfers in hid-cp2112 ... Browse Code »

    cp2112_i2c_xfer() only supports a single i2c_msg. More than
    one message at a time just returns EIO. This breaks certain
    important cases. For example, the at24 eeprom driver generates
    paired write and read messages (for eeprom address and data).

    Since the device doesn't support i2c repeated starts in general,
    but does support a single write-repeated-start-read pair
    (since hardware rev 1), we recognize the latter case and
    implement only that.

    Signed-off-by: Ellen Wang
    Signed-off-by: Jiri Kosina

    Ellen Wang
     

09 Jul, 2015

1 commit

08 Jul, 2015

1 commit

  • 6debce6f4   HID: cp2112: fix to force single data-report reply ... Browse Code »

    Current implementation of cp2112_raw_event() only accepts one data report at a
    time. If last received data report is not fully handled yet, a new incoming
    data report will overwrite it. In such case we don't guaranteed to propagate
    the correct incoming data.

    The trivial fix implemented here forces a single report at a time by requesting
    in cp2112_read() no more than 61 byte of data, which is the payload size of a
    single data report.

    Cc: stable@vger.kernel.org
    Signed-off-by: Antonio Borneo
    Tested-by: Ellen Wang
    Signed-off-by: Jiri Kosina

    Antonio Borneo
     

19 Sep, 2014

1 commit

29 Jul, 2014

1 commit

  • b9029345e   HID: cp2112: add I2C mode ... Browse Code »

    cp2112 supports single I2C read/write transactions. It can't combine I2C
    transactions.

    Add master_xfer, using similar code flow as for smbus_xfer.

    Signed-off-by: Antonio Borneo
    Reviewed-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Antonio Borneo
     

07 Jul, 2014

1 commit

  • beb9d007a   HID: cp2112: fix gpio value in gpio_direction_output ... Browse Code »

    CP2112 does not offer an atomic method to set both gpio
    direction and value.
    Also it does not permit to set gpio value before putting
    gpio in output. In fact, accordingly to Silicon Labs
    AN495, Rev. 0.2, cpt. 4.4, the HID report to set gpio
    values "does not affect any pins that are not configured
    as outputs".

    This is confirmed on evaluation board CP2112-EK.
    With current driver, after execute:
    echo in > /sys/class/gpio/gpio248/direction
    echo low > /sys/class/gpio/gpio248/direction
    gpio output is still high. Only after a following
    echo low > /sys/class/gpio/gpio248/direction
    gpio output gets low.

    Fix driver by changing order of operations; first set
    direction then set value.

    The drawback of this new sequence is that we can have
    a pulse on gpio pin when direction is changed from
    input to output-low, but this cannot be avoided on
    current CP2112.

    Signed-off-by: Antonio Borneo
    Reviewed-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Antonio Borneo
     

14 Mar, 2014

2 commits

18 Feb, 2014

5 commits