Pull RISC-V updates from Palmer Dabbelt:
"A handful of new RISC-V related patches for this merge window:
- A check to ensure drivers are properly using uaccess. This isn't
manifesting with any of the drivers I'm currently using, but may
catch errors in new drivers.
- Some preliminary support for the FU740, along with the HiFive
Unleashed it will appear on.
- NUMA support for RISC-V, which involves making the arm64 code
generic.
- Support for kasan on the vmalloc region.
- A handful of new drivers for the Kendryte K210, along with the DT
plumbing required to boot on a handful of K210-based boards.
- Support for allocating ASIDs.
- Preliminary support for kernels larger than 128MiB.
- Various other improvements to our KASAN support, including the
utilization of huge pages when allocating the KASAN regions.
We may have already found a bug with the KASAN_VMALLOC code, but it's
passing my tests. There's a fix in the works, but that will probably
miss the merge window.
* tag 'riscv-for-linus-5.12-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: (75 commits)
riscv: Improve kasan population by using hugepages when possible
riscv: Improve kasan population function
riscv: Use KASAN_SHADOW_INIT define for kasan memory initialization
riscv: Improve kasan definitions
riscv: Get rid of MAX_EARLY_MAPPING_SIZE
soc: canaan: Sort the Makefile alphabetically
riscv: Disable KSAN_SANITIZE for vDSO
riscv: Remove unnecessary declaration
riscv: Add Canaan Kendryte K210 SD card defconfig
riscv: Update Canaan Kendryte K210 defconfig
riscv: Add Kendryte KD233 board device tree
riscv: Add SiPeed MAIXDUINO board device tree
riscv: Add SiPeed MAIX GO board device tree
riscv: Add SiPeed MAIX DOCK board device tree
riscv: Add SiPeed MAIX BiT board device tree
riscv: Update Canaan Kendryte K210 device tree
dt-bindings: add resets property to dw-apb-timer
dt-bindings: fix sifive gpio properties
dt-bindings: update sifive uart compatible string
dt-bindings: update sifive clint compatible string
...
Pull pin control updates from Linus Walleij:
"This is the bulk of pin control changes for the v5.12 kernel.
This time a calm set with no core changes.
New drivers/subdrivers:
- Renesas R8A7790A0 pin controller.
- Allwinner H616 and H616-R pin controllers.
- Qualcomm SM8350 and SC8180x pin controllers.
Improvements:
- Redo the DT bindings for Ralink RT2880.
- A common Qualcomm TLMM DT binding in YAML.
- Delete the unused drivers for U300, COH901, Sirf Atlas, and ZTE ZX"
* tag 'pinctrl-v5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (71 commits)
pinctrl: mediatek: Fix trigger type setting follow for unexpected interrupt
dt-bindings: pinctrl: Group tuples in pin control properties
pinctrl: nuvoton: npcm7xx: Fix alignment of table header comment
pinctrl: at91-pio4: fix "Prefer 'unsigned int' to bare use of 'unsigned'"
pinctrl: at91-pio4: add support for slew-rate
dt-bindings: pinctrl: at91-pio4: add slew-rate
pinctrl: actions: Add depends on || COMPILE_TEST
pinctrl: single: set function name when adding function
pinctrl: qcom: Add sc8180x TLMM driver
dt-bindings: pinctrl: qcom: Add sc8180x binding
dt-bindings: pinctrl: qcom: Define common TLMM binding
pinctrl: qcom: Add SM8350 pinctrl driver
dt-bindings: pinctrl: qcom: Add SM8350 pinctrl bindings
pinctrl: samsung: use raw_spinlock for s3c64xx
dt-bindings: mediatek: mt8192: Fix dt_binding_check warning
pinctrl: qcom: spmi-mpp: Add PM8019 compatible
pinctrl: pinmux: add function selector to pinmux-functions
pinctrl: samsung: use raw_spinlock for locking
pinctrl: clarify #pinctrl-cells for pinctrl-single,pins
pinctrl: actions: Add the platform dependency to drivers
...
Add the pinctrl-k210.c pinctrl driver for the Canaan Kendryte K210
field programmable IO array (FPIOA) to allow configuring the SoC pin
functions. The K210 has 48 programmable pins which can take any of 256
possible functions.
This patch is inspired from the k210 pinctrl driver for the u-boot
project and contains many direct contributions from Sean Anderson.
The MAINTAINERS file is updated, adding the entry "CANAAN/KENDRYTE K210
SOC FPIOA DRIVER" with myself listed as maintainer for this driver.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
I happened to apply the v1 of the patch restriction the
selection to ARM or ARM64, sorry for my sloppiness.
Fixing up the mistake as I can't back the patch out now.
Fixes: 5784921f7b ("pinctrl: actions: Add the platform dependency to drivers")
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pcs_add_function() fails to set the function name in struct pcs_function
when adding a new function. As a result this line in pcs_set_mux():
dev_dbg(pcs->dev, "enabling %s function%i\n",
func->name, fselector);
prints "(null)" for the function:
pinctrl-single 44e10800.pinmux: enabling (null) function0
pinctrl-single 44e10800.pinmux: enabling (null) function1
pinctrl-single 44e10800.pinmux: enabling (null) function2
pinctrl-single 44e10800.pinmux: enabling (null) function3
With this fix, the output is now:
pinctrl-single 44e10800.pinmux: enabling pinmux-uart0-pins function0
pinctrl-single 44e10800.pinmux: enabling pinmux-mmc0-pins function1
pinctrl-single 44e10800.pinmux: enabling pinmux-i2c0-pins function2
pinctrl-single 44e10800.pinmux: enabling pinmux-mmc0-pins function3
Cc: Jason Kridner <jkridner@beagleboard.org>
Cc: Robert Nelson <robertcnelson@beagleboard.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Drew Fustini <drew@beagleboard.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20210125203542.51513-1-drew@beagleboard.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
intel-pinctrl for v5.12-1
* Enable pin control on Intel Alder Lake-P
* Traverse through capabilities, convert them to features for the future use
The following is an automated git shortlog grouped by driver:
intel:
- Convert capability list to features
- Drop unnecessary check for predefined features
- Split intel_pinctrl_add_padgroups() for better maintenance
tigerlake:
- Add Alder Lake-P ACPI ID
Add the function selector to the pinmux-functions debugfs output. This
is an integer which is the index into the pinmux function tree. It will
make it easier to correlate function name to function selector without
having to count the lines in the output.
Example output of "pinmux-functions":
function 0: pinmux-uart0-pins, groups = [ pinmux-uart0-pins ]
function 1: pinmux-uart1-pins, groups = [ pinmux-uart1-pins ]
function 2: pinmux-uart2-pins, groups = [ pinmux-uart2-pins ]
function 3: pinmux-mmc0-pins, groups = [ pinmux-mmc0-pins ]
function 3: pinmux-mmc1-pins, groups = [ pinmux-mmc1-pins ]
function 5: pinmux-i2c0-pins, groups = [ pinmux-i2c0-pins ]
function 6: pinmux-i2c1-pins, groups = [ pinmux-i2c1-pins ]
function 7: pinmux-i2c2-pins, groups = [ pinmux-i2c2-pins ]
function 8: pinmux-pwm0-pins, groups = [ pinmux-pwm0-pins ]
function 9: pinmux-pwm1-pins, groups = [ pinmux-pwm1-pins ]
function 10: pinmux-adc-pins, groups = [ pinmux-adc-pins ]
Cc: Jason Kridner <jkridner@beagleboard.org>
Cc: Robert Nelson <robertcnelson@beagleboard.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Drew Fustini <drew@beagleboard.org>
Link: https://lore.kernel.org/r/20210123202212.528046-1-drew@beagleboard.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch converts spin_[lock|unlock] functions of pin bank to
raw_spinlock to support preempt-rt. This can avoid BUG() assertion when
irqchip callbacks are triggerred. Spinlocks can be converted rt_mutex
which is preemptible when we apply preempt-rt patches.
According to "Documentation/driver-api/gpio/driver.rst",
"Realtime considerations: a realtime compliant GPIO driver should not
use spinlock_t or any sleepable APIs (like PM runtime) as part of its
irqchip implementation.
- spinlock_t should be replaced with raw_spinlock_t.[1]
"
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20210121030009.25673-1-chanho61.park@samsung.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- Add otg function and otg-vbus group.
- Add lcd-8bit, lcd-16bit, lcd-18bit, lcd-generic and lcd-special
groups. Change the lcd-24bit group so that it only selects the pins
that aren't in the lcd-18bit and lcd-generic groups (which breaks
Device Tree in theory, but there is none out there for any JZ4760
based board, yet). Remove the lcd-no-pins group which is just useless.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210120110722.20133-1-paul@crapouillou.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In Linux, if a driver does disable_irq() and later does enable_irq()
on its interrupt, I believe it's expecting these properties:
* If an interrupt was pending when the driver disabled then it will
still be pending after the driver re-enables.
* If an edge-triggered interrupt comes in while an interrupt is
disabled it should assert when the interrupt is re-enabled.
If you think that the above sounds a lot like the disable_irq() and
enable_irq() are supposed to be masking/unmasking the interrupt
instead of disabling/enabling it then you've made an astute
observation. Specifically when talking about interrupts, "mask"
usually means to stop posting interrupts but keep tracking them and
"disable" means to fully shut off interrupt detection. It's
unfortunate that this is so confusing, but presumably this is all the
way it is for historical reasons.
Perhaps more confusing than the above is that, even though clients of
IRQs themselves don't have a way to request mask/unmask
vs. disable/enable calls, IRQ chips themselves can implement both.
...and yet more confusing is that if an IRQ chip implements
disable/enable then they will be called when a client driver calls
disable_irq() / enable_irq().
It does feel like some of the above could be cleared up. However,
without any other core interrupt changes it should be clear that when
an IRQ chip gets a request to "disable" an IRQ that it has to treat it
like a mask of that IRQ.
In any case, after that long interlude you can see that the "unmask
and clear" can break things. Maulik tried to fix it so that we no
longer did "unmask and clear" in commit 71266d9d39 ("pinctrl: qcom:
Move clearing pending IRQ to .irq_request_resources callback"), but it
only handled the PDC case and it had problems (it caused
sc7180-trogdor devices to fail to suspend). Let's fix.
>From my understanding the source of the phantom interrupt in the
were these two things:
1. One that could have been introduced in msm_gpio_irq_set_type()
(only for the non-PDC case).
2. Edges could have been detected when a GPIO was muxed away.
Fixing case #1 is easy. We can just add a clear in
msm_gpio_irq_set_type().
Fixing case #2 is harder. Let's use a concrete example. In
sc7180-trogdor.dtsi we configure the uart3 to have two pinctrl states,
sleep and default, and mux between the two during runtime PM and
system suspend (see geni_se_resources_{on,off}() for more
details). The difference between the sleep and default state is that
the RX pin is muxed to a GPIO during sleep and muxed to the UART
otherwise.
As per Qualcomm, when we mux the pin over to the UART function the PDC
(or the non-PDC interrupt detection logic) is still watching it /
latching edges. These edges don't cause interrupts because the
current code masks the interrupt unless we're entering suspend.
However, as soon as we enter suspend we unmask the interrupt and it's
counted as a wakeup.
Let's deal with the problem like this:
* When we mux away, we'll mask our interrupt. This isn't necessary in
the above case since the client already masked us, but it's a good
idea in general.
* When we mux back will clear any interrupts and unmask.
Fixes: 4b7618fdc7 ("pinctrl: qcom: Add irq_enable callback for msm gpio")
Fixes: 71266d9d39 ("pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Maulik Shah <mkshah@codeaurora.org>
Tested-by: Maulik Shah <mkshah@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210114191601.v7.4.I7cf3019783720feb57b958c95c2b684940264cd1@changeid
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When the Qualcomm pinctrl driver wants to Ack an interrupt, it does a
read-modify-write on the interrupt status register. On some SoCs it
makes sure that the status bit is 1 to "Ack" and on others it makes
sure that the bit is 0 to "Ack". Presumably the first type of
interrupt controller is a "write 1 to clear" type register and the
second just let you directly set the interrupt status register.
As far as I can tell from scanning structure definitions, the
interrupt status bit is always in a register by itself. Thus with
both types of interrupt controllers it is safe to "Ack" interrupts
without doing a read-modify-write. We can do a simple write.
It should be noted that if the interrupt status bit _was_ ever in a
register with other things (like maybe status bits for other GPIOs):
a) For "write 1 clear" type controllers then read-modify-write would
be totally wrong because we'd accidentally end up clearing
interrupts we weren't looking at.
b) For "direct set" type controllers then read-modify-write would also
be wrong because someone setting one of the other bits in the
register might accidentally clear (or set) our interrupt.
I say this simply to show that the current read-modify-write doesn't
provide any sort of "future proofing" of the code. In fact (for
"write 1 clear" controllers) the new code is slightly more "future
proof" since it would allow more than one interrupt status bits to
share a register.
NOTE: this code fixes no bugs--it simply avoids an extra register
read.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Maulik Shah <mkshah@codeaurora.org>
Tested-by: Maulik Shah <mkshah@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210114191601.v7.2.I3635de080604e1feda770591c5563bd6e63dd39d@changeid
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
