Merge branch 'next' into for-linus

Prepare input updates for 6.17 merge window.

Merge tag 'ib-mfd-gpio-input-pwm-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into next

Merge an immutable branch between MFD, GPIO, Input and PWM to resolve
conflicts for the mer

Merge tag 'ib-mfd-gpio-input-pwm-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into next

Merge an immutable branch between MFD, GPIO, Input and PWM to resolve
conflicts for the merge window pull request.

show more ...

Merge tag 'mtd/for-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux

Pull mtd updates from Miquel Raynal:
"MTD changes:

- Apart from a binding conversion to yaml, only minor chan

Merge tag 'mtd/for-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux

Pull mtd updates from Miquel Raynal:
"MTD changes:

- Apart from a binding conversion to yaml, only minor changes/small
fixes have been merged.

Raw NAND changes:

- Minor fixes for various controller drivers like DMA mapping checks,
better timing derivations or bitflip statistics.

- some Hynix NAND flashes were not supporting read-retries, so don't
even try to do it

SPI NAND changes:

- In order to support high-speed modes, certain chips need extra
configuration like adding more dummy cycles. This is now possible,
especially on Winbond chips.

- Aside from that, Gigadevice gets support for a new chip (GD5F1GM9).

SPI NOR changes:

- A notable changes is the fix for exiting 4-byte addressing on
Infineon SEMPER flashes. These flashes do not support the standard
EX4B opcode (E9h), and use a vendor-specific opcode (B8h) instead.

- There is also a fix for unlocking flashes that are write-protected
at power-on. This was caused by using an uninitialized mtd_info in
spi_nor_try_unlock_all()"

* tag 'mtd/for-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (26 commits)
mtd: spinand: winbond: Add comment about the maximum frequency
mtd: spinand: winbond: Enable high-speed modes on w35n0xjw
mtd: spinand: winbond: Enable high-speed modes on w25n0xjw
mtd: spinand: Add a ->configure_chip() hook
mtd: spinand: Add a frequency field to all READ_FROM_CACHE variants
mtd: spinand: Fix macro alignment
spi: spi-mem: Take into account the actual maximum frequency
spi: spi-mem: Use picoseconds for calculating the op durations
mtd: rawnand: atmel: set pmecc data setup time
mtd: spinand: propagate spinand_wait() errors from spinand_write_page()
mtd: rawnand: fsmc: Add missing check after DMA map
mtd: rawnand: rockchip: Add missing check after DMA map
mtd: rawnand: hynix: don't try read-retry on SLC NANDs
mtd: rawnand: atmel: Fix dma_mapping_error() address
mtd: nand: brcmnand: fix mtd corrected bits stat
mtd: rawnand: renesas: Add missing check after DMA map
mtd: spinand: gigadevice: Add support for GD5F1GM9 chips
mtd: nand: brcmnand: replace manual string choices with standard helpers
mtd: map: Don't use "proxy" headers
mtd: spi-nor: Fix spi_nor_try_unlock_all()
...

show more ...

Merge tag 'nand/for-6.17' into mtd/next

* Raw NAND changes:

Various controller drivers received minor fixes like DMA mapping checks,
better timing derivations or bitflip statistics.
It has also bee

Merge tag 'nand/for-6.17' into mtd/next

* Raw NAND changes:

Various controller drivers received minor fixes like DMA mapping checks,
better timing derivations or bitflip statistics.
It has also been discovered that some Hynix NAND flashes were not
supporting read-retries, which is not properly supported.

* SPI NAND changes:

In order to support high-speed modes, certain chips need extra
configuration like adding more dummy cycles. This is now possible,
especially on Winbond chips.

Aside from that, Gigadevice gets support for a new chip (GD5F1GM9).

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

show more ...

mtd: spinand: Add a frequency field to all READ_FROM_CACHE variants

These macros had initially no frequency field. When I added the "maximum
operation frequency" field, I did it initially on very co

mtd: spinand: Add a frequency field to all READ_FROM_CACHE variants

These macros had initially no frequency field. When I added the "maximum
operation frequency" field, I did it initially on very common macros and
I decided to add an optional field for that (with VA_ARGS) in order to
prevent massively unreadable changes. I then added new variants in the
spinand.h header, and requested a frequency field for them by
default. Some times later, I also added maximum frequencies to other
existing variants, but I did it incorrectly, without noticing I was
wrong because the field was optional.

This mix is error prone, so let's do what I should have done since the
very beginning: add a frequency field to all READ_FROM_CACHE variants.

There is no functional change.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

show more ...

Merge remote-tracking branch 'drm/drm-next' into msm-next

Back-merge drm-next to (indirectly) get arm-smmu updates for making
stall-on-fault more reliable.

Signed-off-by: Rob Clark <robin.clark@oss

Merge remote-tracking branch 'drm/drm-next' into msm-next

Back-merge drm-next to (indirectly) get arm-smmu updates for making
stall-on-fault more reliable.

Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>

show more ...

Merge drm/drm-next into drm-misc-next

Backmerging to forward to v6.16-rc1

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Merge drm/drm-next into drm-xe-next

Backmerging to bring in 6.16

Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>

Merge drm/drm-next into drm-intel-next

Sync to v6.16-rc1, among other things to get the fixed size GENMASK_U*()
and BIT_U*() macros.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Merge tag 'mtd/for-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux

Pull MTD updates from Miquel Raynal:
"A big core MTD change is the introduction of a new class to always
regist

Merge tag 'mtd/for-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux

Pull MTD updates from Miquel Raynal:
"A big core MTD change is the introduction of a new class to always
register a master device. This is a problem that has been there
forever: the "master" device was not always present depending on a
number of heuristics such as the presence of fixed partitions and the
absence of a Kconfig symbol to force its presence. This was a problem
for runtime PM operations which might not have the "master" device
available in all situation.

The SPI NAND subsystem has seen the introduction of DTR operations
(the equivalent of DDR transfers), which involved quite a few
preparation patches for clarifying macro names.

In the raw NAND subsystem, the brcmnand driver has been "fixed" for
old legacy SoCs with an update of the ->exec_op() hook, there has been
the introduction of a new controller driver named Loongson-1, and the
Qualcomm driver has received quite a few misc fixes as well as a new
compatible.

Finally, Macornix SPI NOR entries have been cleaned-up and some SFDP
table fixups for Macronix MX25L3255E have been merged.

Aside from this, there is the usual load of misc improvement, fixes,
and yaml conversion"

* tag 'mtd/for-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (42 commits)
mtd: rawnand: brcmnand: legacy exec_op implementation
mtd: rawnand: sunxi: Add randomizer configuration in sunxi_nfc_hw_ecc_write_chunk
mtd: nand: brcmnand: fix NAND timeout when accessing eMMC
mtd: nand: sunxi: Add randomizer configuration before randomizer enable
mtd: spinand: esmt: fix id code for F50D1G41LB
mtd: rawnand: brcmnand: remove unused parameters
mtd: core: always create master device
mtd: rawnand: loongson1: Fix inconsistent refcounting in ls1x_nand_chip_init()
mtd: rawnand: loongson1: Fix error code in ls1x_nand_dma_transfer()
mtd: rawnand: qcom: Fix read len for onfi param page
mtd: rawnand: qcom: Fix last codeword read in qcom_param_page_type_exec()
mtd: rawnand: qcom: Pass 18 bit offset from NANDc base to BAM base
dt-bindings: mtd: qcom,nandc: Document the SDX75 NAND controller
mtd: bcm47xxnflash: Add error handling for bcm47xxnflash_ops_bcm4706_ctl_cmd()
mtd: rawnand: Use non-hybrid PCI devres API
mtd: nand: ecc-mxic: Fix use of uninitialized variable ret
mtd: spinand: winbond: Add support for W35N02JW and W35N04JW chips
mtd: spinand: winbond: Add octal support
mtd: spinand: winbond: Add support for W35N01JW in single mode
mtd: spinand: winbond: Rename DTR variants
...

show more ...

Merge tag 'nand/for-6.16' into mtd/next

The SPI NAND subsystem has seen the introduction of DTR operations (the
equivalent of DDR transfers), which involved quite a few preparation
patches for clari

Merge tag 'nand/for-6.16' into mtd/next

The SPI NAND subsystem has seen the introduction of DTR operations (the
equivalent of DDR transfers), which involved quite a few preparation
patches for clarifying macro names.

In the raw NAND subsystem, the brcmnand driver has been "fixed" for old
legacy SoCs with an update of the ->exec_op() hook, there has been the
introduction of a new controller driver named Loongson-1, and the
Qualcomm driver has received quite a few misc fixes as well as a new
compatible.

Aside from this, there is the usual load of misc improvement and fixes.

show more ...

mtd: spinand: Use more specific naming for the (quad) program load op

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supp

mtd: spinand: Use more specific naming for the (quad) program load op

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really means by describing the expected bus
topology in the (quad) program load macro name.

While at modifying it, better add the missing_ OP suffix to align with
all the other macros of the same kind.

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

show more ...

mtd: spinand: Use more specific naming for the (single) program load op

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for su

mtd: spinand: Use more specific naming for the (single) program load op

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really means by describing the expected bus
topology in the (single) program load macro name.

While at modifying it, better add the missing_ OP suffix to align with
all the other macros of the same kind.

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

show more ...

mtd: spinand: Use more specific naming for the (quad IO) read from cache ops

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros f

mtd: spinand: Use more specific naming for the (quad IO) read from cache ops

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really mean by describing the expected bus
topology in the (quad IO) read from cache macro names.

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

show more ...

mtd: spinand: Use more specific naming for the (quad output) read from cache ops

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macr

mtd: spinand: Use more specific naming for the (quad output) read from cache ops

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really mean by describing the expected bus
topology in the (quad output) read from cache macro names.

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

show more ...

mtd: spinand: Use more specific naming for the (dual IO) read from cache ops

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros f

mtd: spinand: Use more specific naming for the (dual IO) read from cache ops

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really mean by describing the expected bus
topology in the (dual IO) read from cache macro names. While at
modifying them, better reordering the macros to group them all by bus
topology which now feels more intuitive.

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

show more ...

mtd: spinand: Use more specific naming for the (dual output) read from cache ops

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macr

mtd: spinand: Use more specific naming for the (dual output) read from cache ops

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really mean by describing the expected bus
topology in the (dual output) read from cache macro names.

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

show more ...

mtd: spinand: Use more specific naming for the (single) read from cache ops

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros fo

mtd: spinand: Use more specific naming for the (single) read from cache ops

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really mean by describing the expected bus
topology in the (single) read from cache macro names.

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

show more ...

Merge drm/drm-fixes into drm-misc-fixes

Backmerging to get updates from v6.15-rc1.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Merge branch 'next' into for-linus

Prepare input updates for 6.15 merge window.

Merge tag 'v6.14-rc4' into next

Sync up with the mainline.

Merge tag 'v6.14-rc1' into perf-tools-next

To get the various fixes in the current master.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Merge drm/drm-next into drm-xe-next

Sync to fix conlicts between drm-xe-next and drm-intel-next.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>

Merge drm/drm-next into drm-misc-next

Bring rc1 to start the new release dev.

Signed-off-by: Maxime Ripard <mripard@kernel.org>

Merge drm/drm-next into drm-intel-next

Sync with v6.14-rc1.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>