* RE: [PATCH v3 05/11] dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a and ls2088a
From: Xiaowei Bao @ 2019-09-03 1:33 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
Mingkai Hu
In-Reply-To: <20190902123140.GI9720@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年9月2日 20:32
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> arnd@arndb.de; gregkh@linuxfoundation.org; Z.q. Hou
> <zhiqiang.hou@nxp.com>
> Subject: Re: [PATCH v3 05/11] dt-bindings: pci: layerscape-pci: add compatible
> strings for ls1088a and ls2088a
>
> On Mon, Sep 02, 2019 at 11:17:10AM +0800, Xiaowei Bao wrote:
> > Add compatible strings for ls1088a and ls2088a.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - No change.
> > v3:
> > - Use one valid combination of compatible strings.
> >
> > Documentation/devicetree/bindings/pci/layerscape-pci.txt | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > index e20ceaa..762ae41 100644
> > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > @@ -22,7 +22,9 @@ Required properties:
> > "fsl,ls1043a-pcie"
> > "fsl,ls1012a-pcie"
> > EP mode:
> > - "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
> > + "fsl,ls1046a-pcie-ep" "fsl,ls-pcie-ep"
> > + "fsl,ls1088a-pcie-ep" "fsl,ls-pcie-ep"
> > + "fsl,ls2088a-pcie-ep" "fsl,ls-pcie-ep"
>
> This isn't consistent with "[PATCH v3 09/11] PCI: layerscape: Add EP mode..."
> as that patch drops the fallback "fsl,ls-pcie-ep". Either the fallback must be
> preserved in the driver, or you need to drop it here.
>
> What if there are existing users that depend on the fallback?
>
> (I'm also not sure if that comma should have been dropped).
Hi Andrew,
Thanks for your comments, I lose the comma.
Thanks
Xiaowei
>
> Thanks,
>
> Andrew Murray
>
> > - reg: base addresses and lengths of the PCIe controller register blocks.
> > - interrupts: A list of interrupt outputs of the controller. Must contain an
> > entry for each entry in the interrupt-names property.
> > --
> > 2.9.5
> >
_______________________________________________
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: imx8mn-ddr4-evk: Enable GPIO LED
From: Anson Huang @ 2019-09-03 1:30 UTC (permalink / raw)
To: Pavel Machek
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, dl-linux-imx,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190902203144.GA4787@bug>
Hi, Pavel
> On Mon 2019-09-02 16:45:38, Anson Huang wrote:
> > i.MX8MN DDR4 EVK board has a GPIO LED to indicate status, add support
> > for it.
>
> LED maintainers want to be on the cc list...
The get_maintainer.pl does NOT show the LED maintainers...But I have added it
in V2.
>
> > @@ -15,6 +15,18 @@
> > stdout-path = &uart2;
> > };
> >
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpio_led>;
> > +
> > + status {
> > + label = "status";
> > + gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
> > + default-state = "on";
> > + };
>
> And we should really standardize labels for user-controlled status LEDs.
> Mentioning color would be nice, for a start.
OK, I change the label to "yellow:status" in V2, please help review, thanks.
Anson
_______________________________________________
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: imx8mn-ddr4-evk: Enable GPIO LED
From: Anson Huang @ 2019-09-03 13:27 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
linux-leds, devicetree, linux-arm-kernel, linux-kernel
Cc: dmurphy, Linux-imx, pavel, jacek.anaszewski
i.MX8MN DDR4 EVK board has a GPIO LED to indicate status,
add support for it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V1:
- Mention color in the label.
---
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
index b698061..bf1c097 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
@@ -15,6 +15,18 @@
stdout-path = &uart2;
};
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_led>;
+
+ status {
+ label = "yellow:status";
+ gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
reg_usdhc2_vmmc: regulator-usdhc2 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -54,6 +66,12 @@
>;
};
+ pinctrl_gpio_led: gpioledgrp {
+ fsl,pins = <
+ MX8MN_IOMUXC_NAND_READY_B_GPIO3_IO16 0x19
+ >;
+ };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX8MN_IOMUXC_I2C1_SCL_I2C1_SCL 0x400001c3
--
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 related
* RE: [PATCH 1/7] iommu/arm-smmu: add Nvidia SMMUv2 implementation
From: Krishna Reddy @ 2019-09-03 1:07 UTC (permalink / raw)
To: Robin Murphy
Cc: Timo Alho, Thierry Reding, Mikko Perttunen,
linux-kernel@vger.kernel.org, joro@8bytes.org,
will.deacon@arm.com, iommu@lists.linux-foundation.org,
Pritesh Raithatha, Thomas Zeng (SW-TEGRA), Sachin Nikam,
linux-tegra@vger.kernel.org, Yu-Huan Hsu, Juha Tukkinen,
Alexander Van Brunt, linux-arm-kernel@lists.infradead.org
In-Reply-To: <3f2cbbe2-f6d7-07e3-3fef-18af518dedef@arm.com>
>>> +ARM_SMMU_MATCH_DATA(nvidia_smmuv2, ARM_SMMU_V2, NVIDIA_SMMUV2);
>> The ARM MMU-500 implementation is unmodified. It is the way the are integrated and used together(for interleaved accesses) is different from regular ARM MMU-500.
>> I have added it to get the model number and to be able differentiate the SMMU implementation in arm-smmu-impl.c.
>In that case, I would rather keep smmu->model representing the MMU-500 microarchitecture -
>since you'll still want to pick up errata workarounds etc. for that - and detect the Tegra integration via an explicit of_device_is_compatible()
> check in arm_smmu_impl_init().
Looks good to me.
>For comparison, under ACPI we'd probably have to detect integration details by looking at table headers, separately
> from the IORT "Model" field, so I'd prefer if the DT vs. ACPI handling didn't diverge more than necessary.
ACPI support for T194 can be added based on need in subsequent patches. For now, I am updating it for DT support.
-KR
_______________________________________________
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 RESEND v2 1/6] dt-bindings: watchdog: Add YAML schemas for the generic watchdog bindings
From: Guenter Roeck @ 2019-09-03 0:37 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, linux-watchdog, linux-kernel,
Chen-Yu Tsai, Rob Herring, wim, Frank Rowand, linux-arm-kernel
In-Reply-To: <20190902114650.w65ya7mgfsyu275x@flea>
On 9/2/19 4:46 AM, Maxime Ripard wrote:
> Hi Guenther,
>
> On Fri, Aug 30, 2019 at 09:48:11AM -0700, Guenter Roeck wrote:
>> On Wed, Aug 21, 2019 at 04:38:30PM +0200, Maxime Ripard wrote:
>>> From: Maxime Ripard <maxime.ripard@bootlin.com>
>>>
>>> The watchdogs have a bunch of generic properties that are needed in a
>>> device tree. Add a YAML schemas for those.
>>>
>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>>
>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>
> Thanks for reviewing this, which tree should this go through? Yours or Rob's?
>
I added the watchdog patches to my watchdog-next tree, where Wim
usually pick them up. I would be ok with Rob picking them up too
if he wants to.
Guenter
_______________________________________________
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] power: reset: make reboot-mode user selectable
From: Sebastian Reichel @ 2019-09-03 0:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bartosz Golaszewski, Linux PM list, linux-kernel@vger.kernel.org,
Linux ARM, Nandor Han
In-Reply-To: <CAK8P3a3uNPepYweCN9+_cQNQyiSGdidwNGL0+xhti2vm8g9O_g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 604 bytes --]
Hi,
On Mon, Sep 02, 2019 at 11:16:27PM +0200, Arnd Bergmann wrote:
> On Mon, Sep 2, 2019 at 10:39 PM Sebastian Reichel <sre@kernel.org> wrote:
> > This patch does not look good to me. Better patch would be to
> > allow compiling CONFIG_REBOOT_MODE without CONFIG_OF. Obviously
> > the configuration would not be useful for anything except compile
> > testing, but that is also true for this patch.
>
> Ok, I'd suggest we leave it with the bugfix you already applied then.
> [caa2b55784, power: reset: nvmem-reboot-mode: add CONFIG_OF dependency]
That's also fine with me.
-- Sebastian
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] clocksource: atmel-st: Variable sr in at91rm9200_timer_interrupt() could be uninitialized
From: Alexandre Belloni @ 2019-09-02 22:36 UTC (permalink / raw)
To: Yizhuo
Cc: csong, Daniel Lezcano, zhiyunq, linux-kernel, Ludovic Desroches,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190902222946.20548-1-yzhai003@ucr.edu>
On 02/09/2019 15:29:46-0700, Yizhuo wrote:
> Inside function at91rm9200_timer_interrupt(), variable sr could
> be uninitialized if regmap_read() fails. However, sr is used
Could you elaborate on how this could fail?
> to decide the control flow later in the if statement, which is
> potentially unsafe. We could check the return value of
> regmap_read() and print an error here.
>
> Signed-off-by: Yizhuo <yzhai003@ucr.edu>
> ---
> drivers/clocksource/timer-atmel-st.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/timer-atmel-st.c b/drivers/clocksource/timer-atmel-st.c
> index ab0aabfae5f0..061a3f27847e 100644
> --- a/drivers/clocksource/timer-atmel-st.c
> +++ b/drivers/clocksource/timer-atmel-st.c
> @@ -48,8 +48,14 @@ static inline unsigned long read_CRTR(void)
> static irqreturn_t at91rm9200_timer_interrupt(int irq, void *dev_id)
> {
> u32 sr;
> + int ret;
> +
> + ret = regmap_read(regmap_st, AT91_ST_SR, &sr);
> + if (ret) {
> + pr_err("Fail to read AT91_ST_SR.\n");
> + return ret;
> + }
>
> - regmap_read(regmap_st, AT91_ST_SR, &sr);
> sr &= irqmask;
>
> /*
> --
> 2.17.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.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] clocksource: atmel-st: Variable sr in at91rm9200_timer_interrupt() could be uninitialized
From: Yizhuo @ 2019-09-02 22:29 UTC (permalink / raw)
Cc: csong, Alexandre Belloni, Daniel Lezcano, zhiyunq, linux-kernel,
Yizhuo, Ludovic Desroches, Thomas Gleixner, linux-arm-kernel
Inside function at91rm9200_timer_interrupt(), variable sr could
be uninitialized if regmap_read() fails. However, sr is used
to decide the control flow later in the if statement, which is
potentially unsafe. We could check the return value of
regmap_read() and print an error here.
Signed-off-by: Yizhuo <yzhai003@ucr.edu>
---
drivers/clocksource/timer-atmel-st.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-atmel-st.c b/drivers/clocksource/timer-atmel-st.c
index ab0aabfae5f0..061a3f27847e 100644
--- a/drivers/clocksource/timer-atmel-st.c
+++ b/drivers/clocksource/timer-atmel-st.c
@@ -48,8 +48,14 @@ static inline unsigned long read_CRTR(void)
static irqreturn_t at91rm9200_timer_interrupt(int irq, void *dev_id)
{
u32 sr;
+ int ret;
+
+ ret = regmap_read(regmap_st, AT91_ST_SR, &sr);
+ if (ret) {
+ pr_err("Fail to read AT91_ST_SR.\n");
+ return ret;
+ }
- regmap_read(regmap_st, AT91_ST_SR, &sr);
sr &= irqmask;
/*
--
2.17.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] PCI: Move ATS declarations to linux/pci.h
From: Bjorn Helgaas @ 2019-09-02 21:38 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Krzysztof Wilczynski, linux-pci, Joerg Roedel, linux-kernel,
iommu, Kelsey Skunberg, Will Deacon, David Woodhouse,
linux-arm-kernel, Robin Murphy
In-Reply-To: <20190902211100.GH7013@google.com>
[+cc Kelsey]
On Mon, Sep 02, 2019 at 04:11:00PM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 30, 2019 at 09:18:40AM -0700, Christoph Hellwig wrote:
> > On Fri, Aug 30, 2019 at 05:07:56PM +0200, Krzysztof Wilczynski wrote:
> > > Move ATS function prototypes from include/linux/pci-ats.h to
> > > include/linux/pci.h so users only need to include <linux/pci.h>:
> >
> > Why is that so important? Very few PCI(e) device drivers use ATS,
> > so keeping it out of everyones include hell doesn't seem all bad.
>
> This was my idea, and it wasn't a good one, sorry.
>
> The ATS, PRI, and PASID interfaces are all sort of related and are
> used only by the IOMMU drivers, so it probably makes sense to put them
> all together. Right now the ATS stuff is in linux/pci.h and PRI/PASID
> stuff is in linux/pci-ats.h. Maybe the right thing would be to move
> the ATS stuff to pci-ats.h.
>
> I previously moved it from pci-ats.h to pci.h with ff9bee895c4d ("PCI:
> Move ATS declarations to linux/pci.h so they're all together") with
> the excuse of putting the external ATS interfaces next to
> pci_ats_init(). But that really looks like it was a mistake because
> pci_ats_init() is a PCI-internal thing and its declaration should
> probably be in drivers/pci/pci.h instead.
Never mind the pci_ats_init() part; Kelsey has already moved that:
https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?id=b92b512a435d
_______________________________________________
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 15/22] media: imx7-media-csi: Create media links in bound notifier
From: Steve Longerbeam @ 2019-09-02 21:37 UTC (permalink / raw)
To: Rui Miguel Silva
Cc: open list:STAGING SUBSYSTEM, Fabio Estevam,
Pengutronix Kernel Team, Greg Kroah-Hartman, Sascha Hauer,
open list, NXP Linux Team, Philipp Zabel, Mauro Carvalho Chehab,
Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-media
In-Reply-To: <m3blw35970.fsf@gmail.com>
Hi Rui,
On 9/2/19 2:38 AM, Rui Miguel Silva wrote:
> Hi Steve,
> On Tue 06 Aug 2019 at 00:34, Steve Longerbeam wrote:
>> Implement a notifier bound op to register media links from the remote
>> sub-device's source pad(s) to the CSI sink pad.
>>
>> Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com>
>> ---
>> drivers/staging/media/imx/imx7-media-csi.c | 24 ++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/drivers/staging/media/imx/imx7-media-csi.c b/drivers/staging/media/imx/imx7-media-csi.c
>> index a1c96c52a606..f71ac485f780 100644
>> --- a/drivers/staging/media/imx/imx7-media-csi.c
>> +++ b/drivers/staging/media/imx/imx7-media-csi.c
>> @@ -196,6 +196,11 @@ struct imx7_csi {
>> struct completion last_eof_completion;
>> };
>>
>> +static inline struct imx7_csi *notifier_to_dev(struct v4l2_async_notifier *n)
>>
> As the other one add the namespace for the function name:
> imx7_csi_notifier_to_dev
>
> other than this, looks good to me.
Thanks for the review. I will make those changes in next rev.
Steve
>
>
>> +{
>> + return container_of(n, struct imx7_csi, notifier);
>> +}
>> +
>> static u32 imx7_csi_reg_read(struct imx7_csi *csi, unsigned int offset)
>> {
>> return readl(csi->regbase + offset);
>> @@ -1173,6 +1178,23 @@ static int imx7_csi_parse_endpoint(struct device *dev,
>> return fwnode_device_is_available(asd->match.fwnode) ? 0 : -EINVAL;
>> }
>>
>> +static int imx7_csi_notify_bound(struct v4l2_async_notifier *notifier,
>> + struct v4l2_subdev *sd,
>> + struct v4l2_async_subdev *asd)
>> +{
>> + struct imx7_csi *csi = notifier_to_dev(notifier);
>> + struct media_pad *sink = &csi->sd.entity.pads[IMX7_CSI_PAD_SINK];
>> +
>> + return media_create_fwnode_pad_links(sink,
>> + dev_fwnode(csi->sd.dev),
>> + &sd->entity,
>> + dev_fwnode(sd->dev), 0);
>> +}
>> +
>> +static const struct v4l2_async_notifier_operations imx7_csi_notify_ops = {
>> + .bound = imx7_csi_notify_bound,
>> +};
>> +
>> static int imx7_csi_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> @@ -1253,6 +1275,8 @@ static int imx7_csi_probe(struct platform_device *pdev)
>>
>> v4l2_async_notifier_init(&csi->notifier);
>>
>> + csi->notifier.ops = &imx7_csi_notify_ops;
>> +
>> ret = v4l2_async_register_fwnode_subdev(&csi->sd, &csi->notifier,
>> sizeof(struct v4l2_async_subdev),
>> NULL, 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 1/4] ACPI: Support Generic Initiator only domains
From: Rafael J. Wysocki @ 2019-09-02 21:26 UTC (permalink / raw)
To: Jonathan Cameron, Dan Williams, Keith Busch
Cc: ACPI Devel Maling List, Rafael J . Wysocki,
Linux Kernel Mailing List, Linuxarm, Linux Memory Management List,
Jerome Glisse, Andrew Morton, Linux ARM
In-Reply-To: <20190821145242.2330-2-Jonathan.Cameron@huawei.com>
On Wed, Aug 21, 2019 at 4:53 PM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> Generic Initiators are a new ACPI concept that allows for the
> description of proximity domains that contain a device which
> performs memory access (such as a network card) but neither
> host CPU nor Memory.
>
> This patch has the parsing code and provides the infrastructure
> for an architecture to associate these new domains with their
> nearest memory processing node.
>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Dan, Keith, any comments?
AFAICS this clashes with the series from Dan that rearranges the ACPI
NUMA related code.
> ---
> drivers/acpi/numa.c | 62 +++++++++++++++++++++++++++++++++-
> drivers/base/node.c | 3 ++
> include/asm-generic/topology.h | 3 ++
> include/linux/nodemask.h | 1 +
> include/linux/topology.h | 7 ++++
> 5 files changed, 75 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
> index eadbf90e65d1..fe34315a9234 100644
> --- a/drivers/acpi/numa.c
> +++ b/drivers/acpi/numa.c
> @@ -170,6 +170,38 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
> }
> break;
>
> + case ACPI_SRAT_TYPE_GENERIC_AFFINITY:
> + {
> + struct acpi_srat_generic_affinity *p =
> + (struct acpi_srat_generic_affinity *)header;
> + char name[9] = {};
> +
> + if (p->device_handle_type == 0) {
> + /*
> + * For pci devices this may be the only place they
> + * are assigned a proximity domain
> + */
> + pr_debug("SRAT Generic Initiator(Seg:%u BDF:%u) in proximity domain %d %s\n",
> + *(u16 *)(&p->device_handle[0]),
> + *(u16 *)(&p->device_handle[2]),
> + p->proximity_domain,
> + (p->flags & ACPI_SRAT_GENERIC_AFFINITY_ENABLED) ?
> + "enabled" : "disabled");
> + } else {
> + /*
> + * In this case we can rely on the device having a
> + * proximity domain reference
> + */
> + memcpy(name, p->device_handle, 8);
> + pr_info("SRAT Generic Initiator(HID=%.8s UID=%.4s) in proximity domain %d %s\n",
> + (char *)(&p->device_handle[0]),
> + (char *)(&p->device_handle[8]),
> + p->proximity_domain,
> + (p->flags & ACPI_SRAT_GENERIC_AFFINITY_ENABLED) ?
> + "enabled" : "disabled");
> + }
> + }
> + break;
> default:
> pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
> header->type);
> @@ -378,6 +410,32 @@ acpi_parse_gicc_affinity(union acpi_subtable_headers *header,
> return 0;
> }
>
> +static int __init
> +acpi_parse_gi_affinity(union acpi_subtable_headers *header,
> + const unsigned long end)
> +{
> + struct acpi_srat_generic_affinity *gi_affinity;
> + int node;
> +
> + gi_affinity = (struct acpi_srat_generic_affinity *)header;
> + if (!gi_affinity)
> + return -EINVAL;
> + acpi_table_print_srat_entry(&header->common);
> +
> + if (!(gi_affinity->flags & ACPI_SRAT_GENERIC_AFFINITY_ENABLED))
> + return -EINVAL;
> +
> + node = acpi_map_pxm_to_node(gi_affinity->proximity_domain);
> + if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
> + pr_err("SRAT: Too many proximity domains.\n");
> + return -EINVAL;
> + }
> + node_set(node, numa_nodes_parsed);
> + node_set_state(node, N_GENERIC_INITIATOR);
> +
> + return 0;
> +}
> +
> static int __initdata parsed_numa_memblks;
>
> static int __init
> @@ -433,7 +491,7 @@ int __init acpi_numa_init(void)
>
> /* SRAT: System Resource Affinity Table */
> if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
> - struct acpi_subtable_proc srat_proc[3];
> + struct acpi_subtable_proc srat_proc[4];
>
> memset(srat_proc, 0, sizeof(srat_proc));
> srat_proc[0].id = ACPI_SRAT_TYPE_CPU_AFFINITY;
> @@ -442,6 +500,8 @@ int __init acpi_numa_init(void)
> srat_proc[1].handler = acpi_parse_x2apic_affinity;
> srat_proc[2].id = ACPI_SRAT_TYPE_GICC_AFFINITY;
> srat_proc[2].handler = acpi_parse_gicc_affinity;
> + srat_proc[3].id = ACPI_SRAT_TYPE_GENERIC_AFFINITY;
> + srat_proc[3].handler = acpi_parse_gi_affinity;
>
> acpi_table_parse_entries_array(ACPI_SIG_SRAT,
> sizeof(struct acpi_table_srat),
> diff --git a/drivers/base/node.c b/drivers/base/node.c
> index 75b7e6f6535b..6f60689af5f8 100644
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -980,6 +980,8 @@ static struct node_attr node_state_attr[] = {
> #endif
> [N_MEMORY] = _NODE_ATTR(has_memory, N_MEMORY),
> [N_CPU] = _NODE_ATTR(has_cpu, N_CPU),
> + [N_GENERIC_INITIATOR] = _NODE_ATTR(has_generic_initiator,
> + N_GENERIC_INITIATOR),
> };
>
> static struct attribute *node_state_attrs[] = {
> @@ -991,6 +993,7 @@ static struct attribute *node_state_attrs[] = {
> #endif
> &node_state_attr[N_MEMORY].attr.attr,
> &node_state_attr[N_CPU].attr.attr,
> + &node_state_attr[N_GENERIC_INITIATOR].attr.attr,
> NULL
> };
>
> diff --git a/include/asm-generic/topology.h b/include/asm-generic/topology.h
> index 238873739550..54d0b4176a45 100644
> --- a/include/asm-generic/topology.h
> +++ b/include/asm-generic/topology.h
> @@ -71,6 +71,9 @@
> #ifndef set_cpu_numa_mem
> #define set_cpu_numa_mem(cpu, node)
> #endif
> +#ifndef set_gi_numa_mem
> +#define set_gi_numa_mem(gi, node)
> +#endif
>
> #endif /* !CONFIG_NUMA || !CONFIG_HAVE_MEMORYLESS_NODES */
>
> diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
> index 27e7fa36f707..1aebf766fb52 100644
> --- a/include/linux/nodemask.h
> +++ b/include/linux/nodemask.h
> @@ -399,6 +399,7 @@ enum node_states {
> #endif
> N_MEMORY, /* The node has memory(regular, high, movable) */
> N_CPU, /* The node has one or more cpus */
> + N_GENERIC_INITIATOR, /* The node is a GI only node */
> NR_NODE_STATES
> };
>
> diff --git a/include/linux/topology.h b/include/linux/topology.h
> index 47a3e3c08036..2f97754e0508 100644
> --- a/include/linux/topology.h
> +++ b/include/linux/topology.h
> @@ -125,6 +125,13 @@ static inline void set_numa_mem(int node)
> }
> #endif
>
> +#ifndef set_gi_numa_mem
> +static inline void set_gi_numa_mem(int gi, int node)
> +{
> + _node_numa_mem_[gi] = node;
> +}
> +#endif
> +
> #ifndef node_to_mem_node
> static inline int node_to_mem_node(int node)
> {
> --
> 2.20.1
>
_______________________________________________
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] power: reset: make reboot-mode user selectable
From: Arnd Bergmann @ 2019-09-02 21:16 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Bartosz Golaszewski, Linux PM list, linux-kernel@vger.kernel.org,
Linux ARM, Nandor Han
In-Reply-To: <20190902203857.zusvlv3yv5arel6y@earth.universe>
On Mon, Sep 2, 2019 at 10:39 PM Sebastian Reichel <sre@kernel.org> wrote:
>
> This patch does not look good to me. Better patch would be to
> allow compiling CONFIG_REBOOT_MODE without CONFIG_OF. Obviously
> the configuration would not be useful for anything except compile
> testing, but that is also true for this patch.
Ok, I'd suggest we leave it with the bugfix you already applied then.
[caa2b55784, power: reset: nvmem-reboot-mode: add CONFIG_OF dependency]
Arnd
_______________________________________________
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] ACPI: support for NXP i2c controller
From: Andy Shevchenko @ 2019-09-02 21:16 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Wolfram Sang, Sascha Hauer, Udit Kumar, Rafael J. Wysocki,
Linux Kernel Mailing List, Leo Li, ACPI Devel Maling List,
Meenakshi Aggarwal, linux-i2c, Chuanhua Han, Shawn Guo, Linux ARM,
Len Brown
In-Reply-To: <CAJZ5v0hY2sL+XfN_4v07_hjvoxgCAt+Q89+wNg5Pky6XKP-mqA@mail.gmail.com>
On Mon, Sep 2, 2019 at 11:58 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Jul 11, 2019 at 12:35 PM Chuanhua Han <chuanhua.han@nxp.com> wrote:
> >
> > Enable NXP i2c controller to boot with ACPI
> >
> > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
> > Signed-off-by: Udit Kumar <udit.kumar@nxp.com>
> > Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
>
> Wolfram, any objections to this from the i2c side?
May I propose amendment(s)?
> > @@ -44,6 +44,7 @@
> > #include <linux/pm_runtime.h>
> > #include <linux/sched.h>
> > #include <linux/slab.h>
> > +#include <linux/acpi.h>
If it's kept in order, better to go with it. (Yes, it is as I have checked)
However, property.h should be included instead, see below.
> > const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
> > &pdev->dev);
> > + const struct acpi_device_id *acpi_id =
> > + acpi_match_device(i2c_imx_acpi_ids,
> > + &pdev->dev);
> > if (of_id)
> > i2c_imx->hwdata = of_id->data;
> > + else if (acpi_id)
> > + i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> > + acpi_id->driver_data;
The above altogher may be replaced with
const struct imx_i2c_hwdata *match;
...
match = device_get_match_data(&pdev->dev);
if (match)
i2c_imx->hwdata = match;
else
...
> > + .acpi_match_table = ACPI_PTR(i2c_imx_acpi_ids),
Since there is no #ifdef guard no need to use ACPI_PTR().
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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] PCI: Move ATS declarations to linux/pci.h
From: Bjorn Helgaas @ 2019-09-02 21:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Krzysztof Wilczynski, linux-pci, Joerg Roedel, linux-kernel,
iommu, Will Deacon, David Woodhouse, linux-arm-kernel,
Robin Murphy
In-Reply-To: <20190830161840.GA9733@infradead.org>
On Fri, Aug 30, 2019 at 09:18:40AM -0700, Christoph Hellwig wrote:
> On Fri, Aug 30, 2019 at 05:07:56PM +0200, Krzysztof Wilczynski wrote:
> > Move ATS function prototypes from include/linux/pci-ats.h to
> > include/linux/pci.h so users only need to include <linux/pci.h>:
>
> Why is that so important? Very few PCI(e) device drivers use ATS,
> so keeping it out of everyones include hell doesn't seem all bad.
This was my idea, and it wasn't a good one, sorry.
The ATS, PRI, and PASID interfaces are all sort of related and are
used only by the IOMMU drivers, so it probably makes sense to put them
all together. Right now the ATS stuff is in linux/pci.h and PRI/PASID
stuff is in linux/pci-ats.h. Maybe the right thing would be to move
the ATS stuff to pci-ats.h.
I previously moved it from pci-ats.h to pci.h with ff9bee895c4d ("PCI:
Move ATS declarations to linux/pci.h so they're all together") with
the excuse of putting the external ATS interfaces next to
pci_ats_init(). But that really looks like it was a mistake because
pci_ats_init() is a PCI-internal thing and its declaration should
probably be in drivers/pci/pci.h instead.
There's also a useless "struct pci_ats" forward declaration in
linux/pci.h that I should have removed with d544d75ac96a ("PCI: Embed
ATS info directly into struct pci_dev").
Bjorn
_______________________________________________
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] ACPI: support for NXP i2c controller
From: Wolfram Sang @ 2019-09-02 21:02 UTC (permalink / raw)
To: Rafael J. Wysocki, Oleksij Rempel
Cc: Udit Kumar, Sascha Hauer, Rafael J. Wysocki,
Linux Kernel Mailing List, Leo Li, ACPI Devel Maling List,
Meenakshi Aggarwal, linux-i2c, Chuanhua Han, Shawn Guo, Linux ARM,
Len Brown
In-Reply-To: <CAJZ5v0hY2sL+XfN_4v07_hjvoxgCAt+Q89+wNg5Pky6XKP-mqA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4426 bytes --]
On Mon, Sep 02, 2019 at 10:56:22PM +0200, Rafael J. Wysocki wrote:
> On Thu, Jul 11, 2019 at 12:35 PM Chuanhua Han <chuanhua.han@nxp.com> wrote:
> >
> > Enable NXP i2c controller to boot with ACPI
> >
> > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
> > Signed-off-by: Udit Kumar <udit.kumar@nxp.com>
> > Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
>
> Wolfram, any objections to this from the i2c side?
CCing the new maintainer of this driver...
>
> > ---
> > drivers/acpi/acpi_apd.c | 6 ++++++
> > drivers/i2c/busses/i2c-imx.c | 15 +++++++++++++++
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
> > index ff47317..cf8566c 100644
> > --- a/drivers/acpi/acpi_apd.c
> > +++ b/drivers/acpi/acpi_apd.c
> > @@ -165,6 +165,11 @@ static const struct apd_device_desc thunderx2_i2c_desc = {
> > .fixed_clk_rate = 125000000,
> > };
> >
> > +static const struct apd_device_desc nxp_i2c_desc = {
> > + .setup = acpi_apd_setup,
> > + .fixed_clk_rate = 350000000,
> > +};
> > +
> > static const struct apd_device_desc hip08_spi_desc = {
> > .setup = acpi_apd_setup,
> > .fixed_clk_rate = 250000000,
> > @@ -238,6 +243,7 @@ static const struct acpi_device_id acpi_apd_device_ids[] = {
> > { "HISI02A1", APD_ADDR(hip07_i2c_desc) },
> > { "HISI02A2", APD_ADDR(hip08_i2c_desc) },
> > { "HISI0173", APD_ADDR(hip08_spi_desc) },
> > + { "NXP0001", APD_ADDR(nxp_i2c_desc) },
> > #endif
> > { }
> > };
> > diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> > index b1b8b93..99f9b96 100644
> > --- a/drivers/i2c/busses/i2c-imx.c
> > +++ b/drivers/i2c/busses/i2c-imx.c
> > @@ -44,6 +44,7 @@
> > #include <linux/pm_runtime.h>
> > #include <linux/sched.h>
> > #include <linux/slab.h>
> > +#include <linux/acpi.h>
> >
> > /* This will be the driver name the kernel reports */
> > #define DRIVER_NAME "imx-i2c"
> > @@ -255,6 +256,12 @@ static const struct of_device_id i2c_imx_dt_ids[] = {
> > };
> > MODULE_DEVICE_TABLE(of, i2c_imx_dt_ids);
> >
> > +static const struct acpi_device_id i2c_imx_acpi_ids[] = {
> > + {"NXP0001", .driver_data = (kernel_ulong_t)&vf610_i2c_hwdata},
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(acpi, i2c_imx_acpi_ids);
> > +
> > static inline int is_imx1_i2c(struct imx_i2c_struct *i2c_imx)
> > {
> > return i2c_imx->hwdata->devtype == IMX1_I2C;
> > @@ -1052,6 +1059,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
> > {
> > const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
> > &pdev->dev);
> > + const struct acpi_device_id *acpi_id =
> > + acpi_match_device(i2c_imx_acpi_ids,
> > + &pdev->dev);
> > struct imx_i2c_struct *i2c_imx;
> > struct resource *res;
> > struct imxi2c_platform_data *pdata = dev_get_platdata(&pdev->dev);
> > @@ -1079,6 +1089,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
> >
> > if (of_id)
> > i2c_imx->hwdata = of_id->data;
> > + else if (acpi_id)
> > + i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> > + acpi_id->driver_data;
> > else
> > i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> > platform_get_device_id(pdev)->driver_data;
> > @@ -1091,6 +1104,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
> > i2c_imx->adapter.nr = pdev->id;
> > i2c_imx->adapter.dev.of_node = pdev->dev.of_node;
> > i2c_imx->base = base;
> > + ACPI_COMPANION_SET(&i2c_imx->adapter.dev, ACPI_COMPANION(&pdev->dev));
> >
> > /* Get I2C clock */
> > i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
> > @@ -1253,6 +1267,7 @@ static struct platform_driver i2c_imx_driver = {
> > .name = DRIVER_NAME,
> > .pm = &i2c_imx_pm_ops,
> > .of_match_table = i2c_imx_dt_ids,
> > + .acpi_match_table = ACPI_PTR(i2c_imx_acpi_ids),
> > },
> > .id_table = imx_i2c_devtype,
> > };
> > --
> > 2.9.5
> >
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] ACPI: support for NXP i2c controller
From: Rafael J. Wysocki @ 2019-09-02 20:56 UTC (permalink / raw)
To: Chuanhua Han, Wolfram Sang
Cc: Udit Kumar, Sascha Hauer, Rafael J. Wysocki,
Linux Kernel Mailing List, Leo Li, ACPI Devel Maling List,
Meenakshi Aggarwal, linux-i2c, Shawn Guo, Linux ARM, Len Brown
In-Reply-To: <20190711102601.20582-1-chuanhua.han@nxp.com>
On Thu, Jul 11, 2019 at 12:35 PM Chuanhua Han <chuanhua.han@nxp.com> wrote:
>
> Enable NXP i2c controller to boot with ACPI
>
> Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
> Signed-off-by: Udit Kumar <udit.kumar@nxp.com>
> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
Wolfram, any objections to this from the i2c side?
> ---
> drivers/acpi/acpi_apd.c | 6 ++++++
> drivers/i2c/busses/i2c-imx.c | 15 +++++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
> index ff47317..cf8566c 100644
> --- a/drivers/acpi/acpi_apd.c
> +++ b/drivers/acpi/acpi_apd.c
> @@ -165,6 +165,11 @@ static const struct apd_device_desc thunderx2_i2c_desc = {
> .fixed_clk_rate = 125000000,
> };
>
> +static const struct apd_device_desc nxp_i2c_desc = {
> + .setup = acpi_apd_setup,
> + .fixed_clk_rate = 350000000,
> +};
> +
> static const struct apd_device_desc hip08_spi_desc = {
> .setup = acpi_apd_setup,
> .fixed_clk_rate = 250000000,
> @@ -238,6 +243,7 @@ static const struct acpi_device_id acpi_apd_device_ids[] = {
> { "HISI02A1", APD_ADDR(hip07_i2c_desc) },
> { "HISI02A2", APD_ADDR(hip08_i2c_desc) },
> { "HISI0173", APD_ADDR(hip08_spi_desc) },
> + { "NXP0001", APD_ADDR(nxp_i2c_desc) },
> #endif
> { }
> };
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index b1b8b93..99f9b96 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -44,6 +44,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
> +#include <linux/acpi.h>
>
> /* This will be the driver name the kernel reports */
> #define DRIVER_NAME "imx-i2c"
> @@ -255,6 +256,12 @@ static const struct of_device_id i2c_imx_dt_ids[] = {
> };
> MODULE_DEVICE_TABLE(of, i2c_imx_dt_ids);
>
> +static const struct acpi_device_id i2c_imx_acpi_ids[] = {
> + {"NXP0001", .driver_data = (kernel_ulong_t)&vf610_i2c_hwdata},
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, i2c_imx_acpi_ids);
> +
> static inline int is_imx1_i2c(struct imx_i2c_struct *i2c_imx)
> {
> return i2c_imx->hwdata->devtype == IMX1_I2C;
> @@ -1052,6 +1059,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
> {
> const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
> &pdev->dev);
> + const struct acpi_device_id *acpi_id =
> + acpi_match_device(i2c_imx_acpi_ids,
> + &pdev->dev);
> struct imx_i2c_struct *i2c_imx;
> struct resource *res;
> struct imxi2c_platform_data *pdata = dev_get_platdata(&pdev->dev);
> @@ -1079,6 +1089,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
>
> if (of_id)
> i2c_imx->hwdata = of_id->data;
> + else if (acpi_id)
> + i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> + acpi_id->driver_data;
> else
> i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> platform_get_device_id(pdev)->driver_data;
> @@ -1091,6 +1104,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
> i2c_imx->adapter.nr = pdev->id;
> i2c_imx->adapter.dev.of_node = pdev->dev.of_node;
> i2c_imx->base = base;
> + ACPI_COMPANION_SET(&i2c_imx->adapter.dev, ACPI_COMPANION(&pdev->dev));
>
> /* Get I2C clock */
> i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
> @@ -1253,6 +1267,7 @@ static struct platform_driver i2c_imx_driver = {
> .name = DRIVER_NAME,
> .pm = &i2c_imx_pm_ops,
> .of_match_table = i2c_imx_dt_ids,
> + .acpi_match_table = ACPI_PTR(i2c_imx_acpi_ids),
> },
> .id_table = imx_i2c_devtype,
> };
> --
> 2.9.5
>
_______________________________________________
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] iio: adc: meson_saradc: Fix memory allocation order
From: Elie Roudninski @ 2019-09-02 20:40 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Lars-Peter Clausen, Neil Armstrong, linux-iio, Kevin Hilman,
linux-kernel, Remi Pommarel, linux-arm-kernel,
Peter Meerwald-Stadler, Hartmut Knaack, linux-amlogic,
Jonathan Cameron
In-Reply-To: <CAFBinCD96nJBPnyNgWA6CgwE2kZrkXB3-cgbV9aQLB=JtbrN2w@mail.gmail.com>
On Sun, Sep 1, 2019 at 12:29 PM Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> On Sun, Sep 1, 2019 at 12:45 PM Remi Pommarel <repk@triplefau.lt> wrote:
> >
> > meson_saradc's irq handler uses priv->regmap so make sure that it is
> > allocated before the irq get enabled.
> >
> > This also fixes crash when CONFIG_DEBUG_SHIRQ is enabled, as device
> > managed resources are freed in the inverted order they had been
> > allocated, priv->regmap was freed before the spurious fake irq that
> > CONFIG_DEBUG_SHIRQ adds called the handler.
> >
>
> Fixes: 3af109131b7eb8 ("iio: adc: meson-saradc: switch from polling to
> interrupt mode")
> > Reported-by: Elie Roudninski <xademax@gmail.com>
> > Signed-off-by: Remi Pommarel <repk@triplefau.lt>
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> thank you for fixing this!
The patch fixed the kernel panic I had, i can now successfully boot my
meson-gxl-s905x-libretech-cc boad using patched linux 5.2.11
Tested-by: Elie ROUDNINSKI <xademax@gmail.com>
Elie
>
>
> Martin
_______________________________________________
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] power: reset: make reboot-mode user selectable
From: Sebastian Reichel @ 2019-09-02 20:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bartosz Golaszewski, linux-pm, linux-kernel, linux-arm-kernel,
Nandor Han
In-Reply-To: <20190805075812.1056069-1-arnd@arndb.de>
[-- Attachment #1.1: Type: text/plain, Size: 5988 bytes --]
Hi Arnd and Nandor,
On Mon, Aug 05, 2019 at 09:57:15AM +0200, Arnd Bergmann wrote:
> Nandor Han points out that there might be drivers that can use
> the reboot-mode interfaces but might also be usable on configurations
> without device tree.
>
> Move the 'depends on OF' dependency into CONFIG_REBOOT_MODE since
> that is the only thing that truely has a compile-time dependency
> on CONFIG_OF, and make it user visible to make it possible to
> disable it.
>
> The drivers that used to 'select REBOOT_MODE' of course now have to
> use 'depends on REBOOT_MODE instead'. With this, we can soften the
> dependency and allow compile-testing the three front-end drivers
> on non-OF platforms.
>
> Note: anyone who was using a reboot mode driver in their kernel
> configuration now has to enable CONFIG_REBOOT_MODE as well.
>
> Suggested-by: Nandor Han <nandor.han@vaisala.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Nandor, this is so far untested, could you make sure this
> works in all configurations and forward it along with the
> bugfix?
>
> Sebastian, I'm not convinced this is a good idea, just sending
> it as Nandor requested. Please decide for yourself.
> ---
(Sorry for late reply)
This patch does not look good to me. Better patch would be to
allow compiling CONFIG_REBOOT_MODE without CONFIG_OF. Obviously
the configuration would not be useful for anything except compile
testing, but that is also true for this patch.
Making the small OF dependent section in reboot_mode_register()
would be a smaller patch with bigger test coverage, without
breakng existing configurations.
-- Sebastian
> arch/arm/configs/davinci_all_defconfig | 1 +
> arch/arm64/configs/defconfig | 1 +
> drivers/power/reset/Kconfig | 22 +++++++++++++---------
> include/linux/reboot-mode.h | 20 ++++++++++++++++++++
> 4 files changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
> index b34970ce6b31..ebf506c01899 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -139,6 +139,7 @@ CONFIG_GPIO_PCA953X_IRQ=y
> CONFIG_RESET_CONTROLLER=y
> CONFIG_POWER_RESET=y
> CONFIG_POWER_RESET_GPIO=y
> +CONFIG_REBOOT_MODE=m
> CONFIG_SYSCON_REBOOT_MODE=m
> CONFIG_BATTERY_LEGO_EV3=m
> CONFIG_WATCHDOG=y
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 0e58ef02880c..bb7d7bec1413 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -419,6 +419,7 @@ CONFIG_ROCKCHIP_IODOMAIN=y
> CONFIG_POWER_RESET_MSM=y
> CONFIG_POWER_RESET_XGENE=y
> CONFIG_POWER_RESET_SYSCON=y
> +CONFIG_REBOOT_MODE=y
> CONFIG_SYSCON_REBOOT_MODE=y
> CONFIG_BATTERY_SBS=m
> CONFIG_BATTERY_BQ27XXX=y
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index a564237278ff..997323d443f5 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -9,6 +9,13 @@ menuconfig POWER_RESET
>
> if POWER_RESET
>
> +config REBOOT_MODE
> + tristate "Pass reboot-mode to firmware"
> + depends on OF
> + help
> + Some drivers allow setting the reboot mode through a platform
> + interface that the boot firmware can read.
> +
> config POWER_RESET_AS3722
> bool "ams AS3722 power-off driver"
> depends on MFD_AS3722
> @@ -107,9 +114,9 @@ config POWER_RESET_MSM
>
> config POWER_RESET_QCOM_PON
> tristate "Qualcomm power-on driver"
> - depends on ARCH_QCOM
> + depends on ARCH_QCOM || COMPILE_TEST
> depends on MFD_SPMI_PMIC
> - select REBOOT_MODE
> + depends on REBOOT_MODE || !REBOOT_MODE
> help
> Power On support for Qualcomm boards.
> If you have a Qualcomm platform and need support for
> @@ -223,14 +230,11 @@ config POWER_RESET_ZX
> help
> Reboot support for ZTE SoCs.
>
> -config REBOOT_MODE
> - tristate
> -
> config SYSCON_REBOOT_MODE
> tristate "Generic SYSCON regmap reboot mode driver"
> - depends on OF
> + depends on OF || COMPILE_TEST
> depends on MFD_SYSCON
> - select REBOOT_MODE
> + depends on REBOOT_MODE || !REBOOT_MODE
> help
> Say y here will enable reboot mode driver. This will
> get reboot mode arguments and store it in SYSCON mapped
> @@ -248,8 +252,8 @@ config POWER_RESET_SC27XX
>
> config NVMEM_REBOOT_MODE
> tristate "Generic NVMEM reboot mode driver"
> - depends on OF
> - select REBOOT_MODE
> + depends on OF || COMPILE_TEST
> + depends on REBOOT_MODE || !REBOOT_MODE
> help
> Say y here will enable reboot mode driver. This will
> get reboot mode arguments and store it in a NVMEM cell,
> diff --git a/include/linux/reboot-mode.h b/include/linux/reboot-mode.h
> index 4a2abb38d1d6..bd002060e3d0 100644
> --- a/include/linux/reboot-mode.h
> +++ b/include/linux/reboot-mode.h
> @@ -9,11 +9,31 @@ struct reboot_mode_driver {
> struct notifier_block reboot_notifier;
> };
>
> +#if IS_ENABLED(CONFIG_REBOOT_MODE)
> int reboot_mode_register(struct reboot_mode_driver *reboot);
> int reboot_mode_unregister(struct reboot_mode_driver *reboot);
> int devm_reboot_mode_register(struct device *dev,
> struct reboot_mode_driver *reboot);
> void devm_reboot_mode_unregister(struct device *dev,
> struct reboot_mode_driver *reboot);
> +#else
> +static inline int reboot_mode_register(struct reboot_mode_driver *reboot)
> +{
> + return 0;
> +}
> +static inline int reboot_mode_unregister(struct reboot_mode_driver *reboot)
> +{
> + return 0;
> +}
> +static inline int devm_reboot_mode_register(struct device *dev,
> + struct reboot_mode_driver *reboot)
> +{
> + return 0;
> +}
> +static inline void devm_reboot_mode_unregister(struct device *dev,
> + struct reboot_mode_driver *reboot)
> +{
> +}
> +#endif
>
> #endif
> --
> 2.20.0
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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: imx8mn-ddr4-evk: Enable GPIO LED
From: Pavel Machek @ 2019-09-02 20:31 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, shawnguo, s.hauer, linux-kernel,
robh+dt, Linux-imx, kernel, festevam, linux-arm-kernel
In-Reply-To: <1567457138-3002-1-git-send-email-Anson.Huang@nxp.com>
On Mon 2019-09-02 16:45:38, Anson Huang wrote:
> i.MX8MN DDR4 EVK board has a GPIO LED to indicate status,
> add support for it.
LED maintainers want to be on the cc list...
> @@ -15,6 +15,18 @@
> stdout-path = &uart2;
> };
>
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_led>;
> +
> + status {
> + label = "status";
> + gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
And we should really standardize labels for user-controlled status LEDs. Mentioning
color would be nice, for a start.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/3] ASoC: xlnx: add Xilinx logicPD-I2S FPGA IP support
From: Miquel Raynal @ 2019-09-02 20:21 UTC (permalink / raw)
To: Michal Simek
Cc: Mark Rutland, devicetree, alsa-devel,
Maruthi Srinivas Bayyavarapu, Takashi Iwai, Rob Herring,
Liam Girdwood, Mark Brown, Thomas Petazzoni, praveenv,
Jaroslav Kysela, alexandre, linux-arm-kernel
In-Reply-To: <df36fc2d-ed62-2556-513d-158a7707d5cd@xilinx.com>
Hi Michal,
Michal Simek <michal.simek@xilinx.com> wrote on Mon, 2 Sep 2019
09:39:11 +0200:
> Hi Miquel
>
> On 30. 08. 19 23:06, Miquel Raynal wrote:
> > This IP is very simple so this driver manage both the DAI and the PCM
> > streams, hence the presence of both components in this driver.
> >
> > There are plenty available interruptions when capturing or playing
> > back audio that can be triggered but the only one that fits the ALSA
> > sound system is the XFER_DONE which is used to bound sound
> > periods. Other interrupts are masked. Please note that capture and
> > playback are not possible at the same time though.
> >
> > Capture seems to work (at least it creates a file with something
> > inside) but I have no capture mechanism on the board to actually test
> > that it works correctly.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> >
> > Hello,
> >
> > This is my first contribution in the sound subsystem, I hope I've
> > understood the core but I might be entirely wrong as well, so please
> > do not hesitate to be critical on my choices.
> >
> > Thanks,
> > Miquèl
> >
> > sound/soc/xilinx/Kconfig | 7 +
> > sound/soc/xilinx/Makefile | 2 +
> > sound/soc/xilinx/xlnx-logicpd-i2s.c | 468 ++++++++++++++++++++++++++++
>
> What IP is this?
> https://www.xilinx.com/products/intellectual-property/audio-i2s.html
>
> https://github.com/Xilinx/linux-xlnx/blob/master/sound/soc/xilinx/xlnx_i2s.c
>
> Anyway I am adding Praveen and Maruthi to take a look.
Actually I have been tricked by a datasheet with the wrong title: this
is a LogicPD IP, it is not from Xilinx. I will resubmit with a new
driver name/compatible and add the relevant people.
Thanks,
Miquèl
_______________________________________________
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 6/6] pwm: atmel: implement .get_state()
From: Uwe Kleine-König @ 2019-09-02 20:06 UTC (permalink / raw)
To: Claudiu.Beznea
Cc: linux-pwm, alexandre.belloni, Ludovic.Desroches, thierry.reding,
linux-arm-kernel
In-Reply-To: <8da4ef26-872f-beaf-b5cb-9d8cb93a2ce9@microchip.com>
Hello Claudiu,
On Wed, Aug 28, 2019 at 10:26:18AM +0000, Claudiu.Beznea@microchip.com wrote:
> On 24.08.2019 03:10, Uwe Kleine-König wrote:
> > External E-Mail
> > This function reads back the configured parameters from the hardware. As
> > .apply rounds down (mostly) I'm rounding up in .get_state() to achieve
> > that applying a state just read from hardware is a no-op.
>
> Since this read is only at probing, at least for the moment, and, as far as
Yes, up to now .get_state() is only called at probing time. There is a
patch series (by me) on the list that changes that. (Though I'm not
entirely sure this is a good idea. Will comment my doubts in that thread
later.)
> I remember, the idea w/ .get_state was to reflect in Linux the states of
> PWMs that were setup before Linux takes control (e.g. PWMs setup in
> bootloaders) I think it would no problem if it would be no-ops in this
> scenario.
IMHO it should be a no-op.
> In case of run-time state retrieval, pwm_get_state() should be
> enough. If one would get the state previously saved w/ this .get_state API
> he/she would change it, then it would apply the changes to the hardware. No
> changes of PWM state would be anyway skipped from the beginning, in
> pwm_apply_state() by this code:
>
> if (state->period == pwm->state.period &&
> state->duty_cycle == pwm->state.duty_cycle &&
> state->polarity == pwm->state.polarity &&
> state->enabled == pwm->state.enabled)
> return 0;
>
> But maybe I'm missing something.
There is a problem I want to solve generally, not only for the atmel driver.
For example I consider it "expected" that
s1 = pwm_get_state(pwm)
pwm_apply_state(pwm, s2)
pwm_apply_state(pwm, s1)
ends in the same configuration as it started. For that it is necessary
(even for the atmel driver with the guard you pointed out above) to
round up in .get_state if .apply rounds down.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.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] net: stmmac: dwmac-sun8i: Variable "val" in function sun8i_dwmac_set_syscon() could be uninitialized
From: David Miller @ 2019-09-02 18:48 UTC (permalink / raw)
To: yzhai003
Cc: csong, alexandre.torgue, netdev, zhiyunq, linux-kernel, mripard,
wens, joabreu, mcoquelin.stm32, peppe.cavallaro, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190831020049.6516-1-yzhai003@ucr.edu>
From: Yizhuo <yzhai003@ucr.edu>
Date: Fri, 30 Aug 2019 19:00:48 -0700
> In function sun8i_dwmac_set_syscon(), local variable "val" could
> be uninitialized if function regmap_field_read() returns -EINVAL.
> However, it will be used directly in the if statement, which
> is potentially unsafe.
>
> Signed-off-by: Yizhuo <yzhai003@ucr.edu>
Applied, thank you.
_______________________________________________
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: fix page faults in do_alignment
From: Eric W. Biederman @ 2019-09-02 17:36 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: kstewart, gustavo, gregkh, linux-kernel, Jing Xiangfeng, linux-mm,
sakari.ailus, bhelgaas, tglx, linux-arm-kernel
In-Reply-To: <20190830222906.GH13294@shell.armlinux.org.uk>
Russell King - ARM Linux admin <linux@armlinux.org.uk> writes:
> On Fri, Aug 30, 2019 at 04:02:48PM -0500, Eric W. Biederman wrote:
>> Russell King - ARM Linux admin <linux@armlinux.org.uk> writes:
>>
>> > On Fri, Aug 30, 2019 at 02:45:36PM -0500, Eric W. Biederman wrote:
>> >> Russell King - ARM Linux admin <linux@armlinux.org.uk> writes:
>> >>
>> >> > On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
>> >> >> The function do_alignment can handle misaligned address for user and
>> >> >> kernel space. If it is a userspace access, do_alignment may fail on
>> >> >> a low-memory situation, because page faults are disabled in
>> >> >> probe_kernel_address.
>> >> >>
>> >> >> Fix this by using __copy_from_user stead of probe_kernel_address.
>> >> >>
>> >> >> Fixes: b255188 ("ARM: fix scheduling while atomic warning in alignment handling code")
>> >> >> Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
>> >> >
>> >> > NAK.
>> >> >
>> >> > The "scheduling while atomic warning in alignment handling code" is
>> >> > caused by fixing up the page fault while trying to handle the
>> >> > mis-alignment fault generated from an instruction in atomic context.
>> >> >
>> >> > Your patch re-introduces that bug.
>> >>
>> >> And the patch that fixed scheduling while atomic apparently introduced a
>> >> regression. Admittedly a regression that took 6 years to track down but
>> >> still.
>> >
>> > Right, and given the number of years, we are trading one regression for
>> > a different regression. If we revert to the original code where we
>> > fix up, we will end up with people complaining about a "new" regression
>> > caused by reverting the previous fix. Follow this policy and we just
>> > end up constantly reverting the previous revert.
>> >
>> > The window is very small - the page in question will have had to have
>> > instructions read from it immediately prior to the handler being entered,
>> > and would have had to be made "old" before subsequently being unmapped.
>>
>> > Rather than excessively complicating the code and making it even more
>> > inefficient (as in your patch), we could instead retry executing the
>> > instruction when we discover that the page is unavailable, which should
>> > cause the page to be paged back in.
>>
>> My patch does not introduce any inefficiencies. It onlys moves the
>> check for user_mode up a bit. My patch did duplicate the code.
>>
>> > If the page really is unavailable, the prefetch abort should cause a
>> > SEGV to be raised, otherwise the re-execution should replace the page.
>> >
>> > The danger to that approach is we page it back in, and it gets paged
>> > back out before we're able to read the instruction indefinitely.
>>
>> I would think either a little code duplication or a function that looks
>> at user_mode(regs) and picks the appropriate kind of copy to do would be
>> the best way to go. Because what needs to happen in the two cases for
>> reading the instruction are almost completely different.
>
> That is what I mean. I'd prefer to avoid that with the large chunk of
> code. How about instead adding a local replacement for
> probe_kernel_address() that just sorts out the reading, rather than
> duplicating all the code to deal with thumb fixup.
So something like this should be fine?
Jing Xiangfeng can you test this please? I think this fixes your issue
but I don't currently have an arm development box where I could test this.
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 04b36436cbc0..b07d17ca0ae5 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -767,6 +767,23 @@ do_alignment_t32_to_handler(unsigned long *pinstr, struct pt_regs *regs,
return NULL;
}
+static inline unsigned long
+copy_instr(bool umode, void *dst, unsigned long instrptr, size_t size)
+{
+ unsigned long result;
+ if (umode) {
+ void __user *src = (void *)instrptr;
+ result = copy_from_user(dst, src, size);
+ } else {
+ void *src = (void *)instrptr;
+ result = probe_kernel_read(dst, src, size);
+ }
+ /* Convert short reads into -EFAULT */
+ if ((result >= 0) && (result < size))
+ result = -EFAULT;
+ return result;
+}
+
static int
do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
{
@@ -778,22 +795,24 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
u16 tinstr = 0;
int isize = 4;
int thumb2_32b = 0;
+ bool umode;
if (interrupts_enabled(regs))
local_irq_enable();
instrptr = instruction_pointer(regs);
+ umode = user_mode(regs);
if (thumb_mode(regs)) {
- u16 *ptr = (u16 *)(instrptr & ~1);
- fault = probe_kernel_address(ptr, tinstr);
+ unsigned long tinstrptr = instrptr & ~1;
+ fault = copy_instr(umode, &tinstr, tinstrptr, 2);
tinstr = __mem_to_opcode_thumb16(tinstr);
if (!fault) {
if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
IS_T32(tinstr)) {
/* Thumb-2 32-bit */
u16 tinst2 = 0;
- fault = probe_kernel_address(ptr + 1, tinst2);
+ fault = copy_instr(umode, &tinst2, tinstrptr + 2, 2);
tinst2 = __mem_to_opcode_thumb16(tinst2);
instr = __opcode_thumb32_compose(tinstr, tinst2);
thumb2_32b = 1;
@@ -803,7 +822,7 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
}
}
} else {
- fault = probe_kernel_address((void *)instrptr, instr);
+ fault = copy_instr(umode, &instr, instrptr, 4);
instr = __mem_to_opcode_arm(instr);
}
@@ -812,7 +831,7 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
goto bad_or_fault;
}
- if (user_mode(regs))
+ if (umode)
goto user;
ai_sys += 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
* [PATCH] arch: arm: reuse addr variable in pfn_valid
From: Clemens Gruber @ 2019-09-02 16:46 UTC (permalink / raw)
To: linux-arm-kernel
Cc: zhaoyang, Clemens Gruber, Mike Rapoport, linux-kernel,
Russell King
Avoid calling __pfn_to_phys twice.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: zhaoyang <huangzhaoyang@gmail.com>
Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
---
arch/arm/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 98e17388a563..a5fe2bdc76de 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -179,7 +179,7 @@ int pfn_valid(unsigned long pfn)
if (__phys_to_pfn(addr) != pfn)
return 0;
- return memblock_is_map_memory(__pfn_to_phys(pfn));
+ return memblock_is_map_memory(addr);
}
EXPORT_SYMBOL(pfn_valid);
#endif
--
2.23.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 0/4] ARM: multi_v7_defconfig: add audio support for stm32mp157a-dk1
From: Arnd Bergmann @ 2019-09-02 16:42 UTC (permalink / raw)
To: Olivier Moysan
Cc: Alexandre Torgue, Tony Lindgren, linux-kernel@vger.kernel.org,
Krzysztof Kozlowski, Yannick Fertre, Enric Balletbo i Serra,
Olof Johansson, Simon Horman, Fabrice Gasnier, linux-stm32,
Linux ARM, Marek Szyprowski
In-Reply-To: <1567440041-19220-1-git-send-email-olivier.moysan@st.com>
On Mon, Sep 2, 2019 at 6:01 PM Olivier Moysan <olivier.moysan@st.com> wrote:
>
> This patchset adds audio support for stm32mp157a-dk1 board.
>
> Olivier Moysan (4):
> ARM: multi_v7_defconfig: enable stm32 sai support
> ARM: multi_v7_defconfig: enable stm32 i2s support
> ARM: multi_v7_defconfig: enable cs42l51 codec support
> ARM: multi_v7_defconfig: enable audio graph card support
The changes are ok, and I expect Alexandre will pick them up and forward
to the soc tree.
However, I would prefer these to just be a single patch, as there is little
use in splitting the intended change up into one line per patch.
Arnd
_______________________________________________
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