* [PATCH v2 2/9] dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation
From: Rob Herring @ 2017-12-20 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-3-f.fainelli@gmail.com>
On Tue, Dec 19, 2017 at 11:22:40AM -0800, Florian Fainelli wrote:
> Correct the Device Tree bindings for the HIF_CPUBIUCTRL node whose
> compatible string is actually brcm,bcm<chip-id>-cpu-biu-ctrl. Also
> document in the binding the fallback property
> ("brcm,brcmstb-cpu-biu-ctrl") and update the example accordingly.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> .../devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 22 ++++++++++++----------
> 1 file changed, 12 insertions(+), 10 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Rob Herring @ 2017-12-20 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0d8147a-46e1-0787-ae37-9c1ef957d190@codeaurora.org>
On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:
> Hi Viresh,
>
> On 12/20/2017 8:56 AM, Viresh Kumar wrote:
> > On 19-12-17, 21:25, Sricharan R wrote:
> >> + cpu at 0 {
> >> + compatible = "qcom,krait";
> >> + enable-method = "qcom,kpss-acc-v1";
> >> + device_type = "cpu";
> >> + reg = <0>;
> >> + qcom,acc = <&acc0>;
> >> + qcom,saw = <&saw0>;
> >> + clocks = <&kraitcc 0>;
> >> + clock-names = "cpu";
> >> + cpu-supply = <&smb208_s2a>;
> >> + operating-points-v2 = <&cpu_opp_table>;
> >> + };
> >> +
> >> + qcom,pvs {
> >> + qcom,pvs-format-a;
> >> + };
> >
> > Not sure what Rob is going to say on that :)
> >
>
> Yes. Would be good to know the best way.
Seems like this should be a property of an efuse node either implied by
the compatible or a separate property. What determines format A vs. B?
Rob
^ permalink raw reply
* [PATCH v5 12/15] devicetree: bindings: Document qcom,krait-cc
From: Rob Herring @ 2017-12-20 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513698900-10638-13-git-send-email-sricharan@codeaurora.org>
On Tue, Dec 19, 2017 at 09:24:57PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> The Krait clock controller controls the krait CPU and the L2 clocks
> consisting a primary mux and secondary mux. Add document for that.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/clock/qcom,krait-cc.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 10/15] devicetree: bindings: Document qcom,kpss-gcc
From: Rob Herring @ 2017-12-20 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513698900-10638-11-git-send-email-sricharan@codeaurora.org>
On Tue, Dec 19, 2017 at 09:24:55PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> The ACC and GCC regions present in KPSSv1 contain registers to
> control clocks and power to each Krait CPU and L2. Documenting
> the bindings here.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 7 +++++
> .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt | 32 ++++++++++++++++++++++
> 2 files changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 05/15] devicetree: bindings: Document qcom,hfpll
From: Rob Herring @ 2017-12-20 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513698900-10638-6-git-send-email-sricharan@codeaurora.org>
On Tue, Dec 19, 2017 at 09:24:50PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> Adds bindings document for qcom,hfpll instantiated within
> the Krait processor subsystem as separate register region.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/clock/qcom,hfpll.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
"dt-bindings: " is the preferred subject prefix. Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Rob Herring @ 2017-12-20 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219135719.9531-2-miquel.raynal@free-electrons.com>
On Tue, Dec 19, 2017 at 02:57:09PM +0100, Miquel Raynal wrote:
> From: Baruch Siach <baruch@tkos.co.il>
>
> Add compatible strings for AP806 and CP110 that are part of the Armada
> 8k/7k line of SoCs.
>
> Add a note on the differences in the size of the control area in
> different bindings. This is an existing difference between the Armada
> 375 binding and the other boards already supported. The new AP806 and
> CP110 bindings are similar to the existing Armada 375 in this regard.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> [<miquel.raynal@free-electrons.com>: reword, additional details]
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> .../devicetree/bindings/thermal/armada-thermal.txt | 37 +++++++++++++++-------
> 1 file changed, 25 insertions(+), 12 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 4/5] dt-bindings: mtd: remove pxa3xx NAND controller documentation
From: Rob Herring @ 2017-12-20 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219132942.27433-5-miquel.raynal@free-electrons.com>
On Tue, Dec 19, 2017 at 02:29:41PM +0100, Miquel Raynal wrote:
> The deprecated pxa3xx_nand.c driver does not exist anymore, it has been
> replaced by marvell_nand.c which has its own up-to-date documentation.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> .../devicetree/bindings/mtd/pxa3xx-nand.txt | 50 ----------------------
> 1 file changed, 50 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: mtd: add Marvell NAND controller documentation
From: Rob Herring @ 2017-12-20 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219132942.27433-2-miquel.raynal@free-electrons.com>
On Tue, Dec 19, 2017 at 02:29:38PM +0100, Miquel Raynal wrote:
> Document the legacy and the new bindings for Marvell NAND controller.
>
> The pxa3xx_nand.c driver does only support legacy bindings, which are
> incomplete and inaccurate. A rework of this controller (called
> marvell_nand.c) does support both.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> .../devicetree/bindings/mtd/marvell-nand.txt | 123 +++++++++++++++++++++
> 1 file changed, 123 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/marvell-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/marvell-nand.txt b/Documentation/devicetree/bindings/mtd/marvell-nand.txt
> new file mode 100644
> index 000000000000..aa6a1ed045b2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/marvell-nand.txt
> @@ -0,0 +1,123 @@
> +Marvell NAND Flash Controller (NFC)
> +
> +Required properties:
> +- compatible: can be one of the following:
> + * "marvell,armada-8k-nand-controller"
> + * "marvell,armada370-nand-controller"
> + * "marvell,pxa3xx-nand-controller"
> + * "marvell,armada-8k-nand" (deprecated)
> + * "marvell,armada370-nand" (deprecated)
> + * "marvell,pxa3xx-nand" (deprecated)
> + Compatibles marked deprecated support only the old bindings described
> + at the bottom.
> +- reg: NAND flash controller memory area.
> +- #address-cells: shall be set to 1. Encode the NAND CS.
> +- #size-cells: shall be set to 0.
> +- interrupts: shall define the NAND controller interrupt.
> +- clocks: shall reference the NAND controller clock.
> +- marvell,system-controller: Set to retrieve the syscon node that handles
> + NAND controller related registers (only required with the
> + "marvell,armada-8k-nand[-controller]" compatibles).
> +
> +Optional properties:
> +- label: see partition.txt. New platforms shall omit this property.
> +- dmas: shall reference DMA channel associated to the NAND controller.
> + This property is only used with "marvell,pxa3xx-nand[-controller]"
> + compatible strings.
> +- dma-names: shall be "rxtx".
> + This property is only used with "marvell,pxa3xx-nand[-controller]"
> + compatible strings.
> +
> +Optional children nodes:
> +Children nodes represent the available NAND chips.
> +
> +Required properties:
> +- reg: shall contain the native Chip Select ids (0-3)
> +- marvell,rb: shall contain the native Ready/Busy ids (0-1)
We already have at least 2 other <vendor>,rb properties. Let's not add a
3rd and make a common one instead.
> +
> +Optional properties:
> +- marvell,nand-keep-config: orders the driver not to take the timings
> + from the core and leaving them completely untouched. Bootloader
> + timings will then be used.
> +- label: MTD name.
> +- nand-on-flash-bbt: see nand.txt.
> +- nand-ecc-mode: see nand.txt. Will use hardware ECC if not specified.
> +- nand-ecc-algo: see nand.txt. This property may be added when using
> + hardware ECC for clarification but will be ignored by the driver
> + because ECC mode is chosen depending on the page size and the strength
> + required by the NAND chip. This value may be overwritten with
> + nand-ecc-strength property.
If not used, then drop it.
> +- nand-ecc-strength: see nand.txt.
> +- nand-ecc-step-size: see nand.txt. This has no effect and will be
> + ignored by the driver when using hardware ECC because Marvell's NAND
> + flash controller does use fixed strength (1-bit for Hamming, 16-bit
> + for BCH), so the step size will shrink or grow in order to fit the
> + required strength. Step sizes are not completely random for all and
> + follow certain patterns described in AN-379, "Marvell SoC NFC ECC".
Same here.
> +
> +See Documentation/devicetree/bindings/mtd/nand.txt for more details on
> +generic bindings.
> +
> +
> +Example:
> +nand_controller: nand-controller at d0000 {
> + compatible = "marvell,armada370-nand-controller";
> + reg = <0xd0000 0x54>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&coredivclk 0>;
> +
> + nand at 0 {
> + reg = <0>;
> + label = "main-storage";
> + marvell,rb = <0>;
> + nand-ecc-mode = "hw";
> + marvell,nand-keep-config;
> + nand-on-flash-bbt;
> + nand-ecc-strength = <4>;
> + nand-ecc-step-size = <512>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition at 0 {
> + label = "Rootfs";
> + reg = <0x00000000 0x40000000>;
> + };
> + };
> + };
> +};
> +
> +
> +Note on legacy bindings: One can find, in not-updated device trees,
> +bindings slightly differents than described above with other properties
s/differents/different/
> +described below as well as the partitions node at the root of a so
> +called "nand" node (without clear controller/chip separation).
> +
> +Legacy properties:
> +- marvell,nand-enable-arbiter: To enable the arbiter, all boards blindly
> + used it, this bit was set by the bootloader for many boards and even if
> + it is marked reserved in several datasheets, it might be needed to set
> + it (otherwise it is harmless) so whether or not this property is set,
> + the bit is selected by the driver.
> +- num-cs: Number of chip-select lines to use, all boards blindly set 1
> + to this and for a reason, other values would have failed. The value of
> + this property is ignored.
> +
> +Example:
> +
> + nand0: nand at 43100000 {
> + compatible = "marvell,pxa3xx-nand";
> + reg = <0x43100000 90>;
> + interrupts = <45>;
> + dmas = <&pdma 97 0>;
> + dma-names = "rxtx";
> + #address-cells = <1>;
> + marvell,nand-keep-config;
> + marvell,nand-enable-arbiter;
> + num-cs = <1>;
> + /* Partitions (optional) */
> + };
> --
> 2.11.0
>
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh Sharma @ 2017-12-20 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-gmbWdZ7rxp5qGrtSBQ7dM=3FqF-Pw=J0LaL=oKTMg4w@mail.gmail.com>
On Tue, Dec 19, 2017 at 6:39 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 19 December 2017 at 07:09, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
>> On Mon, Dec 18, 2017 at 01:40:09PM +0800, Dave Young wrote:
>>> On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
>>> > On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
>>> > > On 13 December 2017 at 12:16, AKASHI Takahiro
>>> > > <takahiro.akashi@linaro.org> wrote:
>>> > > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
>>> > > >> On 13 December 2017 at 10:26, AKASHI Takahiro
>>> > > >> <takahiro.akashi@linaro.org> wrote:
>>> > > >> > Bhupesh, Ard,
>>> > > >> >
>>> > > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
>>> > > >> >> Hi Ard, Akashi
>>> > > >> >>
>>> > > >> > (snip)
>>> > > >> >
>>> > > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
>>> > > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
>>> > > >> >> identify its own usable memory and exclude, at its boot time, any
>>> > > >> >> other memory areas that are part of the panicked kernel's memory.
>>> > > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>>> > > >> >> , for details)
>>> > > >> >
>>> > > >> > Right.
>>> > > >> >
>>> > > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
>>> > > >> >> with the crashkernel memory range:
>>> > > >> >>
>>> > > >> >> /* add linux,usable-memory-range */
>>> > > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
>>> > > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
>>> > > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
>>> > > >> >> address_cells, size_cells);
>>> > > >> >>
>>> > > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
>>> > > >> >> , for details)
>>> > > >> >>
>>> > > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
>>> > > >> >> they are marked as System RAM or as RESERVED. As,
>>> > > >> >> 'linux,usable-memory-range' dt node is patched up only with
>>> > > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
>>> > > >> >>
>>> > > >> >> 3). As a result when the crashkernel boots up it doesn't find this
>>> > > >> >> ACPI memory and crashes while trying to access the same:
>>> > > >> >>
>>> > > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
>>> > > >> >> -r`.img --reuse-cmdline -d
>>> > > >> >>
>>> > > >> >> [snip..]
>>> > > >> >>
>>> > > >> >> Reserved memory range
>>> > > >> >> 000000000e800000-000000002e7fffff (0)
>>> > > >> >>
>>> > > >> >> Coredump memory ranges
>>> > > >> >> 0000000000000000-000000000e7fffff (0)
>>> > > >> >> 000000002e800000-000000003961ffff (0)
>>> > > >> >> 0000000039d40000-000000003ed2ffff (0)
>>> > > >> >> 000000003ed60000-000000003fbfffff (0)
>>> > > >> >> 0000001040000000-0000001ffbffffff (0)
>>> > > >> >> 0000002000000000-0000002ffbffffff (0)
>>> > > >> >> 0000009000000000-0000009ffbffffff (0)
>>> > > >> >> 000000a000000000-000000affbffffff (0)
>>> > > >> >>
>>> > > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
>>> > > >> >> memory cap'ing passed to the crash kernel inside
>>> > > >> >> 'arch/arm64/mm/init.c' (see below):
>>> > > >> >>
>>> > > >> >> static void __init fdt_enforce_memory_region(void)
>>> > > >> >> {
>>> > > >> >> struct memblock_region reg = {
>>> > > >> >> .size = 0,
>>> > > >> >> };
>>> > > >> >>
>>> > > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>>> > > >> >>
>>> > > >> >> if (reg.size)
>>> > > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
>>> > > >> >> comment this out */
>>> > > >> >> }
>>> > > >> >
>>> > > >> > Please just don't do that. It can cause a fatal damage on
>>> > > >> > memory contents of the *crashed* kernel.
>>> > > >> >
>>> > > >> >> 5). Both the above temporary solutions fix the problem.
>>> > > >> >>
>>> > > >> >> 6). However exposing all System RAM regions to the crashkernel is not
>>> > > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
>>> > > >> >> fail.
>>> > > >> >>
>>> > > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
>>> > > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
>>> > > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
>>> > > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
>>> > > >> >> dt node 'linux,usable-memory-range'
>>> > > >> >
>>> > > >> > I still don't understand why we need to carry over the information
>>> > > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
>>> > > >> > such regions are free to be reused by the kernel after some point of
>>> > > >> > initialization. Why does crash dump kernel need to know about them?
>>> > > >> >
>>> > > >>
>>> > > >> Not really. According to the UEFI spec, they can be reclaimed after
>>> > > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
>>> > > >> no longer needs them. Of course, in order to be able to boot a kexec
>>> > > >> kernel, those regions needs to be preserved, which is why they are
>>> > > >> memblock_reserve()'d now.
>>> > > >
>>> > > > For my better understandings, who is actually accessing such regions
>>> > > > during boot time, uefi itself or efistub?
>>> > > >
>>> > >
>>> > > No, only the kernel. This is where the ACPI tables are stored. For
>>> > > instance, on QEMU we have
>>> > >
>>> > > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
>>> > > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
>>> > > 01000013)
>>> > > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
>>> > > BXPC 00000001)
>>> > >
>>> > > covered by
>>> > >
>>> > > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
>>> > > ...
>>> > > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>>> >
>>> > OK. I mistakenly understood those regions could be freed after exiting
>>> > UEFI boot services.
>>> >
>>> > >
>>> > > >> So it seems that kexec does not honour the memblock_reserve() table
>>> > > >> when booting the next kernel.
>>> > > >
>>> > > > not really.
>>> > > >
>>> > > >> > (In other words, can or should we skip some part of ACPI-related init code
>>> > > >> > on crash dump kernel?)
>>> > > >> >
>>> > > >>
>>> > > >> I don't think so. And the change to the handling of ACPI reclaim
>>> > > >> regions only revealed the bug, not created it (given that other
>>> > > >> memblock_reserve regions may be affected as well)
>>> > > >
>>> > > > As whether we should honor such reserved regions over kexec'ing
>>> > > > depends on each one's specific nature, we will have to take care one-by-one.
>>> > > > As a matter of fact, no information about "reserved" memblocks is
>>> > > > exposed to user space (via proc/iomem).
>>> > > >
>>> > >
>>> > > That is why I suggested (somewhere in this thread?) to not expose them
>>> > > as 'System RAM'. Do you think that could solve this?
>>> >
>>> > Memblock-reserv'ing them is necessary to prevent their corruption and
>>> > marking them under another name in /proc/iomem would also be good in order
>>> > not to allocate them as part of crash kernel's memory.
>>> >
>>> > But I'm not still convinced that we should export them in useable-
>>> > memory-range to crash dump kernel. They will be accessed through
>>> > acpi_os_map_memory() and so won't be required to be part of system ram
>>> > (or memblocks), I guess.
>>> > -> Bhupesh?
>>>
>>> I forgot how arm64 kernel retrieve the memory ranges and initialize
>>> them. If no "e820" like interfaces shouldn't kernel reinitialize all
>>> the memory according to the efi memmap? For kdump kernel anything other
>>> than usable memory (which is from the dt node instead) should be
>>> reinitialized according to efi passed info, no?
>>
>> All the regions exported in efi memmap will be added to memblock.memory
>> in (u)efi_init() and then trimmed down to the exact range specified as
>> usable-memory-range by fdt_enforce_memory_region().
>>
>> Now I noticed that the current fdt_enforce_memory_region() may not work well
>> with multiple entries in usable-memory-range.
>>
>
> In any case, the root of the problem is that memory regions lose their
> 'memory' annotation due to the way the memory map is mangled before
> being supplied to the kexec kernel.
>
> Would it be possible to classify all memory that we want to hide from
> the kexec kernel as NOMAP instead? That way, it will not be mapped
> implicitly, but will still be mapped cacheable by acpi_os_ioremap(),
> so this seems to be the most appropriate way to deal with the host
> kernel's memory contents.
Hmm. wouldn't appending the acpi reclaim regions to
'linux,usable-memory-range' in the dtb being passed to the crashkernel
be better? Because its indirectly achieving a similar objective
(although may be a subset of all System RAM regions on the primary
kernel's memory).
I am not aware of the background about the current kexec-tools
implementation where we add only the crashkernel range to the dtb
being passed to the crashkernel.
Probably Akashi can answer better, as to how we arrived at this design
approach and why we didn't want to expose all System RAM regions (i.e.
! NOMPAP regions) to the crashkernel.
I am suspecting that some issues were seen/meet when the System RAM (!
NOMAP regions) were exposed to the crashkernel, and that's why we
finalized on this design approach, but this is something which is just
my guess.
Regards,
Bhupesh
>>> >
>>> > Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>>> > via a kernel command line parameter, "memmap=".
>>>
>>> memmap= is only used in old kexec-tools, now we are passing them via
>>> e820 table.
>>
>> Thanks. I remember that you have explained it before.
>>
>> -Takahiro AKASHI
>>
>>> [snip]
>>>
>>> Thanks
>>> Dave
^ permalink raw reply
* [GIT PULL 2/5] soc/tegra: Changes for v4.16-rc1
From: Dmitry Osipenko @ 2017-12-20 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-2-thierry.reding@gmail.com>
On 20.12.2017 22:18, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.16-soc
>
> for you to fetch changes up to c641ec6eab8587a78160d37f085a5ed6e542ca88:
>
> soc/tegra: pmc: Consolidate Tegra186 support (2017-12-13 13:06:44 +0100)
>
Could you please include these patches
https://patchwork.ozlabs.org/project/linux-tegra/list/?series=9215 ?
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh Sharma @ 2017-12-20 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219050113.GF28046@linaro.org>
On Tue, Dec 19, 2017 at 10:31 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
>>
>> [snip..]
>>
>> [ 0.000000] linux,usable-memory-range base e800000, size 20000000
>> [ 0.000000] - e800000 , 20000000
>> [ 0.000000] linux,usable-memory-range base 396c0000, size a0000
>> [ 0.000000] - 396c0000 , a0000
>> [ 0.000000] linux,usable-memory-range base 39770000, size 40000
>> [ 0.000000] - 39770000 , 40000
>> [ 0.000000] linux,usable-memory-range base 398a0000, size 20000
>> [ 0.000000] - 398a0000 , 20000
>> [ 0.000000] initrd not fully accessible via the linear mapping --
>> please check your bootloader ...
>
> This is an odd message coming from:
> |void __init arm64_memblock_init(void)
> |...
> |
> | if (WARN(base < memblock_start_of_DRAM() ||
> | base + size > memblock_start_of_DRAM() +
> | linear_region_size,
> | "initrd not fully accessible via the linear mapping -- please check your bootloader ...\n")) {
>
> Can you confirm how the condition breaks here?
> I suppose
> base: 0xfe70000
> size: 0x13c0000
> memblock_start_of_DRAM(): 0xe800000
> according to the information you gave me.
Indeed, the first check 'base < memblock_start_of_DRAM()' in the
following check fails:
if (WARN(base < memblock_start_of_DRAM() ||
base + size > memblock_start_of_DRAM() +
linear_region_size,
Here are the values I am seeing on this board using the kernel and
kexec-tools which have been modified to append the
'linux,usable-memory-range' with the acpi reclaim regions:
base=fe70000,
size=13c0000,
memblock_start_of_DRAM=39620000
linear_region_size=800000000000
I suspect that the holes introduced by kexec-tools inside
'arm64_load_other_segments()' in 'kexec/arch/arm64/kexec-arm64.c' (see
the code leg below):
/* Put the other segments after the image. */
hole_min = image_base + arm64_mem.image_size;
if (info->kexec_flags & KEXEC_ON_CRASH)
hole_max = crash_reserved_mem.end;
else
hole_max = ULONG_MAX;
should be updated to introduce appropriate handling of the acpi reclaim regions.
I am not aware of the background of this handling in the kexec-tools.
Do you think this can be at fault, Akashi?
Regards,
Bhupesh
>
>> [ 0.000000] ------------[ cut here ]------------
>> [ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/init.c:597
>> arm64_memblock_init+0x210/0x484
>> [ 0.000000] Modules linked in:
>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.0+ #7
>> [ 0.000000] task: ffff000008d05580 task.stack: ffff000008cc0000
>> [ 0.000000] PC is at arm64_memblock_init+0x210/0x484
>> [ 0.000000] LR is at arm64_memblock_init+0x210/0x484
>> [ 0.000000] pc : [<ffff000008b76984>] lr : [<ffff000008b76984>]
>> pstate: 600000c5
>> [ 0.000000] sp : ffff000008ccfe80
>> [ 0.000000] x29: ffff000008ccfe80 x28: 000000000f370018
>> [ 0.000000] x27: 0000000011230000 x26: 00000000013b0000
>> [ 0.000000] x25: 000000000fe80000 x24: ffff000008cf3000
>> [ 0.000000] x23: ffff000008ec0000 x22: ffff000009680000
>> [ 0.000000] x21: ffff000008afa000 x20: ffff000008080000
>> [ 0.000000] x19: ffff000008afa000 x18: 000000000c283806
>> [ 0.000000] x17: 0000000000000000 x16: ffff000008d05580
>> [ 0.000000] x15: 000000002be00842 x14: 79206b6365686320
>> [ 0.000000] x13: 657361656c70202d x12: 2d20676e69707061
>> [ 0.000000] x11: 6d207261656e696c x10: 2065687420616976
>> [ 0.000000] x9 : 00000000000000f4 x8 : ffff000008517414
>> [ 0.000000] x7 : 746f6f622072756f x6 : 000000000000000d
>> [ 0.000000] x5 : ffff000008c96360 x4 : 0000000000000001
>> [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000000
>> [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000056
>> [ 0.000000] Call trace:
>> [ 0.000000] Exception stack(0xffff000008ccfd40 to 0xffff000008ccfe80)
>> [ 0.000000] fd40: 0000000000000056 0000000000000000
>> 0000000000000000 0000000000000000
>> [ 0.000000] fd60: 0000000000000001 ffff000008c96360
>> 000000000000000d 746f6f622072756f
>> [ 0.000000] fd80: ffff000008517414 00000000000000f4
>> 2065687420616976 6d207261656e696c
>> [ 0.000000] fda0: 2d20676e69707061 657361656c70202d
>> 79206b6365686320 000000002be00842
>> [ 0.000000] fdc0: ffff000008d05580 0000000000000000
>> 000000000c283806 ffff000008afa000
>> [ 0.000000] fde0: ffff000008080000 ffff000008afa000
>> ffff000009680000 ffff000008ec0000
>> [ 0.000000] fe00: ffff000008cf3000 000000000fe80000
>> 00000000013b0000 0000000011230000
>> [ 0.000000] fe20: 000000000f370018 ffff000008ccfe80
>> ffff000008b76984 ffff000008ccfe80
>> [ 0.000000] fe40: ffff000008b76984 00000000600000c5
>> ffff00000959b7a8 ffff000008ec0000
>> [ 0.000000] fe60: ffffffffffffffff 0000000000000005
>> ffff000008ccfe80 ffff000008b76984
>> [ 0.000000] [<ffff000008b76984>] arm64_memblock_init+0x210/0x484
>> [ 0.000000] [<ffff000008b7398c>] setup_arch+0x1b8/0x5f4
>> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
>> [ 0.000000] random: get_random_bytes called from
>> print_oops_end_marker+0x50/0x6c with crng_init=0
>> [ 0.000000] ---[ end trace 0000000000000000 ]---
>> [ 0.000000] Reserving 4KB of memory at 0x2e7f0000 for elfcorehdr
>> [ 0.000000] cma: Failed to reserve 512 MiB
>> [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate
>> 0x0000000000010000 bytes below 0x0000000000000000.
>> [ 0.000000]
>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G W
>> ------------ 4.14.0+ #7
>> [ 0.000000] Call trace:
>> [ 0.000000] [<ffff000008088da8>] dump_backtrace+0x0/0x23c
>> [ 0.000000] [<ffff000008089008>] show_stack+0x24/0x2c
>> [ 0.000000] [<ffff0000087f647c>] dump_stack+0x84/0xa8
>> [ 0.000000] [<ffff0000080cfd44>] panic+0x138/0x2a0
>> [ 0.000000] [<ffff000008b95c88>] memblock_alloc_base+0x44/0x4c
>> [ 0.000000] [<ffff000008b95cbc>] memblock_alloc+0x2c/0x38
>> [ 0.000000] [<ffff000008b772dc>] early_pgtable_alloc+0x20/0x74
>> [ 0.000000] [<ffff000008b7755c>] paging_init+0x28/0x544
>> [ 0.000000] [<ffff000008b73990>] setup_arch+0x1bc/0x5f4
>> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
>> [ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to
>> allocate 0x0000000000010000 bytes below 0x0000000000000000.
>> [ 0.000000]
>>
>> I guess it is because of the 1G alignment requirement between the
>> kernel image and the initrd and how we populate the holes between the
>> kernel image, segments (including dtb) and the initrd from the
>> kexec-tools.
>>
>> Akashi, any pointers on this will be helpful as well.
>>
>> Regards,
>> Bhupesh
>>
>>
>> >> >
>> >> > Regards,
>> >> > Bhupesh
>> >> >
>> >> > >> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>> >> > >> via a kernel command line parameter, "memmap=".
>> >> > >>
>> >> > _______________________________________________
>> >> > kexec mailing list -- kexec at lists.fedoraproject.org
>> >> > To unsubscribe send an email to kexec-leave at lists.fedoraproject.org
^ permalink raw reply
* [PATCH 2/2] arm64: dts: exynos: Fix typo in MSCL clock controller unit address
From: Krzysztof Kozlowski @ 2017-12-20 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220192702.32515-1-krzk@kernel.org>
Fix typo in unit address of MSCL clock controller (the reg entry is
correct).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 0ba5df825eff..3e8311c60d1b 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -468,7 +468,7 @@
clocks = <&xxti>, <&cmu_mif CLK_SCLK_BUS_PLL_ATLAS>;
};
- cmu_mscl: clock-controller at 105d0000 {
+ cmu_mscl: clock-controller at 150d0000 {
compatible = "samsung,exynos5433-cmu-mscl";
reg = <0x150d0000 0x1000>;
#clock-cells = <1>;
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: exynos: Use lower case hex addresses in node unit addresses
From: Krzysztof Kozlowski @ 2017-12-20 19:27 UTC (permalink / raw)
To: linux-arm-kernel
Convert all hex addresses in node unit addresses to lower case to
fix warnings like:
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dtb: Warning (simple_bus_reg):
Node /soc/video-scaler at 13C00000 simple-bus unit address format error, expected "13c00000"
Conversion was done using sed:
$ sed -e 's/@\([a-zA-Z0-9_-]*\) {/@\L\1 {/' -i arch/arm64/boot/dts/exynos/*.dts*
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 8 ++++----
arch/arm64/boot/dts/exynos/exynos7.dtsi | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 1962b8074349..0ba5df825eff 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -994,7 +994,7 @@
reg = <0x145f0000 0x1038>;
};
- gsc_0: video-scaler at 13C00000 {
+ gsc_0: video-scaler at 13c00000 {
compatible = "samsung,exynos5433-gsc";
reg = <0x13c00000 0x1000>;
interrupts = <GIC_SPI 297 IRQ_TYPE_LEVEL_HIGH>;
@@ -1008,7 +1008,7 @@
power-domains = <&pd_gscl>;
};
- gsc_1: video-scaler at 13C10000 {
+ gsc_1: video-scaler at 13c10000 {
compatible = "samsung,exynos5433-gsc";
reg = <0x13c10000 0x1000>;
interrupts = <GIC_SPI 298 IRQ_TYPE_LEVEL_HIGH>;
@@ -1022,7 +1022,7 @@
power-domains = <&pd_gscl>;
};
- gsc_2: video-scaler at 13C20000 {
+ gsc_2: video-scaler at 13c20000 {
compatible = "samsung,exynos5433-gsc";
reg = <0x13c20000 0x1000>;
interrupts = <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>;
@@ -1049,7 +1049,7 @@
power-domains = <&pd_mscl>;
};
- mfc: codec at 152E0000 {
+ mfc: codec at 152e0000 {
compatible = "samsung,exynos5433-mfc";
reg = <0x152E0000 0x10000>;
interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 9a3fbed1765a..3504837b1d43 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -103,7 +103,7 @@
#size-cells = <1>;
ranges;
- pdma0: pdma at 10E10000 {
+ pdma0: pdma at 10e10000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x10E10000 0x1000>;
interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
@@ -114,7 +114,7 @@
#dma-requests = <32>;
};
- pdma1: pdma at 10EB0000 {
+ pdma1: pdma at 10eb0000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x10EB0000 0x1000>;
interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation
From: Michael Turquette @ 2017-12-20 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06b927e4-ed1b-9e1a-becf-e2818e7efe6d@gmail.com>
Quoting Matthias Brugger (2017-12-20 09:13:12)
>
>
> On 12/19/2017 02:32 AM, Stephen Boyd wrote:
> > On 12/14, Matthias Brugger wrote:
> >> Hi Stephen, Michael,
> >>
> >> On 12/01/2017 01:07 PM, Matthias Brugger wrote:
> >>> The ethsys registers a reset controller, so we need to specify a
> >>> reset cell. This patch fixes the documentation.
> >>>
> >>> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> >>> ---
> >>> Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> index 7aa3fa167668..6cc7840ff37a 100644
> >>> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> @@ -20,4 +20,5 @@ ethsys: clock-controller at 1b000000 {
> >>> compatible = "mediatek,mt2701-ethsys", "syscon";
> >>> reg = <0 0x1b000000 0 0x1000>;
> >>> #clock-cells = <1>;
> >>> + #reset-cells = <1>;
> >>> };
> >>>
> >>
> >> Will you take this patch through the clk tree, or shall I take it through my SoC
> >> tree?
> >>
> >
> > It's resets, we are clk maintainers. I'm clkfused.
> >
> > You can take it, along with my
> >
> > Acked-by: Stephen Boyd <sboyd@codeaurora.org>
> >
> > if you like/expect conflicts.
> >
>
> These are resets in the clock IP-block. I'll take it through my branch, I don't
> expect any conflicts.
Sounds good to me.
Best regards,
Mike
>
> Regards,
> Matthias
^ permalink raw reply
* [GIT PULL] arm64: Updates of aarch64 DTS files for v4.15-next
From: Matthias Brugger @ 2017-12-20 19:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, hi Arnd,
Please take the patches below into consideration.
Thanks a lot,
Matthias
---
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git
tags/v4.15-next-dts32
for you to fetch changes up to a227cf4dfd74a873857c9cc017100168d01539ed:
dt-bindings: ARM: Mediatek: Fix ethsys documentation (2017-12-20 18:10:12 +0100)
----------------------------------------------------------------
- add reset cells mt2701 and mt7623 ethsys
- update mmc nodes for mt7623
- mt7623 change mmc card detection pin to active low
- mt7623 set unit address to lower case
----------------------------------------------------------------
Mathieu Malaterre (1):
arm: mt7: dts: Remove leading 0x and 0s from bindings notation
Matthias Brugger (3):
arm: dts: mt7623: Update ethsys binding
arm: dts: mt2701: Add reset-cells
dt-bindings: ARM: Mediatek: Fix ethsys documentation
Sean Wang (2):
arm: dts: mt7623: update mmc related nodes with the appropriate fallback
arm: dts: mt7623: fix card detection issue on bananapi-r2
Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
arch/arm/boot/dts/mt2701.dtsi | 2 ++
arch/arm/boot/dts/mt7623.dtsi | 5 +++--
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
arch/arm/boot/dts/mt7623n-rfb-nand.dts | 2 +-
5 files changed, 8 insertions(+), 4 deletions(-)
^ permalink raw reply
* [RFC PATCH v2 1/3] PCI: rockchip: Add support for pcie wake irq
From: Tony Lindgren @ 2017-12-20 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219004811.GA216620@google.com>
Hi,
* Brian Norris <briannorris@chromium.org> [171219 00:50]:
> On Wed, Aug 23, 2017 at 09:32:39AM +0800, Jeffy Chen wrote:
>
> Did this problem ever get resolved? To be clear, I believe the problem
> at hand is:
>
> (a) in suspend/resume (not runtime PM; we may not even have runtime PM
> support for most PCI devices)
It seems it should be enough to implement runtime PM in the PCI
controller. Isn't each PCI WAKE# line is wired from each PCI device
to the PCI controller?
Then the PCI controller can figure out from which PCI device the
WAKE# came from.
> Options I can think of:
> (1) implement runtime PM callbacks for all PCI devices, where we clear
> any PME status and ensure WAKE# stops asserting [1]
I don't think this is needed, it should be enough to have just
the PCI controller implement runtime PM :)
Regards,
Tony
^ permalink raw reply
* [GIT PULL 5/5] arm64: tegra: Changes for v4.16-rc1
From: Thierry Reding @ 2017-12-20 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.16-arm64-dt
for you to fetch changes up to 50f5b841ba06f4dfb739e7a5ab9b87e8173d5915:
arm64: tegra: Use sor1_out clock (2017-12-15 10:14:17 +0100)
Thanks,
Thierry
----------------------------------------------------------------
arm64: tegra: Changes for v4.16-rc1
This set of patches enables a bunch of new features on Jetson TX2 that
were finally unblocked by the GPIO driver getting merged for v4.15.
----------------------------------------------------------------
Jon Hunter (1):
arm64: tegra: Add CPU and PSCI nodes for NVIDIA Tegra210 platforms
Thierry Reding (12):
dt-bindings: misc: Add Tegra186 MISC registers bindings
dt-bindings: memory: Add Tegra186 support
arm64: tegra: Add MISC registers on Tegra186
arm64: tegra: Add FUSE block on Tegra186
arm64: tegra: Add memory controller on Tegra186
arm64: tegra: Enable memory controller on P3310
arm64: tegra: Add SMMU node for Tegra186
arm64: tegra: Add display nodes on Tegra186
arm64: tegra: Mark I2C4 as DDC on P3310
arm64: tegra: Enable HDMI on Jetson TX2
arm64: tegra: Fix SD write-protect polarity on Jetson TX2
arm64: tegra: Use sor1_out clock
.../memory-controllers/nvidia,tegra30-mc.txt | 2 +
.../bindings/misc/nvidia,tegra186-misc.txt | 12 +
arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts | 51 +++
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 10 +-
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 351 +++++++++++++++++++++
arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi | 23 ++
arch/arm64/boot/dts/nvidia/tegra210-p2530.dtsi | 23 ++
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 4 +-
include/dt-bindings/memory/tegra186-mc.h | 111 +++++++
9 files changed, 582 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.txt
create mode 100644 include/dt-bindings/memory/tegra186-mc.h
^ permalink raw reply
* [GIT PULL 4/5] ARM: tegra: Device tree changes for v4.16-rc1
From: Thierry Reding @ 2017-12-20 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.16-arm-dt
for you to fetch changes up to bb768f28b29e7c72875d8521e2d5b09337561365:
ARM: tegra: Add video decoder on Tegra20 (2017-12-20 19:57:20 +0100)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Device tree changes for v4.16-rc1
These changes enable the video decoder engine found on Tegra20 SoCs.
----------------------------------------------------------------
Dmitry Osipenko (1):
ARM: tegra: Add video decoder on Tegra20
Vladimir Zapolskiy (1):
ARM: tegra: Add device tree node to describe IRAM on Tegra20
arch/arm/boot/dts/tegra20.dtsi | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
^ permalink raw reply
* [GIT PULL 3/5] memory: tegra: Changes for v4.16-rc1
From: Thierry Reding @ 2017-12-20 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.16-memory
for you to fetch changes up to 83476bfaf6ac1cebf0cc5a3bdcf5031ef875cf42:
iommu/tegra-smmu: Fix return value check in tegra_smmu_group_get() (2017-12-20 18:32:08 +0100)
Thanks,
Thierry
----------------------------------------------------------------
memory: tegra: Changes for v4.16-rc1
The Tegra memory controller driver will now instruct the SMMU driver to
create groups, which will make it easier for device drivers to share an
IOMMU domain between multiple devices.
Initial Tegra186 support is also added in a separate driver.
----------------------------------------------------------------
Thierry Reding (6):
dt-bindings: misc: Add Tegra186 MISC registers bindings
dt-bindings: memory: Add Tegra186 support
Merge branch 'for-4.16/dt-bindings' into for-4.16/memory
memory: tegra: Add Tegra186 support
memory: tegra: Create SMMU display groups
iommu/tegra: Allow devices to be grouped
Wei Yongjun (1):
iommu/tegra-smmu: Fix return value check in tegra_smmu_group_get()
.../memory-controllers/nvidia,tegra30-mc.txt | 2 +
.../bindings/misc/nvidia,tegra186-misc.txt | 12 +
drivers/iommu/tegra-smmu.c | 124 ++++-
drivers/memory/tegra/Makefile | 1 +
drivers/memory/tegra/tegra114.c | 15 +
drivers/memory/tegra/tegra124.c | 17 +
drivers/memory/tegra/tegra186.c | 600 +++++++++++++++++++++
drivers/memory/tegra/tegra210.c | 15 +
drivers/memory/tegra/tegra30.c | 15 +
include/dt-bindings/memory/tegra186-mc.h | 111 ++++
include/soc/tegra/mc.h | 9 +
11 files changed, 917 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.txt
create mode 100644 drivers/memory/tegra/tegra186.c
create mode 100644 include/dt-bindings/memory/tegra186-mc.h
^ permalink raw reply
* [GIT PULL 2/5] soc/tegra: Changes for v4.16-rc1
From: Thierry Reding @ 2017-12-20 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.16-soc
for you to fetch changes up to c641ec6eab8587a78160d37f085a5ed6e542ca88:
soc/tegra: pmc: Consolidate Tegra186 support (2017-12-13 13:06:44 +0100)
Thanks,
Thierry
----------------------------------------------------------------
soc/tegra: Changes for v4.16-rc1
Fuse and chip ID support for Tegra186 is added in this set of changes,
followed by some unification work for the PMC driver in order to avoid
code duplication between Tegra186 and prior chips.
----------------------------------------------------------------
Thierry Reding (7):
dt-bindings: misc: Add Tegra186 MISC registers bindings
Merge branch 'for-4.16/dt-bindings' into for-4.16/soc
soc/tegra: fuse: Move register mapping check
soc/tegra: fuse: Warn if accessing unmapped registers
soc/tegra: fuse: Add Tegra186 chip ID support
soc/tegra: pmc: Parameterize driver
soc/tegra: pmc: Consolidate Tegra186 support
Timo Alho (1):
soc/tegra: fuse: Add Tegra186 support
.../bindings/misc/nvidia,tegra186-misc.txt | 12 +
drivers/soc/tegra/Kconfig | 5 +-
drivers/soc/tegra/Makefile | 1 -
drivers/soc/tegra/fuse/fuse-tegra.c | 3 +
drivers/soc/tegra/fuse/fuse-tegra30.c | 24 +-
drivers/soc/tegra/fuse/fuse.h | 4 +
drivers/soc/tegra/fuse/tegra-apbmisc.c | 11 +-
drivers/soc/tegra/pmc-tegra186.c | 169 ------------
drivers/soc/tegra/pmc.c | 304 +++++++++++++++++----
include/soc/tegra/pmc.h | 12 +
10 files changed, 310 insertions(+), 235 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.txt
delete mode 100644 drivers/soc/tegra/pmc-tegra186.c
^ permalink raw reply
* [GIT PULL 1/5] dt-bindings: Updates for v4.16-rc1
From: Thierry Reding @ 2017-12-20 19:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC maintainers,
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.16-dt-bindings
for you to fetch changes up to 029ab5eaf091ce5eaa1f3017f66fd1d10f431d61:
dt-bindings: memory: Add Tegra186 support (2017-12-13 12:53:43 +0100)
Thanks,
Thierry
----------------------------------------------------------------
dt-bindings: Updates for v4.16-rc1
This contains a set of patches that extend existing bindings with support
for Tegra186.
----------------------------------------------------------------
Thierry Reding (2):
dt-bindings: misc: Add Tegra186 MISC registers bindings
dt-bindings: memory: Add Tegra186 support
.../memory-controllers/nvidia,tegra30-mc.txt | 2 +
.../bindings/misc/nvidia,tegra186-misc.txt | 12 +++
include/dt-bindings/memory/tegra186-mc.h | 111 +++++++++++++++++++++
3 files changed, 125 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.txt
create mode 100644 include/dt-bindings/memory/tegra186-mc.h
^ permalink raw reply
* [GIT PULL] arm: Updates of armv7 DTS for v4.15-next
From: Matthias Brugger @ 2017-12-20 19:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
Please feel free to pull the following patches.
Thanks,
Matthias
---
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git
tags/v4.15-next-dts64
for you to fetch changes up to c0c3333daba6617b44228a8dffb8184b2fd1931d:
arm64: dts: Add power controller device node of MT2712 (2017-12-20 20:02:50 +0100)
----------------------------------------------------------------
- mt8173 add cpufreq related nodes
supply nodes
frequency/voltage operation table
- mt2712 add cpufreq related nodes
fixed regulator
supply nodes
frequency/voltage operation table
- mt2712 add clock contoller nodes
- mt2712 add scpsys node
----------------------------------------------------------------
Andrew-sh Cheng (2):
arm64: dts: mediatek: add mt8173 cpufreq related device nodes
arm64: dts: mediatek: add mt2712 cpufreq related device nodes
weiyi.lu at mediatek.com (2):
arm64: dts: mt2712: Add clock controller device nodes
arm64: dts: Add power controller device node of MT2712
arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 27 ++++
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 188 ++++++++++++++++++++++++++++
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 +++
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 90 +++++++++++++
4 files changed, 323 insertions(+)
^ permalink raw reply
* [GIT PULL] arm: Updates of soc drivers for v4.15-next
From: Matthias Brugger @ 2017-12-20 19:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
Please take the following patches into account.
Thanks,
Matthias
---
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git
tags/v4.15-next-soc
for you to fetch changes up to 579c60686a086f250c82c76778eb1839394e54ef:
soc: mediatek: add MT2712 scpsys support (2017-12-20 18:30:29 +0100)
----------------------------------------------------------------
- change kconfig entry for armv7 SoCs to be more generic
- add support for mt2701 scpsys driver
binding documentation
extend driver to allow the bus protection to overwrite the register
----------------------------------------------------------------
Sean Wang (1):
ARM: mediatek: use more generic prompts for SoCs with ARMv7
weiyi.lu at mediatek.com (4):
dt-bindings: soc: add MT2712 power dt-bindings
soc: mediatek: extend bus protection API
soc: mediatek: add dependent clock jpgdec/audio for scpsys
soc: mediatek: add MT2712 scpsys support
.../devicetree/bindings/soc/mediatek/scpsys.txt | 3 +
arch/arm/mach-mediatek/Kconfig | 2 +-
drivers/soc/mediatek/mtk-infracfg.c | 26 +++-
drivers/soc/mediatek/mtk-scpsys.c | 140 ++++++++++++++++++---
include/dt-bindings/power/mt2712-power.h | 26 ++++
include/linux/soc/mediatek/infracfg.h | 7 +-
6 files changed, 181 insertions(+), 23 deletions(-)
create mode 100644 include/dt-bindings/power/mt2712-power.h
^ permalink raw reply
* [PATCH 3/3] [v7] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-20 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513797033-9494-1-git-send-email-timur@codeaurora.org>
Newer versions of the firmware for the Qualcomm Datacenter Technologies
QDF2400 restricts access to a subset of the GPIOs on the TLMM. To
prevent older kernels from accidentally accessing the restricted GPIOs,
we change the ACPI HID for the TLMM block from QCOM8001 to QCOM8002,
and introduce a new property "gpios". This property is an array of
specific GPIOs that are accessible. When an older kernel boots on
newer (restricted) firmware, it will fail to probe.
To implement the sparse GPIO map, we register all of the GPIOs, but set
the pin count for the unavailable GPIOs to zero. The pinctrl-msm
driver will block those unavailable GPIOs from being accessed.
Support for QCOM8001 is removed as there is no longer any firmware that
implements it.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 96 ++++++++++++++++++++++------------
1 file changed, 64 insertions(+), 32 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c b/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
index bb3ce5c3e18b..f8ba58dd4d07 100644
--- a/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
+++ b/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
@@ -32,7 +32,7 @@
static struct msm_pinctrl_soc_data qdf2xxx_pinctrl;
-/* A reasonable limit to the number of GPIOS */
+/* A maximum of 256 allows us to use a u8 array to hold the GPIO numbers */
#define MAX_GPIOS 256
/* maximum size of each gpio name (enough room for "gpioXXX" + null) */
@@ -45,59 +45,91 @@ static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
char (*names)[NAME_SIZE];
unsigned int i;
u32 num_gpios;
+ unsigned int avail_gpios; /* The number of GPIOs we support */
+ u8 gpios[MAX_GPIOS]; /* An array of supported GPIOs */
int ret;
/* Query the number of GPIOs from ACPI */
ret = device_property_read_u32(&pdev->dev, "num-gpios", &num_gpios);
if (ret < 0) {
- dev_warn(&pdev->dev, "missing num-gpios property\n");
+ dev_err(&pdev->dev, "missing 'num-gpios' property\n");
return ret;
}
-
if (!num_gpios || num_gpios > MAX_GPIOS) {
- dev_warn(&pdev->dev, "invalid num-gpios property\n");
+ dev_err(&pdev->dev, "invalid 'num-gpios' property\n");
+ return -ENODEV;
+ }
+
+ /* The number of GPIOs in the approved list */
+ ret = device_property_read_u8_array(&pdev->dev, "gpios", NULL, 0);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "missing 'gpios' property\n");
+ return ret;
+ }
+ /*
+ * The number of available GPIOs should be non-zero, and no
+ * more than the total number of GPIOS.
+ */
+ if (!ret || ret > num_gpios) {
+ dev_err(&pdev->dev, "invalid 'gpios' property\n");
return -ENODEV;
}
+ avail_gpios = ret;
+
+ ret = device_property_read_u8_array(&pdev->dev, "gpios", gpios,
+ avail_gpios);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "could not read list of GPIOs\n");
+ return ret;
+ }
pins = devm_kcalloc(&pdev->dev, num_gpios,
sizeof(struct pinctrl_pin_desc), GFP_KERNEL);
groups = devm_kcalloc(&pdev->dev, num_gpios,
sizeof(struct msm_pingroup), GFP_KERNEL);
- names = devm_kcalloc(&pdev->dev, num_gpios, NAME_SIZE, GFP_KERNEL);
+ names = devm_kcalloc(&pdev->dev, avail_gpios, NAME_SIZE, GFP_KERNEL);
if (!pins || !groups || !names)
return -ENOMEM;
+ /*
+ * Initialize the array. GPIOs not listed in the 'gpios' array
+ * still need a number, but nothing else.
+ */
for (i = 0; i < num_gpios; i++) {
- snprintf(names[i], NAME_SIZE, "gpio%u", i);
-
pins[i].number = i;
- pins[i].name = names[i];
-
- groups[i].npins = 1;
- groups[i].name = names[i];
groups[i].pins = &pins[i].number;
+ }
- groups[i].ctl_reg = 0x10000 * i;
- groups[i].io_reg = 0x04 + 0x10000 * i;
- groups[i].intr_cfg_reg = 0x08 + 0x10000 * i;
- groups[i].intr_status_reg = 0x0c + 0x10000 * i;
- groups[i].intr_target_reg = 0x08 + 0x10000 * i;
-
- groups[i].mux_bit = 2;
- groups[i].pull_bit = 0;
- groups[i].drv_bit = 6;
- groups[i].oe_bit = 9;
- groups[i].in_bit = 0;
- groups[i].out_bit = 1;
- groups[i].intr_enable_bit = 0;
- groups[i].intr_status_bit = 0;
- groups[i].intr_target_bit = 5;
- groups[i].intr_target_kpss_val = 1;
- groups[i].intr_raw_status_bit = 4;
- groups[i].intr_polarity_bit = 1;
- groups[i].intr_detection_bit = 2;
- groups[i].intr_detection_width = 2;
+ /* Populate the entries that are meant to be exposed as GPIOs. */
+ for (i = 0; i < avail_gpios; i++) {
+ unsigned int gpio = gpios[i];
+
+ groups[gpio].npins = 1;
+ snprintf(names[i], NAME_SIZE, "gpio%u", gpio);
+ pins[gpio].name = names[i];
+ groups[gpio].name = names[i];
+
+ groups[gpio].ctl_reg = 0x10000 * gpio;
+ groups[gpio].io_reg = 0x04 + 0x10000 * gpio;
+ groups[gpio].intr_cfg_reg = 0x08 + 0x10000 * gpio;
+ groups[gpio].intr_status_reg = 0x0c + 0x10000 * gpio;
+ groups[gpio].intr_target_reg = 0x08 + 0x10000 * gpio;
+
+ groups[gpio].mux_bit = 2;
+ groups[gpio].pull_bit = 0;
+ groups[gpio].drv_bit = 6;
+ groups[gpio].oe_bit = 9;
+ groups[gpio].in_bit = 0;
+ groups[gpio].out_bit = 1;
+ groups[gpio].intr_enable_bit = 0;
+ groups[gpio].intr_status_bit = 0;
+ groups[gpio].intr_target_bit = 5;
+ groups[gpio].intr_target_kpss_val = 1;
+ groups[gpio].intr_raw_status_bit = 4;
+ groups[gpio].intr_polarity_bit = 1;
+ groups[gpio].intr_detection_bit = 2;
+ groups[gpio].intr_detection_width = 2;
}
qdf2xxx_pinctrl.pins = pins;
@@ -110,7 +142,7 @@ static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
}
static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
- {"QCOM8001"},
+ {"QCOM8002"},
{},
};
MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 2/3] [v8] pinctrl: qcom: disable GPIO groups with no pins
From: Timur Tabi @ 2017-12-20 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513797033-9494-1-git-send-email-timur@codeaurora.org>
pinctrl-msm only accepts an array of GPIOs from 0 to n-1, and it expects
each group to support have only one pin (npins == 1).
We can support "sparse" GPIO maps if we allow for some groups to have zero
pins (npins == 0). These pins are "hidden" from the rest of the driver
and gpiolib.
Access to unavailable GPIOs is blocked via a request callback. If the
requested GPIO is unavailable, -EACCES is returned, which prevents
further access to that GPIO.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/pinctrl/qcom/pinctrl-msm.c | 28 +++++++++++++++++++++++-----
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
index 7a960590ecaa..d45b4c2b5af1 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -507,6 +507,11 @@ static void msm_gpio_dbg_show_one(struct seq_file *s,
};
g = &pctrl->soc->groups[offset];
+
+ /* If the GPIO group has no pins, then don't show it. */
+ if (!g->npins)
+ return;
+
ctl_reg = readl(pctrl->regs + g->ctl_reg);
is_out = !!(ctl_reg & BIT(g->oe_bit));
@@ -516,7 +521,7 @@ static void msm_gpio_dbg_show_one(struct seq_file *s,
seq_printf(s, " %-8s: %-3s %d", g->name, is_out ? "out" : "in", func);
seq_printf(s, " %dmA", msm_regval_to_drive(drive));
- seq_printf(s, " %s", pulls[pull]);
+ seq_printf(s, " %s\n", pulls[pull]);
}
static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
@@ -524,23 +529,36 @@ static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
unsigned gpio = chip->base;
unsigned i;
- for (i = 0; i < chip->ngpio; i++, gpio++) {
+ for (i = 0; i < chip->ngpio; i++, gpio++)
msm_gpio_dbg_show_one(s, NULL, chip, i, gpio);
- seq_puts(s, "\n");
- }
}
#else
#define msm_gpio_dbg_show NULL
#endif
+/*
+ * If the requested GPIO has no pins, then treat it as unavailable.
+ * Otherwise, call the standard request function.
+ */
+static int msm_gpio_request(struct gpio_chip *chip, unsigned int offset)
+{
+ struct msm_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct msm_pingroup *g = &pctrl->soc->groups[offset];
+
+ if (!g->npins)
+ return -EACCES;
+
+ return gpiochip_generic_request(chip, offset);
+}
+
static const struct gpio_chip msm_gpio_template = {
.direction_input = msm_gpio_direction_input,
.direction_output = msm_gpio_direction_output,
.get_direction = msm_gpio_get_direction,
.get = msm_gpio_get,
.set = msm_gpio_set,
- .request = gpiochip_generic_request,
+ .request = msm_gpio_request,
.free = gpiochip_generic_free,
.dbg_show = msm_gpio_dbg_show,
};
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
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