* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Steven Rostedt @ 2016-11-16 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_8hhp1J1BwWE6m=mtYYCixajJLj1GJGRuNPtO328qQGg@mail.gmail.com>
On Wed, 16 Nov 2016 11:48:38 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >
> > Does that allay your concerns?
> >
>
> Yes, it does. Thanks
Does this mean I can pull this patch into my queue then?
-- Steve
^ permalink raw reply
* [PATCH v05 60/72] arch/arm/include/uapi/asm/signal.h: use __kernel_size_t instead of size_t
From: Mikko Rapeli @ 2016-11-16 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1898059.B1P75dnZ5Q@wuerfel>
On Wed, Aug 24, 2016 at 05:02:56PM +0200, Arnd Bergmann wrote:
> On Monday, August 22, 2016 8:33:17 PM CEST Mikko Rapeli wrote:
> > diff --git a/arch/arm/include/uapi/asm/signal.h b/arch/arm/include/uapi/asm/signal.h
> > index 33073bd..859f2de 100644
> > --- a/arch/arm/include/uapi/asm/signal.h
> > +++ b/arch/arm/include/uapi/asm/signal.h
> > @@ -113,7 +113,7 @@ struct sigaction {
> > typedef struct sigaltstack {
> > void __user *ss_sp;
> > int ss_flags;
> > - size_t ss_size;
> > + __kernel_size_t ss_size;
> > } stack_t;
>
> I was going to reply with an Ack, but on further consideration,
> I'm not sure if we can't do this in general: size_t may be either
> 'unsigned int' or 'unsigned long' (depending on the architecture
> and toolchain), and if kernel and glibc disagree on this, we
> have a problem with any user space code that expects sigaltstack->ss_size
> to be the same type as size_t (as mandated by the man page).
>
> I wonder if there is another way to address this.
I presume that kernel headers need to follow libc in this case and include
<stddef.h>?
-Mikko
^ permalink raw reply
* [PATCH] pinctrl: sunxi: fix theoretical uninitialized variable access
From: Arnd Bergmann @ 2016-11-16 14:18 UTC (permalink / raw)
To: linux-arm-kernel
gcc warns about a way that it could use an uninitialized variable:
drivers/pinctrl/sunxi/pinctrl-sunxi.c: In function 'sunxi_pinctrl_init':
drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: error: 'best_div' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This cannot really happen except if 'freq' is UINT_MAX and 'clock' is
zero, and both of these are forbidden. To shut up the warning anyway,
this changes the logic to initialize the return code to the first
divider value before looking at the others.
Fixes: 7c926492d38a ("pinctrl: sunxi: Add support for interrupt debouncing")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 2339d4718b4d..6b7953da4228 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -1125,10 +1125,13 @@ static int sunxi_pinctrl_build_state(struct platform_device *pdev)
static int sunxi_pinctrl_get_debounce_div(struct clk *clk, int freq, int *diff)
{
unsigned long clock = clk_get_rate(clk);
- unsigned int best_diff = ~0, best_div;
+ unsigned int best_diff, best_div;
int i;
- for (i = 0; i < 8; i++) {
+ best_diff = abs(freq - clock);
+ best_div = 0;
+
+ for (i = 1; i < 8; i++) {
int cur_diff = abs(freq - (clock >> i));
if (cur_diff < best_diff) {
--
2.9.0
^ permalink raw reply related
* [PATCH 1/1] drivers: dma-contiguous: Ensure cma reserve region never cross the low/high mem boundary
From: Jason Liu @ 2016-11-16 14:19 UTC (permalink / raw)
To: linux-arm-kernel
If the cma reserve region goes through the device-tree method,
also need ensure the cma reserved region not cross the low/high
mem boundary. This patch did the similar fix as commit:16195dd
("mm: cma: Ensure that reservations never cross the low/high mem boundary")
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/base/dma-contiguous.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index e167a1e1..2bc093c 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -244,6 +244,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
{
phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
phys_addr_t mask = align - 1;
+ phys_addr_t highmem_start;
unsigned long node = rmem->fdt_node;
struct cma *cma;
int err;
@@ -256,6 +257,32 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
pr_err("Reserved memory: incorrect alignment of CMA region\n");
return -EINVAL;
}
+#ifdef CONFIG_X86
+ /*
+ * high_memory isn't direct mapped memory so retrieving its physical
+ * address isn't appropriate. But it would be useful to check the
+ * physical address of the highmem boundary so it's justfiable to get
+ * the physical address from it. On x86 there is a validation check for
+ * this case, so the following workaround is needed to avoid it.
+ */
+ highmem_start = __pa_nodebug(high_memory);
+#else
+ highmem_start = __pa(high_memory);
+#endif
+
+ /*
+ * All pages in the reserved area must come from the same zone.
+ * If the reserved region crosses the low/high memory boundary,
+ * try to fix it up and then fall back to allocate from the low mem
+ */
+ if (rmem->base < highmem_start &&
+ (rmem->base + rmem->size) > highmem_start) {
+ memblock_free(rmem->base, rmem->size);
+ rmem->base = memblock_alloc_range(rmem->size, align, 0,
+ highmem_start, MEMBLOCK_NONE);
+ if (!rmem->base)
+ return -ENOMEM;
+ }
err = cma_init_reserved_mem(rmem->base, rmem->size, 0, &cma);
if (err) {
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] phy: rockchip-inno-usb2: fix uninitialized tmout variable
From: Arnd Bergmann @ 2016-11-16 14:22 UTC (permalink / raw)
To: linux-arm-kernel
The newly added OTG support has an obvious uninitialized variable
access that gcc warns about:
drivers/phy/phy-rockchip-inno-usb2.c: In function 'rockchip_chg_detect_work':
drivers/phy/phy-rockchip-inno-usb2.c:717:7: error: 'tmout' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This replaces the use of the uninitialized variable with what
the value was in the previous USB_CHG_STATE_WAIT_FOR_DCD
state.
Fixes: 0c42fe48fd23 ("phy: rockchip-inno-usb2: support otg-port for rk3399")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
index eb89de59b68f..2f99ec95079c 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -714,7 +714,7 @@ static void rockchip_chg_detect_work(struct work_struct *work)
delay = CHG_SECONDARY_DET_TIME;
rphy->chg_state = USB_CHG_STATE_PRIMARY_DONE;
} else {
- if (tmout) {
+ if (rphy->dcd_retries == CHG_DCD_MAX_RETRIES) {
/* floating charger found */
rphy->chg_type = POWER_SUPPLY_TYPE_USB_DCP;
rphy->chg_state = USB_CHG_STATE_DETECTED;
--
2.9.0
^ permalink raw reply related
* [PATCH 08/16] ARM: vexpress: use generic API for enabling SCU
From: Sudeep Holla @ 2016-11-16 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-9-git-send-email-pankaj.dubey@samsung.com>
On 14/11/16 05:02, Pankaj Dubey wrote:
> Now as we have of_scu_enable which takes care of mapping
> scu base from DT, lets use it.
>
> CC: Liviu Dudau <liviu.dudau@arm.com>
> CC: Sudeep Holla <sudeep.holla@arm.com>
I assume you will take this series through a single tree. Also I assume
you may make changes around a9 SCU. I will try to test if I can get my
setup back working. But if this patch is not changed, then
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v5 1/2] drm: tilcdc: implement palette loading for rev1
From: Jyri Sarha @ 2016-11-16 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJUh8KypU_-HtGa+ieCpO46FBME8_VQCJvYkCjFhmuVWgg@mail.gmail.com>
On 11/16/16 13:34, Bartosz Golaszewski wrote:
> 2016-10-31 17:05 GMT+01:00 Jyri Sarha <jsarha@ti.com>:
>> On 10/31/16 16:19, Bartosz Golaszewski wrote:
>>> Revision 1 of the IP doesn't work if we don't load the palette (even
>>> if it's not used, which is the case for the RGB565 format).
>>>
>>> Add a function called from tilcdc_crtc_enable() which performs all
>>> required actions if we're dealing with a rev1 chip.
>>>
>>
>> There is only one thing I do not like about this patch. The palette
>> loading is done so late that the frame buffer address are already placed
>> into DMA base and ceiling registers, and we need to read them from the
>> registers and restore them back after the palette loading.
>>
>> Could you try if the palette loading function works without trouble when
>> called from tilcdc_pm_resume() before drm_atomic_helper_resume() call?
>> If it does it would be cleaner in the sense that you could get rid off
>> the old dma address restore code. You could reinit the completion always
>> there right before the palette loading.
>>
>> If you can not get the above suggestion to work, then I can take this
>> patch.
>>
>
> Hi Jyri,
>
> the problem is that tilcdc_pm_resume() is not called when tilcdc is
> initialized. We would have to have two calls in different places for
> that to work.
>
Yep, I know now. I worked on the issue while you were on vacation.
Please review my latest patch series (including this patch) and more
importantly test if the palette loading still works on rev 1 LCDC.
>>> +static void tilcdc_crtc_load_palette(struct drm_crtc *crtc)
>>> +{
>>> + u32 dma_fb_base, dma_fb_ceiling, raster_ctl;
>>> + struct tilcdc_crtc *tilcdc_crtc;
>>> + struct drm_device *dev;
>>> + u16 *first_entry;
>>> +
>>> + dev = crtc->dev;
>>> + tilcdc_crtc = to_tilcdc_crtc(crtc);
>>> + first_entry = tilcdc_crtc->palette_base;
>>> +
>>> + *first_entry = TILCDC_REV1_PALETTE_FIRST_ENTRY;
>>> +
>>> + dma_fb_base = tilcdc_read(dev, LCDC_DMA_FB_BASE_ADDR_0_REG);
>>> + dma_fb_ceiling = tilcdc_read(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG);
>>> + raster_ctl = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
>>> +
>>> + /* Tell the LCDC where the palette is located. */
>>> + tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG,
>>> + tilcdc_crtc->palette_dma_handle);
>>> + tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG,
>>> + (u32)tilcdc_crtc->palette_dma_handle
>>
>> Just a nit pick, but I would put the plus sign to the end of the line
>> above instead of the beginning of the line bellow. However,
>> check_patch.pl does not complain about this so I guess I can accept it too.
>>
>>> + + TILCDC_REV1_PALETTE_SIZE - 1);
>>> +
>
> I'll fix that in v6.
>
> Thanks,
> Bartosz Golaszewski
>
^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Ulf Hansson @ 2016-11-16 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028153755.GL5806@leverpostej>
On 28 October 2016 at 17:37, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
>> Greetings,
>>
>> I have an IMX6 board that has the following:
>> sdhc1: mmc0: sdio radio
>> sdhc2: mmc1: /dev/mmcblk1: microSD connector
>> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
>>
>> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
>> registered as /dev/mmcblk1 so that permanent storage is the first
>> mmcblk device as I think this is more intuitive however currently
>> these get instanced in the order they appear in the imx6qdl.dtsi
>> device-tree configuration and are not able to be mapped the way I want
>> them in my dts file.
>>
>> Is there a way, or if not is there a desire for a way, to specify the
>> order of /dev/mmcblk devices via device-tree?
>
> As with many other devices, there is no standard way of controlling the
> Linux enumeration (and given the ID space is shared with other dynamic
> devices it's not something that could generally work).
>
> These should be refererd to by UUID if possible.
>
> If not, we could cosider adding a by-dt-path or something like that.
So does that mean you think using "DT aliases" would be okay? As
Javier pointed out, there have been some attempts [1] for that, but
they didn't make it.
Perhaps we need to re-consider, and if so please re-review the DT
bindings patch from that series.
Kind regards
Uffe
[1]
https://lkml.org/lkml/2016/4/29/610 or
http://www.spinics.net/lists/linux-mmc/msg36701.html
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-16 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116132337.GD19962@lunn.ch>
On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
> >
> > There two kind of PHYs supporting eee, the one advertising eee by
> > default (like realtek) and the one not advertising it (like
> > micrel).
This is just the default register value.
>
> I don't know too much about EEE. So maybe a dumb question. Does the
> MAC need to be involved? Or is it just the PHY?
>
> If the MAC needs to be involved, the PHY should not be advertising
> EEE
> unless the MAC asks for it by calling phy_init_eee(). If this is
> true,
> maybe we need to change the realtek driver, and others in that class.
As far I understand, the advertised capabilities are exchanged during
the auto-negotiation.
At this stage, if the advertisement is disabled (regarless of the
actual support) on either side of the link, there will be no low power
idle state on the Tx nor the Rx path.
If the advertisement is enabled on both side but we don't call
phy_init_eee, I suppose Tx won't enter LPI, but Rx could.
>
> ??????Andrew
^ permalink raw reply
* [PATCH v8 0/7] arm/arm64: vgic: Implement API for vGICv3 live migration
From: Vijay Kilari @ 2016-11-16 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116114722.GB3811@cbox>
On Wed, Nov 16, 2016 at 5:17 PM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Fri, Nov 04, 2016 at 04:43:26PM +0530, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>
>> This patchset adds API for saving and restoring
>> of VGICv3 registers to support live migration with new vgic feature.
>> This API definition is as per version of VGICv3 specification
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>>
>> The patch 3 & 4 are picked from the Pavel's previous implementation.
>> http://www.spinics.net/lists/kvm/msg122040.html
>
> Do we have QEMU/kvmtool patches somewhere at this point so that I can
> test this?
I will send you next revision of QEMU patches tomorrow.
>
> Thanks,
> -Christoffer
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Andrew Lunn @ 2016-11-16 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479307890.17538.40.camel@baylibre.com>
On Wed, Nov 16, 2016 at 03:51:30PM +0100, Jerome Brunet wrote:
> On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
> > >
> > > There two kind of PHYs supporting eee, the one advertising eee by
> > > default (like realtek) and the one not advertising it (like
> > > micrel).
>
> This is just the default register value.
>
> >
> > I don't know too much about EEE. So maybe a dumb question. Does the
> > MAC need to be involved? Or is it just the PHY?
> >
> > If the MAC needs to be involved, the PHY should not be advertising
> > EEE
> > unless the MAC asks for it by calling phy_init_eee(). If this is
> > true,
> > maybe we need to change the realtek driver, and others in that class.
>
> As far I understand, the advertised capabilities are exchanged during
> the auto-negotiation.
>
> At this stage, if the advertisement is disabled (regarless of the
> actual support) on either side of the link, there will be no low power
> idle state on the Tx nor the Rx path.
>
> If the advertisement is enabled on both side but we don't call
> phy_init_eee, I suppose Tx won't enter LPI, but Rx could.
What i was trying to find out is, if the MAC needs to support EEE as
well as the PHY, what happens when the MAC does not support EEE, but
the PHYs do negotiate EEE? Does it break?
Andrew
^ permalink raw reply
* [PATCH net 2/3] dt-bindings: net: add DT bindings for realtek phys
From: Rob Herring @ 2016-11-16 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479220154-25851-3-git-send-email-jbrunet@baylibre.com>
On Tue, Nov 15, 2016 at 03:29:13PM +0100, Jerome Brunet wrote:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/realtek-phy.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/realtek-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/net/realtek-phy.txt b/Documentation/devicetree/bindings/net/realtek-phy.txt
> new file mode 100644
> index 000000000000..dc2845a6b387
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek-phy.txt
> @@ -0,0 +1,20 @@
> +Realtek Ethernet PHY
> +
> +Some boards require special tuning values of the phy.
> +
> +Optional properties:
> +
> +realtek,disable-eee-1000t:
> +realtek,disable-eee-100tx:
Make these generic/common.
> + If set, respectively disable 1000-BaseT and 100-BaseTx energy efficient
> + ethernet capabilty advertisement
> + default: Leave the phy default settings unchanged (capabilities advertised)
> +
> +Example:
> +
> +&mdio0 {
> + ethernetphy0: ethernet-phy at 0 {
> + reg = <0>;
> + realtek,disable-eee-1000t;
> + };
> +};
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v8 0/7] arm/arm64: vgic: Implement API for vGICv3 live migration
From: Christoffer Dall @ 2016-11-16 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6t=0sRYG1jn_=hqod+Kca9-8fWbtwL_-HXE3HvrA_h7PQ@mail.gmail.com>
On Wed, Nov 16, 2016 at 08:24:16PM +0530, Vijay Kilari wrote:
> On Wed, Nov 16, 2016 at 5:17 PM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Fri, Nov 04, 2016 at 04:43:26PM +0530, vijay.kilari at gmail.com wrote:
> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >>
> >> This patchset adds API for saving and restoring
> >> of VGICv3 registers to support live migration with new vgic feature.
> >> This API definition is as per version of VGICv3 specification
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
> >>
> >> The patch 3 & 4 are picked from the Pavel's previous implementation.
> >> http://www.spinics.net/lists/kvm/msg122040.html
> >
> > Do we have QEMU/kvmtool patches somewhere at this point so that I can
> > test this?
>
> I will send you next revision of QEMU patches tomorrow.
>
Sounds good, thanks.
-Christoffer
^ permalink raw reply
* [PATCH] ARM: dts: imx: Adjust CPU nodes
From: Fabio Estevam @ 2016-11-16 15:15 UTC (permalink / raw)
To: linux-arm-kernel
Make CPU nodes consistent throughout the i.MX dts files, which
also matches the description from ePAPR spec.
This also fixes the following W=1 warning in some cases:
Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg property
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx1.dtsi | 3 ++-
arch/arm/boot/dts/imx23.dtsi | 5 +++--
arch/arm/boot/dts/imx25.dtsi | 5 +++--
arch/arm/boot/dts/imx27.dtsi | 1 +
arch/arm/boot/dts/imx28.dtsi | 5 +++--
arch/arm/boot/dts/imx31.dtsi | 5 +++--
arch/arm/boot/dts/imx35.dtsi | 5 +++--
7 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/imx1.dtsi b/arch/arm/boot/dts/imx1.dtsi
index b792eee..dd3de38 100644
--- a/arch/arm/boot/dts/imx1.dtsi
+++ b/arch/arm/boot/dts/imx1.dtsi
@@ -43,8 +43,9 @@
#size-cells = <0>;
#address-cells = <1>;
- cpu: cpu at 0 {
+ cpu at 0 {
device_type = "cpu";
+ reg = <0>;
compatible = "arm,arm920t";
operating-points = <200000 1900000>;
clock-latency = <62500>;
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index ac2a9da..96eae64 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -29,12 +29,13 @@
};
cpus {
- #address-cells = <0>;
+ #address-cells = <1>;
#size-cells = <0>;
- cpu {
+ cpu at 0 {
compatible = "arm,arm926ej-s";
device_type = "cpu";
+ reg = <0>;
};
};
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 831d09a..6a34815 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -43,12 +43,13 @@
};
cpus {
- #address-cells = <0>;
+ #address-cells = <1>;
#size-cells = <0>;
- cpu {
+ cpu at 0 {
compatible = "arm,arm926ej-s";
device_type = "cpu";
+ reg = <0>;
};
};
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 9d8b596..6a7cb9e 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -65,6 +65,7 @@
cpu: cpu at 0 {
device_type = "cpu";
+ reg = <0>;
compatible = "arm,arm926ej-s";
operating-points = <
/* kHz uV */
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 3aabf65..70927d5 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -40,12 +40,13 @@
};
cpus {
- #address-cells = <0>;
+ #address-cells = <1>;
#size-cells = <0>;
- cpu {
+ cpu at 0 {
compatible = "arm,arm926ej-s";
device_type = "cpu";
+ reg = <0>;
};
};
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 685916e..aa4d9cb 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -22,12 +22,13 @@
};
cpus {
- #address-cells = <0>;
+ #address-cells = <1>;
#size-cells = <0>;
- cpu {
+ cpu at 0 {
compatible = "arm,arm1136jf-s";
device_type = "cpu";
+ reg = <0>;
};
};
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 9f40e62..6f7b943 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -27,12 +27,13 @@
};
cpus {
- #address-cells = <0>;
+ #address-cells = <1>;
#size-cells = <0>;
- cpu {
+ cpu at 0 {
compatible = "arm,arm1136jf-s";
device_type = "cpu";
+ reg = <0>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/6] Documentation: dt-bindings: Document STM32 ADC DT bindings
From: Rob Herring @ 2016-11-16 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479223861-21747-2-git-send-email-fabrice.gasnier@st.com>
On Tue, Nov 15, 2016 at 04:30:56PM +0100, Fabrice Gasnier wrote:
> This patch adds documentation of device tree bindings for the STM32 ADC.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> .../devicetree/bindings/iio/adc/st,stm32-adc.txt | 83 ++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH net 2/3] dt-bindings: net: add DT bindings for realtek phys
From: Jerome Brunet @ 2016-11-16 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116151104.5sfcqjyvrzre5pkn@rob-hp-laptop>
On Wed, 2016-11-16 at 09:11 -0600, Rob Herring wrote:
> On Tue, Nov 15, 2016 at 03:29:13PM +0100, Jerome Brunet wrote:
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> > ---
> > ?.../devicetree/bindings/net/realtek-phy.txt??????????| 20
> > ++++++++++++++++++++
> > ?1 file changed, 20 insertions(+)
> > ?create mode 100644 Documentation/devicetree/bindings/net/realtek-
> > phy.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/realtek-phy.txt
> > b/Documentation/devicetree/bindings/net/realtek-phy.txt
> > new file mode 100644
> > index 000000000000..dc2845a6b387
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/realtek-phy.txt
> > @@ -0,0 +1,20 @@
> > +Realtek Ethernet PHY
> > +
> > +Some boards require special tuning values of the phy.
> > +
> > +Optional properties:
> > +
> > +realtek,disable-eee-1000t:
> > +realtek,disable-eee-100tx:
>
> Make these generic/common.
Same feedback from the net folks. Will do.
Thx Rob
>
> >
> > +??If set, respectively disable 1000-BaseT and 100-BaseTx energy
> > efficient
> > +??ethernet capabilty advertisement
> > +??default: Leave the phy default settings unchanged (capabilities
> > advertised)
> > +
> > +Example:
> > +
> > +&mdio0 {
> > + ethernetphy0: ethernet-phy at 0 {
> > + reg = <0>;
> > + realtek,disable-eee-1000t;
> > + };
> > +};
> > --?
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > devicetree" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at??http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation
From: Arnd Bergmann @ 2016-11-16 15:20 UTC (permalink / raw)
To: linux-arm-kernel
This function clearly never worked and always returns true,
as pointed out by gcc-7:
arch/arm/mach-ux500/pm.c: In function 'prcmu_is_cpu_in_wfi':
arch/arm/mach-ux500/pm.c:137:212: error: ?: using integer constants in boolean context, the expression will always evaluate to 'true' [-Werror=int-in-bool-context]
With the added braces, the condition actually makes sense.
Fixes: 34fe6f107eab ("mfd : Check if the other db8500 core is in WFI")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-ux500/pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-ux500/pm.c b/arch/arm/mach-ux500/pm.c
index 8538910db202..a970e7fcba9e 100644
--- a/arch/arm/mach-ux500/pm.c
+++ b/arch/arm/mach-ux500/pm.c
@@ -134,8 +134,8 @@ bool prcmu_pending_irq(void)
*/
bool prcmu_is_cpu_in_wfi(int cpu)
{
- return readl(PRCM_ARM_WFI_STANDBY) & cpu ? PRCM_ARM_WFI_STANDBY_WFI1 :
- PRCM_ARM_WFI_STANDBY_WFI0;
+ return readl(PRCM_ARM_WFI_STANDBY) &
+ (cpu ? PRCM_ARM_WFI_STANDBY_WFI1 : PRCM_ARM_WFI_STANDBY_WFI0);
}
/*
--
2.9.0
^ permalink raw reply related
* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Ard Biesheuvel @ 2016-11-16 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116090838.6c540230@gandalf.local.home>
On 16 November 2016 at 14:08, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 16 Nov 2016 11:48:38 +0000
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> >
>> > Does that allay your concerns?
>> >
>>
>> Yes, it does. Thanks
>
> Does this mean I can pull this patch into my queue then?
>
Fine by me
Thanks,
Ard.
^ permalink raw reply
* [PATCH] iommu: mtk: add common-clk dependency
From: Arnd Bergmann @ 2016-11-16 15:28 UTC (permalink / raw)
To: linux-arm-kernel
After the MT2701 clock driver was added, we get a harmless warning for
the iommu driver that selects it, when compile-testing without
COMMON_CLK.
warning: (MTK_IOMMU_V1) selects COMMON_CLK_MT2701_IMGSYS which has unmet direct dependencies (COMMON_CLK)
Adding a dependency on COMMON_CLK avoids the warning.
Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 8ee54d71c7eb..bb537d06d319 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -346,7 +346,7 @@ config MTK_IOMMU
config MTK_IOMMU_V1
bool "MTK IOMMU Version 1 (M4U gen1) Support"
- depends on ARM
+ depends on ARM && COMMON_CLK
depends on ARCH_MEDIATEK || COMPILE_TEST
select ARM_DMA_USE_IOMMU
select IOMMU_API
--
2.9.0
^ permalink raw reply related
* [PATCH v8 00/16] ACPI IORT ARM SMMU support
From: Lorenzo Pieralisi @ 2016-11-16 15:29 UTC (permalink / raw)
To: linux-arm-kernel
This patch series is v8 of a previous posting:
https://lkml.org/lkml/2016/11/9/422
v7 -> v8
- Renamed fwnode iommu_ops registration API according to review
- Minor change in ARM SMMU driver DT/ACPI split
- Added review tags
v6 -> v7
- Rebased against v4.9-rc4
- Fixed IORT probing on ACPI systems with missing IORT table
- Fixed SMMUv1/v2 global interrupt detection
- Updated iommu_ops firmware look-up
v5 -> v6
- Rebased against v4.9-rc1
- Changed FWNODE_IOMMU to FWNODE_ACPI_STATIC
- Moved platform devices creation into IORT code
- Updated fwnode handling
- Added default dma masks initialization
v4 -> v5
- Added SMMUv1/v2 support
- Rebased against v4.8-rc5 and dependencies series
- Consolidated IORT platform devices creation
v3 -> v4
- Added single mapping API (for IORT named components)
- Fixed arm_smmu_iort_xlate() return value
- Reworked fwnode registration and platform device creation
ordering to fix probe ordering dependencies
- Added code to keep device_node ref count with new iommu
fwspec API
- Added patch to make iommu_fwspec arch agnostic
- Dropped RFC status
- Rebased against v4.8-rc2
v2 -> v3
- Rebased on top of dependencies series [1][2][3](v4.7-rc3)
- Added back reliance on ACPI early probing infrastructure
- Patch[1-3] merged through other dependent series
- Added back IOMMU fwnode generalization
- Move SMMU v3 static functions configuration to IORT code
- Implemented generic IOMMU fwspec API
- Added code to implement fwnode platform device look-up
v1 -> v2:
- Rebased on top of dependencies series [1][2][3](v4.7-rc1)
- Removed IOMMU fwnode generalization
- Implemented ARM SMMU v3 ACPI probing instead of ARM SMMU v2
owing to patch series dependencies [1]
- Moved platform device creation logic to IORT code to
generalize its usage for ARM SMMU v1-v2-v3 components
- Removed reliance on ACPI early device probing
- Created IORT specific iommu_xlate() translation hook leaving
OF code unchanged according to v1 reviews
The ACPI IORT table provides information that allows instantiating
ARM SMMU devices and carrying out id mappings between components on
ARM based systems (devices, IOMMUs, interrupt controllers).
http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
Building on basic IORT support, this patchset enables ARM SMMUs support
on ACPI systems.
Most of the code is aimed at building the required generic ACPI
infrastructure to create and enable IOMMU components and to bring
the IOMMU infrastructure for ACPI on par with DT, which is going to
make future ARM SMMU components easier to integrate.
PATCH (1) adds a FWNODE_ACPI_STATIC type to the struct fwnode_handle type.
It is required to attach a fwnode identifier to platform
devices allocated/detected through static ACPI table entries
(ie IORT tables entries).
IOMMU devices have to have an identifier to look them up
eg IOMMU core layer carrying out id translation. This can be
done through a fwnode_handle (ie IOMMU platform devices created
out of IORT tables are not ACPI devices hence they can't be
allocated as such, otherwise they would have a fwnode_handle of
type FWNODE_ACPI).
PATCH (2) makes use of the ACPI early probing API to add a linker script
section for probing devices via IORT ACPI kernel code.
PATCH (3) provides IORT support for registering IOMMU IORT node through
their fwnode handle.
PATCH (4) make of_iommu_{set/get}_ops() functions DT agnostic and
rename the registration API.
PATCH (5) convert ARM SMMU driver to use fwnode instead of of_node as
look-up and iommu_ops retrieval token.
PATCH (6) convert ARM SMMU v3 driver to use fwnode instead of of_node as
look-up and iommu_ops retrieval token.
PATCH (7) implements the of_dma_configure() API in ACPI world -
acpi_dma_configure() - and patches PCI and ACPI core code to
start making use of it.
PATCH (8) provides an IORT function to detect existence of specific type
of IORT components.
PATCH (9) creates the kernel infrastructure required to create ARM SMMU
platform devices for IORT nodes.
PATCH (10) refactors the ARM SMMU v3 driver so that the init functions are
split in a way that groups together code that probes through DT
and code that carries out HW registers FW agnostic probing, in
preparation for adding the ACPI probing path.
PATCH (11) adds ARM SMMU v3 IORT IOMMU operations to create and probe
ARM SMMU v3 components.
PATCH (12) refactors the ARM SMMU v1/v2 driver so that the init functions
are split in a way that groups together code that probes
through DT and code that carries out HW registers FW agnostic
probing, in preparation for adding the ACPI probing path.
PATCH (13) adds ARM SMMU v1/v2 IORT IOMMU operations to create and
probe ARM SMMU v1/v2 components.
PATCH (14) Extend the IORT iort_node_map_rid() to work on a type mask
instead of a single type so that the translation API can
be used on a range of components.
PATCH (15) Add IORT API to carry out id mappings for components that do
do not have an input identifier/RIDs (ie named components).
PATCH (16) provides IORT infrastructure to carry out IOMMU configuration
for devices and hook it up to the previously introduced ACPI
DMA configure API.
This patchset is provided for review/testing purposes here:
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/iort-smmu-v8
Tested on Juno and FVP models for ARM SMMU v1 and v3 probing path.
Lorenzo Pieralisi (16):
drivers: acpi: add FWNODE_ACPI_STATIC fwnode type
drivers: acpi: iort: introduce linker section for IORT entries probing
drivers: acpi: iort: add support for IOMMU fwnode registration
drivers: iommu: make of_iommu_set/get_ops() DT agnostic
drivers: iommu: arm-smmu: convert struct device of_node to fwnode
usage
drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode
usage
drivers: acpi: implement acpi_dma_configure
drivers: acpi: iort: add node match function
drivers: acpi: iort: add support for ARM SMMU platform devices
creation
drivers: iommu: arm-smmu-v3: split probe functions into DT/generic
portions
drivers: iommu: arm-smmu-v3: add IORT configuration
drivers: iommu: arm-smmu: split probe functions into DT/generic
portions
drivers: iommu: arm-smmu: add IORT configuration
drivers: acpi: iort: replace rid map type with type mask
drivers: acpi: iort: add single mapping function
drivers: acpi: iort: introduce iort_iommu_configure
drivers/acpi/arm64/iort.c | 595 +++++++++++++++++++++++++++++++++++++-
drivers/acpi/glue.c | 4 +-
drivers/acpi/scan.c | 45 +++
drivers/iommu/arm-smmu-v3.c | 105 +++++--
drivers/iommu/arm-smmu.c | 154 ++++++++--
drivers/iommu/iommu.c | 40 +++
drivers/iommu/of_iommu.c | 39 ---
drivers/pci/probe.c | 3 +-
include/acpi/acpi_bus.h | 2 +
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/acpi.h | 26 ++
include/linux/acpi_iort.h | 14 +
include/linux/fwnode.h | 3 +-
include/linux/iommu.h | 14 +
include/linux/of_iommu.h | 12 +-
15 files changed, 953 insertions(+), 104 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v8 01/16] drivers: acpi: add FWNODE_ACPI_STATIC fwnode type
From: Lorenzo Pieralisi @ 2016-11-16 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152936.22955-1-lorenzo.pieralisi@arm.com>
On systems booting with a device tree, every struct device is associated
with a struct device_node, that provides its DT firmware representation.
The device node can be used in generic kernel contexts (eg IRQ
translation, IOMMU streamid mapping), to retrieve the properties
associated with the device and carry out kernel operations accordingly.
Owing to the 1:1 relationship between the device and its device_node,
the device_node can also be used as a look-up token for the device (eg
looking up a device through its device_node), to retrieve the device in
kernel paths where the device_node is available.
On systems booting with ACPI, the same abstraction provided by
the device_node is required to provide look-up functionality.
The struct acpi_device, that represents firmware objects in the
ACPI namespace already includes a struct fwnode_handle of
type FWNODE_ACPI as their member; the same abstraction is missing
though for devices that are instantiated out of static ACPI tables
entries (eg ARM SMMU devices).
Add a new fwnode_handle type to associate devices created out
of static ACPI table entries to the respective firmware components
and create a simple ACPI core layer interface to dynamically allocate
and free the corresponding firmware nodes so that kernel subsystems
can use it to instantiate the nodes and associate them with the
respective devices.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
include/linux/acpi.h | 21 +++++++++++++++++++++
include/linux/fwnode.h | 3 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 689a8b9..6efb13c 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -56,6 +56,27 @@ static inline acpi_handle acpi_device_handle(struct acpi_device *adev)
acpi_fwnode_handle(adev) : NULL)
#define ACPI_HANDLE(dev) acpi_device_handle(ACPI_COMPANION(dev))
+static inline struct fwnode_handle *acpi_alloc_fwnode_static(void)
+{
+ struct fwnode_handle *fwnode;
+
+ fwnode = kzalloc(sizeof(struct fwnode_handle), GFP_KERNEL);
+ if (!fwnode)
+ return NULL;
+
+ fwnode->type = FWNODE_ACPI_STATIC;
+
+ return fwnode;
+}
+
+static inline void acpi_free_fwnode_static(struct fwnode_handle *fwnode)
+{
+ if (WARN_ON(!fwnode || fwnode->type != FWNODE_ACPI_STATIC))
+ return;
+
+ kfree(fwnode);
+}
+
/**
* ACPI_DEVICE_CLASS - macro used to describe an ACPI device with
* the PCI-defined class-code information
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 8516717..8bd28ce 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -17,8 +17,9 @@ enum fwnode_type {
FWNODE_OF,
FWNODE_ACPI,
FWNODE_ACPI_DATA,
+ FWNODE_ACPI_STATIC,
FWNODE_PDATA,
- FWNODE_IRQCHIP,
+ FWNODE_IRQCHIP
};
struct fwnode_handle {
--
2.10.0
^ permalink raw reply related
* [PATCH v8 02/16] drivers: acpi: iort: introduce linker section for IORT entries probing
From: Lorenzo Pieralisi @ 2016-11-16 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152936.22955-1-lorenzo.pieralisi@arm.com>
Since commit e647b532275b ("ACPI: Add early device probing
infrastructure") the kernel has gained the infrastructure that allows
adding linker script section entries to execute ACPI driver callbacks
(ie probe routines) for all subsystems that register a table entry
in the respective kernel section (eg clocksource, irqchip).
Since ARM IOMMU devices data is described through IORT tables when
booting with ACPI, the ARM IOMMU drivers must be made able to hook ACPI
callback routines that are called to probe IORT entries and initialize
the respective IOMMU devices.
To avoid adding driver specific hooks into IORT table initialization
code (breaking therefore code modularity - ie ACPI IORT code must be made
aware of ARM SMMU drivers ACPI init callbacks), this patch adds code
that allows ARM SMMU drivers to take advantage of the ACPI early probing
infrastructure, so that they can add linker script section entries
containing drivers callback to be executed on IORT tables detection.
Since IORT nodes are differentiated by a type, the callback routines
can easily parse the IORT table entries, check the IORT nodes and
carry out some actions whenever the IORT node type associated with
the driver specific callback is matched.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/acpi/arm64/iort.c | 13 ++++++++++---
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/acpi_iort.h | 3 +++
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 6b81746..2c46ebc 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -361,8 +361,15 @@ void __init acpi_iort_init(void)
acpi_status status;
status = acpi_get_table(ACPI_SIG_IORT, 0, &iort_table);
- if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
- const char *msg = acpi_format_exception(status);
- pr_err("Failed to get table, %s\n", msg);
+ if (ACPI_FAILURE(status)) {
+ if (status != AE_NOT_FOUND) {
+ const char *msg = acpi_format_exception(status);
+
+ pr_err("Failed to get table, %s\n", msg);
+ }
+
+ return;
}
+
+ acpi_probe_device_table(iort);
}
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 3074796..f9c9f3c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -563,6 +563,7 @@
IRQCHIP_OF_MATCH_TABLE() \
ACPI_PROBE_TABLE(irqchip) \
ACPI_PROBE_TABLE(clksrc) \
+ ACPI_PROBE_TABLE(iort) \
EARLYCON_TABLE()
#define INIT_TEXT \
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 0e32dac..d16fdda 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -39,4 +39,7 @@ static inline struct irq_domain *iort_get_device_domain(struct device *dev,
{ return NULL; }
#endif
+#define IORT_ACPI_DECLARE(name, table_id, fn) \
+ ACPI_DECLARE_PROBE_ENTRY(iort, name, table_id, 0, NULL, 0, fn)
+
#endif /* __ACPI_IORT_H__ */
--
2.10.0
^ permalink raw reply related
* [PATCH v8 03/16] drivers: acpi: iort: add support for IOMMU fwnode registration
From: Lorenzo Pieralisi @ 2016-11-16 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152936.22955-1-lorenzo.pieralisi@arm.com>
The ACPI IORT table provide entries for IOMMU (aka SMMU in ARM world)
components that allow creating the kernel data structures required to
probe and initialize the IOMMU devices.
This patch provides support in the IORT kernel code to register IOMMU
components and their respective fwnode.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
drivers/acpi/arm64/iort.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 2c46ebc..1ac2720 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -20,7 +20,9 @@
#include <linux/acpi_iort.h>
#include <linux/kernel.h>
+#include <linux/list.h>
#include <linux/pci.h>
+#include <linux/slab.h>
struct iort_its_msi_chip {
struct list_head list;
@@ -28,6 +30,90 @@ struct iort_its_msi_chip {
u32 translation_id;
};
+struct iort_fwnode {
+ struct list_head list;
+ struct acpi_iort_node *iort_node;
+ struct fwnode_handle *fwnode;
+};
+static LIST_HEAD(iort_fwnode_list);
+static DEFINE_SPINLOCK(iort_fwnode_lock);
+
+/**
+ * iort_set_fwnode() - Create iort_fwnode and use it to register
+ * iommu data in the iort_fwnode_list
+ *
+ * @node: IORT table node associated with the IOMMU
+ * @fwnode: fwnode associated with the IORT node
+ *
+ * Returns: 0 on success
+ * <0 on failure
+ */
+static inline int iort_set_fwnode(struct acpi_iort_node *iort_node,
+ struct fwnode_handle *fwnode)
+{
+ struct iort_fwnode *np;
+
+ np = kzalloc(sizeof(struct iort_fwnode), GFP_ATOMIC);
+
+ if (WARN_ON(!np))
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&np->list);
+ np->iort_node = iort_node;
+ np->fwnode = fwnode;
+
+ spin_lock(&iort_fwnode_lock);
+ list_add_tail(&np->list, &iort_fwnode_list);
+ spin_unlock(&iort_fwnode_lock);
+
+ return 0;
+}
+
+/**
+ * iort_get_fwnode() - Retrieve fwnode associated with an IORT node
+ *
+ * @node: IORT table node to be looked-up
+ *
+ * Returns: fwnode_handle pointer on success, NULL on failure
+ */
+static inline
+struct fwnode_handle *iort_get_fwnode(struct acpi_iort_node *node)
+{
+ struct iort_fwnode *curr;
+ struct fwnode_handle *fwnode = NULL;
+
+ spin_lock(&iort_fwnode_lock);
+ list_for_each_entry(curr, &iort_fwnode_list, list) {
+ if (curr->iort_node == node) {
+ fwnode = curr->fwnode;
+ break;
+ }
+ }
+ spin_unlock(&iort_fwnode_lock);
+
+ return fwnode;
+}
+
+/**
+ * iort_delete_fwnode() - Delete fwnode associated with an IORT node
+ *
+ * @node: IORT table node associated with fwnode to delete
+ */
+static inline void iort_delete_fwnode(struct acpi_iort_node *node)
+{
+ struct iort_fwnode *curr, *tmp;
+
+ spin_lock(&iort_fwnode_lock);
+ list_for_each_entry_safe(curr, tmp, &iort_fwnode_list, list) {
+ if (curr->iort_node == node) {
+ list_del(&curr->list);
+ kfree(curr);
+ break;
+ }
+ }
+ spin_unlock(&iort_fwnode_lock);
+}
+
typedef acpi_status (*iort_find_node_callback)
(struct acpi_iort_node *node, void *context);
--
2.10.0
^ permalink raw reply related
* [PATCH v8 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Lorenzo Pieralisi @ 2016-11-16 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152936.22955-1-lorenzo.pieralisi@arm.com>
The of_iommu_{set/get}_ops() API is used to associate a device
tree node with a specific set of IOMMU operations. The same
kernel interface is required on systems booting with ACPI, where
devices are not associated with a device tree node, therefore
the interface requires generalization.
The struct device fwnode member represents the fwnode token associated
with the device and the struct it points at is firmware specific;
regardless, it is initialized on both ACPI and DT systems and makes an
ideal candidate to use it to associate a set of IOMMU operations to a
given device, through its struct device.fwnode member pointer, paving
the way for representing per-device iommu_ops (ie an iommu instance
associated with a device).
Convert the DT specific of_iommu_{set/get}_ops() interface to
use struct device.fwnode as a look-up token, making the interface
usable on ACPI systems and rename the data structures and the
registration API so that they are made to represent their usage
more clearly.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
---
drivers/iommu/iommu.c | 40 ++++++++++++++++++++++++++++++++++++++++
drivers/iommu/of_iommu.c | 39 ---------------------------------------
include/linux/iommu.h | 14 ++++++++++++++
include/linux/of_iommu.h | 12 ++++++++++--
4 files changed, 64 insertions(+), 41 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 9a2f196..8d3e847 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1615,6 +1615,46 @@ int iommu_request_dm_for_dev(struct device *dev)
return ret;
}
+struct iommu_instance {
+ struct list_head list;
+ struct fwnode_handle *fwnode;
+ const struct iommu_ops *ops;
+};
+static LIST_HEAD(iommu_instance_list);
+static DEFINE_SPINLOCK(iommu_instance_lock);
+
+void iommu_register_instance(struct fwnode_handle *fwnode,
+ const struct iommu_ops *ops)
+{
+ struct iommu_instance *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
+
+ if (WARN_ON(!iommu))
+ return;
+
+ of_node_get(to_of_node(fwnode));
+ INIT_LIST_HEAD(&iommu->list);
+ iommu->fwnode = fwnode;
+ iommu->ops = ops;
+ spin_lock(&iommu_instance_lock);
+ list_add_tail(&iommu->list, &iommu_instance_list);
+ spin_unlock(&iommu_instance_lock);
+}
+
+const struct iommu_ops *iommu_get_instance(struct fwnode_handle *fwnode)
+{
+ struct iommu_instance *instance;
+ const struct iommu_ops *ops = NULL;
+
+ spin_lock(&iommu_instance_lock);
+ list_for_each_entry(instance, &iommu_instance_list, list)
+ if (instance->fwnode == fwnode) {
+ ops = instance->ops;
+ break;
+ }
+ spin_unlock(&iommu_instance_lock);
+ return ops;
+}
+
int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
const struct iommu_ops *ops)
{
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5b82862..0f57ddc 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -96,45 +96,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
}
EXPORT_SYMBOL_GPL(of_get_dma_window);
-struct of_iommu_node {
- struct list_head list;
- struct device_node *np;
- const struct iommu_ops *ops;
-};
-static LIST_HEAD(of_iommu_list);
-static DEFINE_SPINLOCK(of_iommu_lock);
-
-void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops)
-{
- struct of_iommu_node *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
-
- if (WARN_ON(!iommu))
- return;
-
- of_node_get(np);
- INIT_LIST_HEAD(&iommu->list);
- iommu->np = np;
- iommu->ops = ops;
- spin_lock(&of_iommu_lock);
- list_add_tail(&iommu->list, &of_iommu_list);
- spin_unlock(&of_iommu_lock);
-}
-
-const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
-{
- struct of_iommu_node *node;
- const struct iommu_ops *ops = NULL;
-
- spin_lock(&of_iommu_lock);
- list_for_each_entry(node, &of_iommu_list, list)
- if (node->np == np) {
- ops = node->ops;
- break;
- }
- spin_unlock(&of_iommu_lock);
- return ops;
-}
-
static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
{
struct of_phandle_args *iommu_spec = data;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 436dc21..f2960e4 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -351,6 +351,9 @@ int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
const struct iommu_ops *ops);
void iommu_fwspec_free(struct device *dev);
int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
+void iommu_register_instance(struct fwnode_handle *fwnode,
+ const struct iommu_ops *ops);
+const struct iommu_ops *iommu_get_instance(struct fwnode_handle *fwnode);
#else /* CONFIG_IOMMU_API */
@@ -580,6 +583,17 @@ static inline int iommu_fwspec_add_ids(struct device *dev, u32 *ids,
return -ENODEV;
}
+static inline void iommu_register_instance(struct fwnode_handle *fwnode,
+ const struct iommu_ops *ops)
+{
+}
+
+static inline
+const struct iommu_ops *iommu_get_instance(struct fwnode_handle *fwnode)
+{
+ return NULL;
+}
+
#endif /* CONFIG_IOMMU_API */
#endif /* __LINUX_IOMMU_H */
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index e80b9c7..6a7fc50 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -31,8 +31,16 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
#endif /* CONFIG_OF_IOMMU */
-void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops);
-const struct iommu_ops *of_iommu_get_ops(struct device_node *np);
+static inline void of_iommu_set_ops(struct device_node *np,
+ const struct iommu_ops *ops)
+{
+ iommu_register_instance(&np->fwnode, ops);
+}
+
+static inline const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
+{
+ return iommu_get_instance(&np->fwnode);
+}
extern struct of_device_id __iommu_of_table;
--
2.10.0
^ permalink raw reply related
* [PATCH v8 05/16] drivers: iommu: arm-smmu: convert struct device of_node to fwnode usage
From: Lorenzo Pieralisi @ 2016-11-16 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152936.22955-1-lorenzo.pieralisi@arm.com>
Current ARM SMMU driver rely on the struct device.of_node pointer for
device look-up and iommu_ops retrieval.
In preparation for ACPI probing enablement, convert the driver to use
the struct device.fwnode member for device and iommu_ops look-up so that
the driver infrastructure can be used also on systems that do not
associate an of_node pointer to a struct device (eg ACPI), making the
device look-up and iommu_ops retrieval firmware agnostic.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 8f72814..339a8d3 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1379,13 +1379,14 @@ static bool arm_smmu_capable(enum iommu_cap cap)
static int arm_smmu_match_node(struct device *dev, void *data)
{
- return dev->of_node == data;
+ return dev->fwnode == data;
}
-static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
+static
+struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
{
struct device *dev = driver_find_device(&arm_smmu_driver.driver, NULL,
- np, arm_smmu_match_node);
+ fwnode, arm_smmu_match_node);
put_device(dev);
return dev ? dev_get_drvdata(dev) : NULL;
}
@@ -1403,7 +1404,7 @@ static int arm_smmu_add_device(struct device *dev)
if (ret)
goto out_free;
} else if (fwspec && fwspec->ops == &arm_smmu_ops) {
- smmu = arm_smmu_get_by_node(to_of_node(fwspec->iommu_fwnode));
+ smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
} else {
return -ENODEV;
}
@@ -2007,7 +2008,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
}
}
- of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
+ iommu_register_instance(dev->fwnode, &arm_smmu_ops);
platform_set_drvdata(pdev, smmu);
arm_smmu_device_reset(smmu);
--
2.10.0
^ permalink raw reply related
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