* Re: [PATCH pinctrl/fixes] pinctrl: aspeed: Fix spurious mux failures on the AST2500
From: Linus Walleij @ 2019-09-12 8:23 UTC (permalink / raw)
To: Andrew Jeffery
Cc: linux-aspeed, OpenBMC Maillist, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Joel Stanley, Linux ARM, John Wang
In-Reply-To: <20190829071738.2523-1-andrew@aj.id.au>
On Thu, Aug 29, 2019 at 8:17 AM Andrew Jeffery <andrew@aj.id.au> wrote:
> Commit 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
> was determined to be a partial fix to the problem of acquiring the LPC
> Host Controller and GFX regmaps: The AST2500 pin controller may need to
> fetch syscon regmaps during expression evaluation as well as when
> setting mux state. For example, this case is hit by attempting to export
> pins exposing the LPC Host Controller as GPIOs.
>
> An optional eval() hook is added to the Aspeed pinmux operation struct
> and called from aspeed_sig_expr_eval() if the pointer is set by the
> SoC-specific driver. This enables the AST2500 to perform the custom
> action of acquiring its regmap dependencies as required.
>
> John Wang tested the fix on an Inspur FP5280G2 machine (AST2500-based)
> where the issue was found, and I've booted the fix on Witherspoon
> (AST2500) and Palmetto (AST2400) machines, and poked at relevant pins
> under QEMU by forcing mux configurations via devmem before exporting
> GPIOs to exercise the driver.
>
> Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX controllers")
> Fixes: 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
> Reported-by: John Wang <wangzqbj@inspur.com>
> Tested-by: John Wang <wangzqbj@inspur.com>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Applied for fixes already yesterday!
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 4/4] arm64: dts: add support for A1 based Amlogic AD401
From: Jianxin Pan @ 2019-09-12 8:25 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Martin Blumenstingl,
linux-kernel, Qiufang Dai, Rob Herring, Jian Hu, Xingyu Chen,
Carlo Caione, Tao Zeng, linux-arm-kernel, Jerome Brunet
In-Reply-To: <e0054a53-7516-0527-3df7-c85e168003ba@baylibre.com>
Hi Neil,
On 2019/9/11 23:54, Neil Armstrong wrote:
> On 11/09/2019 17:38, Jianxin Pan wrote:
>> Add basic support for the Amlogic A1 based Amlogic AD401 board:
>> which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
>> Timer, UART. It's capable of booting up into the serial console.
>>
>> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
>> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
>> ---
>> arch/arm64/boot/dts/amlogic/Makefile | 1 +
>> arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts | 30 ++++++
>> arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 131 +++++++++++++++++++++++++
>> 3 files changed, 162 insertions(+)
[...]
>> +
>> + sm: secure-monitor {
>> + compatible = "amlogic,meson-gxbb-sm";
>> + };
>> +
>> + soc {
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> +
>> + apb: bus@0xfe000000 {
>
> Should be bus@fe000000
>
Thanks for your review.
I resent a new version and fixed it.
>> + compatible = "simple-bus";
>> + reg = <0x0 0xfe000000 0x0 0x1000000>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
[...]
>> + xtal: xtal-clk {
>> + compatible = "fixed-clock";
>> + clock-frequency = <24000000>;
>> + clock-output-names = "xtal";
>> + #clock-cells = <0>;
>> + };
>> +};
>>
>
> With that fixed:
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>
> Neil
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/2] block: bypass blk_set_runtime_active for uninitialized q->dev
From: Stanley Chu @ 2019-09-12 8:33 UTC (permalink / raw)
To: Jens Axboe
Cc: linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
Andy Teng (鄧如宏), jejb@linux.ibm.com,
Chun-Hung Wu (巫駿宏),
Kuohong Wang (王國鴻),
linux-block@vger.kernel.org, linux-mediatek@lists.infradead.org,
Peter Wang (王信友), matthias.bgg@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <66fddf12-0dc4-1c73-affd-f8404e87342f@kernel.dk>
Hi Jens,
> > void blk_set_runtime_active(struct request_queue *q)
> > {
> > + if (!q->dev)
> > + return;
> > +
> > spin_lock_irq(&q->queue_lock);
> > q->rpm_status = RPM_ACTIVE;
> > pm_runtime_mark_last_busy(q->dev);
>
> I'd prefer just doing:
>
> if (q->dev) {
> ...
> }
>
> instead. Other than that little complaint, looks good to me.
>
OK! I will change it in v2.
Thanks,
Stanley
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] fixup null q->dev checking in both block and scsi layer
From: Stanley Chu @ 2019-09-12 8:35 UTC (permalink / raw)
To: linux-scsi, linux-block, martin.petersen, axboe, jejb,
matthias.bgg
Cc: andy.teng, chun-hung.wu, kuohong.wang, linux-mediatek, peter.wang,
Stanley Chu, linux-arm-kernel
Some devices may skip blk_pm_runtime_init() and have null pointer in its request_queue->dev. For example, SCSI devices of UFS Well-Known LUNs.
Currently the null pointer is checked by the user of blk_set_runtime_active(), i.e., scsi_dev_type_resume(). It is better to check it by blk_set_runtime_active() itself instead of by its users.
v1 => v2:
- Change if style in blk_set_runtime_active() (Jens)
Stanley Chu (2):
block: bypass blk_set_runtime_active for uninitialized q->dev
scsi: core: remove dummy q->dev check
block/blk-pm.c | 12 +++++++-----
drivers/scsi/scsi_pm.c | 3 +--
2 files changed, 8 insertions(+), 7 deletions(-)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/2] block: bypass blk_set_runtime_active for uninitialized q->dev
From: Stanley Chu @ 2019-09-12 8:35 UTC (permalink / raw)
To: linux-scsi, linux-block, martin.petersen, axboe, jejb,
matthias.bgg
Cc: andy.teng, chun-hung.wu, kuohong.wang, linux-mediatek, peter.wang,
Stanley Chu, linux-arm-kernel
In-Reply-To: <1568277328-4597-1-git-send-email-stanley.chu@mediatek.com>
Some devices may skip blk_pm_runtime_init() and have null pointer
in its request_queue->dev. For example, SCSI devices of UFS Well-Known
LUNs.
Currently the null pointer is checked by the user of
blk_set_runtime_active(), i.e., scsi_dev_type_resume(). It is better to
check it by blk_set_runtime_active() itself instead of by its users.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
---
block/blk-pm.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/block/blk-pm.c b/block/blk-pm.c
index 0a028c189897..1adc1cd748b4 100644
--- a/block/blk-pm.c
+++ b/block/blk-pm.c
@@ -207,10 +207,12 @@ EXPORT_SYMBOL(blk_post_runtime_resume);
*/
void blk_set_runtime_active(struct request_queue *q)
{
- spin_lock_irq(&q->queue_lock);
- q->rpm_status = RPM_ACTIVE;
- pm_runtime_mark_last_busy(q->dev);
- pm_request_autosuspend(q->dev);
- spin_unlock_irq(&q->queue_lock);
+ if (q->dev) {
+ spin_lock_irq(&q->queue_lock);
+ q->rpm_status = RPM_ACTIVE;
+ pm_runtime_mark_last_busy(q->dev);
+ pm_request_autosuspend(q->dev);
+ spin_unlock_irq(&q->queue_lock);
+ }
}
EXPORT_SYMBOL(blk_set_runtime_active);
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] scsi: core: remove dummy q->dev check
From: Stanley Chu @ 2019-09-12 8:35 UTC (permalink / raw)
To: linux-scsi, linux-block, martin.petersen, axboe, jejb,
matthias.bgg
Cc: andy.teng, chun-hung.wu, kuohong.wang, linux-mediatek, peter.wang,
Stanley Chu, linux-arm-kernel
In-Reply-To: <1568277328-4597-1-git-send-email-stanley.chu@mediatek.com>
Currently blk_set_runtime_active() is checking if q->dev is null by
itself, thus remove the same checking in its user: scsi_dev_type_resume().
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
---
drivers/scsi/scsi_pm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 74ded5f3c236..3717eea37ecb 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -94,8 +94,7 @@ static int scsi_dev_type_resume(struct device *dev,
if (!err && scsi_is_sdev_device(dev)) {
struct scsi_device *sdev = to_scsi_device(dev);
- if (sdev->request_queue->dev)
- blk_set_runtime_active(sdev->request_queue);
+ blk_set_runtime_active(sdev->request_queue);
}
}
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V7 3/3] arm64/mm: Enable memory hot remove
From: Anshuman Khandual @ 2019-09-12 8:37 UTC (permalink / raw)
To: Catalin Marinas
Cc: mark.rutland, mhocko, david, linux-mm, arunks, cpandya, ira.weiny,
will, steven.price, valentin.schneider, suzuki.poulose,
Robin.Murphy, broonie, cai, ard.biesheuvel, dan.j.williams,
linux-arm-kernel, osalvador, steve.capper, logang, linux-kernel,
akpm, mgorman
In-Reply-To: <9a7a82cd-77d0-bcab-3028-7be0599b0a10@arm.com>
On 09/12/2019 09:58 AM, Anshuman Khandual wrote:
>
> On 09/10/2019 09:47 PM, Catalin Marinas wrote:
>> On Tue, Sep 03, 2019 at 03:15:58PM +0530, Anshuman Khandual wrote:
>>> @@ -770,6 +1022,28 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>>> void vmemmap_free(unsigned long start, unsigned long end,
>>> struct vmem_altmap *altmap)
>>> {
>>> +#ifdef CONFIG_MEMORY_HOTPLUG
>>> + /*
>>> + * FIXME: We should have called remove_pagetable(start, end, true).
>>> + * vmemmap and vmalloc virtual range might share intermediate kernel
>>> + * page table entries. Removing vmemmap range page table pages here
>>> + * can potentially conflict with a concurrent vmalloc() allocation.
>>> + *
>>> + * This is primarily because vmalloc() does not take init_mm ptl for
>>> + * the entire page table walk and it's modification. Instead it just
>>> + * takes the lock while allocating and installing page table pages
>>> + * via [p4d|pud|pmd|pte]_alloc(). A concurrently vanishing page table
>>> + * entry via memory hot remove can cause vmalloc() kernel page table
>>> + * walk pointers to be invalid on the fly which can cause corruption
>>> + * or worst, a crash.
>>> + *
>>> + * So free_empty_tables() gets called where vmalloc and vmemmap range
>>> + * do not overlap at any intermediate level kernel page table entry.
>>> + */
>>> + unmap_hotplug_range(start, end, true);
>>> + if (!vmalloc_vmemmap_overlap)
>>> + free_empty_tables(start, end);
>>> +#endif
>>> }
>>> #endif /* CONFIG_SPARSEMEM_VMEMMAP */
> Hello Catalin,
>
>> I wonder whether we could simply ignore the vmemmap freeing altogether,
>> just leave it around and not unmap it. This way, we could call
> This would have been an option (even if we just ignore for a moment that
> it might not be the cleanest possible method) if present memory hot remove
> scenarios involved just system RAM of comparable sizes.
>
> But with persistent memory which will be plugged in as ZONE_DEVICE might
> ask for a vmem_atlamp based vmemmap mapping where the backing memory comes
> from the persistent memory range itself not from existing system RAM. IIRC
> altmap support was originally added because the amount persistent memory on
> a system might be order of magnitude higher than that of regular system RAM.
> During normal memory hot add (without altmap) would have caused great deal
> of consumption from system RAM just for persistent memory range's vmemmap
> mapping. In order to avoid such a scenario altmap was created to allocate
> vmemmap mapping backing memory from the device memory range itself.
>
> In such cases vmemmap must be unmapped and it's backing memory freed up for
> the complete removal of persistent memory which originally requested for
> altmap based vmemmap backing.
>
> Just as a reference, the upcoming series which enables altmap support on
> arm64 tries to allocate vmemmap mapping backing memory from the device range
> itself during memory hot add and free them up during memory hot remove. Those
> methods will not be possible if memory hot-remove does not really free up
> vmemmap backing storage.
>
> https://patchwork.kernel.org/project/linux-mm/list/?series=139299
>
Just to add in here. There is an ongoing work which will enable allocating
memory from the hot-add range itself even for normal system RAM. So this
might not be specific to ZONE_DEVICE based device/persistent memory alone
for a long time.
https://lore.kernel.org/lkml/20190725160207.19579-1-osalvador@suse.de/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] aarch64/mm: speedup memory initialisation
From: Hubert Ralf @ 2019-09-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org, anshuman.khandual@arm.com
In-Reply-To: <645c9de8-d82a-8d51-ae4a-bcf903ccd1e5@arm.com>
Am Donnerstag, den 12.09.2019, 13:42 +0530 schrieb Anshuman Khandual:
>
> On 09/10/2019 02:29 PM, Hubert Ralf wrote:
> > On ARM64 memmap_init_zone is used during bootmem_init, which iterates over
> > all pages in the memory starting at the lowest address until the highest
> > address is reached. On arm64 this ends up in searching a memmory region
> > containing for each single page between lowest and highest available
> > physicall address.
> >
> > Having a sparse memory system there may be some big holes in the
> > memory map. For each page in this holes a lookup is done, which is
> > implemented as a binary search on the available memory blocks.
> >
> > Adding a memmap_init for aarch64 to do the init only for the available
> > memory areas reduces the time needed for initialising memory on startup.
> > On a Renesas R-CAR M3 based system with a total hole of 20GB bootmem_init
> > execution time is reduced from 378ms to 84ms.
> >
> > Signed-off-by: Ralf Hubert <ralf.hubert@preh.de>
> > ---
> > arch/arm64/include/asm/pgtable.h | 7 +++++++
> > arch/arm64/mm/init.c | 24 ++++++++++++++++++++++++
> > 2 files changed, 31 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> > index e09760ece844..8c6eefc08b0b 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -298,6 +298,13 @@ static inline int pte_same(pte_t pte_a, pte_t pte_b)
> > return (lhs == rhs);
> > }
> >
> > +#ifdef CONFIG_SPARSEMEM
> > +/* arch mem_map init routine is needed due to holes in a memmap */
> > +# define __HAVE_ARCH_MEMMAP_INIT
>
> This is not required any more. Its gone with the following commit which
> also made generic memmap_init() an weak function currently overridden
> only on ia64.
>
> dfb3ccd00a0 ("mm: make memmap_init a proper function")
>
> > + void memmap_init(unsigned long size, int nid, unsigned long zone,
> > + unsigned long start_pfn);
> > +#endif /* CONFIG_SPARSEMEM */
> > +
> > /*
> > * Huge pte definitions.
> > */
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index f3c795278def..206b28310872 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -250,6 +250,30 @@ int pfn_valid(unsigned long pfn)
> > }
> > EXPORT_SYMBOL(pfn_valid);
> >
> > +#ifdef CONFIG_SPARSEMEM
> > +void __meminit
> > +memmap_init(unsigned long size, int nid, unsigned long zone,
> > + unsigned long start_pfn)
> > +{
> > + struct memblock_region *reg;
> > +
> > + for_each_memblock(memory, reg) {
> > + unsigned long start = memblock_region_memory_base_pfn(reg);
> > + unsigned long end = memblock_region_memory_end_pfn(reg);
> > +
> > + if (start < start_pfn)
> > + start = start_pfn;
> > + if (end > start_pfn + size)
> > + end = start_pfn + size;
> > +
> > + if (start < end) {
> > + memmap_init_zone(end - start, nid, zone, start,
> > + MEMMAP_EARLY, NULL);
> > + }
> > + }
> > +}
> > +#endif /* CONFIG_SPARSEMEM */
>
> In generic mmap_init(), the current high cost comes from early_pfn_valid()
> check for each pfn in memmap_init_zone() given that early_pfn_valid() is
> pfn_valid() when CONFIG_SPARSEMEM which is known to be expensive on arm64.
>
> Though we cannot do anything about pfns which are really present but the
> high cost for non present pfns should be eliminated. The following check
> in the above for_each_memblock() loop can achieve that.
>
> if (reg->flags & MEMBLOCK_NOMAP)
> continue;
>
> MEMBLOCK_NOMAP universally should not be initialized into a zone and holes
> if any should also be universally skipped across platforms. So these changes
> can be moved into generic memmap_init() which will benefit other platforms.
Not sure if I got this. This is a additional short path for memblocks with
the MEMBLOCK_NOMAP flag set, right? For memblocks without these flag the remaining
code still needs to be executed?
In my case I have 4 memblocks with 1.5GB RAM at 0x4000 0000, 0x4 8000 0000,
0x6 0000 0000 and 0x6 8000 0000. None of them has the MEMBLOCK_NOMAP flag set.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] arm64: psci: Use udelay() instead of msleep() to reduce waiting time
From: David Laight @ 2019-09-12 8:48 UTC (permalink / raw)
To: 'Yunfeng Ye', catalin.marinas@arm.com, will@kernel.org
Cc: kstewart@linuxfoundation.org, ard.biesheuvel@linaro.org,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de, wuyun.wu@huawei.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <e4d42bda-72f2-4002-f319-1cbe2bff74d2@huawei.com>
From: Yunfeng Ye
> Sent: 11 September 2019 09:50
> We want to reduce the time of cpu_down() for saving power, found that
> cpu_psci_cpu_kill() cost 10ms after psci_ops.affinity_info() fail.
>
> Normally the time cpu dead is very short, it is no need to wait 10ms.
> so use udelay 10us to instead msleep 10ms in every waiting loop, and add
> cond_resched() to give a chance to run a higher-priority process.
>
> Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
> ---
> arch/arm64/kernel/psci.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index 85ee7d0..9e9d8a6 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -86,15 +86,15 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
> * while it is dying. So, try again a few times.
> */
>
> - for (i = 0; i < 10; i++) {
> + for (i = 0; i < 10000; i++) {
> err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
> if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
> pr_info("CPU%d killed.\n", cpu);
> return 0;
> }
>
> - msleep(10);
> - pr_info("Retrying again to check for CPU kill\n");
> + cond_resched();
> + udelay(10);
You really don't want to be doing 10000 udelay(10) before giving up.
If udelay(10) is long enough for the normal case, then do that once.
After that use usleep_range().
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] crypto: sun4i-ss: enable pm_runtime
From: Corentin Labbe @ 2019-09-12 8:49 UTC (permalink / raw)
To: Maxime Ripard
Cc: herbert, linux-sunxi, linux-kernel, Maxime Ripard, Chen-Yu Tsai,
linux-crypto, davem, linux-arm-kernel
In-Reply-To: <CAO4ZVTM99FksM71BAiraYj7eyREO1Qi=L1NFzEkNmMgBmphBww@mail.gmail.com>
On Thu, Sep 12, 2019 at 08:35:51AM +0200, Maxime Ripard wrote:
> Hi,
>
> Le mer. 11 sept. 2019 à 13:46, Corentin Labbe
> <clabbe.montjoie@gmail.com> a écrit :
> >
> > This patch enables power management on the Security System.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 5 +++
> > drivers/crypto/sunxi-ss/sun4i-ss-core.c | 42 ++++++++++++++++++++++-
> > 2 files changed, 46 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> > index fa4b1b47822e..1fedec9e83b0 100644
> > --- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> > @@ -10,6 +10,8 @@
> > *
> > * You could find the datasheet in Documentation/arm/sunxi.rst
> > */
> > +
> > +#include <linux/pm_runtime.h>
> > #include "sun4i-ss.h"
> >
> > static int noinline_for_stack sun4i_ss_opti_poll(struct skcipher_request *areq)
> > @@ -497,13 +499,16 @@ int sun4i_ss_cipher_init(struct crypto_tfm *tfm)
> > return PTR_ERR(op->fallback_tfm);
> > }
> >
> > + pm_runtime_get_sync(op->ss->dev);
> > return 0;
> > }
> >
> > void sun4i_ss_cipher_exit(struct crypto_tfm *tfm)
> > {
> > struct sun4i_tfm_ctx *op = crypto_tfm_ctx(tfm);
> > +
> > crypto_free_sync_skcipher(op->fallback_tfm);
> > + pm_runtime_put_sync(op->ss->dev);
> > }
> >
> > /* check and set the AES key, prepare the mode to be used */
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > index 2c9ff01dddfc..5e6e1a308f60 100644
> > --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > @@ -14,6 +14,7 @@
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/platform_device.h>
> > +#include <linux/pm_runtime.h>
> > #include <crypto/scatterwalk.h>
> > #include <linux/scatterlist.h>
> > #include <linux/interrupt.h>
> > @@ -258,6 +259,37 @@ static int sun4i_ss_enable(struct sun4i_ss_ctx *ss)
> > return err;
> > }
> >
> > +#ifdef CONFIG_PM
> > +static int sun4i_ss_pm_suspend(struct device *dev)
> > +{
> > + struct sun4i_ss_ctx *ss = dev_get_drvdata(dev);
> > +
> > + sun4i_ss_disable(ss);
> > + return 0;
> > +}
> > +
> > +static int sun4i_ss_pm_resume(struct device *dev)
> > +{
> > + struct sun4i_ss_ctx *ss = dev_get_drvdata(dev);
> > +
> > + return sun4i_ss_enable(ss);
> > +}
> > +#endif
> > +
> > +const struct dev_pm_ops sun4i_ss_pm_ops = {
> > + SET_RUNTIME_PM_OPS(sun4i_ss_pm_suspend, sun4i_ss_pm_resume, NULL)
> > +};
> > +
> > +static void sun4i_ss_pm_init(struct sun4i_ss_ctx *ss)
> > +{
> > + pm_runtime_use_autosuspend(ss->dev);
> > + pm_runtime_set_autosuspend_delay(ss->dev, 1000);
> > +
> > + pm_runtime_get_noresume(ss->dev);
> > + pm_runtime_set_active(ss->dev);
> > + pm_runtime_enable(ss->dev);
> > +}
>
> It's not really clear to me what you're doing here? Can you explain?
>
I set the autosuspend state and delay.
I say that the device is active and so I "get" it.
Then I enable PM.
I do like that since I use the device later in probe(), so I need to keep it up.
At the end of probe() I put the device which go in suspend automaticaly after.
Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] drm/stm: dsi: higher pll out only in video burst mode
From: Yannick Fertré @ 2019-09-12 8:56 UTC (permalink / raw)
To: Yannick Fertre, Philippe Cornu, Benjamin Gaignard, Vincent Abriou,
David Airlie, Daniel Vetter, Maxime Coquelin, Alexandre Torgue,
dri-devel, linux-stm32, linux-arm-kernel, linux-kernel
In order to better support video non-burst modes,
the +20% on pll out is added only in burst mode.
Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Reviewed-by: Yannick FERTRE <yannick.fertre@st.com>
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index a03a642..514efef 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -260,8 +260,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
/* Compute requested pll out */
bpp = mipi_dsi_pixel_format_to_bpp(format);
pll_out_khz = mode->clock * bpp / lanes;
+
/* Add 20% to pll out to be higher than pixel bw (burst mode only) */
- pll_out_khz = (pll_out_khz * 12) / 10;
+ if (mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
+ pll_out_khz = (pll_out_khz * 12) / 10;
+
if (pll_out_khz > dsi->lane_max_kbps) {
pll_out_khz = dsi->lane_max_kbps;
DRM_WARN("Warning max phy mbps is used\n");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] aarch64/mm: speedup memory initialisation
From: Anshuman Khandual @ 2019-09-12 8:59 UTC (permalink / raw)
To: Hubert Ralf, linux-arm-kernel@lists.infradead.org
In-Reply-To: <bf14a3cb2812c03d08c380fccc4ca336cb7b5352.camel@preh.de>
On 09/12/2019 02:10 PM, Hubert Ralf wrote:
> Am Donnerstag, den 12.09.2019, 13:42 +0530 schrieb Anshuman Khandual:
>>
>> On 09/10/2019 02:29 PM, Hubert Ralf wrote:
>>> On ARM64 memmap_init_zone is used during bootmem_init, which iterates over
>>> all pages in the memory starting at the lowest address until the highest
>>> address is reached. On arm64 this ends up in searching a memmory region
>>> containing for each single page between lowest and highest available
>>> physicall address.
>>>
>>> Having a sparse memory system there may be some big holes in the
>>> memory map. For each page in this holes a lookup is done, which is
>>> implemented as a binary search on the available memory blocks.
>>>
>>> Adding a memmap_init for aarch64 to do the init only for the available
>>> memory areas reduces the time needed for initialising memory on startup.
>>> On a Renesas R-CAR M3 based system with a total hole of 20GB bootmem_init
>>> execution time is reduced from 378ms to 84ms.
>>>
>>> Signed-off-by: Ralf Hubert <ralf.hubert@preh.de>
>>> ---
>>> arch/arm64/include/asm/pgtable.h | 7 +++++++
>>> arch/arm64/mm/init.c | 24 ++++++++++++++++++++++++
>>> 2 files changed, 31 insertions(+)
>>>
>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>>> index e09760ece844..8c6eefc08b0b 100644
>>> --- a/arch/arm64/include/asm/pgtable.h
>>> +++ b/arch/arm64/include/asm/pgtable.h
>>> @@ -298,6 +298,13 @@ static inline int pte_same(pte_t pte_a, pte_t pte_b)
>>> return (lhs == rhs);
>>> }
>>>
>>> +#ifdef CONFIG_SPARSEMEM
>>> +/* arch mem_map init routine is needed due to holes in a memmap */
>>> +# define __HAVE_ARCH_MEMMAP_INIT
>>
>> This is not required any more. Its gone with the following commit which
>> also made generic memmap_init() an weak function currently overridden
>> only on ia64.
>>
>> dfb3ccd00a0 ("mm: make memmap_init a proper function")
>>
>>> + void memmap_init(unsigned long size, int nid, unsigned long zone,
>>> + unsigned long start_pfn);
>>> +#endif /* CONFIG_SPARSEMEM */
>>> +
>>> /*
>>> * Huge pte definitions.
>>> */
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index f3c795278def..206b28310872 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -250,6 +250,30 @@ int pfn_valid(unsigned long pfn)
>>> }
>>> EXPORT_SYMBOL(pfn_valid);
>>>
>>> +#ifdef CONFIG_SPARSEMEM
>>> +void __meminit
>>> +memmap_init(unsigned long size, int nid, unsigned long zone,
>>> + unsigned long start_pfn)
>>> +{
>>> + struct memblock_region *reg;
>>> +
>>> + for_each_memblock(memory, reg) {
>>> + unsigned long start = memblock_region_memory_base_pfn(reg);
>>> + unsigned long end = memblock_region_memory_end_pfn(reg);
>>> +
>>> + if (start < start_pfn)
>>> + start = start_pfn;
>>> + if (end > start_pfn + size)
>>> + end = start_pfn + size;
>>> +
>>> + if (start < end) {
>>> + memmap_init_zone(end - start, nid, zone, start,
>>> + MEMMAP_EARLY, NULL);
>>> + }
>>> + }
>>> +}
>>> +#endif /* CONFIG_SPARSEMEM */
>>
>> In generic mmap_init(), the current high cost comes from early_pfn_valid()
>> check for each pfn in memmap_init_zone() given that early_pfn_valid() is
>> pfn_valid() when CONFIG_SPARSEMEM which is known to be expensive on arm64.
>>
>> Though we cannot do anything about pfns which are really present but the
>> high cost for non present pfns should be eliminated. The following check
>> in the above for_each_memblock() loop can achieve that.
>>
>> if (reg->flags & MEMBLOCK_NOMAP)
>> continue;
>>
>> MEMBLOCK_NOMAP universally should not be initialized into a zone and holes
>> if any should also be universally skipped across platforms. So these changes
>> can be moved into generic memmap_init() which will benefit other platforms.
> Not sure if I got this. This is a additional short path for memblocks with
> the MEMBLOCK_NOMAP flag set, right? For memblocks without these flag the remaining
> code still needs to be executed?
Right, they should be initialized in the zone.
>
> In my case I have 4 memblocks with 1.5GB RAM at 0x4000 0000, 0x4 8000 0000,
> 0x6 0000 0000 and 0x6 8000 0000. None of them has the MEMBLOCK_NOMAP flag set.
All of them should be added into the zone with memmap_init_zone() because none of
them has the flag.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC] gpio: define gpio-init nodes to initialize pins similar to hogs
From: Linus Walleij @ 2019-09-12 9:05 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Bartosz Golaszewski, Linux ARM, Sascha Hauer,
open list:GPIO SUBSYSTEM
In-Reply-To: <20190909105919.30418-1-u.kleine-koenig@pengutronix.de>
On Mon, Sep 9, 2019 at 11:59 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> Sometimes it is handy to be able to easily define a "safe" state for a
> GPIO. This might for example be used to ensure that an ethernet phy is
> properly reset during startup or just that all pins have a defined state
> to minimize leakage current. As such a pin must be requestable (and
> changable) by a device driver, a gpio-hog cannot be used.
>
> So define a GPIO initializer with a syntax identical to a GPIO hog just
> using "gpio-init" as identifier instead of "gpio-hog".
>
> The usage I have in mind (and also implemented in a custom patch stack
> on top of barebox already) is targeting the bootloader and not
> necessarily Linux as such an boot-up initialisation should be done as
> early as possible.
>
> Not-yet-signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> maybe it also makes sense to use "gpio-safe"? Maybe it (then) makes
> sense to reset the gpio in the indicated state after it is released?
>
> Also it might be beneficial to make the wording more explicit in the
> description and for example tell that only one of gpio-hog and gpio-init
> must be provided.
It's no secret that I am in favor of this approach, as I like consistency
with the hogs.
The DT people have been against, as they prefer something like an
initial array of values akin to gpio-names IIRC. But this is a good
time for them to speak up.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] gpio: htc-egpio: Remove unused exported htc_egpio_get_wakeup_irq()
From: Linus Walleij @ 2019-09-12 9:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:GPIO SUBSYSTEM, Russell King, Haojian Zhuang,
linux-kernel@vger.kernel.org, Bartosz Golaszewski, Linux ARM,
Philipp Zabel, Paul Parsons, Robert Jarzmik, Daniel Mack
In-Reply-To: <20190910141529.21030-1-geert+renesas@glider.be>
On Tue, Sep 10, 2019 at 3:15 PM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> This function was never used upstream, and is a relic of the original
> handhelds.org code the htc-egpio driver was based on.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Patch applied.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mfd: mt6360: add pmic mt6360 driver
From: Matthias Brugger @ 2019-09-12 9:13 UTC (permalink / raw)
To: Gene Chen, gene_chen, Wilma.Wu, Lee Jones
Cc: Gene Chen, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <1568275837-3560-1-git-send-email-gene.chen.richtek@gmail.com>
Hi Gene Chen,
Please use ./scripts/get_maintainer.pl to find out which are the maintainer(s)
for a specific series/patch.
I added Lee Jones, who is the maintainer of the MTD subsystem.
Right now I have no time to review the patches, sorry.
Regards,
Matthias
On 12/09/2019 10:10, Gene Chen wrote:
> From: Gene Chen <gene_chen@mediatek.corp-partner.google.com>
>
> ---
> drivers/mfd/Kconfig | 12 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/mt6360-core.c | 463 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 476 insertions(+)
> create mode 100644 drivers/mfd/mt6360-core.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index f129f96..a422c76 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -862,6 +862,18 @@ config MFD_MAX8998
> additional drivers must be enabled in order to use the functionality
> of the device.
>
> +config MFD_MT6360
> + tristate "Mediatek MT6360 SubPMIC"
> + select MFD_CORE
> + select REGMAP_I2C
> + select REGMAP_IRQ
> + depends on I2C
> + help
> + Say Y here to enable MT6360 PMU/PMIC/LDO functional support.
> + PMU part include charger, flashlight, rgb led
> + PMIC part include 2-channel BUCKs and 2-channel LDOs
> + LDO part include 4-channel LDOs
> +
> config MFD_MT6397
> tristate "MediaTek MT6397 PMIC Support"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index f026ada..77a8f0b 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -241,6 +241,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o
> +obj-$(CONFIG_MFD_MT6360) += mt6360-core.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c
> new file mode 100644
> index 0000000..d3580618
> --- /dev/null
> +++ b/drivers/mfd/mt6360-core.c
> @@ -0,0 +1,463 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/version.h>
> +
> +#include <linux/mfd/mt6360.h>
> +#include <linux/mfd/mt6360-private.h>
> +
> +/* reg 0 -> 0 ~ 7 */
> +#define MT6360_CHG_TREG_EVT (4)
> +#define MT6360_CHG_AICR_EVT (5)
> +#define MT6360_CHG_MIVR_EVT (6)
> +#define MT6360_PWR_RDY_EVT (7)
> +/* REG 1 -> 8 ~ 15 */
> +#define MT6360_CHG_BATSYSUV_EVT (9)
> +#define MT6360_FLED_CHG_VINOVP_EVT (11)
> +#define MT6360_CHG_VSYSUV_EVT (12)
> +#define MT6360_CHG_VSYSOV_EVT (13)
> +#define MT6360_CHG_VBATOV_EVT (14)
> +#define MT6360_CHG_VBUSOV_EVT (15)
> +/* REG 2 -> 16 ~ 23 */
> +/* REG 3 -> 24 ~ 31 */
> +#define MT6360_WD_PMU_DET (25)
> +#define MT6360_WD_PMU_DONE (26)
> +#define MT6360_CHG_TMRI (27)
> +#define MT6360_CHG_ADPBADI (29)
> +#define MT6360_CHG_RVPI (30)
> +#define MT6360_OTPI (31)
> +/* REG 4 -> 32 ~ 39 */
> +#define MT6360_CHG_AICCMEASL (32)
> +#define MT6360_CHGDET_DONEI (34)
> +#define MT6360_WDTMRI (35)
> +#define MT6360_SSFINISHI (36)
> +#define MT6360_CHG_RECHGI (37)
> +#define MT6360_CHG_TERMI (38)
> +#define MT6360_CHG_IEOCI (39)
> +/* REG 5 -> 40 ~ 47 */
> +#define MT6360_PUMPX_DONEI (40)
> +#define MT6360_BAT_OVP_ADC_EVT (41)
> +#define MT6360_TYPEC_OTP_EVT (42)
> +#define MT6360_ADC_WAKEUP_EVT (43)
> +#define MT6360_ADC_DONEI (44)
> +#define MT6360_BST_BATUVI (45)
> +#define MT6360_BST_VBUSOVI (46)
> +#define MT6360_BST_OLPI (47)
> +/* REG 6 -> 48 ~ 55 */
> +#define MT6360_ATTACH_I (48)
> +#define MT6360_DETACH_I (49)
> +#define MT6360_QC30_STPDONE (51)
> +#define MT6360_QC_VBUSDET_DONE (52)
> +#define MT6360_HVDCP_DET (53)
> +#define MT6360_CHGDETI (54)
> +#define MT6360_DCDTI (55)
> +/* REG 7 -> 56 ~ 63 */
> +#define MT6360_FOD_DONE_EVT (56)
> +#define MT6360_FOD_OV_EVT (57)
> +#define MT6360_CHRDET_UVP_EVT (58)
> +#define MT6360_CHRDET_OVP_EVT (59)
> +#define MT6360_CHRDET_EXT_EVT (60)
> +#define MT6360_FOD_LR_EVT (61)
> +#define MT6360_FOD_HR_EVT (62)
> +#define MT6360_FOD_DISCHG_FAIL_EVT (63)
> +/* REG 8 -> 64 ~ 71 */
> +#define MT6360_USBID_EVT (64)
> +#define MT6360_APWDTRST_EVT (65)
> +#define MT6360_EN_EVT (66)
> +#define MT6360_QONB_RST_EVT (67)
> +#define MT6360_MRSTB_EVT (68)
> +#define MT6360_OTP_EVT (69)
> +#define MT6360_VDDAOV_EVT (70)
> +#define MT6360_SYSUV_EVT (71)
> +/* REG 9 -> 72 ~ 79 */
> +#define MT6360_FLED_STRBPIN_EVT (72)
> +#define MT6360_FLED_TORPIN_EVT (73)
> +#define MT6360_FLED_TX_EVT (74)
> +#define MT6360_FLED_LVF_EVT (75)
> +#define MT6360_FLED2_SHORT_EVT (78)
> +#define MT6360_FLED1_SHORT_EVT (79)
> +/* REG 10 -> 80 ~ 87 */
> +#define MT6360_FLED2_STRB_EVT (80)
> +#define MT6360_FLED1_STRB_EVT (81)
> +#define MT6360_FLED2_STRB_TO_EVT (82)
> +#define MT6360_FLED1_STRB_TO_EVT (83)
> +#define MT6360_FLED2_TOR_EVT (84)
> +#define MT6360_FLED1_TOR_EVT (85)
> +/* REG 11 -> 88 ~ 95 */
> +/* REG 12 -> 96 ~ 103 */
> +#define MT6360_BUCK1_PGB_EVT (96)
> +#define MT6360_BUCK1_OC_EVT (100)
> +#define MT6360_BUCK1_OV_EVT (101)
> +#define MT6360_BUCK1_UV_EVT (102)
> +/* REG 13 -> 104 ~ 111 */
> +#define MT6360_BUCK2_PGB_EVT (104)
> +#define MT6360_BUCK2_OC_EVT (108)
> +#define MT6360_BUCK2_OV_EVT (109)
> +#define MT6360_BUCK2_UV_EVT (110)
> +/* REG 14 -> 112 ~ 119 */
> +#define MT6360_LDO1_OC_EVT (113)
> +#define MT6360_LDO2_OC_EVT (114)
> +#define MT6360_LDO3_OC_EVT (115)
> +#define MT6360_LDO5_OC_EVT (117)
> +#define MT6360_LDO6_OC_EVT (118)
> +#define MT6360_LDO7_OC_EVT (119)
> +/* REG 15 -> 120 ~ 127 */
> +#define MT6360_LDO1_PGB_EVT (121)
> +#define MT6360_LDO2_PGB_EVT (122)
> +#define MT6360_LDO3_PGB_EVT (123)
> +#define MT6360_LDO5_PGB_EVT (125)
> +#define MT6360_LDO6_PGB_EVT (126)
> +#define MT6360_LDO7_PGB_EVT (127)
> +
> +#define MT6360_REGMAP_IRQ_REG(_irq_evt) \
> + REGMAP_IRQ_REG(_irq_evt, (_irq_evt) / 8, BIT((_irq_evt) % 8))
> +
> +#define MT6360_MFD_CELL(_name) \
> + { \
> + .name = #_name, \
> + .of_compatible = "mediatek," #_name, \
> + .num_resources = ARRAY_SIZE(_name##_resources), \
> + .resources = _name##_resources, \
> + }
> +
> +static const struct regmap_irq mt6360_pmu_irqs[] = {
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_TREG_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_AICR_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_MIVR_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_PWR_RDY_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_BATSYSUV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED_CHG_VINOVP_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_VSYSUV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_VSYSOV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_VBATOV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_VBUSOV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_WD_PMU_DET),
> + MT6360_REGMAP_IRQ_REG(MT6360_WD_PMU_DONE),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_TMRI),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_ADPBADI),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_RVPI),
> + MT6360_REGMAP_IRQ_REG(MT6360_OTPI),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_AICCMEASL),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHGDET_DONEI),
> + MT6360_REGMAP_IRQ_REG(MT6360_WDTMRI),
> + MT6360_REGMAP_IRQ_REG(MT6360_SSFINISHI),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_RECHGI),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_TERMI),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_IEOCI),
> + MT6360_REGMAP_IRQ_REG(MT6360_PUMPX_DONEI),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHG_TREG_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_BAT_OVP_ADC_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_TYPEC_OTP_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_ADC_WAKEUP_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_ADC_DONEI),
> + MT6360_REGMAP_IRQ_REG(MT6360_BST_BATUVI),
> + MT6360_REGMAP_IRQ_REG(MT6360_BST_VBUSOVI),
> + MT6360_REGMAP_IRQ_REG(MT6360_BST_OLPI),
> + MT6360_REGMAP_IRQ_REG(MT6360_ATTACH_I),
> + MT6360_REGMAP_IRQ_REG(MT6360_DETACH_I),
> + MT6360_REGMAP_IRQ_REG(MT6360_QC30_STPDONE),
> + MT6360_REGMAP_IRQ_REG(MT6360_QC_VBUSDET_DONE),
> + MT6360_REGMAP_IRQ_REG(MT6360_HVDCP_DET),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHGDETI),
> + MT6360_REGMAP_IRQ_REG(MT6360_DCDTI),
> + MT6360_REGMAP_IRQ_REG(MT6360_FOD_DONE_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FOD_OV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHRDET_UVP_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHRDET_OVP_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_CHRDET_EXT_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FOD_LR_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FOD_HR_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FOD_DISCHG_FAIL_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_USBID_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_APWDTRST_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_EN_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_QONB_RST_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_MRSTB_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_OTP_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_VDDAOV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_SYSUV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED_STRBPIN_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED_TORPIN_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED_TX_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED_LVF_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED2_SHORT_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED1_SHORT_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED2_STRB_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED1_STRB_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED2_STRB_TO_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED1_STRB_TO_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED2_TOR_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_FLED1_TOR_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_BUCK1_PGB_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_BUCK1_OC_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_BUCK1_OV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_BUCK1_UV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_BUCK2_PGB_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_BUCK2_OC_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_BUCK2_OV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_BUCK2_UV_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO1_OC_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO2_OC_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO3_OC_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO5_OC_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO6_OC_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO7_OC_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO1_PGB_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO2_PGB_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO3_PGB_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO5_PGB_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO6_PGB_EVT),
> + MT6360_REGMAP_IRQ_REG(MT6360_LDO7_PGB_EVT),
> +};
> +
> +static int mt6360_pmu_handle_post_irq(void *irq_drv_data)
> +{
> + struct mt6360_pmu_info *mpi = irq_drv_data;
> +
> + return regmap_update_bits(mpi->regmap,
> + MT6360_PMU_IRQ_SET, MT6360_IRQ_RETRIG, MT6360_IRQ_RETRIG);
> +}
> +
> +static const struct regmap_irq_chip mt6360_pmu_irq_chip = {
> + .irqs = mt6360_pmu_irqs,
> + .num_irqs = ARRAY_SIZE(mt6360_pmu_irqs),
> + .num_regs = MT6360_PMU_IRQ_REGNUM,
> + .mask_base = MT6360_PMU_CHG_MASK1,
> + .status_base = MT6360_PMU_CHG_IRQ1,
> + .ack_base = MT6360_PMU_CHG_IRQ1,
> + .init_ack_masked = true,
> + .use_ack = true,
> + .handle_post_irq = mt6360_pmu_handle_post_irq,
> +};
> +
> +static const struct regmap_config mt6360_pmu_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = MT6360_PMU_MAXREG,
> +};
> +
> +static const struct resource mt6360_adc_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_ADC_DONEI, "adc_donei"),
> +};
> +
> +static const struct resource mt6360_chg_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TREG_EVT, "chg_treg_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_PWR_RDY_EVT, "pwr_rdy_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_BATSYSUV_EVT, "chg_batsysuv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSUV_EVT, "chg_vsysuv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSOV_EVT, "chg_vsysov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBATOV_EVT, "chg_vbatov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBUSOV_EVT, "chg_vbusov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_AICCMEASL, "chg_aiccmeasl"),
> + DEFINE_RES_IRQ_NAMED(MT6360_WDTMRI, "wdtmri"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_RECHGI, "chg_rechgi"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TERMI, "chg_termi"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_IEOCI, "chg_ieoci"),
> + DEFINE_RES_IRQ_NAMED(MT6360_PUMPX_DONEI, "pumpx_donei"),
> + DEFINE_RES_IRQ_NAMED(MT6360_ATTACH_I, "attach_i"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHRDET_EXT_EVT, "chrdet_ext_evt"),
> +};
> +
> +static const struct resource mt6360_led_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED_CHG_VINOVP_EVT, "fled_chg_vinovp_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED_LVF_EVT, "fled_lvf_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_SHORT_EVT, "fled2_short_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_SHORT_EVT, "fled1_short_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_STRB_TO_EVT, "fled2_strb_to_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_STRB_TO_EVT, "fled1_strb_to_evt"),
> +};
> +
> +static const struct resource mt6360_pmic_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_PGB_EVT, "buck1_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OC_EVT, "buck1_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OV_EVT, "buck1_ov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_UV_EVT, "buck1_uv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_PGB_EVT, "buck2_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OC_EVT, "buck2_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OV_EVT, "buck2_ov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_UV_EVT, "buck2_uv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_OC_EVT, "ldo6_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_OC_EVT, "ldo7_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_PGB_EVT, "ldo6_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_PGB_EVT, "ldo7_pgb_evt"),
> +};
> +
> +static const struct resource mt6360_ldo_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_OC_EVT, "ldo1_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_OC_EVT, "ldo2_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_OC_EVT, "ldo3_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_OC_EVT, "ldo5_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_PGB_EVT, "ldo1_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_PGB_EVT, "ldo2_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_PGB_EVT, "ldo3_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_PGB_EVT, "ldo5_pgb_evt"),
> +};
> +
> +static const struct mfd_cell mt6360_devs[] = {
> + MT6360_MFD_CELL(mt6360_adc),
> + MT6360_MFD_CELL(mt6360_chg),
> + MT6360_MFD_CELL(mt6360_led),
> + MT6360_MFD_CELL(mt6360_pmic),
> + MT6360_MFD_CELL(mt6360_ldo),
> + /* tcpc dev */
> + {
> + .name = "mt6360_tcpc",
> + .of_compatible = "mediatek,mt6360_tcpc",
> + },
> +};
> +
> +static const unsigned short mt6360_slave_addr[MT6360_SLAVE_MAX] = {
> + MT6360_PMU_SLAVEID,
> + MT6360_PMIC_SLAVEID,
> + MT6360_LDO_SLAVEID,
> + MT6360_TCPC_SLAVEID,
> +};
> +
> +static int mt6360_pmu_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct mt6360_pmu_info *mpi;
> + unsigned int reg_data = 0;
> + int i, ret;
> +
> + mpi = devm_kzalloc(&client->dev, sizeof(*mpi), GFP_KERNEL);
> + if (!mpi)
> + return -ENOMEM;
> + mpi->dev = &client->dev;
> + i2c_set_clientdata(client, mpi);
> +
> + /* regmap regiser */
> + mpi->regmap = devm_regmap_init_i2c(client, &mt6360_pmu_regmap_config);
> + if (IS_ERR(mpi->regmap)) {
> + dev_err(&client->dev, "regmap register fail\n");
> + return PTR_ERR(mpi->regmap);
> + }
> + /* chip id check */
> + ret = regmap_read(mpi->regmap, MT6360_PMU_DEV_INFO, ®_data);
> + if (ret < 0) {
> + dev_err(&client->dev, "device not found\n");
> + return ret;
> + }
> + if ((reg_data & CHIP_VEN_MASK) != CHIP_VEN_MT6360) {
> + dev_err(&client->dev, "not mt6360 chip\n");
> + return -ENODEV;
> + }
> + mpi->chip_rev = reg_data & CHIP_REV_MASK;
> + /* irq register */
> + memcpy(&mpi->irq_chip, &mt6360_pmu_irq_chip, sizeof(mpi->irq_chip));
> + mpi->irq_chip.name = dev_name(&client->dev);
> + mpi->irq_chip.irq_drv_data = mpi;
> + ret = devm_regmap_add_irq_chip(&client->dev, mpi->regmap, client->irq,
> + IRQF_TRIGGER_FALLING, 0, &mpi->irq_chip,
> + &mpi->irq_data);
> + if (ret < 0) {
> + dev_err(&client->dev, "regmap irq chip add fail\n");
> + return ret;
> + }
> + /* new i2c slave device */
> + for (i = 0; i < MT6360_SLAVE_MAX; i++) {
> + if (mt6360_slave_addr[i] == client->addr) {
> + mpi->i2c[i] = client;
> + continue;
> + }
> + mpi->i2c[i] = i2c_new_dummy(client->adapter,
> + mt6360_slave_addr[i]);
> + if (!mpi->i2c[i]) {
> + dev_err(&client->dev, "new i2c dev [%d] fail\n", i);
> + ret = -ENODEV;
> + goto out;
> + }
> + i2c_set_clientdata(mpi->i2c[i], mpi);
> + }
> + /* mfd cell register */
> + ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO,
> + mt6360_devs, ARRAY_SIZE(mt6360_devs), NULL,
> + 0, regmap_irq_get_domain(mpi->irq_data));
> + if (ret < 0) {
> + dev_err(&client->dev, "mfd add cells fail\n");
> + goto out;
> + }
> + dev_info(&client->dev, "Successfully probed\n");
> + return 0;
> +out:
> + while (--i >= 0) {
> + if (mpi->i2c[i]->addr == client->addr)
> + continue;
> + i2c_unregister_device(mpi->i2c[i]);
> + }
> + return ret;
> +}
> +
> +static int mt6360_pmu_remove(struct i2c_client *client)
> +{
> + struct mt6360_pmu_info *mpi = i2c_get_clientdata(client);
> + int i;
> +
> + for (i = 0; i < MT6360_SLAVE_MAX; i++) {
> + if (mpi->i2c[i]->addr == client->addr)
> + continue;
> + i2c_unregister_device(mpi->i2c[i]);
> + }
> + return 0;
> +}
> +
> +static int __maybe_unused mt6360_pmu_suspend(struct device *dev)
> +{
> + struct i2c_client *i2c = to_i2c_client(dev);
> +
> + if (device_may_wakeup(dev))
> + enable_irq_wake(i2c->irq);
> + return 0;
> +}
> +
> +static int __maybe_unused mt6360_pmu_resume(struct device *dev)
> +{
> +
> + struct i2c_client *i2c = to_i2c_client(dev);
> +
> + if (device_may_wakeup(dev))
> + disable_irq_wake(i2c->irq);
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(mt6360_pmu_pm_ops,
> + mt6360_pmu_suspend, mt6360_pmu_resume);
> +
> +static const struct of_device_id __maybe_unused mt6360_pmu_of_id[] = {
> + { .compatible = "mediatek,mt6360_pmu", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mt6360_pmu_of_id);
> +
> +static const struct i2c_device_id mt6360_pmu_id[] = {
> + { "mt6360_pmu", 0 },
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, mt6360_pmu_id);
> +
> +static struct i2c_driver mt6360_pmu_driver = {
> + .driver = {
> + .name = "mt6360_pmu",
> + .owner = THIS_MODULE,
> + .pm = &mt6360_pmu_pm_ops,
> + .of_match_table = of_match_ptr(mt6360_pmu_of_id),
> + },
> + .probe = mt6360_pmu_probe,
> + .remove = mt6360_pmu_remove,
> + .id_table = mt6360_pmu_id,
> +};
> +module_i2c_driver(mt6360_pmu_driver);
> +
> +MODULE_AUTHOR("CY_Huang <cy_huang@richtek.com>");
> +MODULE_DESCRIPTION("MT6360 PMU I2C Driver");
> +MODULE_LICENSE("GPL");
> +MODULE_VERSION("1.0.0");
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] arm64: Kconfig: Fix VEXPRESS driver dependencies
From: Arnd Bergmann @ 2019-09-12 9:17 UTC (permalink / raw)
To: Amit Kucheria
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, linux-clk, linux-kernel@vger.kernel.org,
Kishon Vijay Abraham I, Bartosz Golaszewski, arm-soc, Mark Brown,
Sebastian Reichel, Will Deacon, Michael Turquette, Linux ARM
In-Reply-To: <8f539b28c25d22b8f515c131cd6b24c309f7ca90.1568239378.git.amit.kucheria@linaro.org>
On Thu, Sep 12, 2019 at 12:19 AM Amit Kucheria <amit.kucheria@linaro.org> wrote:
>
> Push various VEXPRESS drivers behind ARCH_VEXPRESS dependency so that it
> doesn't get enabled by default on other platforms.
>
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
> drivers/bus/Kconfig | 2 +-
> drivers/clk/versatile/Kconfig | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index d80e8d70bf10..b2b1beee9953 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -166,7 +166,7 @@ config UNIPHIER_SYSTEM_BUS
>
> config VEXPRESS_CONFIG
> bool "Versatile Express configuration bus"
> - default y if ARCH_VEXPRESS
> + depends on ARCH_VEXPRESS
> depends on ARM || ARM64
> depends on OF
Removing the 'default y' breaks existing defconfig files,
Adding the 'depends on ARCH_VEXPRESS' unnecessarily limits
compile-testing. I'd rather extend it to other architectures than
limit it to builds that have vexpress enabled.
> diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
> index ac766855ba16..826750292c1e 100644
> --- a/drivers/clk/versatile/Kconfig
> +++ b/drivers/clk/versatile/Kconfig
> @@ -5,8 +5,8 @@ config ICST
> config COMMON_CLK_VERSATILE
> bool "Clock driver for ARM Reference designs"
> depends on ARCH_INTEGRATOR || ARCH_REALVIEW || \
> - ARCH_VERSATILE || ARCH_VEXPRESS || ARM64 || \
> - COMPILE_TEST
> + ARCH_VERSATILE || ARCH_VEXPRESS || COMPILE_TEST
> + depends on ARM64
It's definitely wrong to limit this to 64 bit.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] arm64: Kconfig: Fix EXYNOS driver dependencies
From: Arnd Bergmann @ 2019-09-12 9:19 UTC (permalink / raw)
To: Amit Kucheria
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, linux-clk, linux-kernel@vger.kernel.org,
Kishon Vijay Abraham I, Bartosz Golaszewski, arm-soc, Mark Brown,
Sebastian Reichel, Will Deacon, Michael Turquette, Linux ARM
In-Reply-To: <79755cb29b8c23709e346b5dd290481a36627648.1568239378.git.amit.kucheria@linaro.org>
On Thu, Sep 12, 2019 at 12:19 AM Amit Kucheria <amit.kucheria@linaro.org> wrote:
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 9b2790d3f18a..bdf164a7a7c5 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -194,6 +194,7 @@ config COMMON_CLK_ASPEED
>
> config COMMON_CLK_S2MPS11
> tristate "Clock driver for S2MPS1X/S5M8767 MFD"
> + depends on ARCH_EXYNOS
> depends on MFD_SEC_CORE || COMPILE_TEST
> ---help---
> This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
This breaks compile-testing on non-ARM targets.
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index b57093d7c01f..a4c4f01343fd 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -797,6 +797,7 @@ config REGULATOR_S2MPA01
>
> config REGULATOR_S2MPS11
> tristate "Samsung S2MPS11/13/14/15/S2MPU02 voltage regulator"
> + depends on ARCH_EXYNOS
> depends on MFD_SEC_CORE
> help
> This driver supports a Samsung S2MPS11/13/14/15/S2MPU02 voltage
Same here. What you could do instead is add
depends on ARCH_EXYNOS || COMPILE_TEST
to MFD_SEC_CORE, this would then propagate to these
two drivers as well.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Michal Hocko @ 2019-09-12 9:19 UTC (permalink / raw)
To: Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, Mel Gorman, ying.huang, Rik van Riel,
Konrad Rzeszutek Wilk, Vlastimil Babka, Dan Williams,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal, Dave Hansen,
LKML, Paolo Bonzini, Andrew Morton, Fengguang Wu,
Kirill A. Shutemov
In-Reply-To: <CAKgT0UfOp1c+ov=3pBD72EkSB9Vm7mG5G6zJj4=j=UH7zCgg2Q@mail.gmail.com>
On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > [...]
> > > We don't put any limitations on the allocator other then that it needs to
> > > clean up the metadata on allocation, and that it cannot allocate a page
> > > that is in the process of being reported since we pulled it from the
> > > free_list. If the page is a "Reported" page then it decrements the
> > > reported_pages count for the free_area and makes sure the page doesn't
> > > exist in the "Boundary" array pointer value, if it does it moves the
> > > "Boundary" since it is pulling the page.
> >
> > This is still a non-trivial limitation on the page allocation from an
> > external code IMHO. I cannot give any explicit reason why an ordering on
> > the free list might matter (well except for page shuffling which uses it
> > to make physical memory pattern allocation more random) but the
> > architecture seems hacky and dubious to be honest. It shoulds like the
> > whole interface has been developed around a very particular and single
> > purpose optimization.
>
> How is this any different then the code that moves a page that will
> likely be merged to the tail though?
I guess you are referring to the page shuffling. If that is the case
then this is an integral part of the allocator for a reason and it is
very well obvious in the code including the consequences. I do not
really like an idea of hiding similar constrains behind a generic
looking feature which is completely detached from the allocator and so
any future change of the allocator might subtly break it.
> In our case the "Reported" page is likely going to be much more
> expensive to allocate and use then a standard page because it will be
> faulted back in. In such a case wouldn't it make sense for us to want
> to keep the pages that don't require faults ahead of those pages in
> the free_list so that they are more likely to be allocated?
OK, I was suspecting this would pop out. And this is exactly why I
didn't like an idea of an external code imposing a non obvious constrains
to the allocator. You simply cannot count with any ordering with the
page allocator. We used to distinguish cache hot/cold pages in the past
and pushed pages to the specific end of the free list but that has been
removed. There are other potential changes like that possible. Shuffling
is a good recent example.
Anyway I am not a maintainer of this code. I would really like to hear
opinions from Mel and Vlastimil here (now CCed - the thread starts
http://lkml.kernel.org/r/20190907172225.10910.34302.stgit@localhost.localdomain.
--
Michal Hocko
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] arm64: Kconfig: Fix BRCMSTB driver dependencies
From: Arnd Bergmann @ 2019-09-12 9:20 UTC (permalink / raw)
To: Amit Kucheria
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, Linux PM list, linux-kernel@vger.kernel.org,
Kishon Vijay Abraham I, Bartosz Golaszewski, arm-soc, Mark Brown,
Sebastian Reichel, Will Deacon, Michael Turquette, Linux ARM
In-Reply-To: <21b9dd0bf0bbc80b69bc81a7efb88243e4981c56.1568239378.git.amit.kucheria@linaro.org>
On Thu, Sep 12, 2019 at 12:19 AM Amit Kucheria <amit.kucheria@linaro.org> wrote:
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 1851112ccc29..d80e8d70bf10 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -22,6 +22,7 @@ config ARM_CCI400_PORT_CTRL
>
> config BRCMSTB_GISB_ARB
> bool "Broadcom STB GISB bus arbiter"
> + depends on ARCH_BRCMSTB
> depends on ARM || ARM64 || MIPS
> default ARCH_BRCMSTB || BMIPS_GENERIC
> help
This breaks MIPS configurations that need this driver, and
it breask compile-testing on non-ARM/MIPS targets.
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index 651b763f80cd..6f0b1ed1a05a 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -59,6 +59,7 @@ config POWER_RESET_BRCMKONA
>
> config POWER_RESET_BRCMSTB
> bool "Broadcom STB reset driver"
> + depends on ARCH_BRCMSTB
> depends on ARM || ARM64 || MIPS || COMPILE_TEST
> depends on MFD_SYSCON
> default ARCH_BRCMSTB || BMIPS_GENERIC
Same here and below.
> diff --git a/drivers/soc/bcm/Kconfig b/drivers/soc/bcm/Kconfig
> index 648e32693b7e..5a8ff33241ae 100644
> --- a/drivers/soc/bcm/Kconfig
> +++ b/drivers/soc/bcm/Kconfig
> @@ -24,6 +24,7 @@ config RASPBERRYPI_POWER
>
> config SOC_BRCMSTB
> bool "Broadcom STB SoC drivers"
> + depends on ARCH_BRCMSTB
> depends on ARM || ARM64 || BMIPS_GENERIC || COMPILE_TEST
> select SOC_BUS
> help
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] arm64: Kconfig: Fix XGENE driver dependencies
From: Arnd Bergmann @ 2019-09-12 9:23 UTC (permalink / raw)
To: Amit Kucheria
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, Linux PM list, linux-clk,
linux-kernel@vger.kernel.org, linux-pci, Kishon Vijay Abraham I,
Bartosz Golaszewski, arm-soc, Mark Brown,
open list:GPIO SUBSYSTEM, Sebastian Reichel, Will Deacon,
Michael Turquette, Linux ARM
In-Reply-To: <f6cefef2bf6b34ec6eb82d3614054734fa5e8dd1.1568239378.git.amit.kucheria@linaro.org>
On Thu, Sep 12, 2019 at 12:19 AM Amit Kucheria <amit.kucheria@linaro.org> wrote:
>
> Push various XGENE drivers behind ARCH_XGENE dependency so that it
> doesn't get enabled by default on other platforms.
>
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
> arch/arm64/Kconfig.platforms | 3 +++
> drivers/clk/Kconfig | 2 +-
> drivers/gpio/Kconfig | 1 +
> drivers/pci/controller/Kconfig | 1 +
> drivers/phy/Kconfig | 1 +
> drivers/power/reset/Kconfig | 2 +-
> 6 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 4778c775de1b..cdf4e452e34c 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -281,6 +281,9 @@ config ARCH_VULCAN
>
> config ARCH_XGENE
> bool "AppliedMicro X-Gene SOC Family"
> + select COMMON_CLK_XGENE
> + select PCI_XGENE
> + select GPIO_XGENE
> help
> This enables support for AppliedMicro X-Gene SOC Family
I'd rather not 'select' drivers that might be optional, the 'default y'
should be sufficient as long as it's in theory possible to have
them disabled or as loadable modules.
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 801fa1cd0321..9b2790d3f18a 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -225,7 +225,7 @@ config CLK_QORIQ
>
> config COMMON_CLK_XGENE
> bool "Clock driver for APM XGene SoC"
> - default ARCH_XGENE
> + depends on ARCH_XGENE
> depends on ARM64 || COMPILE_TEST
> ---help---
> Sypport for the APM X-Gene SoC reference, PLL, and device clocks.
This breaks compile-testing, and existing defconfigs
that don't list the driver.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Michal Hocko @ 2019-09-12 9:26 UTC (permalink / raw)
To: David Hildenbrand
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <ef460202-cebd-c6d2-19f3-e8a82a3d3cbd@redhat.com>
On Thu 12-09-19 09:47:30, David Hildenbrand wrote:
> On 12.09.19 09:16, Michal Hocko wrote:
> > On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
> >> On 11.09.19 15:51, Michal Hocko wrote:
> >>> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
> >>> [...]
> >>>>> 4. Continuously report, not the "one time report everything" approach.
> >>>>
> >>>> So you mean the allocator reporting this rather than an external code to
> >>>> poll right? I do not know, how much this is nice to have than must have?
> >>>
> >>> Another idea that I haven't really thought through so it might turned
> >>> out to be completely bogus but let's try anyway. Your "report everything"
> >>> just made me look and realize that free_pages_prepare already performs
> >>> stuff that actually does something similar yet unrelated.
> >>>
> >>> We do report to special page poisoning, zeroying or
> >>> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
> >>> space. This sounds like something fitting your model no?
> >>>
> >>
> >> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
> >> don't quite see yet how that would help to remember if a page was
> >> already reported.
> >
> > Do you still have to differ that state when each page is reported?
>
> Ah, very good point. I can see that the reason for this was not
> discussed in this thread so far. (Alexander, Nitesh, please correct me
> if I am wrong). It's buried in the long history of free page
> hinting/reporting.
It would really be preferable to summarize such a previous discussion
ideally with some references.
> Some early patch sets tried to report during every free synchronously.
> Free a page, report them to the hypervisor. This resulted in some issues
> (especially, locking-related and the virtio + the hypervisor being
> involved, resulting in unpredictable delays, quite some overhead ...).
> It was no good.
>
> One design decision then was to not report single pages, but a bunch of
> pages at once. This made it necessary to "remember" the pages to be
> reported and to temporarily block them from getting allocated while
> reporting.
>
> Nitesh implemented (at least) two "capture PFNs of free pages in an
> array when freeing" approaches. One being synchronous from the freeing
> CPU once the list was full (having similar issues as plain synchronous
> reporting) and one being asynchronous by a separate thread (which solved
> many locking issues).
>
> Turned out the a simple array can quickly lead to us having to drop
> "reports" to the hypervisor because the array is full and the reporting
> thread was not able to keep up. Not good as well. Especially, if some
> process frees a lot of memory this can happen quickly and Nitesh wa
> sable to trigger this scenario frequently.
>
> Finally, Nitesh decided to use the bitmap instead to keep track of pages
> to report. I'd like to note that this approach could still be combined
> with an "array of potentially free PFNs". Only when the array/circular
> buffer runs out of entries ("reporting thread cannot keep up"), we would
> have to go back to scanning the bitmap.
>
> That was also the point where Alexander decided to look into integrating
> tracking/handling reported/unreported pages directly in the buddy.
OK, this gives at least some background which is really appreciated.
Explaining _why_ you need something in the core MM is essential to move
forward.
> >> After reporting the page we would have to switch some
> >> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.
> >
> > Yes, you can either store the state somewhere.
> >
> >> Of course, we could map the page and treat that as "the state" when we
> >> reported it, but I am not sure that's such a good idea :)
> >>
> >> As always, I might be very wrong ...
> >
> > I still do not fully understand the usecase so I might be equally wrong.
> > My thinking is along these lines. Why should you scan free pages when
> > you can effectively capture each freed page? If you go one step further
> > then post_alloc_hook would be the counterpart to know that your page has
> > been allocated.
>
> I'd like to note that Nitesh's patch set contains the following hunk,
> which is roughly what you were thinking :)
>
>
> -static inline void __free_one_page(struct page *page,
> +inline void __free_one_page(struct page *page,
> unsigned long pfn,
> struct zone *zone, unsigned int order,
> - int migratetype)
> + int migratetype, bool hint)
> {
> unsigned long combined_pfn;
> unsigned long uninitialized_var(buddy_pfn);
> @@ -980,7 +981,8 @@ static inline void __free_one_page(struct page *page,
> migratetype);
> else
> add_to_free_area(page, &zone->free_area[order], migratetype);
> -
> + if (hint)
> + page_hinting_enqueue(page, order);
> }
>
>
> (ignore the hint parameter, when he would switch to a isolate vs.
> alloc/free, that can go away and all we left is the enqueue part)
>
>
> Inside that callback we can remember the pages any way we want. Right
> now in a bitmap. Maybe later in a array + bitmap (as discussed above).
> Another idea I had was to simply go over all pages and report them when
> running into this "array full" condition. But I am not yet sure about
> the performance implications on rather large machines. So the bitmap
> idea might have some other limitations but seems to do its job.
>
> Hoe that makes things clearer and am not missing something.
It certainly helped me to get a better idea. I have commented on my
reservations regarding the approach in this thread elsewhere but at
least I _think_ I am getting a point of what you guys try to achieve.
Thanks!
--
Michal Hocko
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/4] Cleanup arm64 driver dependencies
From: Arnd Bergmann @ 2019-09-12 9:29 UTC (permalink / raw)
To: Amit Kucheria
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, Linux PM list, linux-clk,
linux-kernel@vger.kernel.org, linux-pci, Kishon Vijay Abraham I,
Bartosz Golaszewski, arm-soc, Mark Brown,
open list:GPIO SUBSYSTEM, Sebastian Reichel, Will Deacon,
Michael Turquette, Linux ARM
In-Reply-To: <cover.1568239378.git.amit.kucheria@linaro.org>
On Thu, Sep 12, 2019 at 12:18 AM Amit Kucheria <amit.kucheria@linaro.org> wrote:
>
> I was using initcall_debugging on a QCOM platform and ran across a bunch of
> driver initcalls that are enabled even if their SoC support is disabled.
>
> Here are some fixups for a subset of them.
The idea seems reasonable, disabling a platform may just turn off
all the drivers that are not useful elsewhere, but there are mistakes
in a lot of your changes, so I'm certainly not applying these for 5.4.
Generally speaking, the way that works best is
config SUBSYS_DRIVER_FOO
tristate "SUBSYS support for FOO platform"
depends on ARCH_FOO || COMPILE_TEST
depends on SUBSYS
default "m" if ARCH_FOO
This means it's enabled as a loadable module by default (use
default "y" instead where necessary) as long as the platform
is enabled, but an x86 allmodconfig build also includes it
because of COMPILE_TEST, while any configuration without
ARCH_FOO that is not compile-testing cannot enable it.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] arm64: Kconfig: Fix EXYNOS driver dependencies
From: Mark Brown @ 2019-09-12 9:32 UTC (permalink / raw)
To: Amit Kucheria
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, linux-clk, linux-kernel, Kishon Vijay Abraham I,
Bartosz Golaszewski, arm, Sebastian Reichel, Will Deacon,
Michael Turquette, linux-arm-kernel
In-Reply-To: <79755cb29b8c23709e346b5dd290481a36627648.1568239378.git.amit.kucheria@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 704 bytes --]
On Thu, Sep 12, 2019 at 03:48:48AM +0530, Amit Kucheria wrote:
> Push various EXYNOS drivers behind ARCH_EXYNOS dependency so that it
> doesn't get enabled by default on other platforms.
> config REGULATOR_S2MPS11
> tristate "Samsung S2MPS11/13/14/15/S2MPU02 voltage regulator"
> + depends on ARCH_EXYNOS
> depends on MFD_SEC_CORE
> help
> This driver supports a Samsung S2MPS11/13/14/15/S2MPU02 voltage
This doesn't match the changelog at all. This driver is not
enabled by default since it's just a normal tristate, they are
disabled by default. As far as I can see all this change will
do is reduce our build test coverage by adding an artificial
dependency without an || COMPILE_TEST.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 1/2] arm64: dts: exynos: Pull for v5.4
From: Krzysztof Kozlowski @ 2019-09-12 9:35 UTC (permalink / raw)
To: Arnd Bergmann, Marek Szyprowski
Cc: DTML, moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES,
linux-kernel@vger.kernel.org, SoC Team, arm-soc, Kukjin Kim,
Olof Johansson, Linux ARM
In-Reply-To: <CAJKOXPcOSvc2DfoN+7Tca=t5dSm3RcKqmm06AfR0PAVBeY=GvQ@mail.gmail.com>
On Thu, 12 Sep 2019 at 08:32, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Wed, 11 Sep 2019 at 23:07, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Wed, Sep 11, 2019 at 8:36 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > Hi,
> > >
> > > Unfortunately the patches were applied right after closing the linux-next.
> >
> > Hi Krzysztof,
> >
> > I took a look at these and am not convinced this is right:
> >
> > > 1. Fix boot of Exynos7 due to wrong address/size of memory node,
> >
> > The current state is clearly broken and a fix is needed, but
> > I'm not sure this is the right fix. Why do you have 32-bit physical
> > addressing on a 64-bit chip? I looked at commit ef72171b3621
> > that introduced it, and it seems it would be better to just
> > revert back to 64-bit addresses.
>
> We discussed with Marek Szyprowski that either we can go back to
> 64-bit addressing or stick to 32. There are not known boards with more
> than 4 GB of RAM so from this point of view the choice was irrelevant.
> At the end of discussion I mentioned to stick with other arm64 boards
> (although not all), so revert to have 64 bit address... but Marek
> chosen differently. Since you ask, let's go back with revert.
>
> >
> > > 2. Move GPU under /soc node,
> >
> > No problem
> >
> > > 3. Minor cleanup of #address-cells.
> >
> > IIRC, an interrupt-controller is required to have a #address-cells
> > property, even if that is normally zero. I don't remember the
> > details, but the gic binding lists it as mandatory, and I think
> > the PCI interrupt-map relies on it. I would just drop this patch.
>
> Indeed, binding requires both address and size cells. I'll drop it.
Short update: no, address-cells are not required by bindings. They are
optional. In case of lack of them, the parent address-cells will be
used so effectively this patch was changing it from 0 to 1. Anyway
this was not expressed in commit msg so I'll drop it.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: crypto: Add DT bindings documentation for sun8i-ce Crypto Engine
From: Maxime Ripard @ 2019-09-12 9:37 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190911183158.GA8264@Red>
[-- Attachment #1.1: Type: text/plain, Size: 2452 bytes --]
Hi Corentin,
On Wed, Sep 11, 2019 at 08:31:58PM +0200, Corentin Labbe wrote:
> On Sat, Sep 07, 2019 at 07:01:16AM +0300, Maxime Ripard wrote:
> > On Fri, Sep 06, 2019 at 08:45:45PM +0200, Corentin Labbe wrote:
> > > This patch adds documentation for Device-Tree bindings for the
> > > Crypto Engine cryptographic accelerator driver.
> > >
> > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > ---
> > > .../bindings/crypto/allwinner,sun8i-ce.yaml | 84 +++++++++++++++++++
> > > 1 file changed, 84 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
> [...]
> > > +else:
> > > + clocks:
> > > + items:
> > > + - description: Bus clock
> > > + - description: Module clock
> > > +
> > > + clock-names:
> > > + items:
> > > + - const: ahb
> > > + - const: mod
> > > +
> > > + resets:
> > > + maxItems: 1
> > > +
> > > + reset-names:
> > > + const: ahb
> >
> > This prevents the usage of the additionalProperties property, which
> > you should really use.
> >
> > What you can do instead is moving the clocks and clock-names
> > description under properties, with a minItems of 2 and a maxItems of
> > 3. Then you can restrict the length of that property to either 2 or 3
> > depending on the case here.
> >
>
> Hello
>
> I fail to do this.
> I do the following (keeped only clock stuff)
> properties:
>
> clocks:
> items:
> - description: Bus clock
> - description: Module clock
> - description: MBus clock
Add minItems: 2 and maxItems: 3 at the same level than items
>
> clock-names:
> items:
> - const: ahb
> - const: mod
> - const: mbus
And here as well
Something I missed earlier though was that we've tried to unify as
much as possible the ahb / apb / axi clocks around the bus name, it
would be great if you could do it.
>
> if:
> properties:
> compatible:
> items:
> const: allwinner,sun50i-h6-crypto
> then:
> properties:
> clocks:
> minItems: 3
> maxItems: 3
> clock-names:
> minItems: 3
> maxItems: 3
You don't need to duplicate the min and maxItems here
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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