* Summary of LPC guest MSI discussion in Santa Fe
From: Christoffer Dall @ 2016-11-09 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582371FB.2040808@redhat.com>
On Wed, Nov 09, 2016 at 01:59:07PM -0500, Don Dutile wrote:
> On 11/09/2016 12:03 PM, Will Deacon wrote:
> >On Tue, Nov 08, 2016 at 09:52:33PM -0500, Don Dutile wrote:
> >>On 11/08/2016 06:35 PM, Alex Williamson wrote:
> >>>On Tue, 8 Nov 2016 21:29:22 +0100
> >>>Christoffer Dall <christoffer.dall@linaro.org> wrote:
> >>>>Is my understanding correct, that you need to tell userspace about the
> >>>>location of the doorbell (in the IOVA space) in case (2), because even
> >>>>though the configuration of the device is handled by the (host) kernel
> >>>>through trapping of the BARs, we have to avoid the VFIO user programming
> >>>>the device to create other DMA transactions to this particular address,
> >>>>since that will obviously conflict and either not produce the desired
> >>>>DMA transactions or result in unintended weird interrupts?
> >
> >Yes, that's the crux of the issue.
> >
> >>>Correct, if the MSI doorbell IOVA range overlaps RAM in the VM, then
> >>>it's potentially a DMA target and we'll get bogus data on DMA read from
> >>>the device, and lose data and potentially trigger spurious interrupts on
> >>>DMA write from the device. Thanks,
> >>>
> >>That's b/c the MSI doorbells are not positioned *above* the SMMU, i.e.,
> >>they address match before the SMMU checks are done. if
> >>all DMA addrs had to go through SMMU first, then the DMA access could
> >>be ignored/rejected.
> >
> >That's actually not true :( The SMMU can't generally distinguish between MSI
> >writes and DMA writes, so it would just see a write transaction to the
> >doorbell address, regardless of how it was generated by the endpoint.
> >
> >Will
> >
> So, we have real systems where MSI doorbells are placed at the same IOVA
> that could have memory for a guest
I don't think this is a property of a hardware system. THe problem is
userspace not knowing where in the IOVA space the kernel is going to
place the doorbell, so you can end up (basically by chance) that some
IPA range of guest memory overlaps with the IOVA space for the doorbell.
>, but not at the same IOVA as memory on real hw ?
On real hardware without an IOMMU the system designer would have to
separate the IOVA and RAM in the physical address space. With an IOMMU,
the SMMU driver just makes sure to allocate separate regions in the IOVA
space.
The challenge, as I understand it, happens with the VM, because the VM
doesn't allocate the IOVA for the MSI doorbell itself, but the host
kernel does this, independently from the attributes (e.g. memory map) of
the VM.
Because the IOVA is a single resource, but with two independent entities
allocating chunks of it (the host kernel for the MSI doorbell IOVA, and
the VFIO user for other DMA operations), you have to provide some
coordination between those to entities to avoid conflicts. In the case
of KVM, the two entities are the host kernel and the VFIO user (QEMU/the
VM), and the host kernel informs the VFIO user to never attempt to use
the doorbell IOVA already reserved by the host kernel for DMA.
One way to do that is to ensure that the IPA space of the VFIO user
corresponding to the doorbell IOVA is simply not valid, ie. the reserved
regions that avoid for example QEMU to allocate RAM there.
(I suppose it's technically possible to get around this issue by letting
QEMU place RAM wherever it wants but tell the guest to never use a
particular subset of its RAM for DMA, because that would conflict with
the doorbell IOVA or be seen as p2p transactions. But I think we all
probably agree that it's a disgusting idea.)
> How are memory holes passed to SMMU so it doesn't have this issue for bare-metal
> (assign an IOVA that overlaps an MSI doorbell address)?
>
As I understand it, the SMMU driver manages the whole IOVA space when
VFIO is *not* involved, so it simply allocates non-overlapping regions.
The problem occurs when you have two independent entities essentially
attempting to mange the same resource (and the problem is exacerbated by
the VM potentially allocating slots in the IOVA space which may have
other limitations it doesn't know about, for example the p2p regions,
because the VM doesn't know anything about the topology of the
underlying physical system).
Christoffer
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Tony Lindgren @ 2016-11-09 19:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
the sysfs brightness attr for changes.") breaks runtime PM for me.
On my omap dm3730 based test system, idle power consumption is over 70
times higher now with this patch! It goes from about 6mW for the core
system to over 440mW during idle meaning there's some busy timer now
active.
Reverting this patch fixes the issue. Any ideas?
Regards,
Tony
^ permalink raw reply
* [PATCH 2/3] ipmi/bt-bmc: maintain a request expiry list
From: Cédric Le Goater @ 2016-11-09 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1e0187c4-d503-ce4a-3d4c-cf21f0bffb96@acm.org>
On 11/09/2016 04:52 PM, Corey Minyard wrote:
> On 11/09/2016 08:30 AM, C?dric Le Goater wrote:
>> On 11/07/2016 08:04 PM, Corey Minyard wrote:
>>> On 11/02/2016 02:57 AM, C?dric Le Goater wrote:
>>>> Regarding the response expiration handling, the IPMI spec says :
>>>>
>>>> The BMC must not return a given response once the corresponding
>>>> Request-to-Response interval has passed. The BMC can ensure this
>>>> by maintaining its own internal list of outstanding requests through
>>>> the interface. The BMC could age and expire the entries in the list
>>>> by expiring the entries at an interval that is somewhat shorter than
>>>> the specified Request-to-Response interval....
>>>>
>>>> To handle such case, we maintain list of received requests using the
>>>> seq number of the BT message to identify them. The list is updated
>>>> each time a request is received and a response is sent. The expiration
>>>> of the reponses is handled at each updates but also with a timer.
>>> This looks correct, but it seems awfully complicated.
>>>
>>> Why can't you get the current time before the wait_event_interruptible()
>>> and then compare the time before you do the write? That would seem to
>>> accomplish the same thing without any lists or extra locks.
>> Well, the expiry list needs a request identifier and it is currently using
>> the Seq byte for this purpose. So the BT message needs to be read to grab
>> that byte. The request is added to a list and that involves some locking.
>>
>> When the response is written, the first matching request is removed from
>> the list and a garbage collector loop is also run. Then, as we might not
>> get any responses to run that loop, we use a timer to empty the list from
>> any expired requests.
>>
>> The read/write ops of the driver are protected with a mutex, the list and
>> the timer add their share of locking. That could have been done with RCU
>> surely but we don't really need performance in this driver.
>>
>> Caveats :
>>
>> bt_bmc_remove_request() should not be done in the writing loop though.
>> It needs a fix.
>>
>> The request identifier is currently Seq but the spec say we should use
>> Seq, NetFn, and Command or an internal Seq value as a request identifier.
>> Google is also working on an OEM/Group extension (Brendan in CC: )
>> which has a different message format. I need to look closer at what
>> should be done in this case.
>
> I'm still not sure why the list is necessary. You have a separate
> thread of execution for each writer, why not just time it in that
> thread?
No, we don't in the current design. This is only a single process
acting as a proxy and dispatching commands on dbus to other
processes doing whatever they need to do. So the request/responses
can interlace.
The current daemon already handles an expiry list but I thought it
would be better to move it in the kernel to have a better response
time. The BMC can be quite slow when busy. It seems that keeping
the logic in user space is better. So let's have it that way. Not
a problem.
> What about the following, not even compile-tested, patch? I'm
> sure my mailer will munge this up, I can send you a clean version
> if you like.
No it is ok. I will give your fix a try on our system and resend.
Thanks,
C.
> From 1a73585a9c1c74ac1d59d82f22e05b30447619a6 Mon Sep 17 00:00:00 2001
> From: Corey Minyard <cminyard@mvista.com>
> Date: Wed, 9 Nov 2016 09:07:48 -0600
> Subject: [PATCH] ipmi:bt-bmc: Fix a multi-user race, time out responses
>
> The IPMI spec says to time out responses after a given amount of
> time, so don't let a writer send something after an amount of time
> has elapsed.
>
> Also, fix a race condition in the same area where if you have two
> writers at the same time, one can get a EIO return when it should
> still be waiting its turn to send. A mutex_lock_interruptible_timeout()
> would be handy here, but it doesn't exist.
>
> Signed-off-by: Corey Minyard <cminyard@mvista.com>
> ---
> drivers/char/ipmi/bt-bmc.c | 39 ++++++++++++++++++++++++---------------
> 1 file changed, 24 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
> index b49e613..5be94cf 100644
> --- a/drivers/char/ipmi/bt-bmc.c
> +++ b/drivers/char/ipmi/bt-bmc.c
> @@ -57,6 +57,8 @@
>
> #define BT_BMC_BUFFER_SIZE 256
>
> +#define BT_BMC_RESPONSE_JIFFIES (5 * HZ)
> +
> struct bt_bmc {
> struct device dev;
> struct miscdevice miscdev;
> @@ -190,14 +192,12 @@ static ssize_t bt_bmc_read(struct file *file, char __user *buf,
>
> WARN_ON(*ppos);
>
> - if (wait_event_interruptible(bt_bmc->queue,
> - bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_H2B_ATN))
> + if (mutex_lock_interruptible(&bt_bmc->mutex))
> return -ERESTARTSYS;
>
> - mutex_lock(&bt_bmc->mutex);
> -
> - if (unlikely(!(bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_H2B_ATN))) {
> - ret = -EIO;
> + if (wait_event_interruptible(bt_bmc->queue,
> + bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_H2B_ATN)) {
> + ret = -ERESTARTSYS;
> goto out_unlock;
> }
>
> @@ -251,6 +251,7 @@ static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
> u8 kbuffer[BT_BMC_BUFFER_SIZE];
> ssize_t ret = 0;
> ssize_t nwritten;
> + unsigned long start_jiffies = jiffies, wait_time;
>
> /*
> * send a minimum response size
> @@ -263,23 +264,31 @@ static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
>
> WARN_ON(*ppos);
>
> + if (mutex_lock_interruptible(&bt_bmc->mutex))
> + return -ERESTARTSYS;
> +
> + wait_time = jiffies - start_jiffies;
> + if (wait_time >= BT_BMC_RESPONSE_TIME_JIFFIES) {
> + ret = -ETIMEDOUT;
> + goto out_unlock;
> + }
> + wait_time = BT_BMC_RESPONSE_TIME_JIFFIES - wait_time;
> +
> /*
> * There's no interrupt for clearing bmc busy so we have to
> * poll
> */
> - if (wait_event_interruptible(bt_bmc->queue,
> + ret = wait_event_interruptible_timeout(bt_bmc->queue,
> !(bt_inb(bt_bmc, BT_CTRL) &
> - (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN))))
> - return -ERESTARTSYS;
> -
> - mutex_lock(&bt_bmc->mutex);
> -
> - if (unlikely(bt_inb(bt_bmc, BT_CTRL) &
> - (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN))) {
> - ret = -EIO;
> + (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN)),
> + wait_time);
> + if (ret <= 0) {
> + if (ret == 0)
> + ret = -ETIMEDOUT;
> goto out_unlock;
> }
>
> + ret = 0;
> clr_wr_ptr(bt_bmc);
>
> while (count) {
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Don Dutile @ 2016-11-09 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109170326.GG17771@arm.com>
On 11/09/2016 12:03 PM, Will Deacon wrote:
> On Tue, Nov 08, 2016 at 09:52:33PM -0500, Don Dutile wrote:
>> On 11/08/2016 06:35 PM, Alex Williamson wrote:
>>> On Tue, 8 Nov 2016 21:29:22 +0100
>>> Christoffer Dall <christoffer.dall@linaro.org> wrote:
>>>> Is my understanding correct, that you need to tell userspace about the
>>>> location of the doorbell (in the IOVA space) in case (2), because even
>>>> though the configuration of the device is handled by the (host) kernel
>>>> through trapping of the BARs, we have to avoid the VFIO user programming
>>>> the device to create other DMA transactions to this particular address,
>>>> since that will obviously conflict and either not produce the desired
>>>> DMA transactions or result in unintended weird interrupts?
>
> Yes, that's the crux of the issue.
>
>>> Correct, if the MSI doorbell IOVA range overlaps RAM in the VM, then
>>> it's potentially a DMA target and we'll get bogus data on DMA read from
>>> the device, and lose data and potentially trigger spurious interrupts on
>>> DMA write from the device. Thanks,
>>>
>> That's b/c the MSI doorbells are not positioned *above* the SMMU, i.e.,
>> they address match before the SMMU checks are done. if
>> all DMA addrs had to go through SMMU first, then the DMA access could
>> be ignored/rejected.
>
> That's actually not true :( The SMMU can't generally distinguish between MSI
> writes and DMA writes, so it would just see a write transaction to the
> doorbell address, regardless of how it was generated by the endpoint.
>
> Will
>
So, we have real systems where MSI doorbells are placed at the same IOVA
that could have memory for a guest, but not at the same IOVA as memory on real hw ?
How are memory holes passed to SMMU so it doesn't have this issue for bare-metal
(assign an IOVA that overlaps an MSI doorbell address)?
^ permalink raw reply
* [PATCH 00/13] mmc: dw_mmc: cleans the codes for dwmmc controller
From: Heiko Stuebner @ 2016-11-09 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:22 CET schrieb Jaehoon Chung:
> This patchset is modified the some minor fixing and cleaning code.
> If needs to split the patches, i will re-send the patches.
>
> * Major changes
> - Use the cookie enum values like sdhci controller.
> - Remove the unnecessary codes and use stop_abort() by default.
> - Remove the obsoleted property "supports-highspeed"
> - Remove the "clock-freq-min-max" property. Instead, use "max-frequency"
> - Minimum clock value is set to 100K by default.
>
> Jaehoon Chung (13):
> mmc: dw_mmc: display the real register value on debugfs
> mmc: dw_mmc: fix the debug message for checking card's present
> mmc: dw_mmc: change the DW_MCI_FREQ_MIN from 400K to 100K
> mmc: dw_mmc: use the hold register when send stop command
> mmc: dw_mmc: call the dw_mci_prep_stop_abort() by default
> mmc: core: move the cookie's enum values from sdhci.h to mmc.h
> mmc: dw_mmc: use the cookie's enum values for post/pre_req()
> mmc: dw_mmc: remove the unnecessary mmc_data structure
patches 1-8 on rk3036, rk3288, rk3368 and rk3399 Rockchip platforms
Tested-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: add nand controller nodes
From: Dinh Nguyen @ 2016-11-09 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109073501.2010-1-s.trumtrar@pengutronix.de>
On 11/09/2016 01:35 AM, Steffen Trumtrar wrote:
> Add the denali nand controller to the socfpga dtsi.
>
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> ---
> arch/arm/boot/dts/socfpga.dtsi | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> index 9f48141270b8..6b0c23ca5e88 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -700,6 +700,19 @@
> status = "disabled";
> };
>
> + nand0: nand at ff900000 {
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + compatible = "denali,denali-nand-dt";
> + reg = <0xff900000 0x100000>,
> + <0xffb80000 0x10000>;
> + reg-names = "nand_data", "denali_reg";
> + interrupts = <0x0 0x90 0x4>;
> + dma-mask = <0xffffffff>;
> + clocks = <&nand_clk>;
> + status = "disabled";
> + };
> +
> ocram: sram at ffff0000 {
> compatible = "mmio-sram";
> reg = <0xffff0000 0x10000>;
>
Since there's only 1 NAND node, do we need to call the node "nand0"? No
need to resend a patch, I can change it locally if we agree that the
node should be just:
nand: nand at ff900000
Dinh
^ permalink raw reply
* [PATCH 01/30] usb: dwc2: Deprecate g-use-dma binding
From: John Youn @ 2016-11-09 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zil9gkcq.fsf@linux.intel.com>
On 11/8/2016 11:54 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn <John.Youn@synopsys.com> writes:
>> On 11/8/2016 1:12 AM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> John Youn <johnyoun@synopsys.com> writes:
>>>> Add a vendor prefix and make the name more consistent by renaming it to
>>>> "snps,gadget-dma-enable".
>>>>
>>>> Signed-off-by: John Youn <johnyoun@synopsys.com>
>>>> ---
>>>> Documentation/devicetree/bindings/usb/dwc2.txt | 5 ++++-
>>>> arch/arm/boot/dts/rk3036.dtsi | 2 +-
>>>> arch/arm/boot/dts/rk3288.dtsi | 2 +-
>>>> arch/arm/boot/dts/rk3xxx.dtsi | 2 +-
>>>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 +-
>>>> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +-
>>>> drivers/usb/dwc2/params.c | 9 ++++++++-
>>>> drivers/usb/dwc2/pci.c | 2 +-
>>>> 8 files changed, 18 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> index 9472111..389a461 100644
>>>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> @@ -26,11 +26,14 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties
>>>> - dr_mode: shall be one of "host", "peripheral" and "otg"
>>>> Refer to usb/generic.txt
>>>> - snps,host-dma-disable: disable host DMA mode.
>>>> -- g-use-dma: enable dma usage in gadget driver.
>>>> +- snps,gadget-dma-enable: enable gadget DMA mode.
>>>
>>> I don't see why you even have this binding. Looking through the code,
>>> you have:
>>>
>>> #define GHWCFG2_SLAVE_ONLY_ARCH 0
>>> #define GHWCFG2_EXT_DMA_ARCH 1
>>> #define GHWCFG2_INT_DMA_ARCH 2
>>>
>>> void dwc2_set_param_dma_enable(struct dwc2_hsotg *hsotg, int val)
>>> {
>>> int valid = 1;
>>>
>>> if (val > 0 && hsotg->hw_params.arch == GHWCFG2_SLAVE_ONLY_ARCH)
>>> valid = 0;
>>> if (val < 0)
>>> valid = 0;
>>>
>>> if (!valid) {
>>> if (val >= 0)
>>> dev_err(hsotg->dev,
>>> "%d invalid for dma_enable parameter. Check HW configuration.\n",
>>> val);
>>> val = hsotg->hw_params.arch != GHWCFG2_SLAVE_ONLY_ARCH;
>>> dev_dbg(hsotg->dev, "Setting dma_enable to %d\n", val);
>>> }
>>>
>>> hsotg->core_params->dma_enable = val;
>>> }
>>>
>>> which seems to hint that DMA support is discoverable. If there is DMA,
>>> why would disable it?
>>>
>>
>> Yes that's the case and I would prefer to make it discoverable and
>> enabled by default.
>>
>> But the legacy behavior has always been like this because DMA was
>> never fully implemented in the gadget driver and it was an opt-in
>> feature. Periodic support was only added recently.
>
> legacy behavior can be changed if another 'policy' makes more
> sense. IMHO, whatever can be discovered in runtime, should be enabled by
> default. That way, we force people to use it and find bugs in certain
> features.
Sounds good to me. I'll make the changes.
Regards,
John
^ permalink raw reply
* [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Scott Branden @ 2016-11-09 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <132c772b-d4b9-c4b6-2eca-0393e7c995f9@broadcom.com>
Hi Adrian/Ulf,
Please ignore my comments in last email I sent out. The v2 patch
documentation matches the code and is good. I am confusing myself
between internal versions and external upstream versions of this code.
On 16-11-09 10:38 AM, Scott Branden wrote:
> Hi Adrian/Ulf,
>
> On 16-11-08 01:55 AM, Adrian Hunter wrote:
>> On 01/11/16 18:37, Scott Branden wrote:
>>> Add bytewise register accesses support for newer versions of IPROC
>>> SDHCI controllers.
>>> Previous sdhci-iproc versions of SDIO controllers
>>> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
>>> accesses.
>>>
>>> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>
>> This is unchanged from V1 which I acked, so:
> I updated the binding name in the documentation but forgot to change it
> in this patch. Now that Rob has ack'd the binding documentation I will
> send out an updated patch with binding string in the code matching the
> ack'd documentation.
Ignore this - PATCH v2 is good.
>
>>
>> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
>>
> With the minor change I will add your ack to the next version I send out.
>
> Thanks,
> Scott
^ permalink raw reply
* KASAN & the vmalloc area
From: Dmitry Vyukov @ 2016-11-09 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109183017.GA837@leverpostej>
On Wed, Nov 9, 2016 at 10:30 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> >> I've seen the same iteration slowness problem on x86 with
>> >> CONFIG_DEBUG_RODATA which walks all pages. The is about 1 minute, but
>> >> it is enough to trigger rcu stall warning.
>> >
>> > Interesting; do you know where that happens? I can't spot any obvious
>> > case where we'd have to walk all the page tables for DEBUG_RODATA.
>>
>> As far as I remember it was this path:
>>
>> mark_readonly in main.c -> mark_rodata_ro -> debug_checkwx ->
>> ptdump_walk_pgd_level_checkwx -> ptdump_walk_pgd_level_core.
>
> Ah, that's x86's equivalent DEBUG_WX checks.
>
>> >> The zero pud and vmalloc-ed stacks looks like different problems.
>> >> To overcome the slowness we could map zero shadow for vmalloc area lazily.
>> >> However for vmalloc-ed stacks we need to map actual memory, because
>> >> stack instrumentation will read/write into the shadow.
>> >
>> > Sure. The point I was trying to make is that there' be fewer page tables
>> > to walk (unless the vmalloc area was exhausted), assuming we also lazily
>> > mapped the common zero shadow for the vmalloc area.
>> >
>> >> One downside here is that vmalloc shadow can be as large as 1:1 (if we
>> >> allocate 1 page in vmalloc area we need to allocate 1 page for
>> >> shadow).
>> >
>> > I thought per prior discussion we'd only need to allocate new pages for
>> > the stacks in the vmalloc region, and we could re-use the zero pages?
>>
>> We can't reuse zero ro pages for stacks, because stack instrumentation
>> writes to stack shadow.
>
> Sorry, I'd meant we'd use the zero pages for everything else but stacks.
> I understand we'd have to allocate real shadow for the stacks.
>
>> When we have a large continuous range of memory, shadow for it is
>> 1/8th. However, if we have a separate page, we will need to map whole
>> page of shadow for it, i.e. 1:1 shadow overhead.
>
> Sure, but for everything but stacks we can re-use the same zero pages,
> no?
>
> For everything else, the cost would be dominated by the page tables for
> the shadow.
Can we estimate the memory overhead?
^ permalink raw reply
* [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Scott Branden @ 2016-11-09 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c94dc018-5a2d-d50b-5746-43ae7fc258ce@intel.com>
Hi Adrian/Ulf,
On 16-11-08 01:55 AM, Adrian Hunter wrote:
> On 01/11/16 18:37, Scott Branden wrote:
>> Add bytewise register accesses support for newer versions of IPROC
>> SDHCI controllers.
>> Previous sdhci-iproc versions of SDIO controllers
>> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
>> accesses.
>>
>> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>
> This is unchanged from V1 which I acked, so:
I updated the binding name in the documentation but forgot to change it
in this patch. Now that Rob has ack'd the binding documentation I will
send out an updated patch with binding string in the code matching the
ack'd documentation.
>
> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
>
With the minor change I will add your ack to the next version I send out.
Thanks,
Scott
^ permalink raw reply
* KASAN & the vmalloc area
From: Mark Rutland @ 2016-11-09 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACT4Y+Ye+nxj=bQ9q9V2nEUpO+3sSWN1E2d_0KZapYyxx0Y69Q@mail.gmail.com>
On Wed, Nov 09, 2016 at 10:16:03AM -0800, Dmitry Vyukov wrote:
> On Wed, Nov 9, 2016 at 2:56 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Nov 08, 2016 at 02:09:27PM -0800, Dmitry Vyukov wrote:
> >> On Tue, Nov 8, 2016 at 11:03 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> >> I've seen the same iteration slowness problem on x86 with
> >> CONFIG_DEBUG_RODATA which walks all pages. The is about 1 minute, but
> >> it is enough to trigger rcu stall warning.
> >
> > Interesting; do you know where that happens? I can't spot any obvious
> > case where we'd have to walk all the page tables for DEBUG_RODATA.
>
> As far as I remember it was this path:
>
> mark_readonly in main.c -> mark_rodata_ro -> debug_checkwx ->
> ptdump_walk_pgd_level_checkwx -> ptdump_walk_pgd_level_core.
Ah, that's x86's equivalent DEBUG_WX checks.
> >> The zero pud and vmalloc-ed stacks looks like different problems.
> >> To overcome the slowness we could map zero shadow for vmalloc area lazily.
> >> However for vmalloc-ed stacks we need to map actual memory, because
> >> stack instrumentation will read/write into the shadow.
> >
> > Sure. The point I was trying to make is that there' be fewer page tables
> > to walk (unless the vmalloc area was exhausted), assuming we also lazily
> > mapped the common zero shadow for the vmalloc area.
> >
> >> One downside here is that vmalloc shadow can be as large as 1:1 (if we
> >> allocate 1 page in vmalloc area we need to allocate 1 page for
> >> shadow).
> >
> > I thought per prior discussion we'd only need to allocate new pages for
> > the stacks in the vmalloc region, and we could re-use the zero pages?
>
> We can't reuse zero ro pages for stacks, because stack instrumentation
> writes to stack shadow.
Sorry, I'd meant we'd use the zero pages for everything else but stacks.
I understand we'd have to allocate real shadow for the stacks.
> When we have a large continuous range of memory, shadow for it is
> 1/8th. However, if we have a separate page, we will need to map whole
> page of shadow for it, i.e. 1:1 shadow overhead.
Sure, but for everything but stacks we can re-use the same zero pages,
no?
For everything else, the cost would be dominated by the page tables for
the shadow.
Thanks,
Mark.
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Ulf Hansson @ 2016-11-09 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478661252-42439-1-git-send-email-yangbo.lu@nxp.com>
- i2c-list
On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 15 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only available
> method left now. This v11 patchset introduces the soc_device_match interface in
> soc driver.
>
> The first four patches of Yangbo are to add the GUTS driver. This is used to
> register a soc device which contain soc version and revision information.
> The other three patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> ---
> Changes for v15:
> - Dropped patch 'dt: bindings: update Freescale DCFG compatible'
> since the work had been done by below patch on ShawnGuo's linux tree.
> 'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for SCFG
> and DCFG'
> - Fixed error code issue in guts driver
> Changes for v16:
> - Dropped patch 'powerpc/fsl: move mpc85xx.h to include/linux/fsl'
> - Added a bug-fix patch from Geert
> ---
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Geert Uytterhoeven (1):
> base: soc: Check for NULL SoC device attributes
>
> Yangbo Lu (5):
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS | 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 70 ++++++
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/soc/Kconfig | 3 +-
> drivers/soc/fsl/Kconfig | 18 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 236 +++++++++++++++++++++
> include/linux/fsl/guts.h | 125 ++++++-----
> include/linux/sys_soc.h | 3 +
> 13 files changed, 447 insertions(+), 51 deletions(-)
> rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig
> create mode 100644 drivers/soc/fsl/guts.c
>
> --
> 2.1.0.27.g96db324
>
Thanks, applied on my mmc tree for next!
I noticed that some DT compatibles weren't documented, according to
checkpatch. Please fix that asap!
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH v2 4/6] pinctrl: aspeed: Read and write bits in LPCHC and GFX controllers
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478097481-14895-5-git-send-email-andrew@aj.id.au>
On Thu, Nov 03, 2016 at 01:07:59AM +1030, Andrew Jeffery wrote:
> The System Control Unit IP block in the Aspeed SoCs is typically where
> the pinmux configuration is found, but not always. A number of pins
> depend on state in one of LPC Host Control (LPCHC) or SoC Display
> Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
> means to adjust these as necessary.
>
> We use syscon to cast a regmap over the GFX and LPCHCR blocks, which is
> used as an arbitration layer between the relevant driver and the pinctrl
> subsystem. The regmaps are then exposed to the SoC-specific pinctrl
> drivers by phandles in the devicetree, and are selected during a mux
> request by querying a new 'ip' member in struct aspeed_sig_desc.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Since v1:
>
> The change is now proactive: instead of reporting that we need to flip bits in
> controllers we can't access, the patch provides access via regmaps for the
> relevant controllers. The implementation also splits out the IP block ID into
> its own variable rather than packing the value into the upper bits of the reg
> member of struct aspeed_sig_desc. This drives some churn in the diff, but I've
> tried to minimise it.
>
> .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 50 +++++++++++++---
> drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 18 +++---
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 39 ++++++++++---
> drivers/pinctrl/aspeed/pinctrl-aspeed.c | 66 +++++++++++++---------
> drivers/pinctrl/aspeed/pinctrl-aspeed.h | 32 ++++++++---
> 5 files changed, 144 insertions(+), 61 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> index 2ad18c4ea55c..115b0cce6c1c 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> @@ -4,12 +4,19 @@ Aspeed Pin Controllers
> The Aspeed SoCs vary in functionality inside a generation but have a common mux
> device register layout.
>
> -Required properties:
> -- compatible : Should be any one of the following:
> - "aspeed,ast2400-pinctrl"
> - "aspeed,g4-pinctrl"
> - "aspeed,ast2500-pinctrl"
> - "aspeed,g5-pinctrl"
> +Required properties for g4:
> +- compatible : Should be any one of the following:
> + "aspeed,ast2400-pinctrl"
> + "aspeed,g4-pinctrl"
> +
> +Required properties for g5:
> +- compatible : Should be any one of the following:
> + "aspeed,ast2500-pinctrl"
> + "aspeed,g5-pinctrl"
> +
> +- aspeed,external-nodes: A cell of phandles to external controller nodes:
> + 0: compatible with "aspeed,ast2500-gfx", "syscon"
> + 1: compatible with "aspeed,ast2500-lpchc", "syscon"
>
> The pin controller node should be a child of a syscon node with the required
> property:
> @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6
> TIMER7 TIMER8 VGABIOSROM
>
>
> -Examples:
> +g4 Example:
>
> syscon: scu at 1e6e2000 {
> compatible = "syscon", "simple-mfd";
> @@ -63,5 +70,34 @@ syscon: scu at 1e6e2000 {
> };
> };
>
> +g5 Example:
> +
> +apb {
> + gfx: display at 1e6e6000 {
> + compatible = "aspeed,ast2500-gfx", "syscon";
> + reg = <0x1e6e6000 0x1000>;
> + };
> +
> + lpchc: lpchc at 1e7890a0 {
> + compatible = "aspeed,ast2500-lpchc", "syscon";
> + reg = <0x1e7890a0 0xc4>;
> + };
> +
> + syscon: scu at 1e6e2000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x1e6e2000 0x1a8>;
> +
> + pinctrl: pinctrl {
Why the single child node here? Doesn't look like any reason for it in
the example.
> + compatible = "aspeed,g5-pinctrl";
> + aspeed,external-nodes = <&gfx, &lpchc>;
> +
> + pinctrl_i2c3_default: i2c3_default {
> + function = "I2C3";
> + groups = "I2C3";
> + };
> + };
> + };
> +};
> +
> Please refer to pinctrl-bindings.txt in this directory for details of the
> common pinctrl bindings used by client devices.
^ permalink raw reply
* [PATCH v2 2/6] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478097481-14895-3-git-send-email-andrew@aj.id.au>
On Thu, Nov 03, 2016 at 01:07:57AM +1030, Andrew Jeffery wrote:
> The Aspeed SoC Display Controller is presented as a syscon device to
> arbitrate access by display and pinmux drivers. Video pinmux
> configuration on fifth generation SoCs depends on bits in both the
> System Control Unit and the Display Controller.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++++++++++++++++
The register space can't be split to 2 nodes?
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> new file mode 100644
> index 000000000000..aea5370efd97
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> @@ -0,0 +1,17 @@
> +* Device tree bindings for Aspeed SoC Display Controller (GFX)
> +
> +The Aspeed SoC Display Controller primarily does as its name suggests, but also
> +participates in pinmux requests on the g5 SoCs. It is therefore considered a
> +syscon device.
> +
> +Required properties:
> +- compatible: "aspeed,ast2500-gfx", "syscon"
I think perhaps we should drop the syscon here and the driver should
just register as a syscon.
Rob
^ permalink raw reply
* [PATCHv3 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478097178-24341-2-git-send-email-tthayer@opensource.altera.com>
On Wed, Nov 02, 2016 at 09:32:55AM -0500, tthayer at opensource.altera.com wrote:
> From: Thor Thayer <tthayer@opensource.altera.com>
>
> Add the Arria10 DevKit System Resource Chip register and state
> monitoring module to the MFD.
>
> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
> ---
> Note: This needs to be applied to the bindings document that
> was Acked & Applied but didn't reach the for-next branch.
> See https://patchwork.ozlabs.org/patch/629397/
> ---
> v2 Change compatible string -mon to -monitor for clarity
> v3 Replace node name a10sr_monitor with just monitor.
> Replace node name a10sr_gpio with just gpio.
> ---
> Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: net: Add OXNAS DWMAC Bindings
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102140237.6955-3-narmstrong@baylibre.com>
On Wed, Nov 02, 2016 at 03:02:37PM +0100, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478073426-3714-2-git-send-email-clg@kaod.org>
On Wed, Nov 02, 2016 at 08:57:04AM +0100, C?dric Le Goater wrote:
> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
> other is H8S/2168 compliant.
>
> The current ipmi/bt-bmc driver implements the IPMI version and we
> should reflect its nature in the compatible node name using
> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
> latter should be used for a H8S interface driver if it is implemented
> one day.
>
> Signed-off-by: C?dric Le Goater <clg@kaod.org>
> ---
> .../ipmi/{aspeed,ast2400-bt-bmc.txt => aspeed,ast2400-ibt-bmc.txt} | 4 ++--
Acked-by: Rob Herring <robh@kernel.org>
> drivers/char/ipmi/bt-bmc.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/ipmi/{aspeed,ast2400-bt-bmc.txt => aspeed,ast2400-ibt-bmc.txt} (85%)
^ permalink raw reply
* [PATCH v2 4/9] regulator: lp873x: Add support for populating input supply
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5619d78-5752-c8fb-8a11-6629c4b7c3f6@ti.com>
On Wed, Nov 02, 2016 at 10:58:40AM +0530, Lokesh Vutla wrote:
>
>
> On Monday 31 October 2016 02:11 AM, Rob Herring wrote:
> > On Fri, Oct 21, 2016 at 04:08:36PM +0530, Lokesh Vutla wrote:
> >> In order to have a proper topology of regulators for a platform, each
> >> registering regulator needs to populate supply_name field for identifying
> >> its supply's name. Add supply_name field for lp873x regulators.
> >>
> >> Cc: Lee Jones <lee.jones@linaro.org>
> >> Cc: Keerthy <j-keerthy@ti.com>
> >> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> >> ---
> >> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
> >> drivers/regulator/lp873x-regulator.c | 1 +
> >> 2 files changed, 9 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
> >> index 52766c2..998837a 100644
> >> --- a/Documentation/devicetree/bindings/mfd/lp873x.txt
> >> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
> >> @@ -7,6 +7,9 @@ Required properties:
> >> - #gpio-cells: Should be two. The first cell is the pin number and
> >> the second cell is used to specify flags.
> >> See ../gpio/gpio.txt for more information.
> >> + - xxx-in-supply: Phandle to parent supply node of each regulator
> >> + populated under regulators node. xxx should match
> >> + the supply_name populated in driver.
> >
> > The driver is irrelevant. This should reference a list in this document.
>
> okay. See if the below updated patch is fine.
>
> -----------------------------8<----------------------------8<----------------------------
> From 666f925423fa35c7bfcc77fa3c883cbea5d8ef8e Mon Sep 17 00:00:00 2001
> From: Lokesh Vutla <lokeshvutla@ti.com>
> Date: Wed, 21 Sep 2016 11:50:49 +0530
> Subject: [PATCH v3] regulator: lp873x: Add support for populating input
> supply
>
> In order to have a proper topology of regulators for a platform, each
> registering regulator needs to populate supply_name field for identifying
> its supply's name. Add supply_name field for lp873x regulators.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
> drivers/regulator/lp873x-regulator.c | 1 +
> 2 files changed, 9 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/2] mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings document
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478018277-10097-2-git-send-email-scott.branden@broadcom.com>
On Tue, Nov 01, 2016 at 09:37:56AM -0700, Scott Branden wrote:
> Adds brcm,sdhci-iproc compat string to DT bindings document for
> the iProc SDHCI driver.
>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
> Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/3] binding: irqchip: mtk-cirq: Add binding document
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478001122-8664-2-git-send-email-youlin.pei@mediatek.com>
On Tue, Nov 01, 2016 at 07:52:00PM +0800, Youlin Pei wrote:
> This commit adds the device tree binding document for
> the mediatek cirq.
>
> Signed-off-by: Youlin Pei <youlin.pei@mediatek.com>
> ---
> .../interrupt-controller/mediatek,cirq.txt | 30 ++++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
> new file mode 100644
> index 0000000..84e8123
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
> @@ -0,0 +1,30 @@
> +* Mediatek 27xx cirq
> +
> +In Mediatek SOCs, the CIRQ is a low power interrupt controller designed to
> +works outside MCUSYS which comprises with Cortex-Ax cores,CCI and GIC.
s/works/work/
> +The external interrupts (outside MCUSYS) will feed through CIRQ and connect
> +to GIC in MCUSYS. When CIRQ is enabled, it will record the edge-sensitive
> +interrupts and generated a pulse signal to parent interrupt controller when
s/generated/generate/
> +flush command is executed. With CIRQ, MCUSYS can be completely turned off
> +to improve the system power consumption without losing interrupts.
> +
> +Required properties:
> +- compatible: should be: "mediatek,mtk-cirq".
This should be SoC specific. This is fine as a fallback if the same
block is in many SoCs, but mediatek and mtk is a bit redundant.
> +- interrupt-controller : Identifies the node as an interrupt controller.
> +- #interrupt-cells : Use the same format as specified by GIC in arm,gic.txt.
> +- interrupt-parent: phandle of irq parent for cirq. The parent must
> + use the same interrupt-cells format as GIC.
> +- reg: Physical base address of the cirq registers and length of memory
> + mapped region.
> +- mediatek,ext-irq-start: Identifies external irq start number in different
> + SOCs.
Wouldn't this always be 32 if the GIC is the parent? If 32 is the common
case, then use the SoC compatible to determine this value.
> +
> +Example:
> + cirq: interrupt-controller at 10204000 {
> + compatible = "mediatek,mtk-cirq";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + interrupt-parent = <&sysirq>;
> + reg = <0 0x10204000 0 0x4000>;
> + mediatek,ext-irq-start = <32>;
> + };
> --
> 1.7.9.5
>
^ permalink raw reply
* [RFC PATCH v2 1/5] net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477932987-27871-2-git-send-email-narmstrong@baylibre.com>
On Mon, Oct 31, 2016 at 05:56:23PM +0100, Neil Armstrong wrote:
> In order to support PHY switching on Amlogic GXL SoCs, add support for
> 16bit and 32bit registers sizes.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
> drivers/net/phy/mdio-mux-mmioreg.c | 60 +++++++++++++++++-----
> 2 files changed, 49 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
> index 8516929..065e8bd 100644
> --- a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
> +++ b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
> @@ -3,7 +3,7 @@ Properties for an MDIO bus multiplexer controlled by a memory-mapped device
> This is a special case of a MDIO bus multiplexer. A memory-mapped device,
> like an FPGA, is used to control which child bus is connected. The mdio-mux
> node must be a child of the memory-mapped device. The driver currently only
As you're touching this sentence, this describes the binding, not a
driver. With that,
Acked-by: Rob Herring <robh@kernel.org>
> -supports devices with eight-bit registers.
> +supports devices with 8, 16 or 32-bit registers.
>
> Required properties in addition to the generic multiplexer properties:
>
> @@ -11,7 +11,7 @@ Required properties in addition to the generic multiplexer properties:
>
> - reg : integer, contains the offset of the register that controls the bus
> multiplexer. The size field in the 'reg' property is the size of
> - register, and must therefore be 1.
> + register, and must therefore be 1, 2, or 4.
>
> - mux-mask : integer, contains an eight-bit mask that specifies which
> bits in the register control the actual bus multiplexer. The
^ permalink raw reply
* [PATCH] arm64: acpi: arch_apei_get_mem_attributes() should use memblock
From: Will Deacon @ 2016-11-09 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5823677D.3050803@arm.com>
On Wed, Nov 09, 2016 at 06:14:21PM +0000, James Morse wrote:
> On 09/11/16 12:12, Ard Biesheuvel wrote:
> > This means that in this case, you may be returning PAGE_KERNEL for
> > regions that are lacking the EFI_MEMORY_WB attribute, which kind of
> > defeats the purpose of this function (AIUI), to align the kernel's
> > view of the region's attributes with the view of the firmware. I would
> > expect that, for use cases like this one, the burden is on the
> > firmware to ensure that only a single EFI_MEMORY_xx attribute is set
> > if any kind of coherency between UEFI and the kernel is expected. If
> > that single attribute is WT or WC, PAGE_KERNEL is most certainly
> > wrong.
>
> I've been trying to test some of the APEI code using some hacks on top of
> kvmtool. (actually, quite a lot of hacks).
>
> When I trigger an event, I see efi_mem_attributes() always return 0 because the
> EFI memory map isn't mapped. This turns out to be because I have 'efi=noruntime'
> on the command line. I stopped digging when I found this previously-dead code,
> but should have gone further.
>
> If this is an expected interaction, we can ignore this as a bug in my test
> setup. (and I have to work out how to get efi runtime services going...)
>
> If not, I can try always mapping the EFI memory map in
> arm_enable_runtime_services() if we booted via ACPI, as in this case runtime
> services isn't the only user of the memory map.
>
>
> My intention here was to just mirror acpi_os_ioremap(), which will call
> ioremap_cache() for WB/WC/WT regions, which (also) ends up using PROT_NORMAL. We
> may get away with this, but you're right, we are less likely to here.
I'd certainly be interested in opinions as to what acpi_os_ioremap is
supposed to do, since it has fingers in the NOMAP pie and if we change the
polarity of pfn_valid() for NOMAP mappings (as suggested by Robert Richter
to fix his NUMA issue), then acpi_os_ioremap will actually *fail* for
these WB/WC regions.
Will
^ permalink raw reply
* [PATCH v2 2/5] ARM: bus: da8xx-mstpri: new driver
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-3-git-send-email-bgolaszewski@baylibre.com>
On Mon, Oct 31, 2016 at 03:45:35PM +0100, Bartosz Golaszewski wrote:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/bus/Kconfig | 9 +
> drivers/bus/Makefile | 2 +
> drivers/bus/da8xx-mstpri.c | 269 +++++++++++++++++++++
> 4 files changed, 300 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
> create mode 100644 drivers/bus/da8xx-mstpri.c
^ permalink raw reply
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-2-git-send-email-bgolaszewski@baylibre.com>
On Mon, Oct 31, 2016 at 03:45:34PM +0100, Bartosz Golaszewski wrote:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> .../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/memory/Kconfig | 8 +
> drivers/memory/Makefile | 1 +
> drivers/memory/da8xx-ddrctl.c | 175 +++++++++++++++++++++
> 4 files changed, 204 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> create mode 100644 drivers/memory/da8xx-ddrctl.c
^ permalink raw reply
* [PATCH v2 5/7] ARM: shmobile: Document DT bindings for CCCR and PRR
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477913455-5314-6-git-send-email-geert+renesas@glider.be>
On Mon, Oct 31, 2016 at 12:30:53PM +0100, Geert Uytterhoeven wrote:
> Add device tree binding documentation for the Common Chip Code Register
> and Product Register, which provide SoC product and revision
> information.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
> - New.
> ---
> Documentation/devicetree/bindings/arm/shmobile.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ 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