Andy Shevchenko [Tue, 18 Mar 2025 10:57:18 +0000 (12:57 +0200)]
pinctrl: nuvoton: Reduce use of OF-specific APIs
Some drivers are using device property APIs along with OF-specific ones.
At the same time few of the latter can be converted to device property
calls. Reduce use of OF-specific APIs in order to bring a bit more consistency
into the drivers.
Sparse is not happy about implementation of the NPCM8XX_PINCFG()
pinctrl-npcm8xx.c:1314:9: warning: obsolete array initializer, use C99 syntax
pinctrl-npcm8xx.c:1315:9: warning: obsolete array initializer, use C99 syntax
...
pinctrl-npcm8xx.c:1412:9: warning: obsolete array initializer, use C99 syntax
pinctrl-npcm8xx.c:1413:9: warning: too many warnings
which uses index-based assignment in a wrong way, i.e. it missed
the equal sign and hence the index is simply ignored, while the
entries are indexed naturally. This is not a problem as the pin
numbering repeats the natural order, but it might be in case of
shuffling the entries. Fix this by adding missed equal sign and
reformat a bit for better readability.
pinctrl: PINCTRL_AMDISP should depend on DRM_AMD_ISP
The AMD Image Signal Processor GPIO pin control functionality is only
present on AMD platforms with ISP support, and its platform device is
instantiated by the AMD ISP driver. Hence add a dependency on
DRM_AMD_ISP, to prevent asking the user about this driver when
configuring a kernel that does not support the AMD ISP.
Linus Walleij [Tue, 18 Mar 2025 10:09:15 +0000 (11:09 +0100)]
Merge tag 'samsung-pinctrl-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung into devel
Samsung pinctrl drivers changes for v6.15
1. Add pin controller drivers for newly usptreamed Samsung Exynos2200
and Exynos7870.
2. Correct filter configuration offset of some of Google GS101 SoC pin
banks, which later is supposed to be used during system
suspend/resume.
In commit 'cf9d052aa600 ("pinctrl: qcom: Don't clear pending interrupts
when enabling")' Doug establishes an expectation that edge interrupts
occurring while an interrupt is disabled should be delivered once the
interrupt is enabled again.
Implement a test to validate that this is the case.
Stephan Gerhold [Wed, 12 Mar 2025 13:19:27 +0000 (14:19 +0100)]
pinctrl: qcom: Clear latched interrupt status when changing IRQ type
When submitting the TLMM test driver, Bjorn reported that some of the test
cases are failing for GPIOs that not are backed by PDC (i.e. "non-wakeup"
GPIOs that are handled directly in pinctrl-msm). Basically, lingering
latched interrupt state is still being delivered at IRQ request time, e.g.:
ok 1 tlmm_test_silent_rising
tlmm_test_silent_falling: ASSERTION FAILED at drivers/pinctrl/qcom/tlmm-test.c:178
Expected atomic_read(&priv->intr_count) == 0, but
atomic_read(&priv->intr_count) == 1 (0x1)
not ok 2 tlmm_test_silent_falling
tlmm_test_silent_low: ASSERTION FAILED at drivers/pinctrl/qcom/tlmm-test.c:178
Expected atomic_read(&priv->intr_count) == 0, but
atomic_read(&priv->intr_count) == 1 (0x1)
not ok 3 tlmm_test_silent_low
ok 4 tlmm_test_silent_high
Whether to report interrupts that came in while the IRQ was unclaimed
doesn't seem to be well-defined in the Linux IRQ API. However, looking
closer at these specific cases, we're actually reporting events that do not
match the interrupt type requested by the driver:
1. After "ok 1 tlmm_test_silent_rising", the GPIO is in low state and
configured for IRQF_TRIGGER_RISING.
2. (a) In preparation for "tlmm_test_silent_falling", the GPIO is switched
to high state. The rising interrupt gets latched.
(b) The GPIO is re-configured for IRQF_TRIGGER_FALLING, but the latched
interrupt isn't cleared.
(c) The IRQ handler is called for the latched interrupt, but there
wasn't any falling edge.
3. (a) For "tlmm_test_silent_low", the GPIO remains in high state.
(b) The GPIO is re-configured for IRQF_TRIGGER_LOW. This seems to
result in a phantom interrupt that gets latched.
(c) The IRQ handler is called for the latched interrupt, but the GPIO
isn't in low state.
4. (a) For "tlmm_test_silent_high", the GPIO is switched to low state.
(b) This doesn't result in a latched interrupt, because RAW_STATUS_EN
was cleared when masking the level-triggered interrupt.
Fix this by clearing the interrupt state whenever making any changes to the
interrupt configuration. This includes previously disabled interrupts, but
also any changes to interrupt polarity or detection type.
With this change, all 16 test cases are now passing for the non-wakeup
GPIOs in the TLMM.
Tegra devices have an 'sfsel' bit field that determines whether a pin
operates in SFIO (Special Function I/O) or GPIO mode. Currently,
tegra_pinctrl_gpio_disable_free() sets this bit when releasing a GPIO.
However, tegra_pinctrl_set_mux() can be called independently in certain
code paths where gpio_disable_free() is not invoked. In such cases, failing
to set the SFIO mode could lead to incorrect pin configurations, resulting
in functional issues for peripherals relying on SFIO.
This patch ensures that whenever set_mux() is called, the SFIO mode is
correctly set in the Mux Register if the 'sfsel' bit is present. This
prevents situations where the pin remains in GPIO mode despite being
configured for SFIO use.
pinctrl-tegra: Restore SFSEL bit when freeing pins
Each pin can be configured as a Special Function IO (SFIO) or GPIO,
where the SFIO enables the pin to operate in alternative modes such as
I2C, SPI, etc.
The current implementation sets all the pins back to SFIO mode
even if they were initially in GPIO mode. This can cause glitches
on the pins when pinctrl_gpio_free() is called.
Avoid these undesired glitches by storing the pin's SFIO/GPIO
state on GPIO request and restoring it on GPIO free.
pinctrl: tegra: Add descriptions for SoC data fields
Add detailed descriptions for the remaining fields in the
tegra_pinctrl_soc_data structure. This improves code documentation
and clarifies the purpose of each field, particularly for the
pin-specific configuration options.
Andre Przywara [Thu, 6 Mar 2025 23:58:27 +0000 (23:58 +0000)]
pinctrl: sunxi: Add support for the secondary A523 GPIO ports
As most other Allwinner SoCs before, the A523 chip contains a second
GPIO controller, managing banks PL and PM.
Use the newly introduced DT based pinctrl driver to describe just the
generic pinctrl properties, so advertise the number of pins per bank
and the interrupt capabilities. The actual function/mux assignment is
taken from the devicetree.
Andre Przywara [Thu, 6 Mar 2025 23:58:26 +0000 (23:58 +0000)]
pinctrl: sunxi: Add support for the Allwinner A523
The Allwinner A523 contains pins in 10 out of the 11 possible pin banks;
it just skips port A.
Use the newly introduced DT based pinctrl driver to describe just the
generic pinctrl properties, so advertise the number of pins per bank
and the interrupt capabilities. The actual function/mux assignment is
taken from the devicetree.
Andre Przywara [Thu, 6 Mar 2025 23:58:25 +0000 (23:58 +0000)]
dt-bindings: pinctrl: add compatible for Allwinner A523/T527
The A523 contains a pin controller similar to previous SoCs, although
using 10 GPIO banks (PortB-PortK), all of them being IRQ capable.
With this SoC we introduce a new style of binding, where the pinmux values
for each pin group are stored in the new "allwinner,pinmux" property in
the DT node, instead of requiring every driver to store a mapping between
the function names and the required pinmux.
Add a new binding file, since all the different variants of the old
binding are making the file a bit unwieldy to handle already, and the new
property would make the situation worse.
Andre Przywara [Thu, 6 Mar 2025 23:58:24 +0000 (23:58 +0000)]
pinctrl: sunxi: allow reading mux values from DT
So far every Allwinner SoC needs a large table in the kernel code, to
describe the mapping between the pinctrl function names ("uart") and
the actual pincontroller mux value to be written into the registers.
This adds a lot of data into a single image kernel, and also looks
somewhat weird, as the DT can easily store the mux value.
Add some code that allows to avoid that table: the struct that describes
the existing pins will be build at *runtime*, based on very basic
information provided by the respective SoC's pinctrl driver. This
consists of the number of pins per bank, plus information which bank
provides IRQ support, along with the mux value to use for that.
The code will then iterate over all children of the pincontroller DT
node (which describe each pin group), and populate that struct with the
mapping between function names and mux values. The only thing that needs
adding in the DT is a property with that value, per pin group.
When this table is built, it will be handed over to the existing sunxi
pinctrl driver, which cannot tell a difference between a hardcoded
struct and this new one built at runtime. It will take care of
registering the pinctrl device with the pinctrl subsystem.
All a new SoC driver would need to do is to provide two arrays, and then
call the sunxi_pinctrl_dt_table_init() function.
Andre Przywara [Thu, 6 Mar 2025 23:58:23 +0000 (23:58 +0000)]
pinctrl: sunxi: support moved power configuration registers
The Allwinner pincontroller IP features some registers to control the
withstand voltage of each pin group. So far those registers were always
located at the same offset, but the A523 SoC has moved them (probably to
accommodate all eleven pin banks).
Add a flag to note this feature, and use that to program the registers
either at offset 0x340 or 0x380. So far no pincontroller driver uses
this flag, but we need it for the upcoming A523 support.
Andre Przywara [Thu, 6 Mar 2025 23:58:22 +0000 (23:58 +0000)]
pinctrl: sunxi: move bank K register offset
The Allwinner pincontroller register layout used to allow for at least
11 banks per controller, any more banks would reside at a second
controller instance.
When the per-bank register map size was increased with the D1, it turned
out that the last bank (port K) of those maximum 11 banks actually would
not fit anymore in the 512 bytes reserved for the pincontroller registers.
On new SoCs Allwinner thus moved the last bank beyond the existing
registers, at offset 0x500.
So far SoCs never used more than 9 banks per controller, but the new
Allwinner A523 actually uses all 11 banks. Since that SoC also uses the
extended layout, its PortK needs to be programmed at offset 0x500.
Factor out the bank offset calculation into a new function, and handle
the case for the last bank separately. Since none of the older SoCs ever
used PortK, we can ignore this case, and just always use offset 0x500
for the last bank.
Andre Przywara [Thu, 6 Mar 2025 23:58:21 +0000 (23:58 +0000)]
pinctrl: sunxi: increase number of GPIO bank regulators
By design, the Allwinner pinctrl IP always supported up to 11 GPIO banks,
though no SoC ever used more than 9 banks so far.
The Allwinner A523 has pins in all 11 banks, which exceeds the number of
per-bank regulators that we currently support, as this was set to 9.
Increase the size of the array to hold up to 11 regulator structs, to
support pins in bank J and K as well.
Andre Przywara [Thu, 6 Mar 2025 23:58:20 +0000 (23:58 +0000)]
pinctrl: sunxi: refactor pinctrl variants into flags
For some Allwinner SoCs we have one pinctrl driver caring for multiple
very similar chips, and are tagging certain pins with a variant bitmask.
The Allwinner D1 introduced a slightly extended register layout, and we
were abusing this variant mask to convey this bit of information into
the common code part.
Now there will be more pinctrl device properties to consider (has PortF
voltage switch, for instance), so shoehorning this into the variant
bitmask will not fly anymore.
Refactor the "variant" field into a more generic "flags" field. It turns
out that we don't need the variant bits to be unique across all SoCs,
but only among those SoCs that share one driver (table), of which there
are at most three variants at the moment. So the actual variant field can
be limited to say 8 bits, and the other bits in the flag register can be
re-purposed to hold other information, like this extended register
layout.
As a side effect we can move the variant definition into the per-SoC
pinctrl driver file, which makes it more obvious that this is just a
private definition, only relevant for this particular table.
This also changes the artificial sun20i-d1 "variant" into the actual
flag bit that we are after.
Linus Walleij [Thu, 13 Mar 2025 08:57:46 +0000 (09:57 +0100)]
Merge tag 'intel-pinctrl-v6.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into devel
intel-pinctrl for v6.15-1
* Introduce devm_kmemdup_array() and convert Intel pin control drivers
* Update PWM handling for the cases when it's provided by Intel pin control
* Miscellaneous fixes, updates, and cleanups
The following is an automated git shortlog grouped by driver:
baytrail:
- copy communities using devm_kmemdup_array()
- Use dedicated helpers for chained IRQ handlers
cherryview:
- use devm_kmemdup_array()
devres:
- Introduce devm_kmemdup_array()
driver core:
- Split devres APIs to device/devres.h
err.h:
- move IOMEM_ERR_PTR() to err.h
iio:
- adc: xilinx-xadc-core: use devm_kmemdup_array()
- imu: st_lsm9ds0: Replace device.h with what is needed
input:
- ipaq-micro-keys: use devm_kmemdup_array()
- sparse-keymap: use devm_kmemdup_array()
intel:
- drop repeated config dependency
- copy communities using devm_kmemdup_array()
- Fix wrong bypass assignment in intel_pinctrl_probe_pwm()
- Import PWM_LPSS namespace for devm_pwm_lpss_probe()
lynxpoint:
- Use dedicated helpers for chained IRQ handlers
MAINTAINERS:
- Add pin control and GPIO to the Intel MID record
pwm:
- lpss: Clarify the bypass member semantics in struct pwm_lpss_boardinfo
- lpss: Actually use a module namespace by defining the namespace earlier
Peter Griffin [Fri, 7 Mar 2025 10:29:05 +0000 (10:29 +0000)]
pinctrl: samsung: add support for eint_fltcon_offset
On gs101 SoC the fltcon0 (filter configuration 0) offset isn't at a
fixed offset like previous SoCs as the fltcon1 register only exists when
there are more than 4 pins in the bank.
Add a eint_fltcon_offset and new GS101_PIN_BANK_EINT* macros that take
an additional fltcon_offs variable.
This can then be used in suspend/resume callbacks to save and restore
the fltcon0 and fltcon1 registers.
Fixes: 4a8be01a1a7a ("pinctrl: samsung: Add gs101 SoC pinctrl configuration") Cc: stable@vger.kernel.org Reviewed-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20250307-pinctrl-fltcon-suspend-v4-1-2d775e486036@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
of_parse_phandle_with_fixed_args() requires its caller to
call into of_node_put() on the node pointer from the output
structure, but such a call is currently missing.
of_parse_phandle_with_fixed_args() requires its caller to
call into of_node_put() on the node pointer from the output
structure, but such a call is currently missing.
of_parse_phandle_with_fixed_args() requires its caller to
call into of_node_put() on the node pointer from the output
structure, but such a call is currently missing.
Artur Weber [Mon, 3 Mar 2025 20:54:49 +0000 (21:54 +0100)]
pinctrl: bcm281xx: Add support for BCM21664 pinmux
BCM21664 is another chip from the Kona line of Broadcom SoCs, and
its pinmux shares a lot of similarities with the BCM281xx pinmux.
Add support for the BCM21664 pinmux controller to the BCM281xx driver.
This also enables pinmux support for the BCM23550, which has an
identical pinmux config to the BCM21664 (hence they can share a
single compatible, brcm,bcm21664-pinctrl).
Artur Weber [Mon, 3 Mar 2025 20:54:48 +0000 (21:54 +0100)]
pinctrl: bcm281xx: Provide pinctrl device info as OF platform data
Introduce a new struct type, "bcm281xx_pinctrl_info", that holds
information about the pins, pin functions and regmap config for a pin
control chip. Create such a struct for the BCM218xx and pass it as
device data for the OF compatible match.
This is done in preparation for introducing additional chip types
to the driver.
Artur Weber [Mon, 3 Mar 2025 20:54:46 +0000 (21:54 +0100)]
dt-bindings: pinctrl: Add bindings for BCM21664 pin controller
Add device tree bindings for the pin controller included in the
BCM21664 chip. The bindings are based off brcm,bcm11351-pinctrl.yaml;
both chips use the same driver, but have different pins, and the
BCM21664 has 6 alt modes instead of 4.
pinctrl: bcm2835: don't -EINVAL on alternate funcs from get_direction()
Since commit 9d846b1aebbe ("gpiolib: check the return value of
gpio_chip::get_direction()") we check the return value of the
get_direction() callback as per its API contract. This driver returns
-EINVAL if the pin in question is set to one of the alternative
(non-GPIO) functions. This isn't really an error that should be
communicated to GPIOLIB so default to returning the "safe" value of
INPUT in this case. The GPIO subsystem does not have the notion of
"unknown" direction.
Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/all/Z7VFB1nST6lbmBIo@finisterre.sirena.org.uk/ Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/20250219102750.38519-1-brgl@bgdev.pl Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Bjorn Andersson [Thu, 27 Feb 2025 20:39:30 +0000 (12:39 -0800)]
pinctrl: qcom: Add test case for TLMM interrupt handling
While looking at the X1E PDC GPIO interrupts it became clear that we're
lacking a convenient and accessible way to validate if the TLMM
interrupt code performing as expected.
This introduces a kunit-based "hack" that relies on pin bias/pull
configuration to tickle the interrupt logic in non-connected pins to
allow us to evaluate that an expected number of interrupts are
delivered.
The bias/pull configuration is done with mmio accesses directly from the
test code, to avoid having to programmatically acquire and drive the
pinconf interface for the test pin. This limits the scalability of the
code to targets with a particular register layout, but serves our needs
for now.
The pin to be used for testing is specified by the tester using the
"tlmm-test.gpio" module parameter.
Worth mentioning is that some of the test cases currently fails for
GPIOs that is not backed by PDC (i.e. "non-wakeup" GPIOs), as lingering
latched interrupt state is being delivered at IRQ request time.
Prathamesh Shete [Tue, 17 Dec 2024 15:32:49 +0000 (21:02 +0530)]
pinctrl-tegra: Add config property GPIO mode
The SFIO/GPIO select bit is a crucial part of Tegra's pin multiplexing
system:
- When set to 1, the pin operates in SFIO mode, controlled by the
pin's assigned special function.
- When set to 0, the pin operates as a general-purpose GPIO.
This SFIO/GPIO select bit that is set for a given pin is not displayed,
adding the support to retrieve this information from the
pinmux set for each pin.
Xianwei Zhao [Wed, 12 Feb 2025 05:20:52 +0000 (13:20 +0800)]
pinctrl: Add driver support for Amlogic SoCs
Add a new pinctrl driver for Amlogic SoCs. All future Amlogic
SoCs pinctrl drives use this, such A4, A5, S6, S7 etc. To support
new Amlogic SoCs, only need to add the corresponding dts file.
Xianwei Zhao [Wed, 12 Feb 2025 05:20:51 +0000 (13:20 +0800)]
pinctrl: pinconf-generic: Add API for pinmux propertity in DTS file
When describing pin mux func through pinmux propertity,
a standard API is added for support. The pinmux contains pin
identification and mux values, which can include multiple
pins. And groups configuration use other word. DTS such as:
Inochi Amaoto [Tue, 11 Feb 2025 05:17:53 +0000 (13:17 +0800)]
dt-bindings: pinctrl: Add pinctrl for Sophgo SG2042 series SoC
SG2042 introduces a simple pinctrl device for all configurable pins.
For the SG2042 pinctl register file, each register (32 bits) is
responsible for two pins, each occupying the upper 16 bits and lower
16 bits of the register. It supports setting pull up/down, drive
strength and input schmitt trigger.
Inochi Amaoto [Tue, 11 Feb 2025 05:17:52 +0000 (13:17 +0800)]
pinctrl: sophgo: introduce generic probe function
Since different series of the Sophgo chip share a common pinctrl data
structure. It is necessary to add a common probe function to alloc
the this data structure. Add pctrl_init callback to allow soc to perform
its own initialization.
Inochi Amaoto [Tue, 11 Feb 2025 05:17:51 +0000 (13:17 +0800)]
pinctrl: sophgo: generalize shareable code of cv18xx pinctrl driver
With generic data structure, it is possible to generalize vddio
operators and DT parsing code of cv18xx pinctrl driver. Introduce
sophgo_cfg_ops callback to allow the driver to adjust the soc
logic and share common code.
Inochi Amaoto [Tue, 11 Feb 2025 05:17:50 +0000 (13:17 +0800)]
pinctrl: sophgo: introduce generic data structure for cv18xx pinctrl driver
To share DT parsing and vddio code, it is necessary to introduce
some generic data structure to abstract the different cv18xx series
and the incoming sg2042 series.
Inochi Amaoto [Tue, 11 Feb 2025 05:17:49 +0000 (13:17 +0800)]
pinctrl: sophgo: avoid to modify untouched bit when setting cv1800 pinconf
When setting pinconf configuration for cv1800 SoC, the driver just writes
the value. It may zero some bits of the pinconf register and cause some
unexpected error. Add a mask to avoid this.
Andy Shevchenko [Tue, 25 Feb 2025 11:16:46 +0000 (13:16 +0200)]
Merge tag 'ib-devres-iio-input-pinctrl-v6.15' into intel/pinctrl
There are a few Intel pin control drivers that are affected
by the devm_kmemdup_array() conversion, merge the ib-devres-iio-input-pinctrl
for making development going smoothly.
* Split devres APIs to a separate header (linux/device/devres.h)
* Move IOMEM_ERR_PTR() to err.h to avoid unneeded loops
* Introduce devm_kmemdup_array()
* Use devm_kmemdup_array() in input, IIO, and pinctrl subsystems
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Andy Shevchenko [Mon, 24 Feb 2025 10:08:12 +0000 (12:08 +0200)]
Merge patch series "Split devres APIs to device/devres.h and introduce devm_kmemdup_array()"
Raag Jadav <raag.jadav@intel.com> says:
This series
1. Splits device/devres.h for the users that are only interested in devres APIs.
Original work by Andy Shevchenko:
https://lore.kernel.org/r/20241203195340.855879-1-andriy.shevchenko@linux.intel.com
2. Introduces a more robust and cleaner devm_kmemdup_array() helper and uses it
across drivers.
The idea behind embedding both work into a single series is to make the review
process easier and reduce conflicts while merging.
Raag Jadav [Wed, 12 Feb 2025 06:25:02 +0000 (11:55 +0530)]
err.h: move IOMEM_ERR_PTR() to err.h
Since IOMEM_ERR_PTR() macro deals with an error pointer, a better place
for it is err.h. This helps avoid dependency on io.h for the users that
don't need it.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Suppress binding attributes for the rzg2l pinctrl driver, as it is an
essential block for Renesas SoCs. Unbinding the driver leads to
warnings from __device_links_no_driver() and can eventually render the
system inaccessible.
Andy Shevchenko [Wed, 5 Feb 2025 09:51:16 +0000 (11:51 +0200)]
pinctrl: cy8c95x0: Initialise boolean variable with boolean values
The 'ret' variable in cy8c95x0_irq_handler() is defined as bool,
but is intialised with integers. Avoid implicit castings and
initialise boolean variable with boolean values.
Andy Shevchenko [Wed, 5 Feb 2025 09:51:14 +0000 (11:51 +0200)]
pinctrl: cy8c95x0: Remove redundant check in cy8c95x0_regmap_update_bits_base()
The function is never called with the PORTSEL register in the argument.
Drop unneeded check, but rescue a comment. While at it, drop inline
and allow any compiler to choose better stragy (note, that inline in
C code is only a recomendation to most of the modern compilers anyway).
Andy Shevchenko [Wed, 5 Feb 2025 09:51:13 +0000 (11:51 +0200)]
pinctrl: cy8c95x0: Transform to cy8c95x0_regmap_read_bits()
The returned value of cy8c95x0_regmap_read() is used always with
a bitmask being applied. Move that bitmasking code into the function.
At the same time transform it to cy8c95x0_regmap_read_bits() which
will be in align with the write and update counterparts.
projects / thirdparty / kernel / linux.git / log
