* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Nikita Yushchenko @ 2017-01-12 5:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <30025121.yS4lyZEDrk@wuerfel>
>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>> index 5ac373c..480b644 100644
>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
>>
>> /* Objects are coherent, unless 'no shareability' flag set. */
>> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
>> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
>> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
>>
>> /*
>> * The device-specific probe callback will get invoked by device_add()
>
> Why are these actually calling arch_setup_dma_ops() here in the first
> place? Are these all devices that are DMA masters without an OF node?
I don't know, but that's a different topic. This patch just adds
argument and sets it to false everywhere but in the location when range
should be definitely enforced.
>> @@ -126,6 +127,8 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> return;
>> }
>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>> +
>> + enforce_range = true;
>> }
>>
>> dev->dma_pfn_offset = offset;
>
> Hmm, I think when the dma-ranges are missing, we should either enforce
> a 32-bit mask, or disallow DMA completely. It's probably too late for
> the latter, I wish we had done this earlier in order to force everyone
> on ARM64 to have a valid dma-ranges property for any DMA master.
This can be done over time.
However the very idea of this version of patch is - keep working pieces
as-is, thus for now setting enforce_range to false in case of no defined
dma-ranges is intentional.
What I should re-check is - does rcar dtsi set dma-ranges, and add it if
it does not.
Nikita
^ permalink raw reply
* [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports
From: Nikita Yushchenko @ 2017-01-12 5:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2489599.dXme8sRkvp@wuerfel>
>> @@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>> if (!dev->archdata.dma_ops)
>> dev->archdata.dma_ops = &swiotlb_dma_ops;
>>
>> + /*
>> + * Whatever the parent bus can set. A device must not set
>> + * a DMA mask larger than this.
>> + */
>> + if (enforce_range)
>> + dev->archdata.parent_dma_mask = size - 1;
>> + else
>> + dev->archdata.parent_dma_mask = DMA_BIT_MASK(64);
>> +
>> dev->archdata.dma_coherent = coherent;
>> __iommu_setup_dma_ops(dev, dma_base, size, iommu);
>>
>
> Could we just pass the mask instead of the size here?
We don't want to change API now.
Nikita
^ permalink raw reply
* [PATCH v3 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
From: Anurup M @ 2017-01-12 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110174515.GC24036@leverpostej>
On Tuesday 10 January 2017 11:15 PM, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 10:28:54AM +0530, Anurup M wrote:
>>
>> On Wednesday 04 January 2017 04:26 AM, Rob Herring wrote:
>>> On Mon, Jan 02, 2017 at 01:49:03AM -0500, Anurup M wrote:
>>>> From: Tan Xiaojun <tanxiaojun@huawei.com>
>>>>
>>>> Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
>>>>
>>>> Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
>>>> Signed-off-by: Anurup M <anurup.m@huawei.com>
>>>> ---
>>>> .../devicetree/bindings/arm/hisilicon/djtag.txt | 41 ++++++++++++++++++++++
>>>> 1 file changed, 41 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>>>> new file mode 100644
>>>> index 0000000..bbe8b45
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>>>> @@ -0,0 +1,41 @@
>>>> +The Hisilicon Djtag is an independent component which connects with some other
>>>> +components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
>>>> +in the chip. The djtag controls access to connecting modules of CPU and IO
>>>> +dies.
>>>> +The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
>>>> +are accessed by djtag during real time debugging. In IO die there are connecting
>>>> +components like RSA. These components appear as devices attached to djtag bus.
>>>> +
>>>> +Hisilicon HiP05/06/07 djtag for CPU and IO die
>>>> +Required properties:
>>>> + - compatible : The value should be as follows
>>>> + (a) "hisilicon,hip05-djtag-v1" for CPU and IO die which use v1 hw in
>>>> + HiP05 chipset.
>>> You don't need to distinguish the CPU and IO blocks?
>> The CPU and IO djtag nodes will have different base address(in reg
>> property).
>> There is no difference in handling of CPU and IO dies in the djtag driver.
>> So there is currently no need to distinguish them.
> It may still make sense to distinuguish them, even if the current djtag
> driver can handle them the same. Presumably clients of the djtag driver
> will poke CPU and IO djtag units differently.
Ok. I shall add "-cpu-/-io-" in the compatible field to distinguish.
e.g. "hisilicon,hip05-cpu-djtag-v1".
Thanks,
Anurup
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH v3 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters
From: Anurup M @ 2017-01-12 6:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110174311.GB24036@leverpostej>
On Tuesday 10 January 2017 11:13 PM, Mark Rutland wrote:
> Hi,
>
> On Mon, Jan 02, 2017 at 01:47:52AM -0500, Anurup M wrote:
>> ToDo:
>> 1) The counter overflow handling is currently unsupported in this
>> patch series.
> From a quick scan of the patches, I see mention of an interrupt in a
> comment the driver, but there's noething in the DT binding.
>
> Is there an overflow interrupt at all?
>
> Or do you need to implement polling to avoid overflow?
>
> This is a prerequisite for merging the driver.
The HiP0x chips support counter overflow interrupt for L3C and MN.
The HiP05/06 interrupts in CPU die use Hisilicon mbigen-v1, but the
mbigen-v1
driver is not available in mainline. So the L3C and MN PMU in HiP05/06
cannot
support counter overflow in driver.
As the support for HiP05/06 are not the prime focus now. I shall remove
them
from the patch series and shall plan to include them later.
For HiP07, as it use mbigen-v2, which is in mainline, I shall include
the overflow
handling support in the next revision (V4 series).
Thanks,
Anurup
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Nikita Yushchenko @ 2017-01-12 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <764334db-3400-58c6-cc4b-3f7ce66daa27@cogentembedded.com>
12.01.2017 08:52, Nikita Yushchenko wrote:
>>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>> index 5ac373c..480b644 100644
>>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
>>>
>>> /* Objects are coherent, unless 'no shareability' flag set. */
>>> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
>>> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
>>> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
>>>
>>> /*
>>> * The device-specific probe callback will get invoked by device_add()
>>
>> Why are these actually calling arch_setup_dma_ops() here in the first
>> place? Are these all devices that are DMA masters without an OF node?
>
> I don't know, but that's a different topic. This patch just adds
> argument and sets it to false everywhere but in the location when range
> should be definitely enforced.
>
>>> @@ -126,6 +127,8 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>>> return;
>>> }
>>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>>> +
>>> + enforce_range = true;
>>> }
>>>
>>> dev->dma_pfn_offset = offset;
>>
>> Hmm, I think when the dma-ranges are missing, we should either enforce
>> a 32-bit mask, or disallow DMA completely. It's probably too late for
>> the latter, I wish we had done this earlier in order to force everyone
>> on ARM64 to have a valid dma-ranges property for any DMA master.
>
> This can be done over time.
>
> However the very idea of this version of patch is - keep working pieces
> as-is, thus for now setting enforce_range to false in case of no defined
> dma-ranges is intentional.
What we can do is - check bus width (as it is defined in DT) and set
enforce_range to true if bus is 32-bit
> What I should re-check is - does rcar dtsi set dma-ranges, and add it if
> it does not.
It does not, will have to add.
In DT bus is defined as 64-bit. But looks like physically it is 32-bit.
Maybe DT needs fixing.
^ permalink raw reply
* [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Krzysztof Kozlowski @ 2017-01-12 6:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGTfZH0H_kA9cRPG4Vqh3iLZncfXqfKDFiSYEXV1zp+9yFP25Q@mail.gmail.com>
On Wed, Jan 11, 2017 at 11:22 PM, Chanwoo Choi <cwchoi00@gmail.com> wrote:
> 2017-01-12 1:26 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
>> On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
>>> This patch replaces the small letter of base address, offset and hex value
>>> with the capital letter to keep the consistency on Exynos5433.
>>>
>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> index abaf6b4d599d..d7ed1a68b6fd 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> @@ -231,7 +231,7 @@
>>> compatible = "arm,psci";
>>> method = "smc";
>>> cpu_off = <0x84000002>;
>>> - cpu_on = <0xC4000003>;
>>> + cpu_on = <0xc4000003>;
>>
>> There is no point of such "improvements". This is just unnecessary
>> churn.
>>
>> Sometimes such things are accepted as part of some bigger work (vide
>> recent Andrzej's sysmmu for HDMI/TV). But on its own? No sense at all.
>
> Do you mean that this patch is not reasonable? or
> The modification of cpu_on property is only not reasonable?
>
> It is simple for the consistency to use the hex value in dts file.
The patch is not reasonable (as sent alone).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704
From: Tomasz Nowicki @ 2017-01-12 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2c048126-a4d6-16af-987a-3174401a3960@arm.com>
On 11.01.2017 13:19, Robin Murphy wrote:
> On 11/01/17 11:51, Tomasz Nowicki wrote:
>> The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs
>> are unique across all SMMU instances on affected Cavium systems.
>>
>> Currently, the workaround code partitions ASIDs and VMIDs by increasing
>> global cavium_smmu_context_count which in turn becomes the base ASID and VMID
>> value for the given SMMU instance upon the context bank initialization.
>>
>> For systems with multiple SMMU instances this approach implies the risk
>> of crossing 8-bit ASID, like for CN88xx capable of 4 SMMUv2, 128 context bank each:
>> SMMU_0 (0-127 ASID RANGE)
>> SMMU_1 (127-255 ASID RANGE)
>> SMMU_2 (256-383 ASID RANGE) <--- crossing 8-bit ASID
>> SMMU_3 (384-511 ASID RANGE) <--- crossing 8-bit ASID
>
> I could swear that at some point in the original discussion it was said
> that the TLBs were only shared between pairs of SMMUs, so in fact 0/1
> and 2/3 are independent of each other
Indeed TLBs are only shared between pairs of SMMUs but the workaround
makes sure ASIDs are unique across all SMMU instances so we do not have
to bother about SMMUs probe order.
- out of interest, have you
> managed to hit an actual problem in practice or is this patch just by
> inspection?
Except SMMU0/1 devices all other devices under other SMMUs will fail on
guest power off/on. Since we try to invalidate tlb with 16bit ASID but
we actually have 8 bit zero padded 16 bit entry.
>
> Of course, depending on the SMMUs to probe in the right order isn't
> particularly robust, so it's still probably a worthwhile change.
>
>> Since we use 8-bit ASID now we effectively misconfigure ASID[15:8] bits for
>> SMMU_CBn_TTBRm register. Also, we still use non-zero ASID[15:8] bits
>> upon context invalidation. This patch adds 16-bit ASID support for stage-1
>> AArch64 contexts for Cavium SMMUv2 model so that we use ASIDs consistently.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> ---
>> drivers/iommu/arm-smmu.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index a60cded..ae8f059 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -260,6 +260,7 @@ enum arm_smmu_s2cr_privcfg {
>>
>> #define TTBCR2_SEP_SHIFT 15
>> #define TTBCR2_SEP_UPSTREAM (0x7 << TTBCR2_SEP_SHIFT)
>> +#define TTBCR2_AS (1 << 4)
>>
>> #define TTBRn_ASID_SHIFT 48
>>
>> @@ -778,6 +779,9 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>> reg = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
>> reg2 = pgtbl_cfg->arm_lpae_s1_cfg.tcr >> 32;
>> reg2 |= TTBCR2_SEP_UPSTREAM;
>> + if (smmu->model == CAVIUM_SMMUV2 &&
>
> I'd be inclined to say "smmu->version == ARM_SMMU_V2" there, rather than
> make it Cavium-specific - we enable 16-bit VMID unconditionally where
> supported, so I don't see any reason not to handle 16-bit ASIDs in the
> same manner.
I agree, I will enable 16-bit ASID for ARM_SMMU_V2.
>
>> + cfg->fmt == ARM_SMMU_CTX_FMT_AARCH64)
>> + reg2 |= TTBCR2_AS;
>> }
>> if (smmu->version > ARM_SMMU_V1)
>> writel_relaxed(reg2, cb_base + ARM_SMMU_CB_TTBCR2);
>>
>
> Either way:
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Thanks Robin!
Tomasz
^ permalink raw reply
* [PATCH v2 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set
From: Baolin Wang @ 2017-01-12 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMz4kuJP9Q7Ly4uRBjCFU32YzbVbnsGyk+wHc+M=g8W=uDBsEQ@mail.gmail.com>
On 3 January 2017 at 13:54, Baolin Wang <baolin.wang@linaro.org> wrote:
> Hi Kison and Heiko,
>
> On 21 December 2016 at 16:12, Baolin Wang <baolin.wang@linaro.org> wrote:
>> According to the documentation, we should set the EXTCON_USB when
>> one SDP charger connector was reported.
>>
>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>
> Could you apply this patch if there are no other comments? Thanks.
Ping?
--
Baolin.wang
Best Regards
^ permalink raw reply
* [PATCH] ARM: defconfig: include QCOM_EBI2 in multi_v7
From: Linus Walleij @ 2017-01-12 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cee567ef-adc3-eb3f-81bb-e8a678b35fa8@codeaurora.org>
On Thu, Jan 12, 2017 at 2:01 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 01/11/2017 07:22 AM, Linus Walleij wrote:
>> On Tue, Jan 10, 2017 at 7:02 PM, Olof Johansson <olof@lixom.net> wrote:
>>> On Tue, Jan 10, 2017 at 2:09 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>>> This adds the Qualcomm External Bus Interface 2 to the multi_v7
>>>> defconfig: it is hard for users to realize that this is a
>>>> required driver for getting things like ethernet, and a necessary
>>>> prerequisite to get the external bus discoverable on the
>>>> MSM8660/APQ8060 machines.
>>> Is it the kind of option that should really be selected through
>>> Kconfig instead for those platforms?
>>
>> Stephen Boyd question.
>>
>> AFAIK the ambition is to go with the platform to have zero
>> stuff in mach-qcom/* and thus it all becomes a defconfig
>> thing.
>
> It could be made a 'default ARCH_QCOM' type of thing. Then the config
> doesn't need an update unless you want to turn it off.
OK I will do that.
Olof: let's scrap this patch.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] bus: qcom_ebi2: default y if ARCH_QCOM
From: Linus Walleij @ 2017-01-12 7:08 UTC (permalink / raw)
To: linux-arm-kernel
Since we want this external bus to be available on multi_v7 builds,
set to default ARCH_QCOM so we get it selected whenever QCOM is
enabled.
Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Andy: I guess you could queue this to ARM SoC, they seem so manage
drivers/bus from there.
---
drivers/bus/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index b9e8cfc93c7e..0a52da439abf 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -112,6 +112,7 @@ config QCOM_EBI2
bool "Qualcomm External Bus Interface 2 (EBI2)"
depends on HAS_IOMEM
depends on ARCH_QCOM || COMPILE_TEST
+ default ARCH_QCOM
help
Say y here to enable support for the Qualcomm External Bus
Interface 2, which can be used to connect things like NAND Flash,
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: Sekhar Nori @ 2017-01-12 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1dd57ac3-554f-7d66-97b0-b76c3ddc7854@lechnology.com>
On Wednesday 11 January 2017 09:55 PM, David Lechner wrote:
>>> +&spi0 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
>>> +
>>> + flash at 0 {
>>> + compatible = "n25q128a13", "jedec,spi-nor";
>>> + reg = <0>;
>>> + spi-max-frequency = <50000000>;
>>> + ti,spi-wdelay = <8>;
>>> +
>>> + /* Partitions are based on the official firmware from LEGO */
>>> + partitions {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + partition at 0 {
>>> + label = "U-Boot";
>>> + reg = <0 0x40000>;
>>> + };
>>> +
>>> + partition at 40000 {
>>> + label = "U-Boot Env";
>>> + reg = <0x40000 0x10000>;
>>> + };
>>> +
>>> + partition at 50000 {
>>> + label = "Kernel";
>>> + reg = <0x50000 0x200000>;
>>> + };
>>> +
>>> + partition at 250000 {
>>> + label = "Filesystem";
>>> + reg = <0x250000 0xa50000>;
>>> + };
>>> +
>>> + partition at cb0000 {
>>> + label = "Storage";
>>> + reg = <0xcb0000 0x2f0000>;
>>> + };
>>> + };
>>> + };
>>> +
>>> + adc at 3 {
>>> + compatible = "ti-ads7957";
>>
>> So looks like this works because of_register_spi_device() sets up
>> modalias of spi device from compatible string. I am fine with it, just
>> highlighting it here to make sure this is acceptable practice. I did not
>> really find any precedence for using SPI device name as compatible
>> property in existing DTS files.
>
> Indeed. It looks like this sort of "trivial" device binding is just used
> for i2c devices. I will submit some patches to add proper device tree
> bindings and change this to "ti,ads7957".
Alright, if you are going to do that, then I suggest you respin this
patch with the adc node dropped for now. That way we can ensure basic
board support in v4.11. If dependencies pan out, the adc can go in too
as a separate patch.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Auger Eric @ 2017-01-12 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM5PR0401MB254547FE747461B3332721FC9A790@AM5PR0401MB2545.eurprd04.prod.outlook.com>
Hi Bharat,
On 12/01/2017 04:59, Bharat Bhushan wrote:
>
>
>> -----Original Message-----
>> From: Eric Auger [mailto:eric.auger at redhat.com]
>> Sent: Wednesday, January 11, 2017 3:12 PM
>> To: eric.auger at redhat.com; eric.auger.pro at gmail.com;
>> christoffer.dall at linaro.org; marc.zyngier at arm.com;
>> robin.murphy at arm.com; alex.williamson at redhat.com;
>> will.deacon at arm.com; joro at 8bytes.org; tglx at linutronix.de;
>> jason at lakedaemon.net; linux-arm-kernel at lists.infradead.org
>> Cc: kvm at vger.kernel.org; drjones at redhat.com; linux-
>> kernel at vger.kernel.org; pranav.sawargaonkar at gmail.com;
>> iommu at lists.linux-foundation.org; punit.agrawal at arm.com; Diana Madalina
>> Craciun <diana.craciun@nxp.com>; gpkulkarni at gmail.com;
>> shankerd at codeaurora.org; Bharat Bhushan <bharat.bhushan@nxp.com>;
>> geethasowjanya.akula at gmail.com
>> Subject: [PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and
>> IOVA reserved regions
>>
>> Following LPC discussions, we now report reserved regions through the
>> iommu-group sysfs reserved_regions attribute file.
>>
>> Reserved regions are populated through the IOMMU get_resv_region
>> callback (former get_dm_regions), now implemented by amd-iommu, intel-
>> iommu and arm-smmu:
>> - the intel-iommu reports the [0xfee00000 - 0xfeefffff] MSI window
>> as a reserved region and RMRR regions as direct-mapped regions.
>> - the amd-iommu reports device direct mapped regions, the MSI region
>> and HT regions.
>> - the arm-smmu reports the MSI window (arbitrarily located at
>> 0x8000000 and 1MB large).
>>
>> Unsafe interrupt assignment is tested by enumerating all MSI irq domains
>> and checking MSI remapping is supported in the above hierarchy.
>> This check is done in case we detect the iommu translates MSI (an
>> IOMMU_RESV_MSI window exists). Otherwise the IRQ remapping capability
>> is checked at IOMMU level. Obviously this is a defensive IRQ safety
>> assessment: Assuming there are several MSI controllers in the system and at
>> least one does not implement IRQ remapping, the assignment will be
>> considered as unsafe (even if this controller is not acessible from the
>> assigned devices).
>>
>> The series first patch stems from Robin's branch:
>> http://linux-arm.org/git?p=linux-
>> rm.git;a=shortlog;h=refs/heads/iommu/misc
>>
>> Best Regards
>>
>> Eric
>>
>> Git: complete series available at
>> https://github.com/eauger/linux/tree/v4.10-rc3-reserved-v8
>
> This series is tested on NXP platform, if you want you can add my tested by
> Tested-by: Bharat Bhushan <bharat.bhushan@nxp.com>
Thank you for this!
Best Regards
Eric
>
> Thanks
> -Bharat
>
>>
>> istory:
>>
>> PATCHv7 -> PATCHv8
>> - take into account Marc's comments and apply his R-b
>> - remove iommu_group_remove_file call in iommu_group_release
>> - add Will's A-b
>> - removed [PATCH v7 01/19] iommu/dma: Implement PCI allocation
>> optimisation and updated iommu/dma: Allow MSI-only cookies
>> as per Robin's indications
>>
>> PATCHv6 -> PATCHv7:
>> - iommu/dma: Implement PCI allocation optimisation was added to apply
>> iommu/dma: Allow MSI-only cookies
>> - report Intel RMRR as direct-mapped regions
>> - report the type in the iommu group sysfs reserved_regions file
>> - do not merge regions of different types when building the list
>> of reserved regions
>> - intgeration Robin's "iommu/dma: Allow MSI-only cookies" last
>> version
>> - update Documentation/ABI/testing/sysfs-kernel-iommu_groups
>> - rename IOMMU_RESV_NOMAP into IOMMU_RESV_RESERVED
>>
>> PATCHv5 -> PATCHv6
>> - Introduce IRQ_DOMAIN_FLAG_MSI as suggested by Marc
>> - irq_domain_is_msi, irq_domain_is_msi_remap,
>> irq_domain_hierarchical_is_msi_remap,
>> - set IRQ_DOMAIN_FLAG_MSI in msi_create_irq_domain
>> - fix compil issue on i386
>> - rework test at VFIO level
>>
>> RFCv4 -> PATCHv5
>> - fix IRQ security assessment by looking at irq domain parents
>> - check DOMAIN_BUS_FSL_MC_MSI irq domains
>> - AMD MSI and HT regions are exposed in iommu group sysfs
>>
>> RFCv3 -> RFCv4:
>> - arm-smmu driver does not register PCI host bridge windows as
>> reserved regions anymore
>> - Implement reserved region get/put callbacks also in arm-smmuv3
>> - take the iommu_group lock on iommu_get_group_resv_regions
>> - add a type field in iommu_resv_region instead of using prot
>> - init the region list_head in iommu_alloc_resv_region, also
>> add type parameter
>> - iommu_insert_resv_region manage overlaps and sort reserved
>> windows
>> - address IRQ safety assessment by enumerating all the MSI irq
>> domains and checking the MSI_REMAP flag
>> - update Documentation/ABI/testing/sysfs-kernel-iommu_groups
>>
>> RFC v2 -> v3:
>> - switch to an iommu-group sysfs API
>> - use new dummy allocator provided by Robin
>> - dummy allocator initialized by vfio-iommu-type1 after enumerating
>> the reserved regions
>> - at the moment ARM MSI base address/size is left unchanged compared
>> to v2
>> - we currently report reserved regions and not usable IOVA regions as
>> requested by Alex
>>
>> RFC v1 -> v2:
>> - fix intel_add_reserved_regions
>> - add mutex lock/unlock in vfio_iommu_type1
>>
>>
>> Eric Auger (17):
>> iommu: Rename iommu_dm_regions into iommu_resv_regions
>> iommu: Add a new type field in iommu_resv_region
>> iommu: iommu_alloc_resv_region
>> iommu: Only map direct mapped regions
>> iommu: iommu_get_group_resv_regions
>> iommu: Implement reserved_regions iommu-group sysfs file
>> iommu/vt-d: Implement reserved region get/put callbacks
>> iommu/amd: Declare MSI and HT regions as reserved IOVA regions
>> iommu/arm-smmu: Implement reserved region get/put callbacks
>> iommu/arm-smmu-v3: Implement reserved region get/put callbacks
>> irqdomain: Add irq domain MSI and MSI_REMAP flags
>> genirq/msi: Set IRQ_DOMAIN_FLAG_MSI on MSI domain creation
>> irqdomain: irq_domain_check_msi_remap
>> irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP
>> vfio/type1: Allow transparent MSI IOVA allocation
>> vfio/type1: Check MSI remapping at irq domain level
>> iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP anymore
>>
>> Robin Murphy (1):
>> iommu/dma: Allow MSI-only cookies
>>
>> .../ABI/testing/sysfs-kernel-iommu_groups | 12 ++
>> drivers/iommu/amd_iommu.c | 54 ++++---
>> drivers/iommu/arm-smmu-v3.c | 30 +++-
>> drivers/iommu/arm-smmu.c | 30 +++-
>> drivers/iommu/dma-iommu.c | 119 +++++++++++---
>> drivers/iommu/intel-iommu.c | 92 ++++++++---
>> drivers/iommu/iommu.c | 177 +++++++++++++++++++--
>> drivers/irqchip/irq-gic-v3-its.c | 1 +
>> drivers/vfio/vfio_iommu_type1.c | 37 ++++-
>> include/linux/dma-iommu.h | 6 +
>> include/linux/iommu.h | 46 ++++--
>> include/linux/irqdomain.h | 36 +++++
>> kernel/irq/irqdomain.c | 36 +++++
>> kernel/irq/msi.c | 4 +-
>> 14 files changed, 587 insertions(+), 93 deletions(-)
>>
>> --
>> 1.9.1
>
^ permalink raw reply
* [PATCH v2 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set
From: Kishon Vijay Abraham I @ 2017-01-12 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMz4ku+X8v2HH5L_fS60naNTqR1ZFKYeWuXuHqjg0UsHQq1dsQ@mail.gmail.com>
Hi,
On Thursday 12 January 2017 12:13 PM, Baolin Wang wrote:
> On 3 January 2017 at 13:54, Baolin Wang <baolin.wang@linaro.org> wrote:
>> Hi Kison and Heiko,
>>
>> On 21 December 2016 at 16:12, Baolin Wang <baolin.wang@linaro.org> wrote:
>>> According to the documentation, we should set the EXTCON_USB when
>>> one SDP charger connector was reported.
>>>
>>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>>
>> Could you apply this patch if there are no other comments? Thanks.
Does it fix something? Or else it can go in the next merge window.
Thanks
Kishon
^ permalink raw reply
* [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: John Crispin @ 2017-01-12 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3fecb422-8185-7ee0-c203-2bfdc4fd1393@phrozen.org>
Hi Andreas,
had a look last night why the ethernet dtsi was not added and it
obviously was not added as we were waiting for the clk-mt2701 to be
merged. the ethernet dtsi will have phandles pointing at the clk nodes
which did not exist at the time. same is true for the PWM code.
i sat down last night and worked out what pending patches i still have
for mt7623 and out of the ~80 required to get v4.4 working i only need
around 10 for v4.10-rc1.
i started to rebase these patches last night and will have time to test
them tomorrow or early next week. as the pwrap node alone is around 200
lines of devicetree we need to figure out a way to add this to the dts
files without duplicating it. i'll try to post a series early next week
that we can then discuss and rebase your geekboard patches on.
John
^ permalink raw reply
* [PATCH 0/4] video: ARM CLCD: add support of an optional GPIO to enable panel
From: Linus Walleij @ 2017-01-12 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <330598fa-d331-3695-b0a2-3590059e2be4@mleia.com>
On Thu, Jan 12, 2017 at 1:05 AM, Vladimir Zapolskiy <vz@mleia.com> wrote:
> On 01/11/2017 05:16 PM, Linus Walleij wrote:
>> On Tue, Jan 10, 2017 at 2:47 PM, Vladimir Murzin
>> <vladimir.murzin@arm.com> wrote:
>>
>>> In another thread Benjamin pointed at patch [1] in drm/kms part for noMMU.
>>>
>>> [1] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=62a0d98a188cc4ebd8ea54b37d274ec20465e464
>>
>> Problem solved?
>>
>> Vladimir: I do not require in any way that you create a CLCD driver for DRM,
>> I just think it would be very very nice...
>>
>
> I have no other option, this series is unreviewed and thus unlikely it will
> be applied, still a panel PCB on my board needs power management support.
Hm I can ACK it I guess, but mergeing it into an unmaintained subsystem
is another issue, just not very optimal. If you get it working on your system
I can look into migrating all the old users to DRM as well.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set
From: Baolin Wang @ 2017-01-12 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58773BC8.2050808@ti.com>
Hi,
On 12 January 2017 at 16:18, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Thursday 12 January 2017 12:13 PM, Baolin Wang wrote:
>> On 3 January 2017 at 13:54, Baolin Wang <baolin.wang@linaro.org> wrote:
>>> Hi Kison and Heiko,
>>>
>>> On 21 December 2016 at 16:12, Baolin Wang <baolin.wang@linaro.org> wrote:
>>>> According to the documentation, we should set the EXTCON_USB when
>>>> one SDP charger connector was reported.
>>>>
>>>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>
>>> Could you apply this patch if there are no other comments? Thanks.
>
> Does it fix something? Or else it can go in the next merge window.
Just fix the correct usage of EXTCON_CHG_USB_SDP connector. It's okay
for me that it can go in the next merge window. Thanks.
--
Baolin.wang
Best Regards
^ permalink raw reply
* [PATCH v5 0/4] drm/dp: Implement CRC debugfs API
From: Tomeu Vizoso @ 2017-01-12 8:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this series builds up on the API for exposing captured CRCs through
debugfs.
It adds new DP helpers for starting and stopping CRC capture and gets
the Rockchip driver to use it.
Also had to add a connector backpointer to the drm_dp_aux struct so we could
wait for the right vblank and store the CRCs afterwards, I will be glad
to hear about better alternatives.
With these patches, tests in IGT such as kms_pipe_crc_basic and
kms_plane do pass on RK3288.
In this v5, "drm/dp: add helpers for capture of frame CRCs" has gone
back to the more explicit way of just retrying once.
Also, I have left the connector back pointer in the AUX structure, as on
IRC nor danvet nor me could find a good reason to change it.
Thanks,
Tomeu
Tomeu Vizoso (4):
drm/bridge: analogix_dp: set connector to drm_dp_aux
drm/dp: add helpers for capture of frame CRCs
drm/bridge: analogix_dp: add helpers for capture of frame CRCs
drm/rockchip: Implement CRC debugfs API
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 34 ++++--
drivers/gpu/drm/drm_dp_helper.c | 124 +++++++++++++++++++++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 +++++++
include/drm/bridge/analogix_dp.h | 3 +
include/drm/drm_dp_helper.h | 7 ++
5 files changed, 202 insertions(+), 8 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v5 4/4] drm/rockchip: Implement CRC debugfs API
From: Tomeu Vizoso @ 2017-01-12 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112085844.19878-1-tomeu.vizoso@collabora.com>
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 +++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb5f001f51c3..6e5eb1aa182a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,7 @@
#include <drm/drm_crtc_helper.h>
#include <drm/drm_flip_work.h>
#include <drm/drm_plane_helper.h>
+#include <drm/bridge/analogix_dp.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -1105,6 +1106,46 @@ static void vop_crtc_destroy_state(struct drm_crtc *crtc,
kfree(s);
}
+static struct drm_connector *vop_get_edp_connector(struct vop *vop)
+{
+ struct drm_crtc *crtc = &vop->crtc;
+ struct drm_connector *connector;
+
+ mutex_lock(&crtc->dev->mode_config.mutex);
+ drm_for_each_connector(connector, crtc->dev)
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ mutex_unlock(&crtc->dev->mode_config.mutex);
+ return connector;
+ }
+ mutex_unlock(&crtc->dev->mode_config.mutex);
+
+ return NULL;
+}
+
+static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
+ const char *source_name, size_t *values_cnt)
+{
+ struct vop *vop = to_vop(crtc);
+ struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc->state);
+ struct drm_connector *connector;
+ int ret;
+
+ connector = vop_get_edp_connector(vop);
+ if (!connector)
+ return -EINVAL;
+
+ *values_cnt = 3;
+
+ if (source_name && strcmp(source_name, "auto") == 0)
+ ret = analogix_dp_start_crc(connector);
+ else if (!source_name)
+ ret = analogix_dp_stop_crc(connector);
+ else
+ ret = -EINVAL;
+
+ return ret;
+}
+
static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -1112,6 +1153,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.reset = vop_crtc_reset,
.atomic_duplicate_state = vop_crtc_duplicate_state,
.atomic_destroy_state = vop_crtc_destroy_state,
+ .set_crc_source = vop_crtc_set_crc_source,
};
static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
--
2.9.3
^ permalink raw reply related
* [PATCH v7 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Marc Zyngier @ 2017-01-12 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c33e4e9-6472-4738-aea2-55dcaab3a94f@huawei.com>
On 12/01/17 04:23, Ding Tianhong wrote:
> Hi Marc:
>
> How about this v7, if any suggestions very grateful.
It's been less than 5 days since you posted this. I'll get to it once I
finish reviewing all the other patches that are sitting in the queue
right before yours.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCHv3 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Chris Packham @ 2017-01-12 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95cb4240-e77b-5eaa-1920-4d9e26028038@gmail.com>
On 12/01/17 09:56, Sebastian Hesselbarth wrote:
> On 01/11/2017 03:44 PM, Linus Walleij wrote:
>> On Fri, Jan 6, 2017 at 5:15 AM, Chris Packham
>> <chris.packham@alliedtelesis.co.nz> wrote:
>>
>>> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>>>
>>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>>> from Marvell.
>>>
>>> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>>
>> I am waiting for an ACK or comment from the maintainers on
>> this patch. Sebastian?
>
> Sorry for the ignorance.
>
> I don't have the patch to reply to inline, but:
>
> - In the driver MPP_MODE2, spi0 there is a typo "csk" instead of "sck".
> - MPP_MODE5 binding "dev","bootcs" and driver "dev","bootcs0" differ.
> - MPP_MODE6 binding "gpio" and driver "gpo" differ.
> - MPP_MODE17 binding "dev","clk" and driver "dev","clkout" differ.
> - MPP_MODE19 binding mentiones "dev","rb" but driver does not.
> - MPP_MODE20 binding "gpio" and driver "gpo" differ.
> - MPP_MODE20 binding "dev","we" and driver "dev","we0" differ.
> - MPP_MODE21 through MPP_MODE30 binding "gpio" and driver "gpo" differ.
> - remove spaces before "0, 0" in mv98dx3236_mpp_gpio_ranges.
>
> Most of it is cosmetic stuff, so if you fix it feel free to add my
>
> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Hi Sebastian,
Hopefully I can get a v4 out with the above fixed soon.
One point on "gpio" vs "gpo" this one isn't a typo. Some of these pins
can be driven as outputs but can't be used as inputs. From a pinctrl
driver point of view there is no difference but I did want to convey
that from a system design point of view if you really need something to
be an input you shouldn't use one of these pins. This is also noted in
the datasheets so it doesn't necessarily need repeating. If you still
want me to use "gpio" in the code and binding I'm happy to do so.
^ permalink raw reply
* [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs
From: Maxime Ripard @ 2017-01-12 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
On Fri, Dec 09, 2016 at 12:04:08PM +0100, Quentin Schulz wrote:
> The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the
> VBUS power supply for both max current and min voltage supplied. This
> series of patch adds the possibility to set these limits from sysfs.
>
> Also, the AXP223 PMIC shares most of its behaviour with the AXP221 but
> the former can set the VBUS power supply max current to 100mA, unlike
> the latter. The AXP223 VBUS power supply driver used to probe on the
> AXP221 compatible. This series of patch introduces a new compatible for
> the AXP223 to be able to set the current max limit to 100mA.
>
> With that new compatible, boards having the AXP223 see their DT updated
> to use the VBUS power supply driver with the correct compatible.
>
> This series of patch also migrates from of_device_is_compatible function
> to the data field of of_device_id to identify the compatible used to
> probe. This improves the code readability.
>
> Mostly cosmetic changes in v2 and adding volatile and writeable regs to
> AXP20X and AXP22X MFD cells for the VBUS power supply driver.
Applied all the DT patches. I also fixed all the prefixes. Please make
sure to look at what prefixes are used by a given subsystem next time.
Thanks!
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170112/8fc64b9f/attachment.sig>
^ permalink raw reply
* kvm: deadlock in kvm_vgic_map_resources
From: Marc Zyngier @ 2017-01-12 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACT4Y+YRg=H0F-_QTtPf0--o85sQCb__j=V25tPchx9ycYtyKg@mail.gmail.com>
Hi Dmitry,
On 11/01/17 19:01, Dmitry Vyukov wrote:
> Hello,
>
> While running syzkaller fuzzer I've got the following deadlock.
> On commit 9c763584b7c8911106bb77af7e648bef09af9d80.
>
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 4.9.0-rc6-xc2-00056-g08372dd4b91d-dirty #50 Not tainted
> ---------------------------------------------
> syz-executor/20805 is trying to acquire lock:
> (
> &kvm->lock
> ){+.+.+.}
> , at:
> [< inline >] kvm_vgic_dist_destroy
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:271
> [<ffff2000080ea4bc>] kvm_vgic_destroy+0x34/0x250
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:294
> but task is already holding lock:
> (&kvm->lock){+.+.+.}, at:
> [<ffff2000080ea7e4>] kvm_vgic_map_resources+0x2c/0x108
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:343
> other info that might help us debug this:
> Possible unsafe locking scenario:
> CPU0
> ----
> lock(&kvm->lock);
> lock(&kvm->lock);
> *** DEADLOCK ***
> May be due to missing lock nesting notation
> 2 locks held by syz-executor/20805:
> #0:(&vcpu->mutex){+.+.+.}, at:
> [<ffff2000080bcc30>] vcpu_load+0x28/0x1d0
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:143
> #1:(&kvm->lock){+.+.+.}, at:
> [<ffff2000080ea7e4>] kvm_vgic_map_resources+0x2c/0x108
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:343
> stack backtrace:
> CPU: 2 PID: 20805 Comm: syz-executor Not tainted
> 4.9.0-rc6-xc2-00056-g08372dd4b91d-dirty #50
> Hardware name: Hardkernel ODROID-C2 (DT)
> Call trace:
> [<ffff200008090560>] dump_backtrace+0x0/0x3c8 arch/arm64/kernel/traps.c:69
> [<ffff200008090948>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:219
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffff200008895840>] dump_stack+0x100/0x150 lib/dump_stack.c:51
> [< inline >] print_deadlock_bug kernel/locking/lockdep.c:1728
> [< inline >] check_deadlock kernel/locking/lockdep.c:1772
> [< inline >] validate_chain kernel/locking/lockdep.c:2250
> [<ffff2000081c8718>] __lock_acquire+0x1938/0x3440 kernel/locking/lockdep.c:3335
> [<ffff2000081caa84>] lock_acquire+0xdc/0x1d8 kernel/locking/lockdep.c:3746
> [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
> [<ffff200009700004>] mutex_lock_nested+0xdc/0x7b8 kernel/locking/mutex.c:621
> [< inline >] kvm_vgic_dist_destroy
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:271
> [<ffff2000080ea4bc>] kvm_vgic_destroy+0x34/0x250
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:294
> [<ffff2000080ec290>] vgic_v2_map_resources+0x218/0x430
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:295
> [<ffff2000080ea884>] kvm_vgic_map_resources+0xcc/0x108
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:348
> [< inline >] kvm_vcpu_first_run_init
> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:505
> [<ffff2000080d2768>] kvm_arch_vcpu_ioctl_run+0xab8/0xce0
> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:591
> [<ffff2000080c1fec>] kvm_vcpu_ioctl+0x434/0xc08
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2557
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [<ffff200008450c38>] do_vfs_ioctl+0x128/0xfc0 fs/ioctl.c:679
> [< inline >] SYSC_ioctl fs/ioctl.c:694
> [<ffff200008451b78>] SyS_ioctl+0xa8/0xb8 fs/ioctl.c:685
> [<ffff200008083ef0>] el0_svc_naked+0x24/0x28 arch/arm64/kernel/entry.S:755
Nice catch, and many thanks for reporting this.
The bug is fairly obvious. Christoffer, what do you think? I don't think
we need to hold the kvm->lock all the way, but I'd like another pair of
eyes (the coffee machine is out of order again, and tea doesn't cut it).
Thanks,
M.
>From 93f80b20fb9351a49ee8b74eed3fc59c84651371 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Thu, 12 Jan 2017 09:21:56 +0000
Subject: [PATCH] KVM: arm/arm64: vgic: Fix deadlock on error handling
Dmitry Vyukov reported that the syzkaller fuzzer triggered a
deadlock in the vgic setup code when an error was detected, as
the cleanup code tries to take a lock that is already held by
the setup code.
The fix is pretty obvious: move the cleaup call after having
dropped the lock, since not much can happen at that point.
Cc: stable at vger.kernel.org
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-init.c | 4 ++++
virt/kvm/arm/vgic/vgic-v2.c | 2 --
virt/kvm/arm/vgic/vgic-v3.c | 2 --
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 5114391..0e0c295 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -350,6 +350,10 @@ int kvm_vgic_map_resources(struct kvm *kvm)
ret = vgic_v3_map_resources(kvm);
out:
mutex_unlock(&kvm->lock);
+
+ if (ret)
+ kvm_vgic_destroy(kvm);
+
return ret;
}
diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
index 9bab867..834137e 100644
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@ -293,8 +293,6 @@ int vgic_v2_map_resources(struct kvm *kvm)
dist->ready = true;
out:
- if (ret)
- kvm_vgic_destroy(kvm);
return ret;
}
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index 7df1b90..a4c7fff 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -308,8 +308,6 @@ int vgic_v3_map_resources(struct kvm *kvm)
dist->ready = true;
out:
- if (ret)
- kvm_vgic_destroy(kvm);
return ret;
}
--
2.1.4
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Marc Gonzalez @ 2017-01-12 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111175110.GB22289@roeck-us.net>
On 11/01/2017 18:51, Guenter Roeck wrote:
> However, some other unrelated undefined behavior does not mean that this
> specific behavior is undefined.
True :-)
Let me just give two additional examples of UB that /have/ bitten
Linux kernel devs.
int i;
for (i = 1; i > 0; ++i)
/* do_something(); */
=> optimized into an infinite loop
and
void func(struct foo *p) {
int n = p->field;
if (!p) return;
=> null-pointer check optimized away
> So far we have a claim that a cast to a void * may somehow be different
> to a cast to a different pointer, if used as function argument, and that
> the behavior with such a cast may be undefined. In other words, you claim
> that a function implemented as, say,
>
> void func(int *var) {}
>
> might result in undefined behavior if some header file declares it as
>
> void func(void *);
>
> and it is called as
>
> int var;
>
> func(&var);
>
> That seems really far fetched to me.
Thanks for giving me an opportunity to play the language lawyer :-)
C99 6.3.2.3 sub-clause 8 states:
"A pointer to a function of one type may be converted to a pointer to a function of another
type and back again; the result shall compare equal to the original pointer. If a converted
pointer is used to call a function whose type is not compatible with the pointed-to type,
the behavior is undefined."
So, the behavior is undefined, not when you cast clk_disable_unprepare,
but when clk_disable_unprepare is later called through the devres->action
function pointer.
However, I agree that it will work as expected on typical platforms
(where all pointers are the same size, and the calling convention
treats all pointers the same).
> I do get the message that you do not like this kind of cast. But that doesn't
> mean it is not correct.
If it's already widely used in the kernel, it seems there is no point
fighting it ;-)
Regards.
^ permalink raw reply
* [RFC PATCH] arm64: defconfig: enable SMMUv3 config
From: Catalin Marinas @ 2017-01-12 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5876CF7C.8080907@hisilicon.com>
On Thu, Jan 12, 2017 at 08:36:12AM +0800, Zhou Wang wrote:
> On 2017/1/9 19:50, Zhou Wang wrote:
> > Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
> > ---
> > arch/arm64/configs/defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index 869dded..3520c50 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -440,6 +440,7 @@ CONFIG_PLATFORM_MHU=y
> > CONFIG_BCM2835_MBOX=y
> > CONFIG_HI6220_MBOX=y
> > CONFIG_ARM_SMMU=y
> > +CONFIG_ARM_SMMU_V3=y
> > CONFIG_RASPBERRYPI_POWER=y
> > CONFIG_QCOM_SMEM=y
> > CONFIG_QCOM_SMD=y
>
> I just happened to find there is no SMMUv3 config in arm64 defconfig.
>
> Maybe we should add it in defconfig or I miss something.
It looks fine to me but it's usually the arm-soc guys picking the
defconfig patches.
--
Catalin
^ permalink raw reply
* [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs
From: Peter Chen @ 2017-01-12 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148418039309.32258.7247753739063801774@sboyd-linaro>
On Wed, Jan 11, 2017 at 04:19:53PM -0800, Stephen Boyd wrote:
> Quoting Peter Chen (2017-01-02 22:53:19)
> > On Wed, Dec 28, 2016 at 02:57:09PM -0800, Stephen Boyd wrote:
> > > If the phy supports it, call phy_set_mode() to pull up D+ when
> > > required by setting the mode to PHY_MODE_USB_DEVICE. If we want
> > > to remove the pullup, set the mode to PHY_MODE_USB_HOST.
> > >
> [..]
> > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > index 0d532a724d48..6d61fa0689b0 100644
> > > --- a/drivers/usb/chipidea/udc.c
> > > +++ b/drivers/usb/chipidea/udc.c
> > > @@ -1609,10 +1610,15 @@ static int ci_udc_pullup(struct usb_gadget *_gadget, int is_on)
> > > return 0;
> > >
> > > pm_runtime_get_sync(&ci->gadget.dev);
> > > - if (is_on)
> > > + if (is_on) {
> > > + if (ci->phy)
> > > + phy_set_mode(ci->phy, PHY_MODE_USB_DEVICE);
> > > hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> > > - else
> > > + } else {
> > > hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> > > + if (ci->phy)
> > > + phy_set_mode(ci->phy, PHY_MODE_USB_HOST);
> > > + }
> > > pm_runtime_put_sync(&ci->gadget.dev);
> > >
> > > return 0;
> >
> > Would you describe the use case for it? Why not adding it at
> > role switch routine?
> >
>
> This is about pulling up D+. The phy I have requires that we manually
> pull up D+ by writing a ULPI register before we set the run/stop bit.
Afaik, only controller can pull up dp when it is at device mode by
setting USBCMD_RS. At host mode, clear USBCMD_RS will only stopping
sending SoF from controller side.
I am puzzled why you can pull up D+ by writing an ULPI register, perhaps,
your phy needs DP to change before switching the mode? Would you
double confirm that?
> I
> thought it would be appropriate to do so in ci_udc_pullup(), where we're
> supposed to put that pullup code, unless I'm mistaken?
>
> It's not exactly about putting the phy into device or host mode, so
> phy_set_mode() may not actually be the best API to use. Perhaps we need
> some sort of phy_pullup_usb() API here?
--
Best Regards,
Peter Chen
^ 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