* Applied "ASoC: rockchip: i2s: Support mono capture" to the asoc tree
From: Mark Brown @ 2018-01-08 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105221242.22083-1-mka@chromium.org>
The patch
ASoC: rockchip: i2s: Support mono capture
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From db51707b9c9aeedd310ebce60f15d5bb006567e0 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka@chromium.org>
Date: Fri, 5 Jan 2018 14:12:42 -0800
Subject: [PATCH] ASoC: rockchip: i2s: Support mono capture
The Rockchip I2S controller only allows to configure even numbers of
capture channels. It is still possible to capture monophonic audio by
using dual-channel mode and ignoring the 'data' from the second
channel.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/rockchip/rockchip_i2s.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c
index 908211e1d6fc..cc22ab3d10dd 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -328,6 +328,7 @@ static int rockchip_i2s_hw_params(struct snd_pcm_substream *substream,
val |= I2S_CHN_4;
break;
case 2:
+ case 1:
val |= I2S_CHN_2;
break;
default:
@@ -460,7 +461,7 @@ static struct snd_soc_dai_driver rockchip_i2s_dai = {
},
.capture = {
.stream_name = "Capture",
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_192000,
.formats = (SNDRV_PCM_FMTBIT_S8 |
@@ -654,7 +655,7 @@ static int rockchip_i2s_probe(struct platform_device *pdev)
}
if (!of_property_read_u32(node, "rockchip,capture-channels", &val)) {
- if (val >= 2 && val <= 8)
+ if (val >= 1 && val <= 8)
soc_dai->capture.channels_max = val;
}
--
2.15.1
^ permalink raw reply related
* [PATCH] soc: xilinx: Create folder structure for soc specific drivers
From: Michal Simek @ 2018-01-08 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c7bb89056326f42fb646ad00b27b841af3de69c1.1513689828.git.michal.simek@xilinx.com>
On 19.12.2017 14:23, Michal Simek wrote:
> Create directory structure with Makefile/Kconfig for adding xilinx soc
> specific drivers.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> This patch is done based on discussion ended here
> https://lkml.org/lkml/2017/12/18/565
>
> ---
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/xilinx/Kconfig | 4 ++++
> drivers/soc/xilinx/Makefile | 1 +
> 4 files changed, 7 insertions(+)
> create mode 100644 drivers/soc/xilinx/Kconfig
> create mode 100644 drivers/soc/xilinx/Makefile
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index fc9e98047421..c07b4a85253f 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -16,6 +16,7 @@ source "drivers/soc/tegra/Kconfig"
> source "drivers/soc/ti/Kconfig"
> source "drivers/soc/ux500/Kconfig"
> source "drivers/soc/versatile/Kconfig"
> +source "drivers/soc/xilinx/Kconfig"
> source "drivers/soc/zte/Kconfig"
>
> endmenu
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index deecb16e7256..61c584d9d619 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -22,4 +22,5 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_SOC_TI) += ti/
> obj-$(CONFIG_ARCH_U8500) += ux500/
> obj-$(CONFIG_PLAT_VERSATILE) += versatile/
> +obj-y += xilinx/
> obj-$(CONFIG_ARCH_ZX) += zte/
> diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig
> new file mode 100644
> index 000000000000..ffaaa2f42c7e
> --- /dev/null
> +++ b/drivers/soc/xilinx/Kconfig
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +menu "Xilinx SoC drivers"
> +
> +endmenu
> diff --git a/drivers/soc/xilinx/Makefile b/drivers/soc/xilinx/Makefile
> new file mode 100644
> index 000000000000..f66554cd5c45
> --- /dev/null
> +++ b/drivers/soc/xilinx/Makefile
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180108/2b9e98a4/attachment.sig>
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Michal Simek @ 2018-01-08 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9614a2cb-66bf-6689-e6ac-abd24a71bb04@xilinx.com>
Hi Mauro,
On 18.12.2017 08:32, Michal Simek wrote:
> Hi guys,
>
> On 15.12.2017 10:27, Mauro Carvalho Chehab wrote:
>> Em Fri, 15 Dec 2017 10:55:26 +0530
>> Dhaval Shah <dhaval23031987@gmail.com> escreveu:
>>
>>> Hi Laurent/Mauro/Greg,
>>>
>>> On Fri, Dec 15, 2017 at 3:32 AM, Laurent Pinchart
>>> <laurent.pinchart@ideasonboard.com> wrote:
>>>> Hi Mauro,
>>>>
>>>> On Thursday, 14 December 2017 23:50:03 EET Mauro Carvalho Chehab wrote:
>>>>> Em Thu, 14 Dec 2017 21:57:06 +0100 Greg KH escreveu:
>>>>>> On Thu, Dec 14, 2017 at 10:44:16PM +0200, Laurent Pinchart wrote:
>>>>>>> On Thursday, 14 December 2017 22:08:51 EET Greg KH wrote:
>>>>>>>> On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
>>>>>>>>> On Thursday, 14 December 2017 20:54:39 EET Joe Perches wrote:
>>>>>>>>>> On Thu, 2017-12-14 at 20:37 +0200, Laurent Pinchart wrote:
>>>>>>>>>>> On Thursday, 14 December 2017 20:32:20 EET Joe Perches wrote:
>>>>>>>>>>>> On Thu, 2017-12-14 at 20:28 +0200, Laurent Pinchart wrote:
>>>>>>>>>>>>> On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
>>>>>>>>>>>>>>> SPDX-License-Identifier is used for the Xilinx Video IP and
>>>>>>>>>>>>>>> related drivers.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Dhaval,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You're not listed as one of the Xilinx driver maintainers. I'm
>>>>>>>>>>>>>> afraid that, without their explicit acks, sent to the ML, I
>>>>>>>>>>>>>> can't accept a patch touching at the driver's license tags.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The patch doesn't change the license, I don't see why it would
>>>>>>>>>>>>> cause any issue. Greg isn't listed as the maintainer or copyright
>>>>>>>>>>>>> holder of any of the 10k+ files to which he added an SPDX license
>>>>>>>>>>>>> header in the last kernel release.
>>>>>>>>>>>>
>>>>>>>>>>>> Adding a comment line that describes an implicit or
>>>>>>>>>>>> explicit license is different than removing the license
>>>>>>>>>>>> text itself.
>>>>>>>>>>>
>>>>>>>>>>> The SPDX license header is meant to be equivalent to the license
>>>>>>>>>>> text.
>>>>>>>>>>
>>>>>>>>>> I understand that.
>>>>>>>>>> At a minimum, removing BSD license text is undesirable
>>>>>>>>>>
>>>>>>>>>> as that license states:
>>>>>>>>>> * * Redistributions of source code must retain the above copyright
>>>>>>>>>> * notice, this list of conditions and the following disclaimer.
>>>>>>>>>>
>>>>>>>>>> etc...
>>>>>>>>>
>>>>>>>>> But this patch only removes the following text:
>>>>>>>>>
>>>>>>>>> - * This program is free software; you can redistribute it and/or
>>>>>>>>> modify
>>>>>>>>> - * it under the terms of the GNU General Public License version 2 as
>>>>>>>>> - * published by the Free Software Foundation.
>>>>>>>>>
>>>>>>>>> and replaces it by the corresponding SPDX header.
>>>>>>>>>
>>>>>>>>>>> The only reason why the large SPDX patch didn't touch the whole
>>>>>>>>>>> kernel in one go was that it was easier to split in in multiple
>>>>>>>>>>> chunks.
>>>>>>>>>>
>>>>>>>>>> Not really, it was scripted.
>>>>>>>>>
>>>>>>>>> But still manually reviewed as far as I know.
>>>>>>>>>
>>>>>>>>>>> This is no different than not including the full GPL license in
>>>>>>>>>>> every header file but only pointing to it through its name and
>>>>>>>>>>> reference, as every kernel source file does.
>>>>>>>>>>
>>>>>>>>>> Not every kernel source file had a license text
>>>>>>>>>> or a reference to another license file.
>>>>>>>>>
>>>>>>>>> Correct, but the files touched by this patch do.
>>>>>>>>>
>>>>>>>>> This issue is in no way specific to linux-media and should be
>>>>>>>>> decided upon at the top level, not on a per-subsystem basis. Greg,
>>>>>>>>> could you comment on this ?
>>>>>>>>
>>>>>>>> Comment on what exactly? I don't understand the problem here, care to
>>>>>>>> summarize it?
>>>>>>>
>>>>>>> In a nutshell (if I understand it correctly), Dhaval Shah submitted
>>>>>>> https:// patchwork.kernel.org/patch/10102451/ which replaces
>>>>>>>
>>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>>> [...]
>>>>>>> - *
>>>>>>> - * This program is free software; you can redistribute it and/or modify
>>>>>>> - * it under the terms of the GNU General Public License version 2 as
>>>>>>> - * published by the Free Software Foundation.
>>>>>>>
>>>>>>> in all .c and .h files of the Xilinx V4L2 driver
>>>>>>> (drivers/media/platform/
>>>>>>> xilinx). I have reviewed the patch and acked it. Mauro then rejected it,
>>>>>>> stating that he can't accept a change to license text without an
>>>>>>> explicit ack from the official driver's maintainers. My position is
>>>>>>> that such a change doesn't change the license and thus doesn't need to
>>>>>>> track all copyright holders, and can be merged without an explicit ack
>>>>>>> from the respective maintainers.
>>>>>>
>>>>>> Yes, I agree with you, no license is being changed here, and no
>>>>>> copyright is either.
>>>>>>
>>>>>> BUT, I know that most major companies are reviewing this process right
>>>>>> now. We have gotten approval from almost all of the major kernel
>>>>>> developer companies to do this, which is great, and supports this work
>>>>>> as being acceptable.
>>>>>>
>>>>>> So it's nice to ask Xilinx if they object to this happening, which I
>>>>>> guess Mauro is trying to say here (in not so many words...) To at least
>>>>>> give them the heads-up that this is what is going to be going on
>>>>>> throughout the kernel tree soon, and if they object, it would be good to
>>>>>> speak up as to why (and if they do, I can put their lawyers in contact
>>>>>> with some lawyers to explain it all to them.)
>>>>>
>>>>> Yes, that's basically what I'm saying.
>>>>>
>>>>> I don't feel comfortable on signing a patch changing the license text
>>>>> without giving the copyright owners an opportunity and enough time
>>>>> to review it and approve, or otherwise comment about such changes.
>>>>
>>>> If I understand you and Greg correctly, you would like to get a general
>>>> approval from Xilinx for SPDX-related changes, but that would be a blanket
>>>> approval that would cover this and all subsequent similar patches. Is that
>>>> correct ? That is reasonable for me.
>>>>
>>>> In that case, could the fact that commit
>>>>
>>>> commit 5fd54ace4721fc5ce2bb5aef6318fcf17f421460
>>>> Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>> Date: Fri Nov 3 11:28:30 2017 +0100
>>>>
>>>> USB: add SPDX identifiers to all remaining files in drivers/usb/
>>>>
>>>> add SPDX headers to several Xilinx-authored source files constitute such a
>>>> blanket approval ?
>>>>
>>> I have to do anything here or Once, we get approval from the Michal
>>> Simek(michal.simek at xilinx.com) and Hyun.kwon at xilinx.com ACK this patch
>>> then it will go into mainline?
>>
>> I would wait for their feedback.
>
> Please do not apply this patch till I get approval from legal. I have
> already discussed things about SPDX some weeks ago.
There is no concern from xilinx legal about this change that's why
Acked-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michal
^ permalink raw reply
* [PATCH v2 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks
From: James Morse @ 2018-01-08 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515157961-20963-8-git-send-email-will.deacon@arm.com>
Hi Will, Marc,
On 05/01/18 13:12, Will Deacon wrote:
> Aliasing attacks against CPU branch predictors can allow an attacker to
> redirect speculative control flow on some CPUs and potentially divulge
> information from one context to another.
>
> This patch adds initial skeleton code behind a new Kconfig option to
> enable implementation-specific mitigations against these attacks for
> CPUs that are affected.
[...]
> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
> index 6f7bdb89817f..6dd83d75b82a 100644
> --- a/arch/arm64/include/asm/mmu.h
> +++ b/arch/arm64/include/asm/mmu.h
> @@ -41,6 +41,43 @@ static inline bool arm64_kernel_unmapped_at_el0(void)
> +static inline struct bp_hardening_data *arm64_get_bp_hardening_data(void)
> +{
> + return this_cpu_ptr(&bp_hardening_data);
> +}
> +
> +static inline void arm64_apply_bp_hardening(void)
> +{
> + struct bp_hardening_data *d;
> +
> + if (!cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR))
> + return;
> +
> + d = arm64_get_bp_hardening_data();
> + if (d->fn)
> + d->fn();
> +}
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 22168cd0dde7..5203b6040cb6 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -318,6 +318,7 @@ static void __do_user_fault(struct task_struct *tsk, unsigned long addr,
> lsb = PAGE_SHIFT;
> si.si_addr_lsb = lsb;
>
> + arm64_apply_bp_hardening();
Due to the this_cpu_ptr() call:
| BUG: using smp_processor_id() in preemptible [00000000] code: print_my_pa/2093
| caller is debug_smp_processor_id+0x1c/0x24
| CPU: 0 PID: 2093 Comm: print_my_pa Tainted: G W
4.15.0-rc3-00044-g7f0aaec94f27-dirty #8950
| Call trace:
| dump_backtrace+0x0/0x164
| show_stack+0x14/0x1c
| dump_stack+0xa4/0xdc
| check_preemption_disabled+0xfc/0x100
| debug_smp_processor_id+0x1c/0x24
| __do_user_fault+0xcc/0x180
| do_page_fault+0x14c/0x364
| do_translation_fault+0x40/0x48
| do_mem_abort+0x40/0xb8
| el0_da+0x20/0x24
Make it a TIF flag?
(Seen with arm64's kpti-base tag and this series)
> force_sig_info(sig, &si, tsk);
> }
Thanks,
James
^ permalink raw reply
* [PATCH] Revert "ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells"
From: Arnd Bergmann @ 2018-01-08 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dd0372b5-e16c-ce77-ce39-2c4ffa61f663@i2se.com>
On Mon, Jan 8, 2018 at 10:36 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Am 08.01.2018 um 10:27 schrieb Arnd Bergmann:
>>
>> On Mon, Jan 8, 2018 at 10:15 AM, Stefan Wahren <stefan.wahren@i2se.com>
>> wrote:
>>>
>>> Hi Eric,
>>> Am 07.01.2018 um 23:08 schrieb Eric Anholt:
>>>>
>>>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>>>
>>>>> This reverts commit 014d6da6cb2525d7f48fb08c705cb130cc7b5f4a.
>>>>>
>>>>> The DT clean up could trigger an endless deferred probe of DWC2 USB
>>>>> driver
>>>>> on the Raspberry Pi 2/3. So revert the change until we fixed the
>>>>> probing
>>>>> issue.
>>>>
>>>> Why's that? I found that I needed to enable the generic no-op phy
>>>> driver, but other than that it was fine.
>>>
>>>
>>> in order to avoid this regression. Changing the configuration is not a
>>> solution for the kernelci guys.
>>>
>>> Btw
>>>
>>> CONFIG_NOP_USB_XCEIV=y
>>>
>>> is already enabled in arm64/defconfig and the issue still occured. Do you
>>> mean a different option?
>>
>> Obviously we need to fix this, but I really want to understand what
>> exactly
>> happened so we can fix the code if possible rather than making the
>> dts file incompatible with the binding again.
>
>
> i fully agree, but dwc2 "hacking" usually requires more time than reverting
> this change.
>
>>
>> Do you have any more insight into how we get into the deferred probe
>> situation?
>
>
> I send this bug report [1] on Friday to linux-usb.
>
> Stefan
>
> [1] - https://marc.info/?l=linux-usb&m=151518314314753&w=2
Ok, I looked at the code now and it seems that the generic phy layer
returns -EINVAL for a phy reference to an invalid node, but not a
reference to a valid node without a driver, here it returns
-EPROBE_DEFER, which by itself is reasonable behavior.
In this case, the NOP_USB_XCEIV driver is using the old usb-phy
framework, and the dwc2 driver tries both but bails out when the
generic phy returns -EPROBE_DEFER.
It sounds like the problem is not limited to raspberry pi then, but
the same thing would happen on any other machine using the
same algorithm. I looked at the other USB drivers that support
both generic-phy and usb-phy drivers:
- the generic usb-hcd code (usb_add_hcd) tries usb-phy first
and then tries generic-phy, but appears to also return
with -EPROBE_DEFER if either of the two asks for deferral.
other return codes are ignored.
- dwc2 (as show above) tries generic-phy first, propagates
-EPROBE_DEFER before trying usb-phy.
- dwc3 tries usb-phy first, and propagates -EPROBE_DEFER
from generic-phy even if usb-phy had succeeded.
- chipidea tries both and uses whichever one works, returning
-EPROBE_DEFER as long as both fail.
- musb/da8xx_probe propagates any error from generic-phy including
-EPROBE_DEFER, it then registers a generic phy and uses
that internally.
- musb/musb_dsps tries both, it fails if usb-phy is not working, but
ignores errors from generic-phy
- musb/omap2430 needs both usb-phy and generic-phy
- musb/sunxi needs a generic-phy and then registers a usb-phy
- renesas_usbhs tries both if they are enabled and fails
if one of them returns any error.
It's hard to tell what exactly is affected by the usb-hcd change,
most importantly since this is configuration dependent: if
the generic-phy layer is disabled, nothing changes, but otherwise
it would be broken the same way as dwc2 and dwc3.
The best idea I have so far is to had a hack into the generic
phy code with a full list of compatible strings that the must
never return -EPROBE_DEFER because that would break
the usb-phy handling:
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index b4964b067aec..6b9c3a1e7ce5 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -387,6 +387,24 @@ int phy_calibrate(struct phy *phy)
}
EXPORT_SYMBOL_GPL(phy_calibrate);
+static struct of_device_id legacy_usbphy[] = {
+ { .compatible = "fsl,imx23-usbphy" },
+ { .compatible = "fsl,imx6q-usbphy" },
+ { .compatible = "fsl,imx6sl-usbphy" },
+ { .compatible = "fsl,imx6sx-usbphy" },
+ { .compatible = "fsl,imx6ul-usbphy" },
+ { .compatible = "fsl,vf610-usbphy" },
+ { .compatible = "nvidia,tegra20-usb-phy" },
+ { .compatible = "nvidia,tegra30-usb-phy" },
+ { .compatible = "nxp,isp1301" },
+ { .compatible = "ti,am335x-usb-ctrl-module" },
+ { .compatible = "ti,am335x-usb-phy" },
+ { .compatible = "ti,keystone-usbphy" },
+ { .compatible = "ti,twl6030-usb" },
+ { .compatible = "usb-nop-xceiv" },
+ {},
+};
+
/**
* _of_phy_get() - lookup and obtain a reference to a phy by phandle
* @np: device_node for which to get the phy
@@ -410,6 +428,15 @@ static struct phy *_of_phy_get(struct device_node
*np, int index)
if (ret)
return ERR_PTR(-ENODEV);
+ /*
+ * Some USB host controllers use a "phys" property to refer to
+ * a device that does not have a generic phy driver but that
+ * has a driver for the older usb-phy framework.
+ * We must not return -EPROBE_DEFER for those, so bail out early.
+ */
+ if (of_match_node(legacy_usbphy, args.np))
+ return ERR_PTR(-ENODEV);
+
mutex_lock(&phy_provider_mutex);
phy_provider = of_phy_provider_lookup(args.np);
if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
Arnd
^ permalink raw reply related
* [PATCH] imx6: fix pcie enumeration
From: Koen Vandeputte @ 2018-01-08 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108110015.GA32027@red-moon>
On 2018-01-08 12:00, Lorenzo Pieralisi wrote:
> [+cc Joao, Jingoo]
>
> On Mon, Jan 08, 2018 at 09:51:37AM +0100, Koen Vandeputte wrote:
>
> [...]
>
>> [ Node 4 | node-4 ] lspci -v
>> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
>> [Normal decode])
>> ??? Flags: bus master, fast devsel, latency 0, IRQ 298
>> ??? Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
>> ??? Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> ^^^^^^^^^^^^^^
>
> So basically, the subordinate number in the root port does not
> affect config space forwarding from what I see and it has always
> been like that for dwc.
>
> You are forced to update it to 0xff because otherwise the kernel
> stops enumerating bus numbers > 1
Indeed, which affects all devices using Designware PCIe init + a PCIe
bridge downstream
> but that's a software issue
> not HW - the subordinate bus number does not seem to affect anything
> here.
> Sigh.
>
> Another option would consist in forcing the kernel to reassign
> all bus numbers by setting the PCI_REASSIGN_ALL_BUS flag but
> that's not a good idea given how inconsistent that flag usage is.
>
> I think that updating the subordinate bus numbers in the DWC
> config register is the correct solution to make sure the kernel
> won't get confused anymore by what seems to be a fake root port,
> I need input from DWC maintainers to confirm my understanding.
>
> Thanks,
> Lorenzo
>
The patch I'm currently using internally:
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -861,7 +861,7 @@ void dw_pcie_setup_rc(struct pcie_port *
???? /* setup bus numbers */
???? val = dw_pcie_readl_rc(pp, PCI_PRIMARY_BUS);
???? val &= 0xff000000;
-??? val |= 0x00010100;
+??? val |= 0x00ff0100;
???? dw_pcie_writel_rc(pp, PCI_PRIMARY_BUS, val);
???? /* setup command register */
Above version logically fixes it for all dwc devices using a bridge
after the RC, not only imx6.
If this is fine, I would submit the patch above and drop the current one.
Backporting this to stable kernels (4.9 .. 4.4 .. etc) will fix all
nasty warnings on these setups during boot without any change in
functionality.
These kernels will require a separate patch as this source file got
moved & renamed.
Thanks for your time and analysis so far,
Koen
^ permalink raw reply
* [PATCH v4 4/4] ARM: pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly.
From: Hao Zhang @ 2018-01-08 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213154549.5zn4uxhsssqw3pb7@flea.lan>
2017-12-13 23:45 GMT+08:00 Maxime Ripard <maxime.ripard@free-electrons.com>:
> Hi,
>
> Thanks for your patch!
>
> On Wed, Dec 13, 2017 at 10:47:48PM +0800, hao_zhang wrote:
>> Pin function can not be match correctly when SUNXI_PIN describe with
>> mutiple variant and same function.
>>
>> such as:
>> on pinctrl-sun4i-a10.c
>>
>> SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
>> SUNXI_FUNCTION(0x0, "gpio_in"),
>> SUNXI_FUNCTION(0x1, "gpio_out"),
>> SUNXI_FUNCTION_VARIANT(0x2, "pwm", /* PWM0 */
>> PINCTRL_SUN4I_A10 |
>> PINCTRL_SUN7I_A20),
>> SUNXI_FUNCTION_VARIANT(0x3, "pwm", /* PWM0 */
>> PINCTRL_SUN8I_R40)),
>>
>> it would always match to the first variant function
>> (PINCTRL_SUN4I_A10, PINCTRL_SUN7I_A20)
>>
>> so we should add variant compare on it.
>>
>> Signed-off-by: hao_zhang <hao5781286@gmail.com>
>> ---
>> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> index 4b6cb25..f23e74e 100644
>> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> @@ -83,9 +83,11 @@ sunxi_pinctrl_desc_find_function_by_name(struct sunxi_pinctrl *pctl,
>> struct sunxi_desc_function *func = pin->functions;
>>
>> while (func->name) {
>> - if (!strcmp(func->name, func_name))
>> + if (!strcmp(func->name, func_name)) {
>> + if (!(func->variant) ||
>> + (func->variant & pctl->variant))
>
> I guess it would be better to have:
> if (!strcmp(func->name, func_name) &&
> (!func->variant || (func->variant & pctl->variant)))
It would over 80 characters, can i change it by this ?
if (!strcmp(func->name, func_name) &&
(func->variant & pctl->variant ||
!func->variant))
>
> Once fixed,
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH] imx6: fix pcie enumeration
From: Lorenzo Pieralisi @ 2018-01-08 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5bc70c34-45b2-5aed-eb06-f8ecfe859fd0@ncentric.com>
[+cc Joao, Jingoo]
On Mon, Jan 08, 2018 at 09:51:37AM +0100, Koen Vandeputte wrote:
[...]
> [ Node 4 | node-4 ] lspci -v
> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
> [Normal decode])
> ??? Flags: bus master, fast devsel, latency 0, IRQ 298
> ??? Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
> ??? Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
^^^^^^^^^^^^^^
So basically, the subordinate number in the root port does not
affect config space forwarding from what I see and it has always
been like that for dwc.
You are forced to update it to 0xff because otherwise the kernel
stops enumerating bus numbers > 1 but that's a software issue
not HW - the subordinate bus number does not seem to affect anything
here.
Sigh.
Another option would consist in forcing the kernel to reassign
all bus numbers by setting the PCI_REASSIGN_ALL_BUS flag but
that's not a good idea given how inconsistent that flag usage is.
I think that updating the subordinate bus numbers in the DWC
config register is the correct solution to make sure the kernel
won't get confused anymore by what seems to be a fake root port,
I need input from DWC maintainers to confirm my understanding.
Thanks,
Lorenzo
> ??? I/O behind bridge: None
> ??? Memory behind bridge: 01100000-012fffff [size=2M]
> ??? Prefetchable memory behind bridge: None
> ??? [virtual] Expansion ROM at 01300000 [disabled] [size=64K]
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> ??? Capabilities: [70] Express Root Port (Slot-), MSI 00
> ??? Capabilities: [100] Advanced Error Reporting
> ??? Capabilities: [140] Virtual Channel
> ??? Kernel driver in use: pcieport
> lspci: Unable to load libkmod resources: error -12
>
> 01:00.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
> Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal
> decode])
> ??? Flags: bus master, fast devsel, latency 0, IRQ 298
> ??? Memory at 01200000 (32-bit, non-prefetchable) [size=128K]
> ??? Bus: primary=01, secondary=02, subordinate=05, sec-latency=0
> ??? I/O behind bridge: None
> ??? Memory behind bridge: 01100000-011fffff [size=1M]
> ??? Prefetchable memory behind bridge: None
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
> ??? Capabilities: [68] Express Upstream Port, MSI 00
> ??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604
> 4-lane, 4-Port PCI Express Gen 2 (5.0 GT/s) Switch
> ??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
> ??? Capabilities: [fb4] Advanced Error Reporting
> ??? Capabilities: [138] Power Budgeting <?>
> ??? Capabilities: [148] Virtual Channel
> ??? Capabilities: [448] Vendor Specific Information: ID=0000 Rev=0
> Len=0cc <?>
> ??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
> Len=010 <?>
> ??? Kernel driver in use: pcieport
>
> 02:01.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
> Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal
> decode])
> ??? Flags: bus master, fast devsel, latency 0, IRQ 299
> ??? Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
> ??? I/O behind bridge: None
> ??? Memory behind bridge: None
> ??? Prefetchable memory behind bridge: None
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
> ??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
> ??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604
> 4-lane, 4-Port PCI Express Gen 2 (5.0 GT/s) Switch
> ??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
> ??? Capabilities: [fb4] Advanced Error Reporting
> ??? Capabilities: [148] Virtual Channel
> ??? Capabilities: [520] Access Control Services
> ??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
> Len=010 <?>
> ??? Kernel driver in use: pcieport
>
> 02:04.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
> Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal
> decode])
> ??? Flags: bus master, fast devsel, latency 0, IRQ 298
> ??? Bus: primary=02, secondary=04, subordinate=04, sec-latency=0
> ??? I/O behind bridge: None
> ??? Memory behind bridge: None
> ??? Prefetchable memory behind bridge: None
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
> ??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
> ??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604
> 4-lane, 4-Port PCI Express Gen 2 (5.0 GT/s) Switch
> ??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
> ??? Capabilities: [fb4] Advanced Error Reporting
> ??? Capabilities: [148] Virtual Channel
> ??? Capabilities: [520] Access Control Services
> ??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
> Len=010 <?>
> ??? Kernel driver in use: pcieport
>
> 02:05.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
> Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal
> decode])
> ??? Flags: bus master, fast devsel, latency 0, IRQ 299
> ??? Bus: primary=02, secondary=05, subordinate=05, sec-latency=0
> ??? I/O behind bridge: None
> ??? Memory behind bridge: 01100000-011fffff [size=1M]
> ??? Prefetchable memory behind bridge: None
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
> ??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
> ??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604
> 4-lane, 4-Port PCI Express Gen 2 (5.0 GT/s) Switch
> ??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
> ??? Capabilities: [fb4] Advanced Error Reporting
> ??? Capabilities: [148] Virtual Channel
> ??? Capabilities: [520] Access Control Services
> ??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
> Len=010 <?>
> ??? Kernel driver in use: pcieport
>
> 05:00.0 Network controller: Qualcomm Atheros AR958x 802.11abgn
> Wireless Network Adapter (rev 01)
> ??? Subsystem: Device 19b6:d016
> ??? Flags: bus master, fast devsel, latency 0, IRQ 299
> ??? Memory at 01100000 (64-bit, non-prefetchable) [size=128K]
> ??? [virtual] Expansion ROM at 01120000 [disabled] [size=64K]
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
> ??? Capabilities: [70] Express Endpoint, MSI 00
> ??? Capabilities: [100] Advanced Error Reporting
> ??? Capabilities: [140] Virtual Channel
> ??? Capabilities: [300] Device Serial Number 00-00-00-00-00-00-00-00
> ??? Kernel driver in use: ath9k
>
^ permalink raw reply
* [PATCH v2 2/4] dmaengine: xilinx_dma: properly configure the SG mode bit in the driver for cdma
From: Vinod Koul @ 2018-01-08 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514961731-1916-3-git-send-email-appanad@xilinx.com>
On Wed, Jan 03, 2018 at 12:12:09PM +0530, Kedareswara rao Appana wrote:
> If the hardware is configured for Scatter Gather(SG) mode,
> and hardware is idle, in the control register SG mode bit
> must be set to a 0 then back to 1 by the software, to force
> the CDMA SG engine to use a new value written to the CURDESC_PNTR
> register, failure to do so could result errors from the dmaengine.
Applied 2-4, thanks
--
~Vinod
^ permalink raw reply
* [PATCH v2 1/4] dmaengine: xilinx_dma: populate dma caps properly
From: Appana Durga Kedareswara Rao @ 2018-01-08 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108103845.GE18649@localhost>
Hi Vinod,
Thanks for the review....
<Snip>
>> @@ -2398,6 +2398,7 @@ static int xilinx_dma_chan_probe(struct
>xilinx_dma_device *xdev,
>> chan->direction = DMA_MEM_TO_DEV;
>> chan->id = chan_id;
>> chan->tdest = chan_id;
>> + xdev->common.directions = BIT(DMA_MEM_TO_DEV);
>>
>> chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
>> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) { @@ -
>2415,6
>> +2416,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
>> chan->direction = DMA_DEV_TO_MEM;
>> chan->id = chan_id;
>> chan->tdest = chan_id - xdev->nr_channels;
>> + xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
>>
>> chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
>> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) { @@ -
>2629,6
>> +2631,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
>> dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
>> }
>>
>> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
>> + xdev->common.src_addr_widths = BIT(addr_width / 8);
>
>Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers? What is value
>of addr_width here typically? Usually controllers can support different widths and
>this is a surprise that you support only one value
Controller supports address width of 32 and 64.
addr_width typical values are 32-bit or 64-bit .
Here addr_width is device-tree parameter...
my understanding of src_addr_widths/dst_addr_widths is, it is a bit mask of the
address with in bytes that DMA supports, please correct if my understanding is wrong.
Regards,
Kedar.
>
>--
>~Vinod
^ permalink raw reply
* [PATCH] soc: imx: gpc: de-register power domains only if initialized
From: Lucas Stach @ 2018-01-08 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108102855.GA32635@b29396-OptiPlex-7040>
Am Montag, den 08.01.2018, 18:28 +0800 schrieb Dong Aisheng:
> On Sun, Jan 07, 2018 at 02:49:05PM +0100, Stefan Agner wrote:
> > If power domain information are missing in the device tree, no
> > power domains get initialized. However, imx_gpc_remove tries to
> > remove power domains always in the old DT binding case. Only
> > remove power domains when imx_gpc_probe initialized them in
> > first place.
> >
> > Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC
> > driver")
> > Cc: Lucas Stach <l.stach@pengutronix.de>
> > Signed-off-by: Stefan Agner <stefan@agner.ch>
> > ---
> > ?drivers/soc/imx/gpc.c | 10 +++++++++-
> > ?1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> > index 53f7275d6cbd..62bb724726d9 100644
> > --- a/drivers/soc/imx/gpc.c
> > +++ b/drivers/soc/imx/gpc.c
> > @@ -470,13 +470,21 @@ static int imx_gpc_probe(struct
> > platform_device *pdev)
> > ?
> > ?static int imx_gpc_remove(struct platform_device *pdev)
> > ?{
>
> What's the original purpose of imx_gpc_remove?
> ARM power domain can't be removed.
Why? As long as it stays powered on there is not reason why we wouldn't
be able to remove the driver.
> And why current imx_gpc_remove only remove domains for old DT but not
> for new ones?
With the new binding the power domains will be removed by the sub-
drivers for the domains.
> How about make it un-removable?
> e.g.
I don't see why this would be a good idea. Once more device-dependency
handling is in place we might need to unbind the power domains when the
regulator driver for the domain is unbound. Do you intend to make them
non-removable, too?
Regards,
Lucas
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 47e7aa9..7fc6737 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -454,36 +454,17 @@ static int imx_gpc_probe(struct platform_device
> *pdev)
> ????????return 0;
> ?}
> ?
> -static int imx_gpc_remove(struct platform_device *pdev)
> -{
> -???????int ret;
> -
> -???????/*
> -????????* If the old DT binding is used the toplevel driver needs to
> -????????* de-register the power domains
> -????????*/
> -???????if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
> -???????????????of_genpd_del_provider(pdev->dev.of_node);
> -
> -???????????????ret =
> pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
> -???????????????if (ret)
> -???????????????????????return ret;
> -???????????????imx_pgc_put_clocks(&imx_gpc_domains[GPC_PGC_DOMAIN_PU
> ]);
> -
> -???????????????ret =
> pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_ARM].base);
> -???????????????if (ret)
> -???????????????????????return ret;
> -???????}
> -
> -???????return 0;
> -}
> -
> ?static struct platform_driver imx_gpc_driver = {
> ????????.driver = {
> ????????????????.name = "imx-gpc",
> ????????????????.of_match_table = imx_gpc_dt_ids,
> +????????????????/*
> +?????????????????* We can't forcibly eject devices form power
> domain,
> +?????????????????* so we can't really remove power domains once they
> +?????????????????* were added.
> +?????????????????*/
> +????????????????.suppress_bind_attrs = true,
> ????????},
> ????????.probe = imx_gpc_probe,
> -???????.remove = imx_gpc_remove,
> ?};
> ?builtin_platform_driver(imx_gpc_driver)
>
> Regards
> Dong Aisheng
>
> > + struct device_node *pgc_node;
> > ? int ret;
> > ?
> > + pgc_node = of_get_child_by_name(pdev->dev.of_node, "pgc");
> > +
> > + /* bail out if DT too old and doesn't provide the
> > necessary info */
> > + if (!of_property_read_bool(pdev->dev.of_node, "#power-
> > domain-cells") &&
> > + ????!pgc_node)
> > + return 0;
> > +
> > ? /*
> > ? ?* If the old DT binding is used the toplevel driver needs
> > to
> > ? ?* de-register the power domains
> > ? ?*/
> > - if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
> > + if (!pgc_node) {
> > ? of_genpd_del_provider(pdev->dev.of_node);
> > ?
> > ? ret =
> > pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
> > --?
> > 2.15.1
> >
^ permalink raw reply
* [PATCH v3] PCI: imx6: Add PHY reference clock source support
From: Lucas Stach @ 2018-01-08 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515073977-10153-1-git-send-email-ilya@compulab.co.il>
Am Donnerstag, den 04.01.2018, 15:52 +0200 schrieb Ilya Ledvich:
> i.MX7D variant of the IP can use either Crystal Oscillator input
> or internal clock input as a Reference Clock input for PCIe PHY.
> Add support for an optional property 'fsl,pcie-phy-refclk-internal'.
> If present then an internal clock input is used as PCIe PHY
> reference clock source. By default an external oscillator input
> is still used.
>
> Verified on Compulab SBC-iMX7 Single Board Computer.
Sorry to get in late here, but I would rather have the external clock
input modeled as a real clock and only use the internal clock if that
isn't present.
Are you even sure that the i.MX7 clock you mention isn't the already
documented "pcie_bus" clock? This one is also allowed to be sourced
externally on the i.MX6.
Regards,
Lucas
> Signed-off-by: Ilya Ledvich <ilya@compulab.co.il>
> ---
> changes since V2:
> add a vendor prefix 'fsl' to a new property
>
> ?Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 5 +++++
> ?drivers/pci/dwc/pci-imx6.c???????????????????????????????| 8
> +++++++-
> ?2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> index 7b1e48b..1591a6a 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> @@ -50,6 +50,11 @@ Additional required properties for imx7d-pcie:
> ? ???????- "pciephy"
> ? ???????- "apps"
> ?
> +Additional optional properties for imx7d-pcie:
> +- fsl,pcie-phy-refclk-internal: If present then an internal PLL
> input is used
> +??as PCIe PHY reference clock source. By default an external
> oscillator input
> +??is used.
> +
> ?Example:
> ?
> ? pcie at 0x01000000 {
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
> index b734835..36812d3 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -61,6 +61,7 @@ struct imx6_pcie {
> ? u32 tx_swing_low;
> ? int link_gen;
> ? struct regulator *vpcie;
> + bool pciephy_refclk_sel;
> ?};
> ?
> ?/* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
> @@ -474,7 +475,9 @@ static void imx6_pcie_init_phy(struct imx6_pcie
> *imx6_pcie)
> ? switch (imx6_pcie->variant) {
> ? case IMX7D:
> ? regmap_update_bits(imx6_pcie->iomuxc_gpr,
> IOMUXC_GPR12,
> - ???IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
> 0);
> + ???IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
> + ???imx6_pcie->pciephy_refclk_sel ?
> + ???IMX7D_GPR12_PCIE_PHY_REFCLK_SEL :
> 0);
> ? break;
> ? case IMX6SX:
> ? regmap_update_bits(imx6_pcie->iomuxc_gpr,
> IOMUXC_GPR12,
> @@ -840,6 +843,9 @@ static int imx6_pcie_probe(struct platform_device
> *pdev)
> ? imx6_pcie->vpcie = NULL;
> ? }
> ?
> + imx6_pcie->pciephy_refclk_sel =
> + of_property_read_bool(node, "fsl,pcie-phy-refclk-
> internal");
> +
> ? platform_set_drvdata(pdev, imx6_pcie);
> ?
> ? ret = imx6_add_pcie_port(imx6_pcie, pdev);
^ permalink raw reply
* [PATCH] ARM: dts: imx6ul: remove unnecessary clocks for cpu-freq
From: Dong Aisheng @ 2018-01-08 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514978534-27416-1-git-send-email-Anson.Huang@nxp.com>
On Wed, Jan 03, 2018 at 07:22:14PM +0800, Anson Huang wrote:
> Remove unnecessary clocks for cpu-freq driver to
> avoid confusion.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH] clk: imx: imx7d: correct video pll clock tree
From: Dong Aisheng @ 2018-01-08 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514999361-2723-1-git-send-email-Anson.Huang@nxp.com>
On Thu, Jan 04, 2018 at 01:09:21AM +0800, Anson Huang wrote:
> There is a test divider and post divider in video PLL,
> test divider is placed before post divider, all clocks
> that can select parent from video PLL should be from
> post divider, NOT from pll_video_main, below are
> clock tree dump before and after this patch:
>
> Before:
> pll_video_main
> pll_video_main_bypass
> pll_video_main_clk
> lcdif_pixel_src
> lcdif_pixel_cg
> lcdif_pixel_pre_div
> lcdif_pixel_post_div
> lcdif_pixel_root_clk
> After:
> pll_video_main
> pll_video_main_bypass
> pll_video_main_clk
> pll_video_test_div
> pll_video_post_div
> lcdif_pixel_src
> lcdif_pixel_cg
> lcdif_pixel_pre_div
> lcdif_pixel_post_div
> lcdif_pixel_root_clk
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx7s: add snvs rtc clock
From: Dong Aisheng @ 2018-01-08 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078402-22135-2-git-send-email-Anson.Huang@nxp.com>
On Thu, Jan 04, 2018 at 11:06:42PM +0800, Anson Huang wrote:
> Add i.MX7 SNVS RTC clock.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
If this clock IMX7D_SNVS_CLK is used for all SNVS sub modules,
then snvs_poweroff and snvs_pwrkey should also rely on it, right?
How about add them all in one time?
BTW, syscon-poweroff seems still not introduce clock support and
fsl,sec-v4.0-pwrkey also does not handle clock, they may need to
be added later.
Regards
Dong Aisheng
> ---
> arch/arm/boot/dts/imx7s.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index e718fd2..f9b97f3 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -534,6 +534,8 @@
> offset = <0x34>;
> interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX7D_SNVS_CLK>;
> + clock-names = "snvs-rtc";
> };
>
> snvs_poweroff: snvs-poweroff {
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 1/4] dmaengine: xilinx_dma: populate dma caps properly
From: Vinod Koul @ 2018-01-08 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514961731-1916-2-git-send-email-appanad@xilinx.com>
On Wed, Jan 03, 2018 at 12:12:08PM +0530, Kedareswara rao Appana wrote:
> When client driver uses dma_get_slave_caps() api,
> it checks for certain fields of dma_device struct
> currently driver is not settings the directions and addr_widths
> fields resulting dma_get_slave_caps() returning failure.
>
> This patch fixes this issue by populating proper values
> to the struct dma_device directions and addr_widths fields.
>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> Changes for v2:
> --> Improved commit message title and description
> as suggested by Vinod.
>
> drivers/dma/xilinx/xilinx_dma.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 88d317d..21ac954 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -2398,6 +2398,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->direction = DMA_MEM_TO_DEV;
> chan->id = chan_id;
> chan->tdest = chan_id;
> + xdev->common.directions = BIT(DMA_MEM_TO_DEV);
>
> chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
> @@ -2415,6 +2416,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->direction = DMA_DEV_TO_MEM;
> chan->id = chan_id;
> chan->tdest = chan_id - xdev->nr_channels;
> + xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
>
> chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
> @@ -2629,6 +2631,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
> dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
> }
>
> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
> + xdev->common.src_addr_widths = BIT(addr_width / 8);
Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers? What is
value of addr_width here typically? Usually controllers can support
different widths and this is a surprise that you support only one value
--
~Vinod
^ permalink raw reply
* [PATCH 1/2] clk: imx: imx7d: add the snvs clock
From: Dong Aisheng @ 2018-01-08 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078402-22135-1-git-send-email-Anson.Huang@nxp.com>
On Thu, Jan 04, 2018 at 11:06:41PM +0800, Anson Huang wrote:
> According to the i.MX7D Reference Manual,
> SNVS block has a clock gate, accessing SNVS block
> would need this clock gate to be enabled, add it
> into clock tree so that SNVS module driver can
> operate this clock gate.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH v2 0/5] constify struct imx_pinctrl_soc_info
From: Dong Aisheng @ 2018-01-08 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106142553.15322-1-stefan@agner.ch>
On Sat, Jan 06, 2018 at 03:25:48PM +0100, Stefan Agner wrote:
> This patchset grew out of the discussion around the first version
> of "pinctrl: imx6ul: add IOMUXC SNVS pinctrl driver for i.MX 6ULL".
> This is necessary for pinctrls of SoCs with multiple compatible
> strings (currently only imx7d) since the struct uses the .data
> pointer in struct of_device_id. It is also helpful for all other
> SoCs since it decreases the .data section for all drivers by 1276
> bytes.
>
> Bai Ping (1):
> pinctrl: imx6ul: add IOMUXC SNVS pinctrl driver for i.MX 6ULL
>
> Stefan Agner (4):
> pinctrl: imx: use struct imx_pinctrl_soc_info as a const
> pinctrl: imx7d: simplify imx7d_pinctrl_probe
> pinctrl: imx: constify struct imx_pinctrl_soc_info
> pinctrl: imx7ulp: constify struct imx_cfg_params_decode
>
This patch series looks really good to me.
So
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH] soc: imx: gpc: de-register power domains only if initialized
From: Dong Aisheng @ 2018-01-08 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180107134905.15624-1-stefan@agner.ch>
On Sun, Jan 07, 2018 at 02:49:05PM +0100, Stefan Agner wrote:
> If power domain information are missing in the device tree, no
> power domains get initialized. However, imx_gpc_remove tries to
> remove power domains always in the old DT binding case. Only
> remove power domains when imx_gpc_probe initialized them in
> first place.
>
> Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver")
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> drivers/soc/imx/gpc.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 53f7275d6cbd..62bb724726d9 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -470,13 +470,21 @@ static int imx_gpc_probe(struct platform_device *pdev)
>
> static int imx_gpc_remove(struct platform_device *pdev)
> {
What's the original purpose of imx_gpc_remove?
ARM power domain can't be removed.
And why current imx_gpc_remove only remove domains for old DT but not
for new ones?
How about make it un-removable?
e.g.
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 47e7aa9..7fc6737 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -454,36 +454,17 @@ static int imx_gpc_probe(struct platform_device *pdev)
return 0;
}
-static int imx_gpc_remove(struct platform_device *pdev)
-{
- int ret;
-
- /*
- * If the old DT binding is used the toplevel driver needs to
- * de-register the power domains
- */
- if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
- of_genpd_del_provider(pdev->dev.of_node);
-
- ret = pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
- if (ret)
- return ret;
- imx_pgc_put_clocks(&imx_gpc_domains[GPC_PGC_DOMAIN_PU]);
-
- ret = pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_ARM].base);
- if (ret)
- return ret;
- }
-
- return 0;
-}
-
static struct platform_driver imx_gpc_driver = {
.driver = {
.name = "imx-gpc",
.of_match_table = imx_gpc_dt_ids,
+ /*
+ * We can't forcibly eject devices form power domain,
+ * so we can't really remove power domains once they
+ * were added.
+ */
+ .suppress_bind_attrs = true,
},
.probe = imx_gpc_probe,
- .remove = imx_gpc_remove,
};
builtin_platform_driver(imx_gpc_driver)
Regards
Dong Aisheng
> + struct device_node *pgc_node;
> int ret;
>
> + pgc_node = of_get_child_by_name(pdev->dev.of_node, "pgc");
> +
> + /* bail out if DT too old and doesn't provide the necessary info */
> + if (!of_property_read_bool(pdev->dev.of_node, "#power-domain-cells") &&
> + !pgc_node)
> + return 0;
> +
> /*
> * If the old DT binding is used the toplevel driver needs to
> * de-register the power domains
> */
> - if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
> + if (!pgc_node) {
> of_genpd_del_provider(pdev->dev.of_node);
>
> ret = pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
> --
> 2.15.1
>
^ permalink raw reply related
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
From: Maxime Ripard @ 2018-01-08 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104152741.m6bsno4vdh65ouw3@core.my.home>
Hi,
On Thu, Jan 04, 2018 at 04:27:41PM +0100, Ond?ej Jirman wrote:
> On Thu, Jan 04, 2018 at 03:06:25PM +0100, Maxime Ripard wrote:
> > On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ond?ej Jirman wrote:
> > > Hello,
> > >
> > > On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > > > Hi,
> > > >
> > > > On Fri, 22 Dec 2017 14:46:48 +0100
> > > > Ond?ej Jirman <megous@megous.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> > > > > >
> > > > > > Test input 0:
> > > > > >
> > > > > > Control ioctls:
> > > > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > > > Standard Controls: 0 Private Controls: 0
> > > > >
> > > > > I'm not sure if your driver passes control queries to the subdev. It
> > > > > did not originally, and I'm not sure you picked up the change from my
> > > > > version of the driver. "Not supported" here seems to indicate that it
> > > > > does not.
> > > > >
> > > > > I'd be interested what's the recommended practice here. It sure helps
> > > > > with some apps that expect to be able to modify various input controls
> > > > > directly on the /dev/video# device. These are then supported out of the
> > > > > box.
> > > > >
> > > > > It's a one-line change. See:
> > > > >
> > > > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > > > heriting-controls
> > > >
> > > > I think this is a feature and not affect the driver's main function.
> > > > I just focused on making the CSI main function to work properly in
> > > > the initial version. Is this feature mandatory or most commonly used?
> > >
> > > I grepped the platform/ code and it seems, that inheriting controls
> > > from subdevs is pretty common for input drivers. (there are varying
> > > approaches though, some inherit by hand in the link function, some
> > > just register and empty ctrl_handler on the v4l2_dev and leave the
> > > rest to the core).
> > >
> > > Practically, I haven't found a common app that would allow me to enter
> > > both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> > > themselves, but it would be better if current controls were available
> > > at the /dev/video0 device automatically.
> > >
> > > It's much simpler for the userspace apps than the alternative, which
> > > is trying to identify the correct subdev that is currently
> > > associated with the CSI driver at runtime, which is not exactly
> > > straightforward and requires much more code, than a few lines in
> > > the kernel, that are required to inherit controls:
> >
> > And it becomes much more complicated once you have the same controls
> > on the v4l2 device and subdevice, which is not that uncommon.
>
> I don't think you understand the issue. In your hypothetical situation, if the
> CSI device will have any controls in the future, the merging of controls from
> subdev will be done automatically anyway, it's not some optional feature.
>
> Also userspace will not get any more complicated than without my proposed change
> to the driver. It will be at most the same as without the change if any subdev
> controls are masked by the CSI device controls.
>
> This CSI driver has no controls anyway. All my change does is create an empty
> handler for future controls of the CSI driver, so that apps can depend on this
> merging behavior right now, and not wait until someone adds the first control
> to the CSI driver.
My point is slightly different though. In more complex pipelines like
we have (which is even more complicated due to the fact that the ISP
is largely unknown), you cannot just have an application that rely on
the controls exposed on the v4l2 device, but they should take the
subdevices into account as well.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180108/bdd92851/attachment.sig>
^ permalink raw reply
* [PATCH 5/5] clk: qcom: use divider_ro_round_rate helper
From: Jerome Brunet @ 2018-01-08 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-6-jbrunet@baylibre.com>
On Fri, 2018-01-05 at 18:09 +0100, Jerome Brunet wrote:
> There is now an helper function to round the rate when the
> divider is read-only. Let's use it
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/clk/qcom/clk-regmap-divider.c | 19 ++++++-------------
> 1 file changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/clk/qcom/clk-regmap-divider.c b/drivers/clk/qcom/clk-regmap-divider.c
> index 4e9b8c2c8980..114e36b97255 100644
> --- a/drivers/clk/qcom/clk-regmap-divider.c
> +++ b/drivers/clk/qcom/clk-regmap-divider.c
> @@ -28,22 +28,15 @@ static long div_round_ro_rate(struct clk_hw *hw, unsigned long rate,
> {
> struct clk_regmap_div *divider = to_clk_regmap_div(hw);
> struct clk_regmap *clkr = ÷r->clkr;
> - u32 div;
> + u32 val;
> struct clk_hw *hw_parent = clk_hw_get_parent(hw);
forgot to remove this line.
>
> - regmap_read(clkr->regmap, divider->reg, &div);
> - div >>= divider->shift;
> - div &= BIT(divider->width) - 1;
> - div += 1;
> -
> - if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
> - if (!hw_parent)
> - return -EINVAL;
> -
> - *prate = clk_hw_round_rate(hw_parent, rate * div);
> - }
> + regmap_read(clkr->regmap, divider->reg, &val);
> + val >>= divider->shift;
> + val &= BIT(divider->width) - 1;
>
> - return DIV_ROUND_UP_ULL((u64)*prate, div);
> + return divider_ro_round_rate(hw, rate, prate, NULL, divider->width,
> + CLK_DIVIDER_ROUND_CLOSEST, val);
> }
>
> static long div_round_rate(struct clk_hw *hw, unsigned long rate,
^ permalink raw reply
* [PATCH] Revert "ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells"
From: Stefan Wahren @ 2018-01-08 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3qfiX_ZsD8pLmoTJZ2+Q8PkHGmfTFW=NL8P8QFML_dLw@mail.gmail.com>
Hi Arnd,
Am 08.01.2018 um 10:27 schrieb Arnd Bergmann:
> On Mon, Jan 8, 2018 at 10:15 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>> Hi Eric,
>> Am 07.01.2018 um 23:08 schrieb Eric Anholt:
>>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>>
>>>> This reverts commit 014d6da6cb2525d7f48fb08c705cb130cc7b5f4a.
>>>>
>>>> The DT clean up could trigger an endless deferred probe of DWC2 USB
>>>> driver
>>>> on the Raspberry Pi 2/3. So revert the change until we fixed the probing
>>>> issue.
>>> Why's that? I found that I needed to enable the generic no-op phy
>>> driver, but other than that it was fine.
>>
>> in order to avoid this regression. Changing the configuration is not a
>> solution for the kernelci guys.
>>
>> Btw
>>
>> CONFIG_NOP_USB_XCEIV=y
>>
>> is already enabled in arm64/defconfig and the issue still occured. Do you
>> mean a different option?
> Obviously we need to fix this, but I really want to understand what exactly
> happened so we can fix the code if possible rather than making the
> dts file incompatible with the binding again.
i fully agree, but dwc2 "hacking" usually requires more time than
reverting this change.
>
> Do you have any more insight into how we get into the deferred probe
> situation?
I send this bug report [1] on Friday to linux-usb.
Stefan
[1] - https://marc.info/?l=linux-usb&m=151518314314753&w=2
>
> Arnd
^ permalink raw reply
* [PATCH] arm64: Implement branch predictor hardening for Falkor
From: Andrew Jones @ 2018-01-08 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515184139-23743-1-git-send-email-shankerd@codeaurora.org>
Hi Shanker,
On Fri, Jan 05, 2018 at 02:28:59PM -0600, Shanker Donthineni wrote:
...
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index cb0fb37..daf53a5 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -54,6 +54,8 @@ static int cpu_enable_trap_ctr_access(void *__unused)
>
> #ifdef CONFIG_KVM
> extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
> +extern char __qcom_hyp_sanitize_link_stack_start[];
> +extern char __qcom_hyp_sanitize_link_stack_end[];
>
> static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
> const char *hyp_vecs_end)
> @@ -96,8 +98,10 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
> spin_unlock(&bp_lock);
> }
> #else
> -#define __psci_hyp_bp_inval_start NULL
> -#define __psci_hyp_bp_inval_end NULL
> +#define __psci_hyp_bp_inval_start NULL
> +#define __psci_hyp_bp_inval_end NULL
> +#define __qcom_hyp_sanitize_link_stack_start NULL
> +#define __qcom_hyp_sanitize_link_stack_start NULL
^^ copy+paste error here
Thanks,
drew
^ permalink raw reply
* [PATCH] Revert "ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells"
From: Arnd Bergmann @ 2018-01-08 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <df3db2e7-5d0f-9c1c-b005-41cf00e7d851@i2se.com>
On Mon, Jan 8, 2018 at 10:15 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Hi Eric,
> Am 07.01.2018 um 23:08 schrieb Eric Anholt:
>>
>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>
>>> This reverts commit 014d6da6cb2525d7f48fb08c705cb130cc7b5f4a.
>>>
>>> The DT clean up could trigger an endless deferred probe of DWC2 USB
>>> driver
>>> on the Raspberry Pi 2/3. So revert the change until we fixed the probing
>>> issue.
>>
>> Why's that? I found that I needed to enable the generic no-op phy
>> driver, but other than that it was fine.
>
>
> in order to avoid this regression. Changing the configuration is not a
> solution for the kernelci guys.
>
> Btw
>
> CONFIG_NOP_USB_XCEIV=y
>
> is already enabled in arm64/defconfig and the issue still occured. Do you
> mean a different option?
Obviously we need to fix this, but I really want to understand what exactly
happened so we can fix the code if possible rather than making the
dts file incompatible with the binding again.
Do you have any more insight into how we get into the deferred probe
situation?
Arnd
^ permalink raw reply
* [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3
From: Marc Zyngier @ 2018-01-08 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108072253.GA178830@jc-sabre>
On 08/01/18 07:24, Jayachandran C wrote:
> On Fri, Jan 05, 2018 at 01:12:33PM +0000, Will Deacon wrote:
>> For non-KASLR kernels where the KPTI behaviour has not been overridden
>> on the command line we can use ID_AA64PFR0_EL1.CSV3 to determine whether
>> or not we should unmap the kernel whilst running at EL0.
>>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>> ---
>> arch/arm64/include/asm/sysreg.h | 1 +
>> arch/arm64/kernel/cpufeature.c | 8 +++++++-
>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
>> index 08cc88574659..ae519bbd3f9e 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -437,6 +437,7 @@
>> #define ID_AA64ISAR1_DPB_SHIFT 0
>>
>> /* id_aa64pfr0 */
>> +#define ID_AA64PFR0_CSV3_SHIFT 60
>> #define ID_AA64PFR0_SVE_SHIFT 32
>> #define ID_AA64PFR0_GIC_SHIFT 24
>> #define ID_AA64PFR0_ASIMD_SHIFT 20
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index 9f0545dfe497..d723fc071f39 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -145,6 +145,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
>> };
>>
>> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
>> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV3_SHIFT, 4, 0),
>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
>> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
>> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
>> @@ -851,6 +852,8 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
>> static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
>> int __unused)
>> {
>> + u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
>> +
>> /* Forced on command line? */
>> if (__kpti_forced) {
>> pr_info_once("kernel page table isolation forced %s by command line option\n",
>> @@ -862,7 +865,9 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
>> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
>> return true;
>>
>> - return false;
>> + /* Defer to CPU feature registers */
>> + return !cpuid_feature_extract_unsigned_field(pfr0,
>> + ID_AA64PFR0_CSV3_SHIFT);
>
> If I read this correctly, this enables KPTI on all processors without the CSV3
> set (which seems to be a future capability).
>
> Turning on KPTI has a small but significant overhead, so I think we should turn
> it off on processors that are not vulnerable to CVE-2017-5754. Can we add something
> like this:
>
> --->8
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 19ed09b..202b037 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -862,6 +862,13 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> return __kpti_forced > 0;
> }
>
> + /* Don't force KPTI for CPUs that are not vulnerable */
> + switch (read_cpuid_id() & MIDR_CPU_MODEL_MASK) {
> + case MIDR_CAVIUM_THUNDERX2:
> + case MIDR_BRCM_VULCAN:
> + return false;
> + }
> +
> /* Useful for KASLR robustness */
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> return true;
>
KPTI is also an improvement for KASLR. Why would you deprive a user of
the choice to further secure their system?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ 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