* [PATCH 1/5] ARM: dts: imx: add Boundary Devices Nitrogen6_SOM2 support
From: Gary Bisson @ 2016-11-01 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101141338.GC9807@dragon>
Hi Shawn,
On Tue, Nov 1, 2016 at 3:13 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> On Tue, Oct 25, 2016 at 11:19:51PM +0200, Gary Bisson wrote:
>> SoM based on i.MX6 Quad with 1GB of DDR3.
>>
>> https://boundarydevices.com/product/nit6x-som-v2/
>>
>> Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/imx6q-nitrogen6_som2.dts | 53 ++
>> arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 770 ++++++++++++++++++++++++++
>> 3 files changed, 824 insertions(+)
>> create mode 100644 arch/arm/boot/dts/imx6q-nitrogen6_som2.dts
>> create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
>
> <snip>
>
>> +/ {
>> + chosen {
>> + stdout-path = &uart2;
>> + };
>> +
>> + memory {
>> + reg = <0x10000000 0x40000000>;
>> + };
>> +
>> + backlight_lcd: backlight_lcd {
>
> Please use hyphen instead of underscore in node name. Please check
> through the patch series.
Sorry about that, forgot (again). Just to make sure, the label can
have underscore but not the name right? Or is it better to have hypens
everywhere?
So I guess I need to make a pass on current boards as well. Some
patches in my series rename the panel to panel_lvdsX to match the
current Nitrogen6_MAX naming[1] but this would need to be changed to
panel-lvdsX as well.
Regards,
Gary
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi#n296
^ permalink raw reply
* [PATCH 01/14] dma: sun6i-dma: Add burst case of 4
From: Chen-Yu Tsai @ 2016-11-01 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477922460.2837.5.camel@intel.com>
On Tue, Nov 1, 2016 at 9:46 PM, Koul, Vinod <vinod.koul@intel.com> wrote:
> On Sun, 2016-10-30 at 10:06 +0800, Chen-Yu Tsai wrote:
>> Looking at the dmaengine API, I believe we got it wrong.
>>
>> max_burst in dma_slave_config denotes the largest amount of data
>> a single transfer should be, as described in dmaengine.h:
>
> Not a single transfer but smallest transaction within a transfer of a
> block. So dmaengines transfer data in bursts from source to destination,
> this parameter decides the size of that bursts
Right.
>
>>
>> * @src_maxburst: the maximum number of words (note: words, as in
>> * units of the src_addr_width member, not bytes) that can be sent
>> * in one burst to the device. Typically something like half the
>> * FIFO depth on I/O peripherals so you don't overflow it. This
>> * may or may not be applicable on memory sources.
>> * @dst_maxburst: same as src_maxburst but for destination target
>> * mutatis mutandis.
>>
>> The DMA engine driver should be free to select whatever burst size
>> that doesn't exceed this. So for max_burst = 4, the driver can select
>> burst = 4 for controllers that do support it, or burst = 1 for those
>> that don't, and do more bursts.
>
> Nope, the client configures these parameters and dmaengine driver
> validates and programs
Shouldn't we just name it "burst_size" then if it's meant to be what
the client specifically asks for?
My understanding is that the client configures its own parameters,
such as the trigger level for the DRQ, like raise DRQ when level < 1/4
FIFO depth, request maxburst = 1/4 or 1/2 FIFO depth, so as not to
overrun the FIFO. When the DRQ is raised, the DMA engine will do a
burst, and after the burst the DRQ would be low again, so the DMA
engine will wait. So the DMA engine driver should be free to
program the actual burst size to something less than maxburst, shouldn't
it?
>>
>> This also means we can increase max_burst for the audio codec, as
>> the FIFO is 64 samples deep for stereo, or 128 samples for mono.
>
> Beware that higher bursts means chance of underrun of FIFO. This value
> is selected with consideration of power and performance required. Lazy
> allocation would be half of FIFO size..
You mean underrun if its the source right? So the client setting maxburst
should take the DRQ trigger level into account for this.
Regards
ChenYu
^ permalink raw reply
* [PATCH/RESEND V4 2/3] ARM64 LPC: Add missing range exception for special ISA
From: kbuild test robot @ 2016-11-01 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478006926-240933-3-git-send-email-yuanzhichang@hisilicon.com>
Hi zhichang.yuan,
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.9-rc3 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/zhichang-yuan/ARM64-LPC-legacy-ISA-I-O-support/20161101-211425
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: openrisc-or1ksim_defconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All errors (new ones prefixed by >>):
drivers/of/address.c: In function '__of_address_to_resource':
>> drivers/of/address.c:733:40: error: 'PCIBIOS_MIN_IO' undeclared (first use in this function)
drivers/of/address.c:733:40: note: each undeclared identifier is reported only once for each function it appears in
vim +/PCIBIOS_MIN_IO +733 drivers/of/address.c
727 if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
728 return -EINVAL;
729 taddr = of_translate_address(dev, addrp);
730 if (taddr == OF_BAD_ADDR)
731 return -EINVAL;
732 memset(r, 0, sizeof(struct resource));
> 733 if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
734 unsigned long port;
735
736 port = pci_address_to_pio(taddr);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 7206 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161101/dc5720b1/attachment-0001.gz>
^ permalink raw reply
* [PATCH] staging: vc04_services: parse_rx_slots() - Fix compiler warning
From: Michael Zoran @ 2016-11-01 15:21 UTC (permalink / raw)
To: linux-arm-kernel
vc04_services contains a debug logging mechanism. The log is
maintained in a shared memory area between the kernel and the
firmware. Changing the sizes of the data in this area would
require a firmware change which is distributed independently
from the kernel binary.
One of the items logged is the address of received messages.
This address is a pointer, but the debugging slot used to store
the information is a 32 bit integer.
Luckily, this value is never interpreted by anything other
then debug tools and it is expected that a human debugging
the kernel interpret it.
This change adds a cast to long before the original cast
to int to silence the warning.
Signed-off-by: Michael Zoran <mzoran@crowfest.net>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index f3e1000..c187719 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -1619,7 +1619,7 @@ parse_rx_slots(VCHIQ_STATE_T *state)
header = (VCHIQ_HEADER_T *)(state->rx_data +
(state->rx_pos & VCHIQ_SLOT_MASK));
- DEBUG_VALUE(PARSE_HEADER, (int)header);
+ DEBUG_VALUE(PARSE_HEADER, (int)(long)header);
msgid = header->msgid;
DEBUG_VALUE(PARSE_MSGID, msgid);
size = header->size;
--
2.10.2
^ permalink raw reply related
* [PATCH] KVM: arm/arm64: vgic: Prevent VGIC_ADDR_TO_INTID from emiting divisions
From: Christoffer Dall @ 2016-11-01 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161029111901.16668-1-marc.zyngier@arm.com>
On Sat, Oct 29, 2016 at 12:19:01PM +0100, Marc Zyngier wrote:
> Using non-constant number of bits for VGIC_ADDR_TO_INTID() leads
> to gcc 6.1 emiting calls to __aeabi_uldivmod, which the kernel
> does not implement.
>
> As we really don't want to implement complex division in the kernel,
> the only other option is to prove to the compiler that there is only
> a few values that are possible for the number of bits per IRQ, and
> that they are all power of 2.
>
> We turn the VGIC_ADDR_TO_INTID macro into a switch that looks for
> the supported set of values (1, 2, 8, 64), and perform the computation
> accordingly. When "bits" is a constant, the compiler optimizes
> away the other cases. If not, we end-up with a small number of cases
> that GCC optimises reasonably well. Out of range values are detected
> both at build time (constants) and at run time (variables).
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> This should be applied *before* Andre's patch fixing out of bound SPIs.
>
> virt/kvm/arm/vgic/vgic-mmio.h | 33 ++++++++++++++++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
> index 4c34d39..a457282 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.h
> +++ b/virt/kvm/arm/vgic/vgic-mmio.h
> @@ -57,10 +57,41 @@ extern struct kvm_io_device_ops kvm_io_gic_ops;
> * multiplication with the inverted fraction, and scale up both the
> * numerator and denominator with 8 to support at most 64 bits per IRQ:
> */
> -#define VGIC_ADDR_TO_INTID(addr, bits) (((addr) & VGIC_ADDR_IRQ_MASK(bits)) * \
> +#define __VGIC_ADDR_INTID(addr, bits) (((addr) & VGIC_ADDR_IRQ_MASK(bits)) * \
> 64 / (bits) / 8)
>
> /*
> + * Perform the same computation, but also handle non-constant number
> + * of bits. We only care about the few cases that are required by
> + * GICv2/v3.
> + */
> +#define VGIC_ADDR_TO_INTID(addr, bits) \
> + ({ \
> + u32 __v; \
> + switch((bits)) { \
> + case 1: \
> + __v = __VGIC_ADDR_INTID((addr), 1); \
> + break; \
> + case 2: \
> + __v = __VGIC_ADDR_INTID((addr), 2); \
> + break; \
> + case 8: \
> + __v = __VGIC_ADDR_INTID((addr), 8); \
> + break; \
> + case 64: \
> + __v = __VGIC_ADDR_INTID((addr), 64); \
> + break; \
> + default: \
> + if (__builtin_constant_p((bits))) \
> + BUILD_BUG(); \
> + else \
> + BUG(); \
> + } \
> + \
> + __v; \
> + })
> +
> +/*
> * Some VGIC registers store per-IRQ information, with a different number
> * of bits per IRQ. For those registers this macro is used.
> * The _WITH_LENGTH version instantiates registers with a fixed length
> --
> 2.9.3
>
Looks functionally correct, just wondering if it's cleaner to turn the
whole thing into a static inline, or if it can be rewritten to use
shifts with any benefit.
In any case, if you like this version:
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
^ permalink raw reply
* [PATCH 2/3] KVM: arm/arm64: Add ARM arch timer interrupts ABI
From: Christoffer Dall @ 2016-11-01 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA_mdrTUBBDV91X3Zo6pNzVaukQ7foN+cPt_41+ouBdEfQ@mail.gmail.com>
On Tue, Nov 01, 2016 at 02:54:11PM +0000, Peter Maydell wrote:
> On 1 November 2016 at 14:50, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Tue, Nov 01, 2016 at 11:26:54AM +0000, Peter Maydell wrote:
> >> Possible current and future outbound interrupt lines (some of these
> >> would only show up in some unlikely or lots-of-implementation-needed
> >> cases, I'm just trying to produce an exhaustive list):
> >> * virtual timer
> >> * physical timer
> >> * hyp timer (nested virtualization case)
> >> * secure timer (unlikely but maybe if EL3 is ever supported inside a VM)
> >> * gic maintenance interrupt (nested virt again)
> >> * PMU interrupt
> >
> > Thanks for the list, that's good to have around for the future.
> >
> > There's also the potential of the EL2 virtual timer for nested VHE
> > support, right?
>
> That's the one I meant by "hyp timer".
>
there's the hyp timer, and then there's the ARMv8.1 virtual hyp timer.
> >> The kernel doesn't know which interrupt number these would be wired
> >> up to, so they're all just arbitrary outputs, and you could put them
> >> in one field or split them up into multiple fields, it doesn't make
> >> much difference.
> >>
> >
> > So if we keep this we're kind of suggesting that we'll have a field per
> > device type later on. Since this is a u8 and we are talking about up 5
> > 5 timers already,
>
> 4.
>
virtual
physical
hyp
virtual hyp
secure
Am I missing something?
-Christoffer
^ permalink raw reply
* [PATCH] fpga zynq: Check the bitstream for validity
From: Jason Gunthorpe @ 2016-11-01 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7117d821-a1b1-7c07-806a-483be99131e6@xilinx.com>
On Tue, Nov 01, 2016 at 07:39:22AM +0100, Michal Simek wrote:
> Regarding BIT and BIN format. This support is in vivado for a long time
> and it is up2you what you want to support. We have removed that BIT
> support and not doing any swap by saying only BIN format is supported.
BIN is not supported, it needs a swap as well.
Moritz has it right, you have to use vivado to create a PROM image to be
compatible with the driver.
Jason
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add Macnica Americas vendor prefix
From: Dinh Nguyen @ 2016-11-01 15:36 UTC (permalink / raw)
To: linux-arm-kernel
Add a vendor prefix for the Macnica company.
http://http://www.macnica.com
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea..81674f2 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -158,6 +158,7 @@ lg LG Corporation
linux Linux-specific binding
lltc Linear Technology Corporation
lsi LSI Corp. (LSI Logic)
+macnica Macnica Americas
marvell Marvell Technology Group Ltd.
maxim Maxim Integrated Products
meas Measurement Specialties
--
2.8.3
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: Add vendor prefix for Terasic Inc.
From: Dinh Nguyen @ 2016-11-01 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101153632.6844-1-dinguyen@kernel.org>
Add a vendor prefix for Terasic.
http://www.terasic.com
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 81674f2..948d3ac 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -276,6 +276,7 @@ tcg Trusted Computing Group
tcl Toby Churchill Ltd.
technexion TechNexion
technologic Technologic Systems
+terasic Terasic Inc.
thine THine Electronics, Inc.
ti Texas Instruments
tlm Trusted Logic Mobility
--
2.8.3
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: Add vendor prefix for Samtec
From: Dinh Nguyen @ 2016-11-01 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101153632.6844-1-dinguyen@kernel.org>
Add a vendor prefix for Samtec, a Softing company.
http://www.samtec.de
http://www.samtec.org
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 948d3ac..bff8f53 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -232,6 +232,7 @@ richtek Richtek Technology Corporation
ricoh Ricoh Co. Ltd.
rockchip Fuzhou Rockchip Electronics Co., Ltd
samsung Samsung Semiconductor
+samtec Samtec/Softing company
sandisk Sandisk Corporation
sbs Smart Battery System
schindler Schindler
--
2.8.3
^ permalink raw reply related
* [PATCH] ARM: dts: socfpga: add specific compatible strings for boards
From: Dinh Nguyen @ 2016-11-01 15:38 UTC (permalink / raw)
To: linux-arm-kernel
Add a more specific board compatible entry for all of the SOCFPGA
Cyclone 5 based boards.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
index afea364..5ecd2ef 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
@@ -18,7 +18,7 @@
/ {
model = "Terasic DE-0(Atlas)";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "terasic,de0-atlas", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
index 424523b..668d77c 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
@@ -19,7 +19,7 @@
/ {
model = "Aries/DENX MCV EVK";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "denx, mcvevk", "altr,socfpga-cyclone5", "altr,socfpga";
aliases {
ethernet0 = &gmac0;
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
index 15e43f4..b0577c1 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
@@ -19,7 +19,7 @@
/ {
model = "Altera SOCFPGA Cyclone V SoC Development Kit";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "altr,socdk", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
index 02e22f5..c5623a7 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
@@ -19,7 +19,7 @@
/ {
model = "Terasic SoCkit";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "terasic,sockit", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
index 9aaf413..992ae49 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
@@ -21,7 +21,7 @@
/ {
model = "Altera SOCFPGA Cyclone V SoC Macnica Sodia board";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "macnica, sodia", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
index b844473..78b187e 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
@@ -51,7 +51,7 @@
/ {
model = "samtec VIN|ING FPGA";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "samtec,vining". "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "console=ttyS0,115200";
--
2.8.3
^ permalink raw reply related
* [PATCH/RESEND V4 2/3] ARM64 LPC: Add missing range exception for special ISA
From: kbuild test robot @ 2016-11-01 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478006926-240933-3-git-send-email-yuanzhichang@hisilicon.com>
Hi zhichang.yuan,
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.9-rc3 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/zhichang-yuan/ARM64-LPC-legacy-ISA-I-O-support/20161101-211425
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: arm-efm32_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `__of_address_to_resource':
>> drivers/of/address.c:748: undefined reference to `pcibios_min_io'
vim +748 drivers/of/address.c
1f5bef30 Grant Likely 2010-06-08 742 r->start = taddr;
1f5bef30 Grant Likely 2010-06-08 743 r->end = taddr + size - 1;
1f5bef30 Grant Likely 2010-06-08 744 }
1f5bef30 Grant Likely 2010-06-08 745 r->flags = flags;
35f3da32 Benoit Cousson 2011-12-05 746 r->name = name ? name : dev->full_name;
35f3da32 Benoit Cousson 2011-12-05 747
1f5bef30 Grant Likely 2010-06-08 @748 return 0;
1f5bef30 Grant Likely 2010-06-08 749 }
1f5bef30 Grant Likely 2010-06-08 750
1f5bef30 Grant Likely 2010-06-08 751 /**
:::::: The code at line 748 was first introduced by commit
:::::: 1f5bef30cf6c66f097ea5dfc580a41924df888d1 of/address: merge of_address_to_resource()
:::::: TO: Grant Likely <grant.likely@secretlab.ca>
:::::: CC: Grant Likely <grant.likely@secretlab.ca>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 10888 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161101/12b0bc75/attachment.gz>
^ permalink raw reply
* [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Jon Mason @ 2016-11-01 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161029081839.GA32579@lunn.ch>
On Sat, Oct 29, 2016 at 10:18:39AM +0200, Andrew Lunn wrote:
> On Fri, Oct 28, 2016 at 04:56:55PM -0400, Jon Mason wrote:
> > The BCM54810 PHY requires some semi-unique configuration, which results
> > in some additional configuration in addition to the standard config.
> > Also, some users of the BCM54810 require the PHY lanes to be swapped.
> > Since there is no way to detect this, add a device tree query to see if
> > it is applicable.
> >
> > Inspired-by: Vikas Soni <vsoni@broadcom.com>
> > Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> > ---
> > drivers/net/phy/Kconfig | 2 +-
> > drivers/net/phy/broadcom.c | 58 +++++++++++++++++++++++++++++++++++++++++++++-
> > include/linux/brcmphy.h | 10 ++++++++
>
> Hi Jon
>
> The binding documentation is missing.
>
> > + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap")) {
> > + /* Lane Swap - Undocumented register...magic! */
> > + ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
> > + 0x11B);
> > + if (ret < 0)
> > + return ret;
> > + }
> > +
>
> I wounder if this property could be made generic? What exactly are you
> swapping? Rx and Tx lanes? Maybe we should add it to phy.txt?
Are you envisioning adding a DT check (similar to the
of_property_read_bool above, only with a more generic string) in
phy_device_create(), which will then set a PHY device flag? This flag
would then be checked for in the PHY driver and the appropriate action
taken (in this case the bcm_phy_write_exp above).
If so, I cam completely fine doing this. I think the only caveat
would be that this would be creating a generic interface for only 1
user. If you envision this being used by others, then disregard my
concern.
Thanks,
Jon
>
> Andrew
^ permalink raw reply
* [PATCH net-next 0/2] drivers: net: xgene: Fix coalescing bugs
From: David Miller @ 2016-11-01 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477954827-9951-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Mon, 31 Oct 2016 16:00:25 -0700
> This patch set fixes the following,
>
> 1. Since ethernet v1 hardware has a bug related to coalescing,
> disabling this feature
> 2. Fixing ethernet v2 hardware, interrupt trigger region
> id to 2, to kickoff coalescing
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Series applied, thanks.
^ permalink raw reply
* [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Eric Anholt @ 2016-11-01 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <529927781.27121.38a9c7fa-bdf8-4732-ac8b-cf15c21e3ce8.open-xchange@email.1und1.de>
Stefan Wahren <stefan.wahren@i2se.com> writes:
>> Eric Anholt <eric@anholt.net> hat am 31. Oktober 2016 um 18:53 geschrieben:
>>
>>
>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>
>> > Hi Eric,
>> >
>> >> Eric Anholt <eric@anholt.net> hat am 27. Oktober 2016 um 18:52 geschrieben:
>> >>
>> >>
>> >> From: Linus Walleij <linus.walleij@linaro.org>
>> >>
>> >> The idea is to give useful names to GPIO lines that an implementer
>> >> will be using from userspace, e.g. for maker type projects. These are
>> >> user-visible using tools/gpio/lsgpio.c
>> >
>> > sorry for the late feedback, but did you check your patch against the
>> > Firmware
>> > DTS [1]?
>> >
>> > As an example the GPIO38 is connected and named as USB_LIMIT_1A2 since
>> > Raspberry
>> > Pi 1 B Plus.
>> >
>> > [1] -
>> > https://github.com/raspberrypi/documentation/blob/master/configuration/images/dt-blob.dts
>>
>> I did use the dt-blob sometimes for cross-checking, but these are
>> written against the schematics, not the dt-blob. If you've got things
>> you'd like changed, could you send a patch?
>
> A patch against your v3 or my own v4 based on your patch?
A followon patch is great, then the changes are obvious and we can
either squash or commit as appropriate.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161101/e9cfffda/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-11-01 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101155950.GA19378@broadcom.com>
> > > + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap")) {
> > > + /* Lane Swap - Undocumented register...magic! */
> > > + ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
> > > + 0x11B);
> > > + if (ret < 0)
> > > + return ret;
> > > + }
> > > +
> >
> > I wounder if this property could be made generic? What exactly are you
> > swapping? Rx and Tx lanes? Maybe we should add it to phy.txt?
>
> Are you envisioning adding a DT check (similar to the
> of_property_read_bool above, only with a more generic string) in
> phy_device_create(), which will then set a PHY device flag? This flag
> would then be checked for in the PHY driver and the appropriate action
> taken (in this case the bcm_phy_write_exp above).
I would keep the parsing of the property in the driver. But if we
think other PHYs could also support this feature, it would be good to
avoid having "brcm,enet-phy-lane-swap", "marvell,enet-phy-lane-swap",
"davicom,enet-phy-lane-swap", etc. It would be better to have one well
defined property documented in phy.txt which any PHY is free to
implement.
Andrew
^ permalink raw reply
* [PATCH v6 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-01 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018160414.1228-5-lorenzo.pieralisi@arm.com>
Bikeshed alert...
On 18/10/16 17:04, Lorenzo Pieralisi wrote:
> The of_iommu_{set/get}_ops() API is used to associate a device
> tree node with a specific set of IOMMU operations. The same
> kernel interface is required on systems booting with ACPI, where
> devices are not associated with a device tree node, therefore
> the interface requires generalization.
>
> The struct device fwnode member represents the fwnode token
> associated with the device and the struct it points at is firmware
> specific; regardless, it is initialized on both ACPI and DT systems
> and makes an ideal candidate to use it to associate a set of IOMMU
> operations to a given device, through its struct device.fwnode member
> pointer.
>
> Convert the DT specific of_iommu_{set/get}_ops() interface to
> use struct device.fwnode as a look-up token, making the interface
> usable on ACPI systems.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/iommu/iommu.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/of_iommu.c | 39 ---------------------------------------
> include/linux/iommu.h | 14 ++++++++++++++
> include/linux/of_iommu.h | 12 ++++++++++--
> 4 files changed, 67 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 9a2f196..320eb8c 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1615,6 +1615,49 @@ int iommu_request_dm_for_dev(struct device *dev)
> return ret;
> }
>
> +struct fwnode_iommu_node {
Having just pulled in this patch in isolation for some hacking, I
realise that by about the fifth time one reads "fwnode_iommu_node" it
just looks like meaningless gibberish. Can we just call it
"iommu_instance" instead, as that's what it's representing here?
> + struct list_head list;
> + struct fwnode_handle *fwnode;
> + const struct iommu_ops *ops;
> +};
> +static LIST_HEAD(fwnode_iommu_list);
> +static DEFINE_SPINLOCK(fwnode_iommu_lock);
> +
> +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops)
> +{
> + struct fwnode_iommu_node *iommu =
> + kzalloc(sizeof(*iommu), GFP_KERNEL);
(plus it shortens this line so it really doesn't the awkward break)
Apologies, (the original rubbish name was my fault anyway)
Robin.
> +
> + if (WARN_ON(!iommu))
> + return;
> +
> + if (is_of_node(fwnode))
> + of_node_get(to_of_node(fwnode));
> +
> + INIT_LIST_HEAD(&iommu->list);
> + iommu->fwnode = fwnode;
> + iommu->ops = ops;
> + spin_lock(&fwnode_iommu_lock);
> + list_add_tail(&iommu->list, &fwnode_iommu_list);
> + spin_unlock(&fwnode_iommu_lock);
> +}
> +
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> +{
> + struct fwnode_iommu_node *node;
> + const struct iommu_ops *ops = NULL;
> +
> + spin_lock(&fwnode_iommu_lock);
> + list_for_each_entry(node, &fwnode_iommu_list, list)
> + if (node->fwnode == fwnode) {
> + ops = node->ops;
> + break;
> + }
> + spin_unlock(&fwnode_iommu_lock);
> + return ops;
> +}
> +
> int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> const struct iommu_ops *ops)
> {
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 5b82862..0f57ddc 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -96,45 +96,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> }
> EXPORT_SYMBOL_GPL(of_get_dma_window);
>
> -struct of_iommu_node {
> - struct list_head list;
> - struct device_node *np;
> - const struct iommu_ops *ops;
> -};
> -static LIST_HEAD(of_iommu_list);
> -static DEFINE_SPINLOCK(of_iommu_lock);
> -
> -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops)
> -{
> - struct of_iommu_node *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> -
> - if (WARN_ON(!iommu))
> - return;
> -
> - of_node_get(np);
> - INIT_LIST_HEAD(&iommu->list);
> - iommu->np = np;
> - iommu->ops = ops;
> - spin_lock(&of_iommu_lock);
> - list_add_tail(&iommu->list, &of_iommu_list);
> - spin_unlock(&of_iommu_lock);
> -}
> -
> -const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> -{
> - struct of_iommu_node *node;
> - const struct iommu_ops *ops = NULL;
> -
> - spin_lock(&of_iommu_lock);
> - list_for_each_entry(node, &of_iommu_list, list)
> - if (node->np == np) {
> - ops = node->ops;
> - break;
> - }
> - spin_unlock(&of_iommu_lock);
> - return ops;
> -}
> -
> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> {
> struct of_phandle_args *iommu_spec = data;
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 436dc21..15d5478 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -351,6 +351,9 @@ int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> const struct iommu_ops *ops);
> void iommu_fwspec_free(struct device *dev);
> int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops);
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode);
>
> #else /* CONFIG_IOMMU_API */
>
> @@ -580,6 +583,17 @@ static inline int iommu_fwspec_add_ids(struct device *dev, u32 *ids,
> return -ENODEV;
> }
>
> +static inline void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops)
> +{
> +}
> +
> +static inline
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> +{
> + return NULL;
> +}
> +
> #endif /* CONFIG_IOMMU_API */
>
> #endif /* __LINUX_IOMMU_H */
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index e80b9c7..7681007 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -31,8 +31,16 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>
> #endif /* CONFIG_OF_IOMMU */
>
> -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops);
> -const struct iommu_ops *of_iommu_get_ops(struct device_node *np);
> +static inline void of_iommu_set_ops(struct device_node *np,
> + const struct iommu_ops *ops)
> +{
> + fwnode_iommu_set_ops(&np->fwnode, ops);
> +}
> +
> +static inline const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> +{
> + return fwnode_iommu_get_ops(&np->fwnode);
> +}
>
> extern struct of_device_id __iommu_of_table;
>
>
^ permalink raw reply
* [PATCH v2 0/2] mmc: sdhci-iproc: Add byte register access support
From: Scott Branden @ 2016-11-01 16:37 UTC (permalink / raw)
To: linux-arm-kernel
Add brcm,sdhci-iproc compat string and code for support of newer versions of
sdhci-iproc controller that allow byte-wise register accesses.
Changes from v1:
- added details to bindings documentation to clarify usage of brcm,sdhci-iproc
compatibility string
Scott Branden (2):
mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings
document
mmc: sdhci-iproc: support standard byte register accesses
.../devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 9 ++++++
drivers/mmc/host/sdhci-iproc.c | 35 ++++++++++++++++++++--
2 files changed, 42 insertions(+), 2 deletions(-)
--
2.5.0
^ permalink raw reply
* [PATCH v2 1/2] mmc: sdhci-iproc: Add brcm, sdhci-iproc compat string in bindings document
From: Scott Branden @ 2016-11-01 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478018277-10097-1-git-send-email-scott.branden@broadcom.com>
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(+)
diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
index be56d2b..954561d 100644
--- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
+++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
@@ -7,6 +7,15 @@ Required properties:
- compatible : Should be one of the following
"brcm,bcm2835-sdhci"
"brcm,sdhci-iproc-cygnus"
+ "brcm,sdhci-iproc"
+
+Use brcm2835-sdhci for Rasperry PI.
+
+Use sdhci-iproc-cygnus for Broadcom SDHCI Controllers
+restricted to 32bit host accesses to SDHCI registers.
+
+Use sdhci-iproc for Broadcom SDHCI Controllers that allow standard
+8, 16, 32-bit host access to SDHCI register.
- clocks : The clock feeding the SDHCI controller.
--
2.5.0
^ permalink raw reply related
* [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Scott Branden @ 2016-11-01 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478018277-10097-1-git-send-email-scott.branden@broadcom.com>
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>
---
drivers/mmc/host/sdhci-iproc.c | 35 +++++++++++++++++++++++++++++++++--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index 7262466..d7046d6 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -143,6 +143,14 @@ static void sdhci_iproc_writeb(struct sdhci_host *host, u8 val, int reg)
}
static const struct sdhci_ops sdhci_iproc_ops = {
+ .set_clock = sdhci_set_clock,
+ .get_max_clock = sdhci_pltfm_clk_get_max_clock,
+ .set_bus_width = sdhci_set_bus_width,
+ .reset = sdhci_reset,
+ .set_uhs_signaling = sdhci_set_uhs_signaling,
+};
+
+static const struct sdhci_ops sdhci_iproc_32only_ops = {
.read_l = sdhci_iproc_readl,
.read_w = sdhci_iproc_readw,
.read_b = sdhci_iproc_readb,
@@ -156,6 +164,28 @@ static const struct sdhci_ops sdhci_iproc_ops = {
.set_uhs_signaling = sdhci_set_uhs_signaling,
};
+static const struct sdhci_pltfm_data sdhci_iproc_cygnus_pltfm_data = {
+ .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
+ .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
+ .ops = &sdhci_iproc_32only_ops,
+};
+
+static const struct sdhci_iproc_data iproc_cygnus_data = {
+ .pdata = &sdhci_iproc_cygnus_pltfm_data,
+ .caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
+ & SDHCI_MAX_BLOCK_MASK) |
+ SDHCI_CAN_VDD_330 |
+ SDHCI_CAN_VDD_180 |
+ SDHCI_CAN_DO_SUSPEND |
+ SDHCI_CAN_DO_HISPD |
+ SDHCI_CAN_DO_ADMA2 |
+ SDHCI_CAN_DO_SDMA,
+ .caps1 = SDHCI_DRIVER_TYPE_C |
+ SDHCI_DRIVER_TYPE_D |
+ SDHCI_SUPPORT_DDR50,
+ .mmc_caps = MMC_CAP_1_8V_DDR,
+};
+
static const struct sdhci_pltfm_data sdhci_iproc_pltfm_data = {
.quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
.quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
@@ -182,7 +212,7 @@ static const struct sdhci_pltfm_data sdhci_bcm2835_pltfm_data = {
.quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
SDHCI_QUIRK_MISSING_CAPS,
- .ops = &sdhci_iproc_ops,
+ .ops = &sdhci_iproc_32only_ops,
};
static const struct sdhci_iproc_data bcm2835_data = {
@@ -194,7 +224,8 @@ static const struct sdhci_iproc_data bcm2835_data = {
static const struct of_device_id sdhci_iproc_of_match[] = {
{ .compatible = "brcm,bcm2835-sdhci", .data = &bcm2835_data },
- { .compatible = "brcm,sdhci-iproc-cygnus", .data = &iproc_data },
+ { .compatible = "brcm,sdhci-iproc-cygnus", .data = &iproc_cygnus_data},
+ { .compatible = "brcm,sdhci-iproc", .data = &iproc_data },
{ }
};
MODULE_DEVICE_TABLE(of, sdhci_iproc_of_match);
--
2.5.0
^ permalink raw reply related
* [PATCH] staging: vc04_services: parse_rx_slots() - Fix compiler warning
From: Eric Anholt @ 2016-11-01 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101152114.19394-1-mzoran@crowfest.net>
Michael Zoran <mzoran@crowfest.net> writes:
> vc04_services contains a debug logging mechanism. The log is
> maintained in a shared memory area between the kernel and the
> firmware. Changing the sizes of the data in this area would
> require a firmware change which is distributed independently
> from the kernel binary.
>
> One of the items logged is the address of received messages.
> This address is a pointer, but the debugging slot used to store
> the information is a 32 bit integer.
>
> Luckily, this value is never interpreted by anything other
> then debug tools and it is expected that a human debugging
> the kernel interpret it.
>
> This change adds a cast to long before the original cast
> to int to silence the warning.
>
> Signed-off-by: Michael Zoran <mzoran@crowfest.net>
Thanks for sorting this out.
Reviewed-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161101/ee842ff3/attachment.sig>
^ permalink raw reply
* [PATCH v2] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Marc Zyngier @ 2016-11-01 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101090408.GA13677@cbox>
[messed up my initial reply, resending]
On Tue, Nov 01 2016 at 09:04:08 AM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Fri, Oct 28, 2016 at 11:27:50AM +0100, Marc Zyngier wrote:
>> Architecturally, TLBs are private to the (physical) CPU they're
>> associated with. But when multiple vcpus from the same VM are
>> being multiplexed on the same CPU, the TLBs are not private
>> to the vcpus (and are actually shared across the VMID).
>>
>> Let's consider the following scenario:
>>
>> - vcpu-0 maps PA to VA
>> - vcpu-1 maps PA' to VA
>>
>> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
>> by vcpu-0 accesses, and access the wrong physical page.
>>
>> The solution to this is to keep a per-VM map of which vcpu ran last
>> on each given physical CPU, and invalidate local TLBs when switching
>> to a different vcpu from the same VM.
>>
>> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> Fixed comments, added Mark's RB.
>>
>> arch/arm/include/asm/kvm_host.h | 11 ++++++++++-
>> arch/arm/include/asm/kvm_hyp.h | 1 +
>> arch/arm/kvm/arm.c | 35 ++++++++++++++++++++++++++++++++++-
>> arch/arm/kvm/hyp/switch.c | 9 +++++++++
>> arch/arm64/include/asm/kvm_host.h | 11 ++++++++++-
>> arch/arm64/kvm/hyp/switch.c | 8 ++++++++
>> 6 files changed, 72 insertions(+), 3 deletions(-)
>>
[...]
>> @@ -310,6 +322,27 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
>> return 0;
>> }
>>
>> +void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu)
>> +{
>
> why is calling this from here sufficient?
>
> You only get a notification from preempt notifiers if you were preempted
> while running (or rather while the vcpu was loaded). I think this
> needs
Arghh. I completely miss-read the code when writing that patch.
> to go in kvm_arch_vcpu_load, but be aware that the vcpu_load gets called
> for other vcpu ioctls and doesn't necessarily imply that the vcpu will
> actually run, which is also the case for the sched_in notification, btw.
> The worst that will happen in that case is a bit of extra TLB
> invalidation, so sticking with kvm_arch_vcpu_load is probably fine.
Indeed. I don't mind the extra invalidation, as long as it is rare
enough. Another possibility would be to do this test on the entry path,
once preemption is disabled.
>
>> + int *last_ran;
>> +
>> + last_ran = per_cpu_ptr(vcpu->kvm->arch.last_vcpu_ran, cpu);
>> +
>> + /*
>> + * We might get preempted before the vCPU actually runs, but
>> + * this is fine. Our TLBI stays pending until we actually make
>> + * it to __activate_vm, so we won't miss a TLBI. If another
>> + * vCPU gets scheduled, it will see our vcpu_id in last_ran,
>> + * and pend a TLBI for itself.
>> + */
>> + if (*last_ran != vcpu->vcpu_id) {
>> + if (*last_ran != -1)
>> + vcpu->arch.tlb_vmid_stale = true;
>> +
>> + *last_ran = vcpu->vcpu_id;
>> + }
>> +}
>> +
>> void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>> {
>> vcpu->cpu = cpu;
>> diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
>> index 92678b7..a411762 100644
>> --- a/arch/arm/kvm/hyp/switch.c
>> +++ b/arch/arm/kvm/hyp/switch.c
>> @@ -75,6 +75,15 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
>> {
>> struct kvm *kvm = kern_hyp_va(vcpu->kvm);
>> write_sysreg(kvm->arch.vttbr, VTTBR);
>> + if (vcpu->arch.tlb_vmid_stale) {
>> + /* Force vttbr to be written */
>> + isb();
>> + /* Local invalidate only for this VMID */
>> + write_sysreg(0, TLBIALL);
>> + dsb(nsh);
>> + vcpu->arch.tlb_vmid_stale = false;
>> + }
>> +
>
> why not call this directly when you notice it via kvm_call_hyp as
> opposed to adding another conditional in the critical path?
Because the cost of a hypercall is very likely to be a lot higher than
that of testing a variable. Not to mention that at this point we're
absolutely sure that we're going to run the guest, while the hook in
vcpu_load is only probabilistic.
Thanks,
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply
* [PATCH 1/2] mmc: sdhci-iproc: Add brcm, sdhci-iproc compat string in bindings document
From: Scott Branden @ 2016-11-01 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <93502f42-ae86-742f-a8b1-3645005fa98e@broadcom.com>
Hi Rob,
On 16-10-18 01:08 PM, Scott Branden wrote:
> Hi Rob,
>
> On 16-10-18 06:16 AM, Rob Herring wrote:
>> On Wed, Oct 12, 2016 at 11:35:51AM -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 | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
>>> b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
>>> index be56d2b..aa58b94 100644
>>> --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
>>> @@ -7,6 +7,7 @@ Required properties:
>>> - compatible : Should be one of the following
>>> "brcm,bcm2835-sdhci"
>>> "brcm,sdhci-iproc-cygnus"
>>> + "brcm,sdhci-iproc"
>>
>> Seems kind of generic. SoC specific compatible strings please.
>>
> The compatibility string is generic on purpose as it is not intended to
> be SoC specific but work on all new iproc SoCs that have the proper
> fixes in place for this block (unlike bcm2835 and cygnus class devices
> which can only do 32-bit accesses). I could call it brcm,sdhci-iproc-v2
> if that is better or leave it as is. Please let me know your preferences.
>
I just sent out v2 of the patch with additional details in the device
tree bindings document. Please let me know if this covers your
concerns. The SDHCI controller binding is not SoC specific and is used
in multiple SoCs going forward with the same binding.
> Regards,
> Scott
^ permalink raw reply
* [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Jon Mason @ 2016-11-01 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101162648.GG10785@lunn.ch>
On Tue, Nov 01, 2016 at 05:26:48PM +0100, Andrew Lunn wrote:
> > > > + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap")) {
> > > > + /* Lane Swap - Undocumented register...magic! */
> > > > + ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
> > > > + 0x11B);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > + }
> > > > +
> > >
> > > I wounder if this property could be made generic? What exactly are you
> > > swapping? Rx and Tx lanes? Maybe we should add it to phy.txt?
> >
> > Are you envisioning adding a DT check (similar to the
> > of_property_read_bool above, only with a more generic string) in
> > phy_device_create(), which will then set a PHY device flag? This flag
> > would then be checked for in the PHY driver and the appropriate action
> > taken (in this case the bcm_phy_write_exp above).
>
> I would keep the parsing of the property in the driver. But if we
> think other PHYs could also support this feature, it would be good to
> avoid having "brcm,enet-phy-lane-swap", "marvell,enet-phy-lane-swap",
> "davicom,enet-phy-lane-swap", etc. It would be better to have one well
> defined property documented in phy.txt which any PHY is free to
> implement.
Okay, I understand what you are saying now. I will assume that if
nothing exists today aside from this Broadcom errata, something in the
future will happen. So, I agree that making it generic is a good idea.
I'll make the generic string be "enet-phy-lane-swap" (without the
previous "brcm"), and add the flag to phy.txt to document it.
Thanks,
Jon
>
> Andrew
^ permalink raw reply
* [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-11-01 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101164337.GA19654@broadcom.com>
> I'll make the generic string be "enet-phy-lane-swap" (without the
> previous "brcm"), and add the flag to phy.txt to document it.
Great.
Please be quite verbose as to what it means.
Thanks
Andrew
^ 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