* [PATCH 3/3] tty/serial: at91: fix hardware handshake when DMA is not used
From: Richard Genoud @ 2016-09-09 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15e0dbe0-6636-6bec-9622-be00056dae5e@atmel.com>
Hi Alex, Cyrille,
I did some tests to clear this HW handcheck history out.
NB: all those tests are with a 4.8-rc5 kernel on a AT91SAM9G35-CM board.
I couldn't test the PDC since, as Cyrille said, there's no such thing on
SAM9G35 USARTs.
The modes that DON'T WORK are:
ATMEL_US_USMODE_HWHS + DMA (RTS won't go up when the data are not read anymore)
ATMEL_US_USMODE_HWHS + PIO (RTS won't even go down when the port is open)
The modes that WORK are:
ATMEL_US_USMODE_NORMAL + DMA (no error, perfect transfer)
ATMEL_US_USMODE_NORMAL + PIO (some chars are eaten or nullified)
So, it seems that Atmel HW's guys where right when they said that the
HW handshake is completely broken on SAM9x5 (updating the manual with a
note saying that ATMEL_US_USMODE_HWHS shouldn't be use would be a good
idea !).
2016-09-07 18:59 GMT+02:00 Alexandre Belloni
<alexandre.belloni@free-electrons.com>:
> Hi,
>
> You forgot that the PDC can properly drive the RTS pin so all the
> platforms that are using the PDC will break after your patch.
You're right, I missed the platforms with PDC.
But right know, all SAM9x5 platforms are broken (and I guess SAM92xx
also), so I guess we'll find a way to correct that.
> Also, I believe the controller is able to drive the RTS and CTS pins
> when simply using PIOs (it knows when one complete character has been
> received and US_RHR has not yet been read). However, I didn't test.
> Maybe someone at Atmel can confirm.
I did see anything like that in SAM9G35 datasheet, and the tests I've done show
the contrary.
Actually, in SAM9G35 datasheet:
"When a character reception is completed, it is transferred to the
Receive Holding register (US_RHR) and the RXRDY bit in US_CSR rises.
If a character is completed while the RXRDY is set, the OVRE
(Overrun Error) bit is set.
The last character is transferred into US_RHR and overwrites the previous one."
> I think that 5be605ac9af9 is doing the right thing but I still can be
> convince otherwise ;).
I'll get to that.
2016-09-07 19:28 GMT+02:00 Cyrille Pitchen <cyrille.pitchen@atmel.com>:
> Hi Richard,
>
> For usart without FIFOs (hence before sama5d2), according to our designers, the
> RTS line could only been controlled by an internal PDC signal which doesn't
> exist with the DMA controller. Referring to its datasheet, the sam9g35 embeds
> DMA controllers. So if you enable the hardware handshaking feature on some
> usart, its RTS line won't be monitored at all. The hardware handshaking is
> broken on all SoCs using DMA controllers instead of PDC.
>
> With the sama5d2, our latest MPU, we fixed this issue by introducing an
> alternative mechanism which relies on 2 thresholds on the RX FIFO. So when
> FIFOs are available, those thresholds can be used to control the level of RTS
> line.
>
> Indeed I think a better test should be:
> if (!atmel_use_pdc_rx(port) && !atmel_use_fifo(port)) {
> dev_info(port->dev, "not enabling hardware flow control
> because neither the PDC nor the FIFO are available");
> termios->c_cflags &= ~CRTSCTS;
> }
Maybe that's ok for SAMAD2+ platform, but not for older ones.
Actually, from all the tests I've done, the only mode that works for
SAM9x5 is:
mode |= ATMEL_US_USMODE_NORMAL;
and the CRTSCTS flag should *NOT* be removed.
So, IHMO, test should be:
if (atmel_use_pdc_rx(port) || atmel_use_fifo(port)) {
mode |= ATMEL_US_USMODE_HWHS;
} else {
mode |= ATMEL_US_USMODE_NORMAL;
}
Because nothing prevents the driver to drive the RTS pin itself, as it
is done in atmel_set_mctrl().
So, IHMO, commit 5be605ac9af9 is all wrong.
It basically says "If the controller can't handle RTS/CTS, then we don't
do HW handshake."
NO ! If the controller can't do it, the driver can do it for him, can't it ?!
(Well, from here, it truly seems it can !)
If you want to grab an atmel board and a scope to do some testing,
here's what I've done:
On one side:
stty -F /dev/ttyS2 115200 crtscts -opost clocal cread
exec 3>/dev/ttyS2
dd if=/home/rgenoud/dev/linux/MAINTAINERS bs=1M count=1 > /dev/ttyS2
exec 3>&-
On the board:
stty -F /dev/ttyS1 115200 crtscts -opost clocal cread
exec 4</dev/ttyS1
rm -f /tmp/rcv
cat <&4 >> /tmp/rcv
# then ctrl-C, and "cat <&4 >> /tmp/rcv" again
# at the ctrl-C, the RTS pin should go up
To enable dma in sam9x5 dts, I added
atmel,use-dma-rx;
in usart0: serial at f801c000
>
> We can double check once again with our designers to confirm that without FIFO
> the only way for the hardware handshaking to work is to use a PDC.
> So IMHO, your patch should not be applied, sorry!
>
> Best regards,
>
> Cyrille
>
Best regards.
Richard.
^ permalink raw reply
* [RESEND GIT PULL] STi DT fixes for v4.8-rcs
From: Arnd Bergmann @ 2016-09-09 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f2d83529-3ab1-fe8e-c599-cf5dfbb1f17b@st.com>
On Thursday, September 8, 2016 5:21:00 PM CEST Patrice Chotard wrote:
> Handle STiH410 interconnect clock required for EHCI/OHCI and SDHCI
>
> With the introduction of critical-clock support in v4.8, our developers'
> default configuration is to run with 'clk_ignore_unused' removed. This
> patch-set ensures they can achieve successful boot when a) booting from
> an SD Card and when b) booting using USB->Eth adaptors for NFS booting.
>
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Fixes for v4.8
From: Arnd Bergmann @ 2016-09-09 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1473232298.git.horms+renesas@verge.net.au>
On Wednesday, September 7, 2016 9:41:04 AM CEST Simon Horman wrote:
> Renesas ARM Based SoC Fixes for v4.8
>
> * Correct R-Car Gen2 regulator quirk
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi
From: Arnd Bergmann @ 2016-09-09 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473432356.28111.60.camel@hellion.org.uk>
On Friday, September 9, 2016 3:45:56 PM CEST Ian Campbell wrote:
> On Tue, 2016-08-23 at 12:09 +0200, Arnd Bergmann wrote:
> > I had skipped the new message as well while sorting through 5000
> > messages after my vacation, but I've now put it into my TODO folder
> > and will get to it eventually.
>
> Is it still on your TODO or should I do...
>
> > We sometimes miss stuff that is meant for arm-soc when it comes
> > from people that don't normally send us patches. If you want to
> > be sure to catch the attention, stick a 'GIT PULL' into the subject
> > or send a ping on IRC.
>
> ... one of these?
>
> It'd be great to get this fixed in v4.8 so that the corresponding
> device-tree.git tag will build.
Oh, it ended up in my v4.9-todo folder, not 4.8, I misunderstood
the urgency, sorry.
I've applied it to the fixes branch now.
Arnd
^ permalink raw reply
* [PULL 0/2] KVM/ARM Fixes for v4.8 - round #2
From: Paolo Bonzini @ 2016-09-09 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909105456.8585-1-christoffer.dall@linaro.org>
On 09/09/2016 12:54, Christoffer Dall wrote:
> Hi Paolo and Radim,
>
> Here are a couple of fixes for KVM/ARM for v4.8-rc6 or -rc7, as soon as
> they can make it.
>
> They fix an idmap issue on 32-bit KVM on ARM, and fixes a memory
> unmapping issue that we've had forever on both arm and arm64.
>
> The following changes since commit 20218b86ad8adb4bf71db9425bb59680f345eafd:
>
> Merge tag 'kvm-s390-master-4.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master (2016-09-05 16:15:22 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-fixes-for-v4.8-round2
>
> for you to fetch changes up to 293f293637b55db4f9f522a5a72514e98a541076:
>
> kvm-arm: Unmap shadow pagetables properly (2016-09-09 12:40:30 +0200)
>
> Thanks!
> -Christoffer
>
> ---
> Marc Zyngier (1):
> arm: KVM: Fix idmap overlap detection when the kernel is idmap'ed
>
> Suzuki K Poulose (1):
> kvm-arm: Unmap shadow pagetables properly
>
> arch/arm/kvm/arm.c | 2 --
> arch/arm/kvm/mmu.c | 4 +++-
> 2 files changed, 3 insertions(+), 3 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Pulled, thanks.
Paolo
^ permalink raw reply
* [PATCH] hwmon: xgene: access mailbox as RAM
From: Arnd Bergmann @ 2016-09-09 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160907223705.GA31582@roeck-us.net>
The newly added hwmon driver fails to build in an allmodconfig
kernel:
1 ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!
According to comments in the code, the mailbox is a shared memory region,
not a set of MMIO registers, so we should use memremap() for mapping it
instead of ioremap or acpi_os_ioremap, and pointer dereferences instead
of readl/writel.
The driver already uses plain kernel pointers, so it's a bit unusual
to work with functions that operate on __iomem pointers, and this
fixes that part too.
I'm using READ_ONCE/WRITE_ONCE here to keep the existing behavior
regarding the ordering of the accesses from the CPU, but note that
there are no barriers (also unchanged from before).
I'm also keeping the endianess behavior, though I'm unsure whether
the message data was supposed to be in LE32 format in the first
place, it's possible this was meant to be interpreted as a byte
stream instead.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
index bc78a5d10182..e834dfb3acca 100644
--- a/drivers/hwmon/xgene-hwmon.c
+++ b/drivers/hwmon/xgene-hwmon.c
@@ -34,7 +34,8 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
-#include <acpi/acpi_io.h>
+#include <linux/io.h>
+
#include <acpi/pcc.h>
/* SLIMpro message defines */
@@ -126,10 +127,10 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
{
u16 ret, val;
- val = readw_relaxed(addr);
+ val = le16_to_cpu(READ_ONCE(*addr));
ret = val & mask;
val &= ~mask;
- writew_relaxed(val, addr);
+ WRITE_ONCE(*addr, cpu_to_le16(val));
return ret;
}
@@ -137,7 +138,7 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev *ctx, u32 *msg)
{
struct acpi_pcct_shared_memory *generic_comm_base = ctx->pcc_comm_addr;
- void *ptr = generic_comm_base + 1;
+ u32 *ptr = (void*)(generic_comm_base + 1);
int rc, i;
u16 val;
@@ -146,21 +147,21 @@ static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev *ctx, u32 *msg)
ctx->resp_pending = true;
/* Write signature for subspace */
- writel_relaxed(PCC_SIGNATURE_MASK | ctx->mbox_idx,
- &generic_comm_base->signature);
+ WRITE_ONCE(generic_comm_base->signature,
+ cpu_to_le32(PCC_SIGNATURE_MASK | ctx->mbox_idx));
/* Write to the shared command region */
- writew_relaxed(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT,
- &generic_comm_base->command);
+ WRITE_ONCE(generic_comm_base->command,
+ cpu_to_le16(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT));
/* Flip CMD COMPLETE bit */
- val = readw_relaxed(&generic_comm_base->status);
+ val = le16_to_cpu(READ_ONCE(generic_comm_base->status));
val &= ~PCCS_CMD_COMPLETE;
- writew_relaxed(val, &generic_comm_base->status);
+ WRITE_ONCE(generic_comm_base->status, cpu_to_le16(val));
/* Copy the message to the PCC comm space */
for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
- writel_relaxed(msg[i], ptr + i * 4);
+ WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));
/* Ring the doorbell */
rc = mbox_send_message(ctx->mbox_chan, msg);
@@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device *pdev)
*/
ctx->comm_base_addr = cppc_ss->base_address;
if (ctx->comm_base_addr) {
- ctx->pcc_comm_addr =
- acpi_os_ioremap(ctx->comm_base_addr,
- cppc_ss->length);
+ ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
+ cppc_ss->length,
+ MEMREMAP_WT);
} else {
dev_err(&pdev->dev, "Failed to get PCC comm region\n");
rc = -ENODEV;
^ permalink raw reply related
* [PATCH v3 2/3] hwmon: xgene: Add hwmon driver
From: Arnd Bergmann @ 2016-09-09 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160907223705.GA31582@roeck-us.net>
On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote:
> On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote:
> > On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
> > > + ctx->comm_base_addr = cppc_ss->base_address;
> > > + if (ctx->comm_base_addr) {
> > > + ctx->pcc_comm_addr =
> > > + acpi_os_ioremap(ctx->comm_base_addr,
> > > + cppc_ss->length);
> > >
> >
> > This causes the arm64 allmodconfig build to fail now, according to
> > kernelci:
> >
> > 1 ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!
> >
> > Should this perhaps call ioremap() or memremap() instead?
> >
> Hmmm ... almost sounds to me like blaming the messenger. e7cd190385d1 ("arm64:
> mark reserved memblock regions explicitly in iomem") starts using a function
> in acpi_os_ioremap() which is not exported. On top of that, memblock_is_memory()
> is declared as __init_memblock, which makes me really uncomfortable.
> If acpi_os_ioremap() must not be used by modules, and possibly only during
> early (?) initialization, maybe its declaration should state those limitations ?
I think there is more wrong with it, the driver also accesses a shared
memory area with kernel pointers using readl_relaxed/writel_relaxed,
which are only valid on MMIO registers.
I've prepared a patch, please have a look at the follow-up email.
Arnd
^ permalink raw reply
* [PATCH V4 3/4] ARM: bcm2835: add thermal node to device-tree of bcm283x
From: Stefan Wahren @ 2016-09-09 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8876586A-98F8-4AAF-AD90-86EB12C22FDC@martin.sperl.org>
> Martin Sperl <kernel@martin.sperl.org> hat am 9. September 2016 um 16:58
> geschrieben:
>
>
>
> > On 09.09.2016, at 16:25, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> >
> >> Am 09.09.2016 um 09:49 schrieb kernel at martin.sperl.org:
> >> From: Martin Sperl <kernel@martin.sperl.org>
> >>
> >> Add the node for the thermal sensor of the bcm2835-soc
> >> to the device tree.
> >>
> >> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
> >> Reviewed-by: Eric Anholt <eric@anholt.net>
> >> ---
> >> arch/arm/boot/dts/bcm283x.dtsi | 6 ++++++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/bcm283x.dtsi
> >> b/arch/arm/boot/dts/bcm283x.dtsi
> >> index b982522..e2e3a46 100644
> >> --- a/arch/arm/boot/dts/bcm283x.dtsi
> >> +++ b/arch/arm/boot/dts/bcm283x.dtsi
> >> @@ -186,6 +186,12 @@
> >> interrupts = <2 14>; /* pwa1 */
> >> };
> >>
> >> + thermal: thermal at 0x7e212000 {
> >> + compatible = "brcm,bcm2835-thermal";
> >> + reg = <0x7e212000 0x8>;
> >> + clocks = <&clocks BCM2835_CLOCK_TSENS>;
> >> + };
> >> +
> >
> > Since the driver handles 3 different SoC (2835, 2836, 2837). This node
> > should be defined in the SoC specific dtsi files, because the BCM2836
> > includes bcm283x.dtsi too.
> >
> > Be aware the patch for bcm2837 must go to ARM64.
>
> I can not really follow:
> * the node is defined in the dtsi included by all 3 soc,
> and it is available on all so it sits where for example
> spi0 or uart0 is located
> * as for arm64: this describes the registers that are
> identical for arm and arm64 and the bcm2837.dtsi
> is also including ../../../../arm/boot/dts/bcm283x.dtsi
>
> So what is the problem?
The thermal driver specifies 3 different compatibles with partially different
settings.
If this patch is applied, all SoC (bcm2835, bcm2836, bcm2837) would use the
bcm2835 settings.
I can't believe this is intended.
Why does the binding contains 3 different compatibles if only one is used?
>
> Martin
>
> P.s the patches apply cleanly against master.
>
^ permalink raw reply
* [PATCH] coresight: stm: return error code instead of zero in .packet() to avoid dead loop
From: Mathieu Poirier @ 2016-09-09 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473416289-30882-1-git-send-email-zhang.chunyan@linaro.org>
On 9 September 2016 at 04:18, Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> In STM framework driver, the trace data writing loop would keep running
> until it received a negative return value or the whole trace packet has
> been written to STM device. So if the .packet() of STM device always
> returns zero since the device is not enabled or the parameter isn't
> supported, STM framework driver will stall into a dead loop.
>
> Returning -EACCES (Permission denied) in .packet() if the device is
> disabled makes more sense, and this is the same for returning -EINVAL
> if the channel passed into is not supported.
>
> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
> ---
> drivers/hwtracing/coresight/coresight-stm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
> index 73be58a..6291ce1 100644
> --- a/drivers/hwtracing/coresight/coresight-stm.c
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -399,10 +399,10 @@ static ssize_t stm_generic_packet(struct stm_data *stm_data,
> struct stm_drvdata, stm);
>
> if (!(drvdata && local_read(&drvdata->mode)))
> - return 0;
> + return -EACCES;
>
> if (channel >= drvdata->numsp)
> - return 0;
> + return -EINVAL;
>
> ch_addr = (unsigned long)stm_channel_addr(drvdata, channel);
>
> --
> 2.7.4
>
Applied, but I had to change the title to "coresight: stm: return
error code instead of zero in .packet()" as the previous one exceeded
80 characters.
Thanks,
Mathieu
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Kevin Hilman @ 2016-09-09 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCC4gkMrJtertYevg_hXDLJEZ0PqfKKLL5UKXo8B=SXsPw@mail.gmail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> On Thu, Sep 8, 2016 at 10:53 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>> On 08/09/16 21:42, Kevin Hilman wrote:
>>>
>>> Ben Dooks <ben.dooks@codethink.co.uk> writes:
>>>
>>>> On 08/09/16 20:52, Martin Blumenstingl wrote:
>>>>>
>>>>> On Thu, Sep 8, 2016 at 9:35 PM, Kevin Hilman <khilman@baylibre.com>
>>>>> wrote:
>>>>>>>
>>>>>>> + phy = devm_phy_create(&pdev->dev, NULL, &phy_meson_usb2_ops);
>>>>>>> + if (IS_ERR(phy)) {
>>>>>>> + dev_err(&pdev->dev, "failed to create PHY\n");
>>>>>>> + return PTR_ERR(phy);
>>>>>>> + }
>>>>>>> +
>>>>>>> + if (usb_reset_refcnt++ == 0) {
>>>>>>> + ret = device_reset(&pdev->dev);
>>>>>>> + if (ret) {
>>>>>>> + dev_err(&phy->dev, "Failed to reset USB PHY\n");
>>>>>>> + return ret;
>>>>>>> + }
>>>>>>> + }
>>>>>>
>>>>>>
>>>>>> The ref count + reset here looks like something that could/should be
>>>>>> handled in a runtime PM callback.
>>>>>
>>>>> Unfortunately that doesn't work (as Jerome found out) because both
>>>>> PHYs are sharing the same reset line.
>>>>> So if the second PHY would call device_reset then it would also reset
>>>>> the first PHY!
>>>>>
>>>>> There's a comment above the declaration of usb_reset_refcnt which
>>>>> tries to explain this:
>>>>> "The PHYs are sharing a common reset line -> we are only allowed to
>>>>> reset once for all PHYs."
>>>>> Maybe I should move this comment to the "if (usb_reset_refcnt++ == 0)
>>>>> {" line to make it easier to see?
>>>>>
>>>>
>>>> pm-runtime has refcounting in it. When one of the nodes turns on,
>>>> the pm-runtime will call your driver to say there is a user when
>>>> this first use turns up.
>>>>
>>>> If all the sub-phys turn off and drop their refcount then the driver
>>>> is called to say there are no more users and you can go to sleep.
>>>
>>>
>>> After a chat w/Martin on IRC, It turns out runtime PM wont help here.
>>>
>>> The reason is because there are physically two PHY devices[1]. Those 2
>>> devices will be treated independely by runtime PM, and have separate
>>> use-counting, which means doing what I proposed would cause a reset to
>>> happen when either device was probed.
>>>
>>> So, I think it's OK as it is.
>>
>>
>> Surely you can do pm_runtime_get/put on the phy's parent platform
>> device and do it that way?
> could you please be more specific with that (do you mean pdev->dev.parent)?
> so we would use pm_runtime_{get_sync,put} with the parent, while we
> would still define the runtime_resume in our driver.
You'd also need to do get/put on the children, but yes, that's what Ben
is suggesting.
However, the problem with all of the solutions proposed (runtime PM ones
included) is that we're forcing a board-specific design issue (2 devices
sharing a reset line) into a driver that should not have any
board-specific assumptions in it.
For example, if this driver is used on another platform where different
PHYs have different reset lines, then one of them (the unlucky one who
is not probed first) will never get reset. So any form of per-device
ref-counting is not a portable solution.
I'm not sure yet how the reset framework is supposed to handle shared
reset lines, but that needs some investigation. I quick glance and it
seems that reset controllers can have shared lines, so that should be
investigated.
Kevin
^ permalink raw reply
* [PATCH v3 1/8] arm64: KVM: Use static keys for selecting the GIC backend
From: Marc Zyngier @ 2016-09-09 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D2D1F0.301@arm.com>
On 09/09/16 16:14, Vladimir Murzin wrote:
> On 09/09/16 15:17, Marc Zyngier wrote:
>> On 09/09/16 14:45, Vladimir Murzin wrote:
>>> On 09/09/16 10:33, Vladimir Murzin wrote:
>>>> Hi Marc,
>>>>
>>>> On 09/09/16 10:19, Marc Zyngier wrote:
>>>>>> Hi Vladimir,
>>>>>>
>>>> ...
>>>>>>>>
>>>>>>>> +extern struct static_key_false kvm_gicv3_cpuif;
>>>>>>
>>>>>> I think we should follow the model set by kvm_vgic_global_state, which
>>>>>> is declared in arm_vgic.h. Even better, we should *embed* the static key
>>>>>> in this structure. This will reduce the clutter and we wouldn't have to
>>>>>> deal with all the section stuff (the hyp_data thing is a good cleanup,
>>>>>> but I'd like to see it as a separate patch if possible).
>>>> Yes, it is what I was thinking about too, but was not sure about which
>>>> way to go, so hyp_data seemed me something we might reuse latter.
>>>> However, I agree that we can defer hyp_data thing...
>>>>
>>>
>>> I've just tried it out and it seems that static keys are not happy to
>>> accept a key after kern_hyp_va is applied at &kvm_vgic_global_state:
>>
>> Ah, there is a trick. You do not need kern_hyp_va at all, because this
>> is not evaluated as an expression at runtime (so the pointer doesn't matter).
>>
>
> Ah, right, thank for a tip! ;)
>
>>>> In file included from ./include/linux/jump_label.h:105:0,
>>>> from arch/arm64/kvm/hyp/switch.c:19:
>>>> ./arch/arm64/include/asm/jump_label.h: In function ?__guest_run?:
>>>> ./arch/arm64/include/asm/jump_label.h:31:2: warning: asm operand 0 probably doesn?t match constraints
>>>> asm goto("1: nop\n\t"
>>>> ^
>>>> ./arch/arm64/include/asm/jump_label.h:31:2: warning: asm operand 0 probably doesn?t match constraints
>>>> asm goto("1: nop\n\t"
>>>> ^
>>>> ./arch/arm64/include/asm/jump_label.h:31:2: error: impossible constraint in ?asm?
>>>> asm goto("1: nop\n\t"
>>>> ^
>>>> ./arch/arm64/include/asm/jump_label.h:31:2: error: impossible constraint in ?asm?
>>>> asm goto("1: nop\n\t"
>>>> ^
>>>> make[1]: *** [arch/arm64/kvm/hyp/switch.o] Error 1
>>>> make: *** [arch/arm64/kvm/hyp/switch.o] Error 2
>>>
>>> it looks like we cannot avoid hyp_data thing... if you don't mind I can
>>> do hyp_data clean-up in separate patch. Alternatively, we can do
>>> conversion to static keys for both architectures later as an
>>> optimisation step.
>>
>> Can you try the above first? I've just tried the same approach with my
>> vgic-trap series, and it compiles fine (untested though):
>
> I was about to try it out, but didn't manage to find a branch with
> vgic-trap series, so I did a quick fixup for my series and now it is
> running non-VHE boot tests and I don't expect issues with VHE one. I
> think diff bellow should work runtime too, but if you do want me to give
> it a try it'd be handy to have a branch I can pull from ;)
I think Christoffer has pulled it into kvmarm/queue.
>> + kvm_vgic_global_state.vgic_v2_cpuif_trap = STATIC_KEY_FALSE_INIT;
>> +
>
> I did this a bit different:
>
> +struct vgic_global __section(.hyp.text) kvm_vgic_global_state =
> {.gicv3_cpuif = STATIC_KEY_FALSE_INIT,};
Yeah, that's actually nicer.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH 0/5] arm64: Signal context expansion
From: Dave Martin @ 2016-09-09 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dad2e7cc-f8cb-4e33-99c7-66effa7a6f5e@redhat.com>
On Fri, Sep 09, 2016 at 04:39:14PM +0200, Florian Weimer wrote:
> On 09/09/2016 04:15 PM, Dave Martin wrote:
> >This new record can be added in sigframe.__reserved[] if there is a
> >need to allocate extra space beyond the standard signal frame. The
> >extra block of memory referenced by extra_context can then be parsed in
> >the same way as sigcontext.__reserved[]. Old code should just ignore
> >the whole thing as an unrecognised record. To maintain backward
> >compatibility, signal context records defined today are always placed
> >directly in __reserved[], never in the block referenced by
> >extra_context.
>
> Do you add this extra information only if the stack is sufficiently large?
>
> x86_64 adds the new information even for small stacks set up with
> sigaltstack, leading to memory corruption on bleeding-edge hardware:
>
> <https://bugzilla.kernel.org/show_bug.cgi?id=153531>
Hmmm, not yet. We already check that the whole frame is writable user
memory, but this isn't sufficient to avoid user corruption in the case
of alternate signal stacks. I'll fix this -- thanks for flagging it.
If the stack isn't large enough, we'll still have to SEGV the task
though.
We can (and should) bump up the SIG{,MIN}STKSZ constants when adding
the SVE support proper to the kernel, but this doesn't solve the
problem of existing binaries. For backwards compatibility the kernel
would still have to permit the historical (too-small) values of
these constants for calls to sigaltstack(2) though, which is not ideal.
I wonder whether we should make the signal stack size runtime
discoverable through sysconf() instead...
Cheers
---Dave
^ permalink raw reply
* [GIT PULL 4/4] arm64: tegra: Device tree changes for v4.9-rc1
From: Thierry Reding @ 2016-09-09 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909152032.9550-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.9-arm64-dt
for you to fetch changes up to 988232412e6711a9bbdc06d4e008b552bbf7cd06:
arm64: tegra: Select PM_GENERIC_DOMAINS (2016-08-24 17:11:44 +0200)
Thanks,
Thierry
----------------------------------------------------------------
arm64: tegra: Device tree changes for v4.9-rc1
Add a couple of devices (AGIC, ADMA) on Tegra210 and enable them on
Smaug. Also enable DPAUX on Smaug to allow the I2C bus that shares pads
with the DPAUX to be used to access various audio devices. Furthermore,
enable the XUSB controller on Smaug for USB 3.0 support.
Finally, select PM_GENERIC_DOMAINS for 64-bit Tegra devices to make sure
devices are probed only after their power partitions have been enabled.
----------------------------------------------------------------
Jon Hunter (9):
arm64: tegra: Drop clock and reset names for XUSB powergates
arm64: tegra: Add AGIC node for Tegra210
arm64: tegra: Add ADMA node for Tegra210
arm64: tegra: Add SOR power-domain for Tegra210
arm64: tegra: Add ACONNECT, ADMA and AGIC nodes Tegra210 Smaug
arm64: tegra: Enable DPAUX for Tegra210 Smaug
arm64: tegra: Add the various audio devices for Tegra210 Smaug
arm64: tegra: Enable XUSB controller on Tegra210 Smaug
arm64: tegra: Select PM_GENERIC_DOMAINS
Stephen Warren (1):
arm64: tegra: Simplify Tegra210 GPIO compatible value
arch/arm64/Kconfig.platforms | 2 +
arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 120 ++++++++++++++++++++++++++
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 79 +++++++++++++++--
3 files changed, 194 insertions(+), 7 deletions(-)
^ permalink raw reply
* [GIT PULL 3/4] ARM: tegra: Device tree changes for v4.9-rc1
From: Thierry Reding @ 2016-09-09 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909152032.9550-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.9-arm-dt
for you to fetch changes up to 7e9d474954f4c8c27534633252500e0c477581bd:
ARM: tegra: Correct polarity for Tegra114 PMIC interrupt (2016-08-16 15:10:23 +0200)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Device tree changes for v4.9-rc1
Contains a couple of cleanups for Tegra114 device trees.
----------------------------------------------------------------
Jon Hunter (1):
ARM: tegra: Correct polarity for Tegra114 PMIC interrupt
Stephen Warren (1):
ARM: tegra: Fix Tegra114 USB compatible values
arch/arm/boot/dts/tegra114-dalmore.dts | 2 +-
arch/arm/boot/dts/tegra114-roth.dts | 2 +-
arch/arm/boot/dts/tegra114-tn7.dts | 2 +-
arch/arm/boot/dts/tegra114.dtsi | 8 ++++----
4 files changed, 7 insertions(+), 7 deletions(-)
^ permalink raw reply
* [GIT PULL 2/4] soc/tegra: Changes for v4.9-rc1
From: Thierry Reding @ 2016-09-09 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909152032.9550-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.9-soc
for you to fetch changes up to a9ccc123a8e05365f7515dcd023b01100809a6fa:
soc/tegra: pmc: Fix incorrect DPD request (2016-08-16 12:30:52 +0200)
Thanks,
Thierry
----------------------------------------------------------------
soc/tegra: Changes for v4.9-rc1
This contains a single patch to fix an issue with setting the deep power
down mode of I/O rails.
----------------------------------------------------------------
Vince Hsu (1):
soc/tegra: pmc: Fix incorrect DPD request
drivers/soc/tegra/pmc.c | 28 ++++++++--------------------
1 file changed, 8 insertions(+), 20 deletions(-)
^ permalink raw reply
* [GIT PULL 1/4] bus: NVIDIA Tegra ACONNECT changes for v4.9-rc1
From: Thierry Reding @ 2016-09-09 15:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC maintainers,
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.9-bus
for you to fetch changes up to 3a99cb090b523f88d0a19598d39704afac11adcb:
bus: tegra-aconnect: Use of_pm_clk_add_clk() (2016-08-16 12:22:51 +0200)
Thanks,
Thierry
----------------------------------------------------------------
bus: NVIDIA Tegra ACONNECT changes for v4.9-rc1
This contains a patch that makes use of some symbols that were added in
v4.8 and a second patch takes advantage to enable building the driver as
a loadable module.
----------------------------------------------------------------
Jon Hunter (1):
bus: tegra-aconnect: Use of_pm_clk_add_clk()
Thierry Reding (1):
bus: tegra-aconnect: Make symbol tristate
drivers/bus/Kconfig | 6 +-----
drivers/bus/tegra-aconnect.c | 22 ++--------------------
2 files changed, 3 insertions(+), 25 deletions(-)
^ permalink raw reply
* [PATCH v10 3/4] ARM64: ACPI: enable ACPI_SPCR_TABLE
From: Will Deacon @ 2016-09-09 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ffcabf79-17b8-f386-32b5-a6052f27f992@linaro.org>
On Fri, Sep 09, 2016 at 06:07:04PM +0300, Aleksey Makarov wrote:
> On 09/09/2016 12:29 PM, Will Deacon wrote:
> > On Wed, Sep 07, 2016 at 12:30:19PM +0300, Aleksey Makarov wrote:
> >>
> >> On 09/05/2016 03:36 PM, Aleksey Makarov wrote:
> >>> SBBR mentions SPCR as a mandatory ACPI table. So enable it for ARM64
> >>>
> >>> Earlycon should be set up as early as possible. ACPI boot tables are
> >>> mapped in arch/arm64/kernel/acpi.c:acpi_boot_table_init() that
> >>> is called from setup_arch() and that's where we parse SPCR.
> >>> So it has to be opted-in per-arch.
> >>>
> >>> When ACPI_SPCR_TABLE is defined initialization of DT earlycon is
> >>> deferred until the DT/ACPI decision is done. Initialize DT earlycon
> >>> if ACPI is disabled.
> >>
> >> Hi Will, Catalin,
> >>
> >> Can you review this patch and consider ACKing it please?
> >
> > Since the ACPI folks seem happy with the series, then:
> >
> > Acked-by: Will Deacon <will.deacon@arm.com>
> >
> > for this patch.
>
> Thank you. Can you pull the series? Should I ask Rafael?
The series should go via Rafael, since the bulk of the changes are
outside of arch/arm64.
Will
^ permalink raw reply
* [PATCH 08/10] PM / Domains: Add support for removing PM domains
From: Jon Hunter @ 2016-09-09 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c8498eca-6934-1cab-31d9-3d8ce4c74897@nvidia.com>
On 09/09/16 14:54, Jon Hunter wrote:
> On 08/09/16 12:49, Ulf Hansson wrote:
>> On 16 August 2016 at 11:49, Jon Hunter <jonathanh@nvidia.com> wrote:
>>> The genpd framework allows users to add PM domains via the pm_genpd_init()
>>> function, however, there is no corresponding function to remove a PM
>>> domain. For most devices this may be fine as the PM domains are never
>>> removed, however, for devices that wish to populate the PM domains from
>>> within a driver, having the ability to remove a PM domain if the probing
>>> of the device fails or the driver is unloaded is necessary.
>>>
>>> Add the function pm_genpd_remove() to remove a PM domain by referencing
>>> it's generic_pm_domain structure.
>>>
>>> PM domains can only be removed if they are not a parent domain to
>>> another PM domain and have no devices associated with them.
>>
>> I think we should also check if the there's is a provider registered
>> for the genpd, as it should also prevent the genpd from being removed.
>> Right?
>
> Yes I would agree. I had thought that after patch #4 of this series that
> only the provider itself would be able to call this. However, we should
> probably still verify that the provider has correctly remove itself.
So now I have the following. I am still not 100% happy. I cannot clear
the ->provider when calling of_genpd_del_provider() and so I cannot use
this to verify if the provider is present and so I need to check the
list of providers and it gets a bit messy. I have been wracking my
brains to find a better alternative (including a single function to
remove the provider and domains at once but there are issues with that
as well).
I think that long term it may make sense to reference the providers
exclusively by the fwnode_handle and make the list of provider non-DT
specific. I could do it now, but it would increase the series.
Cheers
Jon
---
drivers/base/power/domain.c | 89 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 5 +++
2 files changed, 94 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 82f87038f108..57c64fc1a164 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -39,6 +39,8 @@
static LIST_HEAD(gpd_list);
static DEFINE_MUTEX(gpd_list_lock);
+static bool genpd_provider_present(struct device_node *np);
+
/*
* Get the generic PM domain for a particular struct device.
* This validates the struct device pointer, the PM domain pointer,
@@ -1356,6 +1358,68 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
}
EXPORT_SYMBOL_GPL(pm_genpd_init);
+static int genpd_remove(struct generic_pm_domain *genpd)
+{
+ struct gpd_link *l, *link;
+
+ if (IS_ERR_OR_NULL(genpd))
+ return -EINVAL;
+
+ mutex_lock(&genpd->lock);
+
+ if (is_of_node(genpd->provider)) {
+ if (genpd_provider_present(to_of_node(genpd->provider))) {
+ mutex_unlock(&genpd->lock);
+ pr_err("Provider present, unable to remove %s\n",
+ genpd->name);
+ return -EBUSY;
+ }
+ }
+
+ if (!list_empty(&genpd->master_links) || genpd->device_count) {
+ mutex_unlock(&genpd->lock);
+ pr_err("%s: unable to remove %s\n", __func__, genpd->name);
+ return -EBUSY;
+ }
+
+ list_for_each_entry_safe(link, l, &genpd->slave_links, slave_node) {
+ list_del(&link->master_node);
+ list_del(&link->slave_node);
+ kfree(link);
+ }
+
+ list_del(&genpd->gpd_list_node);
+ mutex_unlock(&genpd->lock);
+ cancel_work_sync(&genpd->power_off_work);
+ pr_debug("%s: removed %s\n", __func__, genpd->name);
+
+ return 0;
+}
+
+/**
+ * pm_genpd_remove - Remove a generic I/O PM domain
+ * @genpd: Pointer to PM domain that is to be removed.
+ *
+ * To remove the PM domain, this function:
+ * - Removes the PM domain as a subdomain to any parent domains,
+ * if it was added.
+ * - Removes the PM domain from the list of registered PM domains.
+ *
+ * The PM domain will only be removed, if it is not a parent to any
+ * other PM domain and has no devices associated with it.
+ */
+int pm_genpd_remove(struct generic_pm_domain *genpd)
+{
+ int ret;
+
+ mutex_lock(&gpd_list_lock);
+ ret = genpd_remove(genpd);
+ mutex_unlock(&gpd_list_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pm_genpd_remove);
+
#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
typedef struct generic_pm_domain *(*genpd_xlate_t)(struct of_phandle_args *args,
@@ -1563,6 +1627,26 @@ void of_genpd_del_provider(struct device_node *np)
EXPORT_SYMBOL_GPL(of_genpd_del_provider);
/**
+ * genpd_provider_present() - Verify if a PM domain provider is present
+ * @np: Device node pointer associated with the PM domain provider
+ */
+static bool genpd_provider_present(struct device_node *np)
+{
+ struct of_genpd_provider *cp;
+
+ mutex_lock(&of_genpd_mutex);
+ list_for_each_entry(cp, &of_genpd_providers, link) {
+ if (cp->node == np) {
+ mutex_unlock(&of_genpd_mutex);
+ return true;
+ }
+ }
+ mutex_unlock(&of_genpd_mutex);
+
+ return false;
+}
+
+/**
* genpd_get_from_provider() - Look-up PM domain
* @genpdspec: OF phandle args to use for look-up
*
@@ -1798,6 +1882,11 @@ out:
return ret ? -EPROBE_DEFER : 0;
}
EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
+#else
+static bool genpd_provider_present(struct device_node *np)
+{
+ return false;
+}
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index e71764ac7248..4aa285e44eb0 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -129,6 +129,7 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
struct generic_pm_domain *target);
extern int pm_genpd_init(struct generic_pm_domain *genpd,
struct dev_power_governor *gov, bool is_off);
+extern int pm_genpd_remove(struct generic_pm_domain *genpd);
extern struct dev_power_governor simple_qos_governor;
extern struct dev_power_governor pm_domain_always_on_gov;
@@ -164,6 +165,10 @@ static inline int pm_genpd_init(struct generic_pm_domain *genpd,
{
return -ENOSYS;
}
+static inline int pm_genpd_remove(struct generic_pm_domain *genpd)
+{
+ return -ENOTSUPP;
+}
#endif
static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
--
2.1.4
--
nvpublic
^ permalink raw reply related
* [PATCH v3 1/8] arm64: KVM: Use static keys for selecting the GIC backend
From: Vladimir Murzin @ 2016-09-09 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D2C469.1030006@arm.com>
On 09/09/16 15:17, Marc Zyngier wrote:
> On 09/09/16 14:45, Vladimir Murzin wrote:
>> On 09/09/16 10:33, Vladimir Murzin wrote:
>>> Hi Marc,
>>>
>>> On 09/09/16 10:19, Marc Zyngier wrote:
>>>>> Hi Vladimir,
>>>>>
>>> ...
>>>>>>>
>>>>>>> +extern struct static_key_false kvm_gicv3_cpuif;
>>>>>
>>>>> I think we should follow the model set by kvm_vgic_global_state, which
>>>>> is declared in arm_vgic.h. Even better, we should *embed* the static key
>>>>> in this structure. This will reduce the clutter and we wouldn't have to
>>>>> deal with all the section stuff (the hyp_data thing is a good cleanup,
>>>>> but I'd like to see it as a separate patch if possible).
>>> Yes, it is what I was thinking about too, but was not sure about which
>>> way to go, so hyp_data seemed me something we might reuse latter.
>>> However, I agree that we can defer hyp_data thing...
>>>
>>
>> I've just tried it out and it seems that static keys are not happy to
>> accept a key after kern_hyp_va is applied at &kvm_vgic_global_state:
>
> Ah, there is a trick. You do not need kern_hyp_va at all, because this
> is not evaluated as an expression at runtime (so the pointer doesn't matter).
>
Ah, right, thank for a tip! ;)
>>> In file included from ./include/linux/jump_label.h:105:0,
>>> from arch/arm64/kvm/hyp/switch.c:19:
>>> ./arch/arm64/include/asm/jump_label.h: In function ?__guest_run?:
>>> ./arch/arm64/include/asm/jump_label.h:31:2: warning: asm operand 0 probably doesn?t match constraints
>>> asm goto("1: nop\n\t"
>>> ^
>>> ./arch/arm64/include/asm/jump_label.h:31:2: warning: asm operand 0 probably doesn?t match constraints
>>> asm goto("1: nop\n\t"
>>> ^
>>> ./arch/arm64/include/asm/jump_label.h:31:2: error: impossible constraint in ?asm?
>>> asm goto("1: nop\n\t"
>>> ^
>>> ./arch/arm64/include/asm/jump_label.h:31:2: error: impossible constraint in ?asm?
>>> asm goto("1: nop\n\t"
>>> ^
>>> make[1]: *** [arch/arm64/kvm/hyp/switch.o] Error 1
>>> make: *** [arch/arm64/kvm/hyp/switch.o] Error 2
>>
>> it looks like we cannot avoid hyp_data thing... if you don't mind I can
>> do hyp_data clean-up in separate patch. Alternatively, we can do
>> conversion to static keys for both architectures later as an
>> optimisation step.
>
> Can you try the above first? I've just tried the same approach with my
> vgic-trap series, and it compiles fine (untested though):
I was about to try it out, but didn't manage to find a branch with
vgic-trap series, so I did a quick fixup for my series and now it is
running non-VHE boot tests and I don't expect issues with VHE one. I
think diff bellow should work runtime too, but if you do want me to give
it a try it'd be handy to have a branch I can pull from ;)
>
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 194184c..397e240 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -301,7 +301,7 @@ again:
> if (exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
> goto again;
>
> - if (static_branch_unlikely(&vgic_v2_cpuif_trap) &&
> + if (static_branch_unlikely(&kvm_vgic_global_state.vgic_v2_cpuif_trap) &&
> exit_code == ARM_EXCEPTION_TRAP) {
> bool valid;
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index bb46c03..cc59a28 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -67,6 +67,9 @@ struct vgic_global {
>
> /* Only needed for the legacy KVM_CREATE_IRQCHIP */
> bool can_emulate_gicv2;
> +
> + /* Trapping GICv2 GICV region? */
> + struct static_key_false vgic_v2_cpuif_trap;
> };
>
> extern struct vgic_global kvm_vgic_global_state;
> @@ -269,8 +272,6 @@ struct vgic_cpu {
> bool lpis_enabled;
> };
>
> -extern struct static_key_false vgic_v2_cpuif_trap;
> -
> int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64 *addr, bool write);
> void kvm_vgic_early_init(struct kvm *kvm);
> int kvm_vgic_create(struct kvm *kvm, u32 type);
> diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
> index 0a063af..4af600e 100644
> --- a/virt/kvm/arm/vgic/vgic-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-v2.c
> @@ -278,7 +278,7 @@ int vgic_v2_map_resources(struct kvm *kvm)
> goto out;
> }
>
> - if (!static_branch_unlikely(&vgic_v2_cpuif_trap)) {
> + if (!static_branch_unlikely(&kvm_vgic_global_state.vgic_v2_cpuif_trap)) {
> ret = kvm_phys_addr_ioremap(kvm, dist->vgic_cpu_base,
> kvm_vgic_global_state.vcpu_base,
> KVM_VGIC_V2_CPU_SIZE, true);
> @@ -296,8 +296,6 @@ out:
> return ret;
> }
>
> -DEFINE_STATIC_KEY_FALSE(vgic_v2_cpuif_trap);
> -
> /**
> * vgic_v2_probe - probe for a GICv2 compatible interrupt controller in DT
> * @node: pointer to the DT node
> @@ -314,6 +312,8 @@ int vgic_v2_probe(const struct gic_kvm_info *info)
> return -ENXIO;
> }
>
> + kvm_vgic_global_state.vgic_v2_cpuif_trap = STATIC_KEY_FALSE_INIT;
> +
I did this a bit different:
+struct vgic_global __section(.hyp.text) kvm_vgic_global_state =
{.gicv3_cpuif = STATIC_KEY_FALSE_INIT,};
Thanks
Vladimir
> if (!PAGE_ALIGNED(info->vcpu.start) ||
> !PAGE_ALIGNED(resource_size(&info->vcpu))) {
> kvm_info("GICV region size/alignment is unsafe, using trapping (reduced performance)\n");
> @@ -332,7 +332,7 @@ int vgic_v2_probe(const struct gic_kvm_info *info)
> goto out;
> }
>
> - static_branch_enable(&vgic_v2_cpuif_trap);
> + static_branch_enable(&kvm_vgic_global_state.vgic_v2_cpuif_trap);
> }
>
> kvm_vgic_global_state.vctrl_base = ioremap(info->vctrl.start,
>
>
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH v10 3/4] ARM64: ACPI: enable ACPI_SPCR_TABLE
From: Aleksey Makarov @ 2016-09-09 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909092958.GB20192@arm.com>
On 09/09/2016 12:29 PM, Will Deacon wrote:
> On Wed, Sep 07, 2016 at 12:30:19PM +0300, Aleksey Makarov wrote:
>>
>> On 09/05/2016 03:36 PM, Aleksey Makarov wrote:
>>> SBBR mentions SPCR as a mandatory ACPI table. So enable it for ARM64
>>>
>>> Earlycon should be set up as early as possible. ACPI boot tables are
>>> mapped in arch/arm64/kernel/acpi.c:acpi_boot_table_init() that
>>> is called from setup_arch() and that's where we parse SPCR.
>>> So it has to be opted-in per-arch.
>>>
>>> When ACPI_SPCR_TABLE is defined initialization of DT earlycon is
>>> deferred until the DT/ACPI decision is done. Initialize DT earlycon
>>> if ACPI is disabled.
>>
>> Hi Will, Catalin,
>>
>> Can you review this patch and consider ACKing it please?
>
> Since the ACPI folks seem happy with the series, then:
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
> for this patch.
Thank you. Can you pull the series? Should I ask Rafael?
>
> Will
>
^ permalink raw reply
* [PATCH V4 3/4] ARM: bcm2835: add thermal node to device-tree of bcm283x
From: Martin Sperl @ 2016-09-09 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19cc8fbf-6ceb-995e-850d-9d82bdaff8d0@i2se.com>
> On 09.09.2016, at 16:25, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>
>> Am 09.09.2016 um 09:49 schrieb kernel at martin.sperl.org:
>> From: Martin Sperl <kernel@martin.sperl.org>
>>
>> Add the node for the thermal sensor of the bcm2835-soc
>> to the device tree.
>>
>> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
>> Reviewed-by: Eric Anholt <eric@anholt.net>
>> ---
>> arch/arm/boot/dts/bcm283x.dtsi | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
>> index b982522..e2e3a46 100644
>> --- a/arch/arm/boot/dts/bcm283x.dtsi
>> +++ b/arch/arm/boot/dts/bcm283x.dtsi
>> @@ -186,6 +186,12 @@
>> interrupts = <2 14>; /* pwa1 */
>> };
>>
>> + thermal: thermal at 0x7e212000 {
>> + compatible = "brcm,bcm2835-thermal";
>> + reg = <0x7e212000 0x8>;
>> + clocks = <&clocks BCM2835_CLOCK_TSENS>;
>> + };
>> +
>
> Since the driver handles 3 different SoC (2835, 2836, 2837). This node
> should be defined in the SoC specific dtsi files, because the BCM2836
> includes bcm283x.dtsi too.
>
> Be aware the patch for bcm2837 must go to ARM64.
I can not really follow:
* the node is defined in the dtsi included by all 3 soc,
and it is available on all so it sits where for example
spi0 or uart0 is located
* as for arm64: this describes the registers that are
identical for arm and arm64 and the bcm2837.dtsi
is also including ../../../../arm/boot/dts/bcm283x.dtsi
So what is the problem?
Martin
P.s the patches apply cleanly against master.
^ permalink raw reply
* [GIT PULL] Allwinner clock fixes for 4.8
From: Maxime Ripard @ 2016-09-09 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b03d92eb-ac69-506d-d05a-e28bca5ca284@codeaurora.org>
Hi Stephen,
On Thu, Sep 08, 2016 at 12:56:53PM -0700, Stephen Boyd wrote:
> On 09/07/2016 12:33 PM, Maxime Ripard wrote:
> > Hi Mike, Stephen,
> >
> > Please pull the following tag for the 4.8 release.
> >
> > Thanks!
> > Maxime
> >
> > The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
> >
> > Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
> >
> > are available in the git repository at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-clk-fixes-for-4.8
> >
> > for you to fetch changes up to 6654674cb7b5953ac04fc9d7f5f511676ae97e29:
> >
> > clk: sunxi-ng: Fix wrong reset register offsets (2016-08-29 08:38:55 +0200)
> >
> > ----------------------------------------------------------------
> > Clock Fixes for the Allwinner SoCs, 4.8 Edition
> >
> > The usual bunch of fixes to the our clock drivers, mostly targetted to the
> > brand new sunxi-ng drivers.
>
> Pulled, thanks. But,
Thanks!
> >
> > ----------------------------------------------------------------
> > Chen-Yu Tsai (2):
> > clk: sunxi-ng: Fix inverted test condition in ccu_helper_wait_for_lock
>
> we already had this one in clk-fixes. Git figured it out of course.
Hmmm, sorry, it was probably a mistake from when I got back from
vacation.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160909/6ea04eaf/attachment-0001.sig>
^ permalink raw reply
* [PATCH v5 3/3] iio: adc: add support for Allwinner SoCs ADC
From: Maxime Ripard @ 2016-09-09 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473344917-1524-4-git-send-email-quentin.schulz@free-electrons.com>
On Thu, Sep 08, 2016 at 04:28:37PM +0200, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a touchscreen
> controller and a thermal sensor. This patch adds the ADC driver which is
> based on the MFD for the same SoCs ADC.
>
> This also registers the thermal adc channel in the iio map array so
> iio_hwmon could use it without modifying the Device Tree. This registers
> the driver in the thermal framework.
>
> This driver probes on three different platform_device_id to take into
> account slight differences (registers bit and temperature computation)
> between Allwinner SoCs ADCs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160909/f5011934/attachment.sig>
^ permalink raw reply
* next-20160909 build: 1 failures 0 warnings (next-20160909)
From: Guenter Roeck @ 2016-09-09 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3281448.mbmBk67UZ8@wuerfel>
On 09/09/2016 03:56 AM, Arnd Bergmann wrote:
> On Friday, September 9, 2016 11:14:07 AM CEST Mark Brown wrote:
>> On Fri, Sep 09, 2016 at 09:54:37AM +0100, Build bot for Mark Brown wrote:
>>
>> Since yesterday -next has been failing to build an arm64 allmodconfig
>> due to:
>>
>>> arm64-allmodconfig
>>> ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!
>>
>> caused by 05dbf57876b97d2 (hwmon: Add xgene hwmon driver). That symbol
>> is not exported so can't be used from modules though I can't immediately
>> see how that module acquired a reference to that symbol.
>
> See also https://lkml.org/lkml/2016/9/8/311
>
> I haven't done a patch since we're still debating about how to best
> address this.
>
Until there is a solution, I'll mark the xgene driver as BROKEN. Though I really
think it is the victim here, not the culprit.
Guenter
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi
From: Ian Campbell @ 2016-09-09 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7746678.0mZLVD2k0J@wuerfel>
On Tue, 2016-08-23 at 12:09 +0200, Arnd Bergmann wrote:
> I had skipped the new message as well while sorting through 5000
> messages after my vacation, but I've now put it into my TODO folder
> and will get to it eventually.
Is it still on your TODO or should I do...
> We sometimes miss stuff that is meant for arm-soc when it comes
> from people that don't normally send us patches. If you want to
> be sure to catch the attention, stick a 'GIT PULL' into the subject
> or send a ping on IRC.
... one of these?
It'd be great to get this fixed in v4.8 so that the corresponding
device-tree.git tag will build.
Thanks,
Ian.
^ 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