Merge 6.15-rc6 into driver-core-next

disallowed-macros = [

    # The `clippy::dbg_macro` lint only works with `std::dbg!`, thus we simulate

    # it here, see: https://github.com/rust-lang/rust-clippy/issues/11303.

    { path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool" },

    { path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool", allow-invalid = true },

]

Luca Weiss <luca@lucaweiss.eu> <luca@z3ntu.xyz>

Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>

Luo Jie <quic_luoj@quicinc.com> <luoj@codeaurora.org>

Lance Yang <lance.yang@linux.dev> <ioworker0@gmail.com>

Lance Yang <lance.yang@linux.dev> <mingzhe.yang@ly.com>

Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>

Maciej W. Rozycki <macro@orcam.me.uk> <macro@linux-mips.org>

Maharaja Kennadyrajan <quic_mkenna@quicinc.com> <mkenna@codeaurora.org>

Matthieu Baerts <matttbe@kernel.org> <matthieu.baerts@tessares.net>

Matthieu CASTET <castet.matthieu@free.fr>

Matti Vaittinen <mazziesaccount@gmail.com> <matti.vaittinen@fi.rohmeurope.com>

Mattijs Korpershoek <mkorpershoek@kernel.org> <mkorpershoek@baylibre.com>

Matt Ranostay <matt@ranostay.sg> <matt.ranostay@konsulko.com>

Matt Ranostay <matt@ranostay.sg> <matt@ranostay.consulting>

Matt Ranostay <matt@ranostay.sg> Matthew Ranostay <mranostay@embeddedalley.com>

Tycho Andersen <tycho@tycho.pizza> <tycho@tycho.ws>

Tzung-Bi Shih <tzungbi@kernel.org> <tzungbi@google.com>

Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>

Uwe Kleine-König <u.kleine-koenig@baylibre.com> <ukleinek@baylibre.com>

Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

Uwe Kleine-König <ukleinek@strlen.de>

Uwe Kleine-König <ukl@pengutronix.de>

What:		/sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/temp2_input

Date:		March 2025

KernelVersion:	6.14

KernelVersion:	6.15

Contact:	intel-xe@lists.freedesktop.org

Description:	RO. Package temperature in millidegree Celsius.

What:		/sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/temp3_input

Date:		March 2025

KernelVersion:	6.14

KernelVersion:	6.15

Contact:	intel-xe@lists.freedesktop.org

Description:	RO. VRAM temperature in millidegree Celsius.

title: Mediatek's Keypad Controller

maintainers:

  - Mattijs Korpershoek <mkorpershoek@baylibre.com>

  - Mattijs Korpershoek <mkorpershoek@kernel.org>

allOf:

  - $ref: /schemas/input/matrix-keymap.yaml#

      - rev-rmii

      - moca

      # RX and TX delays are added by the MAC when required

      # RX and TX delays are provided by the PCB. See below

      - rgmii

      # RGMII with internal RX and TX delays provided by the PHY,

      # the MAC should not add the RX or TX delays in this case

      # RX and TX delays are not provided by the PCB. This is the most

      # frequent case. See below

      - rgmii-id

      # RGMII with internal RX delay provided by the PHY, the MAC

      # should not add an RX delay in this case

      # TX delay is provided by the PCB. See below

      - rgmii-rxid

      # RGMII with internal TX delay provided by the PHY, the MAC

      # should not add an TX delay in this case

      # RX delay is provided by the PCB. See below

      - rgmii-txid

      - rtbi

      - smii

additionalProperties: true

# Informative

# ===========

#

# 'phy-modes' & 'phy-connection-type' properties 'rgmii', 'rgmii-id',

# 'rgmii-rxid', and 'rgmii-txid' are frequently used wrongly by

# developers. This informative section clarifies their usage.

#

# The RGMII specification requires a 2ns delay between the data and

# clock signals on the RGMII bus. How this delay is implemented is not

# specified.

#

# One option is to make the clock traces on the PCB longer than the

# data traces. A sufficiently difference in length can provide the 2ns

# delay. If both the RX and TX delays are implemented in this manner,

# 'rgmii' should be used, so indicating the PCB adds the delays.

#

# If the PCB does not add these delays via extra long traces,

# 'rgmii-id' should be used. Here, 'id' refers to 'internal delay',

# where either the MAC or PHY adds the delay.

#

# If only one of the two delays are implemented via extra long clock

# lines, either 'rgmii-rxid' or 'rgmii-txid' should be used,

# indicating the MAC or PHY should implement one of the delays

# internally, while the PCB implements the other delay.

#

# Device Tree describes hardware, and in this case, it describes the

# PCB between the MAC and the PHY, if the PCB implements delays or

# not.

#

# In practice, very few PCBs make use of extra long clock lines. Hence

# any RGMII phy mode other than 'rgmii-id' is probably wrong, and is

# unlikely to be accepted during review without details provided in

# the commit description and comments in the .dts file.

#

# When the PCB does not implement the delays, the MAC or PHY must.  As

# such, this is software configuration, and so not described in Device

# Tree.

#

# The following describes how Linux implements the configuration of

# the MAC and PHY to add these delays when the PCB does not. As stated

# above, developers often get this wrong, and the aim of this section

# is reduce the frequency of these errors by Linux developers. Other

# users of the Device Tree may implement it differently, and still be

# consistent with both the normative and informative description

# above.

#

# By default in Linux, when using phylib/phylink, the MAC is expected

# to read the 'phy-mode' from Device Tree, not implement any delays,

# and pass the value to the PHY. The PHY will then implement delays as

# specified by the 'phy-mode'. The PHY should always be reconfigured

# to implement the needed delays, replacing any setting performed by

# strapping or the bootloader, etc.

#

# Experience to date is that all PHYs which implement RGMII also

# implement the ability to add or not add the needed delays. Hence

# this default is expected to work in all cases. Ignoring this default

# is likely to be questioned by Reviews, and require a strong argument

# to be accepted.

#

# There are a small number of cases where the MAC has hard coded

# delays which cannot be disabled. The 'phy-mode' only describes the

# PCB.  The inability to disable the delays in the MAC does not change

# the meaning of 'phy-mode'. It does however mean that a 'phy-mode' of

# 'rgmii' is now invalid, it cannot be supported, since both the PCB

# and the MAC and PHY adding delays cannot result in a functional

# link. Thus the MAC should report a fatal error for any modes which

# cannot be supported. When the MAC implements the delay, it must

# ensure that the PHY does not also implement the same delay. So it

# must modify the phy-mode it passes to the PHY, removing the delay it

# has added. Failure to remove the delay will result in a

# non-functioning link.

#

# Sometimes there is a need to fine tune the delays. Often the MAC or

# PHY can perform this fine tuning. In the MAC node, the Device Tree

# properties 'rx-internal-delay-ps' and 'tx-internal-delay-ps' should

# be used to indicate fine tuning performed by the MAC. The values

# expected here are small. A value of 2000ps, i.e 2ns, and a phy-mode

# of 'rgmii' will not be accepted by Reviewers.

#

# If the PHY is to perform fine tuning, the properties

# 'rx-internal-delay-ps' and 'tx-internal-delay-ps' in the PHY node

# should be used. When the PHY is implementing delays, e.g. 'rgmii-id'

# these properties should have a value near to 2000ps. If the PCB is

# implementing delays, e.g. 'rgmii', a small value can be used to fine

# tune the delay added by the PCB.

...