* Re: [PATCH 2/3] iio: adc: add Axiado SARADC driver
From: Andy Shevchenko @ 2026-06-05 18:26 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260528-axiado-ax3000-ax3005-saradc-v1-2-345dd5f6608a@axiado.com>
On Thu, May 28, 2026 at 01:10:24AM -0700, Petar Stepanovic wrote:
> Add support for the SARADC controller found on Axiado AX3000 and
> AX3005 SoCs.
>
> The driver supports single-shot voltage reads through the IIO
> subsystem. The number of available input channels is selected from
> the SoC match data, allowing AX3000 and AX3005 variants to use the
> same driver.
(I'll try to not duplicate what Joshua noticed already.)
...
> +config AXIADO_SARADC
> + tristate "Axiado SARADC driver"
> + depends on ARCH_AXIADO || COMPILE_TEST
> + depends on OF
No, in IIO we want a good justification on non-agnostic requirements.
Why can't this device driver be agnostic?
...
> +#include <linux/bitfield.h>
+ bits.h
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/iio/iio.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
No driver should have this header to be included.
Rare and well justified exceptions are possible
(and no, not in this case).
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/regulator/consumer.h>
...
> +struct axiado_saradc {
> + void __iomem *regs;
> + struct clk *clk;
> + unsigned long clk_rate;
> + int vref_uv;
_uV (yes, capital letter as per SI).
> + struct mutex lock; /* Serializes ADC conversions. */
> +};
...
> +static int axiado_saradc_conversion(struct axiado_saradc *info,
> + struct iio_chan_spec const *chan, int *val)
> +{
> + unsigned long usecs;
Missing blank line here.
> + /* Select the channel to be used and trigger conversion */
> + iowrite32(AX_SARADC_MANUAL_CTRL_EN(chan->channel),
> + info->regs + AX_SARADC_MANUAL_CTRL);
Why not writel()?
> +
> + /* Hardware requires 13 conversion cycles at clk_rate */
> + usecs = DIV_ROUND_UP(AX_SARADC_CONV_CYCLES * 1000000, info->clk_rate);
USe USEC_PER_SEC from time.h.
> + usleep_range(usecs, usecs + 10);
> +
> + *val = ioread32(info->regs + AX_SARADC_DOUT) &
> + GENMASK(AX_RESOLUTION_BITS - 1, 0);
> +
> + /* Stop manual conversion */
> + iowrite32(0, info->regs + AX_SARADC_MANUAL_CTRL);
> + return 0;
> +}
...
> +static int axiado_saradc_probe(struct platform_device *pdev)
> +{
> + struct axiado_saradc *info;
> + const struct axiado_saradc_soc_data *soc_data;
> + struct iio_dev *indio_dev;
> + int ret;
> + u32 reg;
> +
> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + info = iio_priv(indio_dev);
> +
> + info->regs = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(info->regs))
> + return PTR_ERR(info->regs);
> +
> + info->clk = devm_clk_get_enabled(&pdev->dev, NULL);
Why no name? It will make harder for the next generations of HW in case they
want more than one clock to be used.
> + if (IS_ERR(info->clk))
> + return PTR_ERR(info->clk);
> +
> + info->clk_rate = clk_get_rate(info->clk);
> + if (!info->clk_rate)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "invalid clock rate\n");
> + info->vref_uv = devm_regulator_get_enable_read_voltage(&pdev->dev,
> + "vref");
Having
struct device *dev = &pdev->dev;
will make the code shorter and easier to read.
> + if (info->vref_uv < 0)
> + return dev_err_probe(&pdev->dev, info->vref_uv,
> + "failed to get vref voltage\n");
> +
> + soc_data = device_get_match_data(&pdev->dev);
> + if (!soc_data)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "failed to get match data\n");
> +
> + mutex_init(&info->lock);
> + reg = FIELD_PREP(AX_SARADC_CH_EN_MASK,
> + GENMASK(soc_data->num_channels - 1, 0)) |
> + AX_SARADC_SAMPLE_16 | AX_SARADC_MODE | AX_SARADC_ENABLE;
FIELD_PREP_CONST() ?
> + iowrite32(AX_SARADC_PD, info->regs + AX_SARADC_GLOBAL_CTRL);
> + iowrite32(reg, info->regs + AX_SARADC_GLOBAL_CTRL);
> +
> + indio_dev->name = dev_name(&pdev->dev);
> + indio_dev->dev.parent = &pdev->dev;
> + indio_dev->info = &axiado_saradc_iio_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = axiado_saradc_iio_channels;
> + indio_dev->num_channels = soc_data->num_channels;
> +
> + ret = devm_iio_device_register(&pdev->dev, indio_dev);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "failed to register IIO device\n");
> +
> + return 0;
> +}
...
> +static const struct of_device_id axiado_saradc_match[] = {
> + {
> + .compatible = "axiado,ax3000-saradc",
> + .data = &ax3000_saradc_data,
> + },
> + {
> + .compatible = "axiado,ax3005-saradc",
> + .data = &ax3005_saradc_data,
> + },
> + {},
No comma for the terminator entry.
> +};
...
> +static struct platform_driver axiado_saradc_driver = {
> + .driver = {
> + .name = KBUILD_MODNAME,
We want to have these kind of strings to be fixed.
> + .of_match_table = axiado_saradc_match,
> + },
> + .probe = axiado_saradc_probe,
> +};
> +
Unnecessary blank line.
> +module_platform_driver(axiado_saradc_driver);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/3] Subject: [PATCH 0/3] iio: adc: Add Axiado SARADC driver
From: Andy Shevchenko @ 2026-06-05 18:16 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260528-axiado-ax3000-ax3005-saradc-v1-0-345dd5f6608a@axiado.com>
On Thu, May 28, 2026 at 01:10:22AM -0700, Petar Stepanovic wrote:
> This series adds support for the SAR ADC controller found on Axiado
> AX3000 and AX3005 SoCs.
>
> The controller is a 10-bit ADC. AX3000 has sixteen input channels and
> AX3005 has eight input channels. The driver uses SoC match data to
> select the number of available channels for each compatible.
>
> The driver supports single-shot voltage reads through the IIO subsystem
> and uses the reference voltage regulator for scale calculation.
When submit a new driver always answer these two questions:
- why do we even need a new brand driver? (No existing that can be extended?)
- where can we get a datasheet? (URL? Other means?)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Frank Li @ 2026-06-05 18:06 UTC (permalink / raw)
To: Stefan Wahren
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <a9304534-2d7d-4316-bcd1-36ff0931bcf0@gmx.net>
On Fri, Jun 05, 2026 at 07:11:30PM +0200, Stefan Wahren wrote:
> Hi Frank,
>
> Am 05.06.26 um 18:35 schrieb Frank Li:
> > On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
> > > Hi Frank,
> > >
> > > Am 27.05.26 um 17:14 schrieb Stefan Wahren:
> > > > Enable DP83822 PHY driver as a module to support the Ethernet PHY,
> > > > which is placed on phyCORE-i.MX93 SOM.
> > > >
> > > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > > > Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> > > could you please take care of this patch?
> > which is base commit, I can't apply clearly.
> I rebased against torvalds/v7.1-rc1
pick to imx/defconfig
Frank
> >
> > Frank
> >
> > > > ---
> > > >
> > > > Changes in V2:
> > > > - rebase patch
> > > > - add Krzysztof's Reviewed-by
> > > >
> > > > arch/arm64/configs/defconfig | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > > > index d905a0777f93..20bbbd310d2f 100644
> > > > --- a/arch/arm64/configs/defconfig
> > > > +++ b/arch/arm64/configs/defconfig
> > > > @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
> > > > CONFIG_QCA808X_PHY=m
> > > > CONFIG_REALTEK_PHY=y
> > > > CONFIG_ROCKCHIP_PHY=y
> > > > +CONFIG_DP83822_PHY=m
> > > > CONFIG_DP83867_PHY=y
> > > > CONFIG_DP83869_PHY=m
> > > > CONFIG_DP83TG720_PHY=m
> > >
>
>
^ permalink raw reply
* Re: [PATCH v02] mailbox: pcc: report errors for PCC clients
From: Adam Young @ 2026-06-05 17:19 UTC (permalink / raw)
To: Sudeep Holla, Adam Young
Cc: Jassi Brar, linux-kernel, linux-hwmon, Rafael J . Wysocki,
Len Brown, linux-acpi, Andi Shyti, Guenter Roeck, Huisong Li,
MyungJoo Ham, Kyungmin Park, Chanwoo Choi, linux-arm-kernel
In-Reply-To: <c61fa285-01a6-4ac3-82ec-2a6357a9e76f@amperemail.onmicrosoft.com>
On 6/3/26 11:15, Adam Young wrote:
>
> On 5/19/26 09:23, Sudeep Holla wrote:
>> On Mon, May 18, 2026 at 03:30:06PM -0400, Adam Young wrote:
>>> The tx_done callback function has a return code (rc) parameter
>>> that the tx_done callback can use to determine how to handle an error.
>>> However the IRQ handler was not setting that value if there is an
>>> error.
>>>
>>> The following clients are affected:
>>>
>>> drivers/acpi/cppc_acpi.c
>>> drivers/i2c/busses/i2c-xgene-slimpro.c
>>> drivers/hwmon/xgene-hwmon.c
>>> drivers/soc/hisilicon/kunpeng_hccs.c
>>> drivers/devfreq/hisi_uncore_freq.c
>>>
>>> All of these only use the error code to report, so they
>>> are expecting an error code to come thorugh, but they
>>> do not modify behavior based on this code.
>>>
>>> In the case of an error code in the IRQ, the handler was returning
>>> IRQ_NONE which is not correct: the IRQ handler was matched
>>> to the IRQ. This mean that multiple error codes returned from
>>> a PCC triggered interrupt would end up disabling the device.
>>>
>>> In addition, if the error code IRQ was coming from a Type4 Device
>>> that was
>>> expecting an IRQ response, that device would then be hung.
>>>
>>> Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended
>>> PCC subspaces(type 3/4)")
>>> Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
>>>
>>> ---
>>> ---
>>> drivers/mailbox/pcc.c | 9 +++++----
>>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>>> index 636879ae1db7..16b9ce087b9e 100644
>>> --- a/drivers/mailbox/pcc.c
>>> +++ b/drivers/mailbox/pcc.c
>>> @@ -314,6 +314,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> {
>>> struct pcc_chan_info *pchan;
>>> struct mbox_chan *chan = p;
>>> + int rc;
>>> pchan = chan->con_priv;
>>> @@ -327,8 +328,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> if (!pcc_mbox_cmd_complete_check(pchan))
>>> return IRQ_NONE;
>>> - if (pcc_mbox_error_check_and_clear(pchan))
>>> - return IRQ_NONE;
>>> + rc = pcc_mbox_error_check_and_clear(pchan);
>> I think we may have to skip the check inside
>> pcc_mbox_error_check_and_clear()
>> for Type 4 channel as the spec expects OSPM to ignore it. It is a
>> separate
>> fix, just noting that here.
>
> I think that should be in this patch, for correctness. It is a small
> enough change. I'll update.
>
Actually, it is a fix in its own right, and can be merged regardless of
this patch, so:
https://lore.kernel.org/lkml/20260604163306.160017-1-admiyo@os.amperecomputing.com/
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Stefan Wahren @ 2026-06-05 17:11 UTC (permalink / raw)
To: Frank Li
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <aiL638OLrfntKmSC@lizhi-Precision-Tower-5810>
Hi Frank,
Am 05.06.26 um 18:35 schrieb Frank Li:
> On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
>> Hi Frank,
>>
>> Am 27.05.26 um 17:14 schrieb Stefan Wahren:
>>> Enable DP83822 PHY driver as a module to support the Ethernet PHY,
>>> which is placed on phyCORE-i.MX93 SOM.
>>>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>> could you please take care of this patch?
> which is base commit, I can't apply clearly.
I rebased against torvalds/v7.1-rc1
>
> Frank
>
>>> ---
>>>
>>> Changes in V2:
>>> - rebase patch
>>> - add Krzysztof's Reviewed-by
>>>
>>> arch/arm64/configs/defconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>>> index d905a0777f93..20bbbd310d2f 100644
>>> --- a/arch/arm64/configs/defconfig
>>> +++ b/arch/arm64/configs/defconfig
>>> @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
>>> CONFIG_QCA808X_PHY=m
>>> CONFIG_REALTEK_PHY=y
>>> CONFIG_ROCKCHIP_PHY=y
>>> +CONFIG_DP83822_PHY=m
>>> CONFIG_DP83867_PHY=y
>>> CONFIG_DP83869_PHY=m
>>> CONFIG_DP83TG720_PHY=m
>>
^ permalink raw reply
* Re: [PATCH RFC v2] drm/rockchip: vop2: Add clock rate mode check
From: Alexey Charkov @ 2026-06-05 16:57 UTC (permalink / raw)
To: Alexey Charkov
Cc: Sebastian Reichel, Sandy Huang, Heiko Stübner, Andy Yan,
Daniel Stone, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, dri-devel, linux-arm-kernel,
linux-rockchip, linux-kernel, kernel
In-Reply-To: <CABjd4Yw_HYpjhrgmonB9FmWV00q=r3yvqnFE4TXEHpM1ZgWOhA@mail.gmail.com>
On Fri, Jun 5, 2026 at 7:58 PM Alexey Charkov <alchark@gmail.com> wrote:
>
> On Fri, Apr 10, 2026 at 2:37 AM Sebastian Reichel
> <sebastian.reichel@collabora.com> wrote:
> >
> > The display might offer modes, which exceed the maximum clock rate of a
> > video output. This usually happens for displays that offer refresh rates
> > above 60 Hz. This results in no picture (or a broken one) being displayed
> > without manual intervention. Fix this by teaching the driver about the
> > maximum achievable clock rates for each video port.
> >
> > The information about the maximum clock rates for each video channel and
> > the tip about multiple pixels being processed per clock were provided by
> > Andy Yan and roughly checked against the information available in the
> > datasheet (which specifies limits like "2560x1600@60Hz with 10-bit"
> > instead of a specific pixel rate).
> >
> > For the video ports supporting a 600 MHz input clock, there is some
> > logic to handle up to 4 pixels in parallel when needed resulting in
> > the extra multiplier.
> >
> > Suggested-by: Andy Yan <andy.yan@rock-chips.com>
> > Link: https://lore.kernel.org/linux-rockchip/1528d788.186b.19d08ed974c.Coremail.andyshrk@163.com/
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> > ---
> > I've kept the RFC tag, as I'm not sure about the 4x parallel pixel
> > processing. IIUIC all of the video ports with a maximum of 600 MHz
> > input clock support it, considering they can go to 4K @ 120Hz,
> > which is above 1.2GHz while Andy mentioned a max. support clock rate
> > of 600 MHz.
> > ---
> > Changes in v2:
> > - Link to v1: https://lore.kernel.org/r/20260217-vop2-clk-rate-check-v1-1-989b569119ba@collabora.com
> > - based on v7.0-rc7
> > - rename max_clock_rate into max_pixel_clock_rate to distinguish from
> > input clock
> > - update max clock rates to the numbers provided by Andy Yan with
> > extra 4x multiplier for 4K 120Hz VPs
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 3 +++
> > drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 1 +
> > drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 10 ++++++++++
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > index a195f5c819a2..35a0edda5375 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > @@ -1434,6 +1434,9 @@ static enum drm_mode_status vop2_crtc_mode_valid(struct drm_crtc *crtc,
> > if (mode->hdisplay > vp->data->max_output.width)
> > return MODE_BAD_HVALUE;
> >
> > + if (mode->clock > vp->data->max_pixel_clock_rate / 1000)
> > + return MODE_CLOCK_HIGH;
> > +
> > return MODE_OK;
> > }
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > index 9124191899ba..fd46913f3346 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > @@ -225,6 +225,7 @@ struct vop2_video_port_data {
> > u16 gamma_lut_len;
> > u16 cubic_lut_len;
> > struct vop_rect max_output;
> > + u32 max_pixel_clock_rate;
> > const u8 pre_scan_max_dly[4];
> > unsigned int offset;
> > /**
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> > index f3950e8476a7..6ae3d506c476 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> > @@ -559,18 +559,21 @@ static const struct vop2_video_port_data rk3568_vop_video_ports[] = {
> > .gamma_lut_len = 1024,
> > .cubic_lut_len = 9 * 9 * 9,
> > .max_output = { 4096, 2304 },
> > + .max_pixel_clock_rate = 600000000U,
> > .pre_scan_max_dly = { 69, 53, 53, 42 },
> > .offset = 0xc00,
> > }, {
> > .id = 1,
> > .gamma_lut_len = 1024,
> > .max_output = { 2048, 1536 },
> > + .max_pixel_clock_rate = 200000000U,
> > .pre_scan_max_dly = { 40, 40, 40, 40 },
> > .offset = 0xd00,
> > }, {
> > .id = 2,
> > .gamma_lut_len = 1024,
> > .max_output = { 1920, 1080 },
> > + .max_pixel_clock_rate = 150000000U,
> > .pre_scan_max_dly = { 40, 40, 40, 40 },
> > .offset = 0xe00,
> > },
> > @@ -775,6 +778,7 @@ static const struct vop2_video_port_data rk3576_vop_video_ports[] = {
> > .gamma_lut_len = 1024,
> > .cubic_lut_len = 9 * 9 * 9, /* 9x9x9 */
> > .max_output = { 4096, 2304 },
> > + .max_pixel_clock_rate = 600000000U * 4,
>
> Hi Sebastian,
>
> I've tested it on a bunch of different displays with RK3576 while also
> giving VP0 an unlimited PLL to work with (and also expanding its rates
> table for each of the displays' EDID preferred pixel clocks), and I'm
> pretty sure this should be * 2 here, rather than * 4. That would also
> align with ".pixel_rate = 2" just below.
>
> In its current form, some of the advanced displays with 240 Hz modes
> by default choose modes leading to visual artifacts indicative of
> overclocking strain of the graphics pipeline.
>
> The rest look plausible, so with that change please feel free to include:
>
> Tested-by: Alexey Charkov <alchark@flipper.net> # RK3576
Sorry, wrong mailbox.
Tested-by: Alexey Charkov <alchark@flipper.net> # RK3576
Best regards,
Alexey
^ permalink raw reply
* Re: [GIT PULL] KVM/arm64 fixes for 7.1, take #5
From: Paolo Bonzini @ 2026-06-05 16:57 UTC (permalink / raw)
To: Marc Zyngier
Cc: Hyunwoo Kim, Joey Gouly, Oliver Upton, Wei-Lin Chang,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, kvmarm,
linux-arm-kernel, kvm
In-Reply-To: <20260605164516.2214533-1-maz@kernel.org>
On Fri, Jun 5, 2026 at 6:45 PM Marc Zyngier <maz@kernel.org> wrote:
>
> Paolo,
>
> Yes, I said that last week's pull request was the last. I really meant
> it, honest. But people (and their AI best mate) keep finding ugly
> stuff in dark corners, and I can't sit on this stuff much longer.
>
> So here we have an assorted mess of bad races, broken userspace, and
> architectural bugs. What's not to like? As usual, details in the tag
> below.
x86 isn't doing any better, so who am I to judge.
Pulled, thanks.
Paolo
>
> Please pull,
>
> M.
>
> The following changes since commit 83726330748981372bde86ed5411d7b306612991:
>
> KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor (2026-05-29 10:04:00 +0100)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.1-5
>
> for you to fetch changes up to 17f073f78fc43280891ecde8f8ec3f84f98bb37c:
>
> KVM: arm64: Correctly identify executable PTEs at stage-2 (2026-06-05 14:07:57 +0100)
>
> ----------------------------------------------------------------
> KVM/arm64 fixes for 7.1, take #5
>
> - Correctly drop the ITS translation cache reference when it actually
> gets invalidated
>
> - Take the SRCU lock for SW page table walks
>
> - Restore POR_EL0 access to host EL0, avoiding POR_EL0 becoming
> inaccessible from EL0 after running a guest
>
> - Reassign nested_mmus array behind mmu_lock, ensuring that vcpu init
> and MMU notifiers are mutually exclusive
>
> - Correctly handle FEAT_XNX at stage-2
>
> ----------------------------------------------------------------
> Hyunwoo Kim (3):
> KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry
> KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation
> KVM: arm64: Reassign nested_mmus array behind mmu_lock
>
> Joey Gouly (1):
> KVM: arm64: Restore POR_EL0 access to host EL0
>
> Oliver Upton (2):
> KVM: arm64: nv: Fix handling of XN[0] when !FEAT_XNX
> KVM: arm64: Correctly identify executable PTEs at stage-2
>
> arch/arm64/include/asm/kvm_nested.h | 4 ++--
> arch/arm64/kvm/at.c | 6 ++++--
> arch/arm64/kvm/hyp/include/hyp/switch.h | 2 ++
> arch/arm64/kvm/hyp/pgtable.c | 4 +++-
> arch/arm64/kvm/nested.c | 33 ++++++++++++++++++++-------------
> arch/arm64/kvm/vgic/vgic-its.c | 6 ++++--
> 6 files changed, 35 insertions(+), 20 deletions(-)
>
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Stefan Wahren @ 2026-06-05 16:51 UTC (permalink / raw)
To: Frank Li
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <aiL5Yy7hiL30FENV@lizhi-Precision-Tower-5810>
Am 05.06.26 um 18:29 schrieb Frank Li:
> On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
>> Hi Frank,
>>
>> Am 27.05.26 um 17:14 schrieb Stefan Wahren:
>>> Enable DP83822 PHY driver as a module to support the Ethernet PHY,
>>> which is placed on phyCORE-i.MX93 SOM.
>>>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>> could you please take care of this patch?
> I will pick it, next time please cc imx@lists.linux.dev, otherwise, my imx
> patchwork can't see your patch
Sorry for this and thanks for picking
Regards
>
> Frank
>
>>> ---
>>>
>>> Changes in V2:
>>> - rebase patch
>>> - add Krzysztof's Reviewed-by
>>>
>>> arch/arm64/configs/defconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>>> index d905a0777f93..20bbbd310d2f 100644
>>> --- a/arch/arm64/configs/defconfig
>>> +++ b/arch/arm64/configs/defconfig
>>> @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
>>> CONFIG_QCA808X_PHY=m
>>> CONFIG_REALTEK_PHY=y
>>> CONFIG_ROCKCHIP_PHY=y
>>> +CONFIG_DP83822_PHY=m
>>> CONFIG_DP83867_PHY=y
>>> CONFIG_DP83869_PHY=m
>>> CONFIG_DP83TG720_PHY=m
>>
^ permalink raw reply
* Re: [PATCH v4 2/4] arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP
From: Frank Li @ 2026-06-05 16:49 UTC (permalink / raw)
To: Alexander Stein
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Shawn Guo, Paul Gerber, devicetree, linux-kernel,
imx, linux-arm-kernel, linux, linux-renesas-soc
In-Reply-To: <20260603093621.2504490-2-alexander.stein@ew.tq-group.com>
On Wed, Jun 03, 2026 at 11:36:07AM +0200, Alexander Stein wrote:
> From: Paul Gerber <paul.gerber@tq-group.com>
>
> This adds support for TQMa8MPQS module on MB-SMARC-2 board.
>
> Signed-off-by: Paul Gerber <paul.gerber@tq-group.com>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
> Changes in v4:
> * Fix audio codec clock config (similar to commit 6d36cebfb466a
> ("arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio
> codec as well")
> * Fix GPIO line names on gpio4, found by Sashiko bot
> * Move compatible and reg property to top for tmp1075
> * Remove interrupts for tmp1075
> No support in bindings and driver, although HW has ALET pin connected
>
...
> + pcieclk: clock-generator@6a {
> + compatible = "renesas,9fgv0241";
> + reg = <0x6a>;
> + clocks = <&clk_xtal25>;
> + #clock-cells = <1>;
> + };
> +
> + imu@6b {
Please generial node name: inertial-sensor@6b
Frank
^ permalink raw reply
* Re: [PATCH v4 4/4] arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
From: Frank Li @ 2026-06-05 16:47 UTC (permalink / raw)
To: Alexander Stein
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Shawn Guo, devicetree, linux-kernel, imx,
linux-arm-kernel, linux, linux-renesas-soc
In-Reply-To: <20260603093621.2504490-4-alexander.stein@ew.tq-group.com>
On Wed, Jun 03, 2026 at 11:36:09AM +0200, Alexander Stein wrote:
> This adds an overlay for the supported LVDS display AUO G133HAN01.
> Configure the video PLL frequency to exactly match typical pixel clock of
> 141.200 MHz.
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
Can you fix W=1 dtb build warnings?
Frank
> Changes in v4:
> * New to series v4
>
> arch/arm64/boot/dts/freescale/Makefile | 2 +
> ...p-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso | 74 +++++++++++++++++++
> 2 files changed, 76 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index dee2bea156740..3f466f102dc1d 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -385,8 +385,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtbo
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33-imx219.dtb
>
> +imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtbo
> imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtbo
> imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtbo
> +dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtb
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
> new file mode 100644
> index 0000000000000..9595cf4d43cd0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
> @@ -0,0 +1,74 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> +/*
> + * Copyright (c) 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
> + * D-82229 Seefeld, Germany.
> + * Author: Martin Schmiedel
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&backlight_lvds0 {
> + status = "okay";
> +};
> +
> +&panel_lvds0 {
> + compatible = "auo,g133han01";
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dual-lvds-odd-pixels;
> +
> + panel_in_lvds0: endpoint {
> + remote-endpoint = <&ldb_lvds_ch0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dual-lvds-even-pixels;
> +
> + panel_in_lvds1: endpoint {
> + remote-endpoint = <&ldb_lvds_ch1>;
> + };
> + };
> + };
> +};
> +
> +&lcdif2 {
> + status = "okay";
> +};
> +
> +&lvds_bridge {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + ldb_lvds_ch0: endpoint {
> + remote-endpoint = <&panel_in_lvds0>;
> + };
> + };
> +
> + port@2 {
> + ldb_lvds_ch1: endpoint {
> + remote-endpoint = <&panel_in_lvds1>;
> + };
> + };
> + };
> +};
> +
> +// Update VIDEO_PLL1 frequency
> +&media_blk_ctrl {
> + assigned-clock-rates = <500000000>, <200000000>,
> + <0>, <0>, <500000000>,
> + <988400000>;
> +};
> +
> +&pwm3 {
> + status = "okay";
> +};
> --
> 2.54.0
>
^ permalink raw reply
* [GIT PULL] KVM/arm64 fixes for 7.1, take #5
From: Marc Zyngier @ 2026-06-05 16:45 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Hyunwoo Kim, Joey Gouly, Oliver Upton, Wei-Lin Chang,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, kvmarm,
linux-arm-kernel, kvm
Paolo,
Yes, I said that last week's pull request was the last. I really meant
it, honest. But people (and their AI best mate) keep finding ugly
stuff in dark corners, and I can't sit on this stuff much longer.
So here we have an assorted mess of bad races, broken userspace, and
architectural bugs. What's not to like? As usual, details in the tag
below.
Please pull,
M.
The following changes since commit 83726330748981372bde86ed5411d7b306612991:
KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor (2026-05-29 10:04:00 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.1-5
for you to fetch changes up to 17f073f78fc43280891ecde8f8ec3f84f98bb37c:
KVM: arm64: Correctly identify executable PTEs at stage-2 (2026-06-05 14:07:57 +0100)
----------------------------------------------------------------
KVM/arm64 fixes for 7.1, take #5
- Correctly drop the ITS translation cache reference when it actually
gets invalidated
- Take the SRCU lock for SW page table walks
- Restore POR_EL0 access to host EL0, avoiding POR_EL0 becoming
inaccessible from EL0 after running a guest
- Reassign nested_mmus array behind mmu_lock, ensuring that vcpu init
and MMU notifiers are mutually exclusive
- Correctly handle FEAT_XNX at stage-2
----------------------------------------------------------------
Hyunwoo Kim (3):
KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry
KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation
KVM: arm64: Reassign nested_mmus array behind mmu_lock
Joey Gouly (1):
KVM: arm64: Restore POR_EL0 access to host EL0
Oliver Upton (2):
KVM: arm64: nv: Fix handling of XN[0] when !FEAT_XNX
KVM: arm64: Correctly identify executable PTEs at stage-2
arch/arm64/include/asm/kvm_nested.h | 4 ++--
arch/arm64/kvm/at.c | 6 ++++--
arch/arm64/kvm/hyp/include/hyp/switch.h | 2 ++
arch/arm64/kvm/hyp/pgtable.c | 4 +++-
arch/arm64/kvm/nested.c | 33 ++++++++++++++++++++-------------
arch/arm64/kvm/vgic/vgic-its.c | 6 ++++--
6 files changed, 35 insertions(+), 20 deletions(-)
^ permalink raw reply
* Re: [PATCH] arm64: arch_timer: reuse arch_timer_read_cnt{p,v}ct_el0() helpers
From: Will Deacon @ 2026-06-05 16:43 UTC (permalink / raw)
To: Mark Rutland, Marc Zyngier, Catalin Marinas, Breno Leitao
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-kernel,
kernel-team
In-Reply-To: <20260523-arch64_fix-v1-1-283bd4b73d49@debian.org>
On Sat, 23 May 2026 12:59:26 -0400, Breno Leitao wrote:
> __arch_counter_get_cntpct() and __arch_counter_get_cntvct() open-code
> the same ECV-aware ALTERNATIVE block that arch_timer_read_cntpct_el0()
> and arch_timer_read_cntvct_el0() already provide in the same header.
> The two pairs are byte-for-byte identical except for the trailing
> arch_counter_enforce_ordering() the __arch_counter_get_* variants add.
>
> Replace the duplicated inline assembly in __arch_counter_get_cntpct()
> and __arch_counter_get_cntvct() with calls to the corresponding helpers.
> This mirrors commit 00b39d150986 ("arm64: vdso: Use
> __arch_counter_get_cntvct()"), which removed similar duplication from
> the vDSO, and keeps the system-counter read sequence in a single place,
> reducing assembly code in the kernell
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: arch_timer: reuse arch_timer_read_cnt{p,v}ct_el0() helpers
https://git.kernel.org/arm64/c/11c33ffb3a4e
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2 0/5] fixes for data/bss linear alias unmap series
From: Will Deacon @ 2026-06-05 16:43 UTC (permalink / raw)
To: linux-arm-kernel, Ard Biesheuvel
Cc: catalin.marinas, kernel-team, Will Deacon, linux-kernel,
Ard Biesheuvel, Kevin Brodsky, Mark Brown, Marc Zyngier
In-Reply-To: <20260604151151.150377-7-ardb+git@google.com>
On Thu, 04 Jun 2026 17:11:52 +0200, Ard Biesheuvel wrote:
> Fixes for the data/bss linear alias unmap series:
>
> - Fix KASAN related issue reported by Mark, by moving all KASAN page
> tables out of BSS [on arm64], not just the ones defined under
> arch/arm64
>
> - Fix two issues spotted by Sashiko
>
> [...]
Applied to arm64 (for-next/mm), thanks!
[1/5] arm64: Rename page table BSS section to .bss..pgtbl
https://git.kernel.org/arm64/c/9c401fa7398f
[2/5] kasan: Move generic KASAN page tables out of BSS too
https://git.kernel.org/arm64/c/9f7f685758c6
[3/5] arm64: Avoid double evaluation of __ptep_get()
https://git.kernel.org/arm64/c/568def8e87fc
[4/5] KVM: arm64: Omit tag sync on stage-2 mappings of the zero page
https://git.kernel.org/arm64/c/2986a6257405
[5/5] arm64: mm: Defer remap of linear alias of data/bss
https://git.kernel.org/arm64/c/53205d56212c
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH V2] arm64/mm: Rename ptdesc_t
From: Will Deacon @ 2026-06-05 16:43 UTC (permalink / raw)
To: linux-arm-kernel, Anshuman Khandual
Cc: catalin.marinas, kernel-team, Will Deacon, David Hildenbrand,
Mike Rapoport, linux-efi, linux-kernel
In-Reply-To: <20260520063417.2363417-1-anshuman.khandual@arm.com>
On Wed, 20 May 2026 07:34:17 +0100, Anshuman Khandual wrote:
> ptdesc_t sounds very similar to the core MM struct ptdesc which is actually
> the memory descriptor for page table allocations. Hence rename this typedef
> element as ptval_t instead for better clarity and separation.
>
>
Applied to arm64 (for-next/mm), thanks!
[1/1] arm64/mm: Rename ptdesc_t
https://git.kernel.org/arm64/c/c34d4d48c4a1
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2 05/12] drm/bridge: synopsys: dw-dp: Add follow-up bridge support
From: Sebastian Reichel @ 2026-06-05 16:42 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Airlie,
Simona Vetter, Dmitry Baryshkov, Cristian Ciocaltea, Damon Ding,
Dmitry Baryshkov, Alexey Charkov, dri-devel, linux-rockchip,
linux-kernel, devicetree, kernel, linux-arm-kernel
In-Reply-To: <177918892313.537125.10814687633426590148.b4-review@b4>
[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]
Hello Luca,
On Tue, May 19, 2026 at 01:08:43PM +0200, Luca Ceresoli wrote:
> On Fri, 01 May 2026 00:20:32 +0200, Sebastian Reichel <sebastian.reichel@collabora.com> wrote:
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> > index fc4ddb7792d7..ccc55e40e81c 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> > @@ -2064,6 +2064,20 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
> > goto unregister_aux;
> > }
> >
> > + next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
>
> devm_drm_of_get_bridge() looks for either a panel or a bridge. Is it
> possible to have a panel connected here?
>
> If it isn't, then using of_drm_get_bridge_by_endpoint() which has just been
> merged [0] would be much simpler and cleaner.
Technically this should always be connected to the USBDP PHY
on the Rockchip platforms using this IP (RK3588 & RK3576) and
there are no other upstream platforms using this code so far.
Having said that, we do have some upstream DTs, which directly
connect it to a DP connector instead (as the PHY does not yet
expose a DRM bridge, that's being handled in a different series).
But there is no upstream board connecting it to an eDP panel,
so I will switch over to of_drm_get_bridge_by_endpoint().
Thanks for the info.
Greetings,
-- Sebastian
>
> [0] https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/03d1078112fddd706b2c1e4a7d98cf18700eb5df
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Frank Li @ 2026-06-05 16:35 UTC (permalink / raw)
To: Stefan Wahren
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <5cf05aec-bc70-4758-9c00-812a33a44946@gmx.net>
On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
> Hi Frank,
>
> Am 27.05.26 um 17:14 schrieb Stefan Wahren:
> > Enable DP83822 PHY driver as a module to support the Ethernet PHY,
> > which is placed on phyCORE-i.MX93 SOM.
> >
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> could you please take care of this patch?
which is base commit, I can't apply clearly.
Frank
> > ---
> >
> > Changes in V2:
> > - rebase patch
> > - add Krzysztof's Reviewed-by
> >
> > arch/arm64/configs/defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index d905a0777f93..20bbbd310d2f 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
> > CONFIG_QCA808X_PHY=m
> > CONFIG_REALTEK_PHY=y
> > CONFIG_ROCKCHIP_PHY=y
> > +CONFIG_DP83822_PHY=m
> > CONFIG_DP83867_PHY=y
> > CONFIG_DP83869_PHY=m
> > CONFIG_DP83TG720_PHY=m
>
>
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Frank Li @ 2026-06-05 16:29 UTC (permalink / raw)
To: Stefan Wahren
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <5cf05aec-bc70-4758-9c00-812a33a44946@gmx.net>
On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
> Hi Frank,
>
> Am 27.05.26 um 17:14 schrieb Stefan Wahren:
> > Enable DP83822 PHY driver as a module to support the Ethernet PHY,
> > which is placed on phyCORE-i.MX93 SOM.
> >
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> could you please take care of this patch?
I will pick it, next time please cc imx@lists.linux.dev, otherwise, my imx
patchwork can't see your patch
Frank
> > ---
> >
> > Changes in V2:
> > - rebase patch
> > - add Krzysztof's Reviewed-by
> >
> > arch/arm64/configs/defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index d905a0777f93..20bbbd310d2f 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
> > CONFIG_QCA808X_PHY=m
> > CONFIG_REALTEK_PHY=y
> > CONFIG_ROCKCHIP_PHY=y
> > +CONFIG_DP83822_PHY=m
> > CONFIG_DP83867_PHY=y
> > CONFIG_DP83869_PHY=m
> > CONFIG_DP83TG720_PHY=m
>
>
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Stefan Wahren @ 2026-06-05 16:22 UTC (permalink / raw)
To: Frank Li
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <20260527151414.184823-1-wahrenst@gmx.net>
Hi Frank,
Am 27.05.26 um 17:14 schrieb Stefan Wahren:
> Enable DP83822 PHY driver as a module to support the Ethernet PHY,
> which is placed on phyCORE-i.MX93 SOM.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
could you please take care of this patch?
> ---
>
> Changes in V2:
> - rebase patch
> - add Krzysztof's Reviewed-by
>
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index d905a0777f93..20bbbd310d2f 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
> CONFIG_QCA808X_PHY=m
> CONFIG_REALTEK_PHY=y
> CONFIG_ROCKCHIP_PHY=y
> +CONFIG_DP83822_PHY=m
> CONFIG_DP83867_PHY=y
> CONFIG_DP83869_PHY=m
> CONFIG_DP83TG720_PHY=m
^ permalink raw reply
* Re: [PATCH v2 4/5] KVM: arm64: Omit tag sync on stage-2 mappings of the zero page
From: Marc Zyngier @ 2026-06-05 16:18 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-kernel, will, catalin.marinas,
Ard Biesheuvel, Kevin Brodsky, Mark Brown, stable
In-Reply-To: <20260604151151.150377-11-ardb+git@google.com>
On Thu, 04 Jun 2026 16:11:56 +0100,
Ard Biesheuvel <ardb+git@google.com> wrote:
>
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Commit
>
> f620d66af316 ("arm64: mte: Do not flag the zero page as PG_mte_tagged")
>
> removed the PG_mte_tagged flag from the zero page, but missed a KVM code
> path that may set this flag on the zero page when it is used in a
> stage-2 CoW mapping of anonymous memory.
>
> So disregard the zero page explicitly in sanitise_mte_tags().
>
> Fixes: f620d66af316 ("arm64: mte: Do not flag the zero page as PG_mte_tagged")
> Cc: <stable@vger.kernel.org> # 5.10.x
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/arm64/kvm/mmu.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index d089c107d9b7..445d6cf035c9 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1479,6 +1479,11 @@ static void sanitise_mte_tags(struct kvm *kvm, kvm_pfn_t pfn,
> if (!kvm_has_mte(kvm))
> return;
>
> + if (is_zero_pfn(pfn)) {
> + WARN_ON_ONCE(nr_pages != 1);
> + return;
> + }
> +
> if (folio_test_hugetlb(folio)) {
> /* Hugetlb has MTE flags set on head page only */
> if (folio_try_hugetlb_mte_tagging(folio)) {
Reviewed-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v4 4/7] dt-bindings: input: sun4i-lradc-keys: Add A100/A133 compatible
From: Conor Dooley @ 2026-06-05 16:11 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-arm-kernel, linux-sunxi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans de Goede, Dmitry Torokhov, Andre Przywara, Jun Yan,
Lukas Schmid, J. Neuschäfer, Eric Biggers, Michal Simek,
Luca Weiss, Sven Peter, Maxime Ripard, devicetree, linux-kernel,
linux-input
In-Reply-To: <20260605070923.3045073-5-alexander.sverdlin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 13/14] net: stmmac: tc956x: add TC956x/QPS615 support
From: Maxime Chevallier @ 2026-06-05 16:05 UTC (permalink / raw)
To: Alex Elder, andrew+netdev, davem, edumazet, kuba, pabeni,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh
Cc: Daniel Thompson, mohd.anwar, a0987203069, alexandre.torgue, ast,
boon.khai.ng, chenchuangyu, chenhuacai, daniel, hawk, hkallweit1,
inochiama, john.fastabend, julianbraha, livelycarpet87,
mcoquelin.stm32, me, prabhakar.mahadev-lad.rj, richardcochran,
rohan.g.thomas, sdf, siyanteng, weishangjuan, wens, netdev, bpf,
linux-arm-msm, devicetree, linux-gpio, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260605010022.968612-14-elder@riscstar.com>
Hi Alex,
On 6/5/26 03:00, Alex Elder wrote:
> From: Daniel Thompson <daniel@riscstar.com>
>
> Toshiba TC956x is an Ethernet AVB/TSN bridge and is essentially a
> small and highly-specialized SoC. TC956x includes an "eMAC" subsystem
> that can be accessed, along with several other peripherals, via two
> PCIe endpoint functions. There is a main driver for the endpoint that
> decomposes things and creates auxiliary bus devices to model the SoC.
>
> The eMAC consists of a Designware XGMAC, XPCS and PMA. Each eMAC is
> supported by an MSIGEN that bridges TC956x level interrupts to PCIe
> MSIs.
>
> Add a driver for the eMAC/MSIGEN combination.
>
> Co-developed-by: Alex Elder <elder@riscstar.com>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> ---
[...]
> +static int tc956x_lookup_max_speed(phy_interface_t phy_interface)
> +{
> + switch (phy_interface) {
> + case PHY_INTERFACE_MODE_SGMII:
The SGMII definition we use in the kernel is the Cisco SGMII de-facto
standard that only supports 10/100/1000M. Some vendors use flavours with
names such as HS-SGMII and such, that's basically SGMII clocked at 2.5G
with aneg disabled. It kinda becomes 2500BaseX then.
So all in all, we don't support 2500M on SGMII.
> + case PHY_INTERFACE_MODE_2500BASEX:
> + return SPEED_2500;
> +
> + default:
> + return -EOPNOTSUPP;
> + }
Maxime
^ permalink raw reply
* Re: [PATCH bpf-next v2 8/8] selftests/bpf: add tests to validate KASAN on JIT programs
From: Alexis Lothoré @ 2026-06-05 16:01 UTC (permalink / raw)
To: Yonghong Song, Alexis Lothoré (eBPF Foundation),
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Jiri Olsa, John Fastabend, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel
In-Reply-To: <13b87293-5237-43d3-9f91-33c13041cb43@linux.dev>
On Fri Jun 5, 2026 at 5:47 PM CEST, Yonghong Song wrote:
[...]
> [root@arch-fb-vm1 bpf]# ./test_progs -n 164
> test_kasan:PASS:alloc test ctx 0 nsec
> gzopen /boot/config-7.1.0-rc5-gec86c8156bd6: No such file or directory
> test_kasan:PASS:open prog 0 nsec
> test_kasan:PASS:find rnd_hi32 prog 0 nsec
> ...
> All error logs:
> test_kasan:PASS:alloc test ctx 0 nsec
> gzopen /boot/config-7.1.0-rc5-gec86c8156bd6: No such file or directory
> test_kasan:PASS:open prog 0 nsec
> test_kasan:PASS:find rnd_hi32 prog 0 nsec
> test_kasan:PASS:load prog 0 nsec
> test_kasan:PASS:open kernel logs 0 nsec
> test_kasan:PASS:get map 0 nsec
> test_kasan:PASS:set map 0 nsec
> run_subtest_with_size_and_location:PASS:find test prog 0 nsec
> run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
> run_subtest_with_size_and_location:PASS:run prog 0 nsec
> run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
> run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
> #164/1 kasan/st_1_not_on_stack:FAIL
[...]
> #164 kasan:FAIL
>
> I checked the subtest 164/1,
>
> For
>
> ret = check_kasan_report_in_kernel_logs(klog_buffer, ctx,
> test->is_write, access_size);
> if (on_stack || test->expect_no_report)
> ASSERT_NEQ(ret, 0, "no report should be generated");
> else
> ASSERT_OK(ret, "report should be generated");
>
> the ret is equal to 1 as klog_buffer is empty. This caused the failure.
Are you seeing any kasan report when you manually check your kernel
logs, or not at all ? If not at all, are you using the "CI" defconfig ?
cat tools/testing/selftests/bpf/{config,config.vm,config.x86_64} > .config && make olddefconfig
If not, would you mind sharing your defconfig ?
Thanks,
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH RFC v2] drm/rockchip: vop2: Add clock rate mode check
From: Alexey Charkov @ 2026-06-05 15:58 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sandy Huang, Heiko Stübner, Andy Yan, Daniel Stone,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, dri-devel, linux-arm-kernel, linux-rockchip,
linux-kernel, kernel
In-Reply-To: <20260409-vop2-clk-rate-check-v2-1-b207cfc427d7@collabora.com>
On Fri, Apr 10, 2026 at 2:37 AM Sebastian Reichel
<sebastian.reichel@collabora.com> wrote:
>
> The display might offer modes, which exceed the maximum clock rate of a
> video output. This usually happens for displays that offer refresh rates
> above 60 Hz. This results in no picture (or a broken one) being displayed
> without manual intervention. Fix this by teaching the driver about the
> maximum achievable clock rates for each video port.
>
> The information about the maximum clock rates for each video channel and
> the tip about multiple pixels being processed per clock were provided by
> Andy Yan and roughly checked against the information available in the
> datasheet (which specifies limits like "2560x1600@60Hz with 10-bit"
> instead of a specific pixel rate).
>
> For the video ports supporting a 600 MHz input clock, there is some
> logic to handle up to 4 pixels in parallel when needed resulting in
> the extra multiplier.
>
> Suggested-by: Andy Yan <andy.yan@rock-chips.com>
> Link: https://lore.kernel.org/linux-rockchip/1528d788.186b.19d08ed974c.Coremail.andyshrk@163.com/
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> I've kept the RFC tag, as I'm not sure about the 4x parallel pixel
> processing. IIUIC all of the video ports with a maximum of 600 MHz
> input clock support it, considering they can go to 4K @ 120Hz,
> which is above 1.2GHz while Andy mentioned a max. support clock rate
> of 600 MHz.
> ---
> Changes in v2:
> - Link to v1: https://lore.kernel.org/r/20260217-vop2-clk-rate-check-v1-1-989b569119ba@collabora.com
> - based on v7.0-rc7
> - rename max_clock_rate into max_pixel_clock_rate to distinguish from
> input clock
> - update max clock rates to the numbers provided by Andy Yan with
> extra 4x multiplier for 4K 120Hz VPs
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 3 +++
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 1 +
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 10 ++++++++++
> 3 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index a195f5c819a2..35a0edda5375 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -1434,6 +1434,9 @@ static enum drm_mode_status vop2_crtc_mode_valid(struct drm_crtc *crtc,
> if (mode->hdisplay > vp->data->max_output.width)
> return MODE_BAD_HVALUE;
>
> + if (mode->clock > vp->data->max_pixel_clock_rate / 1000)
> + return MODE_CLOCK_HIGH;
> +
> return MODE_OK;
> }
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> index 9124191899ba..fd46913f3346 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> @@ -225,6 +225,7 @@ struct vop2_video_port_data {
> u16 gamma_lut_len;
> u16 cubic_lut_len;
> struct vop_rect max_output;
> + u32 max_pixel_clock_rate;
> const u8 pre_scan_max_dly[4];
> unsigned int offset;
> /**
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> index f3950e8476a7..6ae3d506c476 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> @@ -559,18 +559,21 @@ static const struct vop2_video_port_data rk3568_vop_video_ports[] = {
> .gamma_lut_len = 1024,
> .cubic_lut_len = 9 * 9 * 9,
> .max_output = { 4096, 2304 },
> + .max_pixel_clock_rate = 600000000U,
> .pre_scan_max_dly = { 69, 53, 53, 42 },
> .offset = 0xc00,
> }, {
> .id = 1,
> .gamma_lut_len = 1024,
> .max_output = { 2048, 1536 },
> + .max_pixel_clock_rate = 200000000U,
> .pre_scan_max_dly = { 40, 40, 40, 40 },
> .offset = 0xd00,
> }, {
> .id = 2,
> .gamma_lut_len = 1024,
> .max_output = { 1920, 1080 },
> + .max_pixel_clock_rate = 150000000U,
> .pre_scan_max_dly = { 40, 40, 40, 40 },
> .offset = 0xe00,
> },
> @@ -775,6 +778,7 @@ static const struct vop2_video_port_data rk3576_vop_video_ports[] = {
> .gamma_lut_len = 1024,
> .cubic_lut_len = 9 * 9 * 9, /* 9x9x9 */
> .max_output = { 4096, 2304 },
> + .max_pixel_clock_rate = 600000000U * 4,
Hi Sebastian,
I've tested it on a bunch of different displays with RK3576 while also
giving VP0 an unlimited PLL to work with (and also expanding its rates
table for each of the displays' EDID preferred pixel clocks), and I'm
pretty sure this should be * 2 here, rather than * 4. That would also
align with ".pixel_rate = 2" just below.
In its current form, some of the advanced displays with 240 Hz modes
by default choose modes leading to visual artifacts indicative of
overclocking strain of the graphics pipeline.
The rest look plausible, so with that change please feel free to include:
Tested-by: Alexey Charkov <alchark@flipper.net> # RK3576
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH bpf-next v2 5/8] bpf, x86: emit KASAN checks into x86 JITed programs
From: Alexis Lothoré @ 2026-06-05 15:50 UTC (permalink / raw)
To: Yonghong Song, Alexis Lothoré (eBPF Foundation),
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Jiri Olsa, John Fastabend, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel
In-Reply-To: <78009c06-4233-4e0a-88ec-33eba10ad8b3@linux.dev>
Hi Yonghong,
On Fri Jun 5, 2026 at 4:54 PM CEST, Yonghong Song wrote:
>
[...]
>> if (BPF_MODE(insn->code) == BPF_PROBE_MEMSX ||
>> BPF_MODE(insn->code) == BPF_MEMSX)
>> @@ -2592,13 +2622,13 @@ static int do_jit(struct bpf_verifier_env *env, struct bpf_prog *bpf_prog, int *
>> fallthrough;
>> case BPF_STX | BPF_ATOMIC | BPF_W:
>> case BPF_STX | BPF_ATOMIC | BPF_DW:
>> + bool is64 = BPF_SIZE(insn->code) == BPF_DW;
>> + u32 real_src_reg = src_reg;
>> + u32 real_dst_reg = dst_reg;
>
> With llvm23, I got the following build failure:
>
> /home/yhs/work/bpf-next/arch/x86/net/bpf_jit_comp.c:2625:4: error:
> label followed by a declaration is a C23 extension [-Werror,-Wc23-extensions]
> 2625 | bool is64 = BPF_SIZE(insn->code) == BPF_DW;
> | ^
> 1 error generated.
>
> The below is a fix:
Thanks for the test, the report and the fix. So this warning looks
specific to llvm23, as CI does not trigger it with LLVM21. I'll bring
the fix in in the next revision.
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: net: add Realtek r8169 family PCIe Ethernet
From: Heiner Kallweit @ 2026-06-05 15:48 UTC (permalink / raw)
To: ricardo, nic_swsd, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260605-rk3588-dts-rtl-eth-describe-dt-alias-v3-1-8a8857b39daf@pardini.net>
On 05.06.2026 13:49, Ricardo Pardini via B4 Relay wrote:
> From: Ricardo Pardini <ricardo@pardini.net>
>
> Add a binding for fixed/soldered Realtek PCIe Ethernet controllers
> driven by the r8169 driver (RTL8125/8126/8127/8168 and variants).
>
> The "pciVVVV,DDDD" compatibles are the Open Firmware PCI Bus Binding
> spelling, auto-derived from PCI-SIG vendor/device IDs, but they still
> need a binding when used in a board DT - analogous to "usbVVVV,PPPP"
> compatibles documented in their own bindings (e.g. microchip,lan95xx)
> so board DTs attaching properties (fixed MAC, nvmem cell, ...) to
> these PCI function nodes can be validated.
>
The of node seems to be created by of_pci_make_dev_node(). But this
function is called for bridges only in pci_bus_add_device().
So where is the node created in your case? Did you test node creation?
> Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
> ---
> .../devicetree/bindings/net/realtek,r8169.yaml | 54 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 55 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/realtek,r8169.yaml b/Documentation/devicetree/bindings/net/realtek,r8169.yaml
> new file mode 100644
> index 0000000000000..6923211ff4c93
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek,r8169.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/realtek,r8169.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Realtek r8169 family PCIe Ethernet Controllers
> +
> +maintainers:
> + - Heiner Kallweit <hkallweit1@gmail.com>
> +
> +description:
> + PCI function node properties for fixed/soldered Realtek Ethernet
> + controllers driven by the r8169 driver.
> +
> +allOf:
> + - $ref: ethernet-controller.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - pci10ec,8125 # RTL8125 2.5GbE
> + - pci10ec,8126 # RTL8126 5GbE
> + - pci10ec,8127 # RTL8127
> + - pci10ec,8161 # RTL8168 variant
> + - pci10ec,8162 # RTL8168 variant
> + - pci10ec,8168 # RTL8168/8111 GbE
This list reflects just some of the PCI id's handled by r8169.
Any specific reason for this exact selection?
> +
> + reg:
> + maxItems: 1
> +
> + local-mac-address: true
> + mac-address: true
> + nvmem-cells: true
> + nvmem-cell-names: true
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + pcie {
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + ethernet@0,0 {
> + compatible = "pci10ec,8125";
> + reg = <0x10000 0 0 0 0>;
> + local-mac-address = [00 00 00 00 00 00];
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b539be153f6a4..6341de4fadb6c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -134,6 +134,7 @@ M: Heiner Kallweit <hkallweit1@gmail.com>
> M: nic_swsd@realtek.com
> L: netdev@vger.kernel.org
> S: Maintained
> +F: Documentation/devicetree/bindings/net/realtek,r8169.yaml
> F: drivers/net/ethernet/realtek/r8169*
>
> 8250/16?50 (AND CLONE UARTS) SERIAL DRIVER
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox