* [PATCH v2 1/2] dt-bindings: Document the hi3660 clock bindings
From: Rob Herring @ 2017-01-03 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482978805-6981-2-git-send-email-zhangfei.gao@linaro.org>
On Thu, Dec 29, 2016 at 10:33:24AM +0800, Zhangfei Gao wrote:
> Add DT bindings documentation for hi3660 SoC clock.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> ---
> .../devicetree/bindings/clock/hi3660-clock.txt | 42 ++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/hi3660-clock.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] coresight: fix kernel panic caused by invalid CPU
From: Mathieu Poirier @ 2017-01-03 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161226063137.110016-1-wangnan0@huawei.com>
On 25 December 2016 at 23:31, Wang Nan <wangnan0@huawei.com> wrote:
> Commit d52c9750f150 ("coresight: reset 'enable_sink' flag when need be")
> caused a kernel panic because of the using of an invalid value: after
> 'for_each_cpu(cpu, mask)', value of local variable 'cpu' become invalid,
> causes following 'cpu_to_node' access invalid memory area.
>
> This patch brings the deleted 'cpu = cpumask_first(mask)' back.
>
> Panic log:
>
> $ perf record -e cs_etm// ls
>
> Unable to handle kernel paging request at virtual address fffe801804af4f10
> pgd = ffff8017ce031600
> [fffe801804af4f10] *pgd=0000000000000000, *pud=0000000000000000
> Internal error: Oops: 96000004 [#1] SMP
> Modules linked in:
> CPU: 33 PID: 1619 Comm: perf Not tainted 4.7.1+ #16
> Hardware name: Huawei Taishan 2280 /CH05TEVBA, BIOS 1.10 11/24/2016
> task: ffff8017cb0c8400 ti: ffff8017cb154000 task.ti: ffff8017cb154000
> PC is at tmc_alloc_etf_buffer+0x60/0xd4
> LR is at tmc_alloc_etf_buffer+0x44/0xd4
> pc : [<ffff000008633df8>] lr : [<ffff000008633ddc>] pstate: 60000145
> sp : ffff8017cb157b40
> x29: ffff8017cb157b40 x28: 0000000000000000
> ...skip...
> 7a60: ffff000008c64dc8 0000000000000006 0000000000000253 ffffffffffffffff
> 7a80: 0000000000000000 0000000000000000 ffff0000080872cc 0000000000000001
> [<ffff000008633df8>] tmc_alloc_etf_buffer+0x60/0xd4
> [<ffff000008632b9c>] etm_setup_aux+0x1dc/0x1e8
> [<ffff00000816eed4>] rb_alloc_aux+0x2b0/0x338
> [<ffff00000816a5e4>] perf_mmap+0x414/0x568
> [<ffff0000081ab694>] mmap_region+0x324/0x544
> [<ffff0000081abbe8>] do_mmap+0x334/0x3e0
> [<ffff000008191150>] vm_mmap_pgoff+0xa4/0xc8
> [<ffff0000081a9a30>] SyS_mmap_pgoff+0xb0/0x22c
> [<ffff0000080872e4>] sys_mmap+0x18/0x28
> [<ffff0000080843f0>] el0_svc_naked+0x24/0x28
> Code: 912040a5 d0001c00 f873d821 911c6000 (b8656822)
> ---[ end trace 98933da8f92b0c9a ]---
>
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> Cc: Xia Kaixu <xiakaixu@huawei.com>
> Cc: Li Zefan <lizefan@huawei.com>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
> drivers/hwtracing/coresight/coresight-etm-perf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 1774196..26cfac3 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -242,6 +242,7 @@ static void *etm_setup_aux(int event_cpu, void **pages,
> if (!sink_ops(sink)->alloc_buffer)
> goto err;
>
> + cpu = cpumask_first(mask);
> /* Get the AUX specific data from the sink buffer */
> event_data->snk_config =
> sink_ops(sink)->alloc_buffer(sink, cpu, pages,
> --
> 2.10.1
>
Applied - thanks.
^ permalink raw reply
* [PATCH 2/4] ARM: dts: Add am335x-boneblack-wireless
From: Jason Kridner @ 2017-01-03 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103201103.GB25222@atomide.com>
> On Jan 3, 2017, at 3:11 PM, Tony Lindgren <tony@atomide.com> wrote:
>
> * Jason Kridner <jkridner@gmail.com> [161228 13:27]:
>>
>>
>>> On Dec 27, 2016, at 11:58 AM, Robert Nelson <robertcnelson@gmail.com> wrote:
>>>
>>> BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with the Ethernet
>>> replaced by a TI wl1835 wireless module.
>>>
>>> This board can be indentified by the BWAx value after A335BNLT (BBB) in the at24 eeprom:
>>> BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
>>
>> I believe the correct statement is BWxx, but BWBx reserves the option to be software incompatible in some way. My preference is to have it boot anyway, but I believe that is only dependent in the bootloader.
>
> So does this patch need updating for that?
No, it is bootloader controlled.
>
> Regards,
>
> Tony
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
From: Christopher Spinrath @ 2017-01-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <27256207f2d84b1ca4b7dfc41a413fcc@rwthex-s2-a.rwth-ad.de>
Hi Shawn,
thanks for the review!
On 12/30/2016 03:27 PM, Shawn Guo wrote:
> On Fri, Dec 02, 2016 at 03:37:22PM +0100, christopher.spinrath at rwth-aachen.de wrote:
>> From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>>
>> Apart from the already enabled Designware HDMI port, the Utilite Pro
>> has a second display pipeline which has the following shape:
>>
>> IPU1 DI0 --> Parallel display --> tfp410 rgb24 to DVI encoder
>> --> HDMI connector.
>> Enable support for it.
>>
>> In addition, since this pipeline is hardwired to IPU1, sever the link
>> between IPU1 and the SoC-internal Designware HDMI encoder forcing the
>> latter to be connected to IPU2 instead of IPU1. Otherwise, it is not
>> possible to drive both displays at high resolution due to the bandwidth
>> limitations of a single IPU.
>>
>> Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>
> @Philipp, can you help review the changes?
>
>> ---
>>
>> Hi all,
>>
>> the removal of the link between IPU1 and the Designware HDMI encoder is the
>> result of a discussion I had with Philipp Zabel:
>>
>> https://lists.freedesktop.org/archives/dri-devel/2016-November/125399.html .
>>
>> Altough it is not possible to connect anything else to IPU1 on the Utilite, this
>> approach has at least one disadvantage: if the resolution is low enough such
>> that a single IPU can handle both displays then muxing both displays to IPU1
>> would reduce the power consumption.
>>
>> However, IMHO omitting the link IPU1 <--> DW HDMI is still the preferrable
>> solution since I'm not aware of any OS/driver that is capable of switching IPUs
>> or can handle the bandwidth limitation in a sane way. In particular, Linux is
>> unusable when both displays are supposed to be driven at high resolution and
>> both muxing options for the DW HDMI are available (this is not a userspace
>> issue; the system becomes almost unresponsive as soon as the kernel sets the
>> initial resolution).
>>
>> Cheers,
>> Christopher
>>
>> P.S.: this patch depends on the tfp410 bridge driver which has recently been
>> merged into drm-next.
>
> v4.10-rc1 has the driver, so the dependency is gone now, I guess.
That's correct.
>>
>> arch/arm/boot/dts/imx6q-utilite-pro.dts | 115 ++++++++++++++++++++++++++++++++
>> 1 file changed, 115 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> index 2200994..69bdd82 100644
>> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> @@ -59,6 +59,33 @@
>> rtc1 = &snvs_rtc;
>> };
>>
>> + encoder {
>> + compatible = "ti,tfp410";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port at 0 {
>> + reg = <0>;
>> +
>> + tfp410_in: endpoint {
>> + remote-endpoint = <¶llel_display_out>;
>> + };
>> + };
>> +
>> + port at 1 {
>> + reg = <1>;
>> +
>> + tfp410_out: endpoint {
>> + remote-endpoint = <&hdmi_connector_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> gpio-keys {
>> compatible = "gpio-keys";
>> pinctrl-names = "default";
>> @@ -72,6 +99,19 @@
>> };
>> };
>>
>> + hdmi-connector {
>> + compatible = "hdmi-connector";
>> +
>
> The newline is unnecessary.
>
>> + type = "a";
>> + ddc-i2c-bus = <&i2c_dvi_ddc>;
>> +
>> + port {
>> + hdmi_connector_in: endpoint {
>> + remote-endpoint = <&tfp410_out>;
>> + };
>> + };
>> + };
>> +
>> i2cmux {
>> compatible = "i2c-mux-gpio";
>> pinctrl-names = "default";
>> @@ -105,8 +145,46 @@
>> #size-cells = <0>;
>> };
>> };
>> +
>> + parallel-display {
>> + compatible = "fsl,imx-parallel-display";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_ipu1>;
>> +
>
> Ditto
>
> I can fix them up if I get a Reviewed-by tag from Philipp on this
> version.
Thanks. I'll bear that in mind for future patches (and, of course, I
will fix them up myself if I have to send a v2).
Cheers,
Christopher
> Shawn
>
>> + interface-pix-fmt = "rgb24";
>> +
>> + port at 0 {
>> + reg = <0>;
>> +
>> + parallel_display_in: endpoint {
>> + remote-endpoint = <&ipu1_di0_disp0>;
>> + };
>> + };
>> +
>> + port at 1 {
>> + reg = <1>;
>> +
>> + parallel_display_out: endpoint {
>> + remote-endpoint = <&tfp410_in>;
>> + };
>> + };
>> + };
>> };
>>
>> +/*
>> + * A single IPU is not able to drive both display interfaces available on the
>> + * Utilite Pro at high resolution due to its bandwidth limitation. Since the
>> + * tfp410 encoder is wired up to IPU1, sever the link between IPU1 and the
>> + * SoC-internal Designware HDMI encoder forcing the latter to be connected to
>> + * IPU2 instead of IPU1.
>> + */
>> +/delete-node/&ipu1_di0_hdmi;
>> +/delete-node/&hdmi_mux_0;
>> +/delete-node/&ipu1_di1_hdmi;
>> +/delete-node/&hdmi_mux_1;
>> +
>> &hdmi {
>> ddc-i2c-bus = <&i2c2>;
>> status = "okay";
>> @@ -151,6 +229,39 @@
>> >;
>> };
>>
>> + pinctrl_ipu1: ipu1grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x38
>> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x38
>> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x38
>> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x38
>> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x38
>> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x38
>> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x38
>> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x38
>> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x38
>> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x38
>> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x38
>> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x38
>> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x38
>> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x38
>> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x38
>> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x38
>> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x38
>> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x38
>> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x38
>> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x38
>> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x38
>> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x38
>> + MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x38
>> + MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x38
>> + MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x38
>> + MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x38
>> + MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x38
>> + MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x38
>> + >;
>> + };
>> +
>> pinctrl_uart2: uart2grp {
>> fsl,pins = <
>> MX6QDL_PAD_GPIO_7__UART2_TX_DATA 0x1b0b1
>> @@ -194,6 +305,10 @@
>> };
>> };
>>
>> +&ipu1_di0_disp0 {
>> + remote-endpoint = <¶llel_display_in>;
>> +};
>> +
>> &pcie {
>> pcie at 0,0 {
>> reg = <0x000000 0 0 0 0>;
>> --
>> 2.10.2
>>
^ permalink raw reply
* [PATCH 1/2] mmc: sdhci-iproc: Apply caps from bcm2835-mmc driver
From: Stefan Wahren @ 2017-01-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lgusngn7.fsf@eliezer.anholt.net>
Hi Eric,
> Eric Anholt <eric@anholt.net> hat am 3. Januar 2017 um 19:27 geschrieben:
>
>
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
> > Since the mmc module on bcm2835 neither provide a capabilities register nor
> > free documentation we must rely on the downstream implementation [1].
>
> Yeah, caps reg is wired to 0, but it can do high speed.
>
> Since we're VDD_330 only, I'm not sure the driver type flags do
> anything, but I'm still good with having consistency.
yes, the driver type flags currently have no benefit.
>
> Reviewed-by: Eric Anholt <eric@anholt.net>
>
> Interested in porting over the DMA support? :)
AFAIK the sdhci doesn't support external DMA (required for bcm2835).
So DMA support would result in a new driver, which i'm currently not interested.
But i've prepared a fixup patch series for the sdhost driver i want to send to Gerd.
>
> I also noticed that the emmc wrapper module claims it can run with a
> clock from 50-100mhz, and the arasan says it can run at up to 50, 52, or
> 208mhz depending on SD/MMC mode. Could we get a boost from running the
> module at a higher clock rate?
Sorry, i can't follow. Do you mean DDR mode?
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Nikita Yushchenko @ 2017-01-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9382563b-44ab-47a8-14d0-1fdaf49f8c5d@ti.com>
>>>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>>>> index 290a84f..49645277 100644
>>>> --- a/arch/arm64/mm/dma-mapping.c
>>>> +++ b/arch/arm64/mm/dma-mapping.c
>>>> @@ -28,6 +28,7 @@
>>>> #include <linux/dma-contiguous.h>
>>>> #include <linux/vmalloc.h>
>>>> #include <linux/swiotlb.h>
>>>> +#include <linux/pci.h>
>>>>
>>>> #include <asm/cacheflush.h>
>>>>
>>>> @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
>>>>
>>>> static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
>>>> {
>>>> +#ifdef CONFIG_PCI
>>>> + if (dev_is_pci(hwdev)) {
>>>> + struct pci_dev *pdev = to_pci_dev(hwdev);
>>>> + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus);
>>>> +
>>>> + if (br->dev.dma_mask && (*br->dev.dma_mask) &&
>>>> + (mask & (*br->dev.dma_mask)) != mask)
>>>> + return 0;
>>>> + }
>>>> +#endif
>>>
>>> Hmm, but this makes it look like the problem is both arm64 and swiotlb
>>> specific, when in reality it's not. Perhaps another hack you could try
>>> would be to register a PCI bus notifier in the host bridge looking for
>>> BUS_NOTIFY_BIND_DRIVER, then you could proxy the DMA ops for each child
>>> device before the driver has probed, but adding a dma_set_mask callback
>>> to limit the mask to what you need?
>>
>> This is what Renesas BSP tries to do and it does not work.
>>
>> BUS_NOTIFY_BIND_DRIVER arrives after driver's probe routine exits, but
>> i/o can be started before that.
>
> Hm. This is strange statement:
> really_probe
> |->driver_sysfs_add
> |-> blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
> BUS_NOTIFY_BIND_DRIVER, dev);
> ...
> |- ret = drv->probe(dev);
> ...
> |- driver_bound(dev);
> |- blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
> BUS_NOTIFY_BOUND_DRIVER, dev);
>
> Am I missing smth?
I misinterpreted your message, sorry.
BSP attaches to BUS_NOTIFY_BOUND_DRIVER, not to BUS_NOTIFY_BIND_DRIVER,
and simply overwrites device's dma_mask there. You are suggesting
something completely different.
I'll check if your approach is practical.
Currently powerpc architecture has one more approach implemented, they
use pci_controller structure provided by host bridge driver, and that
has a set_dma_mask() hook. Maybe extending this beyond powerpc could be
a good idea. However, that will require changing quite a few host bridge
drivers, without any gain for most of those...
^ permalink raw reply
* [PATCHv2 net-next 01/16] dt-bindings: net: update Marvell PPv2 binding for PPv2.2 support
From: Rob Herring @ 2017-01-03 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943592-12556-2-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:17PM +0100, Thomas Petazzoni wrote:
> The Marvell PPv2 Device Tree binding was so far only used to describe
> the PPv2.1 network controller, used in the Marvell Armada 375.
>
> A new version of this IP block, PPv2.2 is used in the Marvell Armada
> 7K/8K processor. This commit extends the existing binding so that it can
> also be used to describe PPv2.2 hardware.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> .../devicetree/bindings/net/marvell-pp2.txt | 66 ++++++++++++++++++----
> 1 file changed, 55 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt b/Documentation/devicetree/bindings/net/marvell-pp2.txt
> index aa4f423..76071f3 100644
> --- a/Documentation/devicetree/bindings/net/marvell-pp2.txt
> +++ b/Documentation/devicetree/bindings/net/marvell-pp2.txt
> @@ -1,17 +1,28 @@
> -* Marvell Armada 375 Ethernet Controller (PPv2)
> +* Marvell Armada 375 Ethernet Controller (PPv2.1)
> + Marvell Armada 7K/8K Ethernet Controller (PPv2.2)
>
> Required properties:
>
> -- compatible: should be "marvell,armada-375-pp2"
> +- compatible: should be one of:
> + "marvell,armada-375-pp2"
> + "marvell,armada-7k-pp2"
> - reg: addresses and length of the register sets for the device.
> - Must contain the following register sets:
> + For "marvell,armada-375-pp2", must contain the following register
> + sets:
> - common controller registers
> - LMS registers
> - In addition, at least one port register set is required.
> -- clocks: a pointer to the reference clocks for this device, consequently:
> - - main controller clock
> - - GOP clock
> -- clock-names: names of used clocks, must be "pp_clk" and "gop_clk".
> + - one register area per Ethernet port
> + For "marvell,armda-7k-pp2", must contain the following register
> + sets:
> + - common controller registers
> + - per-port registers
> +
> +- clocks: pointers to the reference clocks for this device, consequently:
> + - main controller clock (for both armada-375-pp2 and armada-7k-pp2)
> + - GOP clock (for both armada-375-pp2 and armada-7k-pp2)
> + - MG clock (only for armada-7k-pp2)
> +- clock-names: names of used clocks, must be "pp_clk", "gop_clk" and
> + "mg_clk" (the latter only for armada-7k-pp2).
>
> The ethernet ports are represented by subnodes. At least one port is
> required.
> @@ -19,8 +30,9 @@ required.
> Required properties (port):
>
> - interrupts: interrupt for the port
> -- port-id: should be '0' or '1' for ethernet ports, and '2' for the
> - loopback port
> +- port-id: ID of the port from the MAC point of view
> +- gop-port-id: only for marvell,armada-7k-pp2, ID of the port from the
> + GOP (Group Of Ports) point of view
What GOP is needs a better explanation. Why doesn't 375 need this?
> - phy-mode: See ethernet.txt file in the same directory
>
> Optional properties (port):
> @@ -31,7 +43,7 @@ Optional properties (port):
> then fixed link is assumed, and the 'fixed-link' property is
> mandatory.
>
> -Example:
> +Example for marvell,armada-375-pp2:
>
> ethernet at f0000 {
> compatible = "marvell,armada-375-pp2";
> @@ -59,3 +71,35 @@ ethernet at f0000 {
> phy-mode = "gmii";
> };
> };
> +
> +Example for marvell,armada-7k-pp2:
> +
> +cpm_ethernet: ethernet at 0 {
> + compatible = "marvell,armada-7k-pp22";
> + reg = <0x0 0x100000>,
> + <0x100000 0x80000>;
> + clocks = <&cpm_syscon0 1 3>, <&cpm_syscon0 1 9>, <&cpm_syscon0 1 5>;
> + clock-names = "pp_clk", "gop_clk", "gp_clk";
> + status = "disabled";
Drop status from examples.
> +
> + eth0: eth at 0 {
unit address requires a reg property. Or this can be 'eth0' instead.
> + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
> + port-id = <0>;
> + gop-port-id = <0>;
> + status = "disabled";
> + };
> +
> + eth1: eth at 1 {
> + interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
> + port-id = <1>;
> + gop-port-id = <2>;
> + status = "disabled";
> + };
> +
> + eth2: eth at 2 {
> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> + port-id = <2>;
> + gop-port-id = <3>;
> + status = "disabled";
> + };
> +};
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Grygorii Strashko @ 2017-01-03 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ead2ff8d-fbd3-3109-51e2-41937e9c944d@cogentembedded.com>
On 01/03/2017 01:01 PM, Nikita Yushchenko wrote:
>>> It is possible that PCI device supports 64-bit DMA addressing, and thus
>>> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host
>>> bridge has limitations on inbound transactions addressing. Example of
>>> such setup is NVME SSD device connected to RCAR PCIe controller.
>>>
>>> Previously there was attempt to handle this via bus notifier: after
>>> driver is attached to PCI device, bridge driver gets notifier callback,
>>> and resets dma_mask from there. However, this is racy: PCI device driver
>>> could already allocate buffers and/or start i/o in probe routine.
>>> In NVME case, i/o is started in workqueue context, and this race gives
>>> "sometimes works, sometimes not" effect.
>>>
>>> Proper solution should make driver's dma_set_mask() call to fail if host
>>> bridge can't support mask being set.
>>>
>>> This patch makes __swiotlb_dma_supported() to check mask being set for
>>> PCI device against dma_mask of struct device corresponding to PCI host
>>> bridge (one with name "pciXXXX:YY"), if that dma_mask is set.
>>>
>>> This is the least destructive approach: currently dma_mask of that device
>>> object is not used anyhow, thus all existing setups will work as before,
>>> and modification is required only in actually affected components -
>>> driver of particular PCI host bridge, and dma_map_ops of particular
>>> platform.
>>>
>>> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
>>> ---
>>> arch/arm64/mm/dma-mapping.c | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>>> index 290a84f..49645277 100644
>>> --- a/arch/arm64/mm/dma-mapping.c
>>> +++ b/arch/arm64/mm/dma-mapping.c
>>> @@ -28,6 +28,7 @@
>>> #include <linux/dma-contiguous.h>
>>> #include <linux/vmalloc.h>
>>> #include <linux/swiotlb.h>
>>> +#include <linux/pci.h>
>>>
>>> #include <asm/cacheflush.h>
>>>
>>> @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
>>>
>>> static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
>>> {
>>> +#ifdef CONFIG_PCI
>>> + if (dev_is_pci(hwdev)) {
>>> + struct pci_dev *pdev = to_pci_dev(hwdev);
>>> + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus);
>>> +
>>> + if (br->dev.dma_mask && (*br->dev.dma_mask) &&
>>> + (mask & (*br->dev.dma_mask)) != mask)
>>> + return 0;
>>> + }
>>> +#endif
>>
>> Hmm, but this makes it look like the problem is both arm64 and swiotlb
>> specific, when in reality it's not. Perhaps another hack you could try
>> would be to register a PCI bus notifier in the host bridge looking for
>> BUS_NOTIFY_BIND_DRIVER, then you could proxy the DMA ops for each child
>> device before the driver has probed, but adding a dma_set_mask callback
>> to limit the mask to what you need?
>
> This is what Renesas BSP tries to do and it does not work.
>
> BUS_NOTIFY_BIND_DRIVER arrives after driver's probe routine exits, but
> i/o can be started before that.
Hm. This is strange statement:
really_probe
|->driver_sysfs_add
|-> blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
BUS_NOTIFY_BIND_DRIVER, dev);
...
|- ret = drv->probe(dev);
...
|- driver_bound(dev);
|- blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
BUS_NOTIFY_BOUND_DRIVER, dev);
Am I missing smth?
--
regards,
-grygorii
^ permalink raw reply
* [PATCH 2/4] ARM: dts: Add am335x-boneblack-wireless
From: Tony Lindgren @ 2017-01-03 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CB5C8999-6CAE-41F6-85A6-D2A856BD8011@gmail.com>
* Jason Kridner <jkridner@gmail.com> [161228 13:27]:
>
>
> > On Dec 27, 2016, at 11:58 AM, Robert Nelson <robertcnelson@gmail.com> wrote:
> >
> > BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with the Ethernet
> > replaced by a TI wl1835 wireless module.
> >
> > This board can be indentified by the BWAx value after A335BNLT (BBB) in the at24 eeprom:
> > BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
>
> I believe the correct statement is BWxx, but BWBx reserves the option to be software incompatible in some way. My preference is to have it boot anyway, but I believe that is only dependent in the bootloader.
So does this patch need updating for that?
Regards,
Tony
^ permalink raw reply
* [PATCH v3] ARM: dts: turris-omnia: add support for ethernet switch
From: Andrew Lunn @ 2017-01-03 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103193501.4827-1-uwe@kleine-koenig.org>
On Tue, Jan 03, 2017 at 08:35:01PM +0100, Uwe Kleine-K?nig wrote:
> The Turris Omnia features a Marvell MV88E6176 ethernet switch. Add it to
> the dts.
>
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 0/6] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11
From: Ard Biesheuvel @ 2017-01-03 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483381268-12987-1-git-send-email-ard.biesheuvel@linaro.org>
On 2 January 2017 at 18:21, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> This series adds SIMD implementations for arm64 and ARM of ChaCha20 (*),
> and a port of the ARM bit-sliced AES algorithm to arm64, and
>
> Patch #1 is a prerequisite for the AES-XTS implementation in #6, which needs
> a secondary AES transform to generate the initial tweak.
>
Herbert,
I actually have a scalar AES implementation for arm64 which I could
use instead, making this patch unnecessary.
I could respin the entire series, or you could simply disregard #1 and
#6 for now, whichever you prefer.
Thanks,
Ard.
> Patch #2 optimizes the bit-sliced AES glue code for ARM to iterate over the
> input in the most efficient manner possible.
>
> Patch #3 adds a NEON implementation of ChaCha20 for ARM.
>
> Patch #4 adds a NEON implementation of ChaCha20 for arm64.
>
> Patch #5 modifies the existing NEON and ARMv8 Crypto Extensions implementations
> of AES-CTR to be available as a synchronous skcipher as well. This is intended
> for the mac80211 code, which uses synchronous encapsulations of ctr(aes)
> [ccm, gcm] in softirq context, which supports SIMD algorithms on arm64.
>
> Patch #6 adds a port of the ARM bit-sliced AES code to arm64, in ECB, CTR
> and XTS modes.
>
> Ard Biesheuvel (6):
> crypto: generic/aes - export encrypt and decrypt entry points
> crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
> crypto: arm/chacha20 - implement NEON version based on SSE3 code
> crypto: arm64/chacha20 - implement NEON version based on SSE3 code
> crypto: arm64/aes-blk - expose AES-CTR as synchronous cipher as well
> crypto: arm64/aes - reimplement bit-sliced ARM/NEON implementation for
> arm64
>
> arch/arm/crypto/Kconfig | 6 +
> arch/arm/crypto/Makefile | 2 +
> arch/arm/crypto/aesbs-glue.c | 67 +-
> arch/arm/crypto/chacha20-neon-core.S | 524 ++++++++++++
> arch/arm/crypto/chacha20-neon-glue.c | 128 +++
> arch/arm64/crypto/Kconfig | 13 +
> arch/arm64/crypto/Makefile | 6 +
> arch/arm64/crypto/aes-glue.c | 25 +-
> arch/arm64/crypto/aes-neonbs-core.S | 879 ++++++++++++++++++++
> arch/arm64/crypto/aes-neonbs-glue.c | 344 ++++++++
> arch/arm64/crypto/chacha20-neon-core.S | 450 ++++++++++
> arch/arm64/crypto/chacha20-neon-glue.c | 127 +++
> crypto/aes_generic.c | 10 +-
> include/crypto/aes.h | 3 +
> 14 files changed, 2549 insertions(+), 35 deletions(-)
> create mode 100644 arch/arm/crypto/chacha20-neon-core.S
> create mode 100644 arch/arm/crypto/chacha20-neon-glue.c
> create mode 100644 arch/arm64/crypto/aes-neonbs-core.S
> create mode 100644 arch/arm64/crypto/aes-neonbs-glue.c
> create mode 100644 arch/arm64/crypto/chacha20-neon-core.S
> create mode 100644 arch/arm64/crypto/chacha20-neon-glue.c
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v3] ARM: dts: turris-omnia: add support for ethernet switch
From: Uwe Kleine-König @ 2017-01-03 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103152107.GA32450@lunn.ch>
The Turris Omnia features a Marvell MV88E6176 ethernet switch. Add it to
the dts.
Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
---
Changes since (implicit) v1:
- drop mdio bus and per port phy-handle as they match the default
setup.
Changes since v2:
- Fix switch type in comment and commit log
- drop 2nd cpu port
arch/arm/boot/dts/armada-385-turris-omnia.dts | 58 +++++++++++++++++++++++++--
1 file changed, 55 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
index ab49acb2d452..28eede180e4f 100644
--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -122,7 +122,7 @@
pinctrl-names = "default";
pinctrl-0 = <&ge0_rgmii_pins>;
status = "okay";
- phy-mode = "rgmii-id";
+ phy-mode = "rgmii";
fixed-link {
speed = <1000>;
@@ -135,7 +135,7 @@
pinctrl-names = "default";
pinctrl-0 = <&ge1_rgmii_pins>;
status = "okay";
- phy-mode = "rgmii-id";
+ phy-mode = "rgmii";
fixed-link {
speed = <1000>;
@@ -273,7 +273,59 @@
/* irq is connected to &pcawan pin 7 */
};
- /* Switch MV88E7176 at address 0x10 */
+ /* Switch MV88E6176 at address 0x10 */
+ switch at 10 {
+ compatible = "marvell,mv88e6085";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dsa,member = <0 0>;
+
+ reg = <0x10>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports at 0 {
+ reg = <0>;
+ label = "lan0";
+ };
+
+ ports at 1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ ports at 2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ ports at 3 {
+ reg = <3>;
+ label = "lan3";
+ };
+
+ ports at 4 {
+ reg = <4>;
+ label = "lan4";
+ };
+
+ ports at 5 {
+ reg = <5>;
+ label = "cpu";
+ ethernet = <ð1>;
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ /* port 6 is connected to eth0 */
+ };
+ };
};
&pinctrl {
--
2.11.0
^ permalink raw reply related
* [PATCH] cpufreq: s3c64xx: remove incorrect __init annotation
From: Krzysztof Kozlowski @ 2017-01-03 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0jaKnn+LTTdpgxaFLNaYSuqV8d9PKphOnHrPw0Zp_Uj5w@mail.gmail.com>
On Mon, Jan 02, 2017 at 10:19:29PM +0100, Rafael J. Wysocki wrote:
> On Mon, Jan 2, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Mon, Jan 02, 2017 at 12:39:03PM +0530, Viresh Kumar wrote:
> >> On 16-12-16, 10:06, Arnd Bergmann wrote:
> >> > s3c64xx_cpufreq_config_regulator is incorrectly annotated
> >> > as __init, since the caller is also not init:
> >> >
> >> > WARNING: vmlinux.o(.text+0x92fe1c): Section mismatch in reference from the function s3c64xx_cpufreq_driver_init() to the function .init.text:s3c64xx_cpufreq_config_regulator()
> >> >
> >> > With modern gcc versions, the function gets inline, so we don't
> >> > see the warning, this only happens with gcc-4.6 and older.
> >> >
> >> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> > ---
> >> > drivers/cpufreq/s3c64xx-cpufreq.c | 2 +-
> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c
> >> > index 176e84cc3991..0cb9040eca49 100644
> >> > --- a/drivers/cpufreq/s3c64xx-cpufreq.c
> >> > +++ b/drivers/cpufreq/s3c64xx-cpufreq.c
> >> > @@ -107,7 +107,7 @@ static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy,
> >> > }
> >> >
> >> > #ifdef CONFIG_REGULATOR
> >> > -static void __init s3c64xx_cpufreq_config_regulator(void)
> >> > +static void s3c64xx_cpufreq_config_regulator(void)
> >> > {
> >> > int count, v, i, found;
> >> > struct cpufreq_frequency_table *freq;
> >>
> >> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > Rafael,
> > Are you going to pick it up?
>
> I thought I did, didn't I?
Right, you did. I missed that. Thanks!
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: dts: imx53-qsb: Provide the TVE DAC regulators
From: Fabio Estevam @ 2017-01-03 19:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
On imx53-qsb the TVE DAC regulator comes from:
- LDO7 on the board with the Dialog DA9052 PMIC
- VDAC on the board with the MC34708 PMIC
Pass them in the 'dac-supply' node.
While at it, remove the 'regulator-always-on/regulator-boot-on'
properties as the TVE driver will properly handle it.
Tested on a imx53-qsb board with a Dialog DA9052 PMIC.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx53-qsb.dts | 5 ++++-
arch/arm/boot/dts/imx53-qsrb.dts | 6 ++++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index 3799396..f4c158c 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -90,7 +90,6 @@
ldo7_reg: ldo7 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3600000>;
- regulator-always-on;
};
ldo8_reg: ldo8 {
@@ -113,3 +112,7 @@
};
};
};
+
+&tve {
+ dac-supply = <&ldo7_reg>;
+};
diff --git a/arch/arm/boot/dts/imx53-qsrb.dts b/arch/arm/boot/dts/imx53-qsrb.dts
index 96d7eed..479ca4c 100644
--- a/arch/arm/boot/dts/imx53-qsrb.dts
+++ b/arch/arm/boot/dts/imx53-qsrb.dts
@@ -130,8 +130,6 @@
regulator-name = "VDAC";
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <2775000>;
- regulator-boot-on;
- regulator-always-on;
};
vgen1_reg: vgen1 {
@@ -152,3 +150,7 @@
};
};
};
+
+&tve {
+ dac-supply = <&vdac_reg>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Nikita Yushchenko @ 2017-01-03 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103184444.GP6986@arm.com>
>> It is possible that PCI device supports 64-bit DMA addressing, and thus
>> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host
>> bridge has limitations on inbound transactions addressing. Example of
>> such setup is NVME SSD device connected to RCAR PCIe controller.
>>
>> Previously there was attempt to handle this via bus notifier: after
>> driver is attached to PCI device, bridge driver gets notifier callback,
>> and resets dma_mask from there. However, this is racy: PCI device driver
>> could already allocate buffers and/or start i/o in probe routine.
>> In NVME case, i/o is started in workqueue context, and this race gives
>> "sometimes works, sometimes not" effect.
>>
>> Proper solution should make driver's dma_set_mask() call to fail if host
>> bridge can't support mask being set.
>>
>> This patch makes __swiotlb_dma_supported() to check mask being set for
>> PCI device against dma_mask of struct device corresponding to PCI host
>> bridge (one with name "pciXXXX:YY"), if that dma_mask is set.
>>
>> This is the least destructive approach: currently dma_mask of that device
>> object is not used anyhow, thus all existing setups will work as before,
>> and modification is required only in actually affected components -
>> driver of particular PCI host bridge, and dma_map_ops of particular
>> platform.
>>
>> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
>> ---
>> arch/arm64/mm/dma-mapping.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index 290a84f..49645277 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -28,6 +28,7 @@
>> #include <linux/dma-contiguous.h>
>> #include <linux/vmalloc.h>
>> #include <linux/swiotlb.h>
>> +#include <linux/pci.h>
>>
>> #include <asm/cacheflush.h>
>>
>> @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
>>
>> static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
>> {
>> +#ifdef CONFIG_PCI
>> + if (dev_is_pci(hwdev)) {
>> + struct pci_dev *pdev = to_pci_dev(hwdev);
>> + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus);
>> +
>> + if (br->dev.dma_mask && (*br->dev.dma_mask) &&
>> + (mask & (*br->dev.dma_mask)) != mask)
>> + return 0;
>> + }
>> +#endif
>
> Hmm, but this makes it look like the problem is both arm64 and swiotlb
> specific, when in reality it's not. Perhaps another hack you could try
> would be to register a PCI bus notifier in the host bridge looking for
> BUS_NOTIFY_BIND_DRIVER, then you could proxy the DMA ops for each child
> device before the driver has probed, but adding a dma_set_mask callback
> to limit the mask to what you need?
This is what Renesas BSP tries to do and it does not work.
BUS_NOTIFY_BIND_DRIVER arrives after driver's probe routine exits, but
i/o can be started before that.
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Nikita Yushchenko @ 2017-01-03 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103184444.GP6986@arm.com>
03.01.2017 21:44, Will Deacon ?????:
> On Thu, Dec 29, 2016 at 11:45:03PM +0300, Nikita Yushchenko wrote:
>> It is possible that PCI device supports 64-bit DMA addressing, and thus
>> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host
>> bridge has limitations on inbound transactions addressing. Example of
>> such setup is NVME SSD device connected to RCAR PCIe controller.
>>
>> Previously there was attempt to handle this via bus notifier: after
>> driver is attached to PCI device, bridge driver gets notifier callback,
>> and resets dma_mask from there. However, this is racy: PCI device driver
>> could already allocate buffers and/or start i/o in probe routine.
>> In NVME case, i/o is started in workqueue context, and this race gives
>> "sometimes works, sometimes not" effect.
>>
>> Proper solution should make driver's dma_set_mask() call to fail if host
>> bridge can't support mask being set.
>>
>> This patch makes __swiotlb_dma_supported() to check mask being set for
>> PCI device against dma_mask of struct device corresponding to PCI host
>> bridge (one with name "pciXXXX:YY"), if that dma_mask is set.
>>
>> This is the least destructive approach: currently dma_mask of that device
>> object is not used anyhow, thus all existing setups will work as before,
>> and modification is required only in actually affected components -
>> driver of particular PCI host bridge, and dma_map_ops of particular
>> platform.
>>
>> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
>> ---
>> arch/arm64/mm/dma-mapping.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index 290a84f..49645277 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -28,6 +28,7 @@
>> #include <linux/dma-contiguous.h>
>> #include <linux/vmalloc.h>
>> #include <linux/swiotlb.h>
>> +#include <linux/pci.h>
>>
>> #include <asm/cacheflush.h>
>>
>> @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
>>
>> static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
>> {
>> +#ifdef CONFIG_PCI
>> + if (dev_is_pci(hwdev)) {
>> + struct pci_dev *pdev = to_pci_dev(hwdev);
>> + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus);
>> +
>> + if (br->dev.dma_mask && (*br->dev.dma_mask) &&
>> + (mask & (*br->dev.dma_mask)) != mask)
>> + return 0;
>> + }
>> +#endif
>
> Hmm, but this makes it look like the problem is both arm64 and swiotlb
> specific, when in reality it's not. Perhaps another hack you could try
> would be to register a PCI bus notifier in the host bridge looking for
> BUS_NOTIFY_BIND_DRIVER, then you could proxy the DMA ops for each child
> device before the driver has probed, but adding a dma_set_mask callback
> to limit the mask to what you need?
This is what Renesas BSP tries to do and it does not work.
BUS_NOTIFY_BIND_DRIVER arrives after driver's probe routine exits, but
i/o can be started before that.
^ permalink raw reply
* [PATCH 2/4] input: tm2-touchkey: Add touchkey driver support for TM2
From: Dmitry Torokhov @ 2017-01-03 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7794c9b2-48e6-1451-9a3e-fe24410a145d@osg.samsung.com>
On Tue, Jan 03, 2017 at 10:11:39AM -0300, Javier Martinez Canillas wrote:
> Hello Jaechul,
>
> On 01/03/2017 04:57 AM, Jaechul Lee wrote:
> > This patch adds support for the TM2 touch key and led
> > functionlity.
> >
>
> s/functionlity/functionality
>
> > The driver interfaces with userspace through an input device and
> > reports KEY_PHONE and KEY_BACK event types. LED brightness can be
> > controlled by "/sys/class/leds/tm2-touchkey/brightness".
> >
> > Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> > Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> > ---
> > drivers/input/keyboard/Kconfig | 11 ++
> > drivers/input/keyboard/Makefile | 1 +
> > drivers/input/keyboard/tm2-touchkey.c | 326 ++++++++++++++++++++++++++++++++++
> > 3 files changed, 338 insertions(+)
> > create mode 100644 drivers/input/keyboard/tm2-touchkey.c
> >
> > diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> > index cbd75cf..72c0ba1 100644
> > --- a/drivers/input/keyboard/Kconfig
> > +++ b/drivers/input/keyboard/Kconfig
> > @@ -666,6 +666,17 @@ config KEYBOARD_TC3589X
> > To compile this driver as a module, choose M here: the
> > module will be called tc3589x-keypad.
> >
> > +config KEYBOARD_TM2_TOUCHKEY
> > + tristate "tm2-touchkey support"
> > + depends on I2C
There should be LED dependency as well.
> > + help
> > + Say Y here to enable the tm2-touchkey.
> > + touchkey driver for tm2. This driver can enable
> > + the interrupt and make input events and control led brightness.
> > +
> > + To compile this driver as a module, choose M here.
> > + module will be called tm2-touchkey
> > +
> > config KEYBOARD_TWL4030
> > tristate "TI TWL4030/TWL5030/TPS659x0 keypad support"
> > depends on TWL4030_CORE
> > diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> > index d9f4cfc..7d9acff 100644
> > --- a/drivers/input/keyboard/Makefile
> > +++ b/drivers/input/keyboard/Makefile
> > @@ -61,6 +61,7 @@ obj-$(CONFIG_KEYBOARD_SUN4I_LRADC) += sun4i-lradc-keys.o
> > obj-$(CONFIG_KEYBOARD_SUNKBD) += sunkbd.o
> > obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
> > obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
> > +obj-$(CONFIG_KEYBOARD_TM2_TOUCHKEY) += tm2-touchkey.o
> > obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
> > obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
> > obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
> > diff --git a/drivers/input/keyboard/tm2-touchkey.c b/drivers/input/keyboard/tm2-touchkey.c
> > new file mode 100644
> > index 0000000..d9575d8
> > --- /dev/null
> > +++ b/drivers/input/keyboard/tm2-touchkey.c
> > @@ -0,0 +1,326 @@
> > +/*
> > + * Driver for keys on GPIO lines capable of generating interrupts.
This does not match what the driver does.
> > + *
> > + * Copyright 2005 Phil Blundell
> > + * Copyright 2016 Samsung Electronics Co., Ltd.
> > + *
> > + * Author: Beomho Seo <beomho.seo@samsung.com>
> > + * Author: Jaechul Lee <jcsing.lee@samsung.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/bitops.h>
> > +#include <linux/delay.h>
> > +#include <linux/device.h>
> > +#include <linux/i2c.h>
> > +#include <linux/input.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irq.h>
> > +#include <linux/leds.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/pm.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/workqueue.h>
> > +
> > +#define TM2_TOUCHKEY_DEV_NAME "tm2-touchkey"
> > +#define TM2_TOUCHKEY_KEYCODE_REG 0x03
> > +#define TM2_TOUCHKEY_BASE_REG 0x00
> > +#define TM2_TOUCHKEY_CMD_LED_ON 0x10
> > +#define TM2_TOUCHKEY_CMD_LED_OFF 0x20
> > +#define TM2_TOUCHKEY_BIT_PRESS_EV BIT(3)
> > +#define TM2_TOUCHKEY_BIT_KEYCODE GENMASK(2, 0)
> > +#define TM2_TOUCHKEY_LED_VOLTAGE_MIN 2500000
> > +#define TM2_TOUCHKEY_LED_VOLTAGE_MAX 3300000
> > +
> > +enum {
> > + TM2_TOUCHKEY_KEY_MENU = 0x1,
> > + TM2_TOUCHKEY_KEY_BACK,
> > +};
> > +
> > +#define tm2_touchkey_power_enable(x) __tm2_touchkey_power_onoff(x, 1)
> > +#define tm2_touchkey_power_disable(x) __tm2_touchkey_power_onoff(x, 0)
> > +
> > +struct tm2_touchkey_data {
> > + struct i2c_client *client;
> > + struct input_dev *input_dev;
> > + struct led_classdev led_dev;
> > +
> > + u8 keycode_type;
> > + u8 pressed;
> > + struct work_struct irq_work;
> > +
> > + bool power_onoff;
> > + struct regulator *regulator_vcc; /* 1.8V */
> > + struct regulator *regulator_vdd; /* 3.3V */
> > +};
> > +
> > +static void tm2_touchkey_led_brightness_set(struct led_classdev *led_dev,
> > + enum led_brightness brightness)
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey =
Just call it "touchkey", "samsung_touchkey" is too long for a local
variable.
> > + container_of(led_dev, struct tm2_touchkey_data, led_dev);
> > + u32 volt;
> > + u8 data;
> > +
> > + if (brightness == LED_OFF) {
> > + volt = TM2_TOUCHKEY_LED_VOLTAGE_MIN;
> > + data = TM2_TOUCHKEY_CMD_LED_OFF;
> > + } else {
> > + volt = TM2_TOUCHKEY_LED_VOLTAGE_MAX;
> > + data = TM2_TOUCHKEY_CMD_LED_ON;
> > + }
> > +
> > + regulator_set_voltage(samsung_touchkey->regulator_vdd, volt, volt);
> > + i2c_smbus_write_byte_data(samsung_touchkey->client,
> > + TM2_TOUCHKEY_BASE_REG, data);
> > +}
> > +
> > +static int __tm2_touchkey_power_onoff(struct tm2_touchkey_data
> > + *samsung_touchkey, bool onoff)
> > +{
> > + int ret = 0;
> > +
> > + if (samsung_touchkey->power_onoff == onoff)
> > + return ret;
> > +
> > + if (onoff) {
> > + ret = regulator_enable(samsung_touchkey->regulator_vcc);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regulator_enable(samsung_touchkey->regulator_vdd);
> > + if (ret) {
> > + regulator_disable(samsung_touchkey->regulator_vcc);
> > + return ret;
> > + }
>
> I would add a comment about the sleep here.
Also "bulk" regulator API can be useful here.
>
> > + msleep(150);
> > + } else {
> > + int err;
> > +
> > + err = regulator_disable(samsung_touchkey->regulator_vcc);
> > + if (err)
> > + ret = err;
> > +
> > + err = regulator_disable(samsung_touchkey->regulator_vdd);
> > + if (err && !ret)
> > + ret = err;
> > + }
> > + samsung_touchkey->power_onoff = onoff;
> > +
> > + return ret;
> > +}
> > +
> > +static void tm2_touchkey_irq_work(struct work_struct *irq_work)
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey =
> > + container_of(irq_work, struct tm2_touchkey_data, irq_work);
> > +
> > + if (!samsung_touchkey->pressed) {
> > + input_report_key(samsung_touchkey->input_dev, KEY_PHONE, 0);
> > + input_report_key(samsung_touchkey->input_dev, KEY_BACK, 0);
> > + } else {
> > + if (samsung_touchkey->keycode_type == TM2_TOUCHKEY_KEY_MENU)
> > + input_report_key(samsung_touchkey->input_dev,
> > + KEY_PHONE, 1);
> > + else
> > + input_report_key(samsung_touchkey->input_dev,
> > + KEY_BACK, 1);
> > + }
> > + input_sync(samsung_touchkey->input_dev);
> > +}
There is absolutely no reason for doing this in a work. Just call
input_report_key/input_sync from your threaded IRQ routine.
> > +
> > +static irqreturn_t tm2_touchkey_irq_handler(int irq, void *devid)
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey = devid;
> > + u32 data;
> > +
> > + data = i2c_smbus_read_byte_data(samsung_touchkey->client,
> > + TM2_TOUCHKEY_KEYCODE_REG);
> > +
> > + if (data < 0) {
> > + dev_err(&samsung_touchkey->client->dev, "Failed to read i2c data\n");
> > + return IRQ_HANDLED;
> > + }
> > +
> > + samsung_touchkey->keycode_type = data & TM2_TOUCHKEY_BIT_KEYCODE;
> > + samsung_touchkey->pressed = !(data & TM2_TOUCHKEY_BIT_PRESS_EV);
> > +
> > + if (samsung_touchkey->keycode_type != TM2_TOUCHKEY_KEY_MENU &&
> > + samsung_touchkey->keycode_type != TM2_TOUCHKEY_KEY_BACK)
>
> Shouldn't at least a debug message be printed here so the user can
> know that an error occurred and a correct keycode was not received?
>
> > + return IRQ_HANDLED;
> > +
> > + schedule_work(&samsung_touchkey->irq_work);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int tm2_touchkey_probe(struct i2c_client *client,
> > + const struct i2c_device_id *id)
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey;
> > + int ret;
> > +
> > + ret = i2c_check_functionality(client->adapter,
> > + I2C_FUNC_SMBUS_BYTE |
> > + I2C_FUNC_SMBUS_BYTE_DATA);
> > + if (!ret) {
> > + dev_err(&client->dev, "No I2C functionality found\n");
> > + return -ENODEV;
> > + }
> > +
> > + samsung_touchkey = devm_kzalloc(&client->dev,
> > + sizeof(struct tm2_touchkey_data), GFP_KERNEL);
sizeof(*touchkey)
> > +
> > + if (!samsung_touchkey) {
> > + dev_err(&client->dev, "Failed to allocate memory.\n");
> > + return -ENOMEM;
> > + }
> > +
> > + samsung_touchkey->client = client;
> > + i2c_set_clientdata(client, samsung_touchkey);
> > + INIT_WORK(&samsung_touchkey->irq_work, tm2_touchkey_irq_work);
Work is not needed.
> > +
> > + /* regulator */
> > + samsung_touchkey->regulator_vcc =
> > + devm_regulator_get(&client->dev, "vcc");
> > + if (IS_ERR(samsung_touchkey->regulator_vcc)) {
> > + dev_err(&client->dev, "Failed to get vcc regulator\n");
> > + return PTR_ERR(samsung_touchkey->regulator_vcc);
> > + }
> > +
> > + samsung_touchkey->regulator_vdd =
> > + devm_regulator_get(&client->dev, "vdd");
> > + if (IS_ERR(samsung_touchkey->regulator_vdd)) {
> > + dev_err(&client->dev, "Failed to get vdd regulator\n");
> > + return PTR_ERR(samsung_touchkey->regulator_vcc);
> > + }
devm_regulator_bulk_get
> > +
> > + /* power */
> > + ret = tm2_touchkey_power_enable(samsung_touchkey);
> > + if (ret) {
> > + dev_err(&client->dev, "Failed to enable power\n");
> > + return ret;
> > + }
You need to install devm action (devm_add_action_or_reset) to disable
power when unloading driver (or if initialization fails).
> > +
> > + /* irq */
> > + ret = devm_request_threaded_irq(&client->dev,
> > + client->irq, NULL,
> > + tm2_touchkey_irq_handler,
> > + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
I'd rather we rely on IRQ trigger from DT, so just use IRQF_PNESHOT
here.
I'd rather you allocated input device before requesting IRQ. The
registering input device is fine to do after getting IRQ.
> > + TM2_TOUCHKEY_DEV_NAME,
> > + samsung_touchkey);
> > + if (ret) {
> > + dev_err(&client->dev, "Failed to request threaded irq\n");
> > + return ret;
> > + }
> > +
> > + /* input device */
> > + samsung_touchkey->input_dev = devm_input_allocate_device(&client->dev);
> > + if (!samsung_touchkey->input_dev) {
> > + dev_err(&client->dev, "Failed to alloc input device.\n");
> > + return -ENOMEM;
> > + }
> > + samsung_touchkey->input_dev->name = TM2_TOUCHKEY_DEV_NAME;
> > + samsung_touchkey->input_dev->id.bustype = BUS_I2C;
> > + samsung_touchkey->input_dev->dev.parent = &client->dev;
No need to set parent when using devm_input_allocate_device(), it is
done automatically.
> > +
> > + set_bit(EV_KEY, samsung_touchkey->input_dev->evbit);
> > + set_bit(KEY_PHONE, samsung_touchkey->input_dev->keybit);
> > + set_bit(KEY_BACK, samsung_touchkey->input_dev->keybit);
Just do
input_set_capability(touchkey->input_dev, EV_KEY, KEY_PHONE);
input_set_capability(touchkey->input_dev, EV_KEY, KEY_BACK);
> > + input_set_drvdata(samsung_touchkey->input_dev, samsung_touchkey);
> > +
> > + ret = input_register_device(samsung_touchkey->input_dev);
> > + if (ret) {
> > + dev_err(&client->dev, "Failed to register input device.\n");
> > + return ret;
> > + }
> > +
> > + /* led device */
> > + samsung_touchkey->led_dev.name = TM2_TOUCHKEY_DEV_NAME;
> > + samsung_touchkey->led_dev.brightness = LED_FULL;
> > + samsung_touchkey->led_dev.max_brightness = LED_FULL;
> > + samsung_touchkey->led_dev.brightness_set =
> > + tm2_touchkey_led_brightness_set;
> > +
> > + ret = devm_led_classdev_register(&client->dev,
> > + &samsung_touchkey->led_dev);
> > + if (ret < 0) {
> > + dev_err(&client->dev, "Failed to register touchkey led\n");
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void tm2_touchkey_shutdown(struct i2c_client *client)
> > +{
This is something not normally done. Does your platform really keep
rails on when AP is off?
> > + struct tm2_touchkey_data *samsung_touchkey =
> > + i2c_get_clientdata(client);
> > + int ret;
> > +
> > + disable_irq(client->irq);
> > + ret = tm2_touchkey_power_disable(samsung_touchkey);
> > + if (ret)
> > + dev_err(&client->dev, "Failed to disable power\n");
> > +}
> > +
> > +static int tm2_touchkey_suspend(struct device *dev)
__maybe_unused
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + disable_irq(samsung_touchkey->client->irq);
> > + ret = tm2_touchkey_power_disable(samsung_touchkey);
> > + if (ret)
> > + dev_err(dev, "Failed to disable power\n");
> > +
> > + return ret;
> > +}
>
> These two functions are basically the same, can you factor it out?
>
> > +
> > +static int tm2_touchkey_resume(struct device *dev)
__maybe_unused
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + enable_irq(samsung_touchkey->client->irq);
> > + ret = tm2_touchkey_power_enable(samsung_touchkey);
> > + if (ret)
> > + dev_err(dev, "Failed to enable power\n");
> > +
> > + return ret;
> > +}
> > +
> > +static SIMPLE_DEV_PM_OPS(tm2_touchkey_pm_ops, tm2_touchkey_suspend,
> > + tm2_touchkey_resume);
> > +
> > +static const struct i2c_device_id tm2_touchkey_id_table[] = {
> > + {TM2_TOUCHKEY_DEV_NAME, 0},
> > + {},
> > +};
> > +
>
> You need a MODULE_DEVICE_TABLE(i2c, tm2_touchkey_id_table) here so the
> module can be autoloaded when the device is registered.
>
> > +static const struct of_device_id tm2_touchkey_of_match[] = {
> > + {.compatible = "samsung,tm2-touchkey",},
> > + {},
> > +};
> > +
>
> Here a MODULE_DEVICE_TABLE(of, tm2_touchkey_of_match) is not strictly
> needed since the I2C core always reports MODALIAS of the form i2c:<dev>
> but still is good to have so the I2C core can be fixed at some point.
Yes, please add MODULE_DEVICE_TABLE(of, ...).
>
> > +static struct i2c_driver tm2_touchkey_driver = {
> > + .driver = {
> > + .name = TM2_TOUCHKEY_DEV_NAME,
> > + .pm = &tm2_touchkey_pm_ops,
> > + .of_match_table = of_match_ptr(tm2_touchkey_of_match),
> > + },
> > + .probe = tm2_touchkey_probe,
> > + .shutdown = tm2_touchkey_shutdown,
> > + .id_table = tm2_touchkey_id_table,
> > +};
> > +
> > +module_i2c_driver(tm2_touchkey_driver);
> > +
> > +MODULE_AUTHOR("Beomho Seo <beomho.seo@samsung.com>");
> > +MODULE_AUTHOR("Jaechul Lee <jcsing.lee@samsung.com>");
> > +MODULE_DESCRIPTION("Samsung touchkey driver");
> > +MODULE_LICENSE("GPL v2");
> >
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: enable Qualcomm RPMCC
From: Bjorn Andersson @ 2017-01-03 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483389305-8283-1-git-send-email-andy.gross@linaro.org>
On Mon 02 Jan 12:35 PST 2017, Andy Gross wrote:
> This patch enables the Qualcomm RPM based Clock Controller present on
> A-family boards.
>
> Signed-off-by: Andy Gross <andy.gross@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
> arch/arm/configs/multi_v7_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index b01a438..4ff6779 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -824,6 +824,7 @@ CONFIG_QCOM_SMSM=y
> CONFIG_QCOM_WCNSS_CTRL=m
> CONFIG_ROCKCHIP_PM_DOMAINS=y
> CONFIG_COMMON_CLK_QCOM=y
> +CONFIG_QCOM_CLK_RPM=y
> CONFIG_CHROME_PLATFORMS=y
> CONFIG_STAGING_BOARD=y
> CONFIG_CROS_EC_CHARDEV=m
> --
> 1.9.1
>
^ permalink raw reply
* [GIT PULL] drivers: firmware: PSCI fixes for v4.10
From: Lorenzo Pieralisi @ 2017-01-03 18:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC,
please consider pulling these minor PSCI fixes for v4.10.
Thank you very much.
Regards,
Lorenzo
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/psci-fixes-4.10
for you to fetch changes up to 32d53d1baf874caabe66ba565699ed5853fa2b6f:
MAINTAINERS: extend PSCI entry to cover the newly add PSCI checker code (2017-01-03 17:53:00 +0000)
----------------------------------------------------------------
PSCI fixes for v4.10
Two minor fixes following the merge of the PSCI checker:
- Annotate the PSCI checker timer on the stack used to wake-up from
suspend to prevent warnings when the DEBUG_OBJECTS config option
is enabled
- Extend the PSCI entry in the maintainers list to also include the
PSCI checker code
----------------------------------------------------------------
Sudeep Holla (2):
drivers: psci: annotate timer on stack to silence odebug messages
MAINTAINERS: extend PSCI entry to cover the newly add PSCI checker code
MAINTAINERS | 2 +-
drivers/firmware/psci_checker.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Will Deacon @ 2017-01-03 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com>
On Thu, Dec 29, 2016 at 11:45:03PM +0300, Nikita Yushchenko wrote:
> It is possible that PCI device supports 64-bit DMA addressing, and thus
> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host
> bridge has limitations on inbound transactions addressing. Example of
> such setup is NVME SSD device connected to RCAR PCIe controller.
>
> Previously there was attempt to handle this via bus notifier: after
> driver is attached to PCI device, bridge driver gets notifier callback,
> and resets dma_mask from there. However, this is racy: PCI device driver
> could already allocate buffers and/or start i/o in probe routine.
> In NVME case, i/o is started in workqueue context, and this race gives
> "sometimes works, sometimes not" effect.
>
> Proper solution should make driver's dma_set_mask() call to fail if host
> bridge can't support mask being set.
>
> This patch makes __swiotlb_dma_supported() to check mask being set for
> PCI device against dma_mask of struct device corresponding to PCI host
> bridge (one with name "pciXXXX:YY"), if that dma_mask is set.
>
> This is the least destructive approach: currently dma_mask of that device
> object is not used anyhow, thus all existing setups will work as before,
> and modification is required only in actually affected components -
> driver of particular PCI host bridge, and dma_map_ops of particular
> platform.
>
> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> ---
> arch/arm64/mm/dma-mapping.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 290a84f..49645277 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -28,6 +28,7 @@
> #include <linux/dma-contiguous.h>
> #include <linux/vmalloc.h>
> #include <linux/swiotlb.h>
> +#include <linux/pci.h>
>
> #include <asm/cacheflush.h>
>
> @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
>
> static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
> {
> +#ifdef CONFIG_PCI
> + if (dev_is_pci(hwdev)) {
> + struct pci_dev *pdev = to_pci_dev(hwdev);
> + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus);
> +
> + if (br->dev.dma_mask && (*br->dev.dma_mask) &&
> + (mask & (*br->dev.dma_mask)) != mask)
> + return 0;
> + }
> +#endif
Hmm, but this makes it look like the problem is both arm64 and swiotlb
specific, when in reality it's not. Perhaps another hack you could try
would be to register a PCI bus notifier in the host bridge looking for
BUS_NOTIFY_BIND_DRIVER, then you could proxy the DMA ops for each child
device before the driver has probed, but adding a dma_set_mask callback
to limit the mask to what you need?
I agree that it would be better if dma_set_mask handled all of this
transparently, but it's all based on the underlying ops rather than the
bus type.
Will
^ permalink raw reply
* [PATCH v3 1/3] power: reset: add linkstation-reset driver
From: Florian Fainelli @ 2017-01-03 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEQ9gE=MoQcr3eX0DAxZtvx0FW9pzgkUGjdxKHcsKwH7_+UsUw@mail.gmail.com>
On 01/03/2017 06:08 AM, Roger Shimizu wrote:
> Dear Florian, Andrew,
>
> Thanks for your email!
>
> On Tue, Jan 3, 2017 at 2:19 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> Interestingly, I submitted a patch doing nearly the same thing recently
>> after hacking on a Buffalo Terastation Pro II two days after yours
>> without seeing yours:
>>
>> https://lkml.org/lkml/2016/12/28/273
>
> Glad to know there's other developer working on linkstation/kurobox platform!
>
>> Some comments below.
>>
>>> +
>>> +static void __iomem *base;
>>> +static unsigned long tclk;
>>> +static const struct reset_cfg *cfg;
>>
>> How about avoiding the singletons here and pass this down from the
>> platform driver's private data after we (see below) also make use of a
>> reboot notifier?
>
> I see your patches. Indeed, it's a good idea to avoid the singletons
> and use private data instead.
>
>>> +static int linkstation_reset_probe(struct platform_device *pdev)
>>> +{
>>> + struct device_node *np = pdev->dev.of_node;
>>> + struct resource *res;
>>> + struct clk *clk;
>>> + char symname[KSYM_NAME_LEN];
>>> +
>>> + const struct of_device_id *match =
>>> + of_match_node(linkstation_reset_of_match_table, np);
>>> + cfg = match->data;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + if (!res) {
>>> + dev_err(&pdev->dev, "Missing resource");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
>>> + if (!base) {
>>> + dev_err(&pdev->dev, "Unable to map resource");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + /* We need to know tclk in order to calculate the UART divisor */
>>> + clk = devm_clk_get(&pdev->dev, NULL);
>>> + if (IS_ERR(clk)) {
>>> + dev_err(&pdev->dev, "Clk missing");
>>> + return PTR_ERR(clk);
>>> + }
>>> +
>>> + tclk = clk_get_rate(clk);
>>
>> Does this work with the Terastation II which has not been converted to
>> DT yet? Is tclk available through the CLK API there?
>
> I have no idea whether device-based legacy code and make use of power
> reset driver.
> Maybe Sebastian Reichel can offer a comment?
>
> However, I think Terastation II should convert to DT first.
> If you're willing to test, I can help to provide a dts/dtb.
> (If you use Debian, I can even provide DEB of kernel image and
> flash-kernel patch, which is easy for you to test)
>
> On Tue, Jan 3, 2017 at 10:09 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>>> +
>>>> + /* Check that nothing else has already setup a handler */
>>>> + if (pm_power_off) {
>>>> + lookup_symbol_name((ulong)pm_power_off, symname);
>>>> + dev_err(&pdev->dev,
>>>> + "pm_power_off already claimed %p %s",
>>>> + pm_power_off, symname);
>>>> + return -EBUSY;
>>>> + }
>>>> + pm_power_off = linkstation_reset;
>>>
>>> That seems a bit complicated, why not just assume that there will be
>>> either this driver used, or not at all?
>>
>> That is probably my fault. This is a copy from code i wrote many years
>> ago for the QNAP. I guess at the time i was battling with two
>> different pm_power_off handlers, so put in this code.
>>
>>> Also, you are supposed to register a reboot notifier to which you can
>>> pass private context:
>>
>> At the time i wrote the QNAP code, this did not exist. So maybe my
>> code is no longer a good example to copy.
>
> Really appreciated, Andrew!
> I'll modify this part in next series.
>
> BTW. the private data passing to reboot notifier can be shared to
> power-off function as well?
> Do you have example?
>
>> https://lkml.org/lkml/2016/12/28/275
>>
>> As indicated in my patch series, the UART1-attached micro controller
>> does a lot more things that just providing reboot, which is why I chose
>> to move this code to a MFD driver, as the starting point before adding
>> support for LEDs, FAN, PWM, beeper which would be other types of devices.
>>
>> Is adding support for other peripherals on your TODO as well?
>
> Except reset feature (power-off and reboot), other feature, such as
> LEDs / FAN speed / buttons, is managed by user-land program micro-evtd
> [0][1].
> Since the upstream [1] is not active anymore, Ryan Tandy (in CC) and I
> are maintaining it in Debian [0].
>
> [0] https://tracker.debian.org/pkg/micro-evtd
> [1] https://sourceforge.net/projects/ppc-evtd
>
> micro-evtd worked well for device-based legacy code, but after DT
> conversion, Ryan found the device cannot shutdown properly (reboot is
> OK).
> That why I created this patch series.
> I think for such old hardware and mature user-land program, it doesn't
> deserve the effort to implement those again in kernel side.
> What do you think?
An argument could be made that these are hardware peripherals, and so
the kernel is the best place to abstract support for that, and present
you with the standard device drive model for such kind of peripherals.
We don't have to do everything at the same time, so first things first,
get the reboot working, have me convert the Terastation over to Device
Tree and then we can decide what to do with these additional peripherals.
Thanks!
--
Florian
^ permalink raw reply
* coresight: Problem caused by resetting enable_sink
From: Mathieu Poirier @ 2017-01-03 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6598d4c2-bbfb-1792-d216-a15ab0e841e0@huawei.com>
On Mon, Dec 26, 2016 at 05:17:08PM +0800, Wangnan (F) wrote:
> Hi Mathieu,
Hello Wang,
>
> I meet problems caused by your commit d52c9750f150 ('coresight:
> reset "enable_sink" flag when need be'). Not only the one I
> posted in the previous patch.
>
> My use case is a simple 'perf record -e cs_etm// ls'. It works
> properly before this commit, and failed when allocating aux buffer
> after your commit. I can't fully understand your code, but the
> problem I meet seems caused by inappropriately reseting sink.
>
> My device is connected like this (use two etfs):
>
> Core0--+
> Core1--+-- funnel0 --> etf0
> Core2--|
> Core3--+
>
> Core0--+
> Core1--+-- funnel1 --> etf1
> Core2--|
> Core3--+
Yes, supporting this topology is a problem I long predicted.
>
> Before running perf, two etfs are activated using sysfs
> enable_sink interface.
>
> During etm_setup_aux, coresight_get_enabled_sink() finds
> etf0 for core0, and automatically deactivates it.
>
> For core1, coresight_get_enabled_sink() returns etf1.
> However, etf1 is not on the link of core1, so following
> coresight_build_path() fails.
>
> I guess your commit is based on the assumption that all
> sinks are in the patch for each cores. Like this:
>
>
> Core0--+
> Core1--+-- funnel0 --> etf0 ++
> Core2--| | +--- etr
> Core3--+ | |
> + replicator +
> Core0--+ | |
> Core1--+-- funnel1 --> etf1 ++ +--- etb
> Core2--|
> Core3--+
>
Correct - the entire solution is based on the assumption that all cores use the
same sink. When I wrote the driver not a single system enacted a topology where
cores wouldn't use the same sink for a trace session.
> But it is not true, at least for some hisilicon board.
>
> I have to revert your patch to make CoreSight on my board
> work. Please reconsider this patch, or please give some
> suggestion if you think I misunderstood your patch.
You understood the patch corretly but simply reverting it isn't the solution.
Supporting a system where different sinks are used won't be easy - a lot of
things need to be adjusted. The first and critical part that comes to mind is
the mechanic that fetches the sink definition from the cmd line when using the
perf interface (if I remember correctly the bison/flex parser can handle
multiple sink definition). From there everything needs to be tailored to handle
more than one sink.
You will likely have more questions... Get back to me and I'll be happy to help.
Regards,
Mathieu
>
> Thank you.
>
>
^ permalink raw reply
* [PATCH 0/6] staging: vchiq_arm: Fine-tuning for some function implementations
From: Greg Kroah-Hartman @ 2017-01-03 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r34kniic.fsf@eliezer.anholt.net>
On Tue, Jan 03, 2017 at 09:46:51AM -0800, Eric Anholt wrote:
> SF Markus Elfring <elfring@users.sourceforge.net> writes:
>
> > From: Markus Elfring <elfring@users.sourceforge.net>
> > Date: Sat, 31 Dec 2016 22:42:34 +0100
> >
> > Some update suggestions were taken into account
> > from static source code analysis.
>
> This series is:
>
> Reviewed-by: Eric Anholt <eric@anholt.net>
Nice, but I have a blacklist from this patch author, and have told them
numerous times that I no longer accept patches from them. If you think
they are worthy, please resend them with your reviewed-by on them, but I
will warn you, I've blacklisted them for a reason...
good luck!
greg k-h
^ permalink raw reply
* [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
From: Andy Lutomirski @ 2017-01-03 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3492795.xaneWtGxgW@wuerfel>
On Tue, Jan 3, 2017 at 5:18 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, January 2, 2017 10:08:28 PM CET Andy Lutomirski wrote:
>>
>> > This seems to nicely address the same problem on arm64, which has
>> > run into the same issue due to the various page table formats
>> > that can currently be chosen at compile time.
>>
>> On further reflection, I think this has very little to do with paging
>> formats except insofar as paging formats make us notice the problem.
>> The issue is that user code wants to be able to assume an upper limit
>> on an address, and it gets an upper limit right now that depends on
>> architecture due to paging formats. But someone really might want to
>> write a *portable* 64-bit program that allocates memory with the high
>> 16 bits clear. So let's add such a mechanism directly.
>>
>> As a thought experiment, what if x86_64 simply never allocated "high"
>> (above 2^47-1) addresses unless a new mmap-with-explicit-limit syscall
>> were used? Old glibc would continue working. Old VMs would work.
>> New programs that want to use ginormous mappings would have to use the
>> new syscall. This would be totally stateless and would have no issues
>> with CRIU.
>
> I can see this working well for the 47-bit addressing default, but
> what about applications that actually rely on 39-bit addressing
> (I'd have to double-check, but I think this was the limit that
> people were most interested in for arm64)?
>
> 39 bits seems a little small to make that the default for everyone
> who doesn't pass the extra flag. Having to pass another flag to
> limit the addresses introduces other problems (e.g. mmap from
> library call that doesn't pass that flag).
That's a fair point. Maybe my straw man isn't so good.
>
>> If necessary, we could also have a prctl that changes a
>> "personality-like" limit that is in effect when the old mmap was used.
>> I say "personality-like" because it would reset under exactly the same
>> conditions that personality resets itself.
>
> For "personality-like", it would still have to interact
> with the existing PER_LINUX32 and PER_LINUX32_3GB flags that
> do the exact same thing, so actually using personality might
> be better.
>
> We still have a few bits in the personality arguments, and
> we could combine them with the existing ADDR_LIMIT_3GB
> and ADDR_LIMIT_32BIT flags that are mutually exclusive by
> definition, such as
>
> ADDR_LIMIT_32BIT = 0x0800000, /* existing */
> ADDR_LIMIT_3GB = 0x8000000, /* existing */
> ADDR_LIMIT_39BIT = 0x0010000, /* next free bit */
> ADDR_LIMIT_42BIT = 0x8010000,
> ADDR_LIMIT_47BIT = 0x0810000,
> ADDR_LIMIT_48BIT = 0x8810000,
>
> This would probably take only one or two personality bits for the
> limits that are interesting in practice.
Hmm. What if we approached this a bit differently? We could add a
single new personality bit ADDR_LIMIT_EXPLICIT. Setting this bit
cause PER_LINUX32_3GB etc to be automatically cleared. When
ADDR_LIMIT_EXPLICIT is in effect, prctl can set a 64-bit numeric
limit. If ADDR_LIMIT_EXPLICIT is cleared, the prctl value stops being
settable and reading it via prctl returns whatever is implied by the
other personality bits.
--Andy
^ permalink raw reply
* [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
From: Andy Lutomirski @ 2017-01-03 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103160457.GB17319@node.shutemov.name>
On Tue, Jan 3, 2017 at 8:04 AM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
> On Mon, Jan 02, 2017 at 10:08:28PM -0800, Andy Lutomirski wrote:
>> On Mon, Jan 2, 2017 at 12:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tuesday, December 27, 2016 4:54:13 AM CET Kirill A. Shutemov wrote:
>> >> As with other resources you can set the limit lower than current usage.
>> >> It would affect only future virtual address space allocations.
>>
>> I still don't buy all these use cases:
>>
>> >>
>> >> Use-cases for new rlimit:
>> >>
>> >> - Bumping the soft limit to RLIM_INFINITY, allows current process all
>> >> its children to use addresses above 47-bits.
>>
>> OK, I get this, but only as a workaround for programs that make
>> assumptions about the address space and don't use some mechanism (to
>> be designed?) to work correctly in spite of a larger address space.
>
> I guess you've misread the case. It's opt-in for large adrress space, not
> other way around.
>
> I believe 47-bit VA by default is right way to go to make the transition
> without breaking userspace.
What I meant was: setting the rlimit to anything other than -1ULL is a
workaround, but otherwise I agree. This still makes little sense if
set by PAM or other conventional rlimit tools.
>> >>
>> >> - Lowering the hard limit to 47-bits would prevent current process all
>> >> its children to use addresses above 47-bits, unless a process has
>> >> CAP_SYS_RESOURCES.
>>
>> I've tried and I can't imagine any reason to do this.
>
> That's just if something went wrong and we want to stop an application
> from use addresses above 47-bit.
But CAP_SYS_RESOURCES still makes no sense in this context.
>
>> >> - It?s also can be handy to lower hard or soft limit to arbitrary
>> >> address. User-mode emulation in QEMU may lower the limit to 32-bit
>> >> to emulate 32-bit machine on 64-bit host.
>>
>> I don't understand. QEMU user-mode emulation intercepts all syscalls.
>> What QEMU would *actually* want is a way to say "allocate me some
>> memory with the high N bits clear". mmap-via-int80 on x86 should be
>> fixed to do this, but a new syscall with an explicit parameter would
>> work, as would a prctl changing the current limit.
>
> Look at mess in mmap_find_vma(). QEmu has to guess where is free virtual
> memory. That's unnessesary complex.
>
> prctl would work for this too. new-mmap would *not*: there are more ways
> to allocate vitual address space: shmat(), mremap(). Changing all of them
> just for this is stupid.
Fair enough.
Except that mmap-via-int80, shmat-via-int80, etc should still work (if
I understand what qemu needs correctly), as would the prctl.
>
>> >>
>> >> TODO:
>> >> - port to non-x86;
>> >>
>> >> Not-yet-signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>> >> Cc: linux-api at vger.kernel.org
>> >
>> > This seems to nicely address the same problem on arm64, which has
>> > run into the same issue due to the various page table formats
>> > that can currently be chosen at compile time.
>>
>> On further reflection, I think this has very little to do with paging
>> formats except insofar as paging formats make us notice the problem.
>> The issue is that user code wants to be able to assume an upper limit
>> on an address, and it gets an upper limit right now that depends on
>> architecture due to paging formats. But someone really might want to
>> write a *portable* 64-bit program that allocates memory with the high
>> 16 bits clear. So let's add such a mechanism directly.
>>
>> As a thought experiment, what if x86_64 simply never allocated "high"
>> (above 2^47-1) addresses unless a new mmap-with-explicit-limit syscall
>> were used? Old glibc would continue working. Old VMs would work.
>> New programs that want to use ginormous mappings would have to use the
>> new syscall. This would be totally stateless and would have no issues
>> with CRIU.
>
> Except, we need more than mmap as I mentioned.
>
> And what about stack? I'm not sure that everybody would be happy with
> stack in the middle of address space.
I would, personally. I think that, for very large address spaces, we
should allocate a large block of stack and get rid of the "stack grows
down forever" legacy idea. Then we would never need to worry about
the stack eventually hitting some other allocation. And 2^57 bytes is
hilariously large for a default stack.
^ 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