* Proszę o kontakt
From: Maciej Przybylski @ 2024-03-25 8:36 UTC (permalink / raw)
To: linux-arm-kernel
Dzień dobry,
Czy jest możliwość nawiązania współpracy z Państwem?
Z chęcią porozmawiam z osobą zajmującą się działaniami związanymi ze sprzedażą.
Pomagamy skutecznie pozyskiwać nowych klientów.
Zapraszam do kontaktu.
Pozdrawiam
Maciej Przybylski
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] arm64: dts: ti: verdin-am62: use SD1 CD as GPIO
From: Francesco Dolcini @ 2024-03-25 8:33 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel,
João Paulo Silva Gonçalves
From: Francesco Dolcini <francesco.dolcini@toradex.com>
TI SDHCI instance has a hardware debounce timer of 1 second as described
in commit 7ca0f166f5b2 ("mmc: sdhci_am654: Add workaround for card detect
debounce timer"), because of this the boot time increases of up to 1
second.
Workaround the issue the same way that is done on
arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts, using the SD1 CD as
GPIO.
Suggested-by: Nishanth Menon <nm@ti.com>
Reported-by: João Paulo Silva Gonçalves <joao.goncalves@toradex.com>
Closes: https://lore.kernel.org/all/0e81af80de3d55e72f79af83fa5db87f5c9938f8.camel@toradex.com/
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
v2:
* rebased on v6.9-rc1
* move `ti,fails-without-test-cd` before `status`
* use SDHCI instance, instead of SDHCI IP in the commit message
v1: https://lore.kernel.org/all/20240312144956.40211-1-francesco@dolcini.it/
---
arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
index e8d8857ad51f..b1cc2e60aa23 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
@@ -457,6 +457,13 @@ AM62X_IOPAD(0x01c4, PIN_INPUT, 7) /* (B14) SPI0_D1.GPIO1_19 */ /* SODIMM 161 */
>;
};
+ /* Verdin SD_1_CD# as GPIO */
+ pinctrl_sd1_cd_gpio: main-gpio1-48-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x240, PIN_INPUT_PULLUP, 7) /* (D17) MMC1_SDCD.GPIO1_48 */ /* SODIMM 84 */
+ >;
+ };
+
/* Verdin DSI_1_INT# (pulled-up as active-low) */
pinctrl_dsi1_int: main-gpio1-49-default-pins {
pinctrl-single,pins = <
@@ -571,7 +578,6 @@ AM62X_IOPAD(0x230, PIN_INPUT, 0) /* (A22) MMC1_DAT0 */ /* SODIMM 80 */
AM62X_IOPAD(0x22c, PIN_INPUT, 0) /* (B21) MMC1_DAT1 */ /* SODIMM 82 */
AM62X_IOPAD(0x228, PIN_INPUT, 0) /* (C21) MMC1_DAT2 */ /* SODIMM 70 */
AM62X_IOPAD(0x224, PIN_INPUT, 0) /* (D22) MMC1_DAT3 */ /* SODIMM 72 */
- AM62X_IOPAD(0x240, PIN_INPUT_PULLUP, 0) /* (D17) MMC1_SDCD */ /* SODIMM 84 */
>;
};
@@ -1441,10 +1447,12 @@ &sdhci0 {
/* Verdin SD_1 */
&sdhci1 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sdhci1>;
+ pinctrl-0 = <&pinctrl_sdhci1>, <&pinctrl_sd1_cd_gpio>;
+ cd-gpios = <&main_gpio1 48 GPIO_ACTIVE_LOW>;
disable-wp;
vmmc-supply = <®_sdhc1_vmmc>;
vqmmc-supply = <®_sdhc1_vqmmc>;
+ ti,fails-without-test-cd;
status = "disabled";
};
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 0/2] i.MX93 ADC calibration settings
From: Andrej Picej @ 2024-03-25 8:32 UTC (permalink / raw)
To: Jonathan Cameron
Cc: haibo.chen, linux-iio, devicetree, lars, shawnguo, s.hauer,
kernel, festevam, imx, linux-arm-kernel, linux-kernel, robh,
krzysztof.kozlowski+dt, conor+dt, upstream
In-Reply-To: <20240324135559.1640551d@jic23-huawei>
Hi Jonathan,
On 24. 03. 24 14:55, Jonathan Cameron wrote:
> On Wed, 20 Mar 2024 11:04:04 +0100
> Andrej Picej <andrej.picej@norik.com> wrote:
>
>> Hi all,
>>
>> we had some problems with failing ADC calibration on the i.MX93 boards.
>> Changing default calibration settings fixed this. The board where this
>> patches are useful is not yet upstream but will be soon (hopefully).
>
> Tell us more. My initial instinct is that this shouldn't be board specific.
> What's the trade off we are making here? Time vs precision of calibration or
> something else? If these are set to a level by default that doesn't work
> for our board, maybe we should just change them for all devices?
>
So we have two different boards with the same SoC. On one, the
calibration works with the default values, on the second one the
calibration fails, which makes the ADC unusable. What the ADC lines
measure differ between the boards though. But the implementation is
nothing out of the ordinary.
We tried different things but the only thing that helped is to use
different calibration properties. We tried deferring the probe and
calibration until later boot and after boot, but it did not help.
In the Reference Manual [1] (chapter 72.5.1) it is written:
> 4. Configure desired calibration settings (default values kept for highest accuracy maximum time).
So your assumption is correct, longer calibration time (more averaging
samples) -> higher precision. The default values go for a high accuracy.
And since we use a NRSMPL (Number of Averaging Samples) of 32 instead of
default 512, we reduce the accuracy so the calibration values pass the
internal defined limits.
I'm not sure that changing default values is the right solution here. We
saw default values work with one of the boards. And since the NXP kept
these values adjustable I think there is a reason behind it.
Note: When I say one of the boards I mean one board form. So same board
version, but different HW.
Best regards,
Andrej
[1] i.MX 93 Applications Processor Reference Manual, Rev. 4, 12/2023
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/8] clk: qcom: gdsc: Enable supply reglator in GPU GX handler
From: Johan Hovold @ 2024-03-25 8:31 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Bjorn Andersson, Konrad Dybcio, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Johan Hovold, linux-arm-msm, linux-clk, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, Ulf Hansson, Rob Clark, Abhinav Kumar,
Dmitry Baryshkov
In-Reply-To: <Zf25Sv2x9WaCFuIH@hovoldconsulting.com>
On Fri, Mar 22, 2024 at 06:00:58PM +0100, Johan Hovold wrote:
> On Thu, Jan 25, 2024 at 01:05:08PM -0800, Bjorn Andersson wrote:
> > The GX GDSC is modelled to aid the GMU in powering down the GPU in the
> > event that the GPU crashes, so that it can be restarted again. But in
> > the event that the power-domain is supplied through a dedicated
> > regulator (in contrast to being a subdomin of another power-domain),
> > something needs to turn that regulator on, both to make sure things are
> > powered and to match the operation in gdsc_disable().
> >
> > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > ---
> > drivers/clk/qcom/gdsc.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> > index 5358e28122ab..e7a4068b9f39 100644
> > --- a/drivers/clk/qcom/gdsc.c
> > +++ b/drivers/clk/qcom/gdsc.c
> > @@ -557,7 +557,15 @@ void gdsc_unregister(struct gdsc_desc *desc)
> > */
> > int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain)
> > {
> > - /* Do nothing but give genpd the impression that we were successful */
> > - return 0;
> > + struct gdsc *sc = domain_to_gdsc(domain);
> > + int ret = 0;
> > +
> > + /* Enable the parent supply, when controlled through the regulator framework. */
> > + if (sc->rsupply)
> > + ret = regulator_enable(sc->rsupply);
> > +
> > + /* Do nothing with the GDSC itself */
> > +
> > + return ret;
> > }
> > EXPORT_SYMBOL_GPL(gdsc_gx_do_nothing_enable);
>
> This patch (and series) is now in mainline as commit 9187ebb954ab ("clk:
> qcom: gdsc: Enable supply reglator in GPU GX handler") and appears to be
> involved in triggering the below lockdep splat on boot of the Lenovo
> ThinkPad X13s.
>
> Adding Ulf and the MSM DRM devs as well in case I blamed the wrong
> change here.
I've now verified that applying this series on top of 6.8 also triggers
the lockdep splat even if it is possible that it only exposed an
existing issue.
This is still a regression and also prevents using lockdep on these
platforms, which can lead to further locking issues being introduced
until this is fixed:
#regzbot ^introduced: 9187ebb954ab
Johan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] media: dt-bindings: i2c: add GalaxyCore GC05A2 image sensor
From: AngeloGioacchino Del Regno @ 2024-03-25 8:30 UTC (permalink / raw)
To: Zhi Mao, mchehab, robh+dt, krzysztof.kozlowski+dt, sakari.ailus
Cc: laurent.pinchart, shengnan.wang, yaya.chang,
Project_Global_Chrome_Upstream_Group, yunkec, conor+dt,
matthias.bgg, jacopo.mondi, 10572168, hverkuil-cisco, heiko,
jernej.skrabec, macromorgan, linus.walleij, hdegoede,
tomi.valkeinen, gerald.loacker, andy.shevchenko, bingbu.cao,
dan.scally, linux-media, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Krzysztof Kozlowski
In-Reply-To: <20240323014751.4989-2-zhi.mao@mediatek.com>
Il 23/03/24 02:47, Zhi Mao ha scritto:
> Add YAML device tree binding for GC05A2 CMOS image sensor,
> and the relevant MAINTAINERS entries.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Zhi Mao <zhi.mao@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 2/2] media: i2c: Add GC08A3 image sensor driver
From: AngeloGioacchino Del Regno @ 2024-03-25 8:29 UTC (permalink / raw)
To: Zhi Mao, mchehab, robh+dt, krzysztof.kozlowski+dt, sakari.ailus
Cc: laurent.pinchart, shengnan.wang, yaya.chang,
Project_Global_Chrome_Upstream_Group, yunkec, conor+dt,
matthias.bgg, jacopo.mondi, 10572168, hverkuil-cisco, heiko,
jernej.skrabec, macromorgan, linus.walleij, hdegoede,
tomi.valkeinen, gerald.loacker, andy.shevchenko, bingbu.cao,
dan.scally, linux-media, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20240323023851.5503-3-zhi.mao@mediatek.com>
Il 23/03/24 03:38, Zhi Mao ha scritto:
> Add a V4L2 sub-device driver for Galaxycore GC08A3 image sensor.
>
> Signed-off-by: Zhi Mao <zhi.mao@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH linux-next v3 02/14] crash: split vmcoreinfo exporting code out from crash_core.c
From: Geert Uytterhoeven @ 2024-03-25 8:24 UTC (permalink / raw)
To: Baoquan He
Cc: linux-kernel, kexec, x86, linux-arm-kernel, linuxppc-dev,
linux-s390, linux-sh, linux-mips, linux-riscv, loongarch, akpm,
ebiederm, hbathini, piliu, viro
In-Reply-To: <20240124051254.67105-3-bhe@redhat.com>
Hi Baoquan,
On Wed, Jan 24, 2024 at 6:13 AM Baoquan He <bhe@redhat.com> wrote:
> Now move the relevant codes into separate files:
> kernel/crash_reserve.c, include/linux/crash_reserve.h.
>
> And add config item CRASH_RESERVE to control its enabling.
>
> And also update the old ifdeffery of CONFIG_CRASH_CORE, including of
> <linux/crash_core.h> and config item dependency on CRASH_CORE
> accordingly.
>
> And also do renaming as follows:
> - arch/xxx/kernel/{crash_core.c => vmcore_info.c}
> because they are only related to vmcoreinfo exporting on x86, arm64,
> riscv.
>
> And also Remove config item CRASH_CORE, and rely on CONFIG_KEXEC_CORE to
> decide if build in crash_core.c.
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
> v2->v3:
> - There's conflict when rebasing to linux-next in kernel/crash_core.c
> because of below commits from Uladzislau:
> commit 699d9351822e ("mm: vmalloc: Fix a warning in the crash_save_vmcoreinfo_init()")
> commit 5f4c0c1e2a51 (:mm/vmalloc: remove vmap_area_list")
Thanks for your patch, which is now commit 443cbaf9e2fdbef7
("crash: split vmcoreinfo exporting code out from
crash_core.c") in v6.9-rc1.
After this, there are still two references left to CRASH_CORE:
1. Documentation/admin-guide/kdump/kdump.rst:
Subsequently, CRASH_CORE is selected by KEXEC_CORE::
2. arch/loongarch/Kconfig
config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
def_bool CRASH_CORE
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: soc: mediatek: Add support for MT8188 VPPSYS
From: AngeloGioacchino Del Regno @ 2024-03-25 8:23 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-media, mchehab, robh, krzysztof.kozlowski+dt, conor+dt,
matthias.bgg, amergnat, moudy.ho, hverkuil-cisco,
sebastian.fricke, u.kleine-koenig, chunkuang.hu, p.zabel,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
kernel
In-Reply-To: <20240322-lugged-tabloid-3d5a85dc58d0@spud>
Il 22/03/24 18:42, Conor Dooley ha scritto:
> On Fri, Mar 22, 2024 at 10:28:42AM +0100, AngeloGioacchino Del Regno wrote:
>> Add compatible for MT8188 VPP mutex.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> You should at least mention the difference between this any anything
> else.
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
It's exactly always the same difference for MuteX blocks: different bits to
activate mute for some IP ... but yeah, you're right, I'll shoot a word about
this in the commit description on v2 (waiting a bit before doing that anyway).
Thank you!
Cheers,
Angelo
>
> Thanks,
> Conor.
>
>> ---
>> .../devicetree/bindings/soc/mediatek/mediatek,mutex.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
>> index ba2014a8725c..a10326a9683d 100644
>> --- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
>> +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
>> @@ -33,6 +33,7 @@ properties:
>> - mediatek,mt8186-disp-mutex
>> - mediatek,mt8186-mdp3-mutex
>> - mediatek,mt8188-disp-mutex
>> + - mediatek,mt8188-vpp-mutex
>> - mediatek,mt8192-disp-mutex
>> - mediatek,mt8195-disp-mutex
>> - mediatek,mt8195-vpp-mutex
>> --
>> 2.44.0
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos: gs101: define all PERIC USI nodes
From: Krzysztof Kozlowski @ 2024-03-25 8:22 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: alim.akhtar, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, andre.draszik, willmcvicker, kernel-team
In-Reply-To: <73ba6104-aa54-444e-b6c5-7f89d1fa0060@linaro.org>
On 22/03/2024 14:39, Tudor Ambarus wrote:
>>
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>
> I'd like to respin this patch. Any preference on coding style for
> #address-cells and #size-cells? I guess they shall be above ranges
> property if present.
No, ranges should be just after reg, because it encodes often the same
or similar information (see also DTS Coding Style). I don't have
guideline, can be anywhere before vendor properties.
>
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&hsi2c1_bus>;
>>
>> Please reverse two lines, first pinctrl-0 then pinctrl-names. I know we
>
> Ok.
>
>> did not follow this convention till now, but at least new code can be
>> correct. Also clocks should be before pinctrl, so we keep some sort of
>> alphabetical order.
>
> Ok.
>
> I guess the order shall be:
>
> 1. compatible
> 2. reg
3. ranges
> 3. #address-cells (if applicable)
> #size-cells (if applicable)
> 5. Standard/common properties ordered alphabetically (ex. clocks,
> interrupts, pinctrl)
> 6. vendor-specific properties
> 7. status (if applicable)
>
Rest looks fine, thanks.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] firmware: arm_ffa: support running as a guest in a vm
From: Jens Wiklander @ 2024-03-25 8:13 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Sudeep Holla, Marc Bonnici, Olivier Deprez, Lorenzo Pieralisi,
Bertrand Marquis, Jens Wiklander
Add support for running the driver in a guest to a hypervisor. The main
difference is introducing notification pending interrupt and that
FFA_NOTIFICATION_BITMAP_CREATE doesn't need to be called.
The guest may need to use a notification pending interrupt instead of or
in addition to the schedule receiver interrupt.
FFA_FEAT_NOTIFICATION_PENDING_INT gives the interrupt the hypervisor has
chosen to notify its guest of pending notifications.
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
---
Hi,
I've tested this with Xen with as hypervisor (Xen patches to be posted) and
the NPI handler delivers notifications as expected using
FFA_NOTIFICATION_GET. I've also tested without a hypervisor to see that the
SRI handler still works as expected.
Thanks,
Jens
v1->v2:
* Adds a Notification Pending Interrupt handler to retrieve notifications
using for the interrupted CPU.
* The original Schedule Receiver Interrupt handler is initialized in parallel
depending on whether FFA_FEAT_SCHEDULE_RECEIVER_INT is available.
drivers/firmware/arm_ffa/driver.c | 117 +++++++++++++++++++++---------
1 file changed, 82 insertions(+), 35 deletions(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index f2556a8e9401..9732f0066c70 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -101,11 +101,12 @@ struct ffa_drv_info {
bool bitmap_created;
bool notif_enabled;
unsigned int sched_recv_irq;
+ unsigned int notif_pend_irq;
unsigned int cpuhp_state;
struct ffa_pcpu_irq __percpu *irq_pcpu;
struct workqueue_struct *notif_pcpu_wq;
struct work_struct notif_pcpu_work;
- struct work_struct irq_work;
+ struct work_struct sched_recv_irq_work;
struct xarray partition_info;
DECLARE_HASHTABLE(notifier_hash, ilog2(FFA_MAX_NOTIFICATIONS));
struct mutex notify_lock; /* lock to protect notifier hashtable */
@@ -1291,12 +1292,23 @@ static void ffa_partitions_cleanup(void)
#define FFA_FEAT_SCHEDULE_RECEIVER_INT (2)
#define FFA_FEAT_MANAGED_EXIT_INT (3)
-static irqreturn_t irq_handler(int irq, void *irq_data)
+static irqreturn_t sched_recv_irq_handler(int irq, void *irq_data)
{
struct ffa_pcpu_irq *pcpu = irq_data;
struct ffa_drv_info *info = pcpu->info;
- queue_work(info->notif_pcpu_wq, &info->irq_work);
+ queue_work(info->notif_pcpu_wq, &info->sched_recv_irq_work);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t notif_pend_irq_handler(int irq, void *irq_data)
+{
+ struct ffa_pcpu_irq *pcpu = irq_data;
+ struct ffa_drv_info *info = pcpu->info;
+
+ queue_work_on(smp_processor_id(), info->notif_pcpu_wq,
+ &info->notif_pcpu_work);
return IRQ_HANDLED;
}
@@ -1306,15 +1318,16 @@ static void ffa_sched_recv_irq_work_fn(struct work_struct *work)
ffa_notification_info_get();
}
-static int ffa_sched_recv_irq_map(void)
+static int ffa_irq_map(u32 id)
{
- int ret, irq, sr_intid;
+ int ret, irq, intid;
- /* The returned sr_intid is assumed to be SGI donated to NS world */
- ret = ffa_features(FFA_FEAT_SCHEDULE_RECEIVER_INT, 0, &sr_intid, NULL);
+ /* The returned intid is assumed to be SGI donated to NS world */
+ ret = ffa_features(id, 0, &intid, NULL);
if (ret < 0) {
+ pr_err("Failed to retrieve FF-A id %u interrupt\n", id);
if (ret != -EOPNOTSUPP)
- pr_err("Failed to retrieve scheduler Rx interrupt\n");
+ pr_err("Failed to retrieve FF-A id %u interrupt\n", id);
return ret;
}
@@ -1329,12 +1342,12 @@ static int ffa_sched_recv_irq_map(void)
oirq.np = gic;
oirq.args_count = 1;
- oirq.args[0] = sr_intid;
+ oirq.args[0] = intid;
irq = irq_create_of_mapping(&oirq);
of_node_put(gic);
#ifdef CONFIG_ACPI
} else {
- irq = acpi_register_gsi(NULL, sr_intid, ACPI_EDGE_SENSITIVE,
+ irq = acpi_register_gsi(NULL, intid, ACPI_EDGE_SENSITIVE,
ACPI_ACTIVE_HIGH);
#endif
}
@@ -1355,15 +1368,29 @@ static void ffa_sched_recv_irq_unmap(void)
}
}
+static void ffa_notif_pend_irq_unmap(void)
+{
+ if (drv_info->notif_pend_irq) {
+ irq_dispose_mapping(drv_info->notif_pend_irq);
+ drv_info->notif_pend_irq = 0;
+ }
+}
+
static int ffa_cpuhp_pcpu_irq_enable(unsigned int cpu)
{
- enable_percpu_irq(drv_info->sched_recv_irq, IRQ_TYPE_NONE);
+ if (drv_info->sched_recv_irq)
+ enable_percpu_irq(drv_info->sched_recv_irq, IRQ_TYPE_NONE);
+ if (drv_info->notif_pend_irq)
+ enable_percpu_irq(drv_info->notif_pend_irq, IRQ_TYPE_NONE);
return 0;
}
static int ffa_cpuhp_pcpu_irq_disable(unsigned int cpu)
{
- disable_percpu_irq(drv_info->sched_recv_irq);
+ if (drv_info->sched_recv_irq)
+ disable_percpu_irq(drv_info->sched_recv_irq);
+ if (drv_info->notif_pend_irq)
+ disable_percpu_irq(drv_info->notif_pend_irq);
return 0;
}
@@ -1382,13 +1409,16 @@ static void ffa_uninit_pcpu_irq(void)
if (drv_info->sched_recv_irq)
free_percpu_irq(drv_info->sched_recv_irq, drv_info->irq_pcpu);
+ if (drv_info->notif_pend_irq)
+ free_percpu_irq(drv_info->notif_pend_irq, drv_info->irq_pcpu);
+
if (drv_info->irq_pcpu) {
free_percpu(drv_info->irq_pcpu);
drv_info->irq_pcpu = NULL;
}
}
-static int ffa_init_pcpu_irq(unsigned int irq)
+static int ffa_init_pcpu_irq(void)
{
struct ffa_pcpu_irq __percpu *irq_pcpu;
int ret, cpu;
@@ -1402,13 +1432,29 @@ static int ffa_init_pcpu_irq(unsigned int irq)
drv_info->irq_pcpu = irq_pcpu;
- ret = request_percpu_irq(irq, irq_handler, "ARM-FFA", irq_pcpu);
- if (ret) {
- pr_err("Error registering notification IRQ %d: %d\n", irq, ret);
- return ret;
+ if (drv_info->sched_recv_irq) {
+ ret = request_percpu_irq(drv_info->sched_recv_irq,
+ sched_recv_irq_handler,
+ "ARM-FFA-SR", irq_pcpu);
+ if (ret) {
+ pr_err("Error registering schedule receiver nIRQ %d: %d\n",
+ drv_info->sched_recv_irq, ret);
+ return ret;
+ }
+ }
+
+ if (drv_info->notif_pend_irq) {
+ ret = request_percpu_irq(drv_info->notif_pend_irq,
+ notif_pend_irq_handler,
+ "ARM-FFA-NP", irq_pcpu);
+ if (ret) {
+ pr_err("Error registering notification pendig nIRQ %d: %d\n",
+ drv_info->notif_pend_irq, ret);
+ return ret;
+ }
}
- INIT_WORK(&drv_info->irq_work, ffa_sched_recv_irq_work_fn);
+ INIT_WORK(&drv_info->sched_recv_irq_work, ffa_sched_recv_irq_work_fn);
INIT_WORK(&drv_info->notif_pcpu_work, notif_pcpu_irq_work_fn);
drv_info->notif_pcpu_wq = create_workqueue("ffa_pcpu_irq_notification");
if (!drv_info->notif_pcpu_wq)
@@ -1429,6 +1475,7 @@ static void ffa_notifications_cleanup(void)
{
ffa_uninit_pcpu_irq();
ffa_sched_recv_irq_unmap();
+ ffa_notif_pend_irq_unmap();
if (drv_info->bitmap_created) {
ffa_notification_bitmap_destroy();
@@ -1439,30 +1486,30 @@ static void ffa_notifications_cleanup(void)
static void ffa_notifications_setup(void)
{
- int ret, irq;
+ int ret;
ret = ffa_features(FFA_NOTIFICATION_BITMAP_CREATE, 0, NULL, NULL);
- if (ret) {
- pr_info("Notifications not supported, continuing with it ..\n");
- return;
+ if (!ret) {
+ ret = ffa_notification_bitmap_create();
+ if (ret) {
+ pr_info("Notification bitmap create error %d\n", ret);
+ return;
+ }
+ drv_info->bitmap_created = true;
}
- ret = ffa_notification_bitmap_create();
- if (ret) {
- pr_info("Notification bitmap create error %d\n", ret);
- return;
- }
- drv_info->bitmap_created = true;
+ ret = ffa_irq_map(FFA_FEAT_SCHEDULE_RECEIVER_INT);
+ if (ret > 0)
+ drv_info->sched_recv_irq = ret;
- irq = ffa_sched_recv_irq_map();
- if (irq <= 0) {
- ret = irq;
- goto cleanup;
- }
+ ret = ffa_irq_map(FFA_FEAT_NOTIFICATION_PENDING_INT);
+ if (ret > 0)
+ drv_info->notif_pend_irq = ret;
- drv_info->sched_recv_irq = irq;
+ if (!drv_info->sched_recv_irq && !drv_info->notif_pend_irq)
+ goto cleanup;
- ret = ffa_init_pcpu_irq(irq);
+ ret = ffa_init_pcpu_irq();
if (ret)
goto cleanup;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 37/64] i2c: mt7621: reword according to newest specification
From: Stefan Roese @ 2024-03-25 8:07 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: Andi Shyti, Matthias Brugger, AngeloGioacchino Del Regno,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20240322132619.6389-38-wsa+renesas@sang-engineering.com>
On 3/22/24 14:25, Wolfram Sang wrote:
> Match the wording of this driver wrt. the newest I2C v7, SMBus 3.2, I3C
> specifications and replace "master/slave" with more appropriate terms.
> They are also more specific because we distinguish now between a remote
> entity ("client") and a local one ("target").
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Thanks,
Stefan
> ---
> drivers/i2c/busses/i2c-mt7621.c | 22 +++++++++++-----------
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt7621.c b/drivers/i2c/busses/i2c-mt7621.c
> index 81d46169bc1f..c567a2cf4a90 100644
> --- a/drivers/i2c/busses/i2c-mt7621.c
> +++ b/drivers/i2c/busses/i2c-mt7621.c
> @@ -117,26 +117,26 @@ static int mtk_i2c_check_ack(struct mtk_i2c *i2c, u32 expected)
> return ((ack & ack_expected) == ack_expected) ? 0 : -ENXIO;
> }
>
> -static int mtk_i2c_master_start(struct mtk_i2c *i2c)
> +static int mtk_i2c_host_start(struct mtk_i2c *i2c)
> {
> iowrite32(SM0CTL1_START | SM0CTL1_TRI, i2c->base + REG_SM0CTL1_REG);
> return mtk_i2c_wait_idle(i2c);
> }
>
> -static int mtk_i2c_master_stop(struct mtk_i2c *i2c)
> +static int mtk_i2c_host_stop(struct mtk_i2c *i2c)
> {
> iowrite32(SM0CTL1_STOP | SM0CTL1_TRI, i2c->base + REG_SM0CTL1_REG);
> return mtk_i2c_wait_idle(i2c);
> }
>
> -static int mtk_i2c_master_cmd(struct mtk_i2c *i2c, u32 cmd, int page_len)
> +static int mtk_i2c_host_cmd(struct mtk_i2c *i2c, u32 cmd, int page_len)
> {
> iowrite32(cmd | SM0CTL1_TRI | SM0CTL1_PGLEN(page_len),
> i2c->base + REG_SM0CTL1_REG);
> return mtk_i2c_wait_idle(i2c);
> }
>
> -static int mtk_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> +static int mtk_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> int num)
> {
> struct mtk_i2c *i2c;
> @@ -157,7 +157,7 @@ static int mtk_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> goto err_timeout;
>
> /* start sequence */
> - ret = mtk_i2c_master_start(i2c);
> + ret = mtk_i2c_host_start(i2c);
> if (ret)
> goto err_timeout;
>
> @@ -169,14 +169,14 @@ static int mtk_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> if (pmsg->flags & I2C_M_RD)
> addr |= 1;
> iowrite32(addr, i2c->base + REG_SM0D0_REG);
> - ret = mtk_i2c_master_cmd(i2c, SM0CTL1_WRITE, 2);
> + ret = mtk_i2c_host_cmd(i2c, SM0CTL1_WRITE, 2);
> if (ret)
> goto err_timeout;
> } else {
> /* 7 bits address */
> addr = i2c_8bit_addr_from_msg(pmsg);
> iowrite32(addr, i2c->base + REG_SM0D0_REG);
> - ret = mtk_i2c_master_cmd(i2c, SM0CTL1_WRITE, 1);
> + ret = mtk_i2c_host_cmd(i2c, SM0CTL1_WRITE, 1);
> if (ret)
> goto err_timeout;
> }
> @@ -202,7 +202,7 @@ static int mtk_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> cmd = SM0CTL1_WRITE;
> }
>
> - ret = mtk_i2c_master_cmd(i2c, cmd, page_len);
> + ret = mtk_i2c_host_cmd(i2c, cmd, page_len);
> if (ret)
> goto err_timeout;
>
> @@ -222,7 +222,7 @@ static int mtk_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> }
> }
>
> - ret = mtk_i2c_master_stop(i2c);
> + ret = mtk_i2c_host_stop(i2c);
> if (ret)
> goto err_timeout;
>
> @@ -230,7 +230,7 @@ static int mtk_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> return i;
>
> err_ack:
> - ret = mtk_i2c_master_stop(i2c);
> + ret = mtk_i2c_host_stop(i2c);
> if (ret)
> goto err_timeout;
> return -ENXIO;
> @@ -247,7 +247,7 @@ static u32 mtk_i2c_func(struct i2c_adapter *a)
> }
>
> static const struct i2c_algorithm mtk_i2c_algo = {
> - .master_xfer = mtk_i2c_master_xfer,
> + .xfer = mtk_i2c_xfer,
> .functionality = mtk_i2c_func,
> };
>
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 37/64] i2c: mt7621: reword according to newest specification
From: AngeloGioacchino Del Regno @ 2024-03-25 8:06 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: Stefan Roese, Andi Shyti, Matthias Brugger, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20240322132619.6389-38-wsa+renesas@sang-engineering.com>
Il 22/03/24 14:25, Wolfram Sang ha scritto:
> Match the wording of this driver wrt. the newest I2C v7, SMBus 3.2, I3C
> specifications and replace "master/slave" with more appropriate terms.
> They are also more specific because we distinguish now between a remote
> entity ("client") and a local one ("target").
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: stm32: move can3 node from stm32f746 to stm32f769
From: Dario Binacchi @ 2024-03-25 7:56 UTC (permalink / raw)
To: linux-kernel
Cc: linux-amarula, Dario Binacchi, Alexandre Torgue, Conor Dooley,
Krzysztof Kozlowski, Maxime Coquelin, Rob Herring, devicetree,
linux-arm-kernel, linux-stm32
According to documents [1], [2] and [3], we have 2 CAN devices on the
stm32f746 platform and 3 on the stm32f769 platform. So let's move the
can3 node from stm32f746.dtsi to stm32f769.dtsi.
[1] https://www.st.com/en/microcontrollers-microprocessors/stm32f7-series.html
[2] RM0385: STM32F75xxx and STM32F74xxx advanced Arm®-based 32-bit MCUs
[3] RM0410: STM32F76xxx and STM32F77xxx advanced Arm®-based 32-bit MCUs
Fixes: df362914eead ("ARM: dts: stm32: re-add CAN support on stm32f746")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
arch/arm/boot/dts/st/stm32f746.dtsi | 17 -----------------
arch/arm/boot/dts/st/stm32f769.dtsi | 17 +++++++++++++++++
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/st/stm32f746.dtsi b/arch/arm/boot/dts/st/stm32f746.dtsi
index 65c72b6fcc83..2537b3d47e6f 100644
--- a/arch/arm/boot/dts/st/stm32f746.dtsi
+++ b/arch/arm/boot/dts/st/stm32f746.dtsi
@@ -257,23 +257,6 @@ rtc: rtc@40002800 {
status = "disabled";
};
- can3: can@40003400 {
- compatible = "st,stm32f4-bxcan";
- reg = <0x40003400 0x200>;
- interrupts = <104>, <105>, <106>, <107>;
- interrupt-names = "tx", "rx0", "rx1", "sce";
- resets = <&rcc STM32F7_APB1_RESET(CAN3)>;
- clocks = <&rcc 0 STM32F7_APB1_CLOCK(CAN3)>;
- st,gcan = <&gcan3>;
- status = "disabled";
- };
-
- gcan3: gcan@40003600 {
- compatible = "st,stm32f4-gcan", "syscon";
- reg = <0x40003600 0x200>;
- clocks = <&rcc 0 STM32F7_APB1_CLOCK(CAN3)>;
- };
-
spi2: spi@40003800 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/st/stm32f769.dtsi b/arch/arm/boot/dts/st/stm32f769.dtsi
index 4e7d9032149c..e8cbb99e81a6 100644
--- a/arch/arm/boot/dts/st/stm32f769.dtsi
+++ b/arch/arm/boot/dts/st/stm32f769.dtsi
@@ -7,6 +7,23 @@
/ {
soc {
+ can3: can@40003400 {
+ compatible = "st,stm32f4-bxcan";
+ reg = <0x40003400 0x200>;
+ interrupts = <104>, <105>, <106>, <107>;
+ interrupt-names = "tx", "rx0", "rx1", "sce";
+ resets = <&rcc STM32F7_APB1_RESET(CAN3)>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(CAN3)>;
+ st,gcan = <&gcan3>;
+ status = "disabled";
+ };
+
+ gcan3: gcan@40003600 {
+ compatible = "st,stm32f4-gcan", "syscon";
+ reg = <0x40003600 0x200>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(CAN3)>;
+ };
+
dsi: dsi@40016c00 {
compatible = "st,stm32-dsi";
reg = <0x40016c00 0x800>;
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 3/4] dt-bindings: mmc: fsl-imx-esdhc: add NXP S32G3 support
From: Krzysztof Kozlowski @ 2024-03-25 7:54 UTC (permalink / raw)
To: Wadim Mueller
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Greg Kroah-Hartman, Jiri Slaby, Chester Lin,
Andreas Färber, Matthias Brugger, NXP S32 Linux Team,
Tim Harvey, Alexander Stein, Gregor Herburger, Marek Vasut,
Marco Felsch, Hugo Villeneuve, Markus Niebel, Matthias Schiffer,
Stefan Wahren, Bjorn Helgaas, Yannic Moog, Li Yang, devicetree,
linux-kernel, linux-mmc, linux-arm-kernel, linux-serial
In-Reply-To: <20240324214329.29988-4-wafgo01@gmail.com>
On 24/03/2024 22:43, Wadim Mueller wrote:
> Add a compatible string for the SDHC binding of NXP S32G3 platforms. Here
> we use "nxp,s32g2-usdhc" as fallback since the s32g2-usdhc
> driver works also on S32G3 platforms.
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: serial: fsl-linflexuart: add compatible for S32G3
From: Krzysztof Kozlowski @ 2024-03-25 7:53 UTC (permalink / raw)
To: Wadim Mueller
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Greg Kroah-Hartman, Jiri Slaby, Chester Lin,
Andreas Färber, Matthias Brugger, NXP S32 Linux Team,
Tim Harvey, Marco Felsch, Gregor Herburger, Marek Vasut,
Joao Paulo Goncalves, Markus Niebel, Matthias Schiffer,
Stefan Wahren, Bjorn Helgaas, Philippe Schenker, Yannic Moog,
Li Yang, devicetree, linux-kernel, linux-mmc, linux-arm-kernel,
linux-serial
In-Reply-To: <20240324214329.29988-3-wafgo01@gmail.com>
On 24/03/2024 22:43, Wadim Mueller wrote:
> Add a compatible string for the uart binding of NXP S32G3 platforms. Here
> we use "s32v234-linflexuart" as fallback since the current linflexuart
> driver can still work on S32G3.
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: rockchip: disable analog audio for rock-5b
From: Krzysztof Kozlowski @ 2024-03-25 7:48 UTC (permalink / raw)
To: Pratham Patel
Cc: robh, krzysztof.kozlowski+dt, conor+dt, heiko, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <TbQeSy-AWAKVHo2Alb8hXUvplVNvohDJ2ztRM1x3Fo5PMmGLMsJxtHR-OIms9FlUshfUD9x45EghBCB9gVtcUPlxeMRUJQ_C95DVhu3AJrk=@thefossguy.com>
On 24/03/2024 12:21, Pratham Patel wrote:
> On Sunday, March 24th, 2024 at 16:15, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>
>>
>>
>> On 24/03/2024 07:28, Pratham Patel wrote:
>>
>>> The addition of `of: property: fw_devlink: Fix stupid bug in remote-endpoint parsing`
>>
>>
>> Please refer to commits using commit sha () syntax, as mentioned in
>> submitting patches.
>
> Noticed that in the wiki but didn't do that since the commit hash for the commit
> was different in each branch (of the stable tree). Maybe I should have copied the SHA
> from Linus' tree. I will do that.
There is only one tree: master/mainline tree. Commits in stable do not
matter outside of stable.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx7-mba7: Remove invalid 'no-emmc' property
From: Alexander Stein @ 2024-03-25 7:47 UTC (permalink / raw)
To: shawnguo, Fabio Estevam; +Cc: linux-arm-kernel, Fabio Estevam
In-Reply-To: <20240321182122.1150614-1-festevam@gmail.com>
Hi Fabio,
thanks for addressing the warning.
Am Donnerstag, 21. März 2024, 19:21:22 CET schrieb Fabio Estevam:
> From: Fabio Estevam <festevam@denx.de>
>
> 'no-emmc' is not a valid property.
>
> Remove it to fix the following dt-schema warning:
>
> imx7s-mba7.dtb: mmc@30b40000: Unevaluated properties are not allowed ('no-emmc' was unexpected)
>
> Fixes: d430a7e0e181 ("ARM: dts: imx7-mba7: restrict usdhc interface modes")
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
> index 1235a71c6abe..16bdc76ba4fd 100644
> --- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
> +++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
> @@ -666,7 +666,6 @@ &usdhc1 {
> bus-width = <4>;
> no-1-8-v;
> no-sdio;
> - no-emmc;
This should be changed to 'no-mmc' instead.
Thanks and best regards,
Alexander
> status = "okay";
> };
>
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] virtio_ring: Fix the stale index in available ring
From: Gavin Shan @ 2024-03-25 7:34 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Will Deacon, virtualization, linux-kernel, jasowang, xuanzhuo,
yihyu, shan.gavin, linux-arm-kernel, Catalin Marinas, mochs
In-Reply-To: <20240320030215-mutt-send-email-mst@kernel.org>
On 3/20/24 17:14, Michael S. Tsirkin wrote:
> On Wed, Mar 20, 2024 at 03:24:16PM +1000, Gavin Shan wrote:
>> On 3/20/24 10:49, Michael S. Tsirkin wrote:>
>>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
>>> index 6f7e5010a673..79456706d0bd 100644
>>> --- a/drivers/virtio/virtio_ring.c
>>> +++ b/drivers/virtio/virtio_ring.c
>>> @@ -685,7 +685,8 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
>>> /* Put entry in available array (but don't update avail->idx until they
>>> * do sync). */
>>> avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1);
>>> - vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, head);
>>> + u16 headwithflag = head | (q->split.avail_idx_shadow & ~(vq->split.vring.num - 1));
>>> + vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, headwithflag);
>>> /* Descriptors and available array need to be set before we expose the
>>> * new available array entries. */
>>>
Ok, Michael. I continued with my debugging code. It still looks like a
hardware bug on NVidia's grace-hopper. I really think NVidia needs to be
involved for the discussion, as suggested by you.
Firstly, I bind the vhost process and vCPU thread to CPU#71 and CPU#70.
Note that I have only one vCPU in my configuration.
Secondly, the debugging code is enhanced so that the available head for
(last_avail_idx - 1) is read for twice and recorded. It means the available
head for one specific available index is read for twice. I do see the
available heads are different from the consecutive reads. More details
are shared as below.
From the guest side
===================
virtio_net virtio0: output.0:id 86 is not a head!
head to be released: 047 062 112
avail_idx:
000 49665
001 49666 <--
:
015 49664
avail_head:
000 062
001 047 <--
:
015 112
From the host side
==================
avail_idx
000 49663
001 49666 <---
:
avail_head
000 062 (062)
001 047 (047) <---
:
015 086 (112) // head 086 is returned from the first read,
// but head 112 is returned from the second read
vhost_get_vq_desc: Inconsistent head in two read (86 -> 112) for avail_idx 49664
Thanks,
Gavin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] clk: samsung: exynos850: fix propagation of SPI IPCLK rate
From: Tudor Ambarus @ 2024-03-25 7:15 UTC (permalink / raw)
To: Sam Protsenko
Cc: 김재원/JAEWON KIM, krzysztof.kozlowski,
s.nawrocki, cw00.choi, alim.akhtar, mturquette, sboyd,
peter.griffin, andre.draszik, linux-samsung-soc, linux-clk,
linux-arm-kernel, linux-kernel, willmcvicker, kernel-team
In-Reply-To: <CAPLW+4=nRjRPdu80Y3izifxQDNUaJymU3di0hGErm1dHry3EfQ@mail.gmail.com>
On 3/22/24 18:09, Sam Protsenko wrote:
> Yes, please leave Exynos850 out of it, if possible.
Sure, Sam, thanks for the feedback!
Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4] PCI: keystone: Fix pci_ops for AM654x SoC
From: Siddharth Vadapalli @ 2024-03-25 5:37 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, manivannan.sadhasivam,
fancer.lancer, u.kleine-koenig, cassel, dlemoal,
yoshihiro.shimoda.uh
Cc: linux-pci, linux-kernel, linux-arm-kernel, srk, s-vadapalli
In the process of converting .scan_bus() callbacks to .add_bus(), the
ks_pcie_v3_65_scan_bus() function was changed to ks_pcie_v3_65_add_bus().
The .scan_bus() method belonged to ks_pcie_host_ops which was specific
to controller version 3.65a, while the .add_bus() method had been added
to ks_pcie_ops which is shared between the controller versions 3.65a and
4.90a. Neither the older ks_pcie_v3_65_scan_bus() method, nor the newer
ks_pcie_v3_65_add_bus() method are applicable to the controller version
4.90a which is present in AM654x SoCs.
Thus, as a fix, move the contents of "ks_pcie_v3_65_add_bus()" to the
.host_init callback "ks_pcie_host_init()" and execute it only for non
AM654x SoC devices which have the v3.65a DWC PCIe IP Controllers.
Fixes: 6ab15b5e7057 ("PCI: dwc: keystone: Convert .scan_bus() callback to use add_bus")
Suggested-by: Serge Semin <fancer.lancer@gmail.com>
Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
---
Hello,
This patch is based on linux-next tagged next-20240325.
This patch is technically the next version for the v3 patch at:
https://patchwork.kernel.org/project/linux-pci/patch/20231019081330.2975470-1-s-vadapalli@ti.com/
but the implementation is based on the RFC patch at:
https://patchwork.kernel.org/project/linux-pci/patch/20231027084159.4166188-1-s-vadapalli@ti.com/
Since the RFC patch mentioned above fixes the same issue being
fixed by the v3 patch, I have dropped the v3 patch and am using
the RFC patch since it is a cleaner implementation and was discussed at:
https://lore.kernel.org/r/20231019220847.GA1413474@bhelgaas/
Regards,
Siddharth.
drivers/pci/controller/dwc/pci-keystone.c | 51 ++++++++---------------
1 file changed, 17 insertions(+), 34 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index 844de4418724..f45bdeac520a 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -445,44 +445,10 @@ static struct pci_ops ks_child_pcie_ops = {
.write = pci_generic_config_write,
};
-/**
- * ks_pcie_v3_65_add_bus() - keystone add_bus post initialization
- * @bus: A pointer to the PCI bus structure.
- *
- * This sets BAR0 to enable inbound access for MSI_IRQ register
- */
-static int ks_pcie_v3_65_add_bus(struct pci_bus *bus)
-{
- struct dw_pcie_rp *pp = bus->sysdata;
- struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
- struct keystone_pcie *ks_pcie = to_keystone_pcie(pci);
-
- if (!pci_is_root_bus(bus))
- return 0;
-
- /* Configure and set up BAR0 */
- ks_pcie_set_dbi_mode(ks_pcie);
-
- /* Enable BAR0 */
- dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 1);
- dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, SZ_4K - 1);
-
- ks_pcie_clear_dbi_mode(ks_pcie);
-
- /*
- * For BAR0, just setting bus address for inbound writes (MSI) should
- * be sufficient. Use physical address to avoid any conflicts.
- */
- dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, ks_pcie->app.start);
-
- return 0;
-}
-
static struct pci_ops ks_pcie_ops = {
.map_bus = dw_pcie_own_conf_map_bus,
.read = pci_generic_config_read,
.write = pci_generic_config_write,
- .add_bus = ks_pcie_v3_65_add_bus,
};
/**
@@ -822,6 +788,23 @@ static int __init ks_pcie_host_init(struct dw_pcie_rp *pp)
if (ret < 0)
return ret;
+ if (!ks_pcie->is_am6) {
+ /* Configure and set up BAR0 */
+ ks_pcie_set_dbi_mode(ks_pcie);
+
+ /* Enable BAR0 */
+ dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 1);
+ dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, SZ_4K - 1);
+
+ ks_pcie_clear_dbi_mode(ks_pcie);
+
+ /*
+ * For BAR0, just setting bus address for inbound writes (MSI) should
+ * be sufficient. Use physical address to avoid any conflicts.
+ */
+ dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, ks_pcie->app.start);
+ }
+
#ifdef CONFIG_ARM
/*
* PCIe access errors that result into OCP errors are caught by ARM as
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] video: fbdev: replace of_graph_get_next_endpoint()
From: Helge Deller @ 2024-03-25 4:50 UTC (permalink / raw)
To: Kuninori Morimoto, Uwe Kleine-König, Alexey Brodkin,
Daniel Vetter, David Airlie, Florian Fainelli, Maarten Lankhorst,
Maxime Ripard, Neil Armstrong, Rob Herring, Thomas Zimmermann,
dri-devel, linux-arm-kernel, linux-fbdev, linux-omap,
linux-rpi-kernel
In-Reply-To: <874jcv6msn.wl-kuninori.morimoto.gx@renesas.com>
On 3/25/24 03:57, Kuninori Morimoto wrote:
> From DT point of view, in general, drivers should be asking for a
> specific port number because their function is fixed in the binding.
>
> of_graph_get_next_endpoint() doesn't match to this concept.
>
> Simply replace
>
> - of_graph_get_next_endpoint(xxx, NULL);
> + of_graph_get_endpoint_by_regs(xxx, 0, -1);
>
> Link: https://lore.kernel.org/r/20240202174941.GA310089-robh@kernel.org
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
applied to fbdev git tree.
Thanks!
Helge
> ---
> drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 3 ++-
> drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 20 +------------------
> drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 3 ++-
> drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 3 ++-
> drivers/video/fbdev/omap2/omapfb/dss/venc.c | 3 ++-
> drivers/video/fbdev/pxafb.c | 2 +-
> include/video/omapfb_dss.h | 3 ---
> 7 files changed, 10 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> index b7eb17a16ec4..1f13bcf73da5 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> @@ -28,6 +28,7 @@
> #include <linux/debugfs.h>
> #include <linux/pm_runtime.h>
> #include <linux/of.h>
> +#include <linux/of_graph.h>
> #include <linux/of_platform.h>
> #include <linux/component.h>
>
> @@ -5079,7 +5080,7 @@ static int dsi_probe_of(struct platform_device *pdev)
> struct device_node *ep;
> struct omap_dsi_pin_config pin_cfg;
>
> - ep = omapdss_of_get_first_endpoint(node);
> + ep = of_graph_get_endpoint_by_regs(node, 0, -1);
> if (!ep)
> return 0;
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
> index 0282d4eef139..14965a3fd05b 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
> @@ -130,24 +130,6 @@ static struct device_node *omapdss_of_get_remote_port(const struct device_node *
> return np;
> }
>
> -struct device_node *
> -omapdss_of_get_first_endpoint(const struct device_node *parent)
> -{
> - struct device_node *port, *ep;
> -
> - port = omapdss_of_get_next_port(parent, NULL);
> -
> - if (!port)
> - return NULL;
> -
> - ep = omapdss_of_get_next_endpoint(port, NULL);
> -
> - of_node_put(port);
> -
> - return ep;
> -}
> -EXPORT_SYMBOL_GPL(omapdss_of_get_first_endpoint);
> -
> struct omap_dss_device *
> omapdss_of_find_source_for_first_ep(struct device_node *node)
> {
> @@ -155,7 +137,7 @@ omapdss_of_find_source_for_first_ep(struct device_node *node)
> struct device_node *src_port;
> struct omap_dss_device *src;
>
> - ep = omapdss_of_get_first_endpoint(node);
> + ep = of_graph_get_endpoint_by_regs(node, 0, -1);
> if (!ep)
> return ERR_PTR(-EINVAL);
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> index f05b4e35a842..8f407ec134dc 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> @@ -20,6 +20,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/clk.h>
> #include <linux/of.h>
> +#include <linux/of_graph.h>
> #include <linux/regulator/consumer.h>
> #include <linux/component.h>
> #include <video/omapfb_dss.h>
> @@ -529,7 +530,7 @@ static int hdmi_probe_of(struct platform_device *pdev)
> struct device_node *ep;
> int r;
>
> - ep = omapdss_of_get_first_endpoint(node);
> + ep = of_graph_get_endpoint_by_regs(node, 0, -1);
> if (!ep)
> return 0;
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
> index 03292945b1d4..4ad219f522b9 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
> @@ -25,6 +25,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/clk.h>
> #include <linux/of.h>
> +#include <linux/of_graph.h>
> #include <linux/regulator/consumer.h>
> #include <linux/component.h>
> #include <video/omapfb_dss.h>
> @@ -561,7 +562,7 @@ static int hdmi_probe_of(struct platform_device *pdev)
> struct device_node *ep;
> int r;
>
> - ep = omapdss_of_get_first_endpoint(node);
> + ep = of_graph_get_endpoint_by_regs(node, 0, -1);
> if (!ep)
> return 0;
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> index c9d40e28a06f..0bd80d3b8f1b 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> @@ -24,6 +24,7 @@
> #include <linux/regulator/consumer.h>
> #include <linux/pm_runtime.h>
> #include <linux/of.h>
> +#include <linux/of_graph.h>
> #include <linux/component.h>
>
> #include <video/omapfb_dss.h>
> @@ -764,7 +765,7 @@ static int venc_probe_of(struct platform_device *pdev)
> u32 channels;
> int r;
>
> - ep = omapdss_of_get_first_endpoint(node);
> + ep = of_graph_get_endpoint_by_regs(node, 0, -1);
> if (!ep)
> return 0;
>
> diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
> index fa943612c4e2..2ef56fa28aff 100644
> --- a/drivers/video/fbdev/pxafb.c
> +++ b/drivers/video/fbdev/pxafb.c
> @@ -2171,7 +2171,7 @@ static int of_get_pxafb_mode_info(struct device *dev,
> u32 bus_width;
> int ret, i;
>
> - np = of_graph_get_next_endpoint(dev->of_node, NULL);
> + np = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
> if (!np) {
> dev_err(dev, "could not find endpoint\n");
> return -EINVAL;
> diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
> index e8eaac2cb7b8..a8c0c3eeeb5b 100644
> --- a/include/video/omapfb_dss.h
> +++ b/include/video/omapfb_dss.h
> @@ -819,9 +819,6 @@ struct device_node *
> omapdss_of_get_next_endpoint(const struct device_node *parent,
> struct device_node *prev);
>
> -struct device_node *
> -omapdss_of_get_first_endpoint(const struct device_node *parent);
> -
> struct omap_dss_device *
> omapdss_of_find_source_for_first_ep(struct device_node *node);
> #else
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 00/15] mm/memory: optimize fork() with PTE-mapped THP
From: patchwork-bot+linux-riscv @ 2024-03-25 4:42 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-riscv, linux-kernel, linux-mm, akpm, willy, ryan.roberts,
linux, catalin.marinas, will, dinguyen, mpe, npiggin,
christophe.leroy, aneesh.kumar, naveen.n.rao, paul.walmsley,
palmer, aou, agordeev, gerald.schaefer, hca, gor, borntraeger,
svens, davem, linux-arm-kernel, linuxppc-dev, linux-s390,
sparclinux
In-Reply-To: <20240129124649.189745-1-david@redhat.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Mon, 29 Jan 2024 13:46:34 +0100 you wrote:
> Now that the rmap overhaul[1] is upstream that provides a clean interface
> for rmap batching, let's implement PTE batching during fork when processing
> PTE-mapped THPs.
>
> This series is partially based on Ryan's previous work[2] to implement
> cont-pte support on arm64, but its a complete rewrite based on [1] to
> optimize all architectures independent of any such PTE bits, and to
> use the new rmap batching functions that simplify the code and prepare
> for further rmap accounting changes.
>
> [...]
Here is the summary with links:
- [v3,01/15] arm64/mm: Make set_ptes() robust when OAs cross 48-bit boundary
(no matching commit)
- [v3,02/15] arm/pgtable: define PFN_PTE_SHIFT
(no matching commit)
- [v3,03/15] nios2/pgtable: define PFN_PTE_SHIFT
(no matching commit)
- [v3,04/15] powerpc/pgtable: define PFN_PTE_SHIFT
(no matching commit)
- [v3,05/15] riscv/pgtable: define PFN_PTE_SHIFT
https://git.kernel.org/riscv/c/57c254b2fb31
- [v3,06/15] s390/pgtable: define PFN_PTE_SHIFT
(no matching commit)
- [v3,07/15] sparc/pgtable: define PFN_PTE_SHIFT
(no matching commit)
- [v3,08/15] mm/pgtable: make pte_next_pfn() independent of set_ptes()
(no matching commit)
- [v3,09/15] arm/mm: use pte_next_pfn() in set_ptes()
(no matching commit)
- [v3,10/15] powerpc/mm: use pte_next_pfn() in set_ptes()
(no matching commit)
- [v3,11/15] mm/memory: factor out copying the actual PTE in copy_present_pte()
(no matching commit)
- [v3,12/15] mm/memory: pass PTE to copy_present_pte()
(no matching commit)
- [v3,13/15] mm/memory: optimize fork() with PTE-mapped THP
(no matching commit)
- [v3,14/15] mm/memory: ignore dirty/accessed/soft-dirty bits in folio_pte_batch()
(no matching commit)
- [v3,15/15] mm/memory: ignore writable bit in folio_pte_batch()
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arch/arm/mm: fix major fault accounting when retrying under per-VMA lock
From: patchwork-bot+linux-riscv @ 2024-03-25 4:42 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: linux-riscv, akpm, willy, will, catalin.marinas, palmer, mpe,
christophe.leroy, agordeev, gerald.schaefer, dave.hansen, luto,
peterz, x86, linux-arm-kernel, linuxppc-dev, linux-s390,
linux-kernel, rmk+kernel
In-Reply-To: <20240123064305.2829244-1-surenb@google.com>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Mon, 22 Jan 2024 22:43:05 -0800 you wrote:
> The change [1] missed ARM architecture when fixing major fault accounting
> for page fault retry under per-VMA lock. Add missing code to fix ARM
> architecture fault accounting.
>
> [1] 46e714c729c8 ("arch/mm/fault: fix major fault accounting when retrying under per-VMA lock")
>
> Fixes: 12214eba1992 ("mm: handle read faults under the VMA lock")
>
> [...]
Here is the summary with links:
- [1/1] arch/arm/mm: fix major fault accounting when retrying under per-VMA lock
https://git.kernel.org/riscv/c/e870920bbe68
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/11] Bump the minimum supported version of LLVM to 13.0.1
From: patchwork-bot+linux-riscv @ 2024-03-25 4:42 UTC (permalink / raw)
To: Nathan Chancellor
Cc: linux-riscv, akpm, masahiroy, nicolas, linux-kbuild, llvm,
patches, linux-kernel, tglx, mingo, bp, dave.hansen, x86, linux,
ardb, linux-arm-kernel, catalin.marinas, will, mark.rutland, mpe,
npiggin, aneesh.kumar, naveen.n.rao, linuxppc-dev, paul.walmsley,
palmer, aou, conor, keescook, linux-hardening
In-Reply-To: <20240125-bump-min-llvm-ver-to-13-0-1-v1-0-f5ff9bda41c5@kernel.org>
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Thu, 25 Jan 2024 15:55:06 -0700 you wrote:
> Hi all,
>
> This series bumps the minimum supported version of LLVM for building the
> kernel to 13.0.1. The first patch does the bump and all subsequent
> patches clean up all the various workarounds and checks for earlier
> versions.
>
> [...]
Here is the summary with links:
- [07/11] riscv: Remove MCOUNT_NAME workaround
https://git.kernel.org/riscv/c/de5f3984664e
- [08/11] riscv: Kconfig: Remove version dependency from CONFIG_CLANG_SUPPORTS_DYNAMIC_FTRACE
https://git.kernel.org/riscv/c/a38d97181271
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 0/2] Patches for rockchip clk input / output switch
From: Sugar Zhang @ 2024-03-25 4:16 UTC (permalink / raw)
To: heiko
Cc: linux-rockchip, Sugar Zhang, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-arm-kernel, linux-clk, linux-kernel
These patches add support for rockchip clk input / output switch.
Sugar Zhang (2):
clk: rockchip: Add support for clk input / output switch
dt-bindings: clock: rockchip: Add support for clk input / output
switch
.../bindings/clock/rockchip,clk-out.yaml | 107 +++++++++++++++++++++
drivers/clk/rockchip/Kconfig | 6 ++
drivers/clk/rockchip/Makefile | 2 +
drivers/clk/rockchip/clk-out.c | 99 +++++++++++++++++++
4 files changed, 214 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/rockchip,clk-out.yaml
create mode 100644 drivers/clk/rockchip/clk-out.c
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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