* [GIT PULL] Allwinner clock changes for 4.18
From: Stephen Boyd @ 2018-06-12 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67DOgnW=gesPxgmxZJWieZkzjPJm5mt7eW15HgUP3_SZg@mail.gmail.com>
Quoting Chen-Yu Tsai (2018-06-11 00:53:41)
> Hi,
>
> On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
> > Hi Maxime,
> >
> >
> > 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
> >> Hi Mike, Stephen,
> >>
> >> Please merge the following changes for the next merge window, thanks!
> >>
> >> Maxime
> >>
> >> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> >>
> >> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> >>
> >> are available in the Git repository at:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
> >>
> >> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
> >>
> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
> >>
> >> ----------------------------------------------------------------
> >> Allwinner clock changes for 4.18
> >>
> >> Not a lot of changes for this release, but two quite important features
> >> were added: the H6 PRCM clock support, and the needed changes to the R40
> >> clock driver to allow for the EMAC to operate.
> >>
> >> ----------------------------------------------------------------
> >> Icenowy Zheng (3):
> >> clk: sunxi-ng: add support for H6 PRCM CCU
> >> clk: sunxi-ng: r40: rewrite init code to a platform driver
> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register
> >>
> >
> >
> >
> > Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
> > not included in the pull request?
> >
> >
> > You said "I've picked it up"
> > https://patchwork.kernel.org/patch/10348031/
>
> It looks like it was accidentally dropped after a rebase.
> Not quite sure what happened there. Maxime?
>
I can directly pick and send as fix for clk-fixes targeting rc2.
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Stephen Boyd @ 2018-06-12 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18f6871e-794d-3ea2-487e-32399a8b89b4@microchip.com>
Quoting Codrin Ciubotariu (2018-06-07 03:30:14)
> >
> > Seems to me that clock additions could use a new binding and we start
> > with a new driver that handles these few clocks initially. But I
> > haven't looked whether both can coexist.
>
> Mark already applied to broonie/sound.git the I2S bindings that have a
> phandle to this clock. If I am to change #clock-cells to 1, I will have
> to change the bindings to include the clock-id.
> Which approach should I take now?
>
You're talking about changing the example in the binding doc? That
doesn't really matter. Consumer side of the provider has to match the
cell count from the provider so it doesn't really need to be 'fixed' in
the example at all.
^ permalink raw reply
* [PATCH v6 3/5] dt-bindings: timer: add i.MX EPIT timer binding
From: Clément Péron @ 2018-06-12 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611181042.GA30888@rob-hp-laptop>
Hi Rob,
On Mon, 11 Jun 2018 at 20:10, Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Jun 07, 2018 at 04:05:42PM +0200, Cl?ment P?ron wrote:
> > From: Cl?ment Peron <clement.peron@devialet.com>
> >
> > Add devicetree binding document for NXP's i.MX SoC specific
> > EPIT timer driver.
> >
> > Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> > ---
> > .../devicetree/bindings/timer/fsl,imxepit.txt | 21 +++++++++++++++++++
> > 1 file changed, 21 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Thanks, I posted the v7 yesterday, could you add your tag to the new release ?
Regards,
Clement
^ permalink raw reply
* [clk:clk-bcm-stingray 1/2] drivers/clk/bcm/clk-sr.c:217:3: error: 'BCM_SR_LCPLL0_SATA_REF_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL0_SATA_REFN_CLK'?
From: Stephen Boyd @ 2018-06-12 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <016e740bcf20db8fa753c6686812ce76@mail.gmail.com>
Quoting Ray Jui (2018-06-06 14:00:06)
> Hi Stephen,
>
> I'd like to confirm this kbuild error is caused by changing of the defines
> in the header.
>
> That is, kbuild test should pass with 2/2 patch.
>
> If my understanding is incorrect and this requires any further action,
> please let me know.
Don't think so. Linus merged clk-next over the weekend. Either I applied
the patches in the wrong order, or you sent them in the wrong order. In
the future, please compile test each patch in isolation. I do that
sometimes, but not always as it's still a manual process for me. I need
to update my scripts to make that better, which I'll do shortly.
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-12 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8Hs+CArdkAWoBPbr_p-nq5+0oPwOPg0NsJDRMkE_bM9A@mail.gmail.com>
Hi Ard,
On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 12 June 2018 at 08:36, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>> The start of the linear region map on a KASLR enabled ARM64 machine -
>> which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
>> support), is no longer correctly represented by the PAGE_OFFSET macro,
>> since it is defined as:
>>
>> (UL(1) << (VA_BITS - 1)) + 1)
>>
>
> PAGE_OFFSET is the VA of the start of the linear map. The linear map
> can be sparsely populated with actual memory, regardless of whether
> KASLR is in effect or not. The only difference in the presence of
> KASLR is that there may be such a hole at the beginning, but that does
> not mean the linear map has moved, or that the value of PAGE_OFFSET is
> now wrong.
>
>> So taking an example of a platform with VA_BITS=48, this gives a static
>> value of:
>> PAGE_OFFSET = 0xffff800000000000
>>
>> However, for the KASLR case, we use the 'memstart_offset_seed'
>> to randomize the linear region - since 'memstart_addr' indicates the
>> start of physical RAM, we randomize the same on basis
>> of 'memstart_offset_seed' value.
>>
>> As the PAGE_OFFSET value is used presently by several user space
>> tools (for e.g. makedumpfile and crash tools) to determine the start
>> of linear region and hence to read addresses (like PT_NOTE fields) from
>> '/proc/kcore' for the non-KASLR boot cases, so it would be better to
>> use 'memblock_start_of_DRAM()' value (converted to virtual) as
>> the start of linear region for the KASLR cases and default to
>> the PAGE_OFFSET value for non-KASLR cases to indicate the start of
>> linear region.
>>
>
> Userland code that assumes that the linear map cannot have a hole at
> the beginning should be fixed.
That is a separate case (although that needs fixing as well via a
kernel patch probably as the user-space tools rely on '/proc/iomem'
contents to determine the first System RAM/reserved range).
1. In that particular case (see [1]) the EFI firmware sets the first
EFI block as EfiReservedMemType:
Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]
Since EFI firmware won't return the "EfiReservedMemType" memory to
Linux kernel, so the kernel can't get any info about the first mem
block, and kernel can only see region2 as below:
efi: Processing EFI memory map:
efi: 0x000000200000-0x00000021ffff [Runtime Data |RUN| | |
| | | | |WB|WT|WC|UC]
# head -1 /proc/iomem
00200000-0021ffff : reserved
2a. If we add debug prints to 'arch/arm64/mm/init.c' to print the
kernel Virtual map we can see that the memory node is set to:
# dmesg | grep memory
..........
memory : 0xffff800000200000 - 0xffff801800000000
2b. Now if we use kexec-tools to obtain a crash vmcore we can see that
if we use 'readelf' to get the last program Header from vmcore (logs
below are for the non-kaslr case):
# readelf -l vmcore
ELF Header:
........................
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
..............................................................................................................................................................
LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
0x0000001680000000 0x0000001680000000 RWE 0
3. So if we do a simple calculation:
(VirtAddr + MemSiz) = 0xffff80017fe00000 + 0x0000001680000000 =
0xFFFF8017FFE00000 != 0xffff801800000000.
which indicates that the end virtual memory nodes are not the same
between vmlinux and vmcore.
This happens because the kexec-tools rely on 'proc/iomem' contents
while 'memstart_addr' is computed as 0 by kernel (as value of
memblock_start_of_DRAM() < ARM64_MEMSTART_ALIGN).
Returning back to this patch, this is a generic requirement where we
need the linear region start/base addresses in user-space applications
which is used to read addresses which lie in the linear region (for
e.g. when we read /proc/kcore contents).
>> I tested this on my qualcomm (which supports EFI_RNG_PROTOCOL)
>> and apm mustang (which does not support EFI_RNG_PROTOCOL) arm64 boards
>> and was able to use a modified user space utility (like kexec-tools and
>> makedumpfile) to determine the start of linear region correctly for
>> both the KASLR and non-KASLR boot cases.
>>
>
> Can you explain the nature of the changes to the userland code?
The changes are not to rely on the fixed PAGE_OFFSET macro value for
determining the base address of the linear region, but rather read the
' linear_reg_start_addr' symbol from kernel and use the same both in
case of KASLR and non-KASLR boots to determine the base of the linear
region (in [2], I have implemented a test change to kexec-tools to
read the 'linear_reg_start_addr' symbol which is available on my
public github tree, I have a similar change available in makedumpfile
which I have not yet pushed to github, as it implements other features
as well)
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/582407.html
[2] https://github.com/bhupesh-sharma/kexec-tools/commit/ae511833e948ccf864fae142ccd903f9c7b3461d
Regards,
Bhupesh
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> Cc: James Morse <james.morse@arm.com>
>> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
>> ---
>> arch/arm64/include/asm/memory.h | 3 +++
>> arch/arm64/kernel/arm64ksyms.c | 1 +
>> arch/arm64/mm/init.c | 3 +++
>> 3 files changed, 7 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index 49d99214f43c..bfd0915ecaf8 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -178,6 +178,9 @@ extern s64 memstart_addr;
>> /* PHYS_OFFSET - the physical address of the start of memory. */
>> #define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
>>
>> +/* the virtual base of the linear region. */
>> +extern s64 linear_reg_start_addr;
>> +
>> /* the virtual base of the kernel image (minus TEXT_OFFSET) */
>> extern u64 kimage_vaddr;
>>
>> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
>> index d894a20b70b2..a92238ea45ff 100644
>> --- a/arch/arm64/kernel/arm64ksyms.c
>> +++ b/arch/arm64/kernel/arm64ksyms.c
>> @@ -42,6 +42,7 @@ EXPORT_SYMBOL(__arch_copy_in_user);
>>
>> /* physical memory */
>> EXPORT_SYMBOL(memstart_addr);
>> +EXPORT_SYMBOL(linear_reg_start_addr);
>>
>> /* string / mem functions */
>> EXPORT_SYMBOL(strchr);
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 325cfb3b858a..29447adb0eef 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -60,6 +60,7 @@
>> * that cannot be mistaken for a real physical address.
>> */
>> s64 memstart_addr __ro_after_init = -1;
>> +s64 linear_reg_start_addr __ro_after_init = PAGE_OFFSET;
>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>
>> #ifdef CONFIG_BLK_DEV_INITRD
>> @@ -452,6 +453,8 @@ void __init arm64_memblock_init(void)
>> }
>> }
>>
>> + linear_reg_start_addr = __phys_to_virt(memblock_start_of_DRAM());
>> +
>> /*
>> * Register the kernel text, kernel data, initrd, and initial
>> * pagetables with memblock.
>> --
>> 2.7.4
>>
^ permalink raw reply
* [PATCH 3/3] pinctrl: actions: Add interrupt support for OWL S900 SoC
From: Linus Walleij @ 2018-06-12 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180602165415.30956-4-manivannan.sadhasivam@linaro.org>
On Sat, Jun 2, 2018 at 6:54 PM, Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
> Add interrupt support for Actions Semi OWL S900 SoC.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
(...)
> +++ b/drivers/pinctrl/actions/Kconfig
> @@ -5,6 +5,7 @@ config PINCTRL_OWL
> select PINCONF
> select GENERIC_PINCONF
> select GPIOLIB
> + select GPIOLIB_IRQCHIP
I don't think you're really using that (certain sign: you're implementing
.to_irq().)
GPIOLIB_IRQCHIP is nice, but can only be used when there is
a 1-1 correspondence betweem GPIO line offsets and
IRQ lines and they are numbered 0..n.
However I think you can use it! Look below for my reference
to the tegra186 and how you can probably cut out the custom
irqdomain with some manouvers.
> + struct owl_pinctrl *pctrl = irq_data_get_irq_chip_data(data);
> + const struct owl_gpio_port *port;
(...)
> + unsigned int gpio = data->hwirq;
> +
> + port = owl_gpio_get_port(pctrl, &gpio);
> +
> + gpio_base = pctrl->base + port->offset;
It is all about this calculation really.
> +static int owl_gpio_irq_set_type(struct irq_data *data, unsigned int type)
> +{
> + struct owl_pinctrl *pctrl = irq_data_get_irq_chip_data(data);
> + const struct owl_gpio_port *port;
> + void __iomem *gpio_base;
> + unsigned long flags;
> + unsigned int gpio = data->hwirq;
> + unsigned int offset, value, irq_type = 0;
> +
> + port = owl_gpio_get_port(pctrl, &gpio);
> + if (WARN_ON(port == NULL))
> + return -ENODEV;
> +
> + gpio_base = pctrl->base + port->offset;
> +
> + switch (type) {
> + case IRQ_TYPE_EDGE_RISING:
> + irq_type = OWL_GPIO_INT_EDGE_RISING;
> + break;
> +
> + case IRQ_TYPE_EDGE_FALLING:
> + irq_type = OWL_GPIO_INT_EDGE_FALLING;
> + break;
Very often things such as keys will request trigger on
both edges. This means IRQ_TYPE_EDGE_RISING
and IRQ_TYPE_EDGE_FALLING are both set, which
will cause you problems here, since it is unhandled.
I guess it is fine to set both?
> + offset = gpio < 16 ? 4 : 0;
I think even the compiler should suggest putting he (gpio < 16)
expression in paranthesis.
> + value = readl_relaxed(gpio_base + port->intc_type + offset);
> + value &= ~(OWL_GPIO_INT_MASK << ((gpio % 16) * 2));
> + value |= irq_type << ((gpio % 16) * 2);
> + writel_relaxed(value, gpio_base + port->intc_type + offset);
> +
> + raw_spin_unlock_irqrestore(&pctrl->lock, flags);
> +
> + if (type & IRQ_TYPE_EDGE_BOTH)
> + irq_set_handler_locked(data, handle_edge_irq);
> + else
> + irq_set_handler_locked(data, handle_level_irq);
Here you handle both edges, but not in the switch clause.
> +static void owl_gpio_irq_handler(struct irq_desc *desc)
This looks fine.
> +static struct irq_chip owl_gpio_irq_chip = {
> + .name = "owlgpio",
> + .irq_mask = owl_gpio_irq_mask,
> + .irq_unmask = owl_gpio_irq_unmask,
> + .irq_ack = owl_gpio_irq_ack,
> + .irq_set_type = owl_gpio_irq_set_type,
> +};
If you implement your own irqchip you need to implement
.irq_request_resources and .irq_free_resources locking the GPIO
lines for interrupt, see other drivers that do this or the
gpiolib core code in gpiolib.c.
It would be really neat if you could instead use the
GPIOLIB_IRQCHIP though, but I know it will be a bit tricky
and maybe not possible.
> + for (i = 0; i < pctrl->soc->nports; i++) {
> + irq_set_chained_handler_and_data(pctrl->irq[i],
> + owl_gpio_irq_handler,
> + pctrl);
> + }
If you use GPIOLIB_IRQCHIP with several parent IRQs.
See Thierry's work in drivers/gpio/gpio-tegra186.c for the
only example.
I think that is what you want to do here.
We do want to add helpers in gpiolib to do this in a more
organized and easy-to-use fashion. Patches welcome ;)
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Chen-Yu Tsai @ 2018-06-12 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152879040155.16708.9862482085365718831@swboyd.mtv.corp.google.com>
On Tue, Jun 12, 2018 at 4:00 PM, Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Chen-Yu Tsai (2018-06-11 00:53:41)
>> Hi,
>>
>> On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
>> <yamada.masahiro@socionext.com> wrote:
>> > Hi Maxime,
>> >
>> >
>> > 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
>> >> Hi Mike, Stephen,
>> >>
>> >> Please merge the following changes for the next merge window, thanks!
>> >>
>> >> Maxime
>> >>
>> >> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>> >>
>> >> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>> >>
>> >> are available in the Git repository at:
>> >>
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
>> >>
>> >> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
>> >>
>> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
>> >>
>> >> ----------------------------------------------------------------
>> >> Allwinner clock changes for 4.18
>> >>
>> >> Not a lot of changes for this release, but two quite important features
>> >> were added: the H6 PRCM clock support, and the needed changes to the R40
>> >> clock driver to allow for the EMAC to operate.
>> >>
>> >> ----------------------------------------------------------------
>> >> Icenowy Zheng (3):
>> >> clk: sunxi-ng: add support for H6 PRCM CCU
>> >> clk: sunxi-ng: r40: rewrite init code to a platform driver
>> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register
>> >>
>> >
>> >
>> >
>> > Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
>> > not included in the pull request?
>> >
>> >
>> > You said "I've picked it up"
>> > https://patchwork.kernel.org/patch/10348031/
>>
>> It looks like it was accidentally dropped after a rebase.
>> Not quite sure what happened there. Maxime?
>>
>
> I can directly pick and send as fix for clk-fixes targeting rc2.
The patch can still be found in the sunxi/for-next branch of the
sunxi repo on kernel.org:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/for-next&id=d4a1496286b0c29fcace4e10c0047cca7cc79b25
Or the original on patchwork:
https://patchwork.kernel.org/patch/10348027/
Thanks
ChenYu
^ permalink raw reply
* [PATCH 2/6] PCI: iproc: Add INTx support with better modeling
From: poza at codeaurora.org @ 2018-06-12 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-3-git-send-email-ray.jui@broadcom.com>
On 2018-05-30 03:28, Ray Jui wrote:
> Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
> modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
> INTD share the same interrupt line connected to the GIC in the system,
> while the status of each INTx can be obtained through the INTX CSR
> register
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> drivers/pci/host/pcie-iproc-platform.c | 2 +
> drivers/pci/host/pcie-iproc.c | 95
> +++++++++++++++++++++++++++++++++-
> drivers/pci/host/pcie-iproc.h | 6 +++
> 3 files changed, 101 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-iproc-platform.c
> b/drivers/pci/host/pcie-iproc-platform.c
> index e764a2a..7a51e6c 100644
> --- a/drivers/pci/host/pcie-iproc-platform.c
> +++ b/drivers/pci/host/pcie-iproc-platform.c
> @@ -70,6 +70,8 @@ static int iproc_pcie_pltfm_probe(struct
> platform_device *pdev)
> }
> pcie->base_addr = reg.start;
>
> + pcie->irq = platform_get_irq(pdev, 0);
> +
> if (of_property_read_bool(np, "brcm,pcie-ob")) {
> u32 val;
>
> diff --git a/drivers/pci/host/pcie-iproc.c
> b/drivers/pci/host/pcie-iproc.c
> index 14f374d..0bd2c14 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -14,6 +14,7 @@
> #include <linux/delay.h>
> #include <linux/interrupt.h>
> #include <linux/irqchip/arm-gic-v3.h>
> +#include <linux/irqchip/chained_irq.h>
> #include <linux/platform_device.h>
> #include <linux/of_address.h>
> #include <linux/of_pci.h>
> @@ -264,6 +265,7 @@ enum iproc_pcie_reg {
>
> /* enable INTx */
> IPROC_PCIE_INTX_EN,
> + IPROC_PCIE_INTX_CSR,
>
> /* outbound address mapping */
> IPROC_PCIE_OARR0,
> @@ -305,6 +307,7 @@ static const u16 iproc_pcie_reg_paxb_bcma[] = {
> [IPROC_PCIE_CFG_ADDR] = 0x1f8,
> [IPROC_PCIE_CFG_DATA] = 0x1fc,
> [IPROC_PCIE_INTX_EN] = 0x330,
> + [IPROC_PCIE_INTX_CSR] = 0x334,
> [IPROC_PCIE_LINK_STATUS] = 0xf0c,
> };
>
> @@ -316,6 +319,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
> [IPROC_PCIE_CFG_ADDR] = 0x1f8,
> [IPROC_PCIE_CFG_DATA] = 0x1fc,
> [IPROC_PCIE_INTX_EN] = 0x330,
> + [IPROC_PCIE_INTX_CSR] = 0x334,
> [IPROC_PCIE_OARR0] = 0xd20,
> [IPROC_PCIE_OMAP0] = 0xd40,
> [IPROC_PCIE_OARR1] = 0xd28,
> @@ -332,6 +336,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
> [IPROC_PCIE_CFG_ADDR] = 0x1f8,
> [IPROC_PCIE_CFG_DATA] = 0x1fc,
> [IPROC_PCIE_INTX_EN] = 0x330,
> + [IPROC_PCIE_INTX_CSR] = 0x334,
> [IPROC_PCIE_OARR0] = 0xd20,
> [IPROC_PCIE_OMAP0] = 0xd40,
> [IPROC_PCIE_OARR1] = 0xd28,
> @@ -782,9 +787,90 @@ static int iproc_pcie_check_link(struct iproc_pcie
> *pcie)
> return link_is_active ? 0 : -ENODEV;
> }
>
> -static void iproc_pcie_enable(struct iproc_pcie *pcie)
> +static int iproc_pcie_intx_map(struct irq_domain *domain, unsigned int
> irq,
> + irq_hw_number_t hwirq)
> {
> + irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_simple_irq);
> + irq_set_chip_data(irq, domain->host_data);
> +
> + return 0;
> +}
> +
> +static const struct irq_domain_ops intx_domain_ops = {
> + .map = iproc_pcie_intx_map,
> +};
> +
> +static void iproc_pcie_isr(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct iproc_pcie *pcie;
> + struct device *dev;
> + unsigned long status;
> + u32 bit, virq;
> +
> + chained_irq_enter(chip, desc);
> + pcie = irq_desc_get_handler_data(desc);
> + dev = pcie->dev;
> +
> + /* go through INTx A, B, C, D until all interrupts are handled */
> + while ((status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR) &
> + SYS_RC_INTX_MASK) != 0) {
> + for_each_set_bit(bit, &status, PCI_NUM_INTX) {
> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err(dev, "unexpected INTx%u\n", bit);
> + }
> + }
> +
Are these level or edge interrupts ? although I see DT says:
IRQ_TYPE_NONE
do you not need to clear interrupt status bits in IPROC_PCIE_INTX_CSR ?
> + chained_irq_exit(chip, desc);
> +}
> +
> +static int iproc_pcie_intx_enable(struct iproc_pcie *pcie)
> +{
> + struct device *dev = pcie->dev;
> + struct device_node *node = dev->of_node;
> + int ret;
> +
> iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, SYS_RC_INTX_MASK);
> +
> + /*
> + * BCMA devices do not map INTx the same way as platform devices. All
> + * BCMA needs is the above code to enable INTx
> + */
> + if (pcie->irq <= 0)
> + return 0;
> +
> + /* set IRQ handler */
> + irq_set_chained_handler_and_data(pcie->irq, iproc_pcie_isr, pcie);
> +
> + /* add IRQ domain for INTx */
> + pcie->irq_domain = irq_domain_add_linear(node, PCI_NUM_INTX + 1,
> + &intx_domain_ops, pcie);
> + if (!pcie->irq_domain) {
> + dev_err(dev, "failed to add INTx IRQ domain\n");
> + ret = -ENOMEM;
> + goto err_rm_handler_data;
> + }
> +
> + return 0;
> +
> +err_rm_handler_data:
> + irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
> +
> + return ret;
> +}
> +
> +static void iproc_pcie_intx_disable(struct iproc_pcie *pcie)
> +{
> + iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, 0x0);
> +
> + if (pcie->irq <= 0)
> + return;
> +
> + irq_domain_remove(pcie->irq_domain);
> + irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
> }
>
> static inline bool iproc_pcie_ob_is_valid(struct iproc_pcie *pcie,
> @@ -1410,7 +1496,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie,
> struct list_head *res)
> goto err_power_off_phy;
> }
>
> - iproc_pcie_enable(pcie);
> + ret = iproc_pcie_intx_enable(pcie);
> + if (ret) {
> + dev_err(dev, "failed to enable INTx\n");
> + goto err_power_off_phy;
> + }
>
> if (IS_ENABLED(CONFIG_PCI_MSI))
> if (iproc_pcie_msi_enable(pcie))
> @@ -1455,6 +1545,7 @@ int iproc_pcie_remove(struct iproc_pcie *pcie)
> pci_remove_root_bus(pcie->root_bus);
>
> iproc_pcie_msi_disable(pcie);
> + iproc_pcie_intx_disable(pcie);
>
> phy_power_off(pcie->phy);
> phy_exit(pcie->phy);
> diff --git a/drivers/pci/host/pcie-iproc.h
> b/drivers/pci/host/pcie-iproc.h
> index 67081cb..cbcaf9d 100644
> --- a/drivers/pci/host/pcie-iproc.h
> +++ b/drivers/pci/host/pcie-iproc.h
> @@ -72,6 +72,9 @@ struct iproc_msi;
> * @ib: inbound mapping related parameters
> * @ib_map: outbound mapping region related parameters
> *
> + * @irq: interrupt line wired to the generic GIC for INTx
> + * @irq_domain: IRQ domain for INTx
> + *
> * @need_msi_steer: indicates additional configuration of the iProc
> PCIe
> * controller is required to steer MSI writes to external interrupt
> controller
> * @msi: MSI data
> @@ -99,6 +102,9 @@ struct iproc_pcie {
> struct iproc_pcie_ib ib;
> const struct iproc_pcie_ib_map *ib_map;
>
> + int irq;
> + struct irq_domain *irq_domain;
> +
> bool need_msi_steer;
> struct iproc_msi *msi;
> };
^ permalink raw reply
* [PATCH v3 0/6] add virt-dma support for imx-sdma
From: Robin Gong @ 2018-06-12 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528714877.2842.3.camel@pengutronix.de>
Hi Lucas,
Is the below DEAD LOCK issue same as your side? If yes, then
I'm afraid that we have to make another patch for uart to split dma
functions in uart driver out of the code area which protected by
port.lock. The warning make sense since allocate sdma bd memory
dynamically in virt-dma instead of static allocated as before. I'll
make another uart patch into my next version patchset.
[???46.155406] =====================================================
[???46.161503] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order
detected
[???46.168122] 4.17.0-rc6-00008-g7caafa3-dirty #48 Not tainted
[???46.173696] -----------------------------------------------------
[???46.179795] mxc_uart_stress/419 [HC0[0]:SC0[0]:HE0:SE1] is trying to
acquire:
[???46.186934] fa7c1440 (fs_reclaim){+.+.}, at:
fs_reclaim_acquire.part.3+0x0/0x48
[???46.194270]
[???46.194270] and this task is already holding:
[???46.200106] 09a17fda (&port_lock_key){-.-.}, at:
uart_write+0x84/0x190
[???46.206658] which would create a new lock dependency:
[???46.211710]??(&port_lock_key){-.-.} -> (fs_reclaim){+.+.}
[???46.217132]
[???46.217132] but this new dependency connects a HARDIRQ-irq-safe
lock:
[???46.225051]??(&port_lock_key){-.-.}
[???46.225062]
[???46.225062] ... which became HARDIRQ-irq-safe at:
[???46.234740]???lock_acquire+0x70/0x90
[???46.238326]???_raw_spin_lock_irqsave+0x40/0x54
[???46.242777]???imx_uart_console_write+0x1bc/0x1e0
[???46.247402]???console_unlock+0x320/0x5f0
[???46.251329]???vprintk_emit+0x22c/0x3fc
[???46.255082]???vprintk_default+0x28/0x30
[???46.258923]???vprintk_func+0x78/0xcc
[???46.262503]???printk+0x34/0x54
[???46.265566]???crng_fast_load+0xf8/0x138
[???46.269407]???add_interrupt_randomness+0x21c/0x24c
[???46.274204]???handle_irq_event_percpu+0x40/0x84
[???46.278739]???handle_irq_event+0x40/0x64
[???46.282667]???handle_fasteoi_irq+0xbc/0x178
[???46.286854]???generic_handle_irq+0x28/0x3c
[???46.290954]???__handle_domain_irq+0x6c/0xe8
[???46.295148]???gic_handle_irq+0x64/0xc4
[???46.298904]???__irq_svc+0x70/0x98
[???46.302225]???_raw_spin_unlock_irq+0x30/0x34
[???46.306505]???finish_task_switch+0xc0/0x27c
[???46.310693]???__schedule+0x2c0/0x79c
[???46.314272]???schedule_idle+0x40/0x84
[???46.317941]???do_idle+0x178/0x2b4
[???46.321259]???cpu_startup_entry+0x20/0x24
[???46.325278]???rest_init+0x214/0x264
[???46.328775]???start_kernel+0x39c/0x424
[???46.332527]?????(null)
[???46.334891]
[???46.334891] to a HARDIRQ-irq-unsafe lock:
[???46.340379]??(fs_reclaim){+.+.}
[???46.340391]
[???46.340391] ... which became HARDIRQ-irq-unsafe at:
[???46.349885] ...
[???46.349895]???lock_acquire+0x70/0x90
[???46.355225]???fs_reclaim_acquire.part.3+0x38/0x48
[???46.359933]???fs_reclaim_acquire+0x1c/0x20
[???46.364036]???kmem_cache_alloc+0x2c/0x174
[???46.368051]???alloc_worker.constprop.10+0x1c/0x58
[???46.372759]???init_rescuer.part.4+0x18/0xa4
[???46.376952]???workqueue_init+0xc0/0x210
[???46.380793]???kernel_init_freeable+0x58/0x1d8
[???46.385156]???kernel_init+0x10/0x11c
[???46.388736]???ret_from_fork+0x14/0x20
[???46.392399]?????(null)
[???46.394762]
[???46.394762] other info that might help us debug this:
[???46.394762]
[???46.402769]??Possible interrupt unsafe locking scenario:
[???46.402769]
[???46.409560]????????CPU0????????????????????CPU1
[???46.414092]????????----????????????????????----
[???46.418622]???lock(fs_reclaim);
[???46.421772]????????????????????????????????local_irq_disable();
[???46.427693]????????????????????????????????lock(&port_lock_key);
[???46.433707]????????????????????????????????lock(fs_reclaim);
[???46.439372]???<Interrupt>
[???46.441993]?????lock(&port_lock_key);
[???46.445661]
[???46.445661]??*** DEADLOCK ***
[???46.445661]
On ?, 2018-06-11 at 13:01 +0200, Lucas Stach wrote:
> Hi Robin,
>
> this series breaks serial DMA for me. I wasn't able to dig in deeper
> yet. Please let me know if you can test/reproduce at your side, if
> not
> I'll try to find some time to collect some more debug info.
>
> Regards,
> Lucas
>
> Am Montag, den 11.06.2018, 22:59 +0800 schrieb Robin Gong:
> >
> > The legacy sdma driver has below limitations or drawbacks:
> > ? 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and
> > alloc
> > ?????one page size for one channel regardless of only few BDs
> > needed
> > ?????most time. But in few cases, the max PAGE_SIZE maybe not
> > enough.
> > ? 2. One SDMA channel can't stop immediatley once channel disabled
> > which
> > ?????means SDMA interrupt may come in after this channel
> > terminated.There
> > ?????are some patches for this corner case such as commit
> > "2746e2c389f9",
> > ?????but not cover non-cyclic.
> >
> > The common virt-dma overcomes the above limitations. It can alloc
> > bd
> > dynamically and free bd once this tx transfer done. No memory
> > wasted or
> > maximum limititation here, only depends on how many memory can be
> > requested
> > from kernel. For No.2, such issue can be workaround by checking if
> > there
> > is available descript("sdmac->desc") now once the unwanted
> > interrupt
> > coming. At last the common virt-dma is easier for sdma driver
> > maintain.
> >
> > Change from v2:
> > ? 1. include Sascha's patch to make the main patch easier to
> > review.
> > ?????Thanks Sacha.
> > ? 2. remove useless 'desc'/'chan' in struct sdma_channe.
> >
> > Change from v1:
> > ? 1. split v1 patch into 5 patches.
> > ? 2. remove some unnecessary condition check.
> > ? 3. remove unnecessary 'pending' list.
> >
> > Robin Gong (5):
> > ? dmaengine: imx-sdma: add virt-dma support
> > ? Revert "dmaengine: imx-sdma: fix pagefault when channel is
> > disabled
> > ????during interrupt"
> > ? dmaengine: imx-sdma: remove usless lock
> > ? dmaengine: imx-sdma: remove the maximum limation for bd numbers
> > ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code
> > overlap
> >
> > ?drivers/dma/Kconfig????|???1 +
> > ?drivers/dma/imx-sdma.c | 392 ++++++++++++++++++++++++++++---------
> > ------------
> > ?2 files changed, 227 insertions(+), 166 deletions(-)
> >
> > --?
> > 2.7.4
> >
> > Robin Gong (5):
> > ? dmaengine: imx-sdma: add virt-dma support
> > ? Revert "dmaengine: imx-sdma: fix pagefault when channel is
> > disabled
> > ????during interrupt"
> > ? dmaengine: imx-sdma: remove usless lock
> > ? dmaengine: imx-sdma: remove the maximum limation for bd numbers
> > ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code
> > overlap
> >
> > Sascha Hauer (1):
> > ? dmaengine: imx-sdma: factor out a struct sdma_desc from struct
> > ????sdma_channel
> >
> > ?drivers/dma/Kconfig????|???1 +
> > ?drivers/dma/imx-sdma.c | 391 ++++++++++++++++++++++++++++---------
> > ------------
> > ?2 files changed, 226 insertions(+), 166 deletions(-)
> >
^ permalink raw reply
* [PATCH 0/5] arm64: numa/topology/smp: fix the cpumasks for CPU hotplug
From: Sudeep Holla @ 2018-06-12 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <23796631-312b-82a0-fe03-cb7985433727@huawei.com>
On 12/06/18 02:14, Hanjun Guo wrote:
> Hi Sudeep,
>
> On 2018/6/4 18:39, Sudeep Holla wrote:
>> Hi Will, Catalin, Jeremy, Morten,
>>
>> This is the fix I could come up for the issues we are seeing with arm64
>> for-next branch, in particular with commit 37c3ec2d810f ("arm64: topology:
>> divorce MC scheduling domain from core_siblings").
>>
>> The solution is to update the CPU topology during CPU hotplug operations
>> similar to other architectures like x86 and PPC. This is also inline
>> with the expection from the scheduler.
>>
>> I have cc-ed few Cavium and Huawei guys as they seem to have added or
>> modified the numa related code in the past.
>
> Sorry for the late response, I can test on ARM64 NUMA systems
> with PPTT enabled, before I'm doing that, could you give some
> suggestion of the testing? what specific test case should I
> test? doing CPU offline/online when PPTT is enabled?
>
Thanks for the response. I plan to post v2 after -rc1 which will have
some delta from this. So don't test this for now. Yes CPU hotplug tests
will be good. Also some NUMA based(numactl) assignments and try
hotplugging all CPUs in a node and similar tests with PPTT would be good.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] arm64: make secondary_start_kernel() notrace
From: Zhizhou Zhang @ 2018-06-12 9:07 UTC (permalink / raw)
To: linux-arm-kernel
We can't call function trace hook before setup percpu offset.
When entering secondary_start_kernel(), percpu offset has not
been initialized. So this lead hotplug malfunction.
Here is the flow to reproduce this bug:
echo 0 > /sys/devices/system/cpu/cpu1/online
echo function > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 1 > /sys/devices/system/cpu/cpu1/online
Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
---
arch/arm64/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f3e2e3ae..11b0f30 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -179,7 +179,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
* This is the secondary CPU boot entry. We're using this CPUs
* idle thread stack, but a set of temporary page tables.
*/
-asmlinkage void secondary_start_kernel(void)
+notrace asmlinkage void secondary_start_kernel(void)
{
u64 mpidr = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
struct mm_struct *mm = &init_mm;
--
1.9.1
^ permalink raw reply related
* [PATCH] arm64: make secondary_start_kernel() notrace
From: Mark Rutland @ 2018-06-12 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528794457-14129-1-git-send-email-zhizhouzhang@asrmicro.com>
On Tue, Jun 12, 2018 at 05:07:37PM +0800, Zhizhou Zhang wrote:
> We can't call function trace hook before setup percpu offset.
> When entering secondary_start_kernel(), percpu offset has not
> been initialized. So this lead hotplug malfunction.
> Here is the flow to reproduce this bug:
>
> echo 0 > /sys/devices/system/cpu/cpu1/online
> echo function > /sys/kernel/debug/tracing/current_tracer
> echo 1 > /sys/kernel/debug/tracing/tracing_on
> echo 1 > /sys/devices/system/cpu/cpu1/online
>
> Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
> ---
> arch/arm64/kernel/smp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index f3e2e3ae..11b0f30 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -179,7 +179,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> * This is the secondary CPU boot entry. We're using this CPUs
> * idle thread stack, but a set of temporary page tables.
> */
> -asmlinkage void secondary_start_kernel(void)
> +notrace asmlinkage void secondary_start_kernel(void)
Minor nit: can we please keep asmlinkage first, e.g.
asmlinkage notrace void secondary_start_kernel(void)
Either way:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> {
> u64 mpidr = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> struct mm_struct *mm = &init_mm;
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] arm64: make secondary_start_kernel() notrace
From: Suzuki K Poulose @ 2018-06-12 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528794457-14129-1-git-send-email-zhizhouzhang@asrmicro.com>
On 12/06/18 10:07, Zhizhou Zhang wrote:
> We can't call function trace hook before setup percpu offset.
> When entering secondary_start_kernel(), percpu offset has not
> been initialized. So this lead hotplug malfunction.
> Here is the flow to reproduce this bug:
>
> echo 0 > /sys/devices/system/cpu/cpu1/online
> echo function > /sys/kernel/debug/tracing/current_tracer
> echo 1 > /sys/kernel/debug/tracing/tracing_on
> echo 1 > /sys/devices/system/cpu/cpu1/online
>
> Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
> ---
> arch/arm64/kernel/smp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index f3e2e3ae..11b0f30 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -179,7 +179,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> * This is the secondary CPU boot entry. We're using this CPUs
> * idle thread stack, but a set of temporary page tables.
> */
> -asmlinkage void secondary_start_kernel(void)
> +notrace asmlinkage void secondary_start_kernel(void)
> {
> u64 mpidr = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> struct mm_struct *mm = &init_mm;
>
Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
I think this should go to stable releases as well.
Suzuki
^ permalink raw reply
* [PATCH 10/20] dts: juno: Update coresight bindings for hw port
From: Suzuki K Poulose @ 2018-06-12 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkxNakRGCWT6O0JRKz+N1OTU3-XreC_FiB8Fiv+jEoPEbQ@mail.gmail.com>
On 08/06/18 22:52, Mathieu Poirier wrote:
> On 8 June 2018 at 15:49, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>> On Tue, Jun 05, 2018 at 10:43:21PM +0100, Suzuki K Poulose wrote:
>>> Switch to updated coresight bindings for hw ports.
>>>
>>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>> ---
>>> Changes since V1:
>>> - Add support Juno for r1 & r2.
>>> ---
>>
>> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Sudeep please hold on before applying this as there is more work to be
> done on this set.
Mathieu,
I will wait for Rob / Frank to have a say on the bindings before I post the
next update.
Cheers
Suzuki
^ permalink raw reply
* [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Sean Wang @ 2018-06-12 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DC3FE66E-C3FD-455F-8592-E927604086CD@holtmann.org>
On Wed, 2018-05-30 at 08:26 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
> >>>>>>
[ ... ]
> >>> * Unknown packet (code 14 len 30) 0.641509
> >>> 01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..............bl
> >>> 75 65 74 6f 6f 74 68 64 00 00 00 00 00 00 uetoothd......
> >>> * Unknown packet (code 14 len 30) 0.641592
> >>> 02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..............bt
> >>> 6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00 mon...........
> >>> * Unknown packet (code 16 len 7) [hci0] 6.536771
> >>> 01 00 00 00 05 00 01 .......
> >>> = Open Index: 00:00:46:76:22:01 [hci0] 6.717019
> >>> = Index Info: 00:00:46:76:22:01 (MediaTek, Inc.) [hci0] 6.717030
> >>
> >> can you try with the latest BlueZ 5.49 or git version. Seems it actually stumbles over the extra packet here. Fun fact is that I can not get a backtrace to pin-point the issue in btmon and why it crashes.
> >>
> >
> > I had less experience updating user land BlueZ, but I can try it as possible and see whether Unknown packets still are present at newest version BlueZ. Hopefully I don't misunderstand your point here.
>
> please use the latest btmon and check if it can read your trace.
>
sure, I'll have a try with the latest btmon.
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.741093
> >>> 02 01 01 00 00 .....
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.742088
> >>> 02 01 01 00 00 .....
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.743102
> >>> 02 01 01 00 00 .....
[ ... ]
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.814708
> >>> 02 01 01 00 00 .....
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.815705
> >>> 02 01 01 00 00 .....
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816378
> >>> 02 01 01 00 00 .....
> >>
> >> Why do I see only HCI events here? Is this event conveying any useful information. It is kinda complicated that this is 0xe4 event code which is actually reserved for future use by the Bluetooth SIG. Are there any accompanying HCI commands for this and they just not make it into btmon?
> >>
> >
> > I have made all vendor HCI commands go through BlueZ core in v2 patch.
> >
> > And for these HCI events, they are all corresponding to vendor ACL data, applied only to firmware setup packets, but they're not being sent via BlueZ core, so they are not being logged in btmon.
> >
> > As for its event, where heading 0xe4 refers to a vendor event and is used on notification of that either vendor ACL data or vendor HCI command have been done.
>
> I would prefer if everything goes via the Bluetooth core since then we have it all properly scheduled. Sending things down the ACL data path however if kinda funky. Does your hardware accept sending command both via ACL data and as HCI command? If so, then I would prefer sending them as HCI commands since the speed improvement you think you are getting is neglectable on Linux (I have been down that path). This seems to be a pure optimization when Windows is driving the device.
>
firmware people said the device can support firmware download as HCI commands. According to my test, this way indeed works so I will improve the part in the next version.
> And the vendor event 0xe4 is really only received during firmware download? It is not ever received during normal operation?
>
0xe4 is only received during chip initialization.
I also thought 0xe4 is a poor definition for vendor event and already have notified firmware people should pick 0xff as its vendor event id in the future.
but for now, unfortunately, 0xe4 cannot be changed on the device, the only way is to add a workaround in RX path as below to allow btmon can recognize these bad events properly.
int mtk_btuart_hci_frame(struct hci_dev *hdev, struct sk_buff *skb)
{
struct hci_event_hdr *hdr = (void *)skb->data;
/* Fix up the vendor event id with HCI_VENDOR_PKT instead of
* 0xe4 so that btmon can parse the kind of vendor event properly.
*/
if (hdr->evt == 0xe4)
hdr->evt = HCI_VENDOR_PKT;
/* Each HCI event would go through the core. */
return hci_recv_frame(hdev, skb);
}
> >
> >>
> >>
> >>> < HCI Command: Vendor (0x3f|0x006f) plen 5 [hci0] 6.816413
> >>> 01 07 01 00 04 .....
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816536
> >>> 02 07 01 00 00 .....
[ ... ]
> >>> Encapsulated PDU
> >>> Erroneous Data Reporting
> >>> Non-flushable Packet Boundary Flag
> >>> Link Supervision Timeout Changed Event
> >>> Inquiry TX Power Level
> >>> Enhanced Power Control
> >>> Extended features
> >>> < HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0 [hci0] 10.865987
> >>>> HCI Event: Vendor (0xff) plen 9 [hci0] 10.866259
> >>> 29 19 09 17 20 48 07 11 00 )... H?
> >>
> >> Is this meant to happen here?
> >>
> >
> > If event received is not expected as the specification defines, I think it's probably incorrect.
> >
> > But it requires more discussion with firmware people to make it clearer.
>
> Please check and let them decode what this event means.
>
it's just debugging purpose information listing built-time something
like that and will be removed in the firmware.
> >
> >>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.866372
> >>> Read Local Version Information (0x04|0x0001) ncmd 1
> >>> Status: Success (0x00)
> >>> HCI version: Bluetooth 4.2 (0x08) - Revision 4359 (0x1107)
> >>> LMP version: Bluetooth 4.2 (0x08) - Subversion 2329 (0x0919)
> >>> Manufacturer: MediaTek, Inc. (70)
> >>> < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 [hci0] 10.866391
> >>>> HCI Event: Command Complete (0x0e) plen 10 [hci0] 10.866539
[ ... ]
> >>> LE Add Device To Resolving List (Octet 34 - Bit 3)
> >>> LE Remove Device From Resolving List (Octet 34 - Bit 4)
> >>> LE Clear Resolving List (Octet 34 - Bit 5)
> >>> LE Read Resolving List Size (Octet 34 - Bit 6)
> >>> LE Read Peer Resolvable Address (Octet 34 - Bit 7)
> >>> LE Read Local Resolvable Address (Octet 35 - Bit 0)
> >>> LE Set Address Resolution Enable (Octet 35 - Bit 1)
> >>> LE Set Resolvable Private Address Timeout (Octet 35 - Bit 2)
> >>> LE Read Maximum Data Length (Octet 35 - Bit 3)
> >>> Octet 35 - Bit 4
> >>> Octet 35 - Bit 5
> >>> Octet 35 - Bit 6
> >>> Octet 35 - Bit 7
> >>> Octet 36 - Bit 0
> >>
> >> So you support the PHY commands, but do not indicate support LE 2M or LE Coded? Also these are Bluetooth 5.0 commands.
> >>
> >
> > To be honest. When I ported the device into Bluez core, a unexpected event for LE read local feature would cause a fail at Bluez core, so I made a hack on Bluez core
> >
> > to allow that I can keeping bring up the device without be blocked by the issue most probably from firmware.
> >
> > Below code snippet is the only thing I added to avoid a fail at Bluez core to bring up the device.
> >
> > @@ -927,6 +927,8 @@ static void hci_cc_le_read_local_features(struct hci_dev *hdev,
> > return;
> >
> > memcpy(hdev->le_features, rp->features, 8);
> > + hdev->le_features[0] = 0;
> > + hdev->le_features[1] = 0;
> > }
>
> Send me the trace where you didn?t clear the feature bits and I check what is going on. I doubt that we have a bug, but maybe some of the commands are optional and we should add an appropriate check. Or you guys need to fix your firmware. A new btmon should decode all bits properly.
>
okay, I'll have a follow-up.
> Regards
>
> Marcel
>
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: James Morse @ 2018-06-12 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpNdg=Enp66BybNNuj5tQOp3ggyX=tm_SVzr8v2qCRteDw@mail.gmail.com>
Hi Bhupesh, Ard,
On 12/06/18 09:25, Bhupesh Sharma wrote:
> On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 12 June 2018 at 08:36, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>>> The start of the linear region map on a KASLR enabled ARM64 machine -
>>> which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
>>> support), is no longer correctly represented by the PAGE_OFFSET macro,
>>> since it is defined as:
>>>
>>> (UL(1) << (VA_BITS - 1)) + 1)
>> PAGE_OFFSET is the VA of the start of the linear map. The linear map
>> can be sparsely populated with actual memory, regardless of whether
>> KASLR is in effect or not. The only difference in the presence of
>> KASLR is that there may be such a hole at the beginning, but that does
>> not mean the linear map has moved, or that the value of PAGE_OFFSET is
>> now wrong.
>>> So taking an example of a platform with VA_BITS=48, this gives a static
>>> value of:
>>> PAGE_OFFSET = 0xffff800000000000
>>>
>>> However, for the KASLR case, we use the 'memstart_offset_seed'
>>> to randomize the linear region - since 'memstart_addr' indicates the
>>> start of physical RAM, we randomize the same on basis
>>> of 'memstart_offset_seed' value.
>>>
>>> As the PAGE_OFFSET value is used presently by several user space
>>> tools (for e.g. makedumpfile and crash tools) to determine the start
>>> of linear region and hence to read addresses (like PT_NOTE fields) from
>>> '/proc/kcore' for the non-KASLR boot cases, so it would be better to
>>> use 'memblock_start_of_DRAM()' value (converted to virtual) as
>>> the start of linear region for the KASLR cases and default to
>>> the PAGE_OFFSET value for non-KASLR cases to indicate the start of
>>> linear region.
>> Userland code that assumes that the linear map cannot have a hole at
>> the beginning should be fixed.
> That is a separate case (although that needs fixing as well via a
> kernel patch probably as the user-space tools rely on '/proc/iomem'
> contents to determine the first System RAM/reserved range).
This is for kexec-tools generating the kdump vmcore ELF headers in user-space?
> 1. In that particular case (see [1]) the EFI firmware sets the first
> EFI block as EfiReservedMemType:
>
> Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
> Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]
>
> Since EFI firmware won't return the "EfiReservedMemType" memory to
> Linux kernel,
(Its linux that makes this choice in
drivers/firmware/efi/arm-init.c::is_usable_memory())
> so the kernel can't get any info about the first mem
> block, and kernel can only see region2 as below:
>
> efi: Processing EFI memory map:
> efi: 0x000000200000-0x00000021ffff [Runtime Data |RUN| | |
> | | | | |WB|WT|WC|UC]
>
> # head -1 /proc/iomem
> 00200000-0021ffff : reserved
>
> 2a. If we add debug prints to 'arch/arm64/mm/init.c' to print the
> kernel Virtual map we can see that the memory node is set to:
>
> # dmesg | grep memory
> ..........
> memory : 0xffff800000200000 - 0xffff801800000000
>
> 2b. Now if we use kexec-tools to obtain a crash vmcore we can see that
> if we use 'readelf' to get the last program Header from vmcore (logs
> below are for the non-kaslr case):
>
> # readelf -l vmcore
>
> ELF Header:
> ........................
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> ..............................................................................................................................................................
> LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
> 0x0000001680000000 0x0000001680000000 RWE 0
>
> 3. So if we do a simple calculation:
>
> (VirtAddr + MemSiz) = 0xffff80017fe00000 + 0x0000001680000000 =
> 0xFFFF8017FFE00000 != 0xffff801800000000.
>
> which indicates that the end virtual memory nodes are not the same
> between vmlinux and vmcore.
If I've followed this properly: the problem is that to generate the ELF headers
in the post-kdump vmcore, at kdump-load-time kexec-tools has to guess the
virtual addresses of the 'System RAM' regions it can see in /proc/iomem.
The problem you are hitting is an invisible hole at the beginning of RAM,
meaning user-space's guess_phys_to_virt() is off by the size of this hole.
Isn't KASLR a special case for this? You must have to correct for that after
kdump has happened, based on an elf-note in the vmcore. Can't we always do this?
> This happens because the kexec-tools rely on 'proc/iomem' contents
> while 'memstart_addr' is computed as 0 by kernel (as value of
> memblock_start_of_DRAM() < ARM64_MEMSTART_ALIGN).
> Returning back to this patch, this is a generic requirement where we
> need the linear region start/base addresses in user-space applications
> which is used to read addresses which lie in the linear region (for
> e.g. when we read /proc/kcore contents).
>>> I tested this on my qualcomm (which supports EFI_RNG_PROTOCOL)
>>> and apm mustang (which does not support EFI_RNG_PROTOCOL) arm64 boards
>>> and was able to use a modified user space utility (like kexec-tools and
>>> makedumpfile) to determine the start of linear region correctly for
>>> both the KASLR and non-KASLR boot cases.
>>>
>>
>> Can you explain the nature of the changes to the userland code?
>
> The changes are not to rely on the fixed PAGE_OFFSET macro value for
> determining the base address of the linear region, but rather read the
> ' linear_reg_start_addr' symbol from kernel and use the same both in
> case of KASLR and non-KASLR boots to determine the base of the linear
> region (in [2], I have implemented a test change to kexec-tools to
> read the 'linear_reg_start_addr' symbol which is available on my
Don't use /dev/mem.
> public github tree, I have a similar change available in makedumpfile
> which I have not yet pushed to github, as it implements other features
> as well)
>>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>>> index 49d99214f43c..bfd0915ecaf8 100644
>>> --- a/arch/arm64/include/asm/memory.h
>>> +++ b/arch/arm64/include/asm/memory.h
>>> @@ -178,6 +178,9 @@ extern s64 memstart_addr;
>>> /* PHYS_OFFSET - the physical address of the start of memory. */
>>> #define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
>>>
>>> +/* the virtual base of the linear region. */
>>> +extern s64 linear_reg_start_addr;
>>> +
>>> /* the virtual base of the kernel image (minus TEXT_OFFSET) */
>>> extern u64 kimage_vaddr;
>>>
>>> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
>>> index d894a20b70b2..a92238ea45ff 100644
>>> --- a/arch/arm64/kernel/arm64ksyms.c
>>> +++ b/arch/arm64/kernel/arm64ksyms.c
>>> @@ -42,6 +42,7 @@ EXPORT_SYMBOL(__arch_copy_in_user);
>>>
>>> /* physical memory */
>>> EXPORT_SYMBOL(memstart_addr);
>>> +EXPORT_SYMBOL(linear_reg_start_addr);
>>>
>>> /* string / mem functions */
>>> EXPORT_SYMBOL(strchr);
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 325cfb3b858a..29447adb0eef 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -60,6 +60,7 @@
>>> * that cannot be mistaken for a real physical address.
>>> */
>>> s64 memstart_addr __ro_after_init = -1;
>>> +s64 linear_reg_start_addr __ro_after_init = PAGE_OFFSET;
>>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>
>>> #ifdef CONFIG_BLK_DEV_INITRD
>>> @@ -452,6 +453,8 @@ void __init arm64_memblock_init(void)
>>> }
>>> }
>>>
>>> + linear_reg_start_addr = __phys_to_virt(memblock_start_of_DRAM());
This patch adds a variable that nothing uses, its going to be removed. You can't
depend on reading this via /dev/mem.
Could you add the information you need as an elf-note to the vmcore instead? You
must already pick these up to handle kaslr. (from memory, this is where the
kaslr-offset is described to user-space after we kdump).
Thanks,
James
^ permalink raw reply
* [PATCH 0/4] Fix suspend resume on at91sam9261 and at91sam9263
From: Nicolas Ferre @ 2018-06-12 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607084107.4461-1-alexandre.belloni@bootlin.com>
On 07/06/2018 at 10:41, Alexandre Belloni wrote:
> USB clock detection may not work properly on at91sam9261 and at91sam9263
> because they currently use the same bit mask as at91rm9200 instead of
> the one for at91sam9260.
>
> Take the opportunity to also change the PMC compatible strings for all
> the other SoCs in preparation for the new clock bindings.
>
> Alexandre Belloni (4):
> dt-bindings: arm: remove PMC bindings
> dt-bindings: clk: at91: Document all the PMC compatibles
> ARM: at91: fix USB clock detection handling
> ARM: dts: fix PMC compatible
To the whole series:
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Thanks, best regards.
> .../devicetree/bindings/arm/atmel-pmc.txt | 14 --------------
> .../devicetree/bindings/clock/at91-clock.txt | 9 ++++-----
> arch/arm/boot/dts/at91sam9261.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9rl.dtsi | 2 +-
> arch/arm/boot/dts/sama5d4.dtsi | 2 +-
> arch/arm/mach-at91/pm.c | 5 +++++
> 7 files changed, 13 insertions(+), 23 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/atmel-pmc.txt
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 10/20] dts: juno: Update coresight bindings for hw port
From: Sudeep Holla @ 2018-06-12 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkxNakRGCWT6O0JRKz+N1OTU3-XreC_FiB8Fiv+jEoPEbQ@mail.gmail.com>
On Fri, Jun 08, 2018 at 03:52:58PM -0600, Mathieu Poirier wrote:
> On 8 June 2018 at 15:49, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> > On Tue, Jun 05, 2018 at 10:43:21PM +0100, Suzuki K Poulose wrote:
> >> Switch to updated coresight bindings for hw ports.
> >>
> >> Cc: Sudeep Holla <sudeep.holla@arm.com>
> >> Cc: Liviu Dudau <liviu.dudau@arm.com>
> >> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> >> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >> ---
> >> Changes since V1:
> >> - Add support Juno for r1 & r2.
> >> ---
> >
> > Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Sudeep please hold on before applying this as there is more work to be
> done on this set.
>
Sure, I plan to apply the DT changes only after the driver changes are
queued by you or whichever tree it's channelled through. I was already
told the same to Suzuki.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] pwm: stm32: fix build warning with CONFIG_DMA_ENGINE disabled
From: Arnd Bergmann @ 2018-06-12 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXJg0mYbs=e0QJMDb=A+bRbPsNF=TJzSumSjjOK3yJw2Q@mail.gmail.com>
On Tue, Jun 12, 2018 at 9:25 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>> --- a/drivers/pwm/pwm-stm32.c
>> +++ b/drivers/pwm/pwm-stm32.c
>> @@ -484,9 +484,7 @@ static int stm32_pwm_apply_locked(struct pwm_chip *chip, struct pwm_device *pwm,
>> static const struct pwm_ops stm32pwm_ops = {
>> .owner = THIS_MODULE,
>> .apply = stm32_pwm_apply_locked,
>> -#if IS_ENABLED(CONFIG_DMA_ENGINE)
>> - .capture = stm32_pwm_capture,
>> -#endif
>> + .capture = IS_ENABLED(CONFIG_DMA_ENGINE) ? stm32_pwm_capture : NULL,
>
> Cool, I didn't know IS_ENABLED() can be used in static initializers.
> I guess it's too late/much work to use this trick in e.g. SET_*_PM_OPS(),
> as there are lots of places protecting the functions by #ifdefs?
It's one of those things I've been planning to do for a long time, but as
you noticed, we can't just change the macro but have to come up with a
replacement that works without those #ifdefs. Unfortunately, nobody has
come up with a good /name/ for those macros, which is still the main blocker ;-)
Arnd
^ permalink raw reply
* [PATCH v2 0/5] thermal: tsens: Prepare for version 2 of TSENS IP
From: Amit Kucheria @ 2018-06-12 10:54 UTC (permalink / raw)
To: linux-arm-kernel
This series is a mixed bag: Some code moves to deal with version 2 of the
TSENS IP in common functions, new platform support (sdm845), a cleanup
patch and a DT change to have a common way to deal with the SROT and TM
registers despite slightly different features across the IP family and
different register offsets.
I can merge the tsens-8996.c and tsens-sdm845.c files into a tsens-v2.c if
desired.
Changes since v1:
- Move get_temp() from tsens-8996 to tsens-common and rename
- Change 8996 DT entry to allow init_common() to work across sdm845 and
8996 due to different offsets
Amit Kucheria (5):
thermal: tsens: Get rid of unused fields in structure
dt: qcom: 8996: thermal: Move to DT initialisation
thermal: tsens: Move 8996 get_temp() to common code for reuse
thermal: tsens: Add support for SDM845
thermal: tsens: Check if we have valid data before reading
.../devicetree/bindings/thermal/qcom-tsens.txt | 1 +
arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 +++-
drivers/thermal/qcom/Makefile | 2 +-
drivers/thermal/qcom/tsens-8996.c | 74 +-------------------
drivers/thermal/qcom/tsens-common.c | 78 +++++++++++++++++++---
drivers/thermal/qcom/tsens-sdm845.c | 15 +++++
drivers/thermal/qcom/tsens.c | 3 +
drivers/thermal/qcom/tsens.h | 8 ++-
8 files changed, 107 insertions(+), 86 deletions(-)
create mode 100644 drivers/thermal/qcom/tsens-sdm845.c
--
2.7.4
^ permalink raw reply
* [PATCH v2 2/5] dt: qcom: 8996: thermal: Move to DT initialisation
From: Amit Kucheria @ 2018-06-12 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528799892.git.amit.kucheria@linaro.org>
We also split up the regmap address space into two, one for the TM
registers, the other for the SROT registers. This was required to deal with
different address offsets for the TM and SROT registers across different
SoC families.
Since tsens-common.c/init_common() currently only registers one address space, the order is important (TM before SROT).This is OK since the code doesn't really use the SROT functionality yet.
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 +++++++++++-
drivers/thermal/qcom/tsens-8996.c | 1 -
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 410ae78..b4aab18 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -451,7 +451,17 @@
tsens0: thermal-sensor at 4a8000 {
compatible = "qcom,msm8996-tsens";
- reg = <0x4a8000 0x2000>;
+ reg = <0x4a9000 0x1000>, /* TM */
+ <0x4a8000 0x1000>; /* SROT */
+ #qcom,sensors = <13>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ tsens1: thermal-sensor at 4ac000 {
+ compatible = "qcom,msm8996-tsens";
+ reg = <0x4ad000 0x1000>, /* TM */
+ <0x4ac000 0x1000>; /* SROT */
+ #qcom,sensors = <8>;
#thermal-sensor-cells = <1>;
};
diff --git a/drivers/thermal/qcom/tsens-8996.c b/drivers/thermal/qcom/tsens-8996.c
index e1f7781..6e59078 100644
--- a/drivers/thermal/qcom/tsens-8996.c
+++ b/drivers/thermal/qcom/tsens-8996.c
@@ -79,6 +79,5 @@ static const struct tsens_ops ops_8996 = {
};
const struct tsens_data data_8996 = {
- .num_sensors = 13,
.ops = &ops_8996,
};
--
2.7.4
^ permalink raw reply related
* [GIT PULL 2/4] ARM: Device-tree updates
From: Kalle Valo @ 2018-06-12 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612000142.28883-3-olof@lixom.net>
Olof Johansson <olof@lixom.net> writes:
> - Qualcomm:
> + SDM845, a.k.a Snapdragon 845, an 4+4-core Kryo 385/845
> (Cortex-A75/A55 derivative) SoC that's one of the current high-end
> mobile SoCs.
>
> It's great to see mainline support for it. So far, you
> can't do much with it, since a lot of peripherals are not yet in the
> DTs but driver support for USB, GPU and other pieces are starting to
> trickle in. This might end up being a well-supported SoC upstream if
> the momentum keeps up.
The wifi chip is called wcn3990 and we are working on supporting that in
ath10k. I'm hoping to get it ready for v4.19.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag
From: Marek Szyprowski @ 2018-06-12 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20180612110857eucas1p1f5e3b6d984d4fd7e3b3ce31418df546e@eucas1p1.samsung.com>
dma_alloc_*() buffers might be exposed to userspace via mmap() call, so
they should be cleared on allocation. In case of IOMMU-based dma-mapping
implementation such buffer clearing was missing in the code path for
DMA_ATTR_FORCE_CONTIGUOUS flag handling, because dma_alloc_from_contiguous()
doesn't honor __GFP_ZERO flag. This patch fixes this issue. For more
information on clearing buffers allocated by dma_alloc_* functions,
see commit 6829e274a623 ("arm64: dma-mapping: always clear allocated
buffers").
Fixes: 44176bb38fa4 ("arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
v2:
- fixed incorrect commit id in commit body (thanks to Geert)
- extended description with information that dma_alloc_from_contiguous()
lacks __GFP_ZERO support
---
arch/arm64/mm/dma-mapping.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 632d32109755..aa0037a3185f 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -629,13 +629,14 @@ static void *__iommu_alloc_attrs(struct device *dev, size_t size,
size >> PAGE_SHIFT);
return NULL;
}
- if (!coherent)
- __dma_flush_area(page_to_virt(page), iosize);
-
addr = dma_common_contiguous_remap(page, size, VM_USERMAP,
prot,
__builtin_return_address(0));
- if (!addr) {
+ if (addr) {
+ memset(addr, 0, size);
+ if (!coherent)
+ __dma_flush_area(page_to_virt(page), iosize);
+ } else {
iommu_dma_unmap_page(dev, *handle, iosize, 0, attrs);
dma_release_from_contiguous(dev, page,
size >> PAGE_SHIFT);
--
2.17.1
^ permalink raw reply related
* [PATCH v2] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P
From: Lukasz Majewski @ 2018-06-12 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611051357.GA16091@dragon>
Hi Shawn,
Thanks for you review.
> On Sat, May 19, 2018 at 02:15:06PM +0200, Lukasz Majewski wrote:
> > This commit provides support for HSC and DDC boards from
> > Kieback&Peter GmbH vendor.
> >
> > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > ---
> > Changes for v2:
> >
> > - Remove not needed #address-cells and #size-cells in
> > the gpio_buttons node to pass make W=1
> > - Rename button@{12} to button_{kalt|pwr} nodes to pass make W=1
> > - Include #include <dt-bindings/input/input.h> to use KEY_F6|F7
> > directly
> >
> > ---
> > arch/arm/boot/dts/Makefile | 2 +
> > arch/arm/boot/dts/imx53-kp-ddc.dts | 146
> > ++++++++++++++++++++++++++++ arch/arm/boot/dts/imx53-kp-hsc.dts |
> > 51 ++++++++++ arch/arm/boot/dts/imx53-kp.dtsi | 190
> > +++++++++++++++++++++++++++++++++++++ 4 files changed, 389
> > insertions(+) create mode 100644 arch/arm/boot/dts/imx53-kp-ddc.dts
> > create mode 100644 arch/arm/boot/dts/imx53-kp-hsc.dts
> > create mode 100644 arch/arm/boot/dts/imx53-kp.dtsi
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index fbc04b0db781..00854a5b6ac4 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -360,6 +360,8 @@ dtb-$(CONFIG_SOC_IMX51) += \
> > dtb-$(CONFIG_SOC_IMX53) += \
> > imx53-ard.dtb \
> > imx53-cx9020.dtb \
> > + imx53-kp-ddc.dtb \
> > + imx53-kp-hsc.dtb \
> > imx53-m53evk.dtb \
> > imx53-mba53.dtb \
> > imx53-ppd.dtb \
> > diff --git a/arch/arm/boot/dts/imx53-kp-ddc.dts
> > b/arch/arm/boot/dts/imx53-kp-ddc.dts new file mode 100644
> > index 000000000000..acaf477a52c5
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx53-kp-ddc.dts
> > @@ -0,0 +1,146 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2018
> > + * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
> > + */
> > +
> > +/dts-v1/;
> > +#include "imx53-kp.dtsi"
> > +
> > +/ {
> > + model = "K+P imx53 DDC";
> > + compatible = "kiebackpeter,imx53-ddc", "fsl,imx53";
> > +
> > + backlight_lcd: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&pwm2 0 50000>;
> > + power-supply = <®_backlight>;
> > + brightness-levels = <0 24 28 32 36
> > + 40 44 48 52 56
> > + 60 64 68 72 76
> > + 80 84 88 92 96 100>;
> > + default-brightness-level = <20>;
> > + };
> > +
> > + lcd_display: disp1 {
>
> display for node node.
I assume that I shall change disp1 -> display ?
>
> > + compatible = "fsl,imx-parallel-display";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + interface-pix-fmt = "rgb24";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_disp>;
> > +
> > + port at 0 {
> > + reg = <0>;
> > +
> > + display1_in: endpoint {
> > + remote-endpoint = <&ipu_di1_disp1>;
> > + };
> > + };
> > +
> > + port at 1 {
> > + reg = <1>;
> > +
> > + lcd_display_out: endpoint {
> > + remote-endpoint = <&lcd_panel_in>;
> > + };
> > + };
> > + };
> > +
> > + lcd_panel: lcd-panel {
> > + compatible = "koe,tx14d24vm1bpa";
>
> Undefined compatible?
The display's in question "koe,tx14d24vm1bpa" compatible has been
ack'ed by Rob Herring and Thierry promised to apply it to his tree:
https://patchwork.kernel.org/patch/10391589/
The v2 of this patch:
https://patchwork.kernel.org/patch/10436007/
>
> > + backlight = <&backlight_lcd>;
> > + power-supply = <®_3v3>;
> > +
> > + port {
> > + lcd_panel_in: endpoint {
> > + remote-endpoint =
> > <&lcd_display_out>;
> > + };
> > + };
> > + };
> > +
> > + reg_backlight: regulator-backlight {
> > + compatible = "regulator-fixed";
> > + regulator-name = "backlight-supply";
> > + regulator-min-microvolt = <15000000>;
> > + regulator-max-microvolt = <15000000>;
> > + regulator-always-on;
> > + };
> > +};
> > +
> > +&i2c3 {
> > + adc at 48 {
> > + compatible = "ti,ads1015";
> > + reg = <0x48>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + channel at 4 {
> > + reg = <4>;
> > + ti,gain = <2>;
> > + ti,datarate = <4>;
> > + };
> > +
> > + channel at 6 {
> > + reg = <6>;
> > + ti,gain = <2>;
> > + ti,datarate = <4>;
> > + };
> > + };
> > +
> > + gpio_expander2 at 21 {
>
> Use hyphen instead of underscore in node name.
Ok. I will change this globally. And send v3.
>
> > + compatible = "nxp,pcf8574";
> > + reg = <0x21>;
> > + interrupts = <109>;
> > + #gpio-cells = <2>;
> > + gpio-controller;
> > + };
> > +};
> > +
> > +&iomuxc {
> > + imx53-kp-ddc {
> > + pinctrl_disp: dispgrp {
> > + fsl,pins = <
> > +
> > MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK 0x4
> > +
> > MX53_PAD_EIM_DA10__IPU_DI1_PIN15 0x4
> > +
> > MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0 0x4
> > +
> > MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1 0x4
> > +
> > MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2 0x4
> > +
> > MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3 0x4
> > +
> > MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4 0x4
> > +
> > MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5 0x4
> > +
> > MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6 0x4
> > +
> > MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7 0x4
> > +
> > MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8 0x4
> > +
> > MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9 0x4
> > +
> > MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10 0x4
> > +
> > MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11 0x4
> > +
> > MX53_PAD_EIM_A17__IPU_DISP1_DAT_12 0x4
> > +
> > MX53_PAD_EIM_A18__IPU_DISP1_DAT_13 0x4
> > +
> > MX53_PAD_EIM_A19__IPU_DISP1_DAT_14 0x4
> > +
> > MX53_PAD_EIM_A20__IPU_DISP1_DAT_15 0x4
> > +
> > MX53_PAD_EIM_A21__IPU_DISP1_DAT_16 0x4
> > +
> > MX53_PAD_EIM_A22__IPU_DISP1_DAT_17 0x4
> > +
> > MX53_PAD_EIM_A23__IPU_DISP1_DAT_18 0x4
> > +
> > MX53_PAD_EIM_A24__IPU_DISP1_DAT_19 0x4
> > +
> > MX53_PAD_EIM_D31__IPU_DISP1_DAT_20 0x4
> > +
> > MX53_PAD_EIM_D30__IPU_DISP1_DAT_21 0x4
> > +
> > MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 0x4
> > +
> > MX53_PAD_EIM_D27__IPU_DISP1_DAT_23 0x4
> > + MX53_PAD_GPIO_1__PWM2_PWMO 0x4
> > + >;
> > + };
> > + };
> > +};
> > +
> > +&ipu_di1_disp1 {
> > + remote-endpoint = <&display1_in>;
> > +};
> > +
> > +&fec {
> > + status = "okay";
> > +};
>
> Sort the labeled nodes alphabetically in label name.
>
> > +
> > +&pmic {
> > + fsl,mc13xxx-uses-touch;
> > +};
> > diff --git a/arch/arm/boot/dts/imx53-kp-hsc.dts
> > b/arch/arm/boot/dts/imx53-kp-hsc.dts new file mode 100644
> > index 000000000000..d68cdd5da819
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx53-kp-hsc.dts
> > @@ -0,0 +1,51 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2018
> > + * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
> > + */
> > +
> > +/dts-v1/;
> > +#include "imx53-kp.dtsi"
> > +
> > +/ {
> > + model = "K+P imx53 HSC";
> > + compatible = "kiebackpeter,imx53-hsc", "fsl,imx53";
> > +};
> > +
> > +&fec {
> > + status = "okay";
>
> Have a newline between property list and child node.
>
> > + fixed-link { /* RMII fixed link to LAN9303 */
> > + speed = <100>;
> > + full-duplex;
> > + };
> > +};
> > +
> > +&i2c3 {
> > + switch: switch at a {
> > + compatible = "smsc,lan9303-i2c";
> > + reg = <0xa>;
> > + reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
> > + reset-duration = <400>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 { /* RMII fixed link to master */
> > + reg = <0>;
> > + label = "cpu";
> > + ethernet = <&fec>;
> > + };
> > +
> > + port at 1 { /* external port 1 */
> > + reg = <1>;
> > + label = "lan1";
> > + };
> > +
> > + port at 2 { /* external port 2 */
> > + reg = <2>;
> > + label = "lan2";
> > + };
> > + };
> > + };
> > +};
> > diff --git a/arch/arm/boot/dts/imx53-kp.dtsi
> > b/arch/arm/boot/dts/imx53-kp.dtsi new file mode 100644
> > index 000000000000..f87266843842
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx53-kp.dtsi
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2018
> > + * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
> > + */
> > +
> > +/dts-v1/;
> > +#include "imx53-tqma53.dtsi"
> > +#include <dt-bindings/input/input.h>
> > +
> > +/ {
> > + buzzer {
> > + compatible = "pwm-beeper";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_buzzer>;
> > +
>
> Drop this newline.
>
> > + pwms = <&pwm1 0 500000>;
> > + };
> > +
> > + gpio_buttons {
>
> Use hyphen.
>
> > + compatible = "gpio-keys";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpiobuttons>;
> > +
> > + button_kalt {
>
> Ditto
>
> > + label = "Kaltstart";
> > + linux,code = <KEY_F6>;
> > + gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
> > + };
> > +
> > + button_pwr {
>
> Ditto
>
> > + label = "PowerFailInterrupt";
> > + linux,code = <KEY_F7>;
> > + gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
> > + };
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_leds>;
> > +
> > + led_bus {
>
> Ditto
>
> > + label = "bus";
> > + gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "gpio";
> > + default-state = "off";
> > + };
> > +
> > + led_error {
>
> Ditto
>
> > + label = "error";
> > + gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "gpio";
> > + default-state = "off";
> > + };
> > +
> > + led_flash {
>
> Ditto
>
> > + label = "flash";
> > + gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "heartbeat";
> > + };
> > + };
> > +
> > + reg_3v3: regulator-3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "3V3";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-always-on;
> > + };
> > +};
> > +
> > +&can1 {
> > + status = "okay";
> > +};
> > +
> > +&can2 {
> > + status = "okay";
> > +};
> > +
> > +&i2c3 {
> > + status = "okay";
> > +
> > + gpio_expander1 at 22 {
>
> Ditto
>
> Shawn
>
> > + compatible = "nxp,pcf8574";
> > + reg = <0x22>;
> > + interrupts = <109>;
> > + #gpio-cells = <2>;
> > + gpio-controller;
> > + };
> > +
> > + rtc at 51 {
> > + compatible = "nxp,pcf8563";
> > + reg = <0x51>;
> > + };
> > +};
> > +
> > +&iomuxc {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_kp_common>;
> > +
> > + imx53-kp-common {
> > + pinctrl_buzzer: buzzergrp {
> > + fsl,pins = <
> > + MX53_PAD_SD1_DATA3__PWM1_PWMO 0x1e4
> > + >;
> > + };
> > +
> > + pinctrl_gpiobuttons: gpiobuttonsgrp {
> > + fsl,pins = <
> > + MX53_PAD_EIM_RW__GPIO2_26 0x1e4
> > + MX53_PAD_EIM_D22__GPIO3_22 0x1e4
> > + >;
> > + };
> > +
> > + pinctrl_kp_common: kpcommongrp {
> > + fsl,pins = <
> > + MX53_PAD_EIM_CS0__GPIO2_23 0x1e4
> > + MX53_PAD_GPIO_19__GPIO4_5 0x1e4
> > + MX53_PAD_PATA_DATA6__GPIO2_6 0x1e4
> > + MX53_PAD_PATA_DATA7__GPIO2_7 0xe0
> > + MX53_PAD_CSI0_DAT14__GPIO6_0 0x1e4
> > + MX53_PAD_CSI0_DAT16__GPIO6_2 0x1e4
> > + MX53_PAD_CSI0_DAT18__GPIO6_4 0x1e4
> > + MX53_PAD_EIM_D17__GPIO3_17 0x1e4
> > + MX53_PAD_EIM_D18__GPIO3_18 0x1e4
> > + MX53_PAD_EIM_D21__GPIO3_21 0x1e4
> > + MX53_PAD_EIM_D29__GPIO3_29 0x1e4
> > + MX53_PAD_EIM_DA11__GPIO3_11 0x1e4
> > + MX53_PAD_EIM_DA13__GPIO3_13 0x1e4
> > + MX53_PAD_EIM_DA14__GPIO3_14 0x1e4
> > + MX53_PAD_SD1_DATA0__GPIO1_16 0x1e4
> > + MX53_PAD_SD1_CMD__GPIO1_18 0x1e4
> > + MX53_PAD_SD1_CLK__GPIO1_20 0x1e4
> > + >;
> > + };
> > +
> > + pinctrl_leds: ledgrp {
> > + fsl,pins = <
> > + MX53_PAD_EIM_EB2__GPIO2_30 0x1d4
> > + MX53_PAD_EIM_D28__GPIO3_28 0x1d4
> > + MX53_PAD_EIM_WAIT__GPIO5_0 0x1d4
> > + >;
> > + };
> > +
> > + pinctrl_uart4: uart4grp {
> > + fsl,pins = <
> > + MX53_PAD_CSI0_DAT12__UART4_TXD_MUX
> > 0x1e4
> > + MX53_PAD_CSI0_DAT13__UART4_RXD_MUX
> > 0x1e4
> > + >;
> > + };
> > + };
> > +};
> > +
> > +&pinctrl_uart1 {
> > + fsl,pins = <
> > + MX53_PAD_EIM_D23__GPIO3_23 0x1e4
> > + MX53_PAD_EIM_EB3__GPIO2_31 0x1e4
> > + MX53_PAD_EIM_D24__GPIO3_24 0x1e4
> > + MX53_PAD_EIM_D25__GPIO3_25 0x1e4
> > + MX53_PAD_EIM_D19__GPIO3_19 0x1e4
> > + MX53_PAD_EIM_D20__GPIO3_20 0x1e4
> > + >;
> > +};
> > +
> > +&uart1 {
> > + status = "okay";
> > +};
> > +
> > +&uart2 {
> > + status = "okay";
> > +};
> > +
> > +&uart3 {
> > + status = "okay";
> > +};
> > +
> > +&uart4 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart4>;
> > + status = "okay";
> > +};
> > +
> > +&usbh1 {
> > + status = "okay";
> > +};
> > +
> > +&usbphy0 {
> > + status = "disabled";
> > +};
> > --
> > 2.11.0
> >
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180612/dbdb4b81/attachment-0001.sig>
^ permalink raw reply
* handling voice calls in ALSA soc (on Droid 4)
From: Pavel Machek @ 2018-06-12 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611121548.GB11580@sirena.org.uk>
Hi!
Sebastian, would you have pointer to original Motorola sources you
used for inspiration?
> > With setup like that, how does userland tell kernel that the baseband
> > <-> microphone/speaker connection should be activated?
>
> Audio routing should be done as normal, and ideally the driver for the
> modem will be able to figure out if there's an active call or not. If
> userspace has to enable the input and output manually then you can set
> up SOC_DAPM_PIN_SWITCH()es as normal.
Modem talks AT commands, so the driver is in userspace for now.
I tried SOC_DAPM_PIN_SWITCH(), but it results in alsamixer oopsing, I
guess I'm doing something wrong.
Message from syslogd at devuan at Jun 12 13:51:31 ...
kernel:[ 743.678588] BUG: spinlock bad magic on CPU#1,
alsamixer/2217
Message from syslogd at devuan at Jun 12 13:51:31 ...
kernel:[ 743.684417] lock: 0xede423a0, .magic: eee2a6a4, .owner:
<none>/-1, .owner_cpu: -287136604
I'm trying to understand how it is supposed to work, but
https://www.alsa-project.org/main/index.php/DAPM has TODO's at
critical places. If there's better source of information, let me know.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180612/2a174be2/attachment.sig>
^ 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