Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1
# 7ae9fb1b 21-Feb-2023 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge branch 'next' into for-linus

Prepare input updates for 6.3 merge window.


Revision tags: v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5
# 6f849817 19-Jan-2023 Thomas Zimmermann <tzimmermann@suse.de>

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

Backmerging into drm-misc-next to get DRM accelerator infrastructure,
which is required by ipuv driver.

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


Revision tags: v6.2-rc4
# 407da561 10-Jan-2023 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge tag 'v6.2-rc3' into next

Merge with mainline to bring in timer_shutdown_sync() API.


Revision tags: v6.2-rc3
# 0d8eae7b 02-Jan-2023 Jani Nikula <jani.nikula@intel.com>

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

Sync up with v6.2-rc1.

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


Revision tags: v6.2-rc2
# b501d4dc 30-Dec-2022 Rodrigo Vivi <rodrigo.vivi@intel.com>

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

Sync after v6.2-rc1 landed in drm-next.

We need to get some dependencies in place before we can merge
the fixes series from Gwan-gyeong and Chris.

Referen

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

Sync after v6.2-rc1 landed in drm-next.

We need to get some dependencies in place before we can merge
the fixes series from Gwan-gyeong and Chris.

References: https://lore.kernel.org/all/Y6x5JCDnh2rvh4lA@intel.com/
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

show more ...


# 6599e683 28-Dec-2022 Mauro Carvalho Chehab <mchehab@kernel.org>

Merge tag 'v6.2-rc1' into media_tree

Linux 6.2-rc1

* tag 'v6.2-rc1': (14398 commits)
Linux 6.2-rc1
treewide: Convert del_timer*() to timer_shutdown*()
pstore: Properly assign mem_type propert

Merge tag 'v6.2-rc1' into media_tree

Linux 6.2-rc1

* tag 'v6.2-rc1': (14398 commits)
Linux 6.2-rc1
treewide: Convert del_timer*() to timer_shutdown*()
pstore: Properly assign mem_type property
pstore: Make sure CONFIG_PSTORE_PMSG selects CONFIG_RT_MUTEXES
cfi: Fix CFI failure with KASAN
perf python: Fix splitting CC into compiler and options
afs: Stop implementing ->writepage()
afs: remove afs_cache_netfs and afs_zap_permits() declarations
afs: remove variable nr_servers
afs: Fix lost servers_outstanding count
ALSA: usb-audio: Add new quirk FIXED_RATE for JBL Quantum810 Wireless
ALSA: azt3328: Remove the unused function snd_azf3328_codec_outl()
gcov: add support for checksum field
test_maple_tree: add test for mas_spanning_rebalance() on insufficient data
maple_tree: fix mas_spanning_rebalance() on insufficient data
hugetlb: really allocate vma lock for all sharable vmas
kmsan: export kmsan_handle_urb
kmsan: include linux/vmalloc.h
mm/mempolicy: fix memory leak in set_mempolicy_home_node system call
mm, mremap: fix mremap() expanding vma with addr inside vma
...

show more ...


# d0e99511 17-Jan-2023 Kalle Valo <kvalo@kernel.org>

Merge wireless into wireless-next

Due to the two cherry picked commits from wireless to wireless-next we have
several conflicts in mt76. To avoid any bugs with conflicts merge wireless into
wireless

Merge wireless into wireless-next

Due to the two cherry picked commits from wireless to wireless-next we have
several conflicts in mt76. To avoid any bugs with conflicts merge wireless into
wireless-next.

96f134dc1964 wifi: mt76: handle possible mt76_rx_token_consume failures
fe13dad8992b wifi: mt76: dma: do not increment queue head if mt76_dma_add_buf fails

show more ...


# 2c55d703 03-Jan-2023 Maxime Ripard <maxime@cerno.tech>

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

Let's start the fixes cycle.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>


Revision tags: v6.2-rc1
# 1a931707 16-Dec-2022 Arnaldo Carvalho de Melo <acme@redhat.com>

Merge remote-tracking branch 'torvalds/master' into perf/core

To resolve a trivial merge conflict with c302378bc157f6a7 ("libbpf:
Hashmap interface update to allow both long and void* keys/values"),

Merge remote-tracking branch 'torvalds/master' into perf/core

To resolve a trivial merge conflict with c302378bc157f6a7 ("libbpf:
Hashmap interface update to allow both long and void* keys/values"),
where a function present upstream was removed in the perf tools
development tree.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

show more ...


# 8e17b16a 12-Dec-2022 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'soc-drivers-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

Pull ARM SoC driver updates from Arnd Bergmann:
"There are few major updates in the SoC specific drivers, mainly

Merge tag 'soc-drivers-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

Pull ARM SoC driver updates from Arnd Bergmann:
"There are few major updates in the SoC specific drivers, mainly the
usual reworks and support for variants of the existing SoC. While this
remains Arm centric for the most part, the branch now also contains
updates to risc-v and loongarch specific code in drivers/soc/.

Notable changes include:

- Support for the newly added Qualcomm Snapdragon variants (MSM8956,
MSM8976, SM6115, SM4250, SM8150, SA8155 and SM8550) in the soc ID,
rpmh, rpm, spm and powerdomain drivers.

- Documentation for the somewhat controversial qcom,board-id
properties that are required for booting a number of machines

- A new SoC identification driver for the loongson-2 (loongarch)
platform

- memory controller updates for stm32, tegra, and renesas.

- a new DT binding to better describe LPDDR2/3/4/5 chips in the
memory controller subsystem

- Updates for Tegra specific drivers across multiple subsystems,
improving support for newer SoCs and better identification

- Minor fixes for Broadcom, Freescale, Apple, Renesas, Sifive, TI,
Mediatek and Marvell SoC drivers"

* tag 'soc-drivers-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (137 commits)
soc: qcom: socinfo: Add SM6115 / SM4250 SoC IDs to the soc_id table
dt-bindings: arm: qcom,ids: Add SoC IDs for SM6115 / SM4250 and variants
soc: qcom: socinfo: Add SM8150 and SA8155 SoC IDs to the soc_id table
dt-bindings: arm: qcom,ids: Add SoC IDs for SM8150 and SA8155
dt-bindings: soc: qcom: apr: document generic qcom,apr compatible
soc: qcom: Select REMAP_MMIO for ICC_BWMON driver
soc: qcom: Select REMAP_MMIO for LLCC driver
soc: qcom: rpmpd: Add SM4250 support
dt-bindings: power: rpmpd: Add SM4250 support
dt-bindings: soc: qcom: aoss: Add compatible for SM8550
soc: qcom: llcc: Add configuration data for SM8550
dt-bindings: arm: msm: Add LLCC compatible for SM8550
soc: qcom: llcc: Add v4.1 HW version support
soc: qcom: socinfo: Add SM8550 ID
soc: qcom: rpmh-rsc: Avoid unnecessary checks on irq-done response
soc: qcom: rpmh-rsc: Add support for RSC v3 register offsets
soc: qcom: rpmhpd: Add SM8550 power domains
dt-bindings: power: rpmpd: Add SM8550 to rpmpd binding
soc: qcom: socinfo: Add MSM8956/76 SoC IDs to the soc_id table
dt-bindings: arm: qcom,ids: Add SoC IDs for MSM8956 and MSM8976
...

show more ...


Revision tags: v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4
# 9e549c76 02-Nov-2022 Arnd Bergmann <arnd@arndb.de>

Merge tag 'memory-controller-drv-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers

Memory controller drivers for v6.2

1. STM32 FMC2:
a. Correct in bind

Merge tag 'memory-controller-drv-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers

Memory controller drivers for v6.2

1. STM32 FMC2:
a. Correct in bindings the name of property for address
setup duration. The DTS and driver were already using proper name,
so it is only alignment of bindings with real usage.
b. Split off STM32 memory controller bus peripheral properties into
generic ones (re-usable by multiple memory controllers) and STM32 bus
peripheral. This way, the FMC2 controller properties in Micrel
KSZ8851MLL ethernet controller node can be properly validated.

2. Tegra MC: simplify with DEFINE_SHOW_ATTRIBUTE.

3. Renesas RPC IF: add suppor tfor R-Car Gen4.

4. LPDDR bindings: refactor and extend with description of DDR channels.
Add also bindings for LPDDR4 and LPDDR5.

The rationale for (4) above - LPDDR bindings changes, wrote by Julius Werner:

"We (Chromium OS) have been trying to find a way to pass LPDDR memory
chip information that is available to the firmware through the FDT
(mostly for userspace informational purposes, for now). We have been
using and expanding the existing "jedec,lpddr2" and "jedec,lpddr3"
bindings for this (e.g. [1]). The goal is to be able to identify the
memory layout of the system (how the parts look like, how they're tied
together, how much capacity there is in total) as accurately as
possible from software-probed values.

...

The problem with this is that each individual LPDDR chip has its own
set of mode registers (per rank) that only describe the density of
that particular chip (rank). The host memory controller may have
multiple channels (each of which is basically an entirely separate set
of physical LPDDR pins on the board), a single channel may be
connected to multiple LPDDR chips (e.g. if the memory controller has
an outgoing 32-bit channel, that channel could be tied to two 16-bit
LPDDR chips by tying the low 16 bits to one and the high 16 bits to
the other), and then each of those chips may offer multiple
independent ranks (which rank is being accessed at a given time is
controlled by a separate chip select pin).

So if we just have one "io-width" and one "density" field in the FDT,
there's no way to figure out how much memory there's actually
connected in total, because that only describes a single LPDDR chip.
Worse, there may be chips where different ranks have different
densities (e.g. a 6GB dual-rank chip with one 4GB and one 2GB rank),
and different channels could theoretically be connected to chips of
completely different manufacturers."

Link: https://lore.kernel.org/r/CAODwPW9E8wWwxbYKyf4_-JFb4F-JSmLR3qOF_iudjX0f9ndF0A@mail.gmail.com

* tag 'memory-controller-drv-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
dt-bindings: memory-controller: st,stm32: Split off MC properties
dt-bindings: memory: Add jedec,lpddrX-channel binding
dt-bindings: memory: Add jedec,lpddr4 and jedec,lpddr5 bindings
dt-bindings: memory: Add numeric LPDDR compatible string variant
dt-bindings: memory: Factor out common properties of LPDDR bindings
memory: renesas-rpc-if: Add support for R-Car Gen4
memory: renesas-rpc-if: Clear HS bit during hardware initialization
dt-bindings: memory: renesas,rpc-if: Document R-Car V4H support
memory: tegra186-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code
memory: tegra210-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code
memory: tegra30-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code
memory: tegra20-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code
dt-bindings: memory-controller: st,stm32: Fix st,fmc2_ebi-cs-write-address-setup-ns

Link: https://lore.kernel.org/r/20221026171354.51877-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

show more ...


Revision tags: v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0
# 4985a545 01-Oct-2022 Julius Werner <jwerner@chromium.org>

dt-bindings: memory: Add jedec,lpddrX-channel binding

This patch adds a new device tree binding for an LPDDR channel to serve
as a top-level organizing node for LPDDR part nodes nested below it. An

dt-bindings: memory: Add jedec,lpddrX-channel binding

This patch adds a new device tree binding for an LPDDR channel to serve
as a top-level organizing node for LPDDR part nodes nested below it. An
LPDDR channel needs to have an "io-width" property to describe its width
(this is important because this width does not always match the io-width
of the part number, indicating that multiple parts are wired in parallel
on the same channel), as well as one or more nested "rank@X" nodes.
Those represent information about the individual ranks of each LPDDR
part connected on that channel and should match the existing
"jedec,lpddrX" bindings for individual LPDDR parts.

New platforms should be using this node -- the existing practice of
providing a raw, toplevel "jedec,lpddrX" node without indication of how
many identical parts are in the system should be considered deprecated.

Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220930220606.303395-4-jwerner@chromium.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

show more ...


# a500528f 01-Oct-2022 Julius Werner <jwerner@chromium.org>

dt-bindings: memory: Add jedec,lpddr4 and jedec,lpddr5 bindings

This patch adds bindings for LPDDR4 and LPDDR5 memory analogous to the
existing bindings for LPDDR2 and LPDDR3. For now, the new types

dt-bindings: memory: Add jedec,lpddr4 and jedec,lpddr5 bindings

This patch adds bindings for LPDDR4 and LPDDR5 memory analogous to the
existing bindings for LPDDR2 and LPDDR3. For now, the new types are only
needed for topology description, so other properties like timing
parameters are omitted. They can be added later if needed.

Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220930220606.303395-3-jwerner@chromium.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

show more ...


# 686fe63b 01-Oct-2022 Julius Werner <jwerner@chromium.org>

dt-bindings: memory: Add numeric LPDDR compatible string variant

This patch allows a new kind of compatible string for LPDDR parts in the
device tree bindings, in addition to the existing hardcoded

dt-bindings: memory: Add numeric LPDDR compatible string variant

This patch allows a new kind of compatible string for LPDDR parts in the
device tree bindings, in addition to the existing hardcoded
<vendor>,<part-number> strings. The new format contains manufacturer and
part (revision) information in numerical form, such as lpddr3-ff,0201
for an LPDDR3 part with manufacturer ID ff and revision ID 0201. This
helps cases where LPDDR parts are probed at runtime by boot firmware and
cannot be matched to hardcoded part numbers, such as the firmware on the
qcom/sc7280-herobrine boards does (which supports 4 different memory
configurations at the moment, and more are expected to be added later at
a point where the boot firmware can no longer be updated to specifically
accommodate them).

Signed-off-by: Julius Werner <jwerner@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220930220606.303395-2-jwerner@chromium.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

show more ...


# b7178cd5 01-Oct-2022 Julius Werner <jwerner@chromium.org>

dt-bindings: memory: Factor out common properties of LPDDR bindings

The bindings for different LPDDR versions mostly use the same kinds of
properties, so in order to reduce duplication when we're ad

dt-bindings: memory: Factor out common properties of LPDDR bindings

The bindings for different LPDDR versions mostly use the same kinds of
properties, so in order to reduce duplication when we're adding support
for more versions, this patch creates a new lpddr-props subschema that
can be referenced by the others to define these common parts. (This will
consider a few smaller I/O width and density numbers "legal" for LPDDR3
that are usually not used there, but this should be harmless.)

Signed-off-by: Julius Werner <jwerner@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220930220606.303395-1-jwerner@chromium.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

show more ...