* Re: [RESEND PATCH v6 6/7] gpiolib: add new ioctl() for monitoring changes in line info
From: Linus Walleij @ 2020-02-20 15:03 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Arnd Bergmann, Kent Gibson, Andy Shevchenko,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Bartosz Golaszewski
In-Reply-To: <CAMRc=MfkbJ=zTvgpaxFC7L7APEhfC7J_PcncGaQ_AQUA9uw2Fw@mail.gmail.com>
On Wed, Feb 12, 2020 at 12:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > On Tue, Feb 11, 2020 at 10:19 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > A question:
> >
> > Bartosz, since you know about possible impacts on userspace,
> > since this code use the preferred ktime_get_ns() rather than
> > ktime_get_ns_real(), what happens if we just patch the other
> > event timestamp to use ktime_get_ns() instead, so we use the
> > same everywhere?
> >
> > If it's fine I'd like to just toss in a patch for that as well.
> >
>
> Arnd pointed out it would be an incompatible ABI change[1].
Yeah, I was thinking more about this specific answer from Arnd:
> "It is an incompatible ABI change, the question here is whether anyone
> actually cares. If nothing relies on the timestamps being in
> CLOCK_REALTIME domain, then it can be changed, the question
> is just how you want to prove that this is the case."
So the question is if userspace really cares.
What happens with libgpiod or users of it? Are they assuming
the weirdness of CLOCK_REALTIME, or are they simply assuming
something that is monotonic increasing and just lucky that they
didn't run into anything jumping backwards in time even though
they *could*.
I think I'll propose a change and see what people say.
> However - I asked Khouloud who's working on v2 of the line event
> interface to use ktime_get_ns().
That's great!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [Xen-devel] [PATCH] rwlock: allow recursive read locking when already locked in write mode
From: Jan Beulich @ 2020-02-20 15:02 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Jürgen Groß, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
xen-devel
In-Reply-To: <20200220141117.GK4679@Air-de-Roger>
On 20.02.2020 15:11, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
>> Another option is to use the recurse_cpu field of the
>> associated spin lock: The field is used for recursive locks
>> only, and hence the only conflict would be with
>> _spin_is_locked(), which we don't (and in the future then
>> also shouldn't) use on this lock.
>
> I looked into that also, but things get more complicated AFAICT, as it's
> not possible to atomically fetch the state of the lock and the owner
> CPU at the same time. Neither you could set the LOCKED bit and the CPU
> at the same time.
There's no need to atomically fetch both afaics: The field is
valid only if the LOCKED bit is set. And when reading the
field you only care about the value being equal to
smp_processor_id(), i.e. it is fine to set LOCKED before
updating the CPU field on lock, and to reset the CPU field to
SPINLOCK_NO_CPU (or whatever it's called) before clearing
LOCKED.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] xilinx_spips: Correct the number of dummy cycles for the FAST_READ_4 cmd
From: Peter Maydell @ 2020-02-20 15:02 UTC (permalink / raw)
To: Edgar E. Iglesias
Cc: Sai Pavan Boddu, Francisco Iglesias, Alistair Francis,
QEMU Developers, Edgar Iglesias, Cédric Le Goater,
Alistair Francis
In-Reply-To: <20200216160413.GF22292@toto>
On Wed, 19 Feb 2020 at 01:12, Edgar E. Iglesias
<edgar.iglesias@xilinx.com> wrote:
>
> On Tue, Feb 18, 2020 at 12:33:50PM +0100, Francisco Iglesias wrote:
> > From: Francisco Iglesias <francisco.iglesias@xilinx.com>
> >
> > Correct the number of dummy cycles required by the FAST_READ_4 command (to
> > be eight, one dummy byte).
> >
> > Fixes: ef06ca3946 ("xilinx_spips: Add support for RX discard and RX drain")
> > Suggested-by: Cédric Le Goater <clg@kaod.org>
> > Signed-off-by: Francisco Iglesias <frasse.iglesias@gmail.com>
>
> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Applied to target-arm.next, thanks.
-- PMM
^ permalink raw reply
* [PATCH] Set default CONNECTIVITY_CHECK_URIS to https://www.yoctoproject.org/
From: Nataliya Korovkina @ 2020-02-20 15:03 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Nataliya Korovkina <malus.brandywine@gmail.com>
---
meta/conf/distro/include/default-distrovars.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/default-distrovars.inc b/meta/conf/distro/include/default-distrovars.inc
index 433d4b6651..6c9155b2ae 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -48,4 +48,4 @@ KERNEL_IMAGETYPES ??= "${KERNEL_IMAGETYPE}"
# fetch from the network (and warn you if not). To disable the test set
# the variable to be empty.
# Git example url: git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=master
-CONNECTIVITY_CHECK_URIS ?= "https://www.example.com/"
+CONNECTIVITY_CHECK_URIS ?= "https://www.yoctoproject.org/"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints
From: Qais Yousef @ 2020-02-20 15:03 UTC (permalink / raw)
To: chris hyser
Cc: Parth Shah, vincent.guittot, patrick.bellasi, valentin.schneider,
dhaval.giani, dietmar.eggemann, linux-kernel, peterz, mingo,
pavel, qperret, David.Laight, pjt, tj
In-Reply-To: <a332d633-7826-b85d-5d9f-5e34f9de084a@oracle.com>
On 02/20/20 09:30, chris hyser wrote:
> > The below diff works out well enough in-order to align permission checks
> > with NICE.
> >
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 2bfcff5623f9..ef4a397c9170 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -4878,6 +4878,10 @@ static int __sched_setscheduler(struct task_struct *p,
> > return -EINVAL;
> > if (attr->sched_latency_nice < MIN_LATENCY_NICE)
> > return -EINVAL;
> > + /* Use the same security checks as NICE */
> > + if (attr->sched_latency_nice < p->latency_nice &&
> > + !can_nice(p, attr->sched_latency_nice))
> > + return -EPERM;
> > }
> >
> > if (pi)
> >
> > With the above in effect,
> > A non-root user can only increase the value upto +19, and once increased
> > cannot be decreased. e.g., a user once sets the value latency_nice = 19,
> > the same user cannot set the value latency_nice = 18. This is the same
> > effect as with NICE.
> >
> > Is such permission checks required?
> >
> > Unlike NICE, we are going to use latency_nice for scheduler hints only, and
> > so won't it make more sense to allow a user to increase/decrease the values
> > of their owned tasks?
>
> Whether called a hint or not, it is a trade-off to reduce latency of select
> tasks at the expense of the throughput of the other tasks in the the system.
Does it actually affect the throughput of the other tasks? I thought this will
allow the scheduler to reduce latencies, for instance, when selecting which cpu
it should land on. I can't see how this could hurt other tasks.
Can you expand on the scenario you have in mind please?
> If any of the other tasks belong to other users, you would presumably
> require permission.
AFAIU security_task_setscheduler() will only allow a change if the task is
changing its own attribute value or has SYS_CAP_NICE.
If you're able to change the attribute of another task, then its not only
latency_nice that's broken here.
Thanks
--
Qais Yousef
^ permalink raw reply
* [PATCH v6 04/16] x86/mm: Use helper fault_signal_pending()
From: Peter Xu @ 2020-02-20 15:02 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Peter Xu, Martin Cracauer, Mike Rapoport, Hugh Dickins,
Jerome Glisse, Kirill A . Shutemov, Matthew Wilcox,
Pavel Emelyanov, Brian Geffon, Maya Gokhale, Denis Plotnikov,
Andrea Arcangeli, Johannes Weiner, Dr . David Alan Gilbert,
Linus Torvalds, Mike Kravetz, Marty McFadden, David Hildenbrand,
Bobby Powers, Mel Gorman
In-Reply-To: <20200220145432.4561-1-peterx@redhat.com>
Let's move the fatal signal check even earlier so that we can directly
use the new fault_signal_pending() in x86 mm code.
Signed-off-by: Peter Xu <peterx@redhat.com>
---
arch/x86/mm/fault.c | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index fa4ea09593ab..6a00bc8d047f 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1442,27 +1442,25 @@ void do_user_addr_fault(struct pt_regs *regs,
fault = handle_mm_fault(vma, address, flags);
major |= fault & VM_FAULT_MAJOR;
+ /* Quick path to respond to signals */
+ if (fault_signal_pending(fault, regs)) {
+ if (!user_mode(regs))
+ no_context(regs, hw_error_code, address, SIGBUS,
+ BUS_ADRERR);
+ return;
+ }
+
/*
* If we need to retry the mmap_sem has already been released,
* and if there is a fatal signal pending there is no guarantee
* that we made any progress. Handle this case first.
*/
- if (unlikely(fault & VM_FAULT_RETRY)) {
+ if (unlikely((fault & VM_FAULT_RETRY) &&
+ (flags & FAULT_FLAG_ALLOW_RETRY))) {
/* Retry at most once */
- if (flags & FAULT_FLAG_ALLOW_RETRY) {
- flags &= ~FAULT_FLAG_ALLOW_RETRY;
- flags |= FAULT_FLAG_TRIED;
- if (!fatal_signal_pending(tsk))
- goto retry;
- }
-
- /* User mode? Just return to handle the fatal exception */
- if (flags & FAULT_FLAG_USER)
- return;
-
- /* Not returning to user mode? Handle exceptions or die: */
- no_context(regs, hw_error_code, address, SIGBUS, BUS_ADRERR);
- return;
+ flags &= ~FAULT_FLAG_ALLOW_RETRY;
+ flags |= FAULT_FLAG_TRIED;
+ goto retry;
}
up_read(&mm->mmap_sem);
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v3 4/5] sched/pelt: Add a new runnable average signal
From: Dietmar Eggemann @ 2020-02-20 15:04 UTC (permalink / raw)
To: Vincent Guittot, mingo, peterz, juri.lelli, rostedt, bsegall,
mgorman, linux-kernel
Cc: pauld, parth, valentin.schneider, hdanton
In-Reply-To: <20200219125513.8953-1-vincent.guittot@linaro.org>
On 19/02/2020 13:55, Vincent Guittot wrote:
> Now that runnable_load_avg has been removed, we can replace it by a new
> signal that will highlight the runnable pressure on a cfs_rq. This signal
> track the waiting time of tasks on rq and can help to better define the
> state of rqs.
>
> At now, only util_avg is used to define the state of a rq:
> A rq with more that around 80% of utilization and more than 1 tasks is
> considered as overloaded.
Don't we make the distinction of overutilized and overloaded?
update_sg_lb_stats(), SG_OVERUTILIZED and SG_OVERLOAD
[...]
> @@ -310,13 +325,14 @@ int __update_load_avg_cfs_rq(u64 now, struct cfs_rq *cfs_rq)
> * util_sum = cpu_scale * load_sum
> * runnable_sum = util_sum
> *
> - * load_avg is not supported and meaningless.
> + * load_avg and runnable_load_avg are not supported and meaningless.
Nit pick:
s/runnable_load_avg/runnable_avg
[...]
> + * load_avg and runnable_load_avg are not supported and meaningless.
> *
> */
>
> int update_dl_rq_load_avg(u64 now, struct rq *rq, int running)
[...]
> - * load_avg is not supported and meaningless.
> + * load_avg and runnable_load_avg are not supported and meaningless.
> *
> */
>
> @@ -389,9 +406,11 @@ int update_irq_load_avg(struct rq *rq, u64 running)
[...]
^ permalink raw reply
* Re: [PATCH v2 0/2] hw/arm/xilinx_zynq: Fix USB port instantiation
From: Peter Maydell @ 2020-02-20 15:05 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Alistair Francis, Gerd Hoffmann, qemu-arm, QEMU Developers
In-Reply-To: <20200215122354.13706-1-linux@roeck-us.net>
On Sat, 15 Feb 2020 at 12:23, Guenter Roeck <linux@roeck-us.net> wrote:
>
> USB ports on Xilinx Zync must be instantiated as TYPE_CHIPIDEA to work.
> Linux expects and checks various chipidea registers, which do not exist
> with the basic ehci emulation. This patch series fixes the problem.
>
> The first patch in the series fixes the actual problem.
>
> The second patch removes the now obsolete explicit Xilinx
> support from the EHCI code.
>
> v2: Introduced summary
>
> ----------------------------------------------------------------
> Guenter Roeck (2):
> hw/arm/xilinx_zynq: Fix USB port instantiation
> hw/usb/hcd-ehci-sysbus: Remove obsolete xlnx,ps7-usb class
Xilinx folks -- could you provide a reviewed-by or acked-by
for this series, please?
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH v4 1/3] btrfs: backref: Introduce the skeleton of btrfs_backref_iter
From: Josef Bacik @ 2020-02-20 15:05 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs; +Cc: Johannes Thumshirn
In-Reply-To: <20200218065649.126255-2-wqu@suse.com>
On 2/18/20 1:56 AM, Qu Wenruo wrote:
> Due to the complex nature of btrfs extent tree, when we want to iterate
> all backrefs of one extent, it involves quite a lot of work, like
> searching the EXTENT_ITEM/METADATA_ITEM, iteration through inline and keyed
> backrefs.
>
> Normally this would result pretty complex code, something like:
> btrfs_search_slot()
> /* Ensure we are at EXTENT_ITEM/METADATA_ITEM */
> while (1) { /* Loop for extent tree items */
> while (ptr < end) { /* Loop for inlined items */
> /* REAL WORK HERE */
> }
> next:
> ret = btrfs_next_item()
> /* Ensure we're still at keyed item for specified bytenr */
> }
>
> The idea of btrfs_backref_iter is to avoid such complex and hard to
> read code structure, but something like the following:
>
> iter = btrfs_backref_iter_alloc();
> ret = btrfs_backref_iter_start(iter, bytenr);
> if (ret < 0)
> goto out;
> for (; ; ret = btrfs_backref_iter_next(iter)) {
> /* REAL WORK HERE */
> }
> out:
> btrfs_backref_iter_free(iter);
>
> This patch is just the skeleton + btrfs_backref_iter_start() code.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* [MODERATED] Re: [PATCH 0/2] more sampling fun 0
From: Greg KH @ 2020-02-20 15:05 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220145510.GE160988@tassilo.jf.intel.com>
On Thu, Feb 20, 2020 at 06:55:10AM -0800, speck for Andi Kleen wrote:
> > Then we need to stop using RDRAND internally for our "give me a random
> > number api" which has spread to more and more parts of the kernel.
>
> Only if that API is called frequently enough. AFAIK it is not.
It's called by all sorts of places in the kernel today.
> Normally it's used for rare rekeying of hash tables etc., which
> doesn't happen very often.
"normally" :)
> > Here's a patch that does so:
> > https://lore.kernel.org/lkml/20200216161836.1976-1-Jason@zx2c4.com/
> > which I'm going to advise get merged now and backported to the stable
> > branches.
>
> Don't see any reason at this point. Only do it if there's an actual
> indication of a problem.
It's slow, why wouldn't we stop using it as we already have a much
faster call.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Marc Zyngier @ 2020-02-20 15:06 UTC (permalink / raw)
To: minyard
Cc: Will Deacon, Catalin Marinas, linux-arm-kernel, Corey Minyard,
linux-kernel, Corey Minyard
In-Reply-To: <20200220145048.GH3704@minyard.net>
On 2020-02-20 14:50, Corey Minyard wrote:
> On Thu, Feb 20, 2020 at 02:21:36PM +0000, Marc Zyngier wrote:
>> On 2020-02-19 15:24, minyard@acm.org wrote:
>> > From: Corey Minyard <cminyard@mvista.com>
>>
>> [...]
>>
>> > After studying the EL0 handling for this, I realized an issue with using
>> > MDSCR to check if single step is enabled: it can be expensive on a VM.
>> > So check the task flag first to see if single step is enabled. Then
>> > check MDSCR if the task flag is set.
>>
>> Very tangential remark: I'd really like people *not* to try and
>> optimize
>> Linux based on the behaviour of a hypervisor. In general, reading a
>> system register is fast, and the fact that it traps on a given
>> hypervisor
>> at some point may not be true in the future, nor be a valid assumption
>> across hypervisors.
>
> Normally I would agree, but I based this upon git commit
> https://github.com/torvalds/linux/commit/2a2830703a2371b47f7b50b1d35cb15dc0e2b717
> which seemed to say that it was a significant enough factor to do in
> the
> EL0 case.
And that's a blast from a distant past. Hypervisors have changed
drastically
over these 6 years, and I'm still sitting on a bunch of patches that
*could*
change the way MDSCR_EL1 is handled.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v2 0/2] hw/arm/xilinx_zynq: Fix USB port instantiation
From: Peter Maydell @ 2020-02-20 15:05 UTC (permalink / raw)
To: Guenter Roeck
Cc: Edgar E . Iglesias, Alistair Francis, Gerd Hoffmann, qemu-arm,
QEMU Developers
In-Reply-To: <20200215122354.13706-1-linux@roeck-us.net>
On Sat, 15 Feb 2020 at 12:23, Guenter Roeck <linux@roeck-us.net> wrote:
>
> USB ports on Xilinx Zync must be instantiated as TYPE_CHIPIDEA to work.
> Linux expects and checks various chipidea registers, which do not exist
> with the basic ehci emulation. This patch series fixes the problem.
>
> The first patch in the series fixes the actual problem.
>
> The second patch removes the now obsolete explicit Xilinx
> support from the EHCI code.
>
> v2: Introduced summary
>
> ----------------------------------------------------------------
> Guenter Roeck (2):
> hw/arm/xilinx_zynq: Fix USB port instantiation
> hw/usb/hcd-ehci-sysbus: Remove obsolete xlnx,ps7-usb class
Xilinx folks -- could you provide a reviewed-by or acked-by
for this series, please?
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Marc Zyngier @ 2020-02-20 15:06 UTC (permalink / raw)
To: minyard
Cc: Corey Minyard, Catalin Marinas, linux-kernel, Will Deacon,
Corey Minyard, linux-arm-kernel
In-Reply-To: <20200220145048.GH3704@minyard.net>
On 2020-02-20 14:50, Corey Minyard wrote:
> On Thu, Feb 20, 2020 at 02:21:36PM +0000, Marc Zyngier wrote:
>> On 2020-02-19 15:24, minyard@acm.org wrote:
>> > From: Corey Minyard <cminyard@mvista.com>
>>
>> [...]
>>
>> > After studying the EL0 handling for this, I realized an issue with using
>> > MDSCR to check if single step is enabled: it can be expensive on a VM.
>> > So check the task flag first to see if single step is enabled. Then
>> > check MDSCR if the task flag is set.
>>
>> Very tangential remark: I'd really like people *not* to try and
>> optimize
>> Linux based on the behaviour of a hypervisor. In general, reading a
>> system register is fast, and the fact that it traps on a given
>> hypervisor
>> at some point may not be true in the future, nor be a valid assumption
>> across hypervisors.
>
> Normally I would agree, but I based this upon git commit
> https://github.com/torvalds/linux/commit/2a2830703a2371b47f7b50b1d35cb15dc0e2b717
> which seemed to say that it was a significant enough factor to do in
> the
> EL0 case.
And that's a blast from a distant past. Hypervisors have changed
drastically
over these 6 years, and I'm still sitting on a bunch of patches that
*could*
change the way MDSCR_EL1 is handled.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH v6 6/7] gpiolib: add new ioctl() for monitoring changes in line info
From: Bartosz Golaszewski @ 2020-02-20 15:06 UTC (permalink / raw)
To: Linus Walleij
Cc: Arnd Bergmann, Kent Gibson, Andy Shevchenko,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Bartosz Golaszewski
In-Reply-To: <CACRpkdZE0F_E1o-psXdOh93j1JAS8uqT=ZOf4-mrj5WKoKcD6A@mail.gmail.com>
czw., 20 lut 2020 o 16:03 Linus Walleij <linus.walleij@linaro.org> napisał(a):
>
> On Wed, Feb 12, 2020 at 12:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > On Tue, Feb 11, 2020 at 10:19 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> > > A question:
> > >
> > > Bartosz, since you know about possible impacts on userspace,
> > > since this code use the preferred ktime_get_ns() rather than
> > > ktime_get_ns_real(), what happens if we just patch the other
> > > event timestamp to use ktime_get_ns() instead, so we use the
> > > same everywhere?
> > >
> > > If it's fine I'd like to just toss in a patch for that as well.
> > >
> >
> > Arnd pointed out it would be an incompatible ABI change[1].
>
> Yeah, I was thinking more about this specific answer from Arnd:
>
> > "It is an incompatible ABI change, the question here is whether anyone
> > actually cares. If nothing relies on the timestamps being in
> > CLOCK_REALTIME domain, then it can be changed, the question
> > is just how you want to prove that this is the case."
>
> So the question is if userspace really cares.
>
> What happens with libgpiod or users of it? Are they assuming
> the weirdness of CLOCK_REALTIME, or are they simply assuming
> something that is monotonic increasing and just lucky that they
> didn't run into anything jumping backwards in time even though
> they *could*.
>
> I think I'll propose a change and see what people say.
>
Libgpiod doesn't care about the value really - it just forwards
whatever it reads.
Bart
> > However - I asked Khouloud who's working on v2 of the line event
> > interface to use ktime_get_ns().
>
> That's great!
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 1/3] btrfs: backref: Introduce the skeleton of btrfs_backref_iter
From: Josef Bacik @ 2020-02-20 15:07 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs; +Cc: Johannes Thumshirn
In-Reply-To: <20200218090129.134450-2-wqu@suse.com>
On 2/18/20 4:01 AM, Qu Wenruo wrote:
> Due to the complex nature of btrfs extent tree, when we want to iterate
> all backrefs of one extent, it involves quite a lot of work, like
> searching the EXTENT_ITEM/METADATA_ITEM, iteration through inline and keyed
> backrefs.
>
> Normally this would result pretty complex code, something like:
> btrfs_search_slot()
> /* Ensure we are at EXTENT_ITEM/METADATA_ITEM */
> while (1) { /* Loop for extent tree items */
> while (ptr < end) { /* Loop for inlined items */
> /* REAL WORK HERE */
> }
> next:
> ret = btrfs_next_item()
> /* Ensure we're still at keyed item for specified bytenr */
> }
>
> The idea of btrfs_backref_iter is to avoid such complex and hard to
> read code structure, but something like the following:
>
> iter = btrfs_backref_iter_alloc();
> ret = btrfs_backref_iter_start(iter, bytenr);
> if (ret < 0)
> goto out;
> for (; ; ret = btrfs_backref_iter_next(iter)) {
> /* REAL WORK HERE */
> }
> out:
> btrfs_backref_iter_free(iter);
>
> This patch is just the skeleton + btrfs_backref_iter_start() code.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* Re: drm_dp_mst_topology.c and old compilers
From: Christoph Hellwig @ 2020-02-20 15:07 UTC (permalink / raw)
To: Paul E. McKenney
Cc: maarten.lankhorst, mripard, airlied, daniel, dri-devel,
linux-kernel
In-Reply-To: <20200220004232.GA28048@paulmck-ThinkPad-P72>
On Wed, Feb 19, 2020 at 04:42:33PM -0800, Paul E. McKenney wrote:
> - struct drm_dp_desc desc = { 0 };
> + struct drm_dp_desc desc = {{{ 0 }}};
Does:
struct drm_dp_desc desc = { };
work for your geriatric compiler?
^ permalink raw reply
* Re: [PATCH] backlight: add led-backlight driver
From: Tony Lindgren @ 2020-02-20 14:54 UTC (permalink / raw)
To: Sebastian Reichel
Cc: daniel.thompson, mpartap, jingoohan1, merlijn, kernel list,
dri-devel, martin_rysavy, nekit1000, tomi.valkeinen, Pavel Machek,
jjhiblot, linux-omap, Lee Jones, agx, linux-arm-kernel
In-Reply-To: <20200219234437.l6ac7usebu7rnzsy@earth.universe>
* Sebastian Reichel <sre@kernel.org> [200219 23:45]:
> Finally :)
>
> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Yeah thanks for your persistent effort on getting this working :)
Regards,
Tony
_______________________________________________
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] sh4: Fix PCI ISA IO memory subregion
From: Peter Maydell @ 2020-02-20 15:06 UTC (permalink / raw)
To: Guenter Roeck; +Cc: QEMU Developers, Aurelien Jarno
In-Reply-To: <20200218201050.15273-1-linux@roeck-us.net>
On Tue, 18 Feb 2020 at 20:10, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Booting the r2d machine from flash fails because flash is not discovered.
> Looking at the flattened memory tree, we see the following.
>
> FlatView #1
> AS "memory", root: system
> AS "cpu-memory-0", root: system
> AS "sh_pci_host", root: bus master container
> Root memory region: system
> 0000000000000000-000000000000ffff (prio 0, i/o): io
> 0000000000010000-0000000000ffffff (prio 0, i/o): r2d.flash @0000000000010000
>
> The overlapping memory region is sh_pci.isa, ie the ISA I/O region bridge.
> This region is initially assigned to address 0xfe240000, but overwritten
> with a write into the PCIIOBR register. This write is expected to adjust
> the PCI memory window, but not to change the region's base adddress.
>
> Peter Maydell provided the following detailed explanation.
>
> "Section 22.3.7 and in particular figure 22.3 (of "SSH7751R user's manual:
> hardware") are clear about how this is supposed to work: there is a window
> at 0xfe240000 in the system register space for PCI I/O space. When the CPU
> makes an access into that area, the PCI controller calculates the PCI
> address to use by combining bits 0..17 of the system address with the
> bits 31..18 value that the guest has put into the PCIIOBR. That is, writing
> to the PCIIOBR changes which section of the IO address space is visible in
> the 0xfe240000 window. Instead what QEMU's implementation does is move the
> window to whatever value the guest writes to the PCIIOBR register -- so if
> the guest writes 0 we put the window at 0 in system address space."
>
> Fix the problem by calling memory_region_set_alias_offset() instead of
> removing and re-adding the PCI ISA subregion on writes into PCIIOBR.
> At the same time, in sh_pci_device_realize(), don't set iobr since
> it is overwritten later anyway. Instead, pass the base address to
> memory_region_add_subregion() directly.
>
> Many thanks to Peter Maydell for the detailed problem analysis, and for
> providing suggestions on how to fix the problem.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
I'll put this in via target-arm.next, since we don't really
have a more active sh4-specific tree to send it via.
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Corey Minyard @ 2020-02-20 14:52 UTC (permalink / raw)
To: Daniel Thompson
Cc: Catalin Marinas, Will Deacon, linux-kernel, linux-arm-kernel,
Corey Minyard
In-Reply-To: <20200220140650.tryvv3ishkxduujk@holly.lan>
On Thu, Feb 20, 2020 at 02:06:50PM +0000, Daniel Thompson wrote:
> On Wed, Feb 19, 2020 at 09:24:03AM -0600, minyard@acm.org wrote:
> > From: Corey Minyard <cminyard@mvista.com>
> >
> > I was working on a single-step bug on kgdb on an ARM64 system, and I saw
> > this scenario:
> >
> > * A single step is setup to return to el1
> > * The ERET return to el1
> > * An interrupt is pending and runs before the instruction
> > * As soon as PSTATE.D (the debug disable bit) is cleared, the single
> > step happens in that location, not where it should have.
> >
> > This appears to be due to PSTATE.SS not being cleared when the exception
> > happens. Per section D.2.12.5 of the ARMv8 reference manual, that
> > appears to be incorrect, it says "As part of exception entry, the PE
> > does all of the following: ... Sets PSTATE.SS to 0."
> >
> > However, I appear to not be the first person who has noticed this. In
> > the el0-only portion of the kernel_entry macro in entry.S, I found the
> > following comment: "Ensure MDSCR_EL1.SS is clear, since we can unmask
> > debug exceptions when scheduling." Exactly the same scenario, except
> > coming from a userland single step, not a kernel one.
> >
> > As I was studying this, though, I realized that the following scenario
> > had an issue:
> >
> > * Kernel enables MDSCR.SS, MDSCR.KDE, MDSCR.MDE (unnecessary), and
> > PSTATE.SS to enable a single step in el1, for kgdb or kprobes,
> > on the current CPU's MDSCR register and the process' PSTATE.SS
> > register.
> > * Kernel returns from the exception with ERET.
> > * An interrupt or page fault happens on the instruction, causing the
> > instruction to not be run, but the exception handler runs.
> > * The exception causes the task to migrate to a new core.
> > * The return from the exception runs on a different processor now,
> > where the MDSCR values are not set up for a single step.
> > * The single step fails to happen.
> >
> > This is bad for kgdb, of course, but it seems really bad for kprobes if
> > this happens.
> >
> > To fix both these problems, rework the handling of single steps to clear
> > things out upon entry to the kernel from el1, and then to set up single
> > step when returning to el1, and not do the setup in debug-monitors.c.
> > This means that single stepping does not use
> > enable/disable_debug_monitors(); it is no longer necessary to track
> > those flags for single stepping. This is much like single stepping is
> > handled for el0. A new flag is added in pt_regs to enable single
> > stepping from el1. Unfortunately, the old value of PSTATE.SS cannot be
> > used for this because of the hardware bug mentioned earlier.
> >
> > As part of this, there is an interaction between single stepping and the
> > other users of debug monitors with the MDSCR.KDE bit. That bit has to
> > be set for both hardware breakpoints at el1 and single stepping at el1.
> > A new variable was created to store the cpu-wide value of MDSCR.KDE; the
> > single stepping code makes sure not to clear that bit on kernel entry if
> > it's set in the per-cpu variable.
> >
> > After fixing this and doing some more testing, I ran into another issue:
> >
> > * Kernel enables the pt_regs single step
> > * Kernel returns from the exception with ERET.
> > * An interrupt or page fault happens on the instruction, causing the
> > instruction to not be run, but the exception handler runs.
> > * The exception handling hits a breakpoint and stops.
> > * The user continues from the breakpoint, so the kernel is no longer
> > expecting a single step.
> > * On the return from the first exception, the single step flag in
> > pt_regs is still set, so a single step trap happens.
> > * The kernel keels over from an unexpected single step.
> >
> > There's no easy way to find the pt_regs that has the single step flag
> > set. So a thread info flag was added so that the single step could be
> > disabled in this case. Both that flag and the flag in pt_regs must be
> > set to enable a single step.
> >
> > Signed-off-by: Corey Minyard <cminyard@mvista.com>
>
> I've pointed the kgdbtest suite at this patch (and run one of the
> historically unstable test cases an extra 100 times just in case).
>
> kgdbtest hasn't got great coverage, runs the code in qemu and some
> of the strongest tests are still marked XFAIL on arm64 (for reasons
> unrelated to stepping).
>
> So the best I can say based on the above is that the test suite does not
> observe any regression (but equally no improvement). Nevertheless FWIW:
Thanks for testing this. This is not a surprise, you would either have
to have a broken processor like the one I'm using, or you would have to
have a migration occur on the instruction being single-stepped, which
would be extremely unlikely.
Since I've already gained some experience here, I'll try to look at
fixing things here for ARM64.
-corey
>
>
> Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
>
>
> Daniel.
_______________________________________________
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 05/10] ASoC: tegra: add Tegra210 based AHUB driver
From: Jon Hunter @ 2020-02-20 15:08 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-6-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Audio Hub (AHUB) comprises a collection of hardware accelerators for
> audio pre/post-processing and a programmable full crossbar (XBAR) for
> routing audio data across these accelerators in time and in parallel.
> AHUB supports multiple interfaces to I2S, DSPK, DMIC etc., XBAR is a
> switch used to configure or modify audio routing between HW accelerators
> present inside AHUB.
>
> This patch registers AHUB component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes AHUB interfaces, which can be used to connect different
> components in the ASoC layer. Currently the driver takes care of XBAR
> programming to allow audio data flow through various clients of the AHUB.
> Makefile and Kconfig support is added to allow to build the driver. The
> AHUB component can be enabled in the DT via below compatible bindings.
> - "nvidia,tegra210-ahub" for Tegra210
> - "nvidia,tegra186-ahub" for Tegra186 and Tegra194
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> sound/soc/tegra/Kconfig | 10 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra210_ahub.c | 651 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra210_ahub.h | 125 ++++++++
> 4 files changed, 788 insertions(+)
> create mode 100644 sound/soc/tegra/tegra210_ahub.c
> create mode 100644 sound/soc/tegra/tegra210_ahub.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 05/10] ASoC: tegra: add Tegra210 based AHUB driver
From: Jon Hunter @ 2020-02-20 15:08 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-6-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Audio Hub (AHUB) comprises a collection of hardware accelerators for
> audio pre/post-processing and a programmable full crossbar (XBAR) for
> routing audio data across these accelerators in time and in parallel.
> AHUB supports multiple interfaces to I2S, DSPK, DMIC etc., XBAR is a
> switch used to configure or modify audio routing between HW accelerators
> present inside AHUB.
>
> This patch registers AHUB component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes AHUB interfaces, which can be used to connect different
> components in the ASoC layer. Currently the driver takes care of XBAR
> programming to allow audio data flow through various clients of the AHUB.
> Makefile and Kconfig support is added to allow to build the driver. The
> AHUB component can be enabled in the DT via below compatible bindings.
> - "nvidia,tegra210-ahub" for Tegra210
> - "nvidia,tegra186-ahub" for Tegra186 and Tegra194
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 10 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra210_ahub.c | 651 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra210_ahub.h | 125 ++++++++
> 4 files changed, 788 insertions(+)
> create mode 100644 sound/soc/tegra/tegra210_ahub.c
> create mode 100644 sound/soc/tegra/tegra210_ahub.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v5 2/3] btrfs: backref: Implement btrfs_backref_iter_next()
From: Josef Bacik @ 2020-02-20 15:08 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs; +Cc: Johannes Thumshirn
In-Reply-To: <20200218090129.134450-3-wqu@suse.com>
On 2/18/20 4:01 AM, Qu Wenruo wrote:
> This function will go next inline/keyed backref for
> btrfs_backref_iter infrastructure.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* Re: [PATCH] gpio: Switch timestamps to ktime_get_ns()
From: Bartosz Golaszewski @ 2020-02-20 15:08 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-gpio, Arnd Bergmann
In-Reply-To: <20200220150250.46226-1-linus.walleij@linaro.org>
czw., 20 lut 2020 o 16:03 Linus Walleij <linus.walleij@linaro.org> napisał(a):
>
> The existing use of ktime_get_real_ns() in the timestamps from
> the GPIO events is dubious.
>
> We have had several discussions about this timestamp, and it is
> unclear whether userspace has ever taken into account that a
> timestamp from ktime_get_real_ns() can actually move backwards
> in time relative the previous timetamp, and userspace is more
> likely to expect a monotonic counter.
>
> Background:
> https://lore.kernel.org/linux-gpio/CAK8P3a1Skvm48sje8FNDPLYqyz9Lf8q0qX1QETWtyZTxuX4k1g@mail.gmail.com/
> https://marc.info/?l=linux-gpio&m=151661955709074&w=2
>
> The change is ABI incompatible, but incompatible in a way that
> is IMO more likely to fix future bugs rather than break current
> userspace. To the best of my knowledge all userspace expects
> a monotonic timestamp and users are just lucky that they very
> seldom move backwards in time.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
I too am in favor of this change.
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
^ permalink raw reply
* [PATCH 1/2 v3] leds: ns2: Absorb platform data
From: Linus Walleij @ 2020-02-20 15:08 UTC (permalink / raw)
To: Jacek Anaszewski, Pavel Machek, Dan Murphy
Cc: linux-leds, Linus Walleij, Vincent Donnefort, Simon Guinot
Nothing in the kernel includes the external header
<linux/platform_data/leds-kirkwood-ns2.h> so just push the
contents into the ns2 leds driver. If someone wants to use
platform data or board files to describe this device they
should be able to do so using GPIO machine descriptors but
in any case device tree should be the way forward for these
systems in all cases I can think of, and the driver already
supports that.
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Move header inclusion changes over to patch 2/2
ChangeLog v1->v2:
- Collect Simon's Tested-by tag
---
drivers/leds/leds-ns2.c | 27 ++++++++++++-
.../linux/platform_data/leds-kirkwood-ns2.h | 38 -------------------
2 files changed, 26 insertions(+), 39 deletions(-)
delete mode 100644 include/linux/platform_data/leds-kirkwood-ns2.h
diff --git a/drivers/leds/leds-ns2.c b/drivers/leds/leds-ns2.c
index 7c500dfdcfa3..aefac3461138 100644
--- a/drivers/leds/leds-ns2.c
+++ b/drivers/leds/leds-ns2.c
@@ -15,11 +15,36 @@
#include <linux/gpio.h>
#include <linux/leds.h>
#include <linux/module.h>
-#include <linux/platform_data/leds-kirkwood-ns2.h>
#include <linux/of.h>
#include <linux/of_gpio.h>
#include "leds.h"
+enum ns2_led_modes {
+ NS_V2_LED_OFF,
+ NS_V2_LED_ON,
+ NS_V2_LED_SATA,
+};
+
+struct ns2_led_modval {
+ enum ns2_led_modes mode;
+ int cmd_level;
+ int slow_level;
+};
+
+struct ns2_led {
+ const char *name;
+ const char *default_trigger;
+ unsigned cmd;
+ unsigned slow;
+ int num_modes;
+ struct ns2_led_modval *modval;
+};
+
+struct ns2_led_platform_data {
+ int num_leds;
+ struct ns2_led *leds;
+};
+
/*
* The Network Space v2 dual-GPIO LED is wired to a CPLD. Three different LED
* modes are available: off, on and SATA activity blinking. The LED modes are
diff --git a/include/linux/platform_data/leds-kirkwood-ns2.h b/include/linux/platform_data/leds-kirkwood-ns2.h
deleted file mode 100644
index eb8a6860e816..000000000000
--- a/include/linux/platform_data/leds-kirkwood-ns2.h
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * Platform data structure for Network Space v2 LED driver
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#ifndef __LEDS_KIRKWOOD_NS2_H
-#define __LEDS_KIRKWOOD_NS2_H
-
-enum ns2_led_modes {
- NS_V2_LED_OFF,
- NS_V2_LED_ON,
- NS_V2_LED_SATA,
-};
-
-struct ns2_led_modval {
- enum ns2_led_modes mode;
- int cmd_level;
- int slow_level;
-};
-
-struct ns2_led {
- const char *name;
- const char *default_trigger;
- unsigned cmd;
- unsigned slow;
- int num_modes;
- struct ns2_led_modval *modval;
-};
-
-struct ns2_led_platform_data {
- int num_leds;
- struct ns2_led *leds;
-};
-
-#endif /* __LEDS_KIRKWOOD_NS2_H */
--
2.24.1
^ permalink raw reply related
* [PATCH 2/2 v3] leds: ns2: Convert to GPIO descriptors
From: Linus Walleij @ 2020-02-20 15:08 UTC (permalink / raw)
To: Jacek Anaszewski, Pavel Machek, Dan Murphy
Cc: linux-leds, Linus Walleij, Vincent Donnefort, Simon Guinot
In-Reply-To: <20200220150833.56542-1-linus.walleij@linaro.org>
This converts the NS2 LED driver to use GPIO descriptors.
We take care to request the GPIOs "as is" which is what
the current driver goes to lengths to achieve, then we use
GPIOs throughout.
As the nodes for each LED does not have any corresponding
device, we need to use the DT-specific accessors to get these
GPIO descriptors from the device tree.
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Move the header inclusion changes from patch 1/2 into
this patch.
ChangeLog v1->v2:
- Collected Simon's Tested-by tag.
---
drivers/leds/leds-ns2.c | 76 +++++++++++++++++------------------------
1 file changed, 32 insertions(+), 44 deletions(-)
diff --git a/drivers/leds/leds-ns2.c b/drivers/leds/leds-ns2.c
index aefac3461138..538ca5755602 100644
--- a/drivers/leds/leds-ns2.c
+++ b/drivers/leds/leds-ns2.c
@@ -12,11 +12,10 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/leds.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/of_gpio.h>
#include "leds.h"
enum ns2_led_modes {
@@ -34,8 +33,8 @@ struct ns2_led_modval {
struct ns2_led {
const char *name;
const char *default_trigger;
- unsigned cmd;
- unsigned slow;
+ struct gpio_desc *cmd;
+ struct gpio_desc *slow;
int num_modes;
struct ns2_led_modval *modval;
};
@@ -54,8 +53,8 @@ struct ns2_led_platform_data {
struct ns2_led_data {
struct led_classdev cdev;
- unsigned int cmd;
- unsigned int slow;
+ struct gpio_desc *cmd;
+ struct gpio_desc *slow;
bool can_sleep;
unsigned char sata; /* True when SATA mode active. */
rwlock_t rw_lock; /* Lock GPIOs. */
@@ -71,8 +70,8 @@ static int ns2_led_get_mode(struct ns2_led_data *led_dat,
int cmd_level;
int slow_level;
- cmd_level = gpio_get_value_cansleep(led_dat->cmd);
- slow_level = gpio_get_value_cansleep(led_dat->slow);
+ cmd_level = gpiod_get_value_cansleep(led_dat->cmd);
+ slow_level = gpiod_get_value_cansleep(led_dat->slow);
for (i = 0; i < led_dat->num_modes; i++) {
if (cmd_level == led_dat->modval[i].cmd_level &&
@@ -105,15 +104,15 @@ static void ns2_led_set_mode(struct ns2_led_data *led_dat,
write_lock_irqsave(&led_dat->rw_lock, flags);
if (!led_dat->can_sleep) {
- gpio_set_value(led_dat->cmd,
- led_dat->modval[i].cmd_level);
- gpio_set_value(led_dat->slow,
- led_dat->modval[i].slow_level);
+ gpiod_set_value(led_dat->cmd,
+ led_dat->modval[i].cmd_level);
+ gpiod_set_value(led_dat->slow,
+ led_dat->modval[i].slow_level);
goto exit_unlock;
}
- gpio_set_value_cansleep(led_dat->cmd, led_dat->modval[i].cmd_level);
- gpio_set_value_cansleep(led_dat->slow, led_dat->modval[i].slow_level);
+ gpiod_set_value_cansleep(led_dat->cmd, led_dat->modval[i].cmd_level);
+ gpiod_set_value_cansleep(led_dat->slow, led_dat->modval[i].slow_level);
exit_unlock:
write_unlock_irqrestore(&led_dat->rw_lock, flags);
@@ -201,26 +200,6 @@ create_ns2_led(struct platform_device *pdev, struct ns2_led_data *led_dat,
int ret;
enum ns2_led_modes mode;
- ret = devm_gpio_request_one(&pdev->dev, template->cmd,
- gpio_get_value_cansleep(template->cmd) ?
- GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
- template->name);
- if (ret) {
- dev_err(&pdev->dev, "%s: failed to setup command GPIO\n",
- template->name);
- return ret;
- }
-
- ret = devm_gpio_request_one(&pdev->dev, template->slow,
- gpio_get_value_cansleep(template->slow) ?
- GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
- template->name);
- if (ret) {
- dev_err(&pdev->dev, "%s: failed to setup slow GPIO\n",
- template->name);
- return ret;
- }
-
rwlock_init(&led_dat->rw_lock);
led_dat->cdev.name = template->name;
@@ -230,8 +209,8 @@ create_ns2_led(struct platform_device *pdev, struct ns2_led_data *led_dat,
led_dat->cdev.groups = ns2_led_groups;
led_dat->cmd = template->cmd;
led_dat->slow = template->slow;
- led_dat->can_sleep = gpio_cansleep(led_dat->cmd) |
- gpio_cansleep(led_dat->slow);
+ led_dat->can_sleep = gpiod_cansleep(led_dat->cmd) |
+ gpiod_cansleep(led_dat->slow);
if (led_dat->can_sleep)
led_dat->cdev.brightness_set_blocking = ns2_led_set_blocking;
else
@@ -286,17 +265,26 @@ ns2_leds_get_of_pdata(struct device *dev, struct ns2_led_platform_data *pdata)
const char *string;
int i, num_modes;
struct ns2_led_modval *modval;
+ struct gpio_desc *gd;
- ret = of_get_named_gpio(child, "cmd-gpio", 0);
- if (ret < 0)
- goto err_node_put;
- led->cmd = ret;
- ret = of_get_named_gpio(child, "slow-gpio", 0);
- if (ret < 0)
- goto err_node_put;
- led->slow = ret;
ret = of_property_read_string(child, "label", &string);
led->name = (ret == 0) ? string : child->name;
+
+ gd = gpiod_get_from_of_node(child, "cmd-gpio", 0,
+ GPIOD_ASIS, led->name);
+ if (IS_ERR(gd)) {
+ ret = PTR_ERR(gd);
+ goto err_node_put;
+ }
+ led->cmd = gd;
+ gd = gpiod_get_from_of_node(child, "slow-gpio", 0,
+ GPIOD_ASIS, led->name);
+ if (IS_ERR(gd)) {
+ ret = PTR_ERR(gd);
+ goto err_node_put;
+ }
+ led->slow = gd;
+
ret = of_property_read_string(child, "linux,default-trigger",
&string);
if (ret == 0)
--
2.24.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.