* RE: [EXT] Re: SCMI & Devfreq
From: Sujeet Kumar Baranwal @ 2019-09-18 22:53 UTC (permalink / raw)
To: Sudeep Holla; +Cc: linux-arm-kernel@lists.infradead.org
In-Reply-To: <BYAPR18MB2438DC4E8CA4E90455F0345BAF8C0@BYAPR18MB2438.namprd18.prod.outlook.com>
Sudeep, One trivial question wrt SCMI-CPUFREQ framework.
The SCMI perf protocol would tell what are different frequencies the platform support in the beginning.
For example, the command :
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
shows:
280000 560000 840000 1120000 1400000 1820000 1960000 2240000 2520000 2800000
/* Attempt to change the frequency */
~ # echo 2240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
It works.
But in a scenario, where user tries a number which is not listed, SCP applies its own logic to get a nearby value frequency for CPU and returns.
My question is that could we add some print message in kernel that user wish is not exactly fulfilled, an approximation has been done so the user explicitly knows his command has been partially met. If this to happen, a patch might be needed in kernel. What is your opinion?
Regards
Sujeet
-----Original Message-----
From: Sujeet Kumar Baranwal
Sent: Monday, September 16, 2019 10:37 AM
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Subject: RE: [EXT] Re: SCMI & Devfreq
Ok, Sudeep. I would wait for your mail.
Regards
Sujeet
-----Original Message-----
From: Sudeep Holla <sudeep.holla@arm.com>
Sent: Monday, September 16, 2019 3:15 AM
To: Sujeet Kumar Baranwal <sbaranwal@marvell.com>
Cc: linux-arm-kernel@lists.infradead.org
Subject: Re: [EXT] Re: SCMI & Devfreq
On Mon, Sep 16, 2019 at 05:22:02AM +0000, Sujeet Kumar Baranwal wrote:
> Thanks Sudeep.
>
>>> Good, but just a quick question to check if this is ACPI or DT based
>>> platform ?
>
> DT based.
>
Good.
>>> Yes it needs some work and I do have some prototype, but with no
>>> users in the upstream, I haven't added it yet.
>>> What kind of devices are these ? There was some work around generic
>>> devfreq driver that I had seen >>on the list and my plan was to do
>>> something similar, I need to dig up details as it was while ago.
>
> These are devices needing dedicated clocks like dsp engines. There is
> a need for a userspace dev governor controlling the frequency in
> different situation.
Okay, thanks for the info.
> Could you please share your patches and any instructions if needed.
>
It needs some polishing before I post them externally, they are still hackish. I will do soonish.
--
Regards,
Sudeep
_______________________________________________
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/8] PM / devfreq: Move more initialization before registration
From: Matthias Kaehlcke @ 2019-09-18 23:29 UTC (permalink / raw)
To: Leonard Crestez
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan, linux-pm,
Viresh Kumar, Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park,
MyungJoo Ham, Alexandre Bailon, Georgi Djakov, linux-arm-kernel,
Jacky Bai
In-Reply-To: <59bd0d871fad520eb417ca46943fa7f86ef9186a.1568764439.git.leonard.crestez@nxp.com>
Hi Leonard,
On Wed, Sep 18, 2019 at 03:18:22AM +0300, Leonard Crestez wrote:
> In general it is a better to initialize an object before making it
> accessible externally (through device_register).
>
> This make it possible to avoid relying on locking a partially
> initialized object.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
> drivers/devfreq/devfreq.c | 38 ++++++++++++++++++++------------------
> 1 file changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index a715f27f35fd..57a217fc92de 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -589,10 +589,12 @@ static void devfreq_dev_release(struct device *dev)
>
> if (devfreq->profile->exit)
> devfreq->profile->exit(devfreq->dev.parent);
>
> mutex_destroy(&devfreq->lock);
> + kfree(devfreq->time_in_state);
> + kfree(devfreq->trans_table);
> kfree(devfreq);
> }
>
> /**
> * devfreq_add_device() - Add devfreq feature to the device
> @@ -671,44 +673,43 @@ struct devfreq *devfreq_add_device(struct device *dev,
> devfreq->max_freq = devfreq->scaling_max_freq;
>
> devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev);
> atomic_set(&devfreq->suspend_count, 0);
>
> - dev_set_name(&devfreq->dev, "devfreq%d",
> - atomic_inc_return(&devfreq_no));
> - err = device_register(&devfreq->dev);
> - if (err) {
> - mutex_unlock(&devfreq->lock);
> - put_device(&devfreq->dev);
> - goto err_out;
> - }
> -
> - devfreq->trans_table = devm_kzalloc(&devfreq->dev,
> + devfreq->trans_table = kzalloc(
> array3_size(sizeof(unsigned int),
> devfreq->profile->max_state,
> devfreq->profile->max_state),
> GFP_KERNEL);
> if (!devfreq->trans_table) {
> mutex_unlock(&devfreq->lock);
> err = -ENOMEM;
> - goto err_devfreq;
> + goto err_dev;
> }
>
> - devfreq->time_in_state = devm_kcalloc(&devfreq->dev,
> - devfreq->profile->max_state,
> - sizeof(unsigned long),
> - GFP_KERNEL);
> + devfreq->time_in_state = kcalloc(devfreq->profile->max_state,
> + sizeof(unsigned long),
> + GFP_KERNEL);
> if (!devfreq->time_in_state) {
> mutex_unlock(&devfreq->lock);
> err = -ENOMEM;
> - goto err_devfreq;
> + goto err_dev;
> }
>
> devfreq->last_stat_updated = jiffies;
>
> srcu_init_notifier_head(&devfreq->transition_notifier_list);
>
> + dev_set_name(&devfreq->dev, "devfreq%d",
> + atomic_inc_return(&devfreq_no));
> + err = device_register(&devfreq->dev);
> + if (err) {
> + mutex_unlock(&devfreq->lock);
> + put_device(&devfreq->dev);
> + goto err_out;
goto err_dev;
> + }
> +
> mutex_unlock(&devfreq->lock);
>
> mutex_lock(&devfreq_list_lock);
>
> governor = try_then_request_governor(devfreq->governor_name);
> @@ -734,14 +735,15 @@ struct devfreq *devfreq_add_device(struct device *dev,
>
> return devfreq;
>
> err_init:
> mutex_unlock(&devfreq_list_lock);
> -err_devfreq:
> devfreq_remove_device(devfreq);
> - devfreq = NULL;
> + return ERR_PTR(err);
The two return paths in the unwind part are unorthodox, but I
see why they are needed. Maybe add an empty line between the two paths
to make it a bit more evident that they are separate.
> err_dev:
This code path should include
mutex_destroy(&devfreq->lock);
That was already missing in the original code though.
Actually with the later device registration the mutex could be
initialized later and doesn't need to be held. This would
obsolete the mutex_unlock() calls in the error paths.
_______________________________________________
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/8] PM / devfreq: Move more initialization before registration
From: Matthias Kaehlcke @ 2019-09-19 0:14 UTC (permalink / raw)
To: Leonard Crestez
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan, linux-pm,
Viresh Kumar, Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park,
MyungJoo Ham, Alexandre Bailon, Georgi Djakov, linux-arm-kernel,
Jacky Bai
In-Reply-To: <20190918232904.GP133864@google.com>
On Wed, Sep 18, 2019 at 04:29:04PM -0700, Matthias Kaehlcke wrote:
> Hi Leonard,
>
> On Wed, Sep 18, 2019 at 03:18:22AM +0300, Leonard Crestez wrote:
> > In general it is a better to initialize an object before making it
> > accessible externally (through device_register).
> >
> > This make it possible to avoid relying on locking a partially
> > initialized object.
> >
> > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> > ---
> > drivers/devfreq/devfreq.c | 38 ++++++++++++++++++++------------------
> > 1 file changed, 20 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> > index a715f27f35fd..57a217fc92de 100644
> > --- a/drivers/devfreq/devfreq.c
> > +++ b/drivers/devfreq/devfreq.c
> > @@ -589,10 +589,12 @@ static void devfreq_dev_release(struct device *dev)
> >
> > if (devfreq->profile->exit)
> > devfreq->profile->exit(devfreq->dev.parent);
> >
> > mutex_destroy(&devfreq->lock);
> > + kfree(devfreq->time_in_state);
> > + kfree(devfreq->trans_table);
> > kfree(devfreq);
> > }
> >
> > /**
> > * devfreq_add_device() - Add devfreq feature to the device
> > @@ -671,44 +673,43 @@ struct devfreq *devfreq_add_device(struct device *dev,
> > devfreq->max_freq = devfreq->scaling_max_freq;
> >
> > devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev);
> > atomic_set(&devfreq->suspend_count, 0);
> >
> > - dev_set_name(&devfreq->dev, "devfreq%d",
> > - atomic_inc_return(&devfreq_no));
> > - err = device_register(&devfreq->dev);
> > - if (err) {
> > - mutex_unlock(&devfreq->lock);
> > - put_device(&devfreq->dev);
> > - goto err_out;
> > - }
> > -
> > - devfreq->trans_table = devm_kzalloc(&devfreq->dev,
> > + devfreq->trans_table = kzalloc(
> > array3_size(sizeof(unsigned int),
> > devfreq->profile->max_state,
> > devfreq->profile->max_state),
> > GFP_KERNEL);
> > if (!devfreq->trans_table) {
> > mutex_unlock(&devfreq->lock);
> > err = -ENOMEM;
> > - goto err_devfreq;
> > + goto err_dev;
> > }
> >
> > - devfreq->time_in_state = devm_kcalloc(&devfreq->dev,
> > - devfreq->profile->max_state,
> > - sizeof(unsigned long),
> > - GFP_KERNEL);
> > + devfreq->time_in_state = kcalloc(devfreq->profile->max_state,
> > + sizeof(unsigned long),
> > + GFP_KERNEL);
> > if (!devfreq->time_in_state) {
> > mutex_unlock(&devfreq->lock);
> > err = -ENOMEM;
> > - goto err_devfreq;
> > + goto err_dev;
> > }
> >
> > devfreq->last_stat_updated = jiffies;
> >
> > srcu_init_notifier_head(&devfreq->transition_notifier_list);
> >
> > + dev_set_name(&devfreq->dev, "devfreq%d",
> > + atomic_inc_return(&devfreq_no));
> > + err = device_register(&devfreq->dev);
> > + if (err) {
> > + mutex_unlock(&devfreq->lock);
> > + put_device(&devfreq->dev);
> > + goto err_out;
>
> goto err_dev;
>
> > + }
> > +
> > mutex_unlock(&devfreq->lock);
> >
> > mutex_lock(&devfreq_list_lock);
> >
> > governor = try_then_request_governor(devfreq->governor_name);
> > @@ -734,14 +735,15 @@ struct devfreq *devfreq_add_device(struct device *dev,
> >
> > return devfreq;
> >
> > err_init:
> > mutex_unlock(&devfreq_list_lock);
> > -err_devfreq:
> > devfreq_remove_device(devfreq);
> > - devfreq = NULL;
> > + return ERR_PTR(err);
>
> The two return paths in the unwind part are unorthodox, but I
> see why they are needed. Maybe add an empty line between the two paths
> to make it a bit more evident that they are separate.
>
> > err_dev:
>
> This code path should include
>
> mutex_destroy(&devfreq->lock);
>
> That was already missing in the original code though.
>
> Actually with the later device registration the mutex could be
> initialized later and doesn't need to be held. This would
> obsolete the mutex_unlock() calls in the error paths.
Just saw that you are already doing this in "[4/8] PM / devfreq:
Don't take lock in devfreq_add_device" :)
_______________________________________________
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/8] PM / devfreq: Don't take lock in devfreq_add_device
From: Matthias Kaehlcke @ 2019-09-19 0:20 UTC (permalink / raw)
To: Leonard Crestez
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan, linux-pm,
Viresh Kumar, Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park,
MyungJoo Ham, Alexandre Bailon, Georgi Djakov, linux-arm-kernel,
Jacky Bai
In-Reply-To: <2fe8d1000bed5de70b08ed77fc8360d159ae4434.1568764439.git.leonard.crestez@nxp.com>
On Wed, Sep 18, 2019 at 03:18:23AM +0300, Leonard Crestez wrote:
> A device usually doesn't need to lock itself during initialization
> because it is not yet reachable from other threads.
>
> This simplifies the code and helps avoid recursive lock warnings.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
> drivers/devfreq/devfreq.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 57a217fc92de..860cbbab476c 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -634,11 +634,10 @@ struct devfreq *devfreq_add_device(struct device *dev,
> err = -ENOMEM;
> goto err_out;
> }
>
> mutex_init(&devfreq->lock);
> - mutex_lock(&devfreq->lock);
> devfreq->dev.parent = dev;
> devfreq->dev.class = devfreq_class;
> devfreq->dev.release = devfreq_dev_release;
> INIT_LIST_HEAD(&devfreq->node);
> devfreq->profile = profile;
> @@ -647,28 +646,24 @@ struct devfreq *devfreq_add_device(struct device *dev,
> devfreq->last_status.current_frequency = profile->initial_freq;
> devfreq->data = data;
> devfreq->nb.notifier_call = devfreq_notifier_call;
>
> if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
> - mutex_unlock(&devfreq->lock);
> err = set_freq_table(devfreq);
> if (err < 0)
> goto err_dev;
> - mutex_lock(&devfreq->lock);
> }
>
> devfreq->scaling_min_freq = find_available_min_freq(devfreq);
> if (!devfreq->scaling_min_freq) {
> - mutex_unlock(&devfreq->lock);
> err = -EINVAL;
> goto err_dev;
> }
> devfreq->min_freq = devfreq->scaling_min_freq;
>
> devfreq->scaling_max_freq = find_available_max_freq(devfreq);
> if (!devfreq->scaling_max_freq) {
> - mutex_unlock(&devfreq->lock);
> err = -EINVAL;
> goto err_dev;
> }
> devfreq->max_freq = devfreq->scaling_max_freq;
>
> @@ -679,20 +674,18 @@ struct devfreq *devfreq_add_device(struct device *dev,
> array3_size(sizeof(unsigned int),
> devfreq->profile->max_state,
> devfreq->profile->max_state),
> GFP_KERNEL);
> if (!devfreq->trans_table) {
> - mutex_unlock(&devfreq->lock);
> err = -ENOMEM;
> goto err_dev;
> }
>
> devfreq->time_in_state = kcalloc(devfreq->profile->max_state,
> sizeof(unsigned long),
> GFP_KERNEL);
> if (!devfreq->time_in_state) {
> - mutex_unlock(&devfreq->lock);
> err = -ENOMEM;
> goto err_dev;
> }
>
> devfreq->last_stat_updated = jiffies;
> @@ -701,17 +694,14 @@ struct devfreq *devfreq_add_device(struct device *dev,
>
> dev_set_name(&devfreq->dev, "devfreq%d",
> atomic_inc_return(&devfreq_no));
> err = device_register(&devfreq->dev);
> if (err) {
> - mutex_unlock(&devfreq->lock);
> put_device(&devfreq->dev);
> goto err_out;
> }
>
> - mutex_unlock(&devfreq->lock);
> -
> mutex_lock(&devfreq_list_lock);
>
> governor = try_then_request_governor(devfreq->governor_name);
> if (IS_ERR(governor)) {
> dev_err(dev, "%s: Unable to find governor for the device\n",
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
_______________________________________________
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 02/13] KVM: PPC: Move memslot memory allocation into prepare_memory_region()
From: Paul Mackerras @ 2019-09-19 0:23 UTC (permalink / raw)
To: Sean Christopherson
Cc: Julien Thierry, Cornelia Huck, Wanpeng Li, Janosch Frank, kvm,
Radim Krčmář, Marc Zyngier, James Hogan,
Joerg Roedel, David Hildenbrand, linux-mips, kvm-ppc,
linux-kernel, Christian Borntraeger, James Morse,
linux-arm-kernel, Paolo Bonzini, Vitaly Kuznetsov, kvmarm,
Suzuki K Pouloze, Jim Mattson
In-Reply-To: <20190911185038.24341-3-sean.j.christopherson@intel.com>
On Wed, Sep 11, 2019 at 11:50:27AM -0700, Sean Christopherson wrote:
> Allocate the rmap array during kvm_arch_prepare_memory_region() to pave
> the way for removing kvm_arch_create_memslot() altogether. Moving PPC's
> memory allocation only changes the order of kernel memory allocations
> between PPC and common KVM code.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Seems OK.
Acked-by: Paul Mackerras <paulus@ozlabs.org>
_______________________________________________
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 10/13] KVM: Provide common implementation for generic dirty log functions
From: Paul Mackerras @ 2019-09-19 0:22 UTC (permalink / raw)
To: Sean Christopherson
Cc: Julien Thierry, Cornelia Huck, Wanpeng Li, Janosch Frank, kvm,
Radim Krčmář, Marc Zyngier, James Hogan,
Joerg Roedel, David Hildenbrand, linux-mips, kvm-ppc,
linux-kernel, Christian Borntraeger, James Morse,
linux-arm-kernel, Paolo Bonzini, Vitaly Kuznetsov, kvmarm,
Suzuki K Pouloze, Jim Mattson
In-Reply-To: <20190911185038.24341-11-sean.j.christopherson@intel.com>
On Wed, Sep 11, 2019 at 11:50:35AM -0700, Sean Christopherson wrote:
> Move the implementations of KVM_GET_DIRTY_LOG and KVM_CLEAR_DIRTY_LOG
> for CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT into common KVM code.
> The arch specific implemenations are extremely similar, differing
> only in whether the dirty log needs to be sync'd from hardware (x86)
> and how the TLBs are flushed. Add new arch hooks to handle sync
> and TLB flush; the sync will also be used for non-generic dirty log
> support in a future patch (s390).
>
> The ulterior motive for providing a common implementation is to
> eliminate the dependency between arch and common code with respect to
> the memslot referenced by the dirty log, i.e. to make it obvious in the
> code that the validity of the memslot is guaranteed, as a future patch
> will rework memslot handling such that id_to_memslot() can return NULL.
I notice you add empty definitions of kvm_arch_sync_dirty_log() for
PPC, both Book E and Book 3S. Given that PPC doesn't select
CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT, why is this necessary?
Paul.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Question-GIC-v4.1] Plan on GIC-v4.1 driver development
From: Shaokun Zhang @ 2019-09-19 1:32 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm; +Cc: Tangnianyao (ICT)
In-Reply-To: <c9bdf5bc-4787-2f09-9e8b-60d69aa8754b@kernel.org>
Hi Marc,
On 2019/9/18 17:58, Marc Zyngier wrote:
> On 17/09/2019 10:23, Marc Zyngier wrote:
>> On 17/09/2019 03:15, Shaokun Zhang wrote:
>>> Hi Marc,
>>>
>>> This is from Nianyao Tang.
>>>
>>> I'm planning to do some verification on our GIC-v4.1 implement. I would like some
>>> information about linux GIC-v4.1 driver. When will linux support GIC-v4.1 or what's
>>> the plan on developing GIC-v4.1 driver?
>>
>> The easy answer is that yes, there is a plan. There is some code, even,
>> just not quite in a usable state yet. I'll try to push something out
>> once I get a chance.
>
> FWIW, I've pushed out a branch containing the current state of this work
> at [1]. It doesn't really work at the moment (Doorbells and SGIs are
> unreliable), but hopefully that will give you an idea of what is going on.
>
Thank you, it is really helpful. I will check on this code first. If have any doubt,
I will 'noise' you again ;-)
Thanks in advance,
Shaokun
> Being a work in progress, it is unstable, subject to being changed,
> rebased and deleted without warning.
>
> Thanks,
>
> M.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gic-v4.1-devel
>
_______________________________________________
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 v4 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Justin He (Arm Technology China) @ 2019-09-19 1:46 UTC (permalink / raw)
To: kbuild test robot
Cc: Mark Rutland, Catalin Marinas, linux-mm@kvack.org, Punit Agrawal,
Will Deacon, Alex Van Brunt, Marc Zyngier, Anshuman Khandual,
Matthew Wilcox, Jun Yao, Kaly Xin (Arm Technology China),
hejianet@gmail.com, Ralph Campbell, Suzuki Poulose,
jglisse@redhat.com, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, James Morse, kbuild-all@01.org,
Andrew Morton, Robin Murphy, Kirill A. Shutemov
In-Reply-To: <201909190328.1k5H6WLv%lkp@intel.com>
> -----Original Message-----
> From: kbuild test robot <lkp@intel.com>
> Sent: 2019年9月19日 3:36
> To: Justin He (Arm Technology China) <Justin.He@arm.com>
> Cc: kbuild-all@01.org; Catalin Marinas <Catalin.Marinas@arm.com>; Will
> Deacon <will@kernel.org>; Mark Rutland <Mark.Rutland@arm.com>;
> James Morse <James.Morse@arm.com>; Marc Zyngier <maz@kernel.org>;
> Matthew Wilcox <willy@infradead.org>; Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux-mm@kvack.org; Suzuki Poulose
> <Suzuki.Poulose@arm.com>; Punit Agrawal <punitagrawal@gmail.com>;
> Anshuman Khandual <Anshuman.Khandual@arm.com>; Jun Yao
> <yaojun8558363@gmail.com>; Alex Van Brunt <avanbrunt@nvidia.com>;
> Robin Murphy <Robin.Murphy@arm.com>; Thomas Gleixner
> <tglx@linutronix.de>; Andrew Morton <akpm@linux-foundation.org>;
> jglisse@redhat.com; Ralph Campbell <rcampbell@nvidia.com>;
> hejianet@gmail.com; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>
> Subject: Re: [PATCH v4 3/3] mm: fix double page fault on arm64 if PTE_AF
> is cleared
>
> Hi Jia,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3 next-20190917]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Jia-He/fix-double-page-
> fault-on-arm64/20190918-220036
> config: arm64-allnoconfig (attached as .config)
> compiler: aarch64-linux-gcc (GCC) 7.4.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-
> tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=arm64
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> mm/memory.o: In function `wp_page_copy':
> >> memory.c:(.text+0x8fc): undefined reference to `cpu_has_hw_af'
> memory.c:(.text+0x8fc): relocation truncated to fit: R_AARCH64_CALL26
> against undefined symbol `cpu_has_hw_af'
>
Ah, I should add a stub for CONFIG_ARM64_HW_AFDBM is 'N' on arm64 arch
Will fix it asap
--
Cheers,
Justin (Jia He)
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
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 v4 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
From: Justin He (Arm Technology China) @ 2019-09-19 1:55 UTC (permalink / raw)
To: Catalin Marinas, Suzuki Poulose
Cc: Mark Rutland, Kaly Xin (Arm Technology China), Ralph Campbell,
Andrew Morton, Anshuman Khandual, Marc Zyngier,
linux-kernel@vger.kernel.org, Matthew Wilcox, Jun Yao,
linux-mm@kvack.org, Jérôme Glisse, James Morse,
linux-arm-kernel@lists.infradead.org, Punit Agrawal,
hejianet@gmail.com, Thomas Gleixner, Will Deacon, Alex Van Brunt,
Kirill A. Shutemov, Robin Murphy
In-Reply-To: <20190918164546.GA41588@arrakis.emea.arm.com>
Hi Suzuki
> -----Original Message-----
> From: Catalin Marinas <catalin.marinas@arm.com>
> Sent: 2019年9月19日 0:46
> To: Suzuki Poulose <Suzuki.Poulose@arm.com>
> Cc: Justin He (Arm Technology China) <Justin.He@arm.com>; Will Deacon
> <will@kernel.org>; Mark Rutland <Mark.Rutland@arm.com>; James Morse
> <James.Morse@arm.com>; Marc Zyngier <maz@kernel.org>; Matthew
> Wilcox <willy@infradead.org>; Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux-mm@kvack.org; Punit Agrawal
> <punitagrawal@gmail.com>; Anshuman Khandual
> <Anshuman.Khandual@arm.com>; Jun Yao <yaojun8558363@gmail.com>;
> Alex Van Brunt <avanbrunt@nvidia.com>; Robin Murphy
> <Robin.Murphy@arm.com>; Thomas Gleixner <tglx@linutronix.de>;
> Andrew Morton <akpm@linux-foundation.org>; Jérôme Glisse
> <jglisse@redhat.com>; Ralph Campbell <rcampbell@nvidia.com>;
> hejianet@gmail.com; Kaly Xin (Arm Technology China) <Kaly.Xin@arm.com>
> Subject: Re: [PATCH v4 1/3] arm64: cpufeature: introduce helper
> cpu_has_hw_af()
>
> On Wed, Sep 18, 2019 at 03:20:41PM +0100, Suzuki K Poulose wrote:
> > On 18/09/2019 14:19, Jia He wrote:
> > > diff --git a/arch/arm64/include/asm/cpufeature.h
> b/arch/arm64/include/asm/cpufeature.h
> > > index c96ffa4722d3..206b6e3954cf 100644
> > > --- a/arch/arm64/include/asm/cpufeature.h
> > > +++ b/arch/arm64/include/asm/cpufeature.h
> > > @@ -390,6 +390,7 @@ extern DECLARE_BITMAP(boot_capabilities,
> ARM64_NPATCHABLE);
> > > for_each_set_bit(cap, cpu_hwcaps, ARM64_NCAPS)
> > > bool this_cpu_has_cap(unsigned int cap);
> > > +bool cpu_has_hw_af(void);
> > > void cpu_set_feature(unsigned int num);
> > > bool cpu_have_feature(unsigned int num);
> > > unsigned long cpu_get_elf_hwcap(void);
> > > diff --git a/arch/arm64/kernel/cpufeature.c
> b/arch/arm64/kernel/cpufeature.c
> > > index b1fdc486aed8..c5097f58649d 100644
> > > --- a/arch/arm64/kernel/cpufeature.c
> > > +++ b/arch/arm64/kernel/cpufeature.c
> > > @@ -1141,6 +1141,12 @@ static bool has_hw_dbm(const struct
> arm64_cpu_capabilities *cap,
> > > return true;
> > > }
> > > +/* Decouple AF from AFDBM. */
> > > +bool cpu_has_hw_af(void)
> > > +{
> > Sorry for not having asked this earlier. Are we interested in,
> >
> > "whether *this* CPU has AF support ?" or "whether *at least one*
> > CPU has the AF support" ? The following code does the former.
> >
> > > + return (read_cpuid(ID_AA64MMFR1_EL1) & 0xf);
>
> In a non-preemptible context, the former is ok (per-CPU).
Yes, just as what Catalin explained, we need the former because the
pagefault occurred in every cpus
--
Cheers,
Justin (Jia He)
>
> --
> Catalin
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
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 v4 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Jia He @ 2019-09-19 2:16 UTC (permalink / raw)
To: Kirill A. Shutemov, Jia He
Cc: Mark Rutland, Kaly Xin, Ralph Campbell, Andrew Morton,
Suzuki Poulose, Catalin Marinas, Anshuman Khandual, linux-kernel,
Matthew Wilcox, Jun Yao, linux-mm, Jérôme Glisse,
James Morse, linux-arm-kernel, Punit Agrawal, Marc Zyngier,
Thomas Gleixner, Will Deacon, Alex Van Brunt, Kirill A. Shutemov,
Robin Murphy
In-Reply-To: <20190918140027.ckj32xnryyyesc23@box>
Hi Kirill
[On behalf of justin.he@arm.com because some mails are filted...]
On 2019/9/18 22:00, Kirill A. Shutemov wrote:
> On Wed, Sep 18, 2019 at 09:19:14PM +0800, Jia He wrote:
>> When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
>> will be a double page fault in __copy_from_user_inatomic of cow_user_page.
>>
>> Below call trace is from arm64 do_page_fault for debugging purpose
>> [ 110.016195] Call trace:
>> [ 110.016826] do_page_fault+0x5a4/0x690
>> [ 110.017812] do_mem_abort+0x50/0xb0
>> [ 110.018726] el1_da+0x20/0xc4
>> [ 110.019492] __arch_copy_from_user+0x180/0x280
>> [ 110.020646] do_wp_page+0xb0/0x860
>> [ 110.021517] __handle_mm_fault+0x994/0x1338
>> [ 110.022606] handle_mm_fault+0xe8/0x180
>> [ 110.023584] do_page_fault+0x240/0x690
>> [ 110.024535] do_mem_abort+0x50/0xb0
>> [ 110.025423] el0_da+0x20/0x24
>>
>> The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
>> [ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3
>>
>> As told by Catalin: "On arm64 without hardware Access Flag, copying from
>> user will fail because the pte is old and cannot be marked young. So we
>> always end up with zeroed page after fork() + CoW for pfn mappings. we
>> don't always have a hardware-managed access flag on arm64."
>>
>> This patch fix it by calling pte_mkyoung. Also, the parameter is
>> changed because vmf should be passed to cow_user_page()
>>
>> [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
>>
>> Reported-by: Yibo Cai <Yibo.Cai@arm.com>
>> Signed-off-by: Jia He <justin.he@arm.com>
>> ---
>> mm/memory.c | 35 ++++++++++++++++++++++++++++++-----
>> 1 file changed, 30 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index e2bb51b6242e..d2c130a5883b 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
>> 2;
>> #endif
>>
>> +#ifndef arch_faults_on_old_pte
>> +static inline bool arch_faults_on_old_pte(void)
>> +{
>> + return false;
>> +}
>> +#endif
>> +
>> static int __init disable_randmaps(char *s)
>> {
>> randomize_va_space = 0;
>> @@ -2140,8 +2147,12 @@ static inline int pte_unmap_same(struct mm_struct *mm, pmd_t *pmd,
>> return same;
>> }
>>
>> -static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
>> +static inline void cow_user_page(struct page *dst, struct page *src,
>> + struct vm_fault *vmf)
>> {
>> + struct vm_area_struct *vma = vmf->vma;
>> + unsigned long addr = vmf->address;
>> +
>> debug_dma_assert_idle(src);
>>
>> /*
>> @@ -2152,20 +2163,34 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
>> */
>> if (unlikely(!src)) {
>> void *kaddr = kmap_atomic(dst);
>> - void __user *uaddr = (void __user *)(va & PAGE_MASK);
>> + void __user *uaddr = (void __user *)(addr & PAGE_MASK);
>> + pte_t entry;
>>
>> /*
>> * This really shouldn't fail, because the page is there
>> * in the page tables. But it might just be unreadable,
>> * in which case we just give up and fill the result with
>> - * zeroes.
>> + * zeroes. On architectures with software "accessed" bits,
>> + * we would take a double page fault here, so mark it
>> + * accessed here.
>> */
>> + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
>> + spin_lock(vmf->ptl);
>> + if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
>> + entry = pte_mkyoung(vmf->orig_pte);
>> + if (ptep_set_access_flags(vma, addr,
>> + vmf->pte, entry, 0))
>> + update_mmu_cache(vma, addr, vmf->pte);
>> + }
> I don't follow.
>
> So if pte has changed under you, you don't set the accessed bit, but never
> the less copy from the user.
>
> What makes you think it will not trigger the same problem?
>
> I think we need to make cow_user_page() fail in this case and caller --
> wp_page_copy() -- return zero. If the fault was solved by other thread, we
> are fine. If not userspace would re-fault on the same address and we will
> handle the fault from the second attempt.
Thanks for the pointing. How about make cow_user_page() be returned
VM_FAULT_RETRY? Then in do_page_fault(), it can retry the page fault?
---
Cheers,
Justin (Jia He)
>
>> + spin_unlock(vmf->ptl);
>> + }
>> +
>> if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
>> clear_page(kaddr);
>> kunmap_atomic(kaddr);
>> flush_dcache_page(dst);
>> } else
>> - copy_user_highpage(dst, src, va, vma);
>> + copy_user_highpage(dst, src, addr, vma);
>> }
>>
>> static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
>> @@ -2318,7 +2343,7 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
>> vmf->address);
>> if (!new_page)
>> goto oom;
>> - cow_user_page(new_page, old_page, vmf->address, vma);
>> + cow_user_page(new_page, old_page, vmf);
>> }
>>
>> if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL, &memcg, false))
>> --
>> 2.17.1
>>
>>
--
_______________________________________________
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: Gene Chen @ 2019-09-19 2:20 UTC (permalink / raw)
To: Lee Jones
Cc: gene_chen, linux-kernel, linux-mediatek, matthias.bgg, Wilma.Wu,
linux-arm-kernel, shufan_lee
In-Reply-To: <20190918105121.GB5016@dell>
Lee Jones <lee.jones@linaro.org> 於 2019年9月18日 週三 下午6:51寫道：
>
> On Wed, 18 Sep 2019, Gene Chen wrote:
>
> > From: Gene Chen <gene_chen@richtek.com>
> >
> > Add mfd driver for mt6360 pmic chip include
> > Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck
> >
> > Signed-off-by: Gene Chen <gene_chen@richtek.com
> > ---
>
> This looks different from the one you sent before, but I don't see a
> version bump or any changelog in this space. Please re-submit with
> the differences noted.
>
the change is
1. add missing include file
2. modify commit message
this patch is regarded as version 1
> > drivers/mfd/Kconfig | 12 +
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/mt6360-core.c | 463 +++++++++++++++++++++++++++++++++++++
> > include/linux/mfd/mt6360-private.h | 279 ++++++++++++++++++++++
> > include/linux/mfd/mt6360.h | 33 +++
> > 5 files changed, 788 insertions(+)
> > create mode 100644 drivers/mfd/mt6360-core.c
> > create mode 100644 include/linux/mfd/mt6360-private.h
> > create mode 100644 include/linux/mfd/mt6360.h
>
> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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/3] dt-bindings: reset: add bindings for the Meson-A1 SoC Reset Controller
From: Xingyu Chen @ 2019-09-19 2:34 UTC (permalink / raw)
To: Neil Armstrong, Philipp Zabel, Kevin Hilman
Cc: devicetree, Hanjie Lin, Jianxin Pan, linux-kernel, Rob Herring,
linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <d99786ec-7635-67e5-3e47-738ce131b634@baylibre.com>
Hi, Neil
Thanks for your review
On 2019/9/18 20:39, Neil Armstrong wrote:
> Hi,
>
> On 18/09/2019 14:12, Xingyu Chen wrote:
>> Add DT bindings for the Meson-A1 SoC Reset Controller include file,
>> and also slightly update documentation.
>>
>> Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
>> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
>> ---
>> .../bindings/reset/amlogic,meson-reset.txt | 4 +-
>
> The reset bindings has been moved to yaml, either rebase on linux-next or wait for v5.4-rc1 :
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/refs/tags/next-20190917/Documentation/devicetree/bindings/reset/amlogic%2Cmeson-reset.yaml
>
> NeilI will fix it in next version.
>
>> include/dt-bindings/reset/amlogic,meson-a1-reset.h | 59 ++++++++++++++++++++++
>> 2 files changed, 61 insertions(+), 2 deletions(-)
>> create mode 100644 include/dt-bindings/reset/amlogic,meson-a1-reset.h
>>
>> diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
>> index 28ef6c2..011151a 100644
>> --- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
>> +++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
>> @@ -5,8 +5,8 @@ Please also refer to reset.txt in this directory for common reset
>> controller binding usage.
>>
>> Required properties:
>> -- compatible: Should be "amlogic,meson8b-reset", "amlogic,meson-gxbb-reset" or
>> - "amlogic,meson-axg-reset".
>> +- compatible: Should be "amlogic,meson8b-reset", "amlogic,meson-gxbb-reset",
>> + "amlogic,meson-axg-reset" or "amlogic,meson-a1-reset".
>> - reg: should contain the register address base
>> - #reset-cells: 1, see below
>>
>> diff --git a/include/dt-bindings/reset/amlogic,meson-a1-reset.h b/include/dt-bindings/reset/amlogic,meson-a1-reset.h
>> new file mode 100644
>> index 00000000..8d76a47
>> --- /dev/null
>> +++ b/include/dt-bindings/reset/amlogic,meson-a1-reset.h
>> @@ -0,0 +1,59 @@
>> +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> + *
>> + * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
>> + * Author: Xingyu Chen <xingyu.chen@amlogic.com>
>> + *
>> + */
>> +
>> +#ifndef _DT_BINDINGS_AMLOGIC_MESON_A1_RESET_H
>> +#define _DT_BINDINGS_AMLOGIC_MESON_A1_RESET_H
>> +
>> +/* RESET0 */
>> +#define RESET_AM2AXI_VAD 1
>> +#define RESET_PSRAM 4
>> +#define RESET_PAD_CTRL 5
>> +#define RESET_TEMP_SENSOR 7
>> +#define RESET_AM2AXI_DEV 8
>> +#define RESET_SPICC_A 10
>> +#define RESET_MSR_CLK 11
>> +#define RESET_AUDIO 12
>> +#define RESET_ANALOG_CTRL 13
>> +#define RESET_SAR_ADC 14
>> +#define RESET_AUDIO_VAD 15
>> +#define RESET_CEC 16
>> +#define RESET_PWM_EF 17
>> +#define RESET_PWM_CD 18
>> +#define RESET_PWM_AB 19
>> +#define RESET_IR_CTRL 21
>> +#define RESET_I2C_S_A 22
>> +#define RESET_I2C_M_D 24
>> +#define RESET_I2C_M_C 25
>> +#define RESET_I2C_M_B 26
>> +#define RESET_I2C_M_A 27
>> +#define RESET_I2C_PROD_AHB 28
>> +#define RESET_I2C_PROD 29
>> +
>> +/* RESET1 */
>> +#define RESET_ACODEC 32
>> +#define RESET_DMA 33
>> +#define RESET_SD_EMMC_A 34
>> +#define RESET_USBCTRL 36
>> +#define RESET_USBPHY 38
>> +#define RESET_RSA 42
>> +#define RESET_DMC 43
>> +#define RESET_IRQ_CTRL 45
>> +#define RESET_NIC_VAD 47
>> +#define RESET_NIC_AXI 48
>> +#define RESET_RAMA 49
>> +#define RESET_RAMB 50
>> +#define RESET_ROM 53
>> +#define RESET_SPIFC 54
>> +#define RESET_GIC 55
>> +#define RESET_UART_C 56
>> +#define RESET_UART_B 57
>> +#define RESET_UART_A 58
>> +#define RESET_OSC_RING 59
>> +
>> +/* RESET2 Reserved */
>> +
>> +#endif
>>
>
> .
>
_______________________________________________
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] clk: imx7ulp: remove IMX7ULP_CLK_MIPI_PLL clock
From: Fancy Fang @ 2019-09-19 3:10 UTC (permalink / raw)
To: shawnguo@kernel.org
Cc: sboyd@kernel.org, mturquette@baylibre.com,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
dl-linux-imx, kernel@pengutronix.de, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org
The mipi pll clock comes from the MIPI PHY PLL output, so
it should not be a fixed clock.
MIPI PHY PLL is in the MIPI DSI space, and it is used as
the bit clock for transferring the pixel data out and its
output clock is configured according to the display mode.
So it should be used only for MIPI DSI and not be exported
out for other usages.
Signed-off-by: Fancy Fang <chen.fang@nxp.com>
---
ChangeLog v1->v2:
* Keep other clock indexes unchanged as Shawn suggested.
Documentation/devicetree/bindings/clock/imx7ulp-clock.txt | 1 -
drivers/clk/imx/clk-imx7ulp.c | 3 +--
include/dt-bindings/clock/imx7ulp-clock.h | 1 -
3 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
index a4f8cd478f92..93d89adb7afe 100644
--- a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
@@ -82,7 +82,6 @@ pcc2: pcc2@403f0000 {
<&scg1 IMX7ULP_CLK_APLL_PFD0>,
<&scg1 IMX7ULP_CLK_UPLL>,
<&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>,
- <&scg1 IMX7ULP_CLK_MIPI_PLL>,
<&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>,
<&scg1 IMX7ULP_CLK_ROSC>,
<&scg1 IMX7ULP_CLK_SPLL_BUS_CLK>;
diff --git a/drivers/clk/imx/clk-imx7ulp.c b/drivers/clk/imx/clk-imx7ulp.c
index 995a4ad10904..936c39f767df 100644
--- a/drivers/clk/imx/clk-imx7ulp.c
+++ b/drivers/clk/imx/clk-imx7ulp.c
@@ -28,7 +28,7 @@ static const char * const scs_sels[] = { "dummy", "sosc", "sirc", "firc", "dumm
static const char * const ddr_sels[] = { "apll_pfd_sel", "upll", };
static const char * const nic_sels[] = { "firc", "ddr_clk", };
static const char * const periph_plat_sels[] = { "dummy", "nic1_bus_clk", "nic1_clk", "ddr_clk", "apll_pfd2", "apll_pfd1", "apll_pfd0", "upll", };
-static const char * const periph_bus_sels[] = { "dummy", "sosc_bus_clk", "mpll", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk", };
+static const char * const periph_bus_sels[] = { "dummy", "sosc_bus_clk", "dummy", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk", };
static const char * const arm_sels[] = { "divcore", "dummy", "dummy", "hsrun_divcore", };
/* used by sosc/sirc/firc/ddr/spll/apll dividers */
@@ -75,7 +75,6 @@ static void __init imx7ulp_clk_scg1_init(struct device_node *np)
clks[IMX7ULP_CLK_SOSC] = imx_obtain_fixed_clk_hw(np, "sosc");
clks[IMX7ULP_CLK_SIRC] = imx_obtain_fixed_clk_hw(np, "sirc");
clks[IMX7ULP_CLK_FIRC] = imx_obtain_fixed_clk_hw(np, "firc");
- clks[IMX7ULP_CLK_MIPI_PLL] = imx_obtain_fixed_clk_hw(np, "mpll");
clks[IMX7ULP_CLK_UPLL] = imx_obtain_fixed_clk_hw(np, "upll");
/* SCG1 */
diff --git a/include/dt-bindings/clock/imx7ulp-clock.h b/include/dt-bindings/clock/imx7ulp-clock.h
index 6f66f9005c81..a39b0c40cb41 100644
--- a/include/dt-bindings/clock/imx7ulp-clock.h
+++ b/include/dt-bindings/clock/imx7ulp-clock.h
@@ -49,7 +49,6 @@
#define IMX7ULP_CLK_NIC1_DIV 36
#define IMX7ULP_CLK_NIC1_BUS_DIV 37
#define IMX7ULP_CLK_NIC1_EXT_DIV 38
-#define IMX7ULP_CLK_MIPI_PLL 39
#define IMX7ULP_CLK_SIRC 40
#define IMX7ULP_CLK_SOSC_BUS_CLK 41
#define IMX7ULP_CLK_FIRC_BUS_CLK 42
--
2.17.1
_______________________________________________
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] clk: imx7ulp: remove IMX7ULP_CLK_MIPI_PLL clock
From: Fancy Fang @ 2019-09-19 3:10 UTC (permalink / raw)
To: shawnguo@kernel.org
Cc: sboyd@kernel.org, mturquette@baylibre.com,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
dl-linux-imx, kernel@pengutronix.de, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190919030912.16957-1-chen.fang@nxp.com>
The mipi pll clock comes from the MIPI PHY PLL output, so
it should not be a fixed clock.
MIPI PHY PLL is in the MIPI DSI space, and it is used as
the bit clock for transferring the pixel data out and its
output clock is configured according to the display mode.
So it should be used only for MIPI DSI and not be exported
out for other usages.
Signed-off-by: Fancy Fang <chen.fang@nxp.com>
---
ChangeLog v1->v2:
* Keep other clock indexes unchanged as Shawn suggested.
Documentation/devicetree/bindings/clock/imx7ulp-clock.txt | 1 -
drivers/clk/imx/clk-imx7ulp.c | 3 +--
include/dt-bindings/clock/imx7ulp-clock.h | 1 -
3 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
index a4f8cd478f92..93d89adb7afe 100644
--- a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
@@ -82,7 +82,6 @@ pcc2: pcc2@403f0000 {
<&scg1 IMX7ULP_CLK_APLL_PFD0>,
<&scg1 IMX7ULP_CLK_UPLL>,
<&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>,
- <&scg1 IMX7ULP_CLK_MIPI_PLL>,
<&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>,
<&scg1 IMX7ULP_CLK_ROSC>,
<&scg1 IMX7ULP_CLK_SPLL_BUS_CLK>;
diff --git a/drivers/clk/imx/clk-imx7ulp.c b/drivers/clk/imx/clk-imx7ulp.c
index 995a4ad10904..936c39f767df 100644
--- a/drivers/clk/imx/clk-imx7ulp.c
+++ b/drivers/clk/imx/clk-imx7ulp.c
@@ -28,7 +28,7 @@ static const char * const scs_sels[] = { "dummy", "sosc", "sirc", "firc", "dumm
static const char * const ddr_sels[] = { "apll_pfd_sel", "upll", };
static const char * const nic_sels[] = { "firc", "ddr_clk", };
static const char * const periph_plat_sels[] = { "dummy", "nic1_bus_clk", "nic1_clk", "ddr_clk", "apll_pfd2", "apll_pfd1", "apll_pfd0", "upll", };
-static const char * const periph_bus_sels[] = { "dummy", "sosc_bus_clk", "mpll", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk", };
+static const char * const periph_bus_sels[] = { "dummy", "sosc_bus_clk", "dummy", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk", };
static const char * const arm_sels[] = { "divcore", "dummy", "dummy", "hsrun_divcore", };
/* used by sosc/sirc/firc/ddr/spll/apll dividers */
@@ -75,7 +75,6 @@ static void __init imx7ulp_clk_scg1_init(struct device_node *np)
clks[IMX7ULP_CLK_SOSC] = imx_obtain_fixed_clk_hw(np, "sosc");
clks[IMX7ULP_CLK_SIRC] = imx_obtain_fixed_clk_hw(np, "sirc");
clks[IMX7ULP_CLK_FIRC] = imx_obtain_fixed_clk_hw(np, "firc");
- clks[IMX7ULP_CLK_MIPI_PLL] = imx_obtain_fixed_clk_hw(np, "mpll");
clks[IMX7ULP_CLK_UPLL] = imx_obtain_fixed_clk_hw(np, "upll");
/* SCG1 */
diff --git a/include/dt-bindings/clock/imx7ulp-clock.h b/include/dt-bindings/clock/imx7ulp-clock.h
index 6f66f9005c81..a39b0c40cb41 100644
--- a/include/dt-bindings/clock/imx7ulp-clock.h
+++ b/include/dt-bindings/clock/imx7ulp-clock.h
@@ -49,7 +49,6 @@
#define IMX7ULP_CLK_NIC1_DIV 36
#define IMX7ULP_CLK_NIC1_BUS_DIV 37
#define IMX7ULP_CLK_NIC1_EXT_DIV 38
-#define IMX7ULP_CLK_MIPI_PLL 39
#define IMX7ULP_CLK_SIRC 40
#define IMX7ULP_CLK_SOSC_BUS_CLK 41
#define IMX7ULP_CLK_FIRC_BUS_CLK 42
--
2.17.1
_______________________________________________
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: [RFC PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load
From: Thiago Jung Bauermann @ 2019-09-19 3:59 UTC (permalink / raw)
To: Mimi Zohar
Cc: mark.rutland, jean-philippe, arnd, takahiro.akashi, sboyd,
catalin.marinas, kexec, linux-kernel, Prakhar Srivastava,
yamada.masahiro, kristina.martsenko, duwe, allison, james.morse,
linux-integrity, tglx, linux-arm-kernel
In-Reply-To: <1568841696.4733.3.camel@linux.ibm.com>
Mimi Zohar <zohar@linux.ibm.com> writes:
> On Wed, 2019-09-18 at 10:15 -0400, Mimi Zohar wrote:
>
>> > + uint64_t tmp_start, tmp_end;
>> > +
>> > + propStart = of_find_property(of_chosen, "linux,ima-kexec-buffer",
>> > + NULL);
>> > + if (propStart) {
>> > + tmp_start = fdt64_to_cpu(*((const fdt64_t *) propStart));
>> > + ret = of_remove_property(of_chosen, propStart);
>> > + if (!ret) {
>> > + return ret;
>> > + }
>> > +
>> > + propEnd = of_find_property(of_chosen,
>> > + "linux,ima-kexec-buffer-end", NULL);
>> > + if (!propEnd) {
>> > + return -EINVAL;
>> > + }
>> > +
>> > + tmp_end = fdt64_to_cpu(*((const fdt64_t *) propEnd));
>> > +
>> > + ret = of_remove_property(of_chosen, propEnd);
>> > + if (!ret) {
>> > + return ret;
>> > + }
>>
>> There seems to be quite a bit of code duplication in this function and
>> in ima_get_kexec_buffer(). It could probably be cleaned up with some
>> refactoring.
>
> Sorry, my mistake. One calls of_get_property(), while the other calls
> of_find_property().
of_get_property() is a thin wrapper around of_find_property(), so if
that's the only difference I think they can still be merged.
--
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Y.b. Lu @ 2019-09-19 4:13 UTC (permalink / raw)
To: Leo Li, Fabio Estevam, Russell King - ARM Linux admin
Cc: dann frazier, Will Deacon, Adrian Hunter, Nicolin Chen, linux-mmc,
Christoph Hellwig, Linux ARM
In-Reply-To: <CADRPPNQ-WTY0QC7_bX=N0QeueKve=k0SaMvbjOrByyvzFojz2g@mail.gmail.com>
Sorry. My email was rejected by mailing lists. Let me re-send.
Hi Russell,
I’m not sure what board you were using for LX2160A.
We had an known issue for eSDHC controller and all NXP Layerscape RDB boards.
eSDHC couldn’t provide power-cycle to SD card, and even worse, board reset couldn’t provide power-cycle to SD card either.
But for UHS-I SD card, it’s required to have a power-cycle to reset card if it goes into UHS-I mode. Otherwise, we don’t know what will happen when kernel initializes SD card after a reboot/reset.
I could reproduce that issue with below steps on latest mainline kernel.
1. Power off board, and power on board.
2. Start up kernel, the SD card works fine in UHS-I mode.
3. Reboot/reset board. (This couldn’t provide power-cycle to SD card)
4. Start up kernel, the SD card gets that ADMA error issue.
So could you have a try to power off/power on the board, and then start up kernel. Don’t use reboot, or board reset button.
Or you can remove SD card and start up kernel, and insert SD card when kernel has been started up.
Thanks a lot.
Best regards,
Yangbo Lu
From: Li Yang <leoyang.li@nxp.com>
Sent: Wednesday, September 18, 2019 1:48 AM
To: Fabio Estevam <festevam@gmail.com>; Y.b. Lu <yangbo.lu@nxp.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>; Christoph Hellwig <hch@lst.de>; Linux ARM <linux-arm-kernel@lists.infradead.org>; Nicolin Chen <nicoleotsuka@gmail.com>; Russell King - ARM Linux admin <linux@armlinux.org.uk>; Will Deacon <will.deacon@arm.com>; dann frazier <dann.frazier@canonical.com>; linux-mmc <linux-mmc@vger.kernel.org>
Subject: Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
On Tue, Sep 17, 2019 at 6:31 PM Fabio Estevam <mailto:festevam@gmail.com> wrote:
[Adding Li Yang]
On Tue, Sep 17, 2019 at 10:52 AM Russell King - ARM Linux admin
<mailto:linux@armlinux.org.uk> wrote:
> The pressing question seems to be this:
>
> Are the eSDHC on the LX2160A DMA coherent or are they not?
>
> Any chances of finding out internally what the true answer to that,
> rather than me poking about trying stuff experimentally? Having a
> definitive answer for a potentially data-corrupting change would
> be really good...
Li Yang,
Could you please help to confirm Russell's question?
Adding Yangbo who is working on SDHC.
Regards,
Leo
_______________________________________________
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] staging: mt7621-pci-phy: Use devm_platform_ioremap_resource() in mt7621_pci_phy_probe()
From: Sergio Paracuellos @ 2019-09-19 4:20 UTC (permalink / raw)
To: Markus Elfring
Cc: devel, Bartosz Golaszewski, Greg Kroah-Hartman, kernel-janitors,
LKML, Neil Brown, Matthias Brugger, linux-mediatek, Himanshu Jha,
Emanuel Bennici, Antti Keränen, linux-arm-kernel
In-Reply-To: <1c16a43c-3a01-8a86-02b0-1941ab7321dd@web.de>
Hi Markus,
Thanks for the patch. It looks good to me.
On Wed, Sep 18, 2019 at 9:12 PM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 18 Sep 2019 21:01:32 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
> index d2a07f145143..6ca4a33d13c3 100644
> --- a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
> +++ b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
> @@ -324,7 +324,6 @@ static int mt7621_pci_phy_probe(struct platform_device *pdev)
> const struct soc_device_attribute *attr;
> struct phy_provider *provider;
> struct mt7621_pci_phy *phy;
> - struct resource *res;
> int port;
> void __iomem *port_base;
>
> @@ -344,14 +343,7 @@ static int mt7621_pci_phy_probe(struct platform_device *pdev)
>
> phy->dev = dev;
> platform_set_drvdata(pdev, phy);
> -
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(dev, "failed to get address resource\n");
> - return -ENXIO;
> - }
> -
> - port_base = devm_ioremap_resource(dev, res);
> + port_base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(port_base)) {
> dev_err(dev, "failed to remap phy regs\n");
> return PTR_ERR(port_base);
> --
> 2.23.0
>
Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
_______________________________________________
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 V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
From: Anshuman Khandual @ 2019-09-19 4:56 UTC (permalink / raw)
To: Christophe Leroy, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Thomas Gleixner, linux-s390, Jason Gunthorpe,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Tetsuo Handa, Gerald Schaefer, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Kirill A . Shutemov,
Dan Williams, Vlastimil Babka, linux-arm-kernel,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <64504101-d9dd-f273-02f9-e9a8b178eecc@c-s.fr>
On 09/18/2019 09:56 PM, Christophe Leroy wrote:
>
>
> Le 18/09/2019 à 07:04, Anshuman Khandual a écrit :
>>
>>
>> On 09/13/2019 03:31 PM, Christophe Leroy wrote:
>>>
>>>
>>> Le 13/09/2019 à 11:02, Anshuman Khandual a écrit :
>>>>
>>>>>> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
>>>>>
>>>>> #ifdefs have to be avoided as much as possible, see below
>>>>
>>>> Yeah but it has been bit difficult to avoid all these $ifdef because of the
>>>> availability (or lack of it) for all these pgtable helpers in various config
>>>> combinations on all platforms.
>>>
>>> As far as I can see these pgtable helpers should exist everywhere at least via asm-generic/ files.
>>
>> But they might not actually do the right thing.
>>
>>>
>>> Can you spot a particular config which fails ?
>>
>> Lets consider the following example (after removing the $ifdefs around it)
>> which though builds successfully but fails to pass the intended test. This
>> is with arm64 config 4K pages sizes with 39 bits VA space which ends up
>> with a 3 level page table arrangement.
>>
>> static void __init p4d_clear_tests(p4d_t *p4dp)
>> {
>> p4d_t p4d = READ_ONCE(*p4dp);
>
> My suggestion was not to completely drop the #ifdef but to do like you did in pgd_clear_tests() for instance, ie to add the following test on top of the function:
>
> if (mm_pud_folded(mm) || is_defined(__ARCH_HAS_5LEVEL_HACK))
> return;
>
Sometimes this does not really work. On some platforms, combination of
__PAGETABLE_PUD_FOLDED and __ARCH_HAS_5LEVEL_HACK decide whether the
helpers such as __pud() or __pgd() is even available for that platform.
Ideally it should have been through generic falls backs in include/*/
but I guess there might be bugs on the platform or it has not been
changed to adopt 5 level page table framework with required folding
macros etc.
>>
>> p4d = __p4d(p4d_val(p4d) | RANDOM_ORVALUE);
>> WRITE_ONCE(*p4dp, p4d);
>> p4d_clear(p4dp);
>> p4d = READ_ONCE(*p4dp);
>> WARN_ON(!p4d_none(p4d));
>> }
>>
>> The following test hits an error at WARN_ON(!p4d_none(p4d))
>>
>> [ 16.757333] ------------[ cut here ]------------
>> [ 16.758019] WARNING: CPU: 11 PID: 1 at mm/arch_pgtable_test.c:187 arch_pgtable_tests_init+0x24c/0x474
>> [ 16.759455] Modules linked in:
>> [ 16.759952] CPU: 11 PID: 1 Comm: swapper/0 Not tainted 5.3.0-next-20190916-00005-g61c218153bb8-dirty #222
>> [ 16.761449] Hardware name: linux,dummy-virt (DT)
>> [ 16.762185] pstate: 00400005 (nzcv daif +PAN -UAO)
>> [ 16.762964] pc : arch_pgtable_tests_init+0x24c/0x474
>> [ 16.763750] lr : arch_pgtable_tests_init+0x174/0x474
>> [ 16.764534] sp : ffffffc011d7bd50
>> [ 16.765065] x29: ffffffc011d7bd50 x28: ffffffff1756bac0
>> [ 16.765908] x27: ffffff85ddaf3000 x26: 00000000000002e8
>> [ 16.766767] x25: ffffffc0111ce000 x24: ffffff85ddaf32e8
>> [ 16.767606] x23: ffffff85ddaef278 x22: 00000045cc844000
>> [ 16.768445] x21: 000000065daef003 x20: ffffffff17540000
>> [ 16.769283] x19: ffffff85ddb60000 x18: 0000000000000014
>> [ 16.770122] x17: 00000000980426bb x16: 00000000698594c6
>> [ 16.770976] x15: 0000000066e25a88 x14: 0000000000000000
>> [ 16.771813] x13: ffffffff17540000 x12: 000000000000000a
>> [ 16.772651] x11: ffffff85fcfd0a40 x10: 0000000000000001
>> [ 16.773488] x9 : 0000000000000008 x8 : ffffffc01143ab26
>> [ 16.774336] x7 : 0000000000000000 x6 : 0000000000000000
>> [ 16.775180] x5 : 0000000000000000 x4 : 0000000000000000
>> [ 16.776018] x3 : ffffffff1756bbe8 x2 : 000000065daeb003
>> [ 16.776856] x1 : 000000000065daeb x0 : fffffffffffff000
>> [ 16.777693] Call trace:
>> [ 16.778092] arch_pgtable_tests_init+0x24c/0x474
>> [ 16.778843] do_one_initcall+0x74/0x1b0
>> [ 16.779458] kernel_init_freeable+0x1cc/0x290
>> [ 16.780151] kernel_init+0x10/0x100
>> [ 16.780710] ret_from_fork+0x10/0x18
>> [ 16.781282] ---[ end trace 042e6c40c0a3b038 ]---
>>
>> On arm64 (4K page size|39 bits VA|3 level page table)
>>
>> #elif CONFIG_PGTABLE_LEVELS == 3 /* Applicable here */
>> #define __ARCH_USE_5LEVEL_HACK
>> #include <asm-generic/pgtable-nopud.h>
>>
>> Which pulls in
>>
>> #include <asm-generic/pgtable-nop4d-hack.h>
>>
>> which pulls in
>>
>> #include <asm-generic/5level-fixup.h>
>>
>> which defines
>>
>> static inline int p4d_none(p4d_t p4d)
>> {
>> return 0;
>> }
>>
>> which will invariably trigger WARN_ON(!p4d_none(p4d)).
>>
>> Similarly for next test p4d_populate_tests() which will always be
>> successful because p4d_bad() invariably returns negative.
>>
>> static inline int p4d_bad(p4d_t p4d)
>> {
>> return 0;
>> }
>>
>> static void __init p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp,
>> pud_t *pudp)
>> {
>> p4d_t p4d;
>>
>> /*
>> * This entry points to next level page table page.
>> * Hence this must not qualify as p4d_bad().
>> */
>> pud_clear(pudp);
>> p4d_clear(p4dp);
>> p4d_populate(mm, p4dp, pudp);
>> p4d = READ_ONCE(*p4dp);
>> WARN_ON(p4d_bad(p4d));
>> }
>>
>> We should not run these tests for the above config because they are
>> not applicable and will invariably produce same result.
>>
>>>
>>>>
>>>>>
>>>
>>> [...]
>>>
>>>>>> +#if !defined(__PAGETABLE_PUD_FOLDED) && !defined(__ARCH_HAS_5LEVEL_HACK)
>>>>>
>>>>> The same can be done here.
>>>>
>>>> IIRC not only the page table helpers but there are data types (pxx_t) which
>>>> were not present on various configs and these wrappers help prevent build
>>>> failures. Any ways will try and see if this can be improved further. But
>>>> meanwhile if you have some suggestions, please do let me know.
>>>
>>> pgt_t and pmd_t are everywhere I guess.
>>> then pud_t and p4d_t have fallbacks in asm-generic files.
>>
>> Lets take another example where it fails to compile. On arm64 with 16K
>> page size, 48 bits VA, 4 level page table arrangement in the following
>> test, pgd_populate() does not have the required signature.
>>
>> static void pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp, p4d_t *p4dp)
>> {
>> pgd_t pgd;
>>
>> if (mm_p4d_folded(mm))
>> return;
>>
>> /*
>> * This entry points to next level page table page.
>> * Hence this must not qualify as pgd_bad().
>> */
>> p4d_clear(p4dp);
>> pgd_clear(pgdp);
>> pgd_populate(mm, pgdp, p4dp);
>> pgd = READ_ONCE(*pgdp);
>> WARN_ON(pgd_bad(pgd));
>> }
>>
>> mm/arch_pgtable_test.c: In function ‘pgd_populate_tests’:
>> mm/arch_pgtable_test.c:254:25: error: passing argument 3 of ‘pgd_populate’ from incompatible pointer type [-Werror=incompatible-pointer-types]
>> pgd_populate(mm, pgdp, p4dp);
>> ^~~~
>> In file included from mm/arch_pgtable_test.c:27:0:
>> ./arch/arm64/include/asm/pgalloc.h:81:20: note: expected ‘pud_t * {aka struct <anonymous> *}’ but argument is of type ‘pgd_t * {aka struct <anonymous> *}’
>> static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgdp, pud_t *pudp)
>>
>> The build failure is because p4d_t * maps to pgd_t * but the applicable
>> (it does not fallback on generic ones) pgd_populate() expects a pud_t *.
>>
>> Except for archs which have 5 level page able, pgd_populate() always accepts
>> lower level page table pointers as the last argument as they dont have that
>> many levels.
>>
>> arch/x86/include/asm/pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, p4d_t *p4d)
>> arch/s390/include/asm/pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, p4d_t *p4d)
>>
>> But others
>>
>> arch/arm64/include/asm/pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgdp, pud_t *pudp)
>> arch/m68k/include/asm/motorola_pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pmd_t *pmd)
>> arch/mips/include/asm/pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
>> arch/powerpc/include/asm/book3s/64/pgalloc.h:static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
>>
>> I remember going through all these combinations before arriving at the
>> current state of #ifdef exclusions. Probably, to solved this all platforms
>> have to define pxx_populate() helpers assuming they support 5 level page
>> table.
>>
>>>
>>> So it shouldn't be an issue. Maybe if a couple of arches miss them, the best would be to fix the arches, since that's the purpose of your testsuite isn't it ?
>>
>> The run time failures as explained previously is because of the folding which
>> needs to be protected as they are not even applicable. The compile time
>> failures are because pxx_populate() signatures are platform specific depending
>> on how many page table levels they really support.
>>
>
> So IIUC, the compiletime problem is around __ARCH_HAS_5LEVEL_HACK. For all #if !defined(__PAGETABLE_PXX_FOLDED), something equivalent to the following should make the trick.
>
> if (mm_pxx_folded())
> return;
>
>
> For the __ARCH_HAS_5LEVEL_HACK stuff, I think we should be able to regroup all impacted functions inside a single #ifdef __ARCH_HAS_5LEVEL_HACK
I was wondering if it will be better to
1) Minimize all #ifdefs in the code which might fail on some platforms
2) Restrict proposed test module to platforms where it builds and runs
3) Enable other platforms afterwards after fixing their build problems or other requirements
Would that be a better approach instead ?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] arm64: dts: imx8mn: Use correct clock for usdhc's ipg clk
From: Anson Huang @ 2019-09-19 5:05 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, daniel.lezcano, ping.bai, daniel.baluta, jun.li,
l.stach, abel.vesa, andrew.smirnov, angus, ccaione, agx,
devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1568869559-28611-1-git-send-email-Anson.Huang@nxp.com>
On i.MX8MN, usdhc's ipg clock is from IMX8MN_CLK_IPG_ROOT,
assign it explicitly instead of using IMX8MN_CLK_DUMMY.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 6cb6c9c..725a3a3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -594,7 +594,7 @@
compatible = "fsl,imx8mn-usdhc", "fsl,imx7d-usdhc";
reg = <0x30b40000 0x10000>;
interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MN_CLK_DUMMY>,
+ clocks = <&clk IMX8MN_CLK_IPG_ROOT>,
<&clk IMX8MN_CLK_NAND_USDHC_BUS>,
<&clk IMX8MN_CLK_USDHC1_ROOT>;
clock-names = "ipg", "ahb", "per";
@@ -610,7 +610,7 @@
compatible = "fsl,imx8mn-usdhc", "fsl,imx7d-usdhc";
reg = <0x30b50000 0x10000>;
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MN_CLK_DUMMY>,
+ clocks = <&clk IMX8MN_CLK_IPG_ROOT>,
<&clk IMX8MN_CLK_NAND_USDHC_BUS>,
<&clk IMX8MN_CLK_USDHC2_ROOT>;
clock-names = "ipg", "ahb", "per";
@@ -624,7 +624,7 @@
compatible = "fsl,imx8mn-usdhc", "fsl,imx7d-usdhc";
reg = <0x30b60000 0x10000>;
interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MN_CLK_DUMMY>,
+ clocks = <&clk IMX8MN_CLK_IPG_ROOT>,
<&clk IMX8MN_CLK_NAND_USDHC_BUS>,
<&clk IMX8MN_CLK_USDHC3_ROOT>;
clock-names = "ipg", "ahb", "per";
--
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
* [PATCH 1/3] arm64: dts: imx8mq: Use correct clock for usdhc's ipg clk
From: Anson Huang @ 2019-09-19 5:05 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, daniel.lezcano, ping.bai, daniel.baluta, jun.li,
l.stach, abel.vesa, andrew.smirnov, angus, ccaione, agx,
devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
On i.MX8MQ, usdhc's ipg clock is from IMX8MQ_CLK_IPG_ROOT,
assign it explicitly instead of using IMX8MQ_CLK_DUMMY.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index fd42bee..e2c95ad 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -850,7 +850,7 @@
"fsl,imx7d-usdhc";
reg = <0x30b40000 0x10000>;
interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MQ_CLK_DUMMY>,
+ clocks = <&clk IMX8MQ_CLK_IPG_ROOT>,
<&clk IMX8MQ_CLK_NAND_USDHC_BUS>,
<&clk IMX8MQ_CLK_USDHC1_ROOT>;
clock-names = "ipg", "ahb", "per";
@@ -867,7 +867,7 @@
"fsl,imx7d-usdhc";
reg = <0x30b50000 0x10000>;
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MQ_CLK_DUMMY>,
+ clocks = <&clk IMX8MQ_CLK_IPG_ROOT>,
<&clk IMX8MQ_CLK_NAND_USDHC_BUS>,
<&clk IMX8MQ_CLK_USDHC2_ROOT>;
clock-names = "ipg", "ahb", "per";
--
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
* [PATCH 2/3] arm64: dts: imx8mm: Use correct clock for usdhc's ipg clk
From: Anson Huang @ 2019-09-19 5:05 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, daniel.lezcano, ping.bai, daniel.baluta, jun.li,
l.stach, abel.vesa, andrew.smirnov, angus, ccaione, agx,
devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1568869559-28611-1-git-send-email-Anson.Huang@nxp.com>
On i.MX8MM, usdhc's ipg clock is from IMX8MM_CLK_IPG_ROOT,
assign it explicitly instead of using IMX8MM_CLK_DUMMY.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 7c4dcce..8aafad2 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -694,7 +694,7 @@
compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
reg = <0x30b40000 0x10000>;
interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MM_CLK_DUMMY>,
+ clocks = <&clk IMX8MM_CLK_IPG_ROOT>,
<&clk IMX8MM_CLK_NAND_USDHC_BUS>,
<&clk IMX8MM_CLK_USDHC1_ROOT>;
clock-names = "ipg", "ahb", "per";
@@ -710,7 +710,7 @@
compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
reg = <0x30b50000 0x10000>;
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MM_CLK_DUMMY>,
+ clocks = <&clk IMX8MM_CLK_IPG_ROOT>,
<&clk IMX8MM_CLK_NAND_USDHC_BUS>,
<&clk IMX8MM_CLK_USDHC2_ROOT>;
clock-names = "ipg", "ahb", "per";
@@ -724,7 +724,7 @@
compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
reg = <0x30b60000 0x10000>;
interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MM_CLK_DUMMY>,
+ clocks = <&clk IMX8MM_CLK_IPG_ROOT>,
<&clk IMX8MM_CLK_NAND_USDHC_BUS>,
<&clk IMX8MM_CLK_USDHC3_ROOT>;
clock-names = "ipg", "ahb", "per";
--
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
* [PATCH v2 0/2] crypto: sun4i-ss: Enable power management
From: Corentin Labbe @ 2019-09-19 5:10 UTC (permalink / raw)
To: davem, herbert, mripard, wens
Cc: linux-sunxi, Corentin Labbe, linux-crypto, linux-arm-kernel,
linux-kernel
Hello
This serie enables power management in the sun4i-ss driver.
Regards
Changes since v1:
- Fixed style in patch #1
- Check more return code of PM functions
- Add PM support in hash/prng
- reworked the probe order of PM functions and the PM strategy
Corentin Labbe (2):
crypto: sun4i-ss: simplify enable/disable of the device
crypto: sun4i-ss: enable pm_runtime
drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 9 ++
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 157 ++++++++++++++++------
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 12 ++
drivers/crypto/sunxi-ss/sun4i-ss-prng.c | 9 +-
drivers/crypto/sunxi-ss/sun4i-ss.h | 2 +
5 files changed, 149 insertions(+), 40 deletions(-)
--
2.21.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] crypto: sun4i-ss: simplify enable/disable of the device
From: Corentin Labbe @ 2019-09-19 5:10 UTC (permalink / raw)
To: davem, herbert, mripard, wens
Cc: linux-sunxi, Corentin Labbe, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <20190919051035.4111-1-clabbe.montjoie@gmail.com>
This patch regroups resource enabling/disabling in dedicated function.
This simplify error handling and will permit to support power
management.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
---
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 77 +++++++++++++++----------
1 file changed, 46 insertions(+), 31 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 9aa6fe081a27..6c2db5d83b06 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -223,6 +223,45 @@ static struct sun4i_ss_alg_template ss_algs[] = {
#endif
};
+static void sun4i_ss_disable(struct sun4i_ss_ctx *ss)
+{
+ if (ss->reset)
+ reset_control_assert(ss->reset);
+
+ clk_disable_unprepare(ss->ssclk);
+ clk_disable_unprepare(ss->busclk);
+}
+
+static int sun4i_ss_enable(struct sun4i_ss_ctx *ss)
+{
+ int err;
+
+ err = clk_prepare_enable(ss->busclk);
+ if (err) {
+ dev_err(ss->dev, "Cannot prepare_enable busclk\n");
+ goto err_enable;
+ }
+
+ err = clk_prepare_enable(ss->ssclk);
+ if (err) {
+ dev_err(ss->dev, "Cannot prepare_enable ssclk\n");
+ goto err_enable;
+ }
+
+ if (ss->reset) {
+ err = reset_control_deassert(ss->reset);
+ if (err) {
+ dev_err(ss->dev, "Cannot deassert reset control\n");
+ goto err_enable;
+ }
+ }
+
+ return err;
+err_enable:
+ sun4i_ss_disable(ss);
+ return err;
+}
+
static int sun4i_ss_probe(struct platform_device *pdev)
{
u32 v;
@@ -269,17 +308,9 @@ static int sun4i_ss_probe(struct platform_device *pdev)
ss->reset = NULL;
}
- /* Enable both clocks */
- err = clk_prepare_enable(ss->busclk);
- if (err) {
- dev_err(&pdev->dev, "Cannot prepare_enable busclk\n");
- return err;
- }
- err = clk_prepare_enable(ss->ssclk);
- if (err) {
- dev_err(&pdev->dev, "Cannot prepare_enable ssclk\n");
- goto error_ssclk;
- }
+ err = sun4i_ss_enable(ss);
+ if (err)
+ goto error_enable;
/*
* Check that clock have the correct rates given in the datasheet
@@ -288,16 +319,7 @@ static int sun4i_ss_probe(struct platform_device *pdev)
err = clk_set_rate(ss->ssclk, cr_mod);
if (err) {
dev_err(&pdev->dev, "Cannot set clock rate to ssclk\n");
- goto error_clk;
- }
-
- /* Deassert reset if we have a reset control */
- if (ss->reset) {
- err = reset_control_deassert(ss->reset);
- if (err) {
- dev_err(&pdev->dev, "Cannot deassert reset control\n");
- goto error_clk;
- }
+ goto error_enable;
}
/*
@@ -387,12 +409,8 @@ static int sun4i_ss_probe(struct platform_device *pdev)
break;
}
}
- if (ss->reset)
- reset_control_assert(ss->reset);
-error_clk:
- clk_disable_unprepare(ss->ssclk);
-error_ssclk:
- clk_disable_unprepare(ss->busclk);
+error_enable:
+ sun4i_ss_disable(ss);
return err;
}
@@ -416,10 +434,7 @@ static int sun4i_ss_remove(struct platform_device *pdev)
}
writel(0, ss->base + SS_CTL);
- if (ss->reset)
- reset_control_assert(ss->reset);
- clk_disable_unprepare(ss->busclk);
- clk_disable_unprepare(ss->ssclk);
+ sun4i_ss_disable(ss);
return 0;
}
--
2.21.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] crypto: sun4i-ss: enable pm_runtime
From: Corentin Labbe @ 2019-09-19 5:10 UTC (permalink / raw)
To: davem, herbert, mripard, wens
Cc: linux-sunxi, Corentin Labbe, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <20190919051035.4111-1-clabbe.montjoie@gmail.com>
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 | 9 +++
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 94 +++++++++++++++++++----
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 12 +++
drivers/crypto/sunxi-ss/sun4i-ss-prng.c | 9 ++-
drivers/crypto/sunxi-ss/sun4i-ss.h | 2 +
5 files changed, 110 insertions(+), 16 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
index fa4b1b47822e..c9799cbe0530 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
@@ -480,6 +480,7 @@ int sun4i_ss_cipher_init(struct crypto_tfm *tfm)
struct sun4i_tfm_ctx *op = crypto_tfm_ctx(tfm);
struct sun4i_ss_alg_template *algt;
const char *name = crypto_tfm_alg_name(tfm);
+ int err;
memset(op, 0, sizeof(struct sun4i_tfm_ctx));
@@ -497,13 +498,21 @@ int sun4i_ss_cipher_init(struct crypto_tfm *tfm)
return PTR_ERR(op->fallback_tfm);
}
+ err = pm_runtime_get_sync(op->ss->dev);
+ if (err < 0)
+ goto error_pm;
return 0;
+error_pm:
+ crypto_free_sync_skcipher(op->fallback_tfm);
+ return err;
}
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(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 6c2db5d83b06..311c2653a9c3 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -44,7 +44,8 @@ static struct sun4i_ss_alg_template ss_algs[] = {
.cra_blocksize = MD5_HMAC_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct sun4i_req_ctx),
.cra_module = THIS_MODULE,
- .cra_init = sun4i_hash_crainit
+ .cra_init = sun4i_hash_crainit,
+ .cra_exit = sun4i_hash_craexit
}
}
}
@@ -70,7 +71,8 @@ static struct sun4i_ss_alg_template ss_algs[] = {
.cra_blocksize = SHA1_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct sun4i_req_ctx),
.cra_module = THIS_MODULE,
- .cra_init = sun4i_hash_crainit
+ .cra_init = sun4i_hash_crainit,
+ .cra_exit = sun4i_hash_craexit
}
}
}
@@ -262,6 +264,61 @@ static int sun4i_ss_enable(struct sun4i_ss_ctx *ss)
return err;
}
+/*
+ * Power management strategy: The device is suspended unless a TFM exists for
+ * one of the algorithms proposed by this driver.
+ */
+#if defined(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)
+};
+
+/*
+ * When power management is enabled, this function enables the PM and set the
+ * device as suspended
+ * When power management is disabled, this function just enables the device
+ */
+static int sun4i_ss_pm_init(struct sun4i_ss_ctx *ss)
+{
+ int err;
+
+ pm_runtime_use_autosuspend(ss->dev);
+ pm_runtime_set_autosuspend_delay(ss->dev, 2000);
+
+ err = pm_runtime_set_suspended(ss->dev);
+ if (err)
+ return err;
+ pm_runtime_enable(ss->dev);
+#if !defined(CONFIG_PM)
+ err = sun4i_ss_enable(ss);
+#endif
+ return err;
+}
+
+static void sun4i_ss_pm_exit(struct sun4i_ss_ctx *ss)
+{
+ pm_runtime_disable(ss->dev);
+#if !defined(CONFIG_PM)
+ sun4i_ss_disable(ss);
+#endif
+}
+
static int sun4i_ss_probe(struct platform_device *pdev)
{
u32 v;
@@ -308,10 +365,6 @@ static int sun4i_ss_probe(struct platform_device *pdev)
ss->reset = NULL;
}
- err = sun4i_ss_enable(ss);
- if (err)
- goto error_enable;
-
/*
* Check that clock have the correct rates given in the datasheet
* Try to set the clock to the maximum allowed
@@ -319,7 +372,7 @@ static int sun4i_ss_probe(struct platform_device *pdev)
err = clk_set_rate(ss->ssclk, cr_mod);
if (err) {
dev_err(&pdev->dev, "Cannot set clock rate to ssclk\n");
- goto error_enable;
+ return err;
}
/*
@@ -347,12 +400,26 @@ static int sun4i_ss_probe(struct platform_device *pdev)
dev_warn(&pdev->dev, "Clock ss is at %lu (%lu MHz) (must be <= %lu)\n",
cr, cr / 1000000, cr_mod);
+ ss->dev = &pdev->dev;
+ platform_set_drvdata(pdev, ss);
+
+ spin_lock_init(&ss->slock);
+
+ err = sun4i_ss_pm_init(ss);
+ if (err)
+ return err;
+
/*
* Datasheet named it "Die Bonding ID"
* I expect to be a sort of Security System Revision number.
* Since the A80 seems to have an other version of SS
* this info could be useful
*/
+
+ err = pm_runtime_get_sync(ss->dev);
+ if (err < 0)
+ goto error_pm;
+
writel(SS_ENABLED, ss->base + SS_CTL);
v = readl(ss->base + SS_CTL);
v >>= 16;
@@ -360,9 +427,7 @@ static int sun4i_ss_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Die ID %d\n", v);
writel(0, ss->base + SS_CTL);
- ss->dev = &pdev->dev;
-
- spin_lock_init(&ss->slock);
+ pm_runtime_put_sync(ss->dev);
for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
ss_algs[i].ss = ss;
@@ -392,7 +457,6 @@ static int sun4i_ss_probe(struct platform_device *pdev)
break;
}
}
- platform_set_drvdata(pdev, ss);
return 0;
error_alg:
i--;
@@ -409,8 +473,8 @@ static int sun4i_ss_probe(struct platform_device *pdev)
break;
}
}
-error_enable:
- sun4i_ss_disable(ss);
+error_pm:
+ sun4i_ss_pm_exit(ss);
return err;
}
@@ -433,8 +497,7 @@ static int sun4i_ss_remove(struct platform_device *pdev)
}
}
- writel(0, ss->base + SS_CTL);
- sun4i_ss_disable(ss);
+ sun4i_ss_pm_exit(ss);
return 0;
}
@@ -449,6 +512,7 @@ static struct platform_driver sun4i_ss_driver = {
.remove = sun4i_ss_remove,
.driver = {
.name = "sun4i-ss",
+ .pm = &sun4i_ss_pm_ops,
.of_match_table = a20ss_crypto_of_match_table,
},
};
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index fcffba5ef927..9930c9ce8971 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -19,17 +19,29 @@ int sun4i_hash_crainit(struct crypto_tfm *tfm)
struct sun4i_tfm_ctx *op = crypto_tfm_ctx(tfm);
struct ahash_alg *alg = __crypto_ahash_alg(tfm->__crt_alg);
struct sun4i_ss_alg_template *algt;
+ int err;
memset(op, 0, sizeof(struct sun4i_tfm_ctx));
algt = container_of(alg, struct sun4i_ss_alg_template, alg.hash);
op->ss = algt->ss;
+ err = pm_runtime_get_sync(op->ss->dev);
+ if (err < 0)
+ return err;
+
crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
sizeof(struct sun4i_req_ctx));
return 0;
}
+void sun4i_hash_craexit(struct crypto_tfm *tfm)
+{
+ struct sun4i_tfm_ctx *op = crypto_tfm_ctx(tfm);
+
+ pm_runtime_put(op->ss->dev);
+}
+
/* sun4i_hash_init: initialize request context */
int sun4i_hash_init(struct ahash_request *areq)
{
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-prng.c b/drivers/crypto/sunxi-ss/sun4i-ss-prng.c
index 63d636424161..729aafdbea84 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-prng.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-prng.c
@@ -17,7 +17,7 @@ int sun4i_ss_prng_generate(struct crypto_rng *tfm, const u8 *src,
{
struct sun4i_ss_alg_template *algt;
struct rng_alg *alg = crypto_rng_alg(tfm);
- int i;
+ int i, err;
u32 v;
u32 *data = (u32 *)dst;
const u32 mode = SS_OP_PRNG | SS_PRNG_CONTINUE | SS_ENABLED;
@@ -28,6 +28,10 @@ int sun4i_ss_prng_generate(struct crypto_rng *tfm, const u8 *src,
algt = container_of(alg, struct sun4i_ss_alg_template, alg.rng);
ss = algt->ss;
+ err = pm_runtime_get_sync(ss->dev);
+ if (err < 0)
+ return err;
+
spin_lock_bh(&ss->slock);
writel(mode, ss->base + SS_CTL);
@@ -52,5 +56,8 @@ int sun4i_ss_prng_generate(struct crypto_rng *tfm, const u8 *src,
writel(0, ss->base + SS_CTL);
spin_unlock_bh(&ss->slock);
+
+ pm_runtime_put(ss->dev);
+
return 0;
}
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss.h b/drivers/crypto/sunxi-ss/sun4i-ss.h
index 35a27a7145f8..60425ac75d90 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss.h
+++ b/drivers/crypto/sunxi-ss/sun4i-ss.h
@@ -22,6 +22,7 @@
#include <linux/scatterlist.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/pm_runtime.h>
#include <crypto/md5.h>
#include <crypto/skcipher.h>
#include <crypto/sha.h>
@@ -177,6 +178,7 @@ struct sun4i_req_ctx {
};
int sun4i_hash_crainit(struct crypto_tfm *tfm);
+void sun4i_hash_craexit(struct crypto_tfm *tfm);
int sun4i_hash_init(struct ahash_request *areq);
int sun4i_hash_update(struct ahash_request *areq);
int sun4i_hash_final(struct ahash_request *areq);
--
2.21.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 0/6] arm64: dts: rockchip: ROC-PC fixes
From: Jagan Teki @ 2019-09-19 5:28 UTC (permalink / raw)
To: Heiko Stuebner, Levin Du, Akash Gajjar, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-rockchip, Jagan Teki, Da Xue,
linux-amarula, linux-arm-kernel
This series is trying to fix the Linux boot and other
regulators stuff for ROC-RK3399-PC board.
patch 1: attach pinctrl to pwm2 pin
patch 2-4: libretech naming conventions
patch 5-6: regulator renaming, input rails fixes
Any inputs?
Jagan.
Jagan Teki (6):
arm64: dts: rockchip: Fix rk3399-roc-pc pwm2 pin
dt-bindings: arm: rockchip: Use libretech for roc-pc binding
arm64: dts: rockchip: Use libretech model, compatible for ROC-PC
arm64: dts: rockchip: Rename roc-pc with libretech notation
arm64: dts: rockchip: Rename vcc12v_sys into dc_12v for roc-rk3399-pc
arm64: dts: rockchip: Fix roc-rk3399-pc regulator input rails
.../devicetree/bindings/arm/rockchip.yaml | 11 +++---
arch/arm64/boot/dts/rockchip/Makefile | 2 +-
...dts => rk3399-libretech-roc-rk3399-pc.dts} | 38 ++++++++++---------
3 files changed, 27 insertions(+), 24 deletions(-)
rename arch/arm64/boot/dts/rockchip/{rk3399-roc-pc.dts => rk3399-libretech-roc-rk3399-pc.dts} (95%)
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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