* [PATCH 1/3] arm64: hugetlb: Fix huge_pte_offset to return poisoned page table entries
From: Catalin Marinas @ 2017-05-03 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412140459.21824-2-punit.agrawal@arm.com>
On Wed, Apr 12, 2017 at 03:04:57PM +0100, Punit Agrawal wrote:
> When memory failure is enabled, a poisoned hugepage pte is marked as a
> swap entry. huge_pte_offset() does not return the poisoned page table
> entries when it encounters PUD/PMD hugepages.
>
> This behaviour of huge_pte_offset() leads to error such as below when
> munmap is called on poisoned hugepages.
>
> [ 344.165544] mm/pgtable-generic.c:33: bad pmd 000000083af00074.
>
> Fix huge_pte_offset() to return the poisoned pte which is then
> appropriately handled by the generic layer code.
>
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: David Woods <dwoods@mellanox.com>
> ---
> arch/arm64/mm/hugetlbpage.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 7514a000e361..5f1832165d69 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -143,15 +143,24 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
> pr_debug("%s: addr:0x%lx pgd:%p\n", __func__, addr, pgd);
> if (!pgd_present(*pgd))
> return NULL;
> - pud = pud_offset(pgd, addr);
> - if (!pud_present(*pud))
> - return NULL;
>
> - if (pud_huge(*pud))
> + pud = pud_offset(pgd, addr);
> + /*
> + * In case of HW Poisoning, a hugepage pud/pmd can contain
> + * poisoned entries. Poisoned entries are marked as swap
> + * entries.
> + *
> + * For puds/pmds that are not present, check to see if it
> + * could be a swap entry (!present and !none).
> + */
> + if ((!pte_present(pud_pte(*pud)) && !pud_none(*pud)) || pud_huge(*pud))
> return (pte_t *)pud;
Since we use puds as huge pages, can we just change pud_present() to
match the pmd_present()? I'd like to see similar checks for pud and pmd,
it would be easier to follow. Something like (unchecked):
if (pud_none(*pud))
return NULL;
/* swap or huge page */
if (!pud_present(*pud) || pud_huge(*pud))
return (pte_t *)pud;
/* table; check the next level */
> +
> pmd = pmd_offset(pud, addr);
> - if (!pmd_present(*pmd))
> + if (pmd_none(*pmd))
> return NULL;
> + if (!pmd_present(*pmd) && !pmd_none(*pmd))
> + return (pte_t *)pmd;
At this point, we already know that pmd_none(*pmd) is false, no ned to
check it again.
--
Catalin
^ permalink raw reply
* [PATCH v2 1/20] clk: divider: Make divider_round_rate take the parent clock
From: Chen-Yu Tsai @ 2017-05-03 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9c2f3ed66ae32e55721bfced41dfd70e49cb746c.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> So far, divider_round_rate only considers the parent clock returned by
> clk_hw_get_parent.
>
> This works fine on clocks that have a single parents, this doesn't work on
> muxes, since we will only consider the first parent, while other parents
> may totally be able to provide a better combination.
>
> Clocks in that case cannot use divider_round_rate, so would have to come up
> with a very similar logic to work around it. Instead of having to do
> something like this, and duplicate that logic everywhere, create a
> divider_round_rate parent to allow caller to give an additional parameter
> for the parent clock to consider.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/clk/clk-divider.c | 26 ++++++++++++++++++--------
> include/linux/clk-provider.h | 4 ++++
> 2 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 96386ffc8483..48750439b1cd 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -275,7 +275,8 @@ static int _next_div(const struct clk_div_table *table, int div,
> return div;
> }
>
> -static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
> +static int clk_divider_bestdiv(struct clk_hw *hw, struct clk_hw *parent,
> + unsigned long rate,
> unsigned long *best_parent_rate,
> const struct clk_div_table *table, u8 width,
> unsigned long flags)
> @@ -314,8 +315,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
> *best_parent_rate = parent_rate_saved;
> return i;
> }
> - parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw),
> - rate * i);
> + parent_rate = clk_hw_round_rate(parent, rate * i);
> now = DIV_ROUND_UP_ULL((u64)parent_rate, i);
> if (_is_best_div(rate, now, best, flags)) {
> bestdiv = i;
> @@ -326,22 +326,32 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
>
> if (!bestdiv) {
> bestdiv = _get_maxdiv(table, width, flags);
> - *best_parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw), 1);
> + *best_parent_rate = clk_hw_round_rate(parent, 1);
> }
>
> return bestdiv;
> }
>
> -long divider_round_rate(struct clk_hw *hw, unsigned long rate,
> - unsigned long *prate, const struct clk_div_table *table,
> - u8 width, unsigned long flags)
> +long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> + unsigned long rate, unsigned long *prate,
> + const struct clk_div_table *table,
> + u8 width, unsigned long flags)
> {
> int div;
>
> - div = clk_divider_bestdiv(hw, rate, prate, table, width, flags);
> + div = clk_divider_bestdiv(hw, parent, rate, prate, table, width, flags);
>
> return DIV_ROUND_UP_ULL((u64)*prate, div);
> }
> +EXPORT_SYMBOL_GPL(divider_round_rate_parent);
> +
> +long divider_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate, const struct clk_div_table *table,
> + u8 width, unsigned long flags)
> +{
> + return divider_round_rate_parent(hw, clk_hw_get_parent(hw), rate, prate,
> + table, width, flags);
> +}
> EXPORT_SYMBOL_GPL(divider_round_rate);
Could this be made a static inline instead? Otherwise,
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
>
> static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index a428aec36ace..14102f783f64 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -412,6 +412,10 @@ extern const struct clk_ops clk_divider_ro_ops;
> unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate,
> unsigned int val, const struct clk_div_table *table,
> unsigned long flags);
> +long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> + unsigned long rate, unsigned long *prate,
> + const struct clk_div_table *table,
> + u8 width, unsigned long flags);
> long divider_round_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long *prate, const struct clk_div_table *table,
> u8 width, unsigned long flags);
> --
> git-series 0.8.11
^ permalink raw reply
* [PATCH 1/3] arm64: dts: ls1046a: support SD UHS-I and eMMC HS200 on RDB
From: Shawn Guo @ 2017-05-03 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492746756-12024-2-git-send-email-yangbo.lu@nxp.com>
On Fri, Apr 21, 2017 at 11:52:34AM +0800, Yangbo Lu wrote:
> This patch is to enable SD UHS-I mode and eMMC HS200 mode on
> LS1046ARDB in dts. Also, the eSDHC peripheral clock must be used
> instead of platform clock to support these modes.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 8 ++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 4 ++--
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> index d1ccc00..08528c2 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> @@ -64,6 +64,14 @@
> };
> };
>
> +&esdhc {
> + mmc-hs200-1_8v;
> + sd-uhs-sdr104;
> + sd-uhs-sdr50;
> + sd-uhs-sdr25;
> + sd-uhs-sdr12;
> +};
> +
Please sort the node alphabetically.
> &duart0 {
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> index f4b8b7e..f06f329 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> @@ -209,10 +209,10 @@
> };
>
> esdhc: esdhc at 1560000 {
> - compatible = "fsl,esdhc";
> + compatible = "fsl,ls1046a-esdhc", "fsl,esdhc";
I do not see "fsl,ls1046a-esdhc" is a documented compatible.
Shawn
> reg = <0x0 0x1560000 0x0 0x10000>;
> interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> - clock-frequency = <0>;
> + clocks = <&clockgen 2 1>;
> voltage-ranges = <1800 1800 3300 3300>;
> sdhci,auto-cmd12;
> big-endian;
> --
> 2.1.0.27.g96db324
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] arm64: dts: ls1012a: add eSDHC nodes
From: Shawn Guo @ 2017-05-03 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492746756-12024-4-git-send-email-yangbo.lu@nxp.com>
On Fri, Apr 21, 2017 at 11:52:36AM +0800, Yangbo Lu wrote:
> There are two eSDHC controllers in LS1012A. This patch is to add
> eSDHC nodes for ls1012a dts. Also enable eSDHC for RDB/QDS boards.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 8 ++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 13 ++++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 25 +++++++++++++++++++++++
> 3 files changed, 46 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> index e2a93d5..a21a587 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> @@ -130,3 +130,11 @@
> &sata {
> status = "okay";
> };
> +
> +&esdhc0 {
> + status = "okay";
> +};
> +
> +&esdhc1 {
> + status = "okay";
> +};
Sort these labeled nodes alphabetically.
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> index ed77f6b..57669b0 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> @@ -61,3 +61,16 @@
> &sata {
> status = "okay";
> };
> +
> +&esdhc0 {
> + sd-uhs-sdr104;
> + sd-uhs-sdr50;
> + sd-uhs-sdr25;
> + sd-uhs-sdr12;
> + status = "okay";
> +};
> +
> +&esdhc1 {
> + mmc-hs200-1_8v;
> + status = "okay";
> +};
Ditto
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> index b497ac1..e3a1943 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> @@ -302,6 +302,31 @@
> };
> };
>
> + esdhc0: esdhc at 1560000 {
Sort the nodes in order of unit-address.
> + compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
Please document the compatible.
Shawn
> + reg = <0x0 0x1560000 0x0 0x10000>;
> + interrupts = <0 62 0x4>;
> + clocks = <&clockgen 4 0>;
> + voltage-ranges = <1800 1800 3300 3300>;
> + sdhci,auto-cmd12;
> + big-endian;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
> + esdhc1: esdhc at 1580000 {
> + compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
> + reg = <0x0 0x1580000 0x0 0x10000>;
> + interrupts = <0 65 0x4>;
> + clocks = <&clockgen 4 0>;
> + voltage-ranges = <1800 1800 3300 3300>;
> + sdhci,auto-cmd12;
> + big-endian;
> + broken-cd;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
> i2c0: i2c at 2180000 {
> compatible = "fsl,vf610-i2c";
> #address-cells = <1>;
> --
> 2.1.0.27.g96db324
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] kvm: Fix mmu_notifier release race
From: Suzuki K Poulose @ 2017-05-03 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <611d0ad2-f907-d41c-cdc1-5977c247b104@arm.com>
On 28/04/17 18:20, Suzuki K Poulose wrote:
> On 26/04/17 17:03, Suzuki K Poulose wrote:
>> On 25/04/17 19:49, Radim Kr?m?? wrote:
>>> 2017-04-24 11:10+0100, Suzuki K Poulose:
>>>> The KVM uses mmu_notifier (wherever available) to keep track
>>>> of the changes to the mm of the guest. The guest shadow page
>>>> tables are released when the VM exits via mmu_notifier->ops.release().
>>>> There is a rare chance that the mmu_notifier->release could be
>>>> called more than once via two different paths, which could end
>>>> up in use-after-free of kvm instance (such as [0]).
>>>>
>>>> e.g:
>>>>
>>>> thread A thread B
>>>> ------- --------------
>>>>
>>>> get_signal-> kvm_destroy_vm()->
>>>> do_exit-> mmu_notifier_unregister->
>>>> exit_mm-> kvm_arch_flush_shadow_all()->
>>>> exit_mmap-> spin_lock(&kvm->mmu_lock)
>>>> mmu_notifier_release-> ....
>>>> kvm_arch_flush_shadow_all()-> .....
>>>> ... spin_lock(&kvm->mmu_lock) .....
>>>> spin_unlock(&kvm->mmu_lock)
>>>> kvm_arch_free_kvm()
>>>> *** use after free of kvm ***
>>>
>>> I don't understand this race ...
>>> a piece of code in mmu_notifier_unregister() says:
>>>
>>> /*
>>> * Wait for any running method to finish, of course including
>>> * ->release if it was run by mmu_notifier_release instead of us.
>>> */
>>> synchronize_srcu(&srcu);
>>>
>>> and code before that removes the notifier from the list, so it cannot be
>>> called after we pass this point. mmu_notifier_release() does roughly
>>> the same and explains it as:
>>>
>>> /*
>>> * synchronize_srcu here prevents mmu_notifier_release from returning to
>>> * exit_mmap (which would proceed with freeing all pages in the mm)
>>> * until the ->release method returns, if it was invoked by
>>> * mmu_notifier_unregister.
>>> *
>>> * The mmu_notifier_mm can't go away from under us because one mm_count
>>> * is held by exit_mmap.
>>> */
>>> synchronize_srcu(&srcu);
>>>
>>> The call of mmu_notifier->release is protected by srcu in both cases and
>>> while it seems possible that mmu_notifier->release would be called
>>> twice, I don't see a combination that could result in use-after-free
>>> from mmu_notifier_release after mmu_notifier_unregister() has returned.
>>
>> Thanks for bringing it up. Even I am wondering why this is triggered ! (But it
>> does get triggered for sure !!)
>>
>> The only difference I can spot with _unregister & _release paths are the way
>> we use src_read_lock across the deletion of the entry from the list.
>>
>> In mmu_notifier_unregister() we do :
>>
>> id = srcu_read_lock(&srcu);
>> /*
>> * exit_mmap will block in mmu_notifier_release to guarantee
>> * that ->release is called before freeing the pages.
>> */
>> if (mn->ops->release)
>> mn->ops->release(mn, mm);
>> srcu_read_unlock(&srcu, id);
>>
>> ## Releases the srcu lock here and then goes on to grab the spin_lock.
>>
>> spin_lock(&mm->mmu_notifier_mm->lock);
>> /*
>> * Can not use list_del_rcu() since __mmu_notifier_release
>> * can delete it before we hold the lock.
>> */
>> hlist_del_init_rcu(&mn->hlist);
>> spin_unlock(&mm->mmu_notifier_mm->lock);
>>
>> While in mmu_notifier_release() we hold it until the node(s) are deleted from the
>> list :
>> /*
>> * SRCU here will block mmu_notifier_unregister until
>> * ->release returns.
>> */
>> id = srcu_read_lock(&srcu);
>> hlist_for_each_entry_rcu(mn, &mm->mmu_notifier_mm->list, hlist)
>> /*
>> * If ->release runs before mmu_notifier_unregister it must be
>> * handled, as it's the only way for the driver to flush all
>> * existing sptes and stop the driver from establishing any more
>> * sptes before all the pages in the mm are freed.
>> */
>> if (mn->ops->release)
>> mn->ops->release(mn, mm);
>>
>> spin_lock(&mm->mmu_notifier_mm->lock);
>> while (unlikely(!hlist_empty(&mm->mmu_notifier_mm->list))) {
>> mn = hlist_entry(mm->mmu_notifier_mm->list.first,
>> struct mmu_notifier,
>> hlist);
>> /*
>> * We arrived before mmu_notifier_unregister so
>> * mmu_notifier_unregister will do nothing other than to wait
>> * for ->release to finish and for mmu_notifier_unregister to
>> * return.
>> */
>> hlist_del_init_rcu(&mn->hlist);
>> }
>> spin_unlock(&mm->mmu_notifier_mm->lock);
>> srcu_read_unlock(&srcu, id);
>>
>> ## The lock is release only after the deletion of the node.
>>
>> Both are followed by a synchronize_srcu(). Now, I am wondering if the unregister path
>> could potentially miss SRCU read lock held in _release() path and go onto finish the
>> synchronize_srcu before the item is deleted ? May be we should do the read_unlock
>> after the deletion of the node in _unregister (like we do in the _release()) ?
>
> I haven't been able to reproduce the mmu_notifier race condition, which leads to KVM
> free, reported at [1]. I will leave it running (with tracepoints/ftrace) over the
> weekend.
>
I couldn't reproduce the proposed "mmu_notifier race" reported in [0].
However I found some other use-after-free cases in the unmap_stage2_range()
code due to the introduction of cond_resched_lock(). It may be just that the
IP reported in [0] was for wrong line of code ? i.e, arch_spin_is_locked instead
of unmap_stage2_range ?
Anyways, I will send a new version of the patches in a separate series.
[0] https://marc.info/?l=linux-kernel&m=149201399018791&w=2
Suzuki
^ permalink raw reply
* [PATCH 0/3] Add eSDHC UHS-I/HS200 mode support for ls1012a/ls1046a/ls208xa
From: Shawn Guo @ 2017-05-03 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492746756-12024-1-git-send-email-yangbo.lu@nxp.com>
On Fri, Apr 21, 2017 at 11:52:33AM +0800, Yangbo Lu wrote:
> This patch is to add eSDHC UHS-I/HS200 mode support for ls1012a/ls1046a/ls208xa.
> Because eSDHC is not a standard SD controller, the specific speed mode support
> depends on board's peripheral circuit for eSDHC. So, we have to add these speed
> modes support on board dts file.
>
> In additon, these dts patches depends on esdhc driver patches which just had been merged
> on mmc.git. Otherwise, the UHS-I SD card and eMMC HS200 card would fail to be initialized,
> but other cards still could work fine.
So it sounds like just a new feature development which doesn't cause any
regression, even if driver and dts changes are merged independently.
For such case, we can just merge patches in their natural path
separately.
Shawn
^ permalink raw reply
* [PATCH 0/3] Add eSDHC UHS-I/HS200 mode support for ls1012a/ls1046a/ls208xa
From: Shawn Guo @ 2017-05-03 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR0401MB253641C6AB25737F9F57EE8DF81E0@DB6PR0401MB2536.eurprd04.prod.outlook.com>
On Tue, Apr 25, 2017 at 09:01:28AM +0000, Y.B. Lu wrote:
> > By curiosity I tried applying these to my mmc tree, but they don't apply.
> > So I can pick them, even with acks.
> > Also it's too difficult for me to host an immutable branch with the
> > relevant sdhci-esdc changes, because of additional sdhci dependencies.
> >
> > Perhaps just easier to pick this for 4.13 or 4.12 rc2.
>
> [Lu Yangbo-B47093] Hi Uffe, I agree.
> These patches are based on Shawn's tree which has the latest layerscape board dts.
> Actually I'm not sure which git tree I should send these patches to according to MAINTAINERS, but I saw Shawn had merged some layerscape board dts before.
>
> Hi Shawn,
> Am I right to send these patches to you for reviewing? Which git tree do you recommend I should send these patches to?
Yes, currently arm64 freescale dts patches flows to mainline as below.
my imx/dt64 branch --> arm-soc tree --> mainline
Shawn
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Poll for CMDQ drain completion more effectively
From: Sunil Kovvuri @ 2017-05-03 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493291587-23488-1-git-send-email-sunil.kovvuri@gmail.com>
On Thu, Apr 27, 2017 at 4:43 PM, <sunil.kovvuri@gmail.com> wrote:
> From: Sunil Goutham <sgoutham@cavium.com>
>
> Modified polling on CMDQ consumer similar to how polling is done for TLB SYNC
> completion in SMMUv2 driver. Code changes are done with reference to
>
> 8513c8930069 iommu/arm-smmu: Poll for TLB sync completion more effectively
>
> Poll timeout has been increased which addresses issue of 100us timeout not
> sufficient, when command queue is full with TLB invalidation commands.
>
> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
> Signed-off-by: Geetha <gakula@cavium.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index d412bdd..34599d4 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -379,6 +379,9 @@
> #define CMDQ_SYNC_0_CS_NONE (0UL << CMDQ_SYNC_0_CS_SHIFT)
> #define CMDQ_SYNC_0_CS_SEV (2UL << CMDQ_SYNC_0_CS_SHIFT)
>
> +#define CMDQ_DRAIN_TIMEOUT_US 1000
> +#define CMDQ_SPIN_COUNT 10
> +
> /* Event queue */
> #define EVTQ_ENT_DWORDS 4
> #define EVTQ_MAX_SZ_SHIFT 7
> @@ -737,7 +740,8 @@ static void queue_inc_prod(struct arm_smmu_queue *q)
> */
> static int queue_poll_cons(struct arm_smmu_queue *q, bool drain, bool wfe)
> {
> - ktime_t timeout = ktime_add_us(ktime_get(), ARM_SMMU_POLL_TIMEOUT_US);
> + ktime_t timeout = ktime_add_us(ktime_get(), CMDQ_DRAIN_TIMEOUT_US);
> + unsigned int spin_cnt, delay = 1;
>
> while (queue_sync_cons(q), (drain ? !queue_empty(q) : queue_full(q))) {
> if (ktime_compare(ktime_get(), timeout) > 0)
> @@ -746,8 +750,13 @@ static int queue_poll_cons(struct arm_smmu_queue *q, bool drain, bool wfe)
> if (wfe) {
> wfe();
> } else {
> - cpu_relax();
> - udelay(1);
> + for (spin_cnt = 0;
> + spin_cnt < CMDQ_SPIN_COUNT; spin_cnt++) {
> + cpu_relax();
> + continue;
> + }
> + udelay(delay);
> + delay *= 2;
> }
> }
>
> --
> 2.7.4
>
Sorry for the ignorance.
Is there a patchwork where I can check current status of ARM IOMMU
related patches ?
And is this patch accepted, if not any comments / feedback ?
Thanks,
Sunil.
^ permalink raw reply
* [PATCH v2 0/5] mtd: nand: gpmi: add i.MX 7 support
From: Shawn Guo @ 2017-05-03 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170422012338.4635-1-stefan@agner.ch>
On Fri, Apr 21, 2017 at 06:23:33PM -0700, Stefan Agner wrote:
> This patchset adds support for i.MX 7 SoC for the GPMI NAND controller.
> There have been similar patchsets already:
> https://lkml.org/lkml/2016/2/23/912
>
> However, this patchset does not make use of any of the new features.
> The current feature set seems to work fine, I successfully run the MTD
> tests on a Colibri iMX7.
>
> --
> Stefan
>
> Changes since v1:
> - Make clks_count const
> - Introduce IS_IMX7D for i.MX 7 SoC's and make it part of GPMI_IS_MX6
>
> Stefan Agner (5):
> mtd: nand: gpmi: unify clock handling
> mtd: nand: gpmi: add i.MX 7 SoC support
> mtd: gpmi: document current clock requirements
> ARM: dts: imx7: add GPMI NAND
> ARM: dts: imx7-colibri: add NAND support
The dts patches look good to me. I will pick them up once the driver
changes are accepted.
Shawn
>
> .../devicetree/bindings/mtd/gpmi-nand.txt | 14 +++++-
> arch/arm/boot/dts/imx7-colibri.dtsi | 9 ++++
> arch/arm/boot/dts/imx7s.dtsi | 31 ++++++++++++
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 56 +++++++++++++---------
> drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 9 +++-
> 5 files changed, 93 insertions(+), 26 deletions(-)
>
> --
> 2.12.2
>
^ permalink raw reply
* [PATCH] [RFC] ARM: dts: imx6sx-sdb: Drop OPP hackery
From: Leonard Crestez @ 2017-05-03 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493149194.20997.3.camel@nxp.com>
On Tue, 2017-04-25 at 22:39 +0300, Leonard Crestez wrote:
> On Tue, 2017-04-25 at 21:30 +0200, Marek Vasut wrote:
> >
> > On 04/25/2017 06:42 PM, Marek Vasut wrote:
> > >
> > > The imx6sx-sdb has one power supply that drives both VDDARM_IN
> > > and VDDSOC_IN, which is the sw1a regulator on the PFUZE PMIC.
> > > Connect both inputs to the sw1a regulator on the PMIC and drop
> > > the OPP hackery which is no longer needed as the power framework
> > > will take care of the regulator configuration as needed.
> > >
> > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > > Cc: Shawn Guo <shawnguo@kernel.org>
> > +CC Leonard
> Tested-by: Leonard Crestez <leonard.crestez@nxp.com>
>
> The OPP hack only applies to LDO bypass mode and that is not in
> upstream. When LDOs are enabled the effect is to use higher voltages
> than necessary for no good reason.
>
> Setting these higher voltages can make some boards (for example Rev B)
> fail to boot with ugly semi-random crashes reminiscent of memory
> corruption. These failures happen the first time the lowest idle state
> is used. This patch fixes those crashes.
>
> It's not clear exactly why the crashes happen. Perhaps waking up from
> idle draws more power than is available? I don't think it matters.
>
> I sent a very similar patch a few minutes after this one:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/503241
> .html
Adding Henri Roosen because he reported something very similar.
Henri: Can you please check if this patch fixes your issue?
--?
Regards,
Leonard
^ permalink raw reply
* [PATCH v5 16/22] KVM: arm64: vgic-its: Add infrastructure for table lookup
From: Auger Eric @ 2017-05-03 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170430193325.GA1670@lvm>
Hi Christoffer,
On 30/04/2017 21:33, Christoffer Dall wrote:
> On Fri, Apr 14, 2017 at 12:15:28PM +0200, Eric Auger wrote:
>> Add a generic lookup_table() helper whose role consists in
>> scanning a contiguous table located in guest RAM and applying
>> a callback on each entry. Entries can be handled as linked lists
>> since the callback may return an offset to the next entry and
>> also tell that an entry is the last one.
>>
>> Helper functions also are added to compute the device/event ID
>> offset to the next DTE/ITE.
>>
>> compute_next_devid_offset, compute_next_eventid_offset and
>> lookup_table will become static in subsequent patches
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> v4 -> v5:
>> - use kvm_read_guest
>>
>> v3 -> v4:
>> - remove static to avoid compilation warning
>> - correct size computation in looup_table()
>> - defines now encode the number of bits used for devid and eventid offsets
>> - use BIT() - 1 to encode the max offets
>> ---
>> virt/kvm/arm/vgic/vgic-its.c | 93 ++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 93 insertions(+)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
>> index 56c5123..c22b35d 100644
>> --- a/virt/kvm/arm/vgic/vgic-its.c
>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>> @@ -195,6 +195,8 @@ static struct its_ite *find_ite(struct vgic_its *its, u32 device_id,
>>
>> #define VITS_TYPER_IDBITS 16
>> #define VITS_TYPER_DEVBITS 16
>> +#define VITS_DTE_MAX_DEVID_OFFSET (BIT(14) - 1)
>> +#define VITS_ITE_MAX_EVENTID_OFFSET (BIT(16) - 1)
>>
>> /*
>> * Finds and returns a collection in the ITS collection table.
>> @@ -1674,6 +1676,97 @@ int vgic_its_attr_regs_access(struct kvm_device *dev,
>> return ret;
>> }
>>
>> +u32 compute_next_devid_offset(struct list_head *h, struct its_device *dev)
>> +{
>> + struct list_head *e = &dev->dev_list;
>> + struct its_device *next;
>> + u32 next_offset;
>> +
>> + if (e->next == h)
>> + return 0;
>> + next = list_entry(e->next, struct its_device, dev_list);
>> + next_offset = next->device_id - dev->device_id;
>> +
>> + return min_t(u32, next_offset, VITS_DTE_MAX_DEVID_OFFSET);
>> +}
>> +
>> +u32 compute_next_eventid_offset(struct list_head *h, struct its_ite *ite)
>> +{
>> + struct list_head *e = &ite->ite_list;
>> + struct its_ite *next;
>> + u32 next_offset;
>> +
>> + if (e->next == h)
>> + return 0;
>> + next = list_entry(e->next, struct its_ite, ite_list);
>> + next_offset = next->event_id - ite->event_id;
>> +
>> + return min_t(u32, next_offset, VITS_ITE_MAX_EVENTID_OFFSET);
>> +}
>> +
>> +/**
>> + * entry_fn_t - Callback called on a table entry restore path
>> + * @its: its handle
>> + * @id: id of the entry
>> + * @entry: pointer to the entry
>> + * @opaque: pointer to an opaque data
>> + * @next_offset: minimal ID offset to the next entry. 0 if this
>> + * entry is the last one, 1 if the entry is invalid, >= 1 if an
>> + * entry's next_offset field was truly decoded
>> + *
>> + * Return: < 0 on error, 0 otherwise
>> + */
>> +typedef int (*entry_fn_t)(struct vgic_its *its, u32 id, void *entry,
>> + void *opaque, u32 *next_offset);
>
> Just noticed. All the table entries are 64-bit long at this point,
> right? So why not make entry a u64 * instead? Could we end up with
> some endianness mess with using void pointers the way it is now?
the size of the entry is ABI dependent while this infrastructure is
generic. In each of such function we use
u64 entry = *(u64 *)addr;
and we do a le64_to_cpu(entry).
Do you see something wrong? Otherwise I would be tempted to leave as is.
Thanks
Eric
>
> Thanks,
> -Christoffer
>
>> +
>> +/**
>> + * lookup_table - scan a contiguous table in guest RAM and applies a function
>> + * to each entry
>> + *
>> + * @its: its handle
>> + * @base: base gpa of the table
>> + * @size: size of the table in bytes
>> + * @esz: entry size in bytes
>> + * @start_id: first entry's ID
>> + * @fn: function to apply on each entry
>> + *
>> + * Return: < 0 on error, 1 if last element identified, 0 otherwise
>> + */
>> +int lookup_table(struct vgic_its *its, gpa_t base, int size, int esz,
>> + int start_id, entry_fn_t fn, void *opaque)
>> +{
>> + void *entry = kzalloc(esz, GFP_KERNEL);
>> + struct kvm *kvm = its->dev->kvm;
>> + unsigned long len = size;
>> + u32 id = start_id;
>> + gpa_t gpa = base;
>> + int ret;
>> +
>> + while (len > 0) {
>> + u32 next_offset;
>> + size_t byte_offset;
>> +
>> + ret = kvm_read_guest(kvm, gpa, entry, esz);
>> + if (ret)
>> + goto out;
>> +
>> + ret = fn(its, id, entry, opaque, &next_offset);
>> + if (ret < 0 || (!ret && !next_offset))
>> + goto out;
>> +
>> + byte_offset = next_offset * esz;
>> + id += next_offset;
>> + gpa += byte_offset;
>> + len -= byte_offset;
>> + }
>> + kfree(entry);
>> + return 0;
>> +
>> +out:
>> + kfree(entry);
>> + return (ret < 0 ? ret : 1);
>> +}
>> +
>> /**
>> * vgic_its_save_device_tables - Save the device table and all ITT
>> * into guest RAM
>> --
>> 2.5.5
>>
^ permalink raw reply
* [PATCH V5 7/7] ARM: ZTE: Use - instead of @ for DT OPP entries
From: Shawn Guo @ 2017-05-03 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5534c08d8b452c8ce623d3e465603d94afd82ed4.1492685450.git.viresh.kumar@linaro.org>
On Thu, Apr 20, 2017 at 04:25:11PM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
Changed the subject prefix to 'arm64: dts: zte: ', and applied the
patch.
Shawn
^ permalink raw reply
* [PATCH 0/2] ASoC: sunxi: Add ADC support for A33
From: Mylène Josserand @ 2017-05-03 13:56 UTC (permalink / raw)
To: linux-arm-kernel
Hello everyone,
This is a first version of a serie to add ADC support
for Sun8i-A33.
Based on asoc/for-next branch, last commit:
20d5c84bef067b7e804a163e2abca16c47125bad.
The first patch adds the support of ADC and microphones in the digital
part (driver sun8i-codec).
The second one adds the route between analog (sun8i-codec-analog) and
digital (sun8i-codec) parts to have a functional ADC route on Sun8i-A33
device tree.
Tested on Allwinner R16 Parrot board with microphone 1 (external) and
microphone 2 (headset).
I am not sure about the bias handling so if you have any comments on it,
do not hesitate.
Thank you in advance!
Best regards,
Myl?ne Josserand (2):
ASoC: sun8i-codec: Add ADC support for a33
ARM: dts: sun8i: Add ADC routing
arch/arm/boot/dts/sun8i-a33.dtsi | 10 ++++-
sound/soc/sunxi/sun8i-codec.c | 80 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 87 insertions(+), 3 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/2] ASoC: sun8i-codec: Add ADC support for a33
From: Mylène Josserand @ 2017-05-03 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503135617.25193-1-mylene.josserand@free-electrons.com>
Add ADC support for the sun8i-codec driver.
This driver uses all the microphones widgets and routes provided by the
analog part (sun8i-codec-analog).
Some digital configurations are needed by creating new ADC widgets
and routes.
Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
---
sound/soc/sunxi/sun8i-codec.c | 80 +++++++++++++++++++++++++++++++++++++++++--
1 file changed, 78 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index 5723c3404f6b..b4938b06acec 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -37,9 +37,11 @@
#define SUN8I_SYSCLK_CTL_SYSCLK_SRC 0
#define SUN8I_MOD_CLK_ENA 0x010
#define SUN8I_MOD_CLK_ENA_AIF1 15
+#define SUN8I_MOD_CLK_ENA_ADC 3
#define SUN8I_MOD_CLK_ENA_DAC 2
#define SUN8I_MOD_RST_CTL 0x014
#define SUN8I_MOD_RST_CTL_AIF1 15
+#define SUN8I_MOD_RST_CTL_ADC 3
#define SUN8I_MOD_RST_CTL_DAC 2
#define SUN8I_SYS_SR_CTRL 0x018
#define SUN8I_SYS_SR_CTRL_AIF1_FS 12
@@ -54,9 +56,25 @@
#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ 4
#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16 (1 << 4)
#define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT 2
+#define SUN8I_AIF1_ADCDAT_CTRL 0x044
+#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA 15
+#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA 14
#define SUN8I_AIF1_DACDAT_CTRL 0x048
#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA 15
#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA 14
+#define SUN8I_AIF1_MXR_SRC 0x04c
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L 15
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL 14
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL 13
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR 12
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R 11
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR 10
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR 9
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL 8
+#define SUN8I_ADC_DIG_CTRL 0x100
+#define SUN8I_ADC_DIG_CTRL_ENDA 15
+#define SUN8I_ADC_DIG_CTRL_ADOUT_DTS 2
+#define SUN8I_ADC_DIG_CTRL_ADOUT_DLY 1
#define SUN8I_DAC_DIG_CTRL 0x120
#define SUN8I_DAC_DIG_CTRL_ENDA 15
#define SUN8I_DAC_MXR_SRC 0x130
@@ -276,10 +294,28 @@ static const struct snd_kcontrol_new sun8i_dac_mixer_controls[] = {
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
};
+static const struct snd_kcontrol_new sun8i_input_mixer_controls[] = {
+ SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital ADC Capture Switch",
+ SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R, 1, 0),
+ SOC_DAPM_DOUBLE("AIF2 Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR, 1, 0),
+ SOC_DAPM_DOUBLE("AIF1 Data Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR, 1, 0),
+ SOC_DAPM_DOUBLE("AIF2 Inv Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL, 1, 0),
+};
+
static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
- /* Digital parts of the DACs */
+ /* Digital parts of the DACs and ADC */
SND_SOC_DAPM_SUPPLY("DAC", SUN8I_DAC_DIG_CTRL, SUN8I_DAC_DIG_CTRL_ENDA,
0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("ADC", SUN8I_ADC_DIG_CTRL, SUN8I_ADC_DIG_CTRL_ENDA,
+ 0, NULL, 0),
/* Analog DAC AIF */
SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left", "Playback", 0,
@@ -289,17 +325,31 @@ static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
SUN8I_AIF1_DACDAT_CTRL,
SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),
- /* DAC Mixers */
+ /* Analog ADC AIF */
+ SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left ADC", "Capture", 0,
+ SUN8I_AIF1_ADCDAT_CTRL,
+ SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA, 0),
+ SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Right ADC", "Capture", 0,
+ SUN8I_AIF1_ADCDAT_CTRL,
+ SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA, 0),
+
+ /* DAC and ADC Mixers */
SOC_MIXER_ARRAY("Left Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
sun8i_dac_mixer_controls),
SOC_MIXER_ARRAY("Right Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
sun8i_dac_mixer_controls),
+ SOC_MIXER_ARRAY("Left Digital ADC Mixer", SND_SOC_NOPM, 0, 0,
+ sun8i_input_mixer_controls),
+ SOC_MIXER_ARRAY("Right Digital ADC Mixer", SND_SOC_NOPM, 0, 0,
+ sun8i_input_mixer_controls),
/* Clocks */
SND_SOC_DAPM_SUPPLY("MODCLK AFI1", SUN8I_MOD_CLK_ENA,
SUN8I_MOD_CLK_ENA_AIF1, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("MODCLK DAC", SUN8I_MOD_CLK_ENA,
SUN8I_MOD_CLK_ENA_DAC, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("MODCLK ADC", SUN8I_MOD_CLK_ENA,
+ SUN8I_MOD_CLK_ENA_ADC, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("AIF1", SUN8I_SYSCLK_CTL,
SUN8I_SYSCLK_CTL_AIF1CLK_ENA, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("SYSCLK", SUN8I_SYSCLK_CTL,
@@ -316,6 +366,12 @@ static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
SUN8I_MOD_RST_CTL_AIF1, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("RST DAC", SUN8I_MOD_RST_CTL,
SUN8I_MOD_RST_CTL_DAC, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("RST ADC", SUN8I_MOD_RST_CTL,
+ SUN8I_MOD_RST_CTL_ADC, 0, NULL, 0),
+
+ SND_SOC_DAPM_MIC("Headset Mic", NULL),
+ SND_SOC_DAPM_MIC("Mic", NULL),
+
};
static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
@@ -325,11 +381,16 @@ static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
{ "RST AIF1", NULL, "AIF1 PLL" },
{ "MODCLK AFI1", NULL, "RST AIF1" },
{ "DAC", NULL, "MODCLK AFI1" },
+ { "ADC", NULL, "MODCLK AFI1" },
{ "RST DAC", NULL, "SYSCLK" },
{ "MODCLK DAC", NULL, "RST DAC" },
{ "DAC", NULL, "MODCLK DAC" },
+ { "RST ADC", NULL, "SYSCLK" },
+ { "MODCLK ADC", NULL, "RST ADC" },
+ { "ADC", NULL, "MODCLK ADC" },
+
/* DAC Routes */
{ "AIF1 Slot 0 Right", NULL, "DAC" },
{ "AIF1 Slot 0 Left", NULL, "DAC" },
@@ -339,6 +400,12 @@ static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
"AIF1 Slot 0 Left"},
{ "Right Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch",
"AIF1 Slot 0 Right"},
+
+ /* ADC routes */
+ { "Left Digital ADC Mixer", "AIF1 Data Digital ADC Capture Switch",
+ "AIF1 Slot 0 Left ADC" },
+ { "Right Digital ADC Mixer", "AIF1 Data Digital ADC Capture Switch",
+ "AIF1 Slot 0 Right ADC" },
};
static struct snd_soc_dai_ops sun8i_codec_dai_ops = {
@@ -356,6 +423,15 @@ static struct snd_soc_dai_driver sun8i_codec_dai = {
.rates = SNDRV_PCM_RATE_8000_192000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
+ /* capture capabilities */
+ .capture = {
+ .stream_name = "Capture",
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = SNDRV_PCM_RATE_8000_192000,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ .sig_bits = 24,
+ },
/* pcm operations */
.ops = &sun8i_codec_dai_ops,
};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: sun8i: Add ADC routing
From: Mylène Josserand @ 2017-05-03 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503135617.25193-1-mylene.josserand@free-electrons.com>
Add the ADC route between the analog and the digital parts
of sun8i A33. Configure the MIC1 to use MBIAS and MIC2 to use HBIAS.
Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
---
arch/arm/boot/dts/sun8i-a33.dtsi | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 306af6cadf26..0d3f7b5a23ef 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -114,7 +114,15 @@
simple-audio-card,aux-devs = <&codec_analog>;
simple-audio-card,routing =
"Left DAC", "AIF1 Slot 0 Left",
- "Right DAC", "AIF1 Slot 0 Right";
+ "Right DAC", "AIF1 Slot 0 Right",
+ "AIF1 Slot 0 Left ADC", "Left ADC",
+ "AIF1 Slot 0 Right ADC", "Right ADC",
+ "Left ADC", "ADC",
+ "Right ADC", "ADC",
+ "Mic", "MBIAS",
+ "Headset Mic", "HBIAS",
+ "MIC1", "Mic",
+ "MIC2", "Headset Mic";
status = "disabled";
simple-audio-card,cpu {
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override
From: Shawn Guo @ 2017-05-03 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f3bbd20c-2132-1121-1044-ba00dba302d6@denx.de>
On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
> On 04/25/2017 07:23 PM, Leonard Crestez wrote:
> > Anyway, that version also sets the supply for reg_arm and reg_soc. It
> > is not necessary for fixing the crash I'm seeing but is good because it
> > will result in the minimum voltage on VDD_ARM_SOC_IN rather than a fix
> > 1375mv. I tested Marek's patch and it works fine on my rev B board
> > (which otherwise fails to boot upstream).
>
> Oh that's nice , thanks ! I don't have SDB and I hacked it up after a
> brief discussion with Fabio without even compile-testing it, thus RFC.
> Glad to hear it works and thanks for testing it ! Can you add a formal
> Tested-by please ?
Hi Marek,
Thanks for your patch. But I prefer Leonard's version because: 1) it
has a better commit log; 2) it sticks to one-patch-does-one-thing
policy.
But I'm going to wait for a while to get Peter's comment discussed,
before I actually apply Leonard's patch.
Shawn
^ permalink raw reply
* [PATCH 1/1] ARM: dts: dra7: Reduce cpu thermal shutdown temperature
From: Ravikumar @ 2017-05-03 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412062442.17736-1-rk@ti.com>
Hi,
On Wednesday 12 April 2017 11:54 AM, Kattekola, Ravikumar wrote:
> On dra7, as per TRM, the HW shutdown (TSHUT) temperature is hardcoded
> to 123C and cannot be modified by SW. This means when the temperature
> reaches 123C HW asserts TSHUT output which signals a warm reset.
> This reset is held until the temperature goes below the TSHUT low (105C).
>
> While in SW, the thermal driver continuously monitors current temperature
> and takes decisions based on whether it reached an alert or a critical point.
> The intention of setting a SW critical point is to prevent force reset by HW
> and instead do an orderly_poweroff(). But if the SW critical temperature is
> greater than or equal to that of HW then it defeats the purpose. To address
> this and let SW take action before HW does keep the SW critical temperature
> less than HW TSHUT value.
>
> The value for SW critical temperature was chosen as 120C just to ensure
> we give SW sometime before HW catches up.
>
> Document reference
> SPRUI30C ? DRA75x, DRA74x Technical Reference Manual - November 2016
> SPRUHZ6H - AM572x Technical Reference Manual - November 2016
>
> Tested on:
> DRA75x PG 2.0 Rev H EVM
>
> Signed-off-by: Ravikumar Kattekola <rk@ti.com>
> ---
> arch/arm/boot/dts/dra7.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 57892f2..e714466 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -2017,4 +2017,8 @@
> coefficients = <0 2000>;
> };
>
> +&cpu_crit {
> + temperature = <120000>; /* milli Celsius */
> +};
> +
> /include/ "dra7xx-clocks.dtsi"
Ping..
Any comments?
Regards,
RK
^ permalink raw reply
* [PATCH] arm64: dts: ls1088a: add esdhc node
From: Shawn Guo @ 2017-05-03 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493271110-6361-1-git-send-email-yangbo.lu@nxp.com>
On Thu, Apr 27, 2017 at 01:31:50PM +0800, Yangbo Lu wrote:
> Add esdhc node for ls1088a and enable it on both RDB and QDS boards.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
It seems that the comments I put on '[PATCH 3/3] arm64: dts: ls1012a:
add eSDHC nodes' applies to this one as well.
Shawn
^ permalink raw reply
* [PATCH 0/2] ASoC: sunxi: Add ADC support for A33
From: Mylene Josserand @ 2017-05-03 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503135617.25193-1-mylene.josserand@free-electrons.com>
Hello,
On 03/05/2017 15:56, Myl?ne Josserand wrote:
> Hello everyone,
>
> This is a first version of a serie to add ADC support
> for Sun8i-A33.
> Based on asoc/for-next branch, last commit:
> 20d5c84bef067b7e804a163e2abca16c47125bad.
>
> The first patch adds the support of ADC and microphones in the digital
> part (driver sun8i-codec).
> The second one adds the route between analog (sun8i-codec-analog) and
> digital (sun8i-codec) parts to have a functional ADC route on Sun8i-A33
> device tree.
>
> Tested on Allwinner R16 Parrot board with microphone 1 (external) and
> microphone 2 (headset).
I forgot to add in my cover-letter amixer commands used to test it:
amixer set 'AIF1 Data Digital ADC' cap
amixer set 'Mic1' cap
or
amixer set 'Mic2' cap
and, just in case, the commands to enable output/DAC:
amixer set 'Headphone' 50%
amixer set 'Headphone' on
amixer set 'DAC' on
amixer set 'AIF1 Slot 0 Digital DAC' on
> I am not sure about the bias handling so if you have any comments on it,
> do not hesitate.
>
> Thank you in advance!
>
> Best regards,
>
> Myl?ne Josserand (2):
> ASoC: sun8i-codec: Add ADC support for a33
> ARM: dts: sun8i: Add ADC routing
>
> arch/arm/boot/dts/sun8i-a33.dtsi | 10 ++++-
> sound/soc/sunxi/sun8i-codec.c | 80 +++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 87 insertions(+), 3 deletions(-)
>
Best regards,
--
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 2/3] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver
From: Antoine Tenart @ 2017-05-03 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6ed16e7e-7f7a-795f-ee82-d2d97c3a5540@arm.com>
Hi Robin,
On Wed, May 03, 2017 at 12:57:25PM +0100, Robin Murphy wrote:
> On 24/04/17 08:54, Antoine Tenart wrote:
> > +
> > +#include <asm/dma-mapping.h>
>
> <linux/dma-mapping.h> everywhere, please.
>
> Other than that, the DMA aspects all look much nicer now, thanks.
I'll update and resend a series when the next -rc1 is out.
Thanks!
Antoine
--
Antoine T?nart, 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/20170503/f1c7a8bc/attachment.sig>
^ permalink raw reply
* [PATCH v5 20/22] KVM: arm64: vgic-its: Device table save/restore
From: Auger Eric @ 2017-05-03 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170430205540.GC1499@lvm>
Hi Christoffer,
On 30/04/2017 22:55, Christoffer Dall wrote:
> On Fri, Apr 14, 2017 at 12:15:32PM +0200, Eric Auger wrote:
>> This patch saves the device table entries into guest RAM.
>> Both flat table and 2 stage tables are supported. DeviceId
>> indexing is used.
>>
>> For each device listed in the device table, we also save
>> the translation table using the vgic_its_save/restore_itt
>> routines.
>>
>> On restore, devices are re-allocated and their ite are
>> re-built.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> v4 -> v5:
>> - sort the device list by deviceid on device table save
>> - use defines for shifts and masks
>> - use abi->dte_esz
>> - clatify entry sizes for L1 and L2 tables
>>
>> v3 -> v4:
>> - use the new proto for its_alloc_device
>> - compute_next_devid_offset, vgic_its_flush/restore_itt
>> become static in this patch
>> - change in the DTE entry format with the introduction of the
>> valid bit and next field width decrease; ittaddr encoded
>> on its full range
>> - fix handle_l1_entry entry handling
>> - correct vgic_its_table_restore error handling
>>
>> v2 -> v3:
>> - fix itt_addr bitmask in vgic_its_restore_dte
>> - addition of return 0 in vgic_its_restore_ite moved to
>> the ITE related patch
>>
>> v1 -> v2:
>> - use 8 byte format for DTE and ITE
>> - support 2 stage format
>> - remove kvm parameter
>> - ITT flush/restore moved in a separate patch
>> - use deviceid indexing
>> ---
>> virt/kvm/arm/vgic/vgic-its.c | 183 +++++++++++++++++++++++++++++++++++++++++--
>> virt/kvm/arm/vgic/vgic.h | 7 ++
>> 2 files changed, 185 insertions(+), 5 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
>> index b02fc3f..86dfc6c 100644
>> --- a/virt/kvm/arm/vgic/vgic-its.c
>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>> @@ -1682,7 +1682,8 @@ int vgic_its_attr_regs_access(struct kvm_device *dev,
>> return ret;
>> }
>>
>> -u32 compute_next_devid_offset(struct list_head *h, struct its_device *dev)
>> +static u32 compute_next_devid_offset(struct list_head *h,
>> + struct its_device *dev)
>> {
>> struct list_head *e = &dev->dev_list;
>> struct its_device *next;
>> @@ -1858,7 +1859,7 @@ static int vgic_its_ite_cmp(void *priv, struct list_head *a,
>> return 1;
>> }
>>
>> -int vgic_its_save_itt(struct vgic_its *its, struct its_device *device)
>> +static int vgic_its_save_itt(struct vgic_its *its, struct its_device *device)
>> {
>> const struct vgic_its_abi *abi = vgic_its_get_abi(its);
>> gpa_t base = device->itt_addr;
>> @@ -1877,7 +1878,7 @@ int vgic_its_save_itt(struct vgic_its *its, struct its_device *device)
>> return 0;
>> }
>>
>> -int vgic_its_restore_itt(struct vgic_its *its, struct its_device *dev)
>> +static int vgic_its_restore_itt(struct vgic_its *its, struct its_device *dev)
>> {
>> const struct vgic_its_abi *abi = vgic_its_get_abi(its);
>> gpa_t base = dev->itt_addr;
>> @@ -1895,12 +1896,161 @@ int vgic_its_restore_itt(struct vgic_its *its, struct its_device *dev)
>> }
>>
>> /**
>> + * vgic_its_save_dte - Save a device table entry at a given GPA
>> + *
>> + * @its: ITS handle
>> + * @dev: ITS device
>> + * @ptr: GPA
>> + */
>> +static int vgic_its_save_dte(struct vgic_its *its, struct its_device *dev,
>> + gpa_t ptr, int dte_esz)
>> +{
>> + struct kvm *kvm = its->dev->kvm;
>> + u64 val, itt_addr_field;
>> + int ret;
>> + u32 next_offset;
>> +
>> + itt_addr_field = dev->itt_addr >> 8;
>> + next_offset = compute_next_devid_offset(&its->device_list, dev);
>> + val = (1ULL << KVM_ITS_DTE_VALID_SHIFT |
>> + ((u64)next_offset << KVM_ITS_DTE_NEXT_SHIFT) |
>
> I think this implies that the next field in your ABI points to the next
> offset, regardless of whether or not this is in a a level 2 or lavel 1
> table. See more comments on this below (I reviewed this patch from the
> bottom up).
Not sure I understand your comment.
Doc says:
- next: equals to 0 if this entry is the last one; otherwise it
corresponds to the deviceid offset to the next DTE, capped by
2^14 -1.
This is independent on 1 or 2 levels as we sort the devices by
deviceid's and compute the delta between those id.
>
> I have a feeling this wasn't tested with 2 level device tables. Could
> that be true?
No this was tested with 1 & and 2 levels (I hacked the guest to force 2
levels). 1 test hole I have though is all my dte's currently belong to
the same 2d level page, ie. my deviceid are not scattered enough.
>
>> + (itt_addr_field << KVM_ITS_DTE_ITTADDR_SHIFT) |
>> + (dev->nb_eventid_bits - 1));
>> + val = cpu_to_le64(val);
>> + ret = kvm_write_guest(kvm, ptr, &val, dte_esz);
>> + return ret;
>> +}
>> +
>> +/**
>> + * vgic_its_restore_dte - restore a device table entry
>> + *
>> + * @its: its handle
>> + * @id: device id the DTE corresponds to
>> + * @ptr: kernel VA where the 8 byte DTE is located
>> + * @opaque: unused
>> + * @next: offset to the next valid device id
>> + *
>> + * Return: < 0 on error, 0 otherwise
>> + */
>> +static int vgic_its_restore_dte(struct vgic_its *its, u32 id,
>> + void *ptr, void *opaque, u32 *next)
>> +{
>> + struct its_device *dev;
>> + gpa_t itt_addr;
>> + u8 nb_eventid_bits;
>> + u64 entry = *(u64 *)ptr;
>> + bool valid;
>> + int ret;
>> +
>> + entry = le64_to_cpu(entry);
>> +
>> + valid = entry >> KVM_ITS_DTE_VALID_SHIFT;
>> + nb_eventid_bits = (entry & KVM_ITS_DTE_SIZE_MASK) + 1;
>> + itt_addr = ((entry & KVM_ITS_DTE_ITTADDR_MASK)
>> + >> KVM_ITS_DTE_ITTADDR_SHIFT) << 8;
>> + *next = 1;
>> +
>> + if (!valid)
>> + return 0;
>> +
>> + /* dte entry is valid */
>> + *next = (entry & KVM_ITS_DTE_NEXT_MASK) >> KVM_ITS_DTE_NEXT_SHIFT;
>> +
>> + ret = vgic_its_alloc_device(its, &dev, id,
>> + itt_addr, nb_eventid_bits);
>> + if (ret)
>> + return ret;
>> + ret = vgic_its_restore_itt(its, dev);
>> +
>> + return ret;
>> +}
>> +
>> +static int vgic_its_device_cmp(void *priv, struct list_head *a,
>> + struct list_head *b)
>> +{
>> + struct its_device *deva = container_of(a, struct its_device, dev_list);
>> + struct its_device *devb = container_of(b, struct its_device, dev_list);
>> +
>> + if (deva->device_id < devb->device_id)
>> + return -1;
>> + else
>> + return 1;
>> +}
>> +
>> +/**
>> * vgic_its_save_device_tables - Save the device table and all ITT
>> * into guest RAM
>> + *
>> + * L1/L2 handling is hidden by vgic_its_check_id() helper which directly
>> + * returns the GPA of the device entry
>> */
>> static int vgic_its_save_device_tables(struct vgic_its *its)
>> {
>> - return -ENXIO;
>> + const struct vgic_its_abi *abi = vgic_its_get_abi(its);
>> + struct its_device *dev;
>> + int dte_esz = abi->dte_esz;
>> + u64 baser;
>> +
>> + baser = its->baser_device_table;
>> +
>> + list_sort(NULL, &its->device_list, vgic_its_device_cmp);
>> +
>> + list_for_each_entry(dev, &its->device_list, dev_list) {
>> + int ret;
>> + gpa_t eaddr;
>> +
>> + if (!vgic_its_check_id(its, baser,
>> + dev->device_id, &eaddr))
>> + return -EINVAL;
>> +
>> + ret = vgic_its_save_itt(its, dev);
>> + if (ret)
>> + return ret;
>> +
>> + ret = vgic_its_save_dte(its, dev, eaddr, dte_esz);
>> + if (ret)
>> + return ret;
>> + }
>> + return 0;
>> +}
>> +
>> +/**
>> + * handle_l1_entry - callback used for L1 entries (2 stage case)
>> + *
>> + * @its: its handle
>> + * @id: id
>
> IIUC, this is actually the index of the entry in the L1 table. I think
> this should be clarified.
yep
>
>> + * @addr: kernel VA
>> + * @opaque: unused
>> + * @next_offset: offset to the next L1 entry: 0 if the last element
>> + * was found, 1 otherwise
>> + */
>> +static int handle_l1_entry(struct vgic_its *its, u32 id, void *addr,
>> + void *opaque, u32 *next_offset)
>
> nit: shouldn't this be called handle_l1_device_table_entry ?
renamed into handle_l1_dte
>
>> +{
>> + const struct vgic_its_abi *abi = vgic_its_get_abi(its);
>> + int l2_start_id = id * (SZ_64K / GITS_LVL1_ENTRY_SIZE);
>
> Hmmm, is this not actually supposed to be (SZ_64K / abi->dte_esz) ?
no because 1st level entries have a fixed size of GITS_LVL1_ENTRY_SIZE bytes
>
>> + u64 entry = *(u64 *)addr;
>> + int ret, ite_esz = abi->ite_esz;
>
> Should this be ite_esz or dte_esz?
you're correct. dte_esz should be used.
>
>> + gpa_t gpa;
>
> nit: put declarations with initialization on separate lines.
OK
>
>> +
>> + entry = le64_to_cpu(entry);
>> + *next_offset = 1;
>
> I think you could attach a comment here saying that level 1 tables have
> to be scanned entirely.
added. note we exit as soon as the last element is found when scanning
l2 tables.
>
> But this also reminds me. Does that mean that the next field in the DTE
> in your documented ABI format points to the next DTE within that level-2
> table, or does it point across to different level-2 tables? I think
> this needs to be clarified in the ABI unless I'm missing something.
see above comment on next_index semantic. In the doc I talk about
deviceid offset and not of table index.
>
>> +
>> + if (!(entry & BIT_ULL(63)))
>> + return 0;
>> +
>> + gpa = entry & GENMASK_ULL(51, 16);
>
> Can you define the bit fields for the level-1 entries as well please?
yep
>
>> +
>> + ret = lookup_table(its, gpa, SZ_64K, ite_esz,
>> + l2_start_id, vgic_its_restore_dte, NULL);
>> +
>> + if (ret == 1) {
>> + /* last entry was found in this L2 table */
>
> maybe you should define these return codes for you table scan function,
> and you wouldn't have to have a separate comment and it would be
> generally easier to follow the code.
I revisited the error values according to your suggestion and this looks
simpler to me now.
>
>> + *next_offset = 0;
>> + ret = 0;
>> + }
>> +
>> + return ret;
>> }
>>
>> /**
>> @@ -1909,7 +2059,30 @@ static int vgic_its_save_device_tables(struct vgic_its *its)
>> */
>> static int vgic_its_restore_device_tables(struct vgic_its *its)
>> {
>> - return -ENXIO;
>> + const struct vgic_its_abi *abi = vgic_its_get_abi(its);
>> + u64 baser = its->baser_device_table;
>> + int l1_esz, ret, l1_tbl_size = GITS_BASER_NR_PAGES(baser) * SZ_64K;
>
> nit: put this initialization on a separate line.
done
>
>> + gpa_t l1_gpa;
>> +
>> + l1_gpa = BASER_ADDRESS(baser);
>> + if (!l1_gpa)
>> + return 0;
>
> I think you meant to check the valid bit here.
yes
>
>> +
>> + if (baser & GITS_BASER_INDIRECT) {
>> + l1_esz = 8;
>> + ret = lookup_table(its, l1_gpa, l1_tbl_size, l1_esz, 0,
>> + handle_l1_entry, NULL);
>> + } else {
>> + l1_esz = abi->dte_esz;
>> + ret = lookup_table(its, l1_gpa, l1_tbl_size, l1_esz, 0,
>> + vgic_its_restore_dte, NULL);
>> + }
>> +
>> + if (ret < 0)
>> + return ret;
>> +
>> + /* if last element was not found we have an issue here */
>
> same comment as other patch
>
>> + return ret ? 0 : -EINVAL;
revisited
Thanks
Eric
>> }
>>
>> static int vgic_its_save_cte(struct vgic_its *its,
>> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
>> index ce57fbd..9bc52ef 100644
>> --- a/virt/kvm/arm/vgic/vgic.h
>> +++ b/virt/kvm/arm/vgic/vgic.h
>> @@ -85,6 +85,13 @@
>> #define KVM_ITS_ITE_PINTID_SHIFT 16
>> #define KVM_ITS_ITE_PINTID_MASK GENMASK_ULL(47, 16)
>> #define KVM_ITS_ITE_ICID_MASK GENMASK_ULL(15, 0)
>> +#define KVM_ITS_DTE_VALID_SHIFT 63
>> +#define KVM_ITS_DTE_VALID_MASK BIT_ULL(63)
>> +#define KVM_ITS_DTE_NEXT_SHIFT 49
>> +#define KVM_ITS_DTE_NEXT_MASK GENMASK_ULL(62, 49)
>> +#define KVM_ITS_DTE_ITTADDR_SHIFT 5
>> +#define KVM_ITS_DTE_ITTADDR_MASK GENMASK_ULL(48, 5)
>> +#define KVM_ITS_DTE_SIZE_MASK GENMASK_ULL(4, 0)
>>
>> static inline bool irq_is_pending(struct vgic_irq *irq)
>> {
>> --
>> 2.5.5
>>
> Thanks,
> -Christoffer
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH] arm64: dts: freescale: update the copyright claims
From: Shawn Guo @ 2017-05-03 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493311678-6207-1-git-send-email-leoyang.li@nxp.com>
On Thu, Apr 27, 2017 at 11:47:58AM -0500, Li Yang wrote:
> Update the copyright claims to comply with company policy.
>
> Signed-off-by: Li Yang <leoyang.li@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: imx_v6_v7_defconfig: Enable cpufreq governors
From: Shawn Guo @ 2017-05-03 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c401883fec8db20878c7593d879e9e128cacc495.1493736306.git.leonard.crestez@nxp.com>
On Tue, May 02, 2017 at 05:46:00PM +0300, Leonard Crestez wrote:
> Enable more common cpufreq governors in imx defconfig because this is
> very useful for testing. In particular you can't use cpufreq-set -f
> $FREQ without explicitly defining CONFIG_CPU_FREQ_GOV_USERSPACE=y.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] arm64: Do not leave an invalid area->pages pointer in dma_common_contiguous_remap()
From: Catalin Marinas @ 2017-05-03 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9ae0fc6b-1da5-760b-9e92-f03bfcf77cd3@arm.com>
On Wed, May 03, 2017 at 01:10:26PM +0100, Robin Murphy wrote:
> On 25/04/17 19:22, Catalin Marinas wrote:
> > The dma_common_pages_remap() function allocates a vm_struct object and
> > initialises the pages pointer to value passed as argument. However, when
> > this function is called dma_common_contiguous_remap(), the pages array
> > is only temporarily allocated, being freed shortly after
> > dma_common_contiguous_remap() returns. Architecture code checking the
> > validity of an area->pages pointer would incorrectly dereference already
> > freed pointers. This has been exposed by the arm64 commit 44176bb38fa4
> > ("arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU").
> >
> > Fixes: 513510ddba96 ("common: dma-mapping: introduce common remapping functions")
> > Cc: Laura Abbott <labbott@redhat.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Reported-by: Andrzej Hajda <a.hajda@samsung.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> >
> > This is for correctness since once the arm64's mmap and get_sgtable ops
> > are fixed for DMA_ATTR_FORCE_CONTIGUOUS, we would no longer see the
> > issue. Anyway, it's better to get this fixed in case others trip over a
> > similar issue. I added a "Fixes" tag for completeness but I'm not sure
> > it's worth back-porting.
> >
> > drivers/base/dma-mapping.c | 29 ++++++++++++++++++++++-------
> > 1 file changed, 22 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> > index efd71cf4fdea..ab7071041141 100644
> > --- a/drivers/base/dma-mapping.c
> > +++ b/drivers/base/dma-mapping.c
> > @@ -277,8 +277,8 @@ EXPORT_SYMBOL(dma_common_mmap);
> > * remaps an array of PAGE_SIZE pages into another vm_area
> > * Cannot be used in non-sleeping contexts
> > */
>
> Nit: the above comment ends up in the wrong place now (it should still
> belong to dma_common_pages_remap()).
Good point, thanks. I'll send a v2 to Greg as we don't really have a
dependency on this on arm64 (once the DMA_ATTR_FORCE_CONTIGUOUS patch is
fixed or reverted).
--
Catalin
^ permalink raw reply
* [PATCHv2 0/2] kvm: arm/arm64: Fixes for race conditions
From: Suzuki K Poulose @ 2017-05-03 14:17 UTC (permalink / raw)
To: linux-arm-kernel
These two patches fixes race conditions in the stage2 page table
handling of the KVM on arm/arm64.
Applies on next-20170503.
Changes since v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/502867.html
- Dropped patch for fixing mmu_notifier race condition, which couldn't be
reproduced.
- Added reviewed-by from Christoffer
- Added new patch to fix another race condition
Suzuki K Poulose (2):
kvm: arm/arm64: Fix race in resetting stage2 PGD
kvm: arm/arm64: Fix use after free of stage2 page table
arch/arm/kvm/mmu.c | 33 ++++++++++++++++++++-------------
1 file changed, 20 insertions(+), 13 deletions(-)
--
2.7.4
^ 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