* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Marek Szyprowski @ 2017-12-12 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc1_n2cdgjuFbA9jNdcSXxfr8Zjf=fUx_jt_N3+LP0n8A@mail.gmail.com>
Hi Krzysztof,
On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>> <javierm@redhat.com> wrote:
>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>
>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Remove RFT tag.
>> Thanks guys! However I still would like to see a tested-by for this on
>> Peach Pi (AFAIU, Marek's only acked the code/solution).
> On the other hand I could just apply it for my for-next branch and
> we'll see if it fixes kernel-ci boot tests... Not a nice way of
> testing but apparently no one has Peach Pi.
Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
However it should at least hide the unbalanced regulator issue.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Krzysztof Kozlowski @ 2017-12-12 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <88bebc9d-a889-403b-a742-c11ad6617638@samsung.com>
On Tue, Dec 12, 2017 at 9:47 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Hi Javier,
>
> On 2017-12-12 09:00, Javier Martinez Canillas wrote:
>>
>> On Tue, Dec 12, 2017 at 8:54 AM, Marek Szyprowski
>> <m.szyprowski@samsung.com> wrote:
(...)
>>> This warning has been added intentionally, see following discussions:
>>> https://patchwork.kernel.org/patch/10034919/
>>> https://patchwork.kernel.org/patch/10070475/
>>>
>>> This means that your test apps should be updated or you should enable
>>> Exynos
>>> IOMMU support in your config. Maybe it is a good time to finally enable
>>> it
>>> in exynos_defconfig.
>>>
>> Has the issue that the boot-loader keeps the display controller
>> enabled and scanning pages on the Exynos Chromebooks resolved?
>>
>> I think that's that preventing to enable it by default in
>> exynos_defconfig since it caused boot failures when enabled on these
>> machines. I don't follow exynos development too closely nowadays so
>> maybe there's a fix in place now.
>
>
> Not directly. I still didn't find time to properly add support for
> devices, which were left in-working state (with active DMA
> transactions) by bootloader, but due to some other changes in the
> order of operations during boot process, power domains are
> initialized very early and due to temporary lack of devices (which
> are not yet added to the system), are turned off. This practically
> stops FIMD for scanning framebuffer and "solves" this issue.
>
> I've checked now and Exynos Snow Chromebook boots fine with IOMMU
> support enabled, both with v4.15-rc3 and linux-next.
Then it looks like we could give EXYNOS_IOMMU a try. At least only on
exynos_defconfig which would leave multi_v7 as a platform to compare.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Krzysztof Kozlowski @ 2017-12-12 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc1rJCWABXUuyU2MKxnLY-MptrM9Mm0HyHVCJn870R+sg@mail.gmail.com>
On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
> <javierm@redhat.com> wrote:
>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>
>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>> ---
>>
>> Changes in v2:
>> - Remove RFT tag.
>
> Thanks guys! However I still would like to see a tested-by for this on
> Peach Pi (AFAIU, Marek's only acked the code/solution).
On the other hand I could just apply it for my for-next branch and
we'll see if it fixes kernel-ci boot tests... Not a nice way of
testing but apparently no one has Peach Pi.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 4/4] [v4] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Andy Shevchenko @ 2017-12-12 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512170904-4749-5-git-send-email-timur@codeaurora.org>
On Fri, 2017-12-01 at 17:28 -0600, Timur Tabi wrote:
> 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.
>
> To allow newer kernels to support older firmware, the driver retains
> support for QCOM8001.
> +static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
> + {"QCOM8001", QDF2XXX_V1},
> + {"QCOM8002", QDF2XXX_V2},
> + {},
> +};
> +MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
>
> + const struct acpi_device_id *id =
> + acpi_match_device(qdf2xxx_acpi_ids, &pdev->dev);
JFYI: there is no need to move IDs like this.
Use members of struct device_driver wisely.
> -static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
> - {"QCOM8001"},
> - {},
> -};
> -MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Mylene JOSSERAND @ 2017-12-12 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212104025.0bba3685@dell-desktop.home>
Le Tue, 12 Dec 2017 10:40:25 +0100,
Mylene JOSSERAND <mylene.josserand@free-electrons.com> a ?crit :
[...]
> I have done further tests.
>
> I booted a previous kernel that I know it was working fine (kernel
> v4.13) then, I booted the kernel with this series and it worked just
> fine.
>
> Only after a power cycle, I am able to reproduce the error, otherwise,
> it is working well. See the boot log of this two tests:
> http://code.bulix.org/7kr0e0-239697?raw
I wrote this mail too fast, I am wrong, the error I had/copied is not
the same error than Corentin is having (and I have 8 CPUS up).
--
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/4] [v2] gpiolib: add bitmask for valid GPIO lines
From: Andy Shevchenko @ 2017-12-12 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512170904-4749-3-git-send-email-timur@codeaurora.org>
On Fri, 2017-12-01 at 17:28 -0600, Timur Tabi wrote:
> Add support for specifying that some GPIOs within a range are
> unavailable.
> Some systems have a sparse list of GPIOs, where a range of GPIOs is
> specified (usually 0 to n-1), but some subset within that range is
> absent or unavailable for whatever reason.
>
> To support this, allow drivers to specify a bitmask of GPIOs that
> are present or absent. Gpiolib will then block access to those that
> are absent.
> - status = gpiochip_irqchip_init_valid_mask(chip);
> + status = gpiochip_init_valid_mask(chip);
> if (status)
> goto err_remove_from_list;
>
> + status = gpiochip_irqchip_init_valid_mask(chip);
> + if (status)
> + goto err_remove_valid_mask;
Yes, this way it looks good!
> +static bool gpiochip_available(const struct gpio_chip *gpiochip,
> + unsigned int offset)
> +{
> + pr_info("%s:%u offset=%u\n", __func__, __LINE__, offset);
Debug leftover?
> +
> + /* No mask means all valid */
> + if (likely(!gpiochip->valid_mask))
> + return true;
> +
> + return test_bit(offset, gpiochip->valid_mask);
Not sure which one is better
return test_bit();
or
return !!test_bit();
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Krzysztof Kozlowski @ 2017-12-12 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212074208.30753-1-javierm@redhat.com>
On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>
> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> ---
>
> Changes in v2:
> - Remove RFT tag.
Thanks guys! However I still would like to see a tested-by for this on
Peach Pi (AFAIU, Marek's only acked the code/solution).
Best regards,
Krzysztof
> - Add Marek's Acked-by tag.
> - Add fixes tag.
>
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index b2b95ff205e8..0029ec27819c 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -664,6 +664,10 @@
> status = "okay";
> };
>
> +&mixer {
> + status = "okay";
> +};
> +
> /* eMMC flash */
> &mmc_0 {
> status = "okay";
> --
> 2.14.3
>
^ permalink raw reply
* [BUG] atmel_ssc_dai: a possible sleep-in-atomic bug in atmel_ssc_shutdown
From: Jia-Ju Bai @ 2017-12-12 9:52 UTC (permalink / raw)
To: linux-arm-kernel
According to sound/soc/atmel/atmel_ssc_dai.c, the driver may sleep under
a spinlock.
The function call path is:
atmel_ssc_shutdown (acquire the spinlock)
free_irq --> may sleep
I do not find a good way to fix it, so I only report.
This possible bug is found by my static analysis tool (DSAC) and checked
by my code review.
Thanks,
Jia-Ju Bai
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a7796: add reg properties to pciec[01] nodes
From: Geert Uytterhoeven @ 2017-12-12 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-4-horms+renesas@verge.net.au>
On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Add reg properties to pciec[01] placeholder nodes
>
> This is to stop the compiler complaining as follows:
> $ make
> ...
> DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [Patch v6 10/12] [media] v4l2: Add v4l2 control IDs for HEVC encoder
From: Sylwester Nawrocki @ 2017-12-12 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513046086.22129.2.camel@smitha-fedora>
On 12/12/2017 03:34 AM, Smitha T Murthy wrote:
>> s/Lay/Layer here and below
>>
> Ok I will change it.
While it's fine to make such change for controls up to V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP...
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP: return "HEVC Hierarchical Lay 1 QP";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_QP: return "HEVC Hierarchical Lay 2 QP";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_QP: return "HEVC Hierarchical Lay 3 QP";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_QP: return "HEVC Hierarchical Lay 4 QP";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_QP: return "HEVC Hierarchical Lay 5 QP";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP: return "HEVC Hierarchical Lay 6 QP";
...for the controls below we may need to replace "Lay" with "L."
to make sure the length of the string don't exceed 31 characters
(32 with terminating NULL). The names below seem to be 1 character
too long and will be truncated when running VIDIOC_QUERY_CTRL ioctl.
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_BR: return "HEVC Hierarchical Lay 0 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_BR: return "HEVC Hierarchical Lay 1 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_BR: return "HEVC Hierarchical Lay 2 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_BR: return "HEVC Hierarchical Lay 3 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_BR: return "HEVC Hierarchical Lay 4 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_BR: return "HEVC Hierarchical Lay 5 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_BR: return "HEVC Hierarchical Lay 6 Bit Rate";
--
Regards,
Sylwester
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a7795: sort subnodes of root node alphabetically
From: Geert Uytterhoeven @ 2017-12-12 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082752.12806-1-horms+renesas@verge.net.au>
On Tue, Dec 12, 2017 at 9:27 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Sort root sub-nodes alphabetically for allow for easier maintenance
> of this file.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 2/3] arm64: dts: renesas: r8a7796: move nodes which have no reg property out of bus
From: Geert Uytterhoeven @ 2017-12-12 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-3-horms+renesas@verge.net.au>
Hi Simon,
On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
> The nodes that have been moved do not have any register properties and thus
> shouldn't be placed on the bus.
[...]
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
but a few minor comments below...
> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -154,6 +154,26 @@
> clock-frequency = <0>;
> };
>
> + pmu_a57 {
> + compatible = "arm,cortex-a57-pmu";
> + interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&a57_0>,
> + <&a57_1>;
> + };
> +
> + pmu_a53 {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts-extended = <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&a53_0>,
> + <&a53_1>,
> + <&a53_2>,
> + <&a53_3>;
Merge these 4 into a single line?
> @@ -2027,4 +1971,64 @@
> resets = <&cpg 822>;
> };
> };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts-extended = <&gic GIC_PPI 13
> + (GIC_CPU_MASK_SIMPLE(6) |
> + IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 14
> + (GIC_CPU_MASK_SIMPLE(6) |
> + IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 11
> + (GIC_CPU_MASK_SIMPLE(6) |
> + IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 10
> + (GIC_CPU_MASK_SIMPLE(6) |
> + IRQ_TYPE_LEVEL_LOW)>;
I think you can do a better job here, by trying not to break entries across
multiple lines ;-)
(Oops, we already have it this way in r8a7795.dtsi)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH net-next v5 1/2] net: add support for Cavium PTP coprocessor
From: Aleksey Makarov @ 2017-12-12 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211225954.ezqut6jvfg65rg4w@localhost>
Hi Richard,
On 12/12/2017 01:59 AM, Richard Cochran wrote:
>
> Sorry I didn't finish reviewing before...
>
> On Mon, Dec 11, 2017 at 05:14:30PM +0300, Aleksey Makarov wrote:
[ ... ]
>> +static int cavium_ptp_probe(struct pci_dev *pdev,
>> + const struct pci_device_id *ent)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct cavium_ptp *clock;
>> + struct cyclecounter *cc;
>> + u64 clock_cfg;
>> + u64 clock_comp;
>> + int err;
>> +
>> + clock = devm_kzalloc(dev, sizeof(*clock), GFP_KERNEL);
>> + if (!clock)
>> + return -ENOMEM;
>> +
>> + clock->pdev = pdev;
>> +
>> + err = pcim_enable_device(pdev);
>> + if (err)
>> + return err;
>> +
>> + err = pcim_iomap_regions(pdev, 1 << PCI_PTP_BAR_NO, pci_name(pdev));
>> + if (err)
>> + return err;
>> +
>> + clock->reg_base = pcim_iomap_table(pdev)[PCI_PTP_BAR_NO];
>> +
>> + spin_lock_init(&clock->spin_lock);
>> +
>> + cc = &clock->cycle_counter;
>> + cc->read = cavium_ptp_cc_read;
>> + cc->mask = CYCLECOUNTER_MASK(64);
>> + cc->mult = 1;
>> + cc->shift = 0;
>> +
>> + timecounter_init(&clock->time_counter, &clock->cycle_counter,
>> + ktime_to_ns(ktime_get_real()));
>> +
>> + clock->clock_rate = ptp_cavium_clock_get();
>> +
>> + clock->ptp_info = (struct ptp_clock_info) {
>> + .owner = THIS_MODULE,
>> + .name = "ThunderX PTP",
>> + .max_adj = 1000000000ull,
>> + .n_ext_ts = 0,
>> + .n_pins = 0,
>> + .pps = 0,
>> + .adjfreq = cavium_ptp_adjfreq,
>> + .adjtime = cavium_ptp_adjtime,
>> + .gettime64 = cavium_ptp_gettime,
>> + .settime64 = cavium_ptp_settime,
>> + .enable = cavium_ptp_enable,
>> + };
>> +
>> + clock_cfg = readq(clock->reg_base + PTP_CLOCK_CFG);
>> + clock_cfg |= PTP_CLOCK_CFG_PTP_EN;
>> + writeq(clock_cfg, clock->reg_base + PTP_CLOCK_CFG);
>> +
>> + clock_comp = ((u64)1000000000ull << 32) / clock->clock_rate;
>> + writeq(clock_comp, clock->reg_base + PTP_CLOCK_COMP);
>> +
>> + clock->ptp_clock = ptp_clock_register(&clock->ptp_info, dev);
>> + if (IS_ERR(clock->ptp_clock)) {
>
> You need to handle the case when ptp_clock_register() returns NULL.
>
> from ptp_clock_kernel.h:
>
> /**
> * ptp_clock_register() - register a PTP hardware clock driver
> *
> * @info: Structure describing the new clock.
> * @parent: Pointer to the parent device of the new clock.
> *
> * Returns a valid pointer on success or PTR_ERR on failure. If PHC
> * support is missing at the configuration level, this function
> * returns NULL, and drivers are expected to gracefully handle that
> * case separately.
> */
If ptp_clock_register() returns NULL, the device is still paired with the driver,
but the driver is not registered in the PTP core. When ethernet driver needs
the reference to this cavium PTP driver, it calls cavium_ptp_get() that checks
if ptp->ptp_clock is NULL and, if so, returns -ENODEV.
I need this behavior because I need to differentiate between two cases:
- the state when the driver is not initialized for the device because of PTP core
has not registered it. In this case function cavium_ptp_get() returns -ENODEV
and ethernet driver proceeds without PTP device.
- the state when the driver is not initialized because kernel has not tired
to initialize it yet. In this case function cavium_ptp_get() returns -EPROBE_DEFER
that is used in ethernet driver to defer initialization.
If you know how to do the same in more smoothly please share it. Or else I would
prefer to insert a comment about it and leave it as is.
Richard, thank you for review. I am going to address your comments in my next series.
Thank you
Aleksey Makarov
>> + clock_cfg = readq(clock->reg_base + PTP_CLOCK_CFG);
>> + clock_cfg &= ~PTP_CLOCK_CFG_PTP_EN;
>> + writeq(clock_cfg, clock->reg_base + PTP_CLOCK_CFG);
>> + return PTR_ERR(clock->ptp_clock);
>> + }
>> +
>> + pci_set_drvdata(pdev, clock);
>> + return 0;
>> +}
>
> Thanks,
> Richard
>
^ permalink raw reply
* [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Mylene JOSSERAND @ 2017-12-12 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211193534.GA3967@Red>
Hi,
Le Mon, 11 Dec 2017 20:35:34 +0100,
Corentin Labbe <clabbe.montjoie@gmail.com> a ?crit :
> On Mon, Dec 11, 2017 at 08:49:57AM +0100, Myl?ne Josserand wrote:
> > Hello everyone,
> >
> > This series adds SMP support for Allwinner Sun8i-a83t
> > with MCPM (Multi-Cluster Power Management).
> > Series information:
> > - Based on last linux-next (next-20171211)
> > - Had dependencies on Chen Yu's patch that add MCPM
> > support:
> > https://patchwork.kernel.org/patch/6402801/
> >
> > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > to use it for A83T. This SoC has a bit flip that needs to be
> > handled. Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg)
> > needed for MCPM.
> > Patch 03: Add CCI-400 node for a83t.
> > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > case of SMP support.
> >
> > If you have any remarks/questions, let me know.
> > Thank you in advance,
> > Myl?ne
> >
>
> Hello
>
> As we discussed in private, Chen Yu's patch should be added in your
> series.
>
> Furthermore, MCPM is not automaticaly selected via imply.
>
> With all patchs I hit a bug:
> [ 0.898668] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:238 [ 0.911162] in_atomic(): 1,
> irqs_disabled(): 0, pid: 1, name: swapper/0 [ 0.917776] CPU: 0
> PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
> [ 0.925418] Hardware name: Allwinner sun8i Family [ 0.930118]
> Backtrace: [ 0.932596] [<c010cc50>] (dump_backtrace) from
> [<c010cf0c>] (show_stack+0x18/0x1c) [ 0.940158] r7:c0b261e4
> r6:60000013 r5:00000000 r4:c0b51958 [ 0.945820] [<c010cef4>]
> (show_stack) from [<c06baccc>] (dump_stack+0x8c/0xa0) [ 0.953045]
> [<c06bac40>] (dump_stack) from [<c0149d40>]
> (___might_sleep+0x150/0x170) [ 0.960779] r7:c0b261e4 r6:00000000
> r5:000000ee r4:ee844000 [ 0.966437] [<c0149bf0>] (___might_sleep)
> from [<c0149dc8>] (__might_sleep+0x68/0xa0) [ 0.974253]
> r4:c0861690 [ 0.976796] [<c0149d60>] (__might_sleep) from
> [<c06d2918>] (mutex_lock+0x24/0x68) [ 0.984269] r6:c0892f6c
> r5:ffffffff r4:c0b1bb24 [ 0.988891] [<c06d28f4>] (mutex_lock) from
> [<c01ccb6c>] (perf_pmu_register+0x24/0x3e4) [ 0.996795]
> r5:ffffffff r4:ee98b014 [ 1.000375] [<c01ccb48>]
> (perf_pmu_register) from [<c03efabc>] (cci_pmu_probe+0x340/0x484)
> [ 1.008631] r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4
> r6:c0b26240 r5:eea19000 [ 1.016447] r4:ee98b010 [ 1.018989]
> [<c03ef77c>] (cci_pmu_probe) from [<c045e21c>]
> (platform_drv_probe+0x58/0xb8) [ 1.027158] r10:00000000
> r9:c0b2610c r8:00000000 r7:fffffdfb r6:c0b2610c r5:ffffffed
> [ 1.034974] r4:eea19010 [ 1.037511] [<c045e1c4>]
> (platform_drv_probe) from [<c045c984>]
> (driver_probe_device+0x254/0x330) [ 1.046371] r7:00000000
> r6:c0bff498 r5:c0bff494 r4:eea19010 [ 1.052026] [<c045c730>]
> (driver_probe_device) from [<c045cbc4>]
> (__device_attach_driver+0xa0/0xd4) [ 1.061062] r10:00000000
> r9:c0bff470 r8:00000000 r7:00000001 r6:eea19010 r5:ee845ac0
> [ 1.068879] r4:c0b2610c r3:00000000 [ 1.072454] [<c045cb24>]
> (__device_attach_driver) from [<c045ad68>]
> (bus_for_each_drv+0x68/0x9c) [ 1.081228] r7:00000001 r6:c045cb24
> r5:ee845ac0 r4:00000000 [ 1.086883] [<c045ad00>]
> (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.095135] r6:c0b3e848 r5:eea19044 r4:eea19010 [ 1.099750]
> [<c045c554>] (__device_attach) from [<c045cc44>]
> (device_initial_probe+0x14/0x18) [ 1.108263] r7:c0b0a4c8
> r6:c0b3e848 r5:eea19010 r4:eea19018 [ 1.113919] [<c045cc30>]
> (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.122523] [<c045bacc>] (bus_probe_device) from [<c0459db8>]
> (device_add+0x40c/0x5a0) [ 1.130429] r7:c0b0a4c8 r6:eea19010
> r5:eea18a10 r4:eea19018 [ 1.136089] [<c04599ac>] (device_add) from
> [<c0582a58>] (of_device_add+0x3c/0x44) [ 1.143564] r10:00000000
> r9:00000000 r8:00000000 r7:eedf21a4 r6:eea18a10 r5:00000000
> [ 1.151380] r4:eea19000 [ 1.153915] [<c0582a1c>]
> (of_device_add) from [<c0582f80>]
> (of_platform_device_create_pdata+0x7c/0xac) [ 1.163210]
> [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>]
> (of_platform_bus_create+0xf4/0x1f0) [ 1.173372] r9:00000000
> r8:00000000 r7:00000001 r6:00000000 r5:eedf2154 r4:00000000
> [ 1.181107] [<c058300c>] (of_platform_bus_create) from
> [<c0583374>] (of_platform_populate+0x74/0xd4) [ 1.190229]
> r10:00000001 r9:eea18a10 r8:00000000 r7:00000000 r6:00000000
> r5:eedf1d04 [ 1.198045] r4:eedf2154 [ 1.200580] [<c0583300>]
> (of_platform_populate) from [<c03ef2a8>]
> (cci_platform_probe+0x3c/0x54) [ 1.209356] r10:00000000
> r9:c0b26168 r8:00000000 r7:fffffdfb r6:c0b26168 r5:ffffffed
> [ 1.217172] r4:eea18a00 [ 1.219708] [<c03ef26c>]
> (cci_platform_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> [ 1.228306] r5:ffffffed r4:eea18a10 [ 1.231881] [<c045e1c4>]
> (platform_drv_probe) from [<c045c984>]
> (driver_probe_device+0x254/0x330) [ 1.240742] r7:00000000
> r6:c0bff498 r5:c0bff494 r4:eea18a10 [ 1.246397] [<c045c730>]
> (driver_probe_device) from [<c045cbc4>]
> (__device_attach_driver+0xa0/0xd4) [ 1.255433] r10:00000000
> r9:c0bff470 r8:00000000 r7:00000001 r6:eea18a10 r5:ee845ce8
> [ 1.263250] r4:c0b26168 r3:00000000 [ 1.266825] [<c045cb24>]
> (__device_attach_driver) from [<c045ad68>]
> (bus_for_each_drv+0x68/0x9c) [ 1.275598] r7:00000001 r6:c045cb24
> r5:ee845ce8 r4:00000000 [ 1.281253] [<c045ad00>]
> (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.289506] r6:c0b3e848 r5:eea18a44 r4:eea18a10 [ 1.294120]
> [<c045c554>] (__device_attach) from [<c045cc44>]
> (device_initial_probe+0x14/0x18) [ 1.302633] r7:c0b0a4c8
> r6:c0b3e848 r5:eea18a10 r4:eea18a18 [ 1.308288] [<c045cc30>]
> (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.316890] [<c045bacc>] (bus_probe_device) from [<c0459db8>]
> (device_add+0x40c/0x5a0) [ 1.324796] r7:c0b0a4c8 r6:eea18a10
> r5:ee993810 r4:eea18a18 [ 1.330450] [<c04599ac>] (device_add) from
> [<c0582a58>] (of_device_add+0x3c/0x44) [ 1.337926] r10:00000000
> r9:c07759d8 r8:00000000 r7:eedf1d54 r6:ee993810 r5:00000000
> [ 1.345743] r4:eea18a00 [ 1.348277] [<c0582a1c>]
> (of_device_add) from [<c0582f80>]
> (of_platform_device_create_pdata+0x7c/0xac) [ 1.357572]
> [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>]
> (of_platform_bus_create+0xf4/0x1f0) [ 1.367734] r9:c07759d8
> r8:00000000 r7:00000001 r6:00000000 r5:eedf1d04 r4:00000000
> [ 1.375469] [<c058300c>] (of_platform_bus_create) from
> [<c058315c>] (of_platform_bus_create+0x150/0x1f0) [ 1.384938]
> r10:ee993810 r9:c07759d8 r8:00000000 r7:00000001 r6:00000000
> r5:eedefe1c [ 1.392754] r4:eedf1d04 [ 1.395289] [<c058300c>]
> (of_platform_bus_create) from [<c0583374>]
> (of_platform_populate+0x74/0xd4) [ 1.404411] r10:00000001
> r9:00000000 r8:00000000 r7:c07759d8 r6:00000000 r5:eedee844
> [ 1.412228] r4:eedefe1c [ 1.414769] [<c0583300>]
> (of_platform_populate) from [<c0a25ee8>]
> (of_platform_default_populate_init+0x80/0x94) [ 1.424844]
> r10:c0a37848 r9:00000000 r8:c0b59680 r7:c0a37834 r6:ffffe000
> r5:c0775ce8 [ 1.432661] r4:00000000 [ 1.435200] [<c0a25e68>]
> (of_platform_default_populate_init) from [<c0102794>]
> (do_one_initcall+0x5c/0x194) [ 1.444925] r5:c0a25e68 r4:c0b0a4c8
> [ 1.448506] [<c0102738>] (do_one_initcall) from [<c0a00f88>]
> (kernel_init_freeable+0x1d4/0x268) [ 1.457195] r9:00000004
> r8:c0b59680 r7:c0a37834 r6:c0b59680 r5:c0a47308 r4:c090cfb8
> [ 1.464932] [<c0a00db4>] (kernel_init_freeable) from [<c06cf3b0>]
> (kernel_init+0x10/0x118) [ 1.473187] r10:00000000 r9:00000000
> r8:00000000 r7:00000000 r6:00000000 r5:c06cf3a0 [ 1.481004]
> r4:00000000 [ 1.483540] [<c06cf3a0>] (kernel_init) from
> [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 1.491098] Exception
> stack(0xee845fb0 to 0xee845ff8) [ 1.496146]
> 5fa0: 00000000 00000000 00000000
> 00000000 [ 1.504313] 5fc0: 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 [ 1.512480] 5fe0: 00000000
> 00000000 00000000 00000000 00000013 00000000 [ 1.519084]
> r5:c06cf3a0 r4:00000000 [ 1.522737] ARM CCI_400_r1 PMU driver
> probed
I have done further tests.
I booted a previous kernel that I know it was working fine (kernel
v4.13) then, I booted the kernel with this series and it worked just
fine.
Only after a power cycle, I am able to reproduce the error, otherwise,
it is working well. See the boot log of this two tests:
http://code.bulix.org/7kr0e0-239697?raw
So I really tested this series but I did not do any power-cycle between
my tests (only reboots). I will investigate on it.
Best regards,
--
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] mmc: sdhci-of-arasan: Disable clk_xin clock in the remove
From: Michal Simek @ 2017-12-12 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081955.2309-1-flavio.ceolin@intel.com>
On 12.12.2017 09:19, Flavio Ceolin wrote:
> clk_xin is properly prepared/enabled on sdhci_arasan_probe(), and
> unprepared/disabled in the error path, but it is not being
> unprepared/disabled on sdhci_arasan_remove().
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 0720ea7..69bd260 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -692,6 +692,7 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
> struct clk *clk_ahb = sdhci_arasan->clk_ahb;
> + struct clk *clk_xin = devm_clk_get(&pdev->dev, "clk_xin");
I don't think this is right. You have already asked for this clock in
probe. It means you should reuse pltfm_host->clk = clk_xin;
And if you look at sdhci_pltfm_unregister you will find out that
clk_disable_unprepare(pltfm_host->clk);
is called there.
>
> if (!IS_ERR(sdhci_arasan->phy)) {
> if (sdhci_arasan->is_phy_on)
> @@ -705,6 +706,9 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
>
> clk_disable_unprepare(clk_ahb);
>
> + if (!IS_ERR(clk_xin))
And clk_xin is required property.
> + clk_disable_unprepare(clk_xin);
> +
> return ret;
> }
>
>
It means NACK from me.
Thanks,
Michal
^ permalink raw reply
* [PATCH v1 4/4] arm64: dts: mediatek: add mt2712 cpufreq related device nodes
From: Matthias Brugger @ 2017-12-12 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212072625.GL25177@vireshk-i7>
Hi,
On 12/12/2017 08:26 AM, Viresh Kumar wrote:
> On 12-12-17, 02:17, Rafael J. Wysocki wrote:
>> On Monday, December 11, 2017 8:57:19 AM CET Viresh Kumar wrote:
>>> On 08-12-17, 14:07, Andrew-sh Cheng wrote:
>>>> Add opp v2 information,
>>>> and also add clocks, regulators and opp information into cpu nodes
>>>>
>>>> Signed-off-by: Andrew-sh Cheng <andrew-sh.cheng@mediatek.com>
>>>> ---
>>>> arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 27 ++++++++++++++
>>>> arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 57 +++++++++++++++++++++++++++++
>>>> 2 files changed, 84 insertions(+)
>>>
>>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>>
>> Of course, DT bindings require ACKs from DT maintainers to be applied.
>
> I didn't knew that we need Acks from DT maintainers for dts files as well? Yeah,
> its very much required while defining new bindings for sure.
>
I will take the dts parts through the Mediatek SoC tree, so you don't have to
worry about them.
Please let me know when you take patch 1 and 2.
Regards,
Matthias
^ permalink raw reply
* [PATCH 1/3] arm64: dts: renesas: r8a7796: sort subnodes of root node alphabetically
From: Geert Uytterhoeven @ 2017-12-12 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-2-horms+renesas@verge.net.au>
On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Sort root sub-nodes alphabetically for allow for easier maintenance
> of this file.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 2/2] ARM: dts: vf610-zii-dev: use XAUI for DSA link ports
From: Russell King @ 2017-12-12 9:29 UTC (permalink / raw)
To: linux-arm-kernel
Use XAUI rather than XGMII for DSA link ports, as this is the interface
mode that the switches actually use. XAUI is the 4 lane bus with clock
per direction, whereas XGMII is a 32 bit bus with clock.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
This must be applied along with patch 1 to avoid breakage.
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
index 1b102c7f7928..4a972fceb3b5 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
@@ -128,7 +128,7 @@
switch0port10: port at 10 {
reg = <10>;
label = "dsa";
- phy-mode = "xgmii";
+ phy-mode = "xaui";
link = <&switch1port10>;
};
};
@@ -233,7 +233,7 @@
switch1port10: port at 10 {
reg = <10>;
label = "dsa";
- phy-mode = "xgmii";
+ phy-mode = "xaui";
link = <&switch0port10>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] net: dsa: allow XAUI phy interface mode
From: Russell King @ 2017-12-12 9:29 UTC (permalink / raw)
To: linux-arm-kernel
XGMII is a 32-bit bus plus two clock signals per direction. XAUI is
four serial lanes per direction. The 88e6190 supports XAUI but not
XGMII as it doesn't have enough pins. The same is true of 88e6176.
Match on PHY_INTERFACE_MODE_XAUI for the XAUI port type, but keep
accepting XGMII for backwards compatibility.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/dsa/mv88e6xxx/port.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index a7801f6668a5..6315774d72b3 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -338,6 +338,7 @@ int mv88e6390x_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
cmode = MV88E6XXX_PORT_STS_CMODE_2500BASEX;
break;
case PHY_INTERFACE_MODE_XGMII:
+ case PHY_INTERFACE_MODE_XAUI:
cmode = MV88E6XXX_PORT_STS_CMODE_XAUI;
break;
case PHY_INTERFACE_MODE_RXAUI:
--
2.7.4
^ permalink raw reply related
* [PATCH] divers/soc/ti: fix max dup length for kstrndup
From: Ma Shimiao @ 2017-12-12 9:29 UTC (permalink / raw)
To: linux-arm-kernel
If source string longer than max, kstrndup will alloc max+1 space.
So, we should make sure the result will not over limit.
Signed-off-by: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
---
drivers/soc/ti/knav_qmss_queue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 39225de9d7f1..77d6b5c03aae 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -225,7 +225,7 @@ static struct knav_queue *__knav_queue_open(struct knav_queue_inst *inst,
if (!knav_queue_is_busy(inst)) {
struct knav_range_info *range = inst->range;
- inst->name = kstrndup(name, KNAV_NAME_SIZE, GFP_KERNEL);
+ inst->name = kstrndup(name, KNAV_NAME_SIZE - 1, GFP_KERNEL);
if (range->ops && range->ops->open_queue)
ret = range->ops->open_queue(range, inst, flags);
@@ -779,7 +779,7 @@ void *knav_pool_create(const char *name,
goto err;
}
- pool->name = kstrndup(name, KNAV_NAME_SIZE, GFP_KERNEL);
+ pool->name = kstrndup(name, KNAV_NAME_SIZE - 1, GFP_KERNEL);
pool->kdev = kdev;
pool->dev = kdev->dev;
--
2.13.6
^ permalink raw reply related
* [PATCH] rcutorture: Add basic ARM64 support to run scripts
From: Lihao Liang @ 2017-12-12 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211163243.GR7829@linux.vnet.ibm.com>
Hi Paul,
Many thanks for your helpful comments! I have addressed all of them in a new version of the patch, which is sent out in a separate email.
If you have further comments, please let me know.
Best regards,
Lihao.
On 2017/12/12 0:32, Paul E. McKenney wrote:
> On Fri, Dec 08, 2017 at 06:13:43PM +0800, lianglihao at huawei.com wrote:
>> From: Lihao Liang <lianglihao@huawei.com>
>>
>> This commit adds support of the qemu command qemu-system-aarch64
>> to rcutorture. Use the following command to run:
>>
>> ./kvm.sh --qemu-cmd qemu-system-aarch64
>>
>> Signed-off-by: Lihao Liang <lianglihao@huawei.com>
>
> Nice!!! Getting ARM support for rcutorture has been on my todo list
> for some time!
>
> A few questions and comments below.
>
> Feedback from ARM experts also welcome!
>
> Thanx, Paul
>
>> ---
>>
>> The max CPUs supported by qemu machine 'virt' is 8 so the value of
>> CONFIG_NR_CPUS in some test configuration files needs to be adjusted.
>>
>> tools/testing/selftests/rcutorture/bin/functions.sh | 18 +++++++++++++++++-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
>> index 07a1377..5ffe4fe 100644
>> --- a/tools/testing/selftests/rcutorture/bin/functions.sh
>> +++ b/tools/testing/selftests/rcutorture/bin/functions.sh
>> @@ -136,6 +136,9 @@ identify_boot_image () {
>> qemu-system-x86_64|qemu-system-i386)
>> echo arch/x86/boot/bzImage
>> ;;
>> + qemu-system-aarch64)
>> + echo arch/arm64/boot/Image
>> + ;;
>> *)
>> echo vmlinux
>> ;;
>
> Is it possible to automatically select ARM based on the kernel binary?
> See the identify_qemu function for how this is done for i386, x86_64,
> and PowerPC. Can an "elif" be added for ARM?
>
>> @@ -185,7 +188,14 @@ identify_qemu_append () {
>> then
>> echo root=/dev/sda
>> else
>> - echo console=ttyS0
>> + case "$1" in
>> + qemu-system-aarch64)
>> + echo console=ttyAMA0
>> + ;;
>> + *)
>> + echo console=ttyS0
>> + ;;
>> + esac
>> fi
>> }
>
> This approach is going to result in very ugly nesting if support is
> added for additional CPU families. How about something like this?
>
> identify_qemu_append () {
> local console=ttyS0
>
> case "$1" in
> qemu-system-x86_64|qemu-system-i386)
> echo noapic selinux=0 initcall_debug debug
> ;;
> qemu-system-aarch64)
> console=ttyAMA0
> ;;
> esac
> if test -n "$TORTURE_QEMU_INTERACTIVE"
> then
> echo root=/dev/sda
> else
> echo console=$console
> fi
> }
>
>> @@ -197,6 +207,9 @@ identify_qemu_args () {
>> case "$1" in
>> qemu-system-x86_64|qemu-system-i386)
>> ;;
>> + qemu-system-aarch64)
>> + echo -M virt -cpu host
>> + ;;
>> qemu-system-ppc64)
>> echo -enable-kvm -M pseries -nodefaults
>> echo -device spapr-vscsi
>> @@ -257,6 +270,9 @@ specify_qemu_cpus () {
>> qemu-system-x86_64|qemu-system-i386)
>
> How about the following instead, eliminating the need for an additional
> case?
>
> qemu-system-x86_64|qemu-system-i386!qemu-system-aarch64)
>
>> echo $2 -smp $3
>> ;;
>> + qemu-system-aarch64)
>> + echo $2 -smp $3
>> + ;;
>> qemu-system-ppc64)
>> nt="`lscpu | grep '^NUMA node0' | sed -e 's/^[^,]*,\([0-9]*\),.*$/\1/'`"
>> echo $2 -smp cores=`expr \( $3 + $nt - 1 \) / $nt`,threads=$nt
>> --
>> 2.7.4
>>
>
>
> .
>
^ permalink raw reply
* [PATCH] arm64: allwinner: a64: a64-olinuxino: add usb otg
From: Jagan Teki @ 2017-12-12 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081335.3qkqcofdbcfuu5zh@flea.lan>
On Tue, Dec 12, 2017 at 1:43 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Tue, Dec 12, 2017 at 11:26:09AM +0530, Jagan Teki wrote:
>> Add usb otg support for a64-olinuxino board,
>> - USB0-ID connected with PH9
>> - USB0-VBUSDET connected with PH6
>> - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>
> How was this tested? Did you test the OTG part, or only the peripheral
> part?
Yes peripheral.
^ permalink raw reply
* [PATCH v7 8/8] KVM: arm/arm64: Avoid work when userspace iqchips are not used
From: Auger Eric @ 2017-12-12 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207105418.22428-9-christoffer.dall@linaro.org>
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> We currently check if the VM has a userspace irqchip on every exit from
> the VCPU, and if so, we do some work to ensure correct timer behavior.
> This is unfortunate, as we could avoid doing any work entirely, if we
> didn't have to support irqchip in userspace.
>
> Realizing the userspace irqchip on ARM is mostly a developer or hobby
> feature, and is unlikely to be used in servers or other scenarios where
> performance is a priority, we can use a refcounted static key to only
> check the irqchip configuration when we have at least one VM that uses
> an irqchip in userspace.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
> ---
> virt/kvm/arm/arch_timer.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 82d4963f63b8..df21451e7654 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -51,6 +51,8 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
> struct arch_timer_context *timer_ctx);
> static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx);
>
> +static DEFINE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
> +
> u64 kvm_phys_timer_read(void)
> {
> return timecounter->cc->read(timecounter->cc);
> @@ -569,7 +571,8 @@ static void unmask_vtimer_irq_user(struct kvm_vcpu *vcpu)
> */
> void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
> {
> - unmask_vtimer_irq_user(vcpu);
> + if (static_branch_unlikely(&userspace_irqchip_in_use))
> + unmask_vtimer_irq_user(vcpu);
> }
>
> int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
> @@ -774,6 +777,8 @@ void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu)
> soft_timer_cancel(&timer->bg_timer, &timer->expired);
> soft_timer_cancel(&timer->phys_timer, NULL);
> kvm_vgic_unmap_phys_irq(vcpu, vtimer->irq.irq);
> + if (timer->enabled && !irqchip_in_kernel(vcpu->kvm))
> + static_branch_dec(&userspace_irqchip_in_use);
> }
>
> static bool timer_irqs_are_valid(struct kvm_vcpu *vcpu)
> @@ -826,8 +831,10 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
> return 0;
>
> /* Without a VGIC we do not map virtual IRQs to physical IRQs */
> - if (!irqchip_in_kernel(vcpu->kvm))
> + if (!irqchip_in_kernel(vcpu->kvm)) {
> + static_branch_inc(&userspace_irqchip_in_use);
> goto no_vgic;
> + }
>
> if (!vgic_initialized(vcpu->kvm))
> return -ENODEV;
>
^ permalink raw reply
* [PATCH v2] rcutorture: Add basic ARM64 support to run scripts
From: lianglihao at huawei.com @ 2017-12-12 9:19 UTC (permalink / raw)
To: linux-arm-kernel
From: Lihao Liang <lianglihao@huawei.com>
This commit adds support of the qemu command qemu-system-aarch64
to rcutorture.
Signed-off-by: Lihao Liang <lianglihao@huawei.com>
---
This commit is against RCU's git tree rcu/dev branch
commit 505b61b2ec1d ("EXP: rcu: Add debugging info to other assertion")
Note that the max CPUs supported by qemu machine 'virt' is 8 so the value of
CONFIG_NR_CPUS in some test configuration files needs to be adjusted.
tools/testing/selftests/rcutorture/bin/functions.sh | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
index 07a1377..0541d10 100644
--- a/tools/testing/selftests/rcutorture/bin/functions.sh
+++ b/tools/testing/selftests/rcutorture/bin/functions.sh
@@ -136,6 +136,9 @@ identify_boot_image () {
qemu-system-x86_64|qemu-system-i386)
echo arch/x86/boot/bzImage
;;
+ qemu-system-aarch64)
+ echo arch/arm64/boot/Image
+ ;;
*)
echo vmlinux
;;
@@ -158,6 +161,9 @@ identify_qemu () {
elif echo $u | grep -q "Intel 80386"
then
echo qemu-system-i386
+ elif echo $u | grep -q aarch64
+ then
+ echo qemu-system-aarch64
elif uname -a | grep -q ppc64
then
echo qemu-system-ppc64
@@ -176,16 +182,20 @@ identify_qemu () {
# Output arguments for the qemu "-append" string based on CPU type
# and the TORTURE_QEMU_INTERACTIVE environment variable.
identify_qemu_append () {
+ local console=ttyS0
case "$1" in
qemu-system-x86_64|qemu-system-i386)
echo noapic selinux=0 initcall_debug debug
;;
+ qemu-system-aarch64)
+ console=ttyAMA0
+ ;;
esac
if test -n "$TORTURE_QEMU_INTERACTIVE"
then
echo root=/dev/sda
else
- echo console=ttyS0
+ echo console=$console
fi
}
@@ -197,6 +207,9 @@ identify_qemu_args () {
case "$1" in
qemu-system-x86_64|qemu-system-i386)
;;
+ qemu-system-aarch64)
+ echo -M virt -cpu host
+ ;;
qemu-system-ppc64)
echo -enable-kvm -M pseries -nodefaults
echo -device spapr-vscsi
@@ -254,7 +267,7 @@ specify_qemu_cpus () {
echo $2
else
case "$1" in
- qemu-system-x86_64|qemu-system-i386)
+ qemu-system-x86_64|qemu-system-i386|qemu-system-aarch64)
echo $2 -smp $3
;;
qemu-system-ppc64)
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v5 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Philippe Ombredanne @ 2017-12-12 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA93ih0C-aMpFAhU+5x6P=QjiOVRPZ0UL1wyKh1oeXzC8UjPXQ@mail.gmail.com>
Dear Masami-san,
On Tue, Dec 12, 2017 at 3:29 AM, Masami Hiramatsu
<masami.hiramatsu@linaro.org> wrote:
[...]
> Then what I'm considering is copyright notice lines. Those are usually
> treat as the header lines, not single line. So
>
>> +// SDPX-License-Identifier: GPL-2.0
>> +// sni_ave.c - Socionext UniPhier AVE ethernet driver
>> +// Copyright 2014 Panasonic Corporation
>> +// Copyright 2015-2017 Socionext Inc.
>
> is acceptable? or should we keep C-style header lines for new drivers?
>
>> +// SDPX-License-Identifier: GPL-2.0
>> +/*
>> + * sni_ave.c - Socionext UniPhier AVE ethernet driver
>> + * Copyright 2014 Panasonic Corporation
>> + * Copyright 2015-2017 Socionext Inc.
>> + */
>
> I just concern that those lines are not "single". that's all. :)
My voice carries the weight of a down feather in this discussion and
to me the benefit of the first form is that you have removed two
lines. Both forms work fine.
--
Cordially
Philippe Ombredanne
^ 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