* [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 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] 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 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: 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] 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 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] 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] 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
* 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
* Applied "ASoC: mediatek: mt2701: fix return value check in mt2701_afe_pcm_dev_probe()" to the asoc tree
From: Mark Brown @ 2018-01-08 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515377701-37553-1-git-send-email-weiyongjun1@huawei.com>
The patch
ASoC: mediatek: mt2701: fix return value check in mt2701_afe_pcm_dev_probe()
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 3e8052d90d24320a1edb556c20523f3b17195985 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Mon, 8 Jan 2018 02:15:01 +0000
Subject: [PATCH] ASoC: mediatek: mt2701: fix return value check in
mt2701_afe_pcm_dev_probe()
In case of error, the function syscon_node_to_regmap() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Fixes: dfa3cbb83e09 ("ASoC: mediatek: modify MT2701 AFE driver to adapt mfd device")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
index f0cd08fa5c5d..5bc4e00a4a29 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
@@ -1440,9 +1440,9 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
}
afe->regmap = syscon_node_to_regmap(dev->parent->of_node);
- if (!afe->regmap) {
+ if (IS_ERR(afe->regmap)) {
dev_err(dev, "could not get regmap from parent\n");
- return -ENODEV;
+ return PTR_ERR(afe->regmap);
}
mutex_init(&afe->irq_alloc_lock);
--
2.15.1
^ permalink raw reply related
* [PATCH v6 0/2] Documentation and driver of logicoreIP
From: Michal Simek @ 2018-01-08 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513881186-26020-1-git-send-email-dshah@xilinx.com>
On 21.12.2017 19:33, Dhaval Shah wrote:
> 1st patch provide Device Tree binding document for logicoreIP
> 2nd patch provide the xlnx_vcu logicoreIP driver, Kconfig changes
> and Makefile changes for the driver.
>
> Dhaval Shah (2):
> dt-bindings: misc: Add DT bindings to xlnx_vcu driver
> misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
>
> .../devicetree/bindings/soc/xilinx/xlnx,vcu.txt | 31 +
> drivers/soc/xilinx/Kconfig | 15 +
> drivers/soc/xilinx/Makefile | 1 +
> drivers/soc/xilinx/xlnx_vcu.c | 630 +++++++++++++++++++++
> 4 files changed, 677 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
> create mode 100644 drivers/soc/xilinx/xlnx_vcu.c
>
It looks like there is no any other concern regarding these patches
that's why I have applied them.
Thanks,
Michal
^ permalink raw reply
* [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
From: Prarit Bhargava @ 2018-01-08 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213124533.GA32362@red-moon>
[Sorry everyone for the late response, I went away on vacation and pushed this
off until I returned.]
On 12/13/2017 07:45 AM, Lorenzo Pieralisi wrote:
> [+Mark, Graeme]
>
> In $SUBJECT, s/avialable/available
>
> On Mon, Dec 11, 2017 at 10:50:58AM -0500, Prarit Bhargava wrote:
>> Other architectures can use SPCR to setup an early console or console
>> but the current code is ARM64 specific.
>
> I see nothing ARM64 specific in current code (apart from some
> ACPICA macros with an ARM tag in them) please explain to me
> what's preventing you to reuse current code on x86.
Ah, I didn't notice that. I thought the ACPICA macros were ARM specific. I'll
rework this patchset with that in mind.
>
>> Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak
>> function acpi_arch_setup_console() that can be used for arch-specific
>> setup. Move flags into ACPI code. Update the Documention on the use of
>> the SPCR.
>>
>> [v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
>> Keep ACPI_SPCR_TABLE selected for ARM64. Fix 8-bit port access width
>> mmio value. Move baud rate check earlier.
>
> This does not belong in the commit log.
Yes, but some maintainers like to see what changed between v1 & v2.
>
>> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>> Cc: linux-doc at vger.kernel.org
>> Cc: linux-kernel at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-pm at vger.kernel.org
>> Cc: linux-acpi at vger.kernel.org
>> Cc: linux-serial at vger.kernel.org
>> Cc: Bhupesh Sharma <bhsharma@redhat.com>
>> Cc: Lv Zheng <lv.zheng@intel.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: x86 at kernel.org
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>> Cc: Timur Tabi <timur@codeaurora.org>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 6 +-
>> arch/arm64/kernel/acpi.c | 128 ++++++++++++++++-
>> drivers/acpi/Kconfig | 7 +-
>> drivers/acpi/spcr.c | 175 ++++++------------------
>> drivers/tty/serial/earlycon.c | 15 +-
>> include/linux/acpi.h | 11 +-
>> include/linux/serial_core.h | 2 -
>> 7 files changed, 184 insertions(+), 160 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 6571fbfdb2a1..0d173289c67e 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -914,9 +914,9 @@
>>
>> earlycon= [KNL] Output early console device and options.
>>
>> - When used with no options, the early console is
>> - determined by the stdout-path property in device
>> - tree's chosen node.
>> + [ARM64] The early console is determined by the
>> + stdout-path property in device tree's chosen node,
>> + or determined by the ACPI SPCR table.
>>
>> cdns,<addr>[,options]
>> Start an early, polled-mode console on a Cadence
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index b3162715ed78..b3e33bbdf3b7 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -25,7 +25,6 @@
>> #include <linux/memblock.h>
>> #include <linux/of_fdt.h>
>> #include <linux/smp.h>
>> -#include <linux/serial_core.h>
>>
>> #include <asm/cputype.h>
>> #include <asm/cpu_ops.h>
>> @@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
>> return ret;
>> }
>>
>> +/*
>> + * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
>> + * occasionally getting stuck as 1. To avoid the potential for a hang, check
>> + * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
>> + * implementations, so only do so if an affected platform is detected in
>> + * acpi_parse_spcr().
>> + */
>> +bool qdf2400_e44_present;
>> +EXPORT_SYMBOL(qdf2400_e44_present);
>
> My eyes, this is horrible but it is not introduced by this patch. It
> would have been much better if:
>
> drivers/tty/serial/amba-pl011.c
>
> parsed the SPCR table (again) to detect it instead of relying on this
> horrible exported flag.
It looks like Timur & you had a discussion and the current consensus is to keep
the code the same.
>
>> +
>> +/*
>> + * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
>> + * Detect them by examining the OEM fields in the SPCR header, similar to PCI
>> + * quirk detection in pci_mcfg.c.
>> + */
>> +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
>> +{
>> + if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
>> + return false;
>> +
>> + if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
>> + return true;
>> +
>> + if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
>> + h->oem_revision == 1)
>> + return true;
>> +
>> + return false;
>> +}
>> +
>> +/*
>> + * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
>> + * register aligned to 32-bit. In addition, the BIOS also encoded the
>> + * access width to be 8 bits. This function detects this errata condition.
>> + */
>> +static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
>> +{
>> + bool xgene_8250 = false;
>> +
>> + if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
>> + return false;
>> +
>> + if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
>> + memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
>> + return false;
>> +
>> + if (!memcmp(tb->header.oem_table_id, "XGENESPC",
>> + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
>> + xgene_8250 = true;
>> +
>> + if (!memcmp(tb->header.oem_table_id, "ProLiant",
>> + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
>> + xgene_8250 = true;
>> +
>> + return xgene_8250;
>> +}
>> +
>> +int acpi_arch_setup_console(struct acpi_table_spcr *table,
>> + char *opts, char *uart, char *iotype,
>> + int baud_rate, bool earlycon)
>> +{
>> + if (table->header.revision < 2) {
>> + pr_err("wrong table version\n");
>> + return -ENOENT;
>> + }
>> +
>> + switch (table->interface_type) {
>> + case ACPI_DBG2_ARM_SBSA_32BIT:
>> + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio32");
>> + /* fall through */
>> + case ACPI_DBG2_ARM_PL011:
>> + case ACPI_DBG2_ARM_SBSA_GENERIC:
>> + case ACPI_DBG2_BCM2835:
>> + snprintf(uart, ACPI_SPCR_BUF_SIZE, "pl011");
>> + break;
>> + default:
>> + if (strlen(uart) == 0)
>> + return -ENOENT;
>> + }
>> +
>> + /*
>> + * If the E44 erratum is required, then we need to tell the pl011
>> + * driver to implement the work-around.
>> + *
>> + * The global variable is used by the probe function when it
>> + * creates the UARTs, whether or not they're used as a console.
>> + *
>> + * If the user specifies "traditional" earlycon, the qdf2400_e44
>> + * console name matches the EARLYCON_DECLARE() statement, and
>> + * SPCR is not used. Parameter "earlycon" is false.
>> + *
>> + * If the user specifies "SPCR" earlycon, then we need to update
>> + * the console name so that it also says "qdf2400_e44". Parameter
>> + * "earlycon" is true.
>> + *
>> + * For consistency, if we change the console name, then we do it
>> + * for everyone, not just earlycon.
>> + */
>> + if (qdf2400_erratum_44_present(&table->header)) {
>> + qdf2400_e44_present = true;
>> + if (earlycon)
>> + snprintf(uart, ACPI_SPCR_BUF_SIZE, "qdf2400_e44");
>> + }
>> +
>> + if (xgene_8250_erratum_present(table)) {
>> + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio32");
>> +
>> + /* for xgene v1 and v2 we don't know the clock rate of the
>> + * UART so don't attempt to change to the baud rate state
>> + * in the table because driver cannot calculate the dividers
>> + */
>> + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx", uart,
>> + iotype, table->serial_port.address);
>> + } else {
>> + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx,%d", uart,
>> + iotype, table->serial_port.address, baud_rate);
>> + }
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(acpi_arch_setup_console);
>
> EXPORT_SYMBOL() ? Why ?
>
> BTW, why do we need an arch hook ? I do not see anything that prevents
> you from using this code on x86 systems - is there anything arch
> specific in the SPCR specification itself ?
See above comment. But also keep in mind I have seen a lot of x86 systems that
do not define the ACPI table version correctly. The table version is 0 or 1,
and the current spec says it must be 2. It looks like ARM requires 2.
>
>> +
>> /*
>> * acpi_boot_table_init() called from setup_arch(), always.
>> * 1. find RSDP and get its address, and then find XSDT
>> @@ -230,10 +351,11 @@ void __init acpi_boot_table_init(void)
>>
>> done:
>> if (acpi_disabled) {
>> - if (earlycon_init_is_deferred)
>> + if (console_acpi_spcr_enable)
>> early_init_dt_scan_chosen_stdout();
>> } else {
>> - parse_spcr(earlycon_init_is_deferred);
>> + /* Always enable the ACPI SPCR console */
>> + acpi_parse_spcr(console_acpi_spcr_enable);
>> if (IS_ENABLED(CONFIG_ACPI_BGRT))
>> acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
>> }
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 46505396869e..9ae98eeada76 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -79,7 +79,12 @@ config ACPI_DEBUGGER_USER
>> endif
>>
>> config ACPI_SPCR_TABLE
>> - bool
>> + bool "ACPI Serial Port Console Redirection Support"
>> + default y if ARM64
>
> You need to remove the selection in arch/arm64 then. Also, moving away
> from a non-visible config may have consequences on ARM64, Graeme and
> Mark are more familiar with the SPCR dependencies so please chime in.
Ok, I'll double check this.
>
>> + help
>> + Enable support for Serial Port Console Redirection (SPCR) Table.
>> + This table provides information about the configuration of the
>> + earlycon console.
>>
>> config ACPI_LPIT
>> bool
>> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
>> index 324b35bfe781..f4bb8110e404 100644
>> --- a/drivers/acpi/spcr.c
>> +++ b/drivers/acpi/spcr.c
>> @@ -16,65 +16,18 @@
>> #include <linux/kernel.h>
>> #include <linux/serial_core.h>
>>
>> -/*
>> - * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
>> - * occasionally getting stuck as 1. To avoid the potential for a hang, check
>> - * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
>> - * implementations, so only do so if an affected platform is detected in
>> - * parse_spcr().
>> - */
>> -bool qdf2400_e44_present;
>> -EXPORT_SYMBOL(qdf2400_e44_present);
>> -
>> -/*
>> - * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
>> - * Detect them by examining the OEM fields in the SPCR header, similiar to PCI
>> - * quirk detection in pci_mcfg.c.
>> - */
>> -static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
>> -{
>> - if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
>> - return false;
>> -
>> - if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
>> - return true;
>> -
>> - if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
>> - h->oem_revision == 1)
>> - return true;
>> -
>> - return false;
>> -}
>> -
>> -/*
>> - * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
>> - * register aligned to 32-bit. In addition, the BIOS also encoded the
>> - * access width to be 8 bits. This function detects this errata condition.
>> - */
>> -static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
>> +int __weak acpi_arch_setup_console(struct acpi_table_spcr *table,
>> + char *opts, char *uart, char *iotype,
>> + int baud_rate, bool earlycon)
>> {
>> - bool xgene_8250 = false;
>> -
>> - if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
>> - return false;
>> -
>> - if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
>> - memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
>> - return false;
>> -
>> - if (!memcmp(tb->header.oem_table_id, "XGENESPC",
>> - ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
>> - xgene_8250 = true;
>> -
>> - if (!memcmp(tb->header.oem_table_id, "ProLiant",
>> - ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
>> - xgene_8250 = true;
>> -
>> - return xgene_8250;
>> + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx,%d", uart, iotype,
>> + table->serial_port.address, baud_rate);
>> + return 0;
>> }
>>
>> +bool console_acpi_spcr_enable __initdata;
>> /**
>> - * parse_spcr() - parse ACPI SPCR table and add preferred console
>> + * acpi_parse_spcr() - parse ACPI SPCR table and add preferred console
>> *
>> * @earlycon: set up earlycon for the console specified by the table
>> *
>> @@ -86,13 +39,13 @@ static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
>> * from arch initialization code as soon as the DT/ACPI decision is made.
>> *
>> */
>> -int __init parse_spcr(bool earlycon)
>> +int __init acpi_parse_spcr(bool earlycon)
>> {
>> - static char opts[64];
>> + static char opts[ACPI_SPCR_OPTS_SIZE];
>> + static char uart[ACPI_SPCR_BUF_SIZE];
>> + static char iotype[ACPI_SPCR_BUF_SIZE];
>> struct acpi_table_spcr *table;
>> acpi_status status;
>> - char *uart;
>> - char *iotype;
>> int baud_rate;
>> int err;
>>
>> @@ -105,48 +58,6 @@ int __init parse_spcr(bool earlycon)
>> if (ACPI_FAILURE(status))
>> return -ENOENT;
>>
>> - if (table->header.revision < 2) {
>> - err = -ENOENT;
>> - pr_err("wrong table version\n");
>> - goto done;
>> - }
>> -
>> - if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
>> - switch (ACPI_ACCESS_BIT_WIDTH((
>> - table->serial_port.access_width))) {
>> - default:
>> - pr_err("Unexpected SPCR Access Width. Defaulting to byte size\n");
>> - case 8:
>> - iotype = "mmio";
>> - break;
>> - case 16:
>> - iotype = "mmio16";
>> - break;
>> - case 32:
>> - iotype = "mmio32";
>> - break;
>> - }
>> - } else
>> - iotype = "io";
>> -
>> - switch (table->interface_type) {
>> - case ACPI_DBG2_ARM_SBSA_32BIT:
>> - iotype = "mmio32";
>> - /* fall through */
>> - case ACPI_DBG2_ARM_PL011:
>> - case ACPI_DBG2_ARM_SBSA_GENERIC:
>> - case ACPI_DBG2_BCM2835:
>> - uart = "pl011";
>> - break;
>> - case ACPI_DBG2_16550_COMPATIBLE:
>> - case ACPI_DBG2_16550_SUBSET:
>> - uart = "uart";
>> - break;
>> - default:
>> - err = -ENOENT;
>> - goto done;
>> - }
>> -
>> switch (table->baud_rate) {
>> case 3:
>> baud_rate = 9600;
>> @@ -165,43 +76,36 @@ int __init parse_spcr(bool earlycon)
>> goto done;
>> }
>>
>> - /*
>> - * If the E44 erratum is required, then we need to tell the pl011
>> - * driver to implement the work-around.
>> - *
>> - * The global variable is used by the probe function when it
>> - * creates the UARTs, whether or not they're used as a console.
>> - *
>> - * If the user specifies "traditional" earlycon, the qdf2400_e44
>> - * console name matches the EARLYCON_DECLARE() statement, and
>> - * SPCR is not used. Parameter "earlycon" is false.
>> - *
>> - * If the user specifies "SPCR" earlycon, then we need to update
>> - * the console name so that it also says "qdf2400_e44". Parameter
>> - * "earlycon" is true.
>> - *
>> - * For consistency, if we change the console name, then we do it
>> - * for everyone, not just earlycon.
>> - */
>> - if (qdf2400_erratum_44_present(&table->header)) {
>> - qdf2400_e44_present = true;
>> - if (earlycon)
>> - uart = "qdf2400_e44";
>> + switch (table->interface_type) {
>> + case ACPI_DBG2_16550_COMPATIBLE:
>> + case ACPI_DBG2_16550_SUBSET:
>> + snprintf(uart, ACPI_SPCR_BUF_SIZE, "uart");
>> + break;
>> + default:
>> + break;
>> }
>>
>> - if (xgene_8250_erratum_present(table)) {
>> - iotype = "mmio32";
>> + if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
>> + u8 width = ACPI_ACCESS_BIT_WIDTH((
>> + table->serial_port.access_width));
>> + switch (width) {
>> + default:
>> + pr_err("Unexpected SPCR Access Width. Defaulting to byte size\n");
>> + case 8:
>> + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio");
>> + break;
>> + case 16:
>> + case 32:
>> + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio%d", width);
>> + break;
>> + }
>> + } else
>> + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "io");
>>
>> - /* for xgene v1 and v2 we don't know the clock rate of the
>> - * UART so don't attempt to change to the baud rate state
>> - * in the table because driver cannot calculate the dividers
>> - */
>> - snprintf(opts, sizeof(opts), "%s,%s,0x%llx", uart, iotype,
>> - table->serial_port.address);
>> - } else {
>> - snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
>> - table->serial_port.address, baud_rate);
>> - }
>> + err = acpi_arch_setup_console(table, opts, uart, iotype, baud_rate,
>> + earlycon);
>> + if (err)
>> + goto done;
>>
>> pr_info("console: %s\n", opts);
>>
>> @@ -209,7 +113,6 @@ int __init parse_spcr(bool earlycon)
>> setup_earlycon(opts);
>>
>> err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
>> -
>
> Unintended change.
>
>> done:
>> acpi_put_table((struct acpi_table_header *)table);
>> return err;
>> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
>> index 4c8b80f1c688..b22afb62c7a3 100644
>> --- a/drivers/tty/serial/earlycon.c
>> +++ b/drivers/tty/serial/earlycon.c
>> @@ -196,26 +196,15 @@ int __init setup_earlycon(char *buf)
>> return -ENOENT;
>> }
>>
>> -/*
>> - * When CONFIG_ACPI_SPCR_TABLE is defined, "earlycon" without parameters in
>> - * command line does not start DT earlycon immediately, instead it defers
>> - * starting it until DT/ACPI decision is made. At that time if ACPI is enabled
>> - * call parse_spcr(), else call early_init_dt_scan_chosen_stdout()
>> - */
>> -bool earlycon_init_is_deferred __initdata;
>> -
>> /* early_param wrapper for setup_earlycon() */
>> static int __init param_setup_earlycon(char *buf)
>> {
>> int err;
>>
>> - /*
>> - * Just 'earlycon' is a valid param for devicetree earlycons;
>> - * don't generate a warning from parse_early_params() in that case
>> - */
>> + /* Just 'earlycon' is a valid param for devicetree and ACPI SPCR. */
>> if (!buf || !buf[0]) {
>> if (IS_ENABLED(CONFIG_ACPI_SPCR_TABLE)) {
>> - earlycon_init_is_deferred = true;
>> + console_acpi_spcr_enable = true;
>
> I am not familiar with this code, I would ask Graeme and Mark to check
> if this change is correct, the logic seems correct to me but I may be
> missing some corner cases.
>
>> return 0;
>> } else if (!buf) {
>> return early_init_dt_scan_chosen_stdout();
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index dc1ebfeeb5ec..875d7327d91c 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -1241,10 +1241,17 @@ static inline bool acpi_has_watchdog(void) { return false; }
>> #endif
>>
>> #ifdef CONFIG_ACPI_SPCR_TABLE
>> +#define ACPI_SPCR_OPTS_SIZE 64
>> +#define ACPI_SPCR_BUF_SIZE 32
>> extern bool qdf2400_e44_present;
>> -int parse_spcr(bool earlycon);
>> +extern bool console_acpi_spcr_enable __initdata;
>> +extern int acpi_arch_setup_console(struct acpi_table_spcr *table,
>> + char *opts, char *uart, char *iotype,
>> + int baud_rate, bool earlycon);
>> +int acpi_parse_spcr(bool earlycon);
>> #else
>> -static inline int parse_spcr(bool earlycon) { return 0; }
>> +static const bool console_acpi_spcr_enable;
>
> The assignment in param_setup_earlycon won't compile.
Hmm ... I'm pretty sure it did. But I'll check that before resubmitting.
P.
>
> Lorenzo
>
^ permalink raw reply
* [PATCH] perf: arm_dsu_pmu: convert to bitmap_from_arr32
From: Arnd Bergmann @ 2018-01-08 12:48 UTC (permalink / raw)
To: linux-arm-kernel
The bitmap_from_u32array() interface got replaced in a global
change, but the arm_dsu_pmu driver adds another instance,
resulting in a build failure:
drivers/perf/arm_dsu_pmu.c: In function 'dsu_pmu_probe_pmu':
drivers/perf/arm_dsu_pmu.c:661:2: error: implicit declaration of function 'bitmap_from_u32array'; did you mean 'bitmap_from_arr32'? [-Werror=implicit-function-declaration]
This changes the new instance accordingly.
Fixes: mmotm ("bitmap: replace bitmap_{from,to}_u32array")
Fixes: 7520fa99246d ("perf: ARM DynamIQ Shared Unit PMU support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
The global change is currently in linux-mm, so it should be
possible to just fold this patch into it, without causing
extra work.
---
drivers/perf/arm_dsu_pmu.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c
index 37c0526c93d5..e2700888a7d9 100644
--- a/drivers/perf/arm_dsu_pmu.c
+++ b/drivers/perf/arm_dsu_pmu.c
@@ -658,10 +658,8 @@ static void dsu_pmu_probe_pmu(struct dsu_pmu *dsu_pmu)
return;
cpmceid[0] = __dsu_pmu_read_pmceid(0);
cpmceid[1] = __dsu_pmu_read_pmceid(1);
- bitmap_from_u32array(dsu_pmu->cpmceid_bitmap,
- DSU_PMU_MAX_COMMON_EVENTS,
- cpmceid,
- ARRAY_SIZE(cpmceid));
+ bitmap_from_arr32(dsu_pmu->cpmceid_bitmap, cpmceid,
+ DSU_PMU_MAX_COMMON_EVENTS);
}
static void dsu_pmu_set_active_cpu(int cpu, struct dsu_pmu *dsu_pmu)
--
2.9.0
^ permalink raw reply related
* [PATCH] perf: arm_dsu_pmu: convert to bitmap_from_arr32
From: Yury Norov @ 2018-01-08 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108124902.3854110-1-arnd@arndb.de>
On Mon, Jan 08, 2018 at 01:48:31PM +0100, Arnd Bergmann wrote:
> The bitmap_from_u32array() interface got replaced in a global
> change, but the arm_dsu_pmu driver adds another instance,
> resulting in a build failure:
>
> drivers/perf/arm_dsu_pmu.c: In function 'dsu_pmu_probe_pmu':
> drivers/perf/arm_dsu_pmu.c:661:2: error: implicit declaration of function 'bitmap_from_u32array'; did you mean 'bitmap_from_arr32'? [-Werror=implicit-function-declaration]
>
> This changes the new instance accordingly.
>
> Fixes: mmotm ("bitmap: replace bitmap_{from,to}_u32array")
> Fixes: 7520fa99246d ("perf: ARM DynamIQ Shared Unit PMU support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> The global change is currently in linux-mm, so it should be
> possible to just fold this patch into it, without causing
> extra work.
> ---
> drivers/perf/arm_dsu_pmu.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c
> index 37c0526c93d5..e2700888a7d9 100644
> --- a/drivers/perf/arm_dsu_pmu.c
> +++ b/drivers/perf/arm_dsu_pmu.c
> @@ -658,10 +658,8 @@ static void dsu_pmu_probe_pmu(struct dsu_pmu *dsu_pmu)
> return;
> cpmceid[0] = __dsu_pmu_read_pmceid(0);
> cpmceid[1] = __dsu_pmu_read_pmceid(1);
> - bitmap_from_u32array(dsu_pmu->cpmceid_bitmap,
> - DSU_PMU_MAX_COMMON_EVENTS,
> - cpmceid,
> - ARRAY_SIZE(cpmceid));
> + bitmap_from_arr32(dsu_pmu->cpmceid_bitmap, cpmceid,
> + DSU_PMU_MAX_COMMON_EVENTS);
> }
>
> static void dsu_pmu_set_active_cpu(int cpu, struct dsu_pmu *dsu_pmu)
Thanks Arnd,
Acked-by: Yury Norov <ynorov@caviumnetworks.com>
^ permalink raw reply
* [PATCH] phy: work around 'phys' references to usb-phy devices
From: Arnd Bergmann @ 2018-01-08 13:01 UTC (permalink / raw)
To: linux-arm-kernel
Stefan Wahren reports a problem with a warning fix that was merged
for v4.15: we had lots of device nodes with a 'phys' property pointing
to a device node that is not compliant with the binding documented in
Documentation/devicetree/bindings/phy/phy-bindings.txt
This generally works because USB HCD drivers that support both the generic
phy subsystem and the older usb-phy subsystem ignore most errors from
phy_get() and related calls and then use the usb-phy driver instead.
However, usb_add_hcd() (along with the respective functions in dwc2 and
dwc3) propagate the EPROBE_DEFER return code so we can try again whenever
the driver gets loaded. In case the driver is written for the usb-phy
subsystem (like usb-generic-phy aka usb-nop-xceiv), we will never load
a generic-phy driver for it, and keep failing here.
There is only a small number of remaining usb-phy drivers that support
device tree, so this adds a workaround by providing a full list of the
potentially affected drivers, and always failing the probe with -ENODEV
here, which is the same behavior that we used to get with incorrect
device tree files. Since we generally want older kernels to also want
to work with the fixed devicetree files, it would be good to backport
the patch into stable kernels as well (3.13+ are possibly affected).
Reverting back to the DTS sources that work would in theory fix USB
support for now, but in the long run we'd run into the same problem
again when the drivers get ported from usb-phy to generic-phy.
Fixes: 014d6da6cb25 ("ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells")
Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
Cc: stable at vger.kernel.org
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This obviously needs to be tested, I wrote this up as a reply to
Stefan's bug report. I'm fairly sure that I covered all usb-phy
driver strings here. My goal is to have a fix merged into 4.15
rather than reverting all the DT fixes.
---
drivers/phy/phy-core.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index b4964b067aec..bb4dd2a2de2d 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 __maybe_unused 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)) {
--
2.9.0
^ permalink raw reply related
* [GIT PULL] ARM64: Xilinx ZynqMP SoC patches for v4.16
From: Michal Simek @ 2018-01-08 13:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi guys,
please consider to pull these 3 patches to your tree. I have discussed
it with Arnd that this could be probably fine even it is a little bit late.
Thanks,
Michal
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-soc-for-4.16
for you to fetch changes up to cee8113a295acfc4cd25728d7c3d44e6bc3bbff9:
soc: xilinx: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
(2018-01-08 13:42:47 +0100)
----------------------------------------------------------------
arm: Xilinx ZynqMP SoC patches for v4.16
- Create drivers/soc/xilinx folder structure
- Add ZynqMP vcu init driver
----------------------------------------------------------------
Dhaval Shah (2):
dt-bindings: soc: xilinx: Add DT bindings to xlnx_vcu driver
soc: xilinx: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
Michal Simek (1):
soc: xilinx: Create folder structure for soc specific drivers
Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt | 31 ++++++++
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/xilinx/Kconfig | 19 +++++
drivers/soc/xilinx/Makefile | 2 +
drivers/soc/xilinx/xlnx_vcu.c | 630
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 684 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
create mode 100644 drivers/soc/xilinx/Kconfig
create mode 100644 drivers/soc/xilinx/Makefile
create mode 100644 drivers/soc/xilinx/xlnx_vcu.c
--
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/739c9cba/attachment.sig>
^ permalink raw reply
* [PATCH] [v2] ARM: B15: fix unused label warnings
From: Arnd Bergmann @ 2018-01-08 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102173308.GF28752@n2100.armlinux.org.uk>
On Tue, Jan 2, 2018 at 6:33 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Mon, Dec 18, 2017 at 05:21:24PM -0800, Florian Fainelli wrote:
>> On 12/18/2017 08:52 AM, Arnd Bergmann wrote:
>> > The new conditionally compiled code leaves some labels and one
>> > variable unreferenced when CONFIG_HOTPLUG_CPU and CONFIG_PM_SLEEP
>> > are disabled:
>> >
>> > arch/arm/mm/cache-b15-rac.c: In function 'b15_rac_init':
>> > arch/arm/mm/cache-b15-rac.c:353:1: error: label 'out_unmap' defined but not used [-Werror=unused-label]
>> > out_unmap:
>> > ^~~~~~~~~
>> > arch/arm/mm/cache-b15-rac.c:351:1: error: label 'out_cpu_dead' defined but not used [-Werror=unused-label]
>> > out_cpu_dead:
>> > ^~~~~~~~~~~~
>> > At top level:
>> > arch/arm/mm/cache-b15-rac.c:53:12: error: 'rac_config0_reg' defined but not used [-Werror=unused-variable]
>> >
>> > This replaces the existing #ifdef conditionals with IS_ENABLED()
>> > checks that let the compiler figure out for itself which code to
>> > drop.
>> >
>> > Fixes: 55de88778f4b ("ARM: 8726/1: B15: Add CPU hotplug awareness")
>> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>
>> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>>
>> Thanks Arnd!
>> --
>> Florian
>
> Arnd, can you throw this at the patch system please?
>
> Note that its now possible to add the "KernelVersion" tag in the email
> headers as well as anywhere in the body. The difference is that git
> tools can add headers via standard options.
Sent now as 8741/1, sorry for the delay.
Arnd
^ permalink raw reply
* [PATCH 01/20] dt-bindings: timer: Add Actions Semi S700
From: Daniel Lezcano @ 2018-01-08 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1bbaef2e-4080-3f54-7db3-a8989acfd691@free.fr>
From: Andreas F?rber <afaerber@suse.de>
Define a compatible string for the Actions Semi S700 SoC timer.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Andreas F?rber <afaerber@suse.de>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
Documentation/devicetree/bindings/timer/actions,owl-timer.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/timer/actions,owl-timer.txt b/Documentation/devicetree/bindings/timer/actions,owl-timer.txt
index e3c28da..977054f 100644
--- a/Documentation/devicetree/bindings/timer/actions,owl-timer.txt
+++ b/Documentation/devicetree/bindings/timer/actions,owl-timer.txt
@@ -2,6 +2,7 @@ Actions Semi Owl Timer
Required properties:
- compatible : "actions,s500-timer" for S500
+ "actions,s700-timer" for S700
"actions,s900-timer" for S900
- reg : Offset and length of the register set for the device.
- interrupts : Should contain the interrupts.
--
2.7.4
^ permalink raw reply related
* [PATCH 02/20] clocksource/drivers/owl: Adopt TIMER_OF_DECLARE()
From: Daniel Lezcano @ 2018-01-08 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515418139-23276-1-git-send-email-daniel.lezcano@linaro.org>
From: Andreas F?rber <afaerber@suse.de>
Commit 1727339590fdb5a1ded881b540cd32121278d414 ("clocksource/drivers:
Rename CLOCKSOURCE_OF_DECLARE to TIMER_OF_DECLARE") deprecated
CLOCKSOURCE_OF_DECLARE(), so adopt the new macro TIMER_OF_DECLARE().
Reported-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Andreas F?rber <afaerber@suse.de>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
drivers/clocksource/owl-timer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/owl-timer.c b/drivers/clocksource/owl-timer.c
index c686305..9fb4333 100644
--- a/drivers/clocksource/owl-timer.c
+++ b/drivers/clocksource/owl-timer.c
@@ -168,5 +168,5 @@ static int __init owl_timer_init(struct device_node *node)
return 0;
}
-CLOCKSOURCE_OF_DECLARE(owl_s500, "actions,s500-timer", owl_timer_init);
-CLOCKSOURCE_OF_DECLARE(owl_s900, "actions,s900-timer", owl_timer_init);
+TIMER_OF_DECLARE(owl_s500, "actions,s500-timer", owl_timer_init);
+TIMER_OF_DECLARE(owl_s900, "actions,s900-timer", owl_timer_init);
--
2.7.4
^ permalink raw reply related
* [PATCH 03/20] clocksource/drivers/owl: Add the S700
From: Daniel Lezcano @ 2018-01-08 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515418139-23276-1-git-send-email-daniel.lezcano@linaro.org>
From: Andreas F?rber <afaerber@suse.de>
Actions S700 has two 2Hz timers like S500, and four TIMx timers like S900.
Signed-off-by: Andreas F?rber <afaerber@suse.de>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
drivers/clocksource/owl-timer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clocksource/owl-timer.c b/drivers/clocksource/owl-timer.c
index 9fb4333..ea00a5e 100644
--- a/drivers/clocksource/owl-timer.c
+++ b/drivers/clocksource/owl-timer.c
@@ -169,4 +169,5 @@ static int __init owl_timer_init(struct device_node *node)
return 0;
}
TIMER_OF_DECLARE(owl_s500, "actions,s500-timer", owl_timer_init);
+TIMER_OF_DECLARE(owl_s700, "actions,s700-timer", owl_timer_init);
TIMER_OF_DECLARE(owl_s900, "actions,s900-timer", owl_timer_init);
--
2.7.4
^ permalink raw reply related
* [PATCH 04/20] clocksource/drivers/tcb_clksrc: Fix clock speed message
From: Daniel Lezcano @ 2018-01-08 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515418139-23276-1-git-send-email-daniel.lezcano@linaro.org>
From: Romain Izard <romain.izard.pro@gmail.com>
The clock speed displayed at boot in an information message was 500 kHz
too high compared to its real value. As the value is not used anywhere,
there is no functional impact.
Fix the rounding formula to display the correct value.
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
drivers/clocksource/tcb_clksrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index 9de47d4..43f4d5c 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -384,7 +384,7 @@ static int __init tcb_clksrc_init(void)
printk(bootinfo, clksrc.name, CONFIG_ATMEL_TCB_CLKSRC_BLOCK,
divided_rate / 1000000,
- ((divided_rate + 500000) % 1000000) / 1000);
+ ((divided_rate % 1000000) + 500) / 1000);
if (tc->tcb_config && tc->tcb_config->counter_width == 32) {
/* use apropriate function to read 32 bit counter */
--
2.7.4
^ permalink raw reply related
* [PATCH 11/20] clocksource/drivers/stm32: Fix kernel panic with multiple timers
From: Daniel Lezcano @ 2018-01-08 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515418139-23276-1-git-send-email-daniel.lezcano@linaro.org>
The current code hides a couple of bugs.
- The global variable 'clock_event_ddata' is overwritten each time the
init function is invoked.
This is fixed with a kmemdup instead of assigning the global variable. That
prevents a memory corruption when several timers are defined in the DT.
- The clockevent's event_handler is NULL if the time framework does
not select the clockevent when registering it, this is fine but the init
code generates in any case an interrupt leading to dereference this
NULL pointer.
The stm32 timer works with shadow registers, a mechanism to cache the
registers. When a change is done in one buffered register, we need to
artificially generate an event to force the timer to copy the content
of the register to the shadowed register.
The auto-reload register (ARR) is one of the shadowed register as well as
the prescaler register (PSC), so in order to force the copy, we issue an
event which in turn leads to an interrupt and the NULL dereference.
This is fixed by inverting two lines where we clear the status register
before enabling the update event interrupt.
As this kernel crash is resulting from the combination of these two bugs,
the fixes are grouped into a single patch.
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Tested-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/clocksource/timer-stm32.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index 8f24237..4bfeb99 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -106,6 +106,10 @@ static int __init stm32_clockevent_init(struct device_node *np)
unsigned long rate, max_delta;
int irq, ret, bits, prescaler = 1;
+ data = kmemdup(&clock_event_ddata, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
clk = of_clk_get(np, 0);
if (IS_ERR(clk)) {
ret = PTR_ERR(clk);
@@ -156,8 +160,8 @@ static int __init stm32_clockevent_init(struct device_node *np)
writel_relaxed(prescaler - 1, data->base + TIM_PSC);
writel_relaxed(TIM_EGR_UG, data->base + TIM_EGR);
- writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
writel_relaxed(0, data->base + TIM_SR);
+ writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
@@ -184,6 +188,7 @@ static int __init stm32_clockevent_init(struct device_node *np)
err_clk_enable:
clk_put(clk);
err_clk_get:
+ kfree(data);
return ret;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 12/20] clocksource/drivers/stm32: Convert the driver to timer-of
From: Daniel Lezcano @ 2018-01-08 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515418139-23276-1-git-send-email-daniel.lezcano@linaro.org>
From: Benjamin Gaignard <benjamin.gaignard@st.com>
Convert the driver to use the timer_of helpers. This allows to remove custom
proprietary structure, factors out and simplifies the code.
[Daniel Lezcano] : Respin against the critical fix patch and massaged the
changelog.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Tested-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/clocksource/Kconfig | 1 +
drivers/clocksource/timer-stm32.c | 187 +++++++++++++++-----------------------
2 files changed, 74 insertions(+), 114 deletions(-)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 9a6b087..786db7a 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -269,6 +269,7 @@ config CLKSRC_STM32
bool "Clocksource for STM32 SoCs" if !ARCH_STM32
depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
select CLKSRC_MMIO
+ select TIMER_OF
config CLKSRC_MPS2
bool "Clocksource for MPS2 SoCs" if COMPILE_TEST
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index 4bfeb99..3e4ab07 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -16,6 +16,9 @@
#include <linux/of_irq.h>
#include <linux/clk.h>
#include <linux/reset.h>
+#include <linux/slab.h>
+
+#include "timer-of.h"
#define TIM_CR1 0x00
#define TIM_DIER 0x0c
@@ -34,162 +37,118 @@
#define TIM_EGR_UG BIT(0)
-struct stm32_clock_event_ddata {
- struct clock_event_device evtdev;
- unsigned periodic_top;
- void __iomem *base;
-};
-
-static int stm32_clock_event_shutdown(struct clock_event_device *evtdev)
+static int stm32_clock_event_shutdown(struct clock_event_device *clkevt)
{
- struct stm32_clock_event_ddata *data =
- container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
- void *base = data->base;
+ struct timer_of *to = to_timer_of(clkevt);
+
+ writel_relaxed(0, timer_of_base(to) + TIM_CR1);
- writel_relaxed(0, base + TIM_CR1);
return 0;
}
-static int stm32_clock_event_set_periodic(struct clock_event_device *evtdev)
+static int stm32_clock_event_set_periodic(struct clock_event_device *clkevt)
{
- struct stm32_clock_event_ddata *data =
- container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
- void *base = data->base;
+ struct timer_of *to = to_timer_of(clkevt);
+
+ writel_relaxed(timer_of_period(to), timer_of_base(to) + TIM_ARR);
+ writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, timer_of_base(to) + TIM_CR1);
- writel_relaxed(data->periodic_top, base + TIM_ARR);
- writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, base + TIM_CR1);
return 0;
}
static int stm32_clock_event_set_next_event(unsigned long evt,
- struct clock_event_device *evtdev)
+ struct clock_event_device *clkevt)
{
- struct stm32_clock_event_ddata *data =
- container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
+ struct timer_of *to = to_timer_of(clkevt);
- writel_relaxed(evt, data->base + TIM_ARR);
+ writel_relaxed(evt, timer_of_base(to) + TIM_ARR);
writel_relaxed(TIM_CR1_ARPE | TIM_CR1_OPM | TIM_CR1_CEN,
- data->base + TIM_CR1);
+ timer_of_base(to) + TIM_CR1);
return 0;
}
static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
{
- struct stm32_clock_event_ddata *data = dev_id;
+ struct clock_event_device *clkevt = (struct clock_event_device *)dev_id;
+ struct timer_of *to = to_timer_of(clkevt);
- writel_relaxed(0, data->base + TIM_SR);
+ writel_relaxed(0, timer_of_base(to) + TIM_SR);
- data->evtdev.event_handler(&data->evtdev);
+ clkevt->event_handler(clkevt);
return IRQ_HANDLED;
}
-static struct stm32_clock_event_ddata clock_event_ddata = {
- .evtdev = {
- .name = "stm32 clockevent",
- .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
- .set_state_shutdown = stm32_clock_event_shutdown,
- .set_state_periodic = stm32_clock_event_set_periodic,
- .set_state_oneshot = stm32_clock_event_shutdown,
- .tick_resume = stm32_clock_event_shutdown,
- .set_next_event = stm32_clock_event_set_next_event,
- .rating = 200,
- },
-};
-
-static int __init stm32_clockevent_init(struct device_node *np)
+static void __init stm32_clockevent_init(struct timer_of *to)
{
- struct stm32_clock_event_ddata *data = &clock_event_ddata;
- struct clk *clk;
- struct reset_control *rstc;
- unsigned long rate, max_delta;
- int irq, ret, bits, prescaler = 1;
-
- data = kmemdup(&clock_event_ddata, sizeof(*data), GFP_KERNEL);
- if (!data)
- return -ENOMEM;
-
- clk = of_clk_get(np, 0);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
- pr_err("failed to get clock for clockevent (%d)\n", ret);
- goto err_clk_get;
- }
-
- ret = clk_prepare_enable(clk);
- if (ret) {
- pr_err("failed to enable timer clock for clockevent (%d)\n",
- ret);
- goto err_clk_enable;
- }
-
- rate = clk_get_rate(clk);
-
- rstc = of_reset_control_get(np, NULL);
- if (!IS_ERR(rstc)) {
- reset_control_assert(rstc);
- reset_control_deassert(rstc);
- }
-
- data->base = of_iomap(np, 0);
- if (!data->base) {
- ret = -ENXIO;
- pr_err("failed to map registers for clockevent\n");
- goto err_iomap;
- }
+ unsigned long max_delta;
+ int prescaler;
- irq = irq_of_parse_and_map(np, 0);
- if (!irq) {
- ret = -EINVAL;
- pr_err("%pOF: failed to get irq.\n", np);
- goto err_get_irq;
- }
+ to->clkevt.name = "stm32_clockevent";
+ to->clkevt.features = CLOCK_EVT_FEAT_PERIODIC;
+ to->clkevt.set_state_shutdown = stm32_clock_event_shutdown;
+ to->clkevt.set_state_periodic = stm32_clock_event_set_periodic;
+ to->clkevt.set_state_oneshot = stm32_clock_event_shutdown;
+ to->clkevt.tick_resume = stm32_clock_event_shutdown;
+ to->clkevt.set_next_event = stm32_clock_event_set_next_event;
/* Detect whether the timer is 16 or 32 bits */
- writel_relaxed(~0U, data->base + TIM_ARR);
- max_delta = readl_relaxed(data->base + TIM_ARR);
+ writel_relaxed(~0U, timer_of_base(to) + TIM_ARR);
+ max_delta = readl_relaxed(timer_of_base(to) + TIM_ARR);
if (max_delta == ~0U) {
prescaler = 1;
- bits = 32;
+ to->clkevt.rating = 250;
} else {
prescaler = 1024;
- bits = 16;
+ to->clkevt.rating = 100;
}
- writel_relaxed(0, data->base + TIM_ARR);
+ writel_relaxed(0, timer_of_base(to) + TIM_ARR);
- writel_relaxed(prescaler - 1, data->base + TIM_PSC);
- writel_relaxed(TIM_EGR_UG, data->base + TIM_EGR);
- writel_relaxed(0, data->base + TIM_SR);
- writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
+ writel_relaxed(prescaler - 1, timer_of_base(to) + TIM_PSC);
+ writel_relaxed(TIM_EGR_UG, timer_of_base(to) + TIM_EGR);
+ writel_relaxed(0, timer_of_base(to) + TIM_SR);
+ writel_relaxed(TIM_DIER_UIE, timer_of_base(to) + TIM_DIER);
- data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
+ /* Adjust rate and period given the prescaler value */
+ to->of_clk.rate = DIV_ROUND_CLOSEST(to->of_clk.rate, prescaler);
+ to->of_clk.period = DIV_ROUND_UP(to->of_clk.rate, HZ);
- clockevents_config_and_register(&data->evtdev,
- DIV_ROUND_CLOSEST(rate, prescaler),
- 0x1, max_delta);
-
- ret = request_irq(irq, stm32_clock_event_handler, IRQF_TIMER,
- "stm32 clockevent", data);
- if (ret) {
- pr_err("%pOF: failed to request irq.\n", np);
- goto err_get_irq;
- }
+ clockevents_config_and_register(&to->clkevt,
+ timer_of_rate(to), 0x1, max_delta);
pr_info("%pOF: STM32 clockevent driver initialized (%d bits)\n",
- np, bits);
+ to->np, max_delta == UINT_MAX ? 32 : 16);
+}
- return ret;
+static int __init stm32_timer_init(struct device_node *node)
+{
+ struct reset_control *rstc;
+ struct timer_of *to;
+ int ret;
+
+ to = kzalloc(sizeof(*to), GFP_KERNEL);
+ if (!to)
+ return -ENOMEM;
+
+ to->flags = TIMER_OF_IRQ | TIMER_OF_CLOCK | TIMER_OF_BASE;
+ to->of_irq.handler = stm32_clock_event_handler;
+
+ ret = timer_of_init(node, to);
+ if (ret)
+ goto err;
-err_get_irq:
- iounmap(data->base);
-err_iomap:
- clk_disable_unprepare(clk);
-err_clk_enable:
- clk_put(clk);
-err_clk_get:
- kfree(data);
+ rstc = of_reset_control_get(node, NULL);
+ if (!IS_ERR(rstc)) {
+ reset_control_assert(rstc);
+ reset_control_deassert(rstc);
+ }
+
+ stm32_clockevent_init(to);
+ return 0;
+err:
+ kfree(to);
return ret;
}
-TIMER_OF_DECLARE(stm32, "st,stm32-timer", stm32_clockevent_init);
+TIMER_OF_DECLARE(stm32, "st,stm32-timer", stm32_timer_init);
--
2.7.4
^ permalink raw reply related
* [PATCH 13/20] clocksource/drivers/stm32: Use the node name as timer name
From: Daniel Lezcano @ 2018-01-08 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515418139-23276-1-git-send-email-daniel.lezcano@linaro.org>
As there are different timers on the stm32, use the node name for the timer
name in order to give the indication of which timer the kernel is using.
The /proc/timer_list gives all the information with the right name, otherwise
we end up digging in the kernel log and /proc/interrupt to do the connection
between the used timer.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Tested-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/clocksource/timer-stm32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index 3e4ab07..14b7a2b 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -85,7 +85,7 @@ static void __init stm32_clockevent_init(struct timer_of *to)
unsigned long max_delta;
int prescaler;
- to->clkevt.name = "stm32_clockevent";
+ to->clkevt.name = to->np->full_name;
to->clkevt.features = CLOCK_EVT_FEAT_PERIODIC;
to->clkevt.set_state_shutdown = stm32_clock_event_shutdown;
to->clkevt.set_state_periodic = stm32_clock_event_set_periodic;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox