R: [RFC PATCH v5 1/7] drivers: thermal: tsens: Add VER_0 tsens version
> -Messaggio originale-
> Da: Amit Kucheria
> Inviato: martedì 11 agosto 2020 14:58
> A: Ansuel Smith
> Cc: Andy Gross ; Bjorn Andersson
> ; Zhang Rui ; Daniel
> Lezcano ; Rob Herring ;
> Linux PM list ; linux-arm-msm m...@vger.kernel.org>; open list:OPEN FIRMWARE AND FLATTENED DEVICE
> TREE BINDINGS ; LKML ker...@vger.kernel.org>
> Oggetto: Re: [RFC PATCH v5 1/7] drivers: thermal: tsens: Add VER_0 tsens
> version
>
> On Sat, Jul 25, 2020 at 11:44 PM Ansuel Smith
> wrote:
> >
> > VER_0 is used to describe device based on tsens version before v0.1.
> > These device are devices based on msm8960 for example apq8064 or
> > ipq806x.
> >
> > Signed-off-by: Ansuel Smith
> > ---
> > drivers/thermal/qcom/tsens.c | 160 +++--
> --
> > drivers/thermal/qcom/tsens.h | 7 +-
> > 2 files changed, 132 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> > index 9fe9a2b26705..78840c1bc5d2 100644
> > --- a/drivers/thermal/qcom/tsens.c
> > +++ b/drivers/thermal/qcom/tsens.c
> > @@ -516,6 +516,15 @@ static irqreturn_t tsens_irq_thread(int irq, void
> *data)
> > dev_dbg(priv->dev, "[%u] %s: no violation: %d\n",
> > hw_id, __func__, temp);
> > }
> > +
> > + if (tsens_version(priv) < VER_0_1) {
> > + /* Constraint: There is only 1 interrupt control
> > register for
> all
> > +* 11 temperature sensor. So monitoring more than 1
> sensor based
> > +* on interrupts will yield inconsistent result. To
> > overcome
> this
> > +* issue we will monitor only sensor 0 which is the
> > master
> sensor.
> > +*/
> > + break;
> > + }
> > }
> >
> > return IRQ_HANDLED;
> > @@ -531,6 +540,13 @@ static int tsens_set_trips(void *_sensor, int low,
> int high)
> > int high_val, low_val, cl_high, cl_low;
> > u32 hw_id = s->hw_id;
> >
> > + if (tsens_version(priv) < VER_0_1) {
> > + /* Pre v0.1 IP had a single register for each type of
> > interrupt
> > +* and thresholds
> > +*/
> > + hw_id = 0;
> > + }
> > +
> > dev_dbg(dev, "[%u] %s: proposed thresholds: (%d:%d)\n",
> > hw_id, __func__, low, high);
> >
> > @@ -550,6 +566,12 @@ static int tsens_set_trips(void *_sensor, int low,
> int high)
> > tsens_set_interrupt(priv, hw_id, LOWER, true);
> > tsens_set_interrupt(priv, hw_id, UPPER, true);
> >
> > + /* VER_0 require to set MIN and MAX THRESH */
> > + if (tsens_version(priv) < VER_0_1) {
> > + regmap_field_write(priv->rf[MIN_THRESH_0], 0);
> > + regmap_field_write(priv->rf[MAX_THRESH_0], 12);
>
> Since MIN_THRESH_0 and MAX_THRESH_0 are the only two threshold on
> pre
> 0.1 IP, just (mis)use the already predefined LOW_THRESH_0 and
> UP_THRESH_0 in regfield_ids in init_common() below? Then we won't need
> this special casing here. All the special casing ugliness can then
> stay in init_common() with comments.
>
> > + }
> > +
> > spin_unlock_irqrestore(>ul_lock, flags);
> >
> > dev_dbg(dev, "[%u] %s: (%d:%d)->(%d:%d)\n",
> > @@ -584,18 +606,21 @@ int get_temp_tsens_valid(const struct
> tsens_sensor *s, int *temp)
> > u32 valid;
> > int ret;
> >
> > - ret = regmap_field_read(priv->rf[valid_idx], );
> > - if (ret)
> > - return ret;
> > - while (!valid) {
> > - /* Valid bit is 0 for 6 AHB clock cycles.
> > -* At 19.2MHz, 1 AHB clock is ~60ns.
> > -* We should enter this loop very, very rarely.
> > -*/
> > - ndelay(400);
> > + /* VER_0 doesn't have VALID bit */
> > + if (tsens_version(priv) >= VER_0_1) {
>
> Since 8960 needs a custom get_temp function, is this change really
> needed?
>
The get_temp_tsens_valid function is used to setup interrupt, think this is
the best way instead of add an if and call get_temp in the setup interrupt
function (instead of using get_temp_valid)
> > ret = regmap_field_read(priv->rf[valid_idx], );
> > if (ret)
> > return ret;
> > + while (!valid) {
> > + /* Valid bit is 0 for 6 AHB clock cycles.
> > +* At 19.2MHz, 1 AHB clock is ~60ns.
> > +* We should enter this loop very, very rarely.
> > +*/
> > + ndelay(400);
> > + ret = regmap_field_read(priv->rf[valid_idx],
> > );
> > + if (ret)
> > + return ret;
> > + }
> > }
> >
> > /* Valid bit is set, OK to
Re: [PATCH v2 00/17] arm/arm64: Turning IPIs into normal interrupts
Hi Marc, On Thu, 25 Jun 2020 at 01:28, Marc Zyngier wrote: > > For as long as SMP ARM has existed, IPIs have been handled as > something special. The arch code and the interrupt controller exchange > a couple of hooks (one to generate an IPI, another to handle it). > > Although this is perfectly manageable, it prevents the use of features > that we could use if IPIs were Linux IRQs (such as pseudo-NMIs). It > also means that each interrupt controller driver has to follow an > architecture-specific interface instead of just implementing the base > irqchip functionalities. The arch code also duplicates a number of > things that the core irq code already does (such as calling > set_irq_regs(), irq_enter()...). > > This series tries to remedy this on arm/arm64 by offering a new > registration interface where the irqchip gives the arch code a range > of interrupts to use for IPIs. The arch code requests these as normal > per-cpu interrupts. > > The bulk of the work is at the interrupt controller level, where all 5 > irqchips used on arm+SMP/arm64 get converted. > > Finally, we drop the legacy registration interface as well as the > custom statistics accounting. > > Note that I have had a look at providing a "generic" interface by > expanding the kernel/irq/ipi.c bag of helpers, but so far all > irqchips have very different requirements, so there is hardly anything > to consolidate for now. Maybe some as hip04 and the Marvell horror get > cleaned up (the latter certainly could do with a good dusting). > > This has been tested on a bunch of 32 and 64bit guests (GICv2, GICv3), > as well as 64bit bare metal (GICv3). The RPi part has only been tested > in QEMU as a 64bit guest, while the HiSi and Marvell parts have only > been compile-tested. This series works perfectly fine on Developerbox. I just want to follow-up regarding when you are planning to push this series upstream? Are you waiting for other irqchips (apart from GIC) to be reviewed? Actually mine work to turn IPI as a pseudo NMI [1] is dependent on this patch-set. [1] https://lkml.org/lkml/2020/5/20/488 -Sumit > > * From v1: > - Clarified the effect of nesting irq_enter/exit (Russell) > - Changed the point where we tear IPIs down on (Valentin) > - IPIs are no longer accessible from DT > - HIP04 and Armada 370-XP have been converted, but are untested > - arch-specific kstat accounting is removed > - ARM's legacy interface is dropped > > Marc Zyngier (17): > genirq: Add fasteoi IPI flow > genirq: Allow interrupts to be excluded from /proc/interrupts > arm64: Allow IPIs to be handled as normal interrupts > ARM: Allow IPIs to be handled as normal interrupts > irqchip/gic-v3: Describe the SGI range > irqchip/gic-v3: Configure SGIs as standard interrupts > irqchip/gic: Atomically update affinity > irqchip/gic: Refactor SMP configuration > irqchip/gic: Configure SGIs as standard interrupts > irqchip/gic-common: Don't enable SGIs by default > irqchip/bcm2836: Configure mailbox interrupts as standard interrupts > irqchip/hip04: Configure IPIs as standard interrupts > irqchip/armada-370-xp: Configure IPIs as standard interrupts > arm64: Kill __smp_cross_call and co > arm64: Remove custom IRQ stat accounting > ARM: Kill __smp_cross_call and co > ARM: Remove custom IRQ stat accounting > > arch/arm/Kconfig| 1 + > arch/arm/include/asm/hardirq.h | 17 -- > arch/arm/include/asm/smp.h | 5 +- > arch/arm/kernel/smp.c | 135 +- > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/hardirq.h| 9 - > arch/arm64/include/asm/irq_work.h | 4 +- > arch/arm64/include/asm/smp.h| 6 +- > arch/arm64/kernel/smp.c | 119 - > drivers/irqchip/irq-armada-370-xp.c | 262 +++- > drivers/irqchip/irq-bcm2836.c | 151 +--- > drivers/irqchip/irq-gic-common.c| 3 - > drivers/irqchip/irq-gic-v3.c| 99 ++- > drivers/irqchip/irq-gic.c | 183 ++- > drivers/irqchip/irq-hip04.c | 89 +- > include/linux/irq.h | 5 +- > kernel/irq/chip.c | 27 +++ > kernel/irq/debugfs.c| 1 + > kernel/irq/proc.c | 2 +- > kernel/irq/settings.h | 7 + > 20 files changed, 713 insertions(+), 413 deletions(-) > > -- > 2.27.0 >
Re: [PATCH v2] loop: unset GENHD_FL_NO_PART_SCAN on LOOP_CONFIGURE
On 8/11/20 12:49 AM, Martijn Coenen wrote:
> On Mon, Aug 10, 2020 at 7:16 PM Lennart Poettering
> wrote:
>>
>> When LOOP_CONFIGURE is used with LO_FLAGS_PARTSCAN we need to propagate
>> this into the GENHD_FL_NO_PART_SCAN. LOOP_SETSTATUS does this,
>> LOOP_CONFIGURE doesn't so far. Effect is that setting up a loopback
>> device with partition scanning doesn't actually work when LOOP_CONFIGURE
>> is issued, though it works fine with LOOP_SETSTATUS.
>>
>> Let's correct that and propagate the flag in LOOP_CONFIGURE too.
>>
>> Fixes: 3448914e8cc5("loop: Add LOOP_CONFIGURE ioctl")
>>
>> Signed-off-by: Lennart Poettering
>> Acked-by: Martijn Coenen
>
> Thanks, still looks good to me.
Applied.
--
Jens Axboe
Re: [PATCH] mm, page_alloc: fix core hung in free_pcppages_bulk()
On 11.08.20 15:11, Charan Teja Kalla wrote:
> Thanks David for the comments.
>
> On 8/11/2020 1:59 PM, David Hildenbrand wrote:
>> On 10.08.20 18:10, Charan Teja Reddy wrote:
>>> The following race is observed with the repeated online, offline and a
>>> delay between two successive online of memory blocks of movable zone.
>>>
>>> P1 P2
>>>
>>> Online the first memory block in
>>> the movable zone. The pcp struct
>>> values are initialized to default
>>> values,i.e., pcp->high = 0 &
>>> pcp->batch = 1.
>>>
>>> Allocate the pages from the
>>> movable zone.
>>>
>>> Try to Online the second memory
>>> block in the movable zone thus it
>>> entered the online_pages() but yet
>>> to call zone_pcp_update().
>>> This process is entered into
>>> the exit path thus it tries
>>> to release the order-0 pages
>>> to pcp lists through
>>> free_unref_page_commit().
>>> As pcp->high = 0, pcp->count = 1
>>> proceed to call the function
>>> free_pcppages_bulk().
>>> Update the pcp values thus the
>>> new pcp values are like, say,
>>> pcp->high = 378, pcp->batch = 63.
>>> Read the pcp's batch value using
>>> READ_ONCE() and pass the same to
>>> free_pcppages_bulk(), pcp values
>>> passed here are, batch = 63,
>>> count = 1.
>>>
>>> Since num of pages in the pcp
>>> lists are less than ->batch,
>>> then it will stuck in
>>> while(list_empty(list)) loop
>>> with interrupts disabled thus
>>> a core hung.
>>>
>>> Avoid this by ensuring free_pcppages_bulk() called with proper count of
>>> pcp list pages.
>>>
>>> The mentioned race is some what easily reproducible without [1] because
>>> pcp's are not updated for the first memory block online and thus there
>>> is a enough race window for P2 between alloc+free and pcp struct values
>>> update through onlining of second memory block.
>>>
>>> With [1], the race is still exists but it is very much narrow as we
>>> update the pcp struct values for the first memory block online itself.
>>>
>>> [1]: https://patchwork.kernel.org/patch/11696389/
>>>
>>> Signed-off-by: Charan Teja Reddy
>>> ---
>>> mm/page_alloc.c | 16 ++--
>>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index e4896e6..25e7e12 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -3106,6 +3106,7 @@ static void free_unref_page_commit(struct page *page,
>>> unsigned long pfn)
>>> struct zone *zone = page_zone(page);
>>> struct per_cpu_pages *pcp;
>>> int migratetype;
>>> + int high;
>>>
>>> migratetype = get_pcppage_migratetype(page);
>>> __count_vm_event(PGFREE);
>>> @@ -3128,8 +3129,19 @@ static void free_unref_page_commit(struct page
>>> *page, unsigned long pfn)
>>> pcp = _cpu_ptr(zone->pageset)->pcp;
>>> list_add(>lru, >lists[migratetype]);
>>> pcp->count++;
>>> - if (pcp->count >= pcp->high) {
>>> - unsigned long batch = READ_ONCE(pcp->batch);
>>> + high = READ_ONCE(pcp->high);
>>> + if (pcp->count >= high) {
>>> + int batch;
>>> +
>>> + batch = READ_ONCE(pcp->batch);
>>> + /*
>>> +* For non-default pcp struct values, high is always
>>> +* greater than the batch. If high < batch then pass
>>> +* proper count to free the pcp's list pages.
>>> +*/
>>> + if (unlikely(high < batch))
>>> + batch = min(pcp->count, batch);
>>> +
>>> free_pcppages_bulk(zone, batch, pcp);
>>> }
>>> }
>>>
>>
>> I was wondering if we should rather set all pageblocks to
>> MIGRATE_ISOLATE in online_pages() before doing the online_pages_range()
>> call, and do undo_isolate_page_range() after onlining is done.
>>
>> move_pfn_range_to_zone()->memmap_init_zone() marks all pageblocks
>> MIGRATE_MOVABLE, and as that function is used also during boot, we could
>> supply a parameter to configure this.
>>
>> This would prevent another race from happening: Having pages exposed to
>> the buddy ready for allocation in online_pages_range() before the
>> sections are marked online.
>
> Yeah this is another bug. And idea of isolate first, online and undoing
> the isolation after zonelist and pcp struct update should
Re: [PATCH] mm, page_alloc: fix core hung in free_pcppages_bulk()
Thanks David for the comments.
On 8/11/2020 1:59 PM, David Hildenbrand wrote:
> On 10.08.20 18:10, Charan Teja Reddy wrote:
>> The following race is observed with the repeated online, offline and a
>> delay between two successive online of memory blocks of movable zone.
>>
>> P1 P2
>>
>> Online the first memory block in
>> the movable zone. The pcp struct
>> values are initialized to default
>> values,i.e., pcp->high = 0 &
>> pcp->batch = 1.
>>
>> Allocate the pages from the
>> movable zone.
>>
>> Try to Online the second memory
>> block in the movable zone thus it
>> entered the online_pages() but yet
>> to call zone_pcp_update().
>> This process is entered into
>> the exit path thus it tries
>> to release the order-0 pages
>> to pcp lists through
>> free_unref_page_commit().
>> As pcp->high = 0, pcp->count = 1
>> proceed to call the function
>> free_pcppages_bulk().
>> Update the pcp values thus the
>> new pcp values are like, say,
>> pcp->high = 378, pcp->batch = 63.
>> Read the pcp's batch value using
>> READ_ONCE() and pass the same to
>> free_pcppages_bulk(), pcp values
>> passed here are, batch = 63,
>> count = 1.
>>
>> Since num of pages in the pcp
>> lists are less than ->batch,
>> then it will stuck in
>> while(list_empty(list)) loop
>> with interrupts disabled thus
>> a core hung.
>>
>> Avoid this by ensuring free_pcppages_bulk() called with proper count of
>> pcp list pages.
>>
>> The mentioned race is some what easily reproducible without [1] because
>> pcp's are not updated for the first memory block online and thus there
>> is a enough race window for P2 between alloc+free and pcp struct values
>> update through onlining of second memory block.
>>
>> With [1], the race is still exists but it is very much narrow as we
>> update the pcp struct values for the first memory block online itself.
>>
>> [1]: https://patchwork.kernel.org/patch/11696389/
>>
>> Signed-off-by: Charan Teja Reddy
>> ---
>> mm/page_alloc.c | 16 ++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index e4896e6..25e7e12 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -3106,6 +3106,7 @@ static void free_unref_page_commit(struct page *page,
>> unsigned long pfn)
>> struct zone *zone = page_zone(page);
>> struct per_cpu_pages *pcp;
>> int migratetype;
>> +int high;
>>
>> migratetype = get_pcppage_migratetype(page);
>> __count_vm_event(PGFREE);
>> @@ -3128,8 +3129,19 @@ static void free_unref_page_commit(struct page *page,
>> unsigned long pfn)
>> pcp = _cpu_ptr(zone->pageset)->pcp;
>> list_add(>lru, >lists[migratetype]);
>> pcp->count++;
>> -if (pcp->count >= pcp->high) {
>> -unsigned long batch = READ_ONCE(pcp->batch);
>> +high = READ_ONCE(pcp->high);
>> +if (pcp->count >= high) {
>> +int batch;
>> +
>> +batch = READ_ONCE(pcp->batch);
>> +/*
>> + * For non-default pcp struct values, high is always
>> + * greater than the batch. If high < batch then pass
>> + * proper count to free the pcp's list pages.
>> + */
>> +if (unlikely(high < batch))
>> +batch = min(pcp->count, batch);
>> +
>> free_pcppages_bulk(zone, batch, pcp);
>> }
>> }
>>
>
> I was wondering if we should rather set all pageblocks to
> MIGRATE_ISOLATE in online_pages() before doing the online_pages_range()
> call, and do undo_isolate_page_range() after onlining is done.
>
> move_pfn_range_to_zone()->memmap_init_zone() marks all pageblocks
> MIGRATE_MOVABLE, and as that function is used also during boot, we could
> supply a parameter to configure this.
>
> This would prevent another race from happening: Having pages exposed to
> the buddy ready for allocation in online_pages_range() before the
> sections are marked online.
Yeah this is another bug. And idea of isolate first, online and undoing
the isolation after zonelist and pcp struct update should work even for
the mentioned issue. This needs to go as a separate fix?
However, IMO, issue in free_pcppages_bulk()
Re: [PATCH] sched/fair: Remove the duplicate check from group_has_capacity()
On 2020/8/11 下午8:48, Valentin Schneider wrote: On 11/08/20 12:44, Qi Zheng wrote: On 2020/8/11 下午6:38, Valentin Schneider wrote: On 11/08/20 04:39, Qi Zheng wrote: On 2020/8/11 上午2:33, Valentin Schneider wrote: On 10/08/20 02:00, Qi Zheng wrote: 1. The group_has_capacity() function is only called in group_classify(). 2. The following inequality has already been checked in group_is_overloaded() which was also called in group_classify(). (sgs->group_capacity * imbalance_pct) < (sgs->group_runnable * 100) Consider group_is_overloaded() returns false because of the first condition: if (sgs->sum_nr_running <= sgs->group_weight) return false; then group_has_capacity() would be the first place where the group_runnable vs group_capacity comparison would be done. Now in that specific case we'll actually only check it if sgs->sum_nr_running == sgs->group_weight and the only case where the runnable vs capacity check can fail here is if there's significant capacity pressure going on. TBH this capacity pressure could be happening even when there are fewer tasks than CPUs, so I'm not sure how intentional that corner case is. Maybe some cpus in sg->cpumask are no longer active at the == case, which causes the significant capacity pressure? That can only happen in that short window between deactivating a CPU and not having rebuilt the sched_domains yet, which sounds quite elusive. In fact, at the beginning, I added unlikely() here to hint the compiler: - if ((sgs->group_capacity * imbalance_pct) < - (sgs->group_runnable * 100)) + if (unlikely((sgs->group_capacity * imbalance_pct) < + (sgs->group_runnable * 100))) The corresponding patch is as follows: [PATCH]sched/core: add unlikely in group_has_capacity() Do you think it is necessary? The "unlikely" approach has the benefit of keeping all corner cases in place. I was tempted to say it could still make sense to get rid of the extra check entirely, given that it has an impact only when: - sum_nr_running == group_weight - group capacity has been noticeably reduced If sum_nr_running < group_weight, we won't evaluate it. If sum_nr_running > group_weight, we either won't call into group_has_capacity() or we'll have checked it already in group_overloaded(). That said, it does make very much sense to check it in that == case. Vincent might have a different take on this, but right now I'd say the unlikely approach is the safest one of the two. So what should I do next? Do I resubmit a patch with unlikely() or add your email to the old patch([PATCH]sched/core: add unlikely in group_has_capacity())? Or continue to wait for suggestions from other maintainers?
Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor
Hi! > >> Thanks for the lively discussion. I have tried to answer some of the > >> comments below. > > > >>> There are options today, e.g. > >>> > >>> a) If the restriction is only per-alias, you can have distinct aliases > >>>where one is writable and another is executable, and you can make it > >>>hard to find the relationship between the two. > >>> > >>> b) If the restriction is only temporal, you can write instructions into > >>>an RW- buffer, transition the buffer to R--, verify the buffer > >>>contents, then transition it to --X. > >>> > >>> c) You can have two processes A and B where A generates instrucitons into > >>>a buffer that (only) B can execute (where B may be restricted from > >>>making syscalls like write, mprotect, etc). > >> > >> The general principle of the mitigation is W^X. I would argue that > >> the above options are violations of the W^X principle. If they are > >> allowed today, they must be fixed. And they will be. So, we cannot > >> rely on them. > > > > Would you mind describing your threat model? > > > > Because I believe you are using model different from everyone else. > > > > In particular, I don't believe b) is a problem or should be fixed. > > It is a problem because a kernel that implements W^X properly > will not allow it. It has no idea what has been done in userland. > It has no idea that the user has checked and verified the buffer > contents after transitioning the page to R--. No, it is not a problem. W^X is designed to protect from attackers doing buffer overflows, not attackers doing arbitrary syscalls. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: PGP signature
Re: [PATCH v2 2/2] platform/chrome: cros_ec_typec: Avoid setting usb role during disconnect
Hi, On Thu, Aug 06, 2020 at 11:39:08AM -0700, Prashant Malani wrote: > I would suggest: > - Merging Patch 1 (role set correction) and Patch 2 (moving the > usb_role_switch_set_role() inside cros_typec_configure_mux() > *but* keep it at the end to preserve existing ordering) into 1 patch. > - Add another patch which re-orders the calls and which in the commit > message lists out all the reasons why this re-ordering > needs to be done. > > Doing the above will help keep better track of why the changes were made. So Azhar can you please prepare v3? thanks, -- heikki
Re: [RFC PATCH] printk: Change timestamp to triplet as mono, boot and real
On Tue 2020-08-11 14:05:12, Thomas Gleixner wrote: > Petr Mladek writes: > > At least "crash" tool would need an update anyway. AFAIK, it checks > > the size of struct printk_log and refuses to read it when it changes. > > > > It means that the hack with VMCOREINFO_FIELD_OFFSET probably is not > > needed because we would need to update the crashdump-related tools anyway. > > > > Well, the timing is good. We are about to switch the printk ring > > buffer into a lockless one. It requires updating the crashdump tools > > as well. We could do this at the same time. The lockless ring buffer > > already is in linux-next. It is aimed for 5.10 or 5.11. > ... > > It would be great to synchronize all these changes changes of the > > printk log buffer structures. > > I agree that having one update is a good thing, but pretty please can we > finally make progress with this and not create yet another dependency? To make it clear. I definitely do not want to block lockless printk by this. BTW: I am not 100% convinced that storing all three timestamps is worth it. It increases the code complexity, metadata size. It needs an interface with the userspace that has to stay backward compatible. Also it still will be racy because the timestamp is taken when the message is printed. It might be "long" before or after the event that it talks about. There is still the alternative to print all three timestamps regularly for those interested. It is less user convenient but much easier to maintain. Best Regards, Petr
Re: [PATCH] mm, page_alloc: fix core hung in free_pcppages_bulk()
Thanks David.
On 8/11/2020 1:06 AM, David Rientjes wrote:
> On Mon, 10 Aug 2020, Charan Teja Reddy wrote:
>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index e4896e6..25e7e12 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -3106,6 +3106,7 @@ static void free_unref_page_commit(struct page *page,
>> unsigned long pfn)
>> struct zone *zone = page_zone(page);
>> struct per_cpu_pages *pcp;
>> int migratetype;
>> +int high;
>>
>> migratetype = get_pcppage_migratetype(page);
>> __count_vm_event(PGFREE);
>> @@ -3128,8 +3129,19 @@ static void free_unref_page_commit(struct page *page,
>> unsigned long pfn)
>> pcp = _cpu_ptr(zone->pageset)->pcp;
>> list_add(>lru, >lists[migratetype]);
>> pcp->count++;
>> -if (pcp->count >= pcp->high) {
>> -unsigned long batch = READ_ONCE(pcp->batch);
>> +high = READ_ONCE(pcp->high);
>> +if (pcp->count >= high) {
>> +int batch;
>> +
>> +batch = READ_ONCE(pcp->batch);
>> +/*
>> + * For non-default pcp struct values, high is always
>> + * greater than the batch. If high < batch then pass
>> + * proper count to free the pcp's list pages.
>> + */
>> +if (unlikely(high < batch))
>> +batch = min(pcp->count, batch);
>> +
>> free_pcppages_bulk(zone, batch, pcp);
>> }
>> }
>
> I'm wondering if a fix to free_pcppages_bulk() is more appropriate here
> because the count passed into it seems otherwise fragile if this results
> in a hung core?
>
Agree that the free_pcppages_bulk() is appropriate place to fix and it
actually much cleaner. Raised V2:
https://patchwork.kernel.org/patch/11709225/
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2] clk: samsung: Prevent potential endless loop in the PLL set_rate ops
Hi Sylwester,
2020年8月11日(火) 13:25 Sylwester Nawrocki :
>
> In the .set_rate callback for some PLLs there is a loop polling state
> of the PLL lock bit and it may become an endless loop when something
> goes wrong with the PLL. For some PLLs there is already (a duplicated)
> code for polling with timeout. This patch replaces that code with
> the readl_relaxed_poll_timeout_atomic() macro and moves it to a common
> helper function, which is then used for all the PLLs. The downside
> of switching to the common macro is that we drop the cpu_relax() call.
Tbh. I'm not sure what effect was exactly expected from cpu_relax() in
the functions which already had timeout handling. Could someone shed
some light on this?
> Using a common helper function rather than the macro directly allows
> to avoid repeating the error message in the code and to avoid the object
> code size increase due to inlining.
>
> Signed-off-by: Sylwester Nawrocki
> ---
> Changes for v2:
> - use common readl_relaxed_poll_timeout_atomic() macro
> ---
> drivers/clk/samsung/clk-pll.c | 92
> +++
> 1 file changed, 32 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
> index ac70ad7..c3c1efe 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -9,13 +9,14 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include "clk.h"
> #include "clk-pll.h"
>
> -#define PLL_TIMEOUT_MS 10
> +#define PLL_TIMEOUT_US 1U
I'm also wondering if 10ms is the universal value that would cover the
oldest PLLs as well, but my loose recollection is that they should
still lock much faster than that. Could you double check that in the
documentation?
Otherwise the patch looks good to me, thanks!
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
>
> struct samsung_clk_pll {
> struct clk_hw hw;
> @@ -63,6 +64,22 @@ static long samsung_pll_round_rate(struct clk_hw *hw,
> return rate_table[i - 1].rate;
> }
>
> +static int samsung_pll_lock_wait(struct samsung_clk_pll *pll,
> +unsigned int reg_mask)
> +{
> + u32 val;
> + int ret;
> +
> + /* Wait until the PLL is in steady locked state */
> + ret = readl_relaxed_poll_timeout_atomic(pll->con_reg, val,
> + val & reg_mask, 0, PLL_TIMEOUT_US);
> + if (ret < 0)
> + pr_err("%s: Could not lock PLL %s\n",
> + __func__, clk_hw_get_name(>hw));
> +
> + return ret;
> +}
> +
> static int samsung_pll3xxx_enable(struct clk_hw *hw)
> {
> struct samsung_clk_pll *pll = to_clk_pll(hw);
> @@ -241,12 +258,9 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw,
> unsigned long drate,
> writel_relaxed(tmp, pll->con_reg);
>
> /* Wait until the PLL is locked if it is enabled. */
> - if (tmp & BIT(pll->enable_offs)) {
> - do {
> - cpu_relax();
> - tmp = readl_relaxed(pll->con_reg);
> - } while (!(tmp & BIT(pll->lock_offs)));
> - }
> + if (tmp & BIT(pll->enable_offs))
> + return samsung_pll_lock_wait(pll, BIT(pll->lock_offs));
> +
> return 0;
> }
>
> @@ -318,7 +332,7 @@ static int samsung_pll36xx_set_rate(struct clk_hw *hw,
> unsigned long drate,
> unsigned long parent_rate)
> {
> struct samsung_clk_pll *pll = to_clk_pll(hw);
> - u32 tmp, pll_con0, pll_con1;
> + u32 pll_con0, pll_con1;
> const struct samsung_pll_rate_table *rate;
>
> rate = samsung_get_pll_settings(pll, drate);
> @@ -356,13 +370,8 @@ static int samsung_pll36xx_set_rate(struct clk_hw *hw,
> unsigned long drate,
> pll_con1 |= rate->kdiv << PLL36XX_KDIV_SHIFT;
> writel_relaxed(pll_con1, pll->con_reg + 4);
>
> - /* wait_lock_time */
> - if (pll_con0 & BIT(pll->enable_offs)) {
> - do {
> - cpu_relax();
> - tmp = readl_relaxed(pll->con_reg);
> - } while (!(tmp & BIT(pll->lock_offs)));
> - }
> + if (pll_con0 & BIT(pll->enable_offs))
> + return samsung_pll_lock_wait(pll, BIT(pll->lock_offs));
>
> return 0;
> }
> @@ -437,7 +446,6 @@ static int samsung_pll45xx_set_rate(struct clk_hw *hw,
> unsigned long drate,
> struct samsung_clk_pll *pll = to_clk_pll(hw);
> const struct samsung_pll_rate_table *rate;
> u32 con0, con1;
> - ktime_t start;
>
> /* Get required rate settings from table */
> rate = samsung_get_pll_settings(pll, drate);
> @@ -489,20 +497,7 @@ static int samsung_pll45xx_set_rate(struct clk_hw *hw,
> unsigned long drate,
> writel_relaxed(con0, pll->con_reg);
>
> /* Wait for locking. */
> - start =
[PATCH V2] mm, page_alloc: fix core hung in free_pcppages_bulk()
The following race is observed with the repeated online, offline and a
delay between two successive online of memory blocks of movable zone.
P1 P2
Online the first memory block in
the movable zone. The pcp struct
values are initialized to default
values,i.e., pcp->high = 0 &
pcp->batch = 1.
Allocate the pages from the
movable zone.
Try to Online the second memory
block in the movable zone thus it
entered the online_pages() but yet
to call zone_pcp_update().
This process is entered into
the exit path thus it tries
to release the order-0 pages
to pcp lists through
free_unref_page_commit().
As pcp->high = 0, pcp->count = 1
proceed to call the function
free_pcppages_bulk().
Update the pcp values thus the
new pcp values are like, say,
pcp->high = 378, pcp->batch = 63.
Read the pcp's batch value using
READ_ONCE() and pass the same to
free_pcppages_bulk(), pcp values
passed here are, batch = 63,
count = 1.
Since num of pages in the pcp
lists are less than ->batch,
then it will stuck in
while(list_empty(list)) loop
with interrupts disabled thus
a core hung.
Avoid this by ensuring free_pcppages_bulk() is called with proper count
of pcp list pages.
The mentioned race is some what easily reproducible without [1] because
pcp's are not updated for the first memory block online and thus there
is a enough race window for P2 between alloc+free and pcp struct values
update through onlining of second memory block.
With [1], the race is still exists but it is very much narrow as we
update the pcp struct values for the first memory block online itself.
[1]: https://patchwork.kernel.org/patch/11696389/
Signed-off-by: Charan Teja Reddy
---
v1: https://patchwork.kernel.org/patch/11707637/
mm/page_alloc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e4896e6..839039f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1304,6 +1304,11 @@ static void free_pcppages_bulk(struct zone *zone, int
count,
struct page *page, *tmp;
LIST_HEAD(head);
+ /*
+* Ensure proper count is passed which otherwise would stuck in the
+* below while (list_empty(list)) loop.
+*/
+ count = min(pcp->count, count);
while (count) {
struct list_head *list;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
Re: [Linux-kernel-mentees] [PATCH net-next v2] ipvs: Fix uninit-value in do_ip_vs_set_ctl()
On Tue, Aug 11, 2020 at 01:29:04PM +0300, Julian Anastasov wrote: > > Hello, > > On Tue, 11 Aug 2020, Peilin Ye wrote: > > > do_ip_vs_set_ctl() is referencing uninitialized stack value when `len` is > > zero. Fix it. > > > > Reported-by: syzbot+23b5f9e7caf61d9a3...@syzkaller.appspotmail.com > > Link: > > https://syzkaller.appspot.com/bug?id=46ebfb92a8a812621a001ef04d90dfa459520fe2 > > Suggested-by: Julian Anastasov > > Signed-off-by: Peilin Ye > > Looks good to me, thanks! > > Acked-by: Julian Anastasov Pablo, could you consider this for nf-next or should we repost when net-next re-opens? Reviewed-by: Simon Horman
Re: [PATCH] HID: i2c-hid: Add 60ms delay after SET_POWER ON
Hi, On 8/11/20 8:00 AM, Kai-Heng Feng wrote: Hi Hans, On Aug 11, 2020, at 00:13, Hans de Goede wrote: Hi, On 10-08-2020 16:29, Kai-Heng Feng wrote: Goodix touchpad fails to operate in I2C mode after system suspend. According to the vendor, Windows is more forgiving and there's a 60ms delay after SET_POWER ON command. So let's do the same here, to workaround for the touchpads that depend on the delay. Signed-off-by: Kai-Heng Feng Interesting I send a very similar patch a couple of days ago, after debugging some touchpads issues on a BMAX Y13 laptop: https://patchwork.kernel.org/patch/11701541/ If you look at that patch you will see that if we add a sleep on power-on to i2c_hid_set_power(), we can remove an existing sleep after power-on from i2c_hid_hwreset(). And there is an interesting comment there which should probably be moved (as my patch does) and corrected for the new knowledge so that people reading the code in the future now why the sleep is there. Thanks for the info. Can you please update your patch with 60ms to supersede mine? Sure, done. Regards, Hans Other then that we've come to the same conclusion, but your sleep is much longer. I guess that is ok though, are you sure we need 60ms as a minimum? Is that what goodix said? Yes, I was told by Goodix that the 60ms delay is needed. Kai-Heng Regards, Hans --- drivers/hid/i2c-hid/i2c-hid-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c index 294c84e136d7..7b24a27fad95 100644 --- a/drivers/hid/i2c-hid/i2c-hid-core.c +++ b/drivers/hid/i2c-hid/i2c-hid-core.c @@ -419,6 +419,9 @@ static int i2c_hid_set_power(struct i2c_client *client, int power_state) if (ret) dev_err(>dev, "failed to change power setting.\n"); + if (!ret && power_state == I2C_HID_PWR_ON) + msleep(60); + set_pwr_exit: return ret; }
Re: [PATCH 19/20] media: platform: vpdma.c: fix comparison to bool
Daniel W. S. Almeida wrote on Fri [2020-Aug-07 05:35:46
-0300]:
> From: "Daniel W. S. Almeida"
>
> Fix the following coccinelle report:
>
> drivers/media/platform/ti-vpe/vpdma.c:946:5-26: WARNING:
> Comparison to bool
>
> Found using - Coccinelle (http://coccinelle.lip6.fr)
>
> Signed-off-by: Daniel W. S. Almeida
Reviewed-by: Benoit Parrot
> ---
> drivers/media/platform/ti-vpe/vpdma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/ti-vpe/vpdma.c
> b/drivers/media/platform/ti-vpe/vpdma.c
> index 2e5148ae7a0f..de600bbc 100644
> --- a/drivers/media/platform/ti-vpe/vpdma.c
> +++ b/drivers/media/platform/ti-vpe/vpdma.c
> @@ -943,7 +943,7 @@ int vpdma_hwlist_alloc(struct vpdma_data *vpdma, void
> *priv)
>
> spin_lock_irqsave(>lock, flags);
> for (i = 0; i < VPDMA_MAX_NUM_LIST &&
> - vpdma->hwlist_used[i] == true; i++)
> + vpdma->hwlist_used[i]; i++)
> ;
>
> if (i < VPDMA_MAX_NUM_LIST) {
> --
> 2.28.0
>
Re: [RFC PATCH v5 2/7] drivers: thermal: tsens: Convert msm8960 to reg_field
On Sat, Jul 25, 2020 at 11:44 PM Ansuel Smith wrote:
>
> Covert msm9860 driver to reg_filed to use the init_common
typo: field
> function.
>
> Signed-off-by: Ansuel Smith
> ---
> drivers/thermal/qcom/tsens-8960.c | 74 +++
> 1 file changed, 74 insertions(+)
>
> diff --git a/drivers/thermal/qcom/tsens-8960.c
> b/drivers/thermal/qcom/tsens-8960.c
> index 2a28a5af209e..45cd0cdff2f5 100644
> --- a/drivers/thermal/qcom/tsens-8960.c
> +++ b/drivers/thermal/qcom/tsens-8960.c
> @@ -56,6 +56,18 @@
> #define TRDY_MASK BIT(7)
> #define TIMEOUT_US 100
>
> +#define S0_STATUS_OFF 0x3628
> +#define S1_STATUS_OFF 0x362c
> +#define S2_STATUS_OFF 0x3630
> +#define S3_STATUS_OFF 0x3634
> +#define S4_STATUS_OFF 0x3638
> +#define S5_STATUS_OFF 0x3664 /* Sensors 5 thru 10 found on
> apq8064/msm8960 */
Run checkpatch and fix spelling. :-) Or just say 'sensor 5-10'
> +#define S6_STATUS_OFF 0x3668
> +#define S7_STATUS_OFF 0x366c
> +#define S8_STATUS_OFF 0x3670
> +#define S9_STATUS_OFF 0x3674
> +#define S10_STATUS_OFF 0x3678
> +
> static int suspend_8960(struct tsens_priv *priv)
> {
> int ret;
> @@ -269,6 +281,66 @@ static int get_temp_8960(const struct tsens_sensor *s,
> int *temp)
> return -ETIMEDOUT;
> }
>
> +static struct tsens_features tsens_8960_feat = {
> + .ver_major = VER_0,
> + .crit_int = 0,
> + .adc= 1,
> + .srot_split = 0,
> + .max_sensors= 11,
Align the equal to like in other files please.
> +};
> +
> +static const struct reg_field tsens_8960_regfields[MAX_REGFIELDS] = {
> + /* - SROT -- */
> + /* No VERSION information */
> +
> + /* CNTL */
> + [TSENS_EN] = REG_FIELD(CNTL_ADDR, 0, 0),
> + [TSENS_SW_RST] = REG_FIELD(CNTL_ADDR, 1, 1),
> + /* 8960 has 5 sensors, 8660 has 11, we only handle 5 */
> + [SENSOR_EN]= REG_FIELD(CNTL_ADDR, 3, 7),
> +
> + /* - TM -- */
> + /* INTERRUPT ENABLE */
> + // [INT_EN] = REG_FIELD(TM_INT_EN_OFF, 0, 0),
Get rid of these comments and at the very least use C-style comments.
> +
> + /* Single UPPER/LOWER TEMPERATURE THRESHOLD for all sensors */
> + [LOW_THRESH_0] = REG_FIELD(THRESHOLD_ADDR, 0, 7),
> + [UP_THRESH_0]= REG_FIELD(THRESHOLD_ADDR, 8, 15),
> + [MIN_THRESH_0] = REG_FIELD(THRESHOLD_ADDR, 16, 23),
> + [MAX_THRESH_0] = REG_FIELD(THRESHOLD_ADDR, 24, 31),
> +
> + // /* UPPER/LOWER INTERRUPT [CLEAR/STATUS] */
> + // /* 1 == clear, 0 == normal operation */
Get rid of these comments and at the very least use C-style comments.
> + [LOW_INT_CLEAR_0] = REG_FIELD(CNTL_ADDR, 9, 9),
> + [UP_INT_CLEAR_0]= REG_FIELD(CNTL_ADDR, 10, 10),
> +
> + /* NO CRITICAL INTERRUPT SUPPORT on 8960 */
> +
> + /* Sn_STATUS */
> + [LAST_TEMP_0] = REG_FIELD(S0_STATUS_OFF, 0, 7),
> + [LAST_TEMP_1] = REG_FIELD(S1_STATUS_OFF, 0, 7),
> + [LAST_TEMP_2] = REG_FIELD(S2_STATUS_OFF, 0, 7),
> + [LAST_TEMP_3] = REG_FIELD(S3_STATUS_OFF, 0, 7),
> + [LAST_TEMP_4] = REG_FIELD(S4_STATUS_OFF, 0, 7),
> + [LAST_TEMP_5] = REG_FIELD(S5_STATUS_OFF, 0, 7),
> + [LAST_TEMP_6] = REG_FIELD(S6_STATUS_OFF, 0, 7),
> + [LAST_TEMP_7] = REG_FIELD(S7_STATUS_OFF, 0, 7),
> + [LAST_TEMP_8] = REG_FIELD(S8_STATUS_OFF, 0, 7),
> + [LAST_TEMP_9] = REG_FIELD(S9_STATUS_OFF, 0, 7),
> + [LAST_TEMP_10] = REG_FIELD(S10_STATUS_OFF, 0, 7),
> +
> + /* No VALID field on 8960 */
> + /* TSENS_INT_STATUS bits: 1 == threshold violated */
> + [MIN_STATUS_0] = REG_FIELD(INT_STATUS_ADDR, 0, 0),
> + [LOWER_STATUS_0] = REG_FIELD(INT_STATUS_ADDR, 1, 1),
> + [UPPER_STATUS_0] = REG_FIELD(INT_STATUS_ADDR, 2, 2),
> + /* No CRITICAL field on 8960 */
> + [MAX_STATUS_0] = REG_FIELD(INT_STATUS_ADDR, 3, 3),
> +
> + /* TRDY: 1=ready, 0=in progress */
> + [TRDY] = REG_FIELD(INT_STATUS_ADDR, 7, 7),
> +};
> +
> static const struct tsens_ops ops_8960 = {
> .init = init_8960,
> .calibrate = calibrate_8960,
> @@ -282,4 +354,6 @@ static const struct tsens_ops ops_8960 = {
> struct tsens_plat_data data_8960 = {
> .num_sensors= 11,
> .ops= _8960,
> + .feat = _8960_feat,
> + .fields = tsens_8960_regfields,
> };
> --
> 2.27.0
>
Re: [RFC PATCH v5 1/7] drivers: thermal: tsens: Add VER_0 tsens version
On Sat, Jul 25, 2020 at 11:44 PM Ansuel Smith wrote:
>
> VER_0 is used to describe device based on tsens version before v0.1.
> These device are devices based on msm8960 for example apq8064 or
> ipq806x.
>
> Signed-off-by: Ansuel Smith
> ---
> drivers/thermal/qcom/tsens.c | 160 +++
> drivers/thermal/qcom/tsens.h | 7 +-
> 2 files changed, 132 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 9fe9a2b26705..78840c1bc5d2 100644
> --- a/drivers/thermal/qcom/tsens.c
> +++ b/drivers/thermal/qcom/tsens.c
> @@ -516,6 +516,15 @@ static irqreturn_t tsens_irq_thread(int irq, void *data)
> dev_dbg(priv->dev, "[%u] %s: no violation: %d\n",
> hw_id, __func__, temp);
> }
> +
> + if (tsens_version(priv) < VER_0_1) {
> + /* Constraint: There is only 1 interrupt control
> register for all
> +* 11 temperature sensor. So monitoring more than 1
> sensor based
> +* on interrupts will yield inconsistent result. To
> overcome this
> +* issue we will monitor only sensor 0 which is the
> master sensor.
> +*/
> + break;
> + }
> }
>
> return IRQ_HANDLED;
> @@ -531,6 +540,13 @@ static int tsens_set_trips(void *_sensor, int low, int
> high)
> int high_val, low_val, cl_high, cl_low;
> u32 hw_id = s->hw_id;
>
> + if (tsens_version(priv) < VER_0_1) {
> + /* Pre v0.1 IP had a single register for each type of
> interrupt
> +* and thresholds
> +*/
> + hw_id = 0;
> + }
> +
> dev_dbg(dev, "[%u] %s: proposed thresholds: (%d:%d)\n",
> hw_id, __func__, low, high);
>
> @@ -550,6 +566,12 @@ static int tsens_set_trips(void *_sensor, int low, int
> high)
> tsens_set_interrupt(priv, hw_id, LOWER, true);
> tsens_set_interrupt(priv, hw_id, UPPER, true);
>
> + /* VER_0 require to set MIN and MAX THRESH */
> + if (tsens_version(priv) < VER_0_1) {
> + regmap_field_write(priv->rf[MIN_THRESH_0], 0);
> + regmap_field_write(priv->rf[MAX_THRESH_0], 12);
Since MIN_THRESH_0 and MAX_THRESH_0 are the only two threshold on pre
0.1 IP, just (mis)use the already predefined LOW_THRESH_0 and
UP_THRESH_0 in regfield_ids in init_common() below? Then we won't need
this special casing here. All the special casing ugliness can then
stay in init_common() with comments.
> + }
> +
> spin_unlock_irqrestore(>ul_lock, flags);
>
> dev_dbg(dev, "[%u] %s: (%d:%d)->(%d:%d)\n",
> @@ -584,18 +606,21 @@ int get_temp_tsens_valid(const struct tsens_sensor *s,
> int *temp)
> u32 valid;
> int ret;
>
> - ret = regmap_field_read(priv->rf[valid_idx], );
> - if (ret)
> - return ret;
> - while (!valid) {
> - /* Valid bit is 0 for 6 AHB clock cycles.
> -* At 19.2MHz, 1 AHB clock is ~60ns.
> -* We should enter this loop very, very rarely.
> -*/
> - ndelay(400);
> + /* VER_0 doesn't have VALID bit */
> + if (tsens_version(priv) >= VER_0_1) {
Since 8960 needs a custom get_temp function, is this change really needed?
> ret = regmap_field_read(priv->rf[valid_idx], );
> if (ret)
> return ret;
> + while (!valid) {
> + /* Valid bit is 0 for 6 AHB clock cycles.
> +* At 19.2MHz, 1 AHB clock is ~60ns.
> +* We should enter this loop very, very rarely.
> +*/
> + ndelay(400);
> + ret = regmap_field_read(priv->rf[valid_idx], );
> + if (ret)
> + return ret;
> + }
> }
>
> /* Valid bit is set, OK to read the temperature */
> @@ -765,8 +790,8 @@ int __init init_common(struct tsens_priv *priv)
>
> if (tsens_version(priv) > VER_0_1) {
> for (i = VER_MAJOR; i <= VER_STEP; i++) {
> - priv->rf[i] = devm_regmap_field_alloc(dev,
> priv->srot_map,
> -
> priv->fields[i]);
> + priv->rf[i] = devm_regmap_field_alloc(
> + dev, priv->srot_map, priv->fields[i]);
This doesn't change any code, simply reformats the code to 80 columns.
Avoid adding such lines to other features, makes it harder to review
changes.
Please ignore the 80 column warning here and elsewhere below when it
is only going over by a few characters. Run checkpatch on your patches
which has now increased the number of columns to 100
Re: [Resend PATCH 2/6] mm/memcg: remove useless check on page->mem_cgroup
>From beeac61119ab39b1869c520c0f272fb8bab93765 Mon Sep 17 00:00:00 2001 From: Alex Shi Date: Wed, 5 Aug 2020 21:02:30 +0800 Subject: [PATCH 2/6] memcg: bail out early from swap accounting when memcg is disabled If we disabled memcg by cgroup_disable=memory, the swap charges are still called. Let's return from the funcs earlier. Signed-off-by: Alex Shi Reviewed-by: Roman Gushchin Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Andrew Morton Cc: cgro...@vger.kernel.org Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org --- mm/memcontrol.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 299382fc55a9..419cf565f40b 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -7098,6 +7098,9 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t entry) VM_BUG_ON_PAGE(PageLRU(page), page); VM_BUG_ON_PAGE(page_count(page), page); + if (mem_cgroup_disabled()) + return; + if (cgroup_subsys_on_dfl(memory_cgrp_subsys)) return; @@ -7163,6 +7166,9 @@ int mem_cgroup_try_charge_swap(struct page *page, swp_entry_t entry) struct mem_cgroup *memcg; unsigned short oldid; + if (mem_cgroup_disabled()) + return 0; + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) return 0; -- 1.8.3.1
drivers/gpu/drm/radeon/radeon_ttm.c:979:21: sparse: sparse: incorrect type in initializer (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 00e4db51259a5f936fec1424b884f029479d3981
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to
define address spaces
date: 8 weeks ago
config: ia64-randconfig-s032-20200811 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=ia64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/gpu/drm/radeon/radeon_ttm.c:979:21: sparse: sparse: cast removes
address space '__user' of expression
drivers/gpu/drm/radeon/radeon_ttm.c:979:21: sparse: sparse: cast removes
address space '__user' of expression
drivers/gpu/drm/radeon/radeon_ttm.c:979:21: sparse: sparse: cast removes
address space '__user' of expression
drivers/gpu/drm/radeon/radeon_ttm.c:979:21: sparse: sparse: cast removes
address space '__user' of expression
>> drivers/gpu/drm/radeon/radeon_ttm.c:979:21: sparse: sparse: incorrect type
>> in initializer (different address spaces) @@ expected unsigned int
>> [noderef] __user *__pu_ptr @@ got unsigned int [usertype] * @@
>> drivers/gpu/drm/radeon/radeon_ttm.c:979:21: sparse: expected unsigned
>> int [noderef] __user *__pu_ptr
drivers/gpu/drm/radeon/radeon_ttm.c:979:21: sparse: got unsigned int
[usertype] *
drivers/gpu/drm/radeon/radeon_ttm.c:979:21: sparse: sparse: cast removes
address space '__user' of expression
drivers/gpu/drm/radeon/radeon_ttm.c:979:21: sparse: sparse: cast removes
address space '__user' of expression
drivers/gpu/drm/radeon/radeon_ttm.c: note: in included file (through
arch/ia64/include/asm/io.h, arch/ia64/include/asm/smp.h,
arch/ia64/include/asm/topology.h, ...):
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument
1 (different base types) @@ expected unsigned int [usertype] value @@
got restricted __le32 [usertype] @@
include/asm-generic/io.h:225:22: sparse: expected unsigned int
[usertype] value
include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument
1 (different base types) @@ expected unsigned int [usertype] value @@
got restricted __le32 [usertype] @@
include/asm-generic/io.h:225:22: sparse: expected unsigned int
[usertype] value
include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
--
>> drivers/gpu/drm/radeon/radeon_fb.c:264:22: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void volatile
>> [noderef] __iomem *s @@ got void *kptr @@
>> drivers/gpu/drm/radeon/radeon_fb.c:264:22: sparse: expected void
>> volatile [noderef] __iomem *s
drivers/gpu/drm/radeon/radeon_fb.c:264:22: sparse: got void *kptr
drivers/gpu/drm/radeon/radeon_fb.c:271:27: sparse: sparse: incorrect type in
assignment (different address spaces) @@ expected char [noderef] __iomem
*screen_base @@ got void *kptr @@
drivers/gpu/drm/radeon/radeon_fb.c:271:27: sparse: expected char
[noderef] __iomem *screen_base
drivers/gpu/drm/radeon/radeon_fb.c:271:27: sparse: got void *kptr
vim +979 drivers/gpu/drm/radeon/radeon_ttm.c
771fe6b912fca54 Jerome Glisse 2009-06-05 782
771fe6b912fca54 Jerome Glisse 2009-06-05 @783 int
radeon_ttm_init(struct radeon_device *rdev)
771fe6b912fca54 Jerome Glisse 2009-06-05 784 {
771fe6b912fca54 Jerome Glisse 2009-06-05 785 int r;
771fe6b912fca54 Jerome Glisse 2009-06-05 786
771fe6b912fca54 Jerome Glisse 2009-06-05 787 /* No others user of
address space so set it to 0 */
771fe6b912fca54 Jerome Glisse 2009-06-05 788 r =
ttm_bo_device_init(>mman.bdev,
44d847b7439bdea David Herrmann2013-08-13 789
_bo_driver,
44d847b7439bdea David Herrmann2013-08-13 790
rdev->ddev->anon_inode->i_mapping,
8b53e1cb2728b63 Gerd Hoffmann 2019-09-05 791
rdev->ddev->vma_offset_manager,
33b3ad3788aba84 Christoph Hellwig 2019-08-15 792
dma_addressing_limited(>pdev->dev));
771fe6b912fca54 Jerome Glisse 2009-06-05 793 i
Re: [PATCH 1/2] mm/slub: Introduce two counters for the partial objects
On Fri, 7 Aug 2020, Pekka Enberg wrote: > Why do you consider this to be a fast path? This is all partial list > accounting when we allocate/deallocate a slab, no? Just like > ___slab_alloc() says, I assumed this to be the slow path... What am I > missing? I thought these were per object counters? If you just want to count the number of slabs then you do not need the lock at all. We already have a counter for the number of slabs. > No objections to alternative fixes, of course, but wrapping the > counters under CONFIG_DEBUG seems like just hiding the actual issue... CONFIG_DEBUG is on by default. It just compiles in the debug code and disables it so we can enable it with a kernel boot option. This is because we have had numerous issues in the past with "production" kernels that could not be recompiled with debug options. So just running the prod kernel with another option will allow you to find hard to debug issues in a full scale producton deployment with potentially proprietary modules etc.
Re: [PATCH] sched/fair: Remove the duplicate check from group_has_capacity()
On 11/08/20 12:44, Qi Zheng wrote: > On 2020/8/11 下午6:38, Valentin Schneider wrote: >> >> On 11/08/20 04:39, Qi Zheng wrote: >>> On 2020/8/11 上午2:33, Valentin Schneider wrote: On 10/08/20 02:00, Qi Zheng wrote: > 1. The group_has_capacity() function is only called in > group_classify(). > 2. The following inequality has already been checked in > group_is_overloaded() which was also called in > group_classify(). > > (sgs->group_capacity * imbalance_pct) < > (sgs->group_runnable * 100) > Consider group_is_overloaded() returns false because of the first condition: if (sgs->sum_nr_running <= sgs->group_weight) return false; then group_has_capacity() would be the first place where the group_runnable vs group_capacity comparison would be done. Now in that specific case we'll actually only check it if sgs->sum_nr_running == sgs->group_weight and the only case where the runnable vs capacity check can fail here is if there's significant capacity pressure going on. TBH this capacity pressure could be happening even when there are fewer tasks than CPUs, so I'm not sure how intentional that corner case is. >>> >>> Maybe some cpus in sg->cpumask are no longer active at the == case, >>> which causes the significant capacity pressure? >>> >> >> That can only happen in that short window between deactivating a CPU and >> not having rebuilt the sched_domains yet, which sounds quite elusive. >> > > In fact, at the beginning, I added unlikely() here to hint the compiler: > > - if ((sgs->group_capacity * imbalance_pct) < > - (sgs->group_runnable * 100)) > + if (unlikely((sgs->group_capacity * imbalance_pct) < > + (sgs->group_runnable * 100))) > > The corresponding patch is as follows: > > [PATCH]sched/core: add unlikely in group_has_capacity() > > Do you think it is necessary? The "unlikely" approach has the benefit of keeping all corner cases in place. I was tempted to say it could still make sense to get rid of the extra check entirely, given that it has an impact only when: - sum_nr_running == group_weight - group capacity has been noticeably reduced If sum_nr_running < group_weight, we won't evaluate it. If sum_nr_running > group_weight, we either won't call into group_has_capacity() or we'll have checked it already in group_overloaded(). That said, it does make very much sense to check it in that == case. Vincent might have a different take on this, but right now I'd say the unlikely approach is the safest one of the two.
[git pull] IOMMU Updates for Linux v5.9
Hi Linus, there is a tiny conflict with your tree because of the Kconfig changes this time. Please see my attached resolution. With that in mind: The following changes since commit 92ed301919932f13b9172e525674157e983d: Linux 5.8-rc7 (2020-07-26 14:14:06 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-updates-v5.9 for you to fetch changes up to e46b3c0d011eab9933c183d5b47569db8e377281: Merge tag 'arm-smmu-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into next (2020-07-29 14:47:37 +0200) IOMMU Updates for Linux v5.9 Including: - Removal of the dev->archdata.iommu (or similar) pointers from most architectures. Only Sparc is left, but this is private to Sparc as their drivers don't use the IOMMU-API. - ARM-SMMU Updates from Will Deacon: - Support for SMMU-500 implementation in Marvell Armada-AP806 SoC - Support for SMMU-500 implementation in NVIDIA Tegra194 SoC - DT compatible string updates - Remove unused IOMMU_SYS_CACHE_ONLY flag - Move ARM-SMMU drivers into their own subdirectory - Intel VT-d Updates from Lu Baolu: - Misc tweaks and fixes for vSVA - Report/response page request events - Cleanups - Move the Kconfig and Makefile bits for the AMD and Intel drivers into their respective subdirectory. - MT6779 IOMMU Support - Support for new chipsets in the Renesas IOMMU driver - Other misc cleanups and fixes (e.g. to improve compile test coverage) Alexander A. Klimov (1): iommu/omap: Replace HTTP links with HTTPS ones Baolin Wang (2): iommu: Mark __iommu_map_sg() as static iommu: Add gfp parameter to io_pgtable_ops->map() Chao Hao (10): dt-bindings: mediatek: Add bindings for MT6779 iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL iommu/mediatek: Use a u32 flags to describe different HW features iommu/mediatek: Setting MISC_CTRL register iommu/mediatek: Move inv_sel_reg into the plat_data iommu/mediatek: Add sub_comm id in translation fault iommu/mediatek: Add REG_MMU_WR_LEN_CTRL register definition iommu/mediatek: Extend protect pa alignment value iommu/mediatek: Modify MMU_CTRL register setting iommu/mediatek: Add mt6779 basic support Colin Ian King (1): iommu/omap: Check for failure of a call to omap_iommu_dump_ctx Denis Efremov (1): iommu/pamu: Use kzfree() in fsl_pamu_probe() Hanna Hawa (1): iommu/arm-smmu: Workaround for Marvell Armada-AP806 SoC erratum #582743 Jacob Pan (4): iommu/vt-d: Remove global page support in devTLB flush iommu/vt-d: Fix PASID devTLB invalidation iommu/vt-d: Warn on out-of-range invalidation address iommu/vt-d: Disable multiple GPASID-dev bind Jean-Philippe Brucker (1): iommu: Allow page responses without PASID Jerry Snitselaar (3): iommu: Add include/uapi/linux/iommu.h to MAINTAINERS file iommu/vt-d: Move Kconfig and Makefile bits down into intel directory iommu/amd: Move Kconfig and Makefile bits down into amd directory Joe Perches (1): iommu/qcom: Change CONFIG_BIG_ENDIAN to CONFIG_CPU_BIG_ENDIAN Joerg Roedel (19): Merge tag 'v5.8-rc3' into arm/qcom iommu/amd: Add helper functions to update domain->pt_root iommu/exynos: Use dev_iommu_priv_get/set() iommu/vt-d: Use dev_iommu_priv_get/set() iommu/msm: Use dev_iommu_priv_get/set() iommu/omap: Use dev_iommu_priv_get/set() iommu/rockchip: Use dev_iommu_priv_get/set() iommu/tegra: Use dev_iommu_priv_get/set() iommu/pamu: Use dev_iommu_priv_get/set() iommu/mediatek: Do no use dev->archdata.iommu x86: Remove dev->archdata.iommu pointer ia64: Remove dev->archdata.iommu pointer arm: Remove dev->archdata.iommu pointer arm64: Remove dev->archdata.iommu pointer powerpc/dma: Remove dev->archdata.iommu_domain iommu/mediatek: Include liunx/dma-mapping.h Merge tag 'arm-smmu-updates' of git://git.kernel.org/.../will/linux into arm/smmu Merge branches 'arm/renesas', 'arm/qcom', 'arm/mediatek', 'arm/omap', 'arm/exynos', 'arm/smmu', 'ppc/pamu', 'x86/vt-d', 'x86/amd' and 'core' into next Merge tag 'arm-smmu-updates' of git://git.kernel.org/.../will/linux into next John Garry (1): iommu/arm-smmu-v3: Fix trivial typo Jonathan Marek (2): dt-bindings: arm-smmu: Add sm8150 and sm8250 compatible strings iommu: arm-smmu-impl: Use qcom impl for sm8150 and sm8250 compatibles Krishna Reddy (5): iommu/arm-smmu: move TLB timeout and spin count macros iommu/arm-smmu: ioremap smmu mmio
KASAN: use-after-free Read in corrupted (4)
Hello, syzbot found the following issue on: HEAD commit:d6efb3ac Merge tag 'tty-5.9-rc1' of git://git.kernel.org/p.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=172b697690 kernel config: https://syzkaller.appspot.com/x/.config?x=ff87594cecb7e666 dashboard link: https://syzkaller.appspot.com/bug?extid=48135e34de22e3a82c99 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1373613a90 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+48135e34de22e3a82...@syzkaller.appspotmail.com netdevsim netdevsim0 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 == BUG: KASAN: use-after-free in __lock_acquire+0x41d0/0x5640 kernel/locking/lockdep.c:4296 Read of size 8 at addr 8880936320a0 by task syz-executor.0/6858 CPU: 1 PID: 6858 Comm: syz-executor.0 Not tainted 5.8.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: dump_sta --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH 4.19 47/48] i40e: Memory leak in i40e_config_iwarp_qvlist
Hi! > From: Martyna Szapar > > [ Upstream commit 0b63644602cfcbac849f7ea49272a39e90fa95eb ] > > Added freeing the old allocation of vf->qvlist_info in function > i40e_config_iwarp_qvlist before overwriting it with > the new allocation. Ok, but this also other error paths: > --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c > +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c > @@ -449,16 +450,19 @@ static int i40e_config_iwarp_qvlist(stru >"Incorrect number of iwarp vectors %u. Maximum %u > allowed.\n", >qvlist_info->num_vectors, >msix_vf); > - goto err; > + ret = -EINVAL; > + goto err_out; > } And it is no longer freeing data qvlist_info() in this path. Is that correct? Should it goto err_free instead? > @@ -512,10 +518,11 @@ static int i40e_config_iwarp_qvlist(stru > } > > return 0; > -err: > +err_free: > kfree(vf->qvlist_info); > vf->qvlist_info = NULL; > - return -EINVAL; > +err_out: > + return ret; > } Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: PGP signature
Re: VDPA Debug/Statistics
On Tue, Aug 11, 2020 at 11:58:23AM +, Eli Cohen wrote: > On Tue, Aug 11, 2020 at 11:26:20AM +, Eli Cohen wrote: > > Hi All > > > > Currently, the only statistics we get for a VDPA instance comes from the > > virtio_net device instance. Since VDPA involves hardware acceleration, > > there can be quite a lot of information that can be fetched from the > > underlying device. Currently there is no generic method to fetch this > > information. > > > > One way of doing this can be to create a the host, a net device for > > each VDPA instance, and use it to get this information or do some > > configuration. Ethtool can be used in such a case > > > > I would like to hear what you think about this or maybe you have some other > > ideas to address this topic. > > > > Thanks, > > Eli > > Something I'm not sure I understand is how are vdpa instances created on > mellanox cards? There's a devlink command for that, is that right? > Can that be extended for stats? > > Currently any VF will be probed as VDPA device. We're adding devlink support > but I am not sure if devlink is suitable for displaying statistics. We will > discuss internally but I wanted to know why you guys think. OK still things like specifying the mac are managed through rtnetlink, right? Right now it does not look like you can mix stats and vf, they are handled separately: if (rtnl_fill_stats(skb, dev)) goto nla_put_failure; if (rtnl_fill_vf(skb, dev, ext_filter_mask)) goto nla_put_failure; but ability to query vf stats on the host sounds useful generally. As another option, we could use a vdpa specific way to retrieve stats, and teach qemu to report them. > -- > MST
Re: [Resend PATCH 2/6] mm/memcg: remove useless check on page->mem_cgroup
在 2020/8/11 下午7:30, Michal Hocko 写道: > subject line looks like a left over. It doesn't match the path. Did you > mean > memcg: bail out early from swap accounting when memcg is disabled? It's much better, Thanks for correction! > > Btw. if this patch was first in the series then you wouldn't need to > mention the warnings that would trigger based on your previous patch. > I am fine with both ways but mentioning the warning is usefule. Right. but the patch is very simple, w/o warning message doesn't cuase trouble. So, removing the 'and keep WARN_ON monitor' make sense too. Do I need a resend for the commit log change? Thanks a lot! Alex > > On Tue 11-08-20 19:10:28, Alex Shi wrote: >> If we disabled memcg by cgroup_disable=memory, the swap charges are >> still called. Let's return from the funcs earlier and keep WARN_ON >> monitor. >> >> Signed-off-by: Alex Shi >> Reviewed-by: Roman Gushchin >> Acked-by: Michal Hocko >> Cc: Johannes Weiner >> Cc: Michal Hocko >> Cc: Vladimir Davydov >> Cc: Andrew Morton >> Cc: cgro...@vger.kernel.org >> Cc: linux...@kvack.org >> Cc: linux-kernel@vger.kernel.org >> --- >> mm/memcontrol.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 299382fc55a9..419cf565f40b 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -7098,6 +7098,9 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t >> entry) >> VM_BUG_ON_PAGE(PageLRU(page), page); >> VM_BUG_ON_PAGE(page_count(page), page); >> >> +if (mem_cgroup_disabled()) >> +return; >> + >> if (cgroup_subsys_on_dfl(memory_cgrp_subsys)) >> return; >> >> @@ -7163,6 +7166,9 @@ int mem_cgroup_try_charge_swap(struct page *page, >> swp_entry_t entry) >> struct mem_cgroup *memcg; >> unsigned short oldid; >> >> +if (mem_cgroup_disabled()) >> +return 0; >> + >> if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) >> return 0; >> >> -- >> 1.8.3.1 >
Re: [PATCH 06/13] MIPS: generic: Call the machine's .get_system_type callback if provided
Le lun. 3 août 2020 à 19:01, Paul Cercueil a
écrit :
Call the machine's .get_system_type callback in the global
get_system_type() function, if it was provided by the mips_machine
implementation.
The get_system_type() function had to be moved within init.c to be
able
to use the static variable "mach". Therefore the proc.c, now empty,
has
been removed.
Signed-off-by: Paul Cercueil
---
arch/mips/generic/Makefile | 1 -
arch/mips/generic/init.c | 19 +++
arch/mips/generic/proc.c | 25 -
3 files changed, 19 insertions(+), 26 deletions(-)
delete mode 100644 arch/mips/generic/proc.c
diff --git a/arch/mips/generic/Makefile b/arch/mips/generic/Makefile
index 2384a6b09e4c..f49aeede93c2 100644
--- a/arch/mips/generic/Makefile
+++ b/arch/mips/generic/Makefile
@@ -6,7 +6,6 @@
obj-y += init.o
obj-y += irq.o
-obj-y += proc.o
obj-$(CONFIG_YAMON_DT_SHIM)+= yamon-dt.o
obj-$(CONFIG_LEGACY_BOARD_SEAD3) += board-sead3.o
diff --git a/arch/mips/generic/init.c b/arch/mips/generic/init.c
index 805d0135a9f4..7d82b436939e 100644
--- a/arch/mips/generic/init.c
+++ b/arch/mips/generic/init.c
@@ -207,3 +207,22 @@ void __init arch_init_irq(void)
void __init prom_free_prom_memory(void)
{
}
+
+const char *get_system_type(void)
+{
+ const char *str;
+ int err;
+
+ if (mach && mach->get_system_type)
+ return mach->get_system_type(of_root);
The 'mach' variable is __initconst, so there's a section violation
right here. I'll send a V2.
-Paul
+
+ err = of_property_read_string(of_root, "model", );
+ if (!err)
+ return str;
+
+ err = of_property_read_string_index(of_root, "compatible", 0, );
+ if (!err)
+ return str;
+
+ return "Unknown";
+}
diff --git a/arch/mips/generic/proc.c b/arch/mips/generic/proc.c
deleted file mode 100644
index 4c992809cc3f..
--- a/arch/mips/generic/proc.c
+++ /dev/null
@@ -1,25 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * Copyright (C) 2016 Imagination Technologies
- * Author: Paul Burton
- */
-
-#include
-
-#include
-
-const char *get_system_type(void)
-{
- const char *str;
- int err;
-
- err = of_property_read_string(of_root, "model", );
- if (!err)
- return str;
-
- err = of_property_read_string_index(of_root, "compatible", 0, );
- if (!err)
- return str;
-
- return "Unknown";
-}
--
2.27.0
Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor
On 8/8/20 5:17 PM, Pavel Machek wrote: > Hi! > >> Thanks for the lively discussion. I have tried to answer some of the >> comments below. > >>> There are options today, e.g. >>> >>> a) If the restriction is only per-alias, you can have distinct aliases >>>where one is writable and another is executable, and you can make it >>>hard to find the relationship between the two. >>> >>> b) If the restriction is only temporal, you can write instructions into >>>an RW- buffer, transition the buffer to R--, verify the buffer >>>contents, then transition it to --X. >>> >>> c) You can have two processes A and B where A generates instrucitons into >>>a buffer that (only) B can execute (where B may be restricted from >>>making syscalls like write, mprotect, etc). >> >> The general principle of the mitigation is W^X. I would argue that >> the above options are violations of the W^X principle. If they are >> allowed today, they must be fixed. And they will be. So, we cannot >> rely on them. > > Would you mind describing your threat model? > > Because I believe you are using model different from everyone else. > > In particular, I don't believe b) is a problem or should be fixed. It is a problem because a kernel that implements W^X properly will not allow it. It has no idea what has been done in userland. It has no idea that the user has checked and verified the buffer contents after transitioning the page to R--. > > I'll add d), application mmaps a file(R--), and uses write syscall to change > trampolines in it. > No matter how you do it, these are all user-level methods that can be hacked. The kernel cannot be sure that an attacker's code has not found its way into the file. >> b) This is again a violation. The kernel should refuse to give execute >> permission to a page that was writeable in the past and refuse to >> give write permission to a page that was executable in the past. > > Why? I don't know about the latter part. I guess I need to think about it. But the former is valid. When a page is RW-, a hacker could hack the page. Then it does not matter that the page is transitioned to R--. Again, the kernel cannot be sure that the user has verified the contents after R--. IMO, W^X needs to be enforced temporally as well. Madhavan
Re: lockdep splat ("possible circular locking dependency detected") with PL011 on 5.8
On Tue, Aug 11, 2020 at 12:17:13PM +0100, Will Deacon wrote:
> On Tue, Aug 11, 2020 at 12:38:41PM +0200, pet...@infradead.org wrote:
> > diff --git a/drivers/tty/serial/amba-pl011.c
> > b/drivers/tty/serial/amba-pl011.c
> > index 8efd7c2a34fe..1717790ece2b 100644
> > --- a/drivers/tty/serial/amba-pl011.c
> > +++ b/drivers/tty/serial/amba-pl011.c
> > @@ -308,8 +308,9 @@ static void pl011_write(unsigned int val, const struct
> > uart_amba_port *uap,
> > */
> > static int pl011_fifo_to_tty(struct uart_amba_port *uap)
> > {
> > - u16 status;
> > unsigned int ch, flag, fifotaken;
> > + int sysrq;
> > + u16 status;
> >
> > for (fifotaken = 0; fifotaken != 256; fifotaken++) {
> > status = pl011_read(uap, REG_FR);
> > @@ -344,10 +345,12 @@ static int pl011_fifo_to_tty(struct uart_amba_port
> > *uap)
> > flag = TTY_FRAME;
> > }
> >
> > - if (uart_handle_sysrq_char(>port, ch & 255))
> > - continue;
> > + spin_unlock(>port.lock);
> > + sysrq = uart_handle_sysrq_char(>port, ch & 255);
> > + spin_lock(>port.lock);
> >
> > - uart_insert_char(>port, ch, UART011_DR_OE, ch, flag);
> > + if (!sysrq)
> > + uart_insert_char(>port, ch, UART011_DR_OE, ch,
> > flag);
> > }
> >
> > return fifotaken;
>
> Cheers, that seems to do the trick:
>
> Tested-by: Will Deacon
>
> but what I don't understand is why I haven't run into this before, and why
> nobody else seems to be reporting it!
>
> I'll try some older kernels to see if it ever worked.
I tried 5.4, 4.19, 4.14 and 4.9:
5.4 and 4.19 have the lockdep splat
4.14 doesn't have the splat, yet I don't see why (the driver code hasn't really
changed)
4.9 magic sysrq doesn't work at all (no splat either though)
Will
[PATCH v1] thermal/of: Introduce k-po, k-pu and k-i for a thermal zone
The default value for k_pu is:
2 * sustainable_power / (desired_temperature - switch_on_temp)
The default value for k_po is:
sustainable_power / (desired_temperature - switch_on_temp)
The default value for k_i is 10.
Even though these parameters of the PID controller can be changed
by the following sysfs files:
/sys/class/thermal/thermal_zoneX/k_pu
/sys/class/thermal/thermal_zoneX/k_po
/sys/class/thermal/thermal_zoneX/k_i
But it's still more convenient to change the default values by devicetree,
so introduce these three optional properties. If provided these properties,
they will be parsed and associated with the thermal zone via the thermal
zone parameters.
Signed-off-by: Finley Xiao
---
Documentation/devicetree/bindings/thermal/thermal.txt | 14 ++
drivers/thermal/thermal_of.c | 7 +++
2 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
b/Documentation/devicetree/bindings/thermal/thermal.txt
index f78bec19ca35..ebe936b57ded 100644
--- a/Documentation/devicetree/bindings/thermal/thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -165,6 +165,20 @@ Optional property:
2000mW, while on a 10'' tablet is around
4500mW.
+- k-po:Proportional parameter of the PID controller
when
+ current temperature is above the target.
+ Type: signed
+ Size: one cell
+
+- k-pu:Proportional parameter of the PID controller
when
+ current temperature is below the target.
+ Type: signed
+ Size: one cell
+
+- k-i: Integral parameter of the PID controller.
+ Type: signed
+ Size: one cell
+
Note: The delay properties are bound to the maximum dT/dt (temperature
derivative over time) in two situations for a thermal zone:
(i) - when passive cooling is activated (polling-delay-passive); and
diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
index ddf88dbe7ba2..b2a9f92cd8d2 100644
--- a/drivers/thermal/thermal_of.c
+++ b/drivers/thermal/thermal_of.c
@@ -1089,6 +1089,7 @@ int __init of_parse_thermal_zones(void)
struct thermal_zone_params *tzp;
int i, mask = 0;
u32 prop;
+ s32 sval;
tz = thermal_of_build_thermal_zone(child);
if (IS_ERR(tz)) {
@@ -1113,6 +1114,12 @@ int __init of_parse_thermal_zones(void)
if (!of_property_read_u32(child, "sustainable-power", ))
tzp->sustainable_power = prop;
+ if (!of_property_read_s32(child, "k-po", ))
+ tzp->k_po = sval;
+ if (!of_property_read_s32(child, "k-pu", ))
+ tzp->k_pu = sval;
+ if (!of_property_read_s32(child, "k-i", ))
+ tzp->k_i = sval;
for (i = 0; i < tz->ntrips; i++)
mask |= 1 << i;
--
2.11.0
[PATCH] drivers: crypto: picoxcell_crypto: Fix potential race condition bug
From: Madhuparna Bhowmik engine->stat_irq_thresh was initialized after device_create_file() in the probe function, the initialization may race with call to spacc_stat_irq_thresh_store() which updates engine->stat_irq_thresh, therefore initialize it before creating the file in probe function. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Madhuparna Bhowmik --- drivers/crypto/picoxcell_crypto.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c index dac6eb37fff9..fb34bf92861d 100644 --- a/drivers/crypto/picoxcell_crypto.c +++ b/drivers/crypto/picoxcell_crypto.c @@ -1685,11 +1685,6 @@ static int spacc_probe(struct platform_device *pdev) goto err_clk_put; } - ret = device_create_file(>dev, _attr_stat_irq_thresh); - if (ret) - goto err_clk_disable; - - /* * Use an IRQ threshold of 50% as a default. This seems to be a * reasonable trade off of latency against throughput but can be @@ -1697,6 +1692,10 @@ static int spacc_probe(struct platform_device *pdev) */ engine->stat_irq_thresh = (engine->fifo_sz / 2); + ret = device_create_file(>dev, _attr_stat_irq_thresh); + if (ret) + goto err_clk_disable; + /* * Configure the interrupts. We only use the STAT_CNT interrupt as we * only submit a new packet for processing when we complete another in -- 2.17.1
Re: [PATCH] net: untag pointer in sockptr_is_kernel
Hi Miles,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
[also build test ERROR on linus/master]
[cannot apply to net/master hch-configfs/for-next sparc-next/master v5.8
next-20200811]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Miles-Chen/net-untag-pointer-in-sockptr_is_kernel/20200811-183033
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
bfdd5aaa54b0a44d9df550fe4c9db7e1470a11b8
config: x86_64-randconfig-a013-20200811 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
4f2ad15db535873dda9bfe248a2771023b64a43c)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from net/ipv6/af_inet6.c:29:
In file included from include/linux/net.h:24:
>> include/linux/sockptr.h:23:24: error: implicit declaration of function
>> 'untagged_addr' [-Werror,-Wimplicit-function-declaration]
return (unsigned long)untagged_addr(sockptr.kernel) >= TASK_SIZE;
^
1 error generated.
--
In file included from net/ipv6/udp.c:24:
In file included from include/linux/net.h:24:
>> include/linux/sockptr.h:23:24: error: implicit declaration of function
>> 'untagged_addr' [-Werror,-Wimplicit-function-declaration]
return (unsigned long)untagged_addr(sockptr.kernel) >= TASK_SIZE;
^
net/ipv6/udp.c:1029:30: warning: no previous prototype for function
'udp_v6_early_demux' [-Wmissing-prototypes]
INDIRECT_CALLABLE_SCOPE void udp_v6_early_demux(struct sk_buff *skb)
^
net/ipv6/udp.c:1029:25: note: declare 'static' if the function is not
intended to be used outside of this translation unit
INDIRECT_CALLABLE_SCOPE void udp_v6_early_demux(struct sk_buff *skb)
^
static
net/ipv6/udp.c:1070:29: warning: no previous prototype for function
'udpv6_rcv' [-Wmissing-prototypes]
INDIRECT_CALLABLE_SCOPE int udpv6_rcv(struct sk_buff *skb)
^
net/ipv6/udp.c:1070:25: note: declare 'static' if the function is not
intended to be used outside of this translation unit
INDIRECT_CALLABLE_SCOPE int udpv6_rcv(struct sk_buff *skb)
^
static
2 warnings and 1 error generated.
vim +/untagged_addr +23 include/linux/sockptr.h
20
21 static inline bool sockptr_is_kernel(sockptr_t sockptr)
22 {
> 23 return (unsigned long)untagged_addr(sockptr.kernel) >=
TASK_SIZE;
24 }
25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
cc1: fatal error: opening output file arch/powerpc/boot/dts/fsl/.mpc8541cds.dtb.dts.tmp: No such file or directory
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 00e4db51259a5f936fec1424b884f029479d3981 commit: cc8a51ca6f05ade72f7dd2624bc5f9b948e216fc kbuild: always create directories of targets date: 2 days ago config: powerpc-randconfig-c004-20200811 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout cc8a51ca6f05ade72f7dd2624bc5f9b948e216fc # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> cc1: fatal error: opening output file >> arch/powerpc/boot/dts/fsl/.mpc8541cds.dtb.dts.tmp: No such file or directory compilation terminated. -- >> cc1: fatal error: opening output file >> arch/powerpc/boot/dts/fsl/.mpc8548cds_32b.dtb.dts.tmp: No such file or >> directory compilation terminated. -- >> cc1: fatal error: opening output file >> arch/powerpc/boot/dts/fsl/.mpc8555cds.dtb.dts.tmp: No such file or directory compilation terminated. -- >> cc1: fatal error: opening output file >> arch/powerpc/boot/dts/fsl/.mpc8568mds.dtb.dts.tmp: No such file or directory compilation terminated. -- >> cc1: fatal error: opening output file >> arch/powerpc/boot/dts/fsl/.mpc8544ds.dtb.dts.tmp: No such file or directory compilation terminated. -- >> cc1: fatal error: opening output file >> arch/powerpc/boot/dts/fsl/.mpc8572ds.dtb.dts.tmp: No such file or directory compilation terminated. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] net: untag pointer in sockptr_is_kernel
Hi Miles,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
[also build test ERROR on linus/master]
[cannot apply to net/master hch-configfs/for-next sparc-next/master v5.8
next-20200811]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Miles-Chen/net-untag-pointer-in-sockptr_is_kernel/20200811-183033
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
bfdd5aaa54b0a44d9df550fe4c9db7e1470a11b8
config: x86_64-randconfig-s022-20200811 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/net.h:24,
from net/core/stream.c:18:
include/linux/sockptr.h: In function 'sockptr_is_kernel':
>> include/linux/sockptr.h:23:24: error: implicit declaration of function
>> 'untagged_addr' [-Werror=implicit-function-declaration]
23 | return (unsigned long)untagged_addr(sockptr.kernel) >= TASK_SIZE;
|^
cc1: some warnings being treated as errors
--
In file included from include/linux/net.h:24,
from net/ipv6/ip6_fib.c:20:
include/linux/sockptr.h: In function 'sockptr_is_kernel':
>> include/linux/sockptr.h:23:24: error: implicit declaration of function
>> 'untagged_addr' [-Werror=implicit-function-declaration]
23 | return (unsigned long)untagged_addr(sockptr.kernel) >= TASK_SIZE;
|^
net/ipv6/ip6_fib.c: In function 'fib6_add':
net/ipv6/ip6_fib.c:1373:25: warning: variable 'pn' set but not used
[-Wunused-but-set-variable]
1373 | struct fib6_node *fn, *pn = NULL;
| ^~
cc1: some warnings being treated as errors
--
In file included from include/linux/net.h:24,
from net/ipv6/udp.c:24:
include/linux/sockptr.h: In function 'sockptr_is_kernel':
>> include/linux/sockptr.h:23:24: error: implicit declaration of function
>> 'untagged_addr' [-Werror=implicit-function-declaration]
23 | return (unsigned long)untagged_addr(sockptr.kernel) >= TASK_SIZE;
|^
net/ipv6/udp.c: At top level:
net/ipv6/udp.c:1029:30: warning: no previous prototype for
'udp_v6_early_demux' [-Wmissing-prototypes]
1029 | INDIRECT_CALLABLE_SCOPE void udp_v6_early_demux(struct sk_buff *skb)
| ^~
net/ipv6/udp.c:1070:29: warning: no previous prototype for 'udpv6_rcv'
[-Wmissing-prototypes]
1070 | INDIRECT_CALLABLE_SCOPE int udpv6_rcv(struct sk_buff *skb)
| ^
cc1: some warnings being treated as errors
vim +/untagged_addr +23 include/linux/sockptr.h
20
21 static inline bool sockptr_is_kernel(sockptr_t sockptr)
22 {
> 23 return (unsigned long)untagged_addr(sockptr.kernel) >=
TASK_SIZE;
24 }
25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
drivers/net/wireless/ti/wlcore/main.c:700:9: sparse: sparse: context imbalance in 'wlcore_irq' - different lock contexts for basic block
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 00e4db51259a5f936fec1424b884f029479d3981
commit: 35fba0f0fd762a8b87d403ae3c723e0061c4aa25 wlcore: Use spin_trylock in
wlcore_irq() to see if we need to queue tx
date: 4 weeks ago
config: mips-randconfig-s032-20200811 (attached as .config)
compiler: mips64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout 35fba0f0fd762a8b87d403ae3c723e0061c4aa25
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/net/wireless/ti/wlcore/main.c:643:34: sparse: sparse: context
imbalance in 'wlcore_irq_locked' - different lock contexts for basic block
>> drivers/net/wireless/ti/wlcore/main.c:700:9: sparse: sparse: context
>> imbalance in 'wlcore_irq' - different lock contexts for basic block
vim +/wlcore_irq +700 drivers/net/wireless/ti/wlcore/main.c
b5b45b3cbd5616 drivers/net/wireless/ti/wlcore/main.c Arik Nemtsov
2012-06-21 649
b5b45b3cbd5616 drivers/net/wireless/ti/wlcore/main.c Arik Nemtsov
2012-06-21 650 static irqreturn_t wlcore_irq(int irq, void *cookie)
b5b45b3cbd5616 drivers/net/wireless/ti/wlcore/main.c Arik Nemtsov
2012-06-21 651 {
b5b45b3cbd5616 drivers/net/wireless/ti/wlcore/main.c Arik Nemtsov
2012-06-21 652 int ret;
b5b45b3cbd5616 drivers/net/wireless/ti/wlcore/main.c Arik Nemtsov
2012-06-21 653 unsigned long flags;
b5b45b3cbd5616 drivers/net/wireless/ti/wlcore/main.c Arik Nemtsov
2012-06-21 654 struct wl1271 *wl = cookie;
35fba0f0fd762a drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2020-07-02 655 bool queue_tx_work = true;
b5b45b3cbd5616 drivers/net/wireless/ti/wlcore/main.c Arik Nemtsov
2012-06-21 656
eb215c33f308ce drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2020-07-02 657 set_bit(WL1271_FLAG_IRQ_RUNNING, >flags);
eb215c33f308ce drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2020-07-02 658
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 659 /* complete the ELP completion */
eb215c33f308ce drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2020-07-02 660 if (test_bit(WL1271_FLAG_IN_ELP, >flags)) {
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 661 spin_lock_irqsave(>wl_lock, flags);
eb215c33f308ce drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2020-07-02 662 if (wl->elp_compl)
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 663 complete(wl->elp_compl);
eb215c33f308ce drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2020-07-02 664 spin_unlock_irqrestore(>wl_lock, flags);
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 665 }
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 666
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 667 if (test_bit(WL1271_FLAG_SUSPENDED, >flags)) {
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 668 /* don't enqueue a work right now. mark it as
pending */
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 669 set_bit(WL1271_FLAG_PENDING_WORK, >flags);
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 670 wl1271_debug(DEBUG_IRQ, "should not enqueue
work");
eb215c33f308ce drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2020-07-02 671 spin_lock_irqsave(>wl_lock, flags);
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 672 disable_irq_nosync(wl->irq);
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 673 pm_wakeup_event(wl->dev, 0);
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 674 spin_unlock_irqrestore(>wl_lock, flags);
4633d30b61ac14 drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2019-10-09 675 goto out_handled;
97236a0656034e drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2013-03-08 676 }
97236a0656034e drivers/net/wireless/ti/wlcore/main.c
Re: [RFC][PATCH v3 11/11] misc: hisi_hikey_usb: Driver to support usb functionality of Hikey960
Em Mon, 10 Aug 2020 21:36:58 -0700
John Stultz escreveu:
> On Mon, Aug 10, 2020 at 9:35 AM Mauro Carvalho Chehab
> wrote:
> > Em Wed, 16 Oct 2019 03:33:40 +
> > John Stultz escreveu:
> >
> > > From: Yu Chen
> > >
> > > The HiKey960 has a fairly complex USB configuration due to it
> > > needing to support a USB-C port for host/device mode and multiple
> > > USB-A ports in host mode using a single USB controller.
> > >
> > > See schematics here:
> > >
> > > https://github.com/96boards/documentation/raw/master/consumer/hikey/hikey960/hardware-docs/HiKey960_Schematics.pdf
> > >
> > > This driver acts as a usb-role-switch intermediary, intercepting
> > > the role switch notifications from the tcpm code, and passing
> > > them on to the dwc3 core.
> > >
> > > In doing so, it also controls the onboard hub and power gpios in
> > > order to properly route the data lines between the USB-C port
> > > and the onboard hub to the USB-A ports.
> > >
> > > NOTE: It was noted that controlling the TYPEC_VBUS_POWER_OFF and
> > > TYPEC_VBUS_POWER_ON values here is not reccomended. I'm looking
> > > for a way to remove that bit from the logic here, but wanted to
> > > still get feedback on this approach.
> >
> > Let me somewhat hijack this thread. I'm trying to add support here
> > for the Hikey 970 driver. Maybe you might help me finding the remaing
> > issues over there ;-)
>
> So.. just as a heads up, this is a fairly old version of this patch. I
> have the current version here:
>
> https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/hikey960-mainline-WIP=1155346a06472177b8a7e7918de052549916f06f
>
> So you may want to rework ontop of that.
Yeah, I used the version from your tree.
>
> That said, the last time I submitted the hub/mux driver, Rob pushed
> back suggesting that the vbus, switch and hub power should probably be
> DT describable:
> https://lore.kernel.org/lkml/20191218163738.GA12358@bogus/
Yeah, makes sense. After USB starts working, I'll try to write a
patch on the top of yours in order to use the schema he proposed.
For now, I'm trying to understand why the only two devices found
are the hub ones. Maybe the device is still in budget mode.
> I'm at the point where I probably don't have additional cycles to
> spend to rework all the supporting drivers to support such a DT
> binding, so I'm not very optimistic this patch will go upstream (its
> much easier to float the current hub/mux driver). So you may want to
> focus on Rob's feedback there rather than any of my feedback here. :)
I have some cycles to spend on this. Just got a 960 board on my hands.
I guess I'll try to test your patches on the top of it.
> > The Hikey 970 has lots of things in common with Hikey 960, but
> > the USB hub uses a somewhat different approach (based on what I
> > saw at the Linaro's 4.9 official Hikey kernel tree).
> >
> > Basically, with the enclosed patch applied, the USB hub needs these
> > at the DT file:
> >
> > hikey_usbhub: hikey_usbhub {
> > compatible = "hisilicon,kirin970_hikey_usbhub";
> >
> > typec-vbus-gpios = < 1 0>;
> > otg-switch-gpios = < 2 0>;
> > hub_reset_en_gpio = < 3 0>;
> > hub-vdd-supply = <>;
> > usb-role-switch;
> > ...
> > }
> >
> > E.g. when compared with Hikey 960, the USB hub:
> >
> > - Hikey 970 uses a regulator instead of GPIO for powering on;
>
> So, it might not be too hard to rework the hikey960 hub power gpio to
> a gpio-regulator binding, and then both platforms can use the same
> code?
Good point. Yeah, it doesn't sound hard to do that.
> > - Hikey 970 has a reset pin controlled via GPIO.
>
> You might be able to put this reset pin under the dwc3 resets?
I'll try.
> > It should be simple to add support for it, as done by the
> > enclosed patch. With this, the phy driver for Hikey 970 and a new
> > small driver to properly set clocks and reset lines at dwg3[1],
> > I can now see the hub on my Hikey970:
> >
> > $ lsusb
> > Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> >
> > Still, I'm missing something to make it work, as, besides the hub,
> > right now, it doesn't detect the keyboard/mouse, which are
> > attached at the USB hub.
> >
> > Do you have any ideas?
>
> Not sure about the hub keyboard mouse issue. I worry that may be an
> issue with the hub power not being on?
> Make sure the mux driver is in the expected state when you boot up and
> switch modes.
No, it is not power. The power supply for LDO17 (used on Hikey 970) is
enabled before this driver gets called (as there's a logic handling
EPROBE_DEFER on my patch).
It is starting to work, after a couple of hacks:
[1.503038] JDB: dwc3_core_init DWC3_DSTS: 0xd3037c
[1.560131] JDB:
RE: [PATCH 1/2] scsi: ufs: Fix interrupt error message for shared interrupts
> The interrupt might be shared, in which case it is not an error for the
> interrupt handler to be called when the interrupt status is zero, so
> remove the message print and register dump.
>
> Signed-off-by: Adrian Hunter
> Fixes: 9333d77573485 ("scsi: ufs: Fix irq return code")
> ---
> drivers/scsi/ufs/ufshcd.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index cdcf56679b41..d7522dba4dcf 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -5994,12 +5994,6 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba)
> intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
> } while (intr_status && --retries);
>
> - if (retval == IRQ_NONE) {
Maybeif (enabled_intr_status && retval == IRQ_NONE) { ?
Thanks,
Avri
Re: [PATCH 0/3] Modernize tasklet callback API
Kees, > > > > Here's the series re-based on top of 5.8 > https://github.com/allenpais/tasklets/tree/V3 > > Let me know how you would want these to be reviewed. > I see the first set of infrastructure patches for tasklets have landed in Linus's tree. Good time to send out the ~200 patches? - Allen
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:817 dpu_crtc_enable() error: uninitialized symbol 'request_bandwidth'.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 00e4db51259a5f936fec1424b884f029479d3981
commit: 241b507c166fef3e461e5daf562d8e41aa41bf15 drm/msm/dpu: fix "frame done"
timeouts
date: 11 months ago
config: arm64-randconfig-m031-20200811 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:817 dpu_crtc_enable() error:
uninitialized symbol 'request_bandwidth'.
vim +/request_bandwidth +817 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
786
787 static void dpu_crtc_enable(struct drm_crtc *crtc,
788 struct drm_crtc_state *old_crtc_state)
789 {
790 struct dpu_crtc *dpu_crtc;
791 struct drm_encoder *encoder;
792 struct msm_drm_private *priv;
793 bool request_bandwidth;
794
795 if (!crtc || !crtc->dev || !crtc->dev->dev_private) {
796 DPU_ERROR("invalid crtc\n");
797 return;
798 }
799 priv = crtc->dev->dev_private;
800
801 pm_runtime_get_sync(crtc->dev->dev);
802
803 DRM_DEBUG_KMS("crtc%d\n", crtc->base.id);
804 dpu_crtc = to_dpu_crtc(crtc);
805
806 drm_for_each_encoder_mask(encoder, crtc->dev,
crtc->state->encoder_mask) {
807 /* in video mode, we hold an extra bandwidth reference
808 * as we cannot drop bandwidth at frame-done if any
809 * crtc is being used in video mode.
810 */
811 if (dpu_encoder_get_intf_mode(encoder) ==
INTF_MODE_VIDEO)
812 request_bandwidth = true;
813 dpu_encoder_register_frame_event_callback(encoder,
814 dpu_crtc_frame_event_cb, (void *)crtc);
815 }
816
> 817 if (request_bandwidth)
818 atomic_inc(&_dpu_crtc_get_kms(crtc)->bandwidth_ref);
819
820 trace_dpu_crtc_enable(DRMID(crtc), true, dpu_crtc);
821 dpu_crtc->enabled = true;
822
823 drm_for_each_encoder_mask(encoder, crtc->dev,
crtc->state->encoder_mask)
824 dpu_encoder_assign_crtc(encoder, crtc);
825
826 /* Enable/restore vblank irq handling */
827 drm_crtc_vblank_on(crtc);
828 }
829
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] net: eliminate meaningless memcpy to data in pskb_carve_inside_nonlinear()
Eric Dumazet wrote:
> On 8/10/20 5:28 AM, Miaohe Lin wrote:
>> The skb_shared_info part of the data is assigned in the following
>> loop. It is meaningless to do a memcpy here.
>>
>
>Reminder : net-next is CLOSED.
>
Thanks for your remind. I would wait for it open.
>This is not correct. We still have to copy _something_
>
>Something like :
>
>diff --git a/net/core/skbuff.c b/net/core/skbuff.c index
>2828f6d5ba898a5e50ccce45589bf1370e474b0f..1c0519426c7ba4b04377fc8054c4223c135879ab
> 100644
>--- a/net/core/skbuff.c
>+++ b/net/core/skbuff.c
>@@ -5953,8 +5953,8 @@ static int pskb_carve_inside_nonlinear(struct sk_buff
>*skb, const u32 off,
>size = SKB_WITH_OVERHEAD(ksize(data));
>
>memcpy((struct skb_shared_info *)(data + size),
>- skb_shinfo(skb), offsetof(struct skb_shared_info,
>-frags[skb_shinfo(skb)->nr_frags]));
>+ skb_shinfo(skb), offsetof(struct skb_shared_info,
>+ frags[0]));
>+
>if (skb_orphan_frags(skb, gfp_mask)) {
>kfree(data);
>return -ENOMEM;
>
This looks good. Will send a patch v2 soon. May I add a suggested-by tag of you
?
Many thanks.
Re: [RFC PATCH v1] power: don't manage floating point regs when no FPU
Christophe Leroy writes:
> There is no point in copying floating point regs when there
> is no FPU and MATH_EMULATION is not selected.
Yeah I guess you're right. I've never touched a system with neither, but
if such a thing exists then it does seem silly to copy regs around that
can't be used.
> Create a new CONFIG_PPC_FPU_REGS bool that is selected by
> CONFIG_MATH_EMULATION and CONFIG_PPC_FPU, and use it to
> opt out everything related to fp_state in thread_struct.
>
> The following app runs in approx 10.50 seconds on an 8xx without
> the patch, and in 9.45 seconds with the patch.
>
> void sigusr1(int sig) { }
>
> int main(int argc, char **argv)
> {
> int i = 10;
>
> signal(SIGUSR1, sigusr1);
> for (;i--;)
> raise(SIGUSR1);
> exit(0);
> }
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/processor.h | 2 ++
> arch/powerpc/kernel/asm-offsets.c | 2 ++
> arch/powerpc/kernel/process.c | 4
> arch/powerpc/kernel/ptrace/ptrace-novsx.c | 8
> arch/powerpc/kernel/ptrace/ptrace.c | 4
> arch/powerpc/kernel/signal.c | 12 +++-
> arch/powerpc/kernel/signal_32.c | 4
> arch/powerpc/kernel/traps.c | 4
> arch/powerpc/platforms/Kconfig.cputype| 4
> 10 files changed, 44 insertions(+), 1 deletion(-)
In general this looks fine.
It's a bit #ifdef heavy. Maybe some of those can be cleaned up a bit
with some wrapper inlines?
> diff --git a/arch/powerpc/kernel/ptrace/ptrace-novsx.c
> b/arch/powerpc/kernel/ptrace/ptrace-novsx.c
> index b2dc4e92d11a..8f87a11f3f8c 100644
> --- a/arch/powerpc/kernel/ptrace/ptrace-novsx.c
> +++ b/arch/powerpc/kernel/ptrace/ptrace-novsx.c
> @@ -28,6 +29,9 @@ int fpr_get(struct task_struct *target, const struct
> user_regset *regset,
>
> return user_regset_copyout(, , , ,
> >thread.fp_state, 0, -1);
> +#else
> + return 0;
> +#endif
Should we return -ENODEV/EIO here? Wonder if another arch can give us a clue.
cheers
Re: possible deadlock in dev_mc_unsync
syzbot suspects this issue was fixed by commit: commit be74294ffa24f5fbc0d6643842e3e095447e17a2 Author: Cong Wang Date: Fri Jun 26 18:24:22 2020 + net: get rid of lockdep_set_class_and_subclass() bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=110b0fc290 start commit: 4a21185c Merge git://git.kernel.org/pub/scm/linux/kernel/g.. git tree: net kernel config: https://syzkaller.appspot.com/x/.config?x=bf3aec367b9ab569 dashboard link: https://syzkaller.appspot.com/bug?extid=08e3d39f3eb8643216be syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11d2b1c510 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17aed77510 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: net: get rid of lockdep_set_class_and_subclass() For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [RFC PATCH] printk: Change timestamp to triplet as mono, boot and real
Petr Mladek writes: > On Tue 2020-08-11 12:40:22, Orson Zhai wrote: >> This is an updated version which comes from patch [1] written by Thomas >> and suggestion [2] about VMCORE_INFO given by Linus. All of that want's to be properly distangled into seperate patches. >> This patch has been tested in qemu-x86-system. One problem is the timestamp >> in kernel log will be printed [0.00] for longer time than before. > > This would be a regression. People put huge effort into having early boot > timestamps, see > https://lore.kernel.org/lkml/20180719205545.16512-1-pasha.tatas...@oracle.com/ > Adding some active people from this patchset into CC. > > I wonder if we could have these early timestamps also in the mono > clock. Not really. timekeeping init happens way after the early TSC (or whatever clock) is registered as sched_clock(). And there is no realistic way to move timekeeping init earlier. What we could do instead is to utilize sched_clock() up to the point where timekeeping becomes available and ensure that monotonic time is not jumping backwards vs. sched_clock() when switching over. For this early boot phase, clock realtime timestamps would be invalid of course and they can stay invalid even after timekeeping is initialized on systems where the RTC is not available in the early boot process. > At least "crash" tool would need an update anyway. AFAIK, it checks > the size of struct printk_log and refuses to read it when it changes. > > It means that the hack with VMCOREINFO_FIELD_OFFSET probably is not > needed because we would need to update the crashdump-related tools anyway. > > Well, the timing is good. We are about to switch the printk ring > buffer into a lockless one. It requires updating the crashdump tools > as well. We could do this at the same time. The lockless ring buffer > already is in linux-next. It is aimed for 5.10 or 5.11. ... > It would be great to synchronize all these changes changes of the > printk log buffer structures. I agree that having one update is a good thing, but pretty please can we finally make progress with this and not create yet another dependency? Thanks, tglx
[PATCH v2 2/2] ASoC: q6routing: add dummy register read/write function
Most of the DAPM widgets for DSP ASoC components reuse reg field
of the widgets for its internal calculations, however these are not
real registers. So read/writes to these numbers are not really
valid. However ASoC core will read these registers to get default
state during startup.
With recent changes to ASoC core, every register read/write
failures are reported very verbosely. Prior to this fails to reads
are totally ignored, so we never saw any error messages.
To fix this add dummy read/write function to return default value.
Reported-by: John Stultz
Fixes: e3a33673e845 ("ASoC: qdsp6: q6routing: Add q6routing driver")
Signed-off-by: Srinivas Kandagatla
---
Changes since v1:
- added reg write callback
sound/soc/qcom/qdsp6/q6routing.c | 16
1 file changed, 16 insertions(+)
diff --git a/sound/soc/qcom/qdsp6/q6routing.c b/sound/soc/qcom/qdsp6/q6routing.c
index eaa95b5a7b66..25d23e0266c7 100644
--- a/sound/soc/qcom/qdsp6/q6routing.c
+++ b/sound/soc/qcom/qdsp6/q6routing.c
@@ -973,6 +973,20 @@ static int msm_routing_probe(struct snd_soc_component *c)
return 0;
}
+static unsigned int q6routing_reg_read(struct snd_soc_component *component,
+ unsigned int reg)
+{
+ /* default value */
+ return 0;
+}
+
+static int q6routing_reg_write(struct snd_soc_component *component,
+ unsigned int reg, unsigned int val)
+{
+ /* dummy */
+ return 0;
+}
+
static const struct snd_soc_component_driver msm_soc_routing_component = {
.probe = msm_routing_probe,
.name = DRV_NAME,
@@ -981,6 +995,8 @@ static const struct snd_soc_component_driver
msm_soc_routing_component = {
.num_dapm_widgets = ARRAY_SIZE(msm_qdsp6_widgets),
.dapm_routes = intercon,
.num_dapm_routes = ARRAY_SIZE(intercon),
+ .read = q6routing_reg_read,
+ .write = q6routing_reg_write,
};
static int q6pcm_routing_probe(struct platform_device *pdev)
--
2.21.0
[PATCH v2 1/2] ASoC: q6afe-dai: mark all widgets registers as SND_SOC_NOPM
Looks like the q6afe-dai dapm widget registers are set as "0",
which is a not correct.
As this registers will be read by ASoC core during startup
which will throw up errors, Fix this by making the registers
as SND_SOC_NOPM as these should be never used.
With recent changes to ASoC core, every register read/write
failures are reported very verbosely. Prior to this fails to reads
are totally ignored, so we never saw any error messages.
Reported-by: John Stultz
Fixes: 24c4cbcfac09 ("ASoC: qdsp6: q6afe: Add q6afe dai driver")
Signed-off-by: Srinivas Kandagatla
---
Changes since v1:
- replaced reg 0 with SND_SOC_NOPM and removed read callback
sound/soc/qcom/qdsp6/q6afe-dai.c | 210 +++
1 file changed, 105 insertions(+), 105 deletions(-)
diff --git a/sound/soc/qcom/qdsp6/q6afe-dai.c b/sound/soc/qcom/qdsp6/q6afe-dai.c
index 2a5302f1db98..0168af849272 100644
--- a/sound/soc/qcom/qdsp6/q6afe-dai.c
+++ b/sound/soc/qcom/qdsp6/q6afe-dai.c
@@ -1150,206 +1150,206 @@ static int q6afe_of_xlate_dai_name(struct
snd_soc_component *component,
}
static const struct snd_soc_dapm_widget q6afe_dai_widgets[] = {
- SND_SOC_DAPM_AIF_IN("HDMI_RX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_0_RX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_1_RX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_2_RX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_3_RX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_4_RX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_5_RX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_6_RX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_0_TX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_1_TX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_2_TX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_3_TX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_4_TX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_5_TX", NULL, 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_6_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("HDMI_RX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_0_RX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_1_RX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_2_RX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_3_RX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_4_RX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_5_RX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_6_RX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_0_TX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_1_TX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_2_TX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_3_TX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_4_TX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_5_TX", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_6_TX", NULL, 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_IN("QUAT_MI2S_RX", NULL,
- 0, 0, 0, 0),
+ 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_OUT("QUAT_MI2S_TX", NULL,
- 0, 0, 0, 0),
+ 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_IN("TERT_MI2S_RX", NULL,
- 0, 0, 0, 0),
+ 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_OUT("TERT_MI2S_TX", NULL,
- 0, 0, 0, 0),
+ 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_IN("SEC_MI2S_RX", NULL,
-0, 0, 0, 0),
+0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_OUT("SEC_MI2S_TX", NULL,
- 0, 0, 0, 0),
+ 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_IN("SEC_MI2S_RX_SD1",
"Secondary MI2S Playback SD1",
- 0, 0, 0, 0),
+ 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_IN("PRI_MI2S_RX", NULL,
-0, 0, 0, 0),
+0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_OUT("PRI_MI2S_TX", NULL,
- 0, 0, 0, 0),
+ 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_IN("PRIMARY_TDM_RX_0", NULL,
-0, 0, 0, 0),
+0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_IN("PRIMARY_TDM_RX_1", NULL,
-
drivers/tty/cyclades.c:3084:41: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 00e4db51259a5f936fec1424b884f029479d3981 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 8 weeks ago config: mips-randconfig-s031-20200811 (attached as .config) compiler: mips64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-168-g9554805c-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/tty/cyclades.c:3077:68: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct FIRM_ID *firm_id @@ got void [noderef] __iomem * @@ drivers/tty/cyclades.c:3077:68: sparse: expected struct FIRM_ID *firm_id drivers/tty/cyclades.c:3077:68: sparse: got void [noderef] __iomem * >> drivers/tty/cyclades.c:3084:41: sparse: sparse: incorrect type in argument 1 >> (different address spaces) @@ expected void const volatile [noderef] >> __iomem *mem @@ got unsigned int * @@ >> drivers/tty/cyclades.c:3084:41: sparse: expected void const volatile >> [noderef] __iomem *mem drivers/tty/cyclades.c:3084:41: sparse: got unsigned int * drivers/tty/cyclades.c:3083:34: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct ZFW_CTRL *zfw_ctrl @@ got void [noderef] __iomem * @@ drivers/tty/cyclades.c:3083:34: sparse: expected struct ZFW_CTRL *zfw_ctrl drivers/tty/cyclades.c:3083:34: sparse: got void [noderef] __iomem * drivers/tty/cyclades.c:3085:45: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct CH_CTRL [noderef] __iomem *ch_ctrl @@ got struct CH_CTRL * @@ drivers/tty/cyclades.c:3085:45: sparse: expected struct CH_CTRL [noderef] __iomem *ch_ctrl drivers/tty/cyclades.c:3085:45: sparse: got struct CH_CTRL * drivers/tty/cyclades.c:3086:46: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct BUF_CTRL [noderef] __iomem *buf_ctrl @@ got struct BUF_CTRL * @@ drivers/tty/cyclades.c:3086:46: sparse: expected struct BUF_CTRL [noderef] __iomem *buf_ctrl drivers/tty/cyclades.c:3086:46: sparse: got struct BUF_CTRL * drivers/tty/cyclades.c: note: in included file (through arch/mips/include/asm/mmiowb.h, include/linux/spinlock.h, include/linux/seqlock.h, ...): arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: cast to restricted __le32 arch/mips/include/asm/io.h:354:1: sparse: sparse: ca
Re: power-off delay/hang due to commit 6d25be57 (mainline)
On Sun, 19 Jul 2020 12:07:14 +0200 Stephen Berman
wrote:
> On Tue, 14 Jul 2020 16:11:35 +0200 Sebastian Andrzej Siewior
> wrote:
>
[...]
>> Stephen, the patch attached adds a WARN_ON() statement which will
>> produce a stack trace (4 or so). Could please run 'dmesg' after a while
>> and send it back. There should be a
>> "WARNING in drivers/acpi/acpica/evmisc.c"
>>
>> statement or something along the lines.
>
> I've now rebuilt 5.6.4 with the new patch; sorry for the delay. Output
> of dmesg attached.
FWIW, while you were away I got an additional datapoint: someone who saw
my original post about this problem to one of the Linux From Scratch
mailing lists wrote me that he had the same problem, also getting
messages about the cdrom timing out ("sr 3:0:0:0" in his case); I told
him about your workaround of adding 'thermal.tzp=300' to the kernel
commandline, and he replied that this works for him too. And it turns
out we have similar motherboards: I have a Gigabyte Z390 M Gaming
Rev. 1001 board and he has Gigabyte Z390 Designare rev 1.0.
Steve Berman
Re: [PATCH] memremap: Convert devmap static branch to {inc,dec}
Looks good to me.
Reviewed-by: William Kucharski
> On Aug 10, 2020, at 5:53 PM, ira.we...@intel.com wrote:
>
> From: Ira Weiny
>
> While reviewing Protection Key Supervisor support it was pointed out
> that using a counter to track static branch enable was an anti-pattern
> which was better solved using the provided static_branch_{inc,dec}
> functions.[1]
>
> Fix up devmap_managed_key to work the same way. Also this should be
> safer because there is a very small (very unlikely) race when multiple
> callers try to enable at the same time.
>
> [1]
> https://lore.kernel.org/lkml/20200714194031.gi5...@worktop.programming.kicks-ass.net/
>
> Cc: Dan Williams
> Cc: Vishal Verma
> Signed-off-by: Ira Weiny
> ---
> mm/memremap.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/mm/memremap.c b/mm/memremap.c
> index 03e38b7a38f1..9fb9ad500e78 100644
> --- a/mm/memremap.c
> +++ b/mm/memremap.c
> @@ -40,12 +40,10 @@ EXPORT_SYMBOL_GPL(memremap_compat_align);
> #ifdef CONFIG_DEV_PAGEMAP_OPS
> DEFINE_STATIC_KEY_FALSE(devmap_managed_key);
> EXPORT_SYMBOL(devmap_managed_key);
> -static atomic_t devmap_managed_enable;
>
> static void devmap_managed_enable_put(void)
> {
> - if (atomic_dec_and_test(_managed_enable))
> - static_branch_disable(_managed_key);
> + static_branch_dec(_managed_key);
> }
>
> static int devmap_managed_enable_get(struct dev_pagemap *pgmap)
> @@ -56,8 +54,7 @@ static int devmap_managed_enable_get(struct dev_pagemap
> *pgmap)
> return -EINVAL;
> }
>
> - if (atomic_inc_return(_managed_enable) == 1)
> - static_branch_enable(_managed_key);
> + static_branch_inc(_managed_key);
> return 0;
> }
> #else
> --
> 2.28.0.rc0.12.gb6a658bd00c9
>
>
RE: VDPA Debug/Statistics
On Tue, Aug 11, 2020 at 11:26:20AM +, Eli Cohen wrote: > Hi All > > Currently, the only statistics we get for a VDPA instance comes from the > virtio_net device instance. Since VDPA involves hardware acceleration, there > can be quite a lot of information that can be fetched from the underlying > device. Currently there is no generic method to fetch this information. > > One way of doing this can be to create a the host, a net device for > each VDPA instance, and use it to get this information or do some > configuration. Ethtool can be used in such a case > > I would like to hear what you think about this or maybe you have some other > ideas to address this topic. > > Thanks, > Eli Something I'm not sure I understand is how are vdpa instances created on mellanox cards? There's a devlink command for that, is that right? Can that be extended for stats? Currently any VF will be probed as VDPA device. We're adding devlink support but I am not sure if devlink is suitable for displaying statistics. We will discuss internally but I wanted to know why you guys think. -- MST
Re: [PATCH] serial: qcom_geni_serial: Fix recent kdb hang
On 8/11/2020 2:56 AM, Doug Anderson wrote:
Hi,
On Mon, Aug 10, 2020 at 5:32 AM Akash Asthana wrote:
Hi Doug,
On 8/7/2020 10:49 AM, Douglas Anderson wrote:
The commit e42d6c3ec0c7 ("serial: qcom_geni_serial: Make kgdb work
even if UART isn't console") worked pretty well and I've been doing a
lot of debugging with it. However, recently I typed "dmesg" in kdb
and then held the space key down to scroll through the pagination. My
device hung. This was repeatable and I found that it was introduced
with the aforementioned commit.
It turns out that there are some strange boundary cases in geni where
in some weird situations it will signal RX_LAST but then will put 0 in
RX_LAST_BYTE. This means that the entire last FIFO entry is valid.
IMO that means we received a word in RX_FIFO and it is the last word
hence RX_LAST bit is set.
What you say would make logical sense, but it's not how I have
observed geni to work. See below.
RX_LAST_BYTE is 0 means none of the bytes are valid in the last word.
This would imply that qcom_geni_serial_handle_rx() is also broken
though, wouldn't it? Specifically imagine that WORD_CNT is 1 and
RX_LAST is set and RX_LAST_BYTE_VALID is true. Here's the logic from
that function:
total_bytes = BYTES_PER_FIFO_WORD * (word_cnt - 1);
if (last_word_partial && last_word_byte_cnt)
total_bytes += last_word_byte_cnt;
else
total_bytes += BYTES_PER_FIFO_WORD;
port->handle_rx(uport, total_bytes, drop);
As you can see that logic will set "total_bytes" to 4 in the case I'm
talking about.
Yeah IMO as per theory this should also be corrected but since you have
already pulled out few experiment to prove garbage data issue(which I
was suspecting) is not seen.
It's already consistent with existing logic and it behaves well
practically . So the changes could be merge. Meanwhile I am checking
with HW team to get clarity.
In such scenario we should just read RX_FIFO buffer (to empty it),
discard the word and return NO_POLL_CHAR. Something like below.
-
else
private_data->poll_cached_bytes_cnt = 4;
private_data->poll_cached_bytes =
readl(uport->membase + SE_GENI_RX_FIFOn);
}
+if (!private_data->poll_cached_bytes_cnt)
+ return NO_POLL_CHAR;
private_data->poll_cached_bytes_cnt--;
ret = private_data->poll_cached_bytes & 0xff;
-
Please let me know whether above code helps.
Your code will avoid the hang. Yes. ...but it will drop bytes. I
devised a quick-n-dirty test. Here's a test of your code:
I assumed those as invalid bytes and don't wanted to read them so yeah
dropping of bytes was expected.
https://crrev.com/c/2346886
...and here's a test of my code:
https://crrev.com/c/2346884
I had to keep a buffer around since it's hard to debug the serial
driver. In both cases I put "DOUG" into the buffer when I detect this
case. If my theory about how geni worked was wrong then we should
expect to see some garbage in the buffer right after the DOUG, right?
...but my code gets the alphabet in nice sequence. Your code drops 4
bytes.
Yeah I was expecting garbage data.
NOTE: while poking around with the above two test patches I found it
was pretty easy to get geni to drop bytes / hit overflow cases and
also to insert bogus 0 bytes in the stream (I believe these are
related). I was able to reproduce this:
* With ${SUBJECT} patch in place.
* With your proposed patch.
* With the recent "geni" patches reverted (in other words back to 1
byte per FIFO entry).
It's not terribly surprising that we're overflowing since I believe
kgdb isn't too keen to read characters at the same time it's writing.
That doesn't explain the weird 0-bytes that geni seemed to be
inserting, but at least it would explain the overflows. However, even
after I fixed this I _still_ was getting problems. Specifically geni
seemed to be hiding bytes from me until it was too late. I put
logging in and would see this:
1 word in FIFO - wxyz
1 word in FIFO (last set, last FIFO has 1 byte) - \n
Check again, still 0 bytes in FIFO
Suddenly 16 bytes are in FIFO and S_RX_FIFO_WR_ERR_EN is set.
RX data first stored in RX_ASYNC_FIFO then it's transfered to RX_FIFO
When get_char is called and we observe 0 bytes in RX_FIFO, most probably
data is not transfered from RX_ASYNC_FIFO to RX_FIFO.
BITS 27:25 of SE_GENI_RX_FIFO_STATUS register shows RX_ASYNC_FIFO word
count.
I spent a whole bunch of time poking at this and couldn't find any
sort of workaround. Presumably geni is taking some time between me
reading the last word out of the FIFO
Re: [PATCH] net: eliminate meaningless memcpy to data in pskb_carve_inside_nonlinear()
Florian Westphal wrote: >Miaohe Lin wrote: >> The skb_shared_info part of the data is assigned in the following loop. > >Where? > It's at the below for (i = 0; i < nfrags; i++) loop. But I missed something as Eric Dumazet pointed out. Sorry about it.
Re: [PATCH 0/5] Some clean-ups for bio merge
Hi, On Wed, Jul 29, 2020 at 11:28:32AM +0800, Baolin Wang wrote: > Hi, > > There are some duplicated code when trying to merge bio from pluged list > and software queue, thus this patch set did some clean-ups when merging > a bio. Any comments are welcome. Thanks. Any comments for this patch set? Thanks. > > Baolin Wang (5): > block: Move bio merge related functions into blk-merge.c > block: Remove redundant blk_mq_sched_allow_merge() validation > block: Add a new helper to attempt to merge a bio > block: Remove blk_mq_attempt_merge() function > block: Remove __blk_mq_sched_bio_merge() helper > > block/blk-core.c | 156 --- > block/blk-merge.c| 168 > +++ > block/blk-mq-sched.c | 64 ++-- > block/blk-mq-sched.h | 13 +--- > block/blk.h | 9 +++ > 5 files changed, 197 insertions(+), 213 deletions(-) > > -- > 1.8.3.1
RE: [PATCH] net: untag pointer in sockptr_is_kernel
> On Tue, Aug 11, 2020 at 06:27:04PM +0800, Miles Chen wrote: > > From: Miles Chen > > > > sockptr_is_kernel() uses (sockptr.kernel >= TASK_SIZE) to tell > > if the pointer is kernel space or user space. When user space uses > > the "top byte ignored" feature such as HWAsan, we must untag > > the pointer before checking against TASK_SIZE. > > > > sockptr_is_kernel() will view a tagged user pointer as a kernel pointer > > and use memcpy directly and causes a kernel crash. > > Dave merged a patch from me to rever the optimized sockptr > implementation for now. If we bring it back we should fold in your > fix. I missed that going though :-( I've looked for a fix to the access_ok(kernel_addr,0) being true issue. Shouldn't TASK_SIZE be increased to cover all the 'tagged' addresses? ISTR the 'tag' bits are the 'next' 8 (or so) address bits at the top of valid user addresses. Then presumably the user-copies would be able to use the tagged address values getting whatever protection that gives. ISTM that for kernel-user boundary checks TASK_SIZE is the wrong constant. (The upper limit for mmap() is entirely different.) The limit should be independent of whether the process is 32 or 64bit (any fault above 4G will fail to find a user-page for 32bit). The limit can also go well into the address 'black hole' that exists on x86-x64 (and similar) between valid user and kernel addresses - handling the relevant trap should be too hard (it is always an error, so need not be fast). So with set_fs(KERNEL_DS) gone x86-x64 can (almost certainly) do a cheap test for (long)addr >= 0 in access_ok() (+ length test). While set_fs() is needed it can be: ((long)addr & current->mask) >= 0 (masking off the top bit if kernel addresses are valid). David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH] sched/fair: Remove the duplicate check from group_has_capacity()
On 2020/8/11 下午6:38, Valentin Schneider wrote: On 11/08/20 04:39, Qi Zheng wrote: On 2020/8/11 上午2:33, Valentin Schneider wrote: On 10/08/20 02:00, Qi Zheng wrote: 1. The group_has_capacity() function is only called in group_classify(). 2. The following inequality has already been checked in group_is_overloaded() which was also called in group_classify(). (sgs->group_capacity * imbalance_pct) < (sgs->group_runnable * 100) Consider group_is_overloaded() returns false because of the first condition: if (sgs->sum_nr_running <= sgs->group_weight) return false; then group_has_capacity() would be the first place where the group_runnable vs group_capacity comparison would be done. Now in that specific case we'll actually only check it if sgs->sum_nr_running == sgs->group_weight and the only case where the runnable vs capacity check can fail here is if there's significant capacity pressure going on. TBH this capacity pressure could be happening even when there are fewer tasks than CPUs, so I'm not sure how intentional that corner case is. Maybe some cpus in sg->cpumask are no longer active at the == case, which causes the significant capacity pressure? That can only happen in that short window between deactivating a CPU and not having rebuilt the sched_domains yet, which sounds quite elusive. In fact, at the beginning, I added unlikely() here to hint the compiler: - if ((sgs->group_capacity * imbalance_pct) < - (sgs->group_runnable * 100)) + if (unlikely((sgs->group_capacity * imbalance_pct) < + (sgs->group_runnable * 100))) The corresponding patch is as follows: [PATCH]sched/core: add unlikely in group_has_capacity() Do you think it is necessary?
Re: [PATCH v2] media: rcar-vin: Add support to select data pins for YCbCr422-8bit input
Hi Prabhakar, On Fri, Aug 07, 2020 at 09:20:36PM +0100, Lad, Prabhakar wrote: > On Wed, Aug 5, 2020 at 1:35 PM Laurent Pinchart wrote: > > On Wed, Aug 05, 2020 at 10:43:25AM +0200, Geert Uytterhoeven wrote: > >> On Wed, Aug 5, 2020 at 10:01 AM Lad, Prabhakar wrote: > >>> On Tue, Aug 4, 2020 at 4:32 PM Geert Uytterhoeven wrote: > On Tue, Aug 4, 2020 at 5:12 PM Lad, Prabhakar wrote: > > On Tue, Aug 4, 2020 at 11:17 AM Geert Uytterhoeven wrote: > >> On Tue, Aug 4, 2020 at 12:05 PM Niklas wrote: > >>> On 2020-08-04 09:04:25 +0100, Lad, Prabhakar wrote: > On Mon, Aug 3, 2020 at 8:28 PM Niklas wrote: > > On 2020-08-03 20:17:54 +0100, Lad, Prabhakar wrote: > >> On Mon, Aug 3, 2020 at 7:06 PM Niklas wrote: > >>> On 2020-08-03 17:02:53 +0100, Lad Prabhakar wrote: > Select the data pins for YCbCr422-8bit input format depending on > bus_width and data_shift passed as part of DT. > > Signed-off-by: Lad Prabhakar > > Reviewed-by: Biju Das > > --- a/drivers/media/platform/rcar-vin/rcar-core.c > +++ b/drivers/media/platform/rcar-vin/rcar-core.c > @@ -624,6 +624,11 @@ static int rvin_parallel_parse_v4l2(struct > device *dev, > vin->parallel = rvpe; > vin->parallel->mbus_type = vep->bus_type; > > + /* select VInDATA[15:8] pins for YCbCr422-8bit format */ > + if (vep->bus.parallel.bus_width == BUS_WIDTH_8 && > + vep->bus.parallel.data_shift == DATA_SHIFT_8) > + vin->parallel->ycbcr_8b_g = true; > + > >>> > >>> I would store the bus_width and bus_shift values in the struct > >>> rvin_parallel_entity and evaluate them in place rater then create > >>> a flag > >>> for this specific use-case.. > >>> > >> Ok will do that. > >> > >>> Also according to the documentation is the check correct? Do we > >>> not wish > >>> to use the new mode when bus_width == 16 and bus_shift == 8. The > >>> check > >>> you have here seems to describe a 8 lane bus where 0 lanes are > >>> used. > >>> > >> bus-width is the actual data lines used, so bus_width == 16 and > >> bus_shift == 8 would mean use lines 23:8, so just check for > >> bus_width > >> == 8 and bus_shift == 8 should be sufficient. > > > > As you and Geert points out I was wrong, they should indeed both be > > 8. > > > >> > >>> I think you should also verify that bus_shift is either 0 or 8 as > >>> that > >>> is all the driver supports. > >>> > >> Not sure if thats correct.In that case this patch wont make sense, > >> I > >> believed we agreed upon we determine the YDS depending on both > >> bus-width and bus-shift. > > > > I'm sorry I think I lost you :-) The driver is not capable of > > supporting > > bus_width = 8 and bus_shift = 2 right? Maybe we are talking about > > different things. > > > > What I tried to say (updated with the knowledge of that bus_width > > should > > indeed be 8 and not 16) was that would it make sens to with > > bus_width=8 > > allow for a bus_shift value other then 0 or 8? What for example > > would > > the driver do if the value was 2? > > > I think this should be possible but I am not sure how this will work. > For example on iWave G21D-Q7 platform with 16-bit wired bus say we > connect a 8-bit camera as below: > > bus-width = 8 and bus-shift = 2 > VI1_G0_B-> Not connected > VI1_G1_B-> Not connected > VI1_G2_B_16-> Connected > VI1_G3_B-> Connected > VI1_G4_B-> Connected > VI1_G5_B-> Connected > VI1_G6_B-> Connected > VI1_G7_B-> Connected > VI1_DATA7_B/VI1_B7_B_16-> Connected > VI1_DATA6_B/VI1_B6_B_16-> Connected > VI1_DATA5_B/VI1_B5_B_16-> Not connected > VI1_DATA4_B/VI1_B4_B_16-> Not connected > VI1_DATA3_B/VI1_B3_B_16-> Not connected > VI1_DATA2_B/VI1_B2_B_16-> Not connected > VI1_DATA1_B/VI1_B1_B_16-> Not connected > VI1_DATA0_B/VI1_B0_B_16-> Not connected > >>> > >>> I agree this is how I would imagine bus-width = 8 and bus-shift = 2 to > >>> be wired. > >>> > So in this case for 8-bit YCbCr422 format should YDS be set I am not > sure. Or is this not a valid case at all ? > >>> > >>> That is my question :-) > >>> >
[RESEND PATCH v3 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. v3: Replaced port@0 with just port in panel@0 node. [1]: Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Tianma nt36672a panel drm: panel: Add tianma nt36672a panel driver .../display/panel/tianma,nt36672a.yaml| 95 ++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++ 5 files changed, 973 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c -- 2.27.0
[RESEND PATCH v3 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
The nt36672a panel from Tianma is a FHD+ panel with a resolution of
1080x2246 and 6.18 inches size. It is found in some of the Poco F1
phones.
Signed-off-by: Sumit Semwal
Reviewed-by: Rob Herring
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0 to just 'port'.
---
.../display/panel/tianma,nt36672a.yaml| 95 +++
1 file changed, 95 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
new file mode 100644
index ..03dc323332a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tianma model NT36672A DSI Panel display driver
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a panel from Tianma is a FHD+ LCD display panel with a resolution
+ of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: tianma,nt36672a
+
+ reg:
+description: DSI virtual channel of the peripheral
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ pinctrl-names:
+description: Pinctrl for panel active and suspend
+
+ pinctrl-0:
+description: Active pinctrls
+
+ pinctrl-1:
+description: Suspend pinctrls
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - pinctrl-names
+ - pinctrl-0
+ - pinctrl-1
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "tianma,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+pinctrl-names = "panel_active", "panel_suspend";
+pinctrl-0 = <_dsi_active>;
+pinctrl-1 = <_dsi_suspend>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port {
+ tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+ };
+};
+
+...
--
2.27.0
[RESEND PATCH v3 2/2] drm: panel: Add tianma nt36672a panel driver
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
With current AOSP, we need to increase it to 200ms - this seems to be a
safe high value to avoid a white screen occasionally.
Signed-off-by: Sumit Semwal
Cc: Benni Steini
---
v2: increase reset sequence timing to a safe 200ms
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++
4 files changed, 878 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b4a43a9e7fbc..2d384e51353b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5544,6 +5544,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 39055c1f0e2f..da9d74c1ec91 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -437,6 +437,17 @@ config DRM_PANEL_TPO_TD043MTEA1
Say Y here if you want to enable support for TPO TD043MTEA1 800x480
4.3" panel (found on the OMAP3 Pandora board).
+config DRM_PANEL_TIANMA_FHD_NT36672A
+ tristate "TIANMA NT36672A panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Tianma NT36672A
+ panel. It is seen mostly in Xiaomi Poco F1 mobile phone.
+ The panel has a 1080x2246 resolution and uses 24 bit RGB per pixel.
+ It provides a MIPI DSI interface to the host.
+
config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index de74f282c433..303e44eb50fa 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TIANMA_FHD_NT36672A) += panel-tianma-nt36672a.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
new file mode 100644
index ..07e8461b8893
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
@@ -0,0 +1,859 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const char * const regulator_names[] = {
+ "vddio",
+ "vddpos",
+ "vddneg",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100
+};
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ const char *panel_name;
+
+ unsigned int width_mm;
+ unsigned int height_mm;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+
+ const struct panel_cmd *on_cmds_1;
+ const struct panel_cmd *on_cmds_2;
+
+ const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+ struct gpio_desc *reset_gpio;
+
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *active;
+ struct
Re: [PATCH 1/2] ASoC: q6afe-dai: add dummy register read function
On Tue, Aug 11, 2020 at 01:04:09PM +0200, Stephan Gerhold wrote:
> Actually q6afe-dai does not seem to make use of the register number.
> The DAPM widgets all look like
> SND_SOC_DAPM_AIF_IN("HDMI_RX", NULL, 0,0, 0, 0),
> /* (wname,stname, wchan, wreg, wshift, winvert)
> Wouldn't it be better to replace wreg = 0 with SND_SOC_NOPM in this case
> so the read/write won't happen at all?
Yes, if they are not used at all then that's what _NOPM is for.
signature.asc
Description: PGP signature
Re: [PATCH v5 01/12] ASoC: qcom: Add common array to initialize soc based core clocks
On Tue, Aug 11, 2020 at 04:13:03PM +0530, Rohit Kumar wrote: > Do you see any concern with patches (1-11). > As of now, there is comment only in patch 12 from Rob which I am > planning to update once other patches are merged. Can you > please review and let me know if anything is missing. Please just post the fixed series instead of sending me a stream of pings, it must be taking you more time to do this than it would to just send the fix. I'm not going to apply your patches during the merge window, they are not bug fixes and sending me content free pings just makes me delay the review. signature.asc Description: PGP signature
Re: VDPA Debug/Statistics
On Tue, Aug 11, 2020 at 11:26:20AM +, Eli Cohen wrote: > Hi All > > Currently, the only statistics we get for a VDPA instance comes from the > virtio_net device instance. Since VDPA involves hardware acceleration, there > can be quite a lot of information that can be fetched from the underlying > device. Currently there is no generic method to fetch this information. > > One way of doing this can be to create a the host, a net device for each VDPA > instance, and use it to get this information or do some configuration. > Ethtool can be used in such a case > > I would like to hear what you think about this or maybe you have some other > ideas to address this topic. > > Thanks, > Eli Something I'm not sure I understand is how are vdpa instances created on mellanox cards? There's a devlink command for that, is that right? Can that be extended for stats? -- MST
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
On Tue, Aug 11, 2020 at 12:26:49PM +0200, Michal Hocko wrote: > On Tue 11-08-20 11:37:13, Uladzislau Rezki wrote: > > On Tue, Aug 11, 2020 at 10:19:17AM +0200, Michal Hocko wrote: > > > On Mon 10-08-20 21:25:26, Michal Hocko wrote: > > > > On Mon 10-08-20 18:07:39, Uladzislau Rezki wrote: > > > [...] > > > > > The problem that i see is we can not use the page allocator from > > > > > atomic > > > > > contexts, what is our case: > > > > > > > > > > > > > > > local_irq_save(flags) or preempt_disable() or raw_spinlock(); > > > > > __get_free_page(GFP_ATOMIC); > > > > > > > > > > > > > > > So if we can convert the page allocator to raw_* lock it will be > > > > > appreciated, > > > > > at least from our side, IMHO, not from RT one. But as i stated above > > > > > we need > > > > > to sort raised questions out if converting is done. > > > > > > > > > > What is your view? > > > > > > > > To me it would make more sense to support atomic allocations also for > > > > the RT tree. Having both GFP_NOWAIT and GFP_ATOMIC which do not really > > > > work for atomic context in RT sounds subtle and wrong. > > > > > > I was thinking about this some more. I still think the above would be a > > > reasonable goal we should try to achieve. If for not other then for > > > future maintainability (especially after the RT patchset is merged). > > > I have tried to search for any known problems/attempts to make > > > zone->lock raw but couldn't find anything. Maybe somebody more involved > > > in RT world have something to say about that. > > > > > I tried yesterday to convert zone->lock. See below files i had to modify: > > > > modified: include/linux/mmzone.h > > modified: mm/compaction.c > > modified: mm/memory_hotplug.c > > modified: mm/page_alloc.c > > modified: mm/page_isolation.c > > modified: mm/page_reporting.c > > modified: mm/shuffle.c > > modified: mm/vmscan.c > > modified: mm/vmstat.c > > > > > > There is one more lock, that is zone->lru_lock one. Both zone->lock and this > > one intersect between each other. If the lru_lock can be nested under > > zone->lock > > it should be converted as well. But i need to analyze it farther. There are > > two wrapper functions which are used as common interface to lock/unlock both > > locks. See compact_lock_irqsave()/compact_unlock_should_abort_lru() in the > > mm/compaction.c. > > > > Any thoughts here? > > I am not an expert on compaction. Vlastimil would know better. My > thinking was that zone->lock is a tail lock but compaction/page > isolation might be doing something I am not aware of right now. > > > Anyway i tried to convert only zone->lock and use page allocator passing > > there > > gfp_mask=0 as argument. So it works. CONFIG_PROVE_RAW_LOCK_NESTING does not > > complain about any "bad" lock nesting. > > > > > Anyway, if the zone->lock is not a good fit for raw_spin_lock then the > > > only way I can see forward is to detect real (RT) atomic contexts and > > > bail out early before taking the lock in the allocator for NOWAIT/ATOMIC > > > requests. > > > > > For RT kernel we can detect it for sure. preemtable() works just fine there, > > i.e. we can identify the context we are currently in. > > In previous email I didn't mention why I prefer full NOWAIT semantic > over rt specific bailouts. There are users making NOWAIT allocation > attempts as an opportunistic allocation request which is OK to fail > as they have a fallback to go through. This would imply they would > prefer to know this ASAP rather then get blocked and sleep. A lack of > reports for PREEMPT_RT would suggest that nobody has noticed as this > though. > I agree here and share your view on it. To me, making *_ATOMIC *_NOWAIT to be fully workable on both kernels sounds like correct way to go. Indeed, there can be no complains as of now. But later on it can be and the question will be raised again, what to do. -- Vlad Rezki
[PATCH v3] sched/fair: simplfy the work when reweighting entity
From: Jiang Biao The code in reweight_entity() can be simplified. For a sched entity on the rq, the entity accounting can be replaced by cfs_rq instantaneous load updates currently called from within the entity accounting. Even though an entity on the rq can't represent a task in reweight_entity() (a task is always dequeued before calling this function) and so the numa task accounting and the rq->cfs_tasks list management of the entity accounting are never called, the redundant cfs_rq->nr_running decrement/increment will be avoided. Signed-off-by: Jiang Biao --- v3<-v2: Amend commit log taking Dietmar's advice. Thx. v2<-v1: Amend the commit log kernel/sched/fair.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 04fa8dbcfa4d..18a8fc7bd0de 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3086,7 +3086,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, /* commit outstanding execution time */ if (cfs_rq->curr == se) update_curr(cfs_rq); - account_entity_dequeue(cfs_rq, se); + update_load_sub(_rq->load, se->load.weight); } dequeue_load_avg(cfs_rq, se); @@ -3102,7 +3102,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, enqueue_load_avg(cfs_rq, se); if (se->on_rq) - account_entity_enqueue(cfs_rq, se); + update_load_add(_rq->load, se->load.weight); } -- 2.21.0
Re: [f2fs-dev] [PATCH] f2fs: change virtual mapping way for compression pages
Plus, differently from your testbed, in my pixel device, there seems to be much more contention in vmap() operation. If it's not there, I agree that there might not be a big difference between vmap() and vm_map_ram(). 2020년 8월 11일 (화) 오후 8:29, Gao Xiang 님이 작성: > > On Tue, Aug 11, 2020 at 08:21:23PM +0900, Daeho Jeong wrote: > > Sure, I'll update the test condition as you said in the commit message. > > FYI, the test is done with 16kb chunk and Pixel 3 (arm64) device. > > Yeah, anyway, it'd better to lock the freq and offline the little > cores in your test as well (it'd make more sense). e.g. if 16k cluster > is applied, even all data is zeroed, the count of vmap/vm_map_ram > isn't hugeous (and as you said, "sometimes, it has a very long delay", > it's much like another scheduling concern as well). > > Anyway, I'm not against your commit but the commit message is a bit > of unclear. At least, if you think that is really the case, I'm ok > with that. > > Thanks, > Gao Xiang > > > > > Thanks, > > > > 2020ë…„ 8ì›” 11ì�¼ (í™”) 오후 7:18, Gao Xiang > > 님ì�´ 작성: > > > > > > On Tue, Aug 11, 2020 at 06:33:26PM +0900, Daeho Jeong wrote: > > > > Plus, when we use vmap(), vmap() normally executes in a short time > > > > like vm_map_ram(). > > > > But, sometimes, it has a very long delay. > > > > > > > > 2020ë…„ 8ì›â€� 11� (Ãâ„¢â€�) 오Û„ 6:28, Daeho > > > > Jeong 님� 작성: > > > > > > > > > > Actually, as you can see, I use the whole zero data blocks in the > > > > > test file. > > > > > It can maximize the effect of changing virtual mapping. > > > > > When I use normal files which can be compressed about 70% from the > > > > > original file, > > > > > The vm_map_ram() version is about 2x faster than vmap() version. > > > > > > What f2fs does is much similar to btrfs compression. Even if these > > > blocks are all zeroed. In principle, the maximum compression ratio > > > is determined (cluster sized blocks into one compressed block, e.g > > > 16k cluster into one compressed block). > > > > > > So it'd be better to describe your configured cluster size (16k or > > > 128k) and your hardware information in the commit message as well. > > > > > > Actually, I also tried with this patch as well on my x86 laptop just > > > now with FIO (I didn't use zeroed block though), and I didn't notice > > > much difference with turbo boost off and maxfreq. > > > > > > I'm not arguing this commit, just a note about this commit message. > > > > > > >> 1048576000 bytes (0.9 G) copied, 9.146217 s, 109 M/s > > > > > > >> 1048576000 bytes (0.9 G) copied, 9.997542 s, 100 M/s > > > > > > >> 1048576000 bytes (0.9 G) copied, 10.109727 s, 99 M/s > > > > > > IMHO, the above number is much like decompressing in the arm64 little > > > cores. > > > > > > Thanks, > > > Gao Xiang > > > > > > > > > > > > > > > > 2020ë…„ 8ì›â€� 11� (Ãâ„¢â€�) 오Û„ 4:55, Chao > > > > > Yu 님� 작성: > > > > > > > > > > > > On 2020/8/11 15:15, Gao Xiang wrote: > > > > > > > On Tue, Aug 11, 2020 at 12:37:53PM +0900, Daeho Jeong wrote: > > > > > > >> From: Daeho Jeong > > > > > > >> > > > > > > >> By profiling f2fs compression works, I've found vmap() callings > > > > > > >> are > > > > > > >> bottlenecks of f2fs decompression path. Changing these with > > > > > > >> vm_map_ram(), we can enhance f2fs decompression speed pretty > > > > > > >> much. > > > > > > >> > > > > > > >> [Verification] > > > > > > >> dd if=/dev/zero of=dummy bs=1m count=1000 > > > > > > >> echo 3 > /proc/sys/vm/drop_caches > > > > > > >> dd if=dummy of=/dev/zero bs=512k > > > > > > >> > > > > > > >> - w/o compression - > > > > > > >> 1048576000 bytes (0.9 G) copied, 1.999384 s, 500 M/s > > > > > > >> 1048576000 bytes (0.9 G) copied, 2.035988 s, 491 M/s > > > > > > >> 1048576000 bytes (0.9 G) copied, 2.039457 s, 490 M/s > > > > > > >> > > > > > > >> - before patch - > > > > > > >> 1048576000 bytes (0.9 G) copied, 9.146217 s, 109 M/s > > > > > > >> 1048576000 bytes (0.9 G) copied, 9.997542 s, 100 M/s > > > > > > >> 1048576000 bytes (0.9 G) copied, 10.109727 s, 99 M/s > > > > > > >> > > > > > > >> - after patch - > > > > > > >> 1048576000 bytes (0.9 G) copied, 2.253441 s, 444 M/s > > > > > > >> 1048576000 bytes (0.9 G) copied, 2.739764 s, 365 M/s > > > > > > >> 1048576000 bytes (0.9 G) copied, 2.185649 s, 458 M/s > > > > > > > > > > > > > > Indeed, vmap() approach has some impact on the whole > > > > > > > workflow. But I don't think the gap is such significant, > > > > > > > maybe it relates to unlocked cpufreq (and big little > > > > > > > core difference if it's on some arm64 board). > > > > > > > > > > > > Agreed, > > > > > > > > > > > > I guess there should be other reason causing the large performance > > > > > > gap, scheduling, frequency, or something else. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ___ > > > > > > >
drivers/net/wireless/ti/wlcore/main.c:643:34: sparse: sparse: context imbalance in 'wlcore_irq_locked' - different lock contexts for basic block
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 00e4db51259a5f936fec1424b884f029479d3981
commit: f0325e38ab39c2e270770b72c79795772ac3b49e wlcore: Use spin_trylock in
wlcore_irq_locked() for running the queue
date: 4 weeks ago
config: mips-randconfig-s032-20200811 (attached as .config)
compiler: mips64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout f0325e38ab39c2e270770b72c79795772ac3b49e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/net/wireless/ti/wlcore/main.c:643:34: sparse: sparse: context
>> imbalance in 'wlcore_irq_locked' - different lock contexts for basic block
vim +/wlcore_irq_locked +643 drivers/net/wireless/ti/wlcore/main.c
1e73eb62cec7cf drivers/net/wireless/wl12xx/wl1271_main.c Juuso Oikarinen
2010-02-22 518
b5b45b3cbd5616 drivers/net/wireless/ti/wlcore/main.c Arik Nemtsov
2012-06-21 519 static int wlcore_irq_locked(struct wl1271 *wl)
f5fc0f86b02afe drivers/net/wireless/wl12xx/wl1271_main.c Luciano Coelho
2009-08-06 520 {
b5b45b3cbd5616 drivers/net/wireless/ti/wlcore/main.c Arik Nemtsov
2012-06-21 521int ret = 0;
c15f63bffabb99 drivers/net/wireless/wl12xx/wl1271_main.c Juuso Oikarinen
2009-10-12 522u32 intr;
1e73eb62cec7cf drivers/net/wireless/wl12xx/wl1271_main.c Juuso Oikarinen
2010-02-22 523int loopcount = WL1271_IRQ_MAX_LOOPS;
f0325e38ab39c2 drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2020-07-02 524bool run_tx_queue = true;
a620865edf62ea drivers/net/wireless/wl12xx/main.cIdo Yariv
2011-03-01 525bool done = false;
a620865edf62ea drivers/net/wireless/wl12xx/main.cIdo Yariv
2011-03-01 526unsigned int defer_count;
b07d4037051318 drivers/net/wireless/wl12xx/main.cIdo Yariv
2011-03-01 527unsigned long flags;
b07d4037051318 drivers/net/wireless/wl12xx/main.cIdo Yariv
2011-03-01 528
341b7cde6ccc60 drivers/net/wireless/wl12xx/main.cIdo Yariv
2011-03-31 529/*
341b7cde6ccc60 drivers/net/wireless/wl12xx/main.cIdo Yariv
2011-03-31 530 * In case edge triggered interrupt must be used, we
cannot iterate
341b7cde6ccc60 drivers/net/wireless/wl12xx/main.cIdo Yariv
2011-03-31 531 * more than once without introducing race conditions
with the hardirq.
341b7cde6ccc60 drivers/net/wireless/wl12xx/main.cIdo Yariv
2011-03-31 532 */
6f921fab584494 drivers/net/wireless/ti/wlcore/main.c Luciano Coelho
2015-03-18 533if (wl->irq_flags & (IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING))
341b7cde6ccc60 drivers/net/wireless/wl12xx/main.cIdo Yariv
2011-03-31 534loopcount = 1;
341b7cde6ccc60 drivers/net/wireless/wl12xx/main.cIdo Yariv
2011-03-31 535
f5fc0f86b02afe drivers/net/wireless/wl12xx/wl1271_main.c Luciano Coelho
2009-08-06 536wl1271_debug(DEBUG_IRQ, "IRQ work");
f5fc0f86b02afe drivers/net/wireless/wl12xx/wl1271_main.c Luciano Coelho
2009-08-06 537
4cc533830b7e6b drivers/net/wireless/ti/wlcore/main.c Ido Yariv
2012-07-24 538if (unlikely(wl->state != WLCORE_STATE_ON))
f5fc0f86b02afe drivers/net/wireless/wl12xx/wl1271_main.c Luciano Coelho
2009-08-06 539goto out;
f5fc0f86b02afe drivers/net/wireless/wl12xx/wl1271_main.c Luciano Coelho
2009-08-06 540
fa2648a34e73fb drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2018-06-19 541ret = pm_runtime_get_sync(wl->dev);
fa2648a34e73fb drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2018-06-19 542if (ret < 0) {
fa2648a34e73fb drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2018-06-19 543pm_runtime_put_noidle(wl->dev);
f5fc0f86b02afe drivers/net/wireless/wl12xx/wl1271_main.c Luciano Coelho
2009-08-06 544goto out;
fa2648a34e73fb drivers/net/wireless/ti/wlcore/main.c Tony Lindgren
2018-06-19 545}
f5fc0f86b02afe drivers/net/wireless/wl12xx/wl1271_main.c Luciano Coelho
2009-08-06 546
a620865edf62ea drivers/net/wireless/wl12xx/main.cIdo Yariv
2011-03-01 547while (!done && loopcount--) {
4e857c58efeb99 drivers/net/wireless/ti/wlcore/main.c Peter Zijlstra
2014-03-17 548smp_mb__after_atomic();
1e73eb62cec7cf drivers/net/wireles
Re: [Resend PATCH 2/6] mm/memcg: remove useless check on page->mem_cgroup
subject line looks like a left over. It doesn't match the path. Did you mean memcg: bail out early from swap accounting when memcg is disabled? Btw. if this patch was first in the series then you wouldn't need to mention the warnings that would trigger based on your previous patch. I am fine with both ways but mentioning the warning is usefule. On Tue 11-08-20 19:10:28, Alex Shi wrote: > If we disabled memcg by cgroup_disable=memory, the swap charges are > still called. Let's return from the funcs earlier and keep WARN_ON > monitor. > > Signed-off-by: Alex Shi > Reviewed-by: Roman Gushchin > Acked-by: Michal Hocko > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Vladimir Davydov > Cc: Andrew Morton > Cc: cgro...@vger.kernel.org > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > --- > mm/memcontrol.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 299382fc55a9..419cf565f40b 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -7098,6 +7098,9 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t > entry) > VM_BUG_ON_PAGE(PageLRU(page), page); > VM_BUG_ON_PAGE(page_count(page), page); > > + if (mem_cgroup_disabled()) > + return; > + > if (cgroup_subsys_on_dfl(memory_cgrp_subsys)) > return; > > @@ -7163,6 +7166,9 @@ int mem_cgroup_try_charge_swap(struct page *page, > swp_entry_t entry) > struct mem_cgroup *memcg; > unsigned short oldid; > > + if (mem_cgroup_disabled()) > + return 0; > + > if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) > return 0; > > -- > 1.8.3.1 -- Michal Hocko SUSE Labs
Re: [f2fs-dev] [PATCH] f2fs: change virtual mapping way for compression pages
On Tue, Aug 11, 2020 at 08:21:23PM +0900, Daeho Jeong wrote: > Sure, I'll update the test condition as you said in the commit message. > FYI, the test is done with 16kb chunk and Pixel 3 (arm64) device. Yeah, anyway, it'd better to lock the freq and offline the little cores in your test as well (it'd make more sense). e.g. if 16k cluster is applied, even all data is zeroed, the count of vmap/vm_map_ram isn't hugeous (and as you said, "sometimes, it has a very long delay", it's much like another scheduling concern as well). Anyway, I'm not against your commit but the commit message is a bit of unclear. At least, if you think that is really the case, I'm ok with that. Thanks, Gao Xiang > > Thanks, > > 2020??? 8??? 11??? (???) ?? 7:18, Gao Xiang ?? > ??: > > > > On Tue, Aug 11, 2020 at 06:33:26PM +0900, Daeho Jeong wrote: > > > Plus, when we use vmap(), vmap() normally executes in a short time > > > like vm_map_ram(). > > > But, sometimes, it has a very long delay. > > > > > > 2020 8 11??? () ?? 6:28, Daeho > > > Jeong ?? ??: > > > > > > > > Actually, as you can see, I use the whole zero data blocks in the test > > > > file. > > > > It can maximize the effect of changing virtual mapping. > > > > When I use normal files which can be compressed about 70% from the > > > > original file, > > > > The vm_map_ram() version is about 2x faster than vmap() version. > > > > What f2fs does is much similar to btrfs compression. Even if these > > blocks are all zeroed. In principle, the maximum compression ratio > > is determined (cluster sized blocks into one compressed block, e.g > > 16k cluster into one compressed block). > > > > So it'd be better to describe your configured cluster size (16k or > > 128k) and your hardware information in the commit message as well. > > > > Actually, I also tried with this patch as well on my x86 laptop just > > now with FIO (I didn't use zeroed block though), and I didn't notice > > much difference with turbo boost off and maxfreq. > > > > I'm not arguing this commit, just a note about this commit message. > > > > > >> 1048576000 bytes (0.9 G) copied, 9.146217 s, 109 M/s > > > > > >> 1048576000 bytes (0.9 G) copied, 9.997542 s, 100 M/s > > > > > >> 1048576000 bytes (0.9 G) copied, 10.109727 s, 99 M/s > > > > IMHO, the above number is much like decompressing in the arm64 little cores. > > > > Thanks, > > Gao Xiang > > > > > > > > > > > > 2020 8 11??? () ?? 4:55, Chao > > > > Yu ?? ??: > > > > > > > > > > On 2020/8/11 15:15, Gao Xiang wrote: > > > > > > On Tue, Aug 11, 2020 at 12:37:53PM +0900, Daeho Jeong wrote: > > > > > >> From: Daeho Jeong > > > > > >> > > > > > >> By profiling f2fs compression works, I've found vmap() callings are > > > > > >> bottlenecks of f2fs decompression path. Changing these with > > > > > >> vm_map_ram(), we can enhance f2fs decompression speed pretty much. > > > > > >> > > > > > >> [Verification] > > > > > >> dd if=/dev/zero of=dummy bs=1m count=1000 > > > > > >> echo 3 > /proc/sys/vm/drop_caches > > > > > >> dd if=dummy of=/dev/zero bs=512k > > > > > >> > > > > > >> - w/o compression - > > > > > >> 1048576000 bytes (0.9 G) copied, 1.999384 s, 500 M/s > > > > > >> 1048576000 bytes (0.9 G) copied, 2.035988 s, 491 M/s > > > > > >> 1048576000 bytes (0.9 G) copied, 2.039457 s, 490 M/s > > > > > >> > > > > > >> - before patch - > > > > > >> 1048576000 bytes (0.9 G) copied, 9.146217 s, 109 M/s > > > > > >> 1048576000 bytes (0.9 G) copied, 9.997542 s, 100 M/s > > > > > >> 1048576000 bytes (0.9 G) copied, 10.109727 s, 99 M/s > > > > > >> > > > > > >> - after patch - > > > > > >> 1048576000 bytes (0.9 G) copied, 2.253441 s, 444 M/s > > > > > >> 1048576000 bytes (0.9 G) copied, 2.739764 s, 365 M/s > > > > > >> 1048576000 bytes (0.9 G) copied, 2.185649 s, 458 M/s > > > > > > > > > > > > Indeed, vmap() approach has some impact on the whole > > > > > > workflow. But I don't think the gap is such significant, > > > > > > maybe it relates to unlocked cpufreq (and big little > > > > > > core difference if it's on some arm64 board). > > > > > > > > > > Agreed, > > > > > > > > > > I guess there should be other reason causing the large performance > > > > > gap, scheduling, frequency, or something else. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ___ > > > > > > Linux-f2fs-devel mailing list > > > > > > linux-f2fs-de...@lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > > > > > . > > > > > > > > > > > >
[PATCH 2/2] clk: samsung: exynos5420: Avoid __clk_lookup() calls when enabling clocks
This patch adds a clk ID to the mout_sw_aclk_g3d clk definition so related
clk pointer gets cached in the driver's private data and can be used
later instead of a __clk_lookup() call.
With that we have all clocks used in the clk_prepare_enable() calls in the
clk provider init callback cached in clk_data.hws[] and we can reference
the clk pointers directly rather than using __clk_lookup() with global names.
Signed-off-by: Sylwester Nawrocki
---
Depends on patch:
[PATCH v2] clk: samsung: Keep top BPLL mux on Exynos542x enabled
drivers/clk/samsung/clk-exynos5420.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index bd62087..06841a6 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -712,8 +712,8 @@ static const struct samsung_mux_clock exynos5x_mux_clks[]
__initconst = {
SRC_TOP12, 8, 1),
MUX(0, "mout_sw_aclk266_g2d", mout_sw_aclk266_g2d_p,
SRC_TOP12, 12, 1),
- MUX_F(0, "mout_sw_aclk_g3d", mout_sw_aclk_g3d_p, SRC_TOP12, 16, 1,
- CLK_SET_RATE_PARENT, 0),
+ MUX_F(CLK_MOUT_SW_ACLK_G3D, "mout_sw_aclk_g3d", mout_sw_aclk_g3d_p,
+ SRC_TOP12, 16, 1, CLK_SET_RATE_PARENT, 0),
MUX(0, "mout_sw_aclk300_jpeg", mout_sw_aclk300_jpeg_p,
SRC_TOP12, 20, 1),
MUX(CLK_MOUT_SW_ACLK300, "mout_sw_aclk300_disp1",
@@ -1649,17 +1649,18 @@ static void __init exynos5x_clk_init(struct device_node
*np,
exynos5x_subcmus);
}
+ hws = ctx->clk_data.hws;
/*
* Keep top part of G3D clock path enabled permanently to ensure
* that the internal busses get their clock regardless of the
* main G3D clock enablement status.
*/
- clk_prepare_enable(__clk_lookup("mout_sw_aclk_g3d"));
+ clk_prepare_enable(hws[CLK_MOUT_SW_ACLK_G3D]->clk);
/*
* Keep top BPLL mux enabled permanently to ensure that DRAM operates
* properly.
*/
- clk_prepare_enable(__clk_lookup("mout_bpll"));
+ clk_prepare_enable(hws[CLK_MOUT_BPLL]->clk);
samsung_clk_of_add_provider(np, ctx);
}
--
2.7.4
[PATCH 1/2] clk: samsung: exynos5420: Add definition of clock ID for mout_sw_aclk_g3d
This patch adds ID for the mout_sw_aclk_g3d (SW_CLKMUX_ACLK_G3D) clock, mostly for internal use in the CMU driver. It will allow to avoid the __clk_lookup() call when setting up the clock during the clock provider initialization. Signed-off-by: Sylwester Nawrocki --- include/dt-bindings/clock/exynos5420.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/clock/exynos5420.h b/include/dt-bindings/clock/exynos5420.h index 02d5ac4..ff917c8 100644 --- a/include/dt-bindings/clock/exynos5420.h +++ b/include/dt-bindings/clock/exynos5420.h @@ -230,6 +230,7 @@ #define CLK_MOUT_USER_MAU_EPLL 659 #define CLK_MOUT_SCLK_SPLL 660 #define CLK_MOUT_MX_MSPLL_CCORE_PHY661 +#define CLK_MOUT_SW_ACLK_G3D 662 /* divider clocks */ #define CLK_DOUT_PIXEL 768 -- 2.7.4
Re: [PATCH 7/7] ARM: dts: r8a7742-iwg21d-q7: Add LCD support
Hi Prabhakar,
Thank you for the patch.
On Fri, Aug 07, 2020 at 06:49:54PM +0100, Lad Prabhakar wrote:
> The iwg21d comes with a 7" capacitive touch screen, therefore
> add support for it.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
> ---
> arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 84 +
> 1 file changed, 84 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> index b3461a61a4bf..cf59fd61e422 100644
> --- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> +++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> @@ -30,6 +30,7 @@
>
> /dts-v1/;
> #include "r8a7742-iwg21m.dtsi"
> +#include
>
> / {
> model = "iWave Systems RainboW-G21D-Qseven board based on RZ/G1H";
> @@ -52,6 +53,50 @@
> clock-frequency = <2600>;
> };
>
> + lcd_backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = < 2 500 0>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> + default-brightness-level = <7>;
> + enable-gpios = < 11 GPIO_ACTIVE_HIGH>;
It's actually a power supply, not an enable GPIO, but it doesn't matter
much, I don't think there's a need to declare a regulator just for the
sake of it.
> + };
> +
> + lvds-receiver {
> + compatible = "ti,ds90cf384a", "lvds-decoder";
> + powerdown-gpios = < 28 GPIO_ACTIVE_LOW>;
This should be handled as a shared power supply, as it's also needed for
the touch screen. Biju has sent patches for the iwg20d that fixes a
probe issue due to that problem, I think you can just copy the fix.
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds_receiver_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + lvds_receiver_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + panel {
> + compatible = "edt,etm0700g0dh6";
> + backlight = <_backlight>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_receiver_out>;
> + };
> + };
> + };
> +
> reg_1p5v: 1p5v {
> compatible = "regulator-fixed";
> regulator-name = "1P5V";
> @@ -129,12 +174,31 @@
> VDDIO-supply = <_3p3v>;
> VDDD-supply = <_1p5v>;
> };
> +
> + touch: touchpanel@38 {
> + compatible = "edt,edt-ft5406";
> + reg = <0x38>;
> + interrupt-parent = <>;
> + interrupts = <24 IRQ_TYPE_EDGE_FALLING>;
Should the reset GPIO also be wired ? It seems to be shared with the
audio codec though, which is annoying.
> + };
> };
>
> {
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + touch-interrupt {
> + gpio-hog;
> + gpios = <24 GPIO_ACTIVE_LOW>;
> + input;
> + };
Is this needed, or does requesting the interrupt in the touch screen
driver configured the GPIO to an input automatically ?
> +};
> +
> {
> pinctrl-0 = <_pins>;
> pinctrl-names = "default";
> @@ -165,6 +229,11 @@
> function = "avb";
> };
>
> + backlight_pins: backlight {
> + groups = "tpu0_to2";
> + function = "tpu0";
> + };
> +
> i2c2_pins: i2c2 {
> groups = "i2c2_b";
> function = "i2c2";
> @@ -208,6 +277,17 @@
> };
> };
>
> + {
> + status = "okay";
> + ports {
> + port@1 {
> + lvds0_out: endpoint {
> + remote-endpoint = <_receiver_in>;
> + };
> + };
> + };
> +};
> +
> _sound {
> pinctrl-0 = <_pins>;
> pinctrl-names = "default";
> @@ -261,6 +341,10 @@
> shared-pin;
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
--
Regards,
Laurent Pinchart
VDPA Debug/Statistics
Hi All Currently, the only statistics we get for a VDPA instance comes from the virtio_net device instance. Since VDPA involves hardware acceleration, there can be quite a lot of information that can be fetched from the underlying device. Currently there is no generic method to fetch this information. One way of doing this can be to create a the host, a net device for each VDPA instance, and use it to get this information or do some configuration. Ethtool can be used in such a case I would like to hear what you think about this or maybe you have some other ideas to address this topic. Thanks, Eli
[PATCH v2] clk: samsung: Prevent potential endless loop in the PLL set_rate ops
In the .set_rate callback for some PLLs there is a loop polling state
of the PLL lock bit and it may become an endless loop when something
goes wrong with the PLL. For some PLLs there is already (a duplicated)
code for polling with timeout. This patch replaces that code with
the readl_relaxed_poll_timeout_atomic() macro and moves it to a common
helper function, which is then used for all the PLLs. The downside
of switching to the common macro is that we drop the cpu_relax() call.
Using a common helper function rather than the macro directly allows
to avoid repeating the error message in the code and to avoid the object
code size increase due to inlining.
Signed-off-by: Sylwester Nawrocki
---
Changes for v2:
- use common readl_relaxed_poll_timeout_atomic() macro
---
drivers/clk/samsung/clk-pll.c | 92 +++
1 file changed, 32 insertions(+), 60 deletions(-)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index ac70ad7..c3c1efe 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -9,13 +9,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include "clk.h"
#include "clk-pll.h"
-#define PLL_TIMEOUT_MS 10
+#define PLL_TIMEOUT_US 1U
struct samsung_clk_pll {
struct clk_hw hw;
@@ -63,6 +64,22 @@ static long samsung_pll_round_rate(struct clk_hw *hw,
return rate_table[i - 1].rate;
}
+static int samsung_pll_lock_wait(struct samsung_clk_pll *pll,
+unsigned int reg_mask)
+{
+ u32 val;
+ int ret;
+
+ /* Wait until the PLL is in steady locked state */
+ ret = readl_relaxed_poll_timeout_atomic(pll->con_reg, val,
+ val & reg_mask, 0, PLL_TIMEOUT_US);
+ if (ret < 0)
+ pr_err("%s: Could not lock PLL %s\n",
+ __func__, clk_hw_get_name(>hw));
+
+ return ret;
+}
+
static int samsung_pll3xxx_enable(struct clk_hw *hw)
{
struct samsung_clk_pll *pll = to_clk_pll(hw);
@@ -241,12 +258,9 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw,
unsigned long drate,
writel_relaxed(tmp, pll->con_reg);
/* Wait until the PLL is locked if it is enabled. */
- if (tmp & BIT(pll->enable_offs)) {
- do {
- cpu_relax();
- tmp = readl_relaxed(pll->con_reg);
- } while (!(tmp & BIT(pll->lock_offs)));
- }
+ if (tmp & BIT(pll->enable_offs))
+ return samsung_pll_lock_wait(pll, BIT(pll->lock_offs));
+
return 0;
}
@@ -318,7 +332,7 @@ static int samsung_pll36xx_set_rate(struct clk_hw *hw,
unsigned long drate,
unsigned long parent_rate)
{
struct samsung_clk_pll *pll = to_clk_pll(hw);
- u32 tmp, pll_con0, pll_con1;
+ u32 pll_con0, pll_con1;
const struct samsung_pll_rate_table *rate;
rate = samsung_get_pll_settings(pll, drate);
@@ -356,13 +370,8 @@ static int samsung_pll36xx_set_rate(struct clk_hw *hw,
unsigned long drate,
pll_con1 |= rate->kdiv << PLL36XX_KDIV_SHIFT;
writel_relaxed(pll_con1, pll->con_reg + 4);
- /* wait_lock_time */
- if (pll_con0 & BIT(pll->enable_offs)) {
- do {
- cpu_relax();
- tmp = readl_relaxed(pll->con_reg);
- } while (!(tmp & BIT(pll->lock_offs)));
- }
+ if (pll_con0 & BIT(pll->enable_offs))
+ return samsung_pll_lock_wait(pll, BIT(pll->lock_offs));
return 0;
}
@@ -437,7 +446,6 @@ static int samsung_pll45xx_set_rate(struct clk_hw *hw,
unsigned long drate,
struct samsung_clk_pll *pll = to_clk_pll(hw);
const struct samsung_pll_rate_table *rate;
u32 con0, con1;
- ktime_t start;
/* Get required rate settings from table */
rate = samsung_get_pll_settings(pll, drate);
@@ -489,20 +497,7 @@ static int samsung_pll45xx_set_rate(struct clk_hw *hw,
unsigned long drate,
writel_relaxed(con0, pll->con_reg);
/* Wait for locking. */
- start = ktime_get();
- while (!(readl_relaxed(pll->con_reg) & PLL45XX_LOCKED)) {
- ktime_t delta = ktime_sub(ktime_get(), start);
-
- if (ktime_to_ms(delta) > PLL_TIMEOUT_MS) {
- pr_err("%s: could not lock PLL %s\n",
- __func__, clk_hw_get_name(hw));
- return -EFAULT;
- }
-
- cpu_relax();
- }
-
- return 0;
+ return samsung_pll_lock_wait(pll, PLL45XX_LOCKED);
}
static const struct clk_ops samsung_pll45xx_clk_ops = {
@@ -588,7 +583,6 @@ static int samsung_pll46xx_set_rate(struct clk_hw *hw,
unsigned long drate,
struct samsung_clk_pll *pll = to_clk_pll(hw);
const struct
Re: [PATCH 1/1] x86/hyperv: Make hv_setup_sched_clock inline
Wei Liu writes: > On Mon, Aug 10, 2020 at 10:08:41PM +0200, Thomas Gleixner wrote: >> Michael Kelley writes: >> > Make hv_setup_sched_clock inline so the reference to pv_ops works >> > correctly with objtool updates to detect noinstr violations. >> > See https://lore.kernel.org/patchwork/patch/1283635/ >> > >> > Signed-off-by: Michael Kelley >> >> Acked-by: Thomas Gleixner > > Thomas and Peter, thank you for your acks. > > I have applied to hyperv-fixes and plan to submit it to Linus in a few > days' time. > > Thomas, let me know if you want this patch to go through the tip tree. I > will revert it from hyperv-fixes if that's the case. I acked it so you can pick it up :)
Re: [f2fs-dev] [PATCH] f2fs: change virtual mapping way for compression pages
Sure, I'll update the test condition as you said in the commit message. FYI, the test is done with 16kb chunk and Pixel 3 (arm64) device. Thanks, 2020년 8월 11일 (화) 오후 7:18, Gao Xiang 님이 작성: > > On Tue, Aug 11, 2020 at 06:33:26PM +0900, Daeho Jeong wrote: > > Plus, when we use vmap(), vmap() normally executes in a short time > > like vm_map_ram(). > > But, sometimes, it has a very long delay. > > > > 2020ë…„ 8ì›” 11ì�¼ (í™”) 오후 6:28, Daeho Jeong 님ì�´ > > 작성: > > > > > > Actually, as you can see, I use the whole zero data blocks in the test > > > file. > > > It can maximize the effect of changing virtual mapping. > > > When I use normal files which can be compressed about 70% from the > > > original file, > > > The vm_map_ram() version is about 2x faster than vmap() version. > > What f2fs does is much similar to btrfs compression. Even if these > blocks are all zeroed. In principle, the maximum compression ratio > is determined (cluster sized blocks into one compressed block, e.g > 16k cluster into one compressed block). > > So it'd be better to describe your configured cluster size (16k or > 128k) and your hardware information in the commit message as well. > > Actually, I also tried with this patch as well on my x86 laptop just > now with FIO (I didn't use zeroed block though), and I didn't notice > much difference with turbo boost off and maxfreq. > > I'm not arguing this commit, just a note about this commit message. > > > > >> 1048576000 bytes (0.9 G) copied, 9.146217 s, 109 M/s > > > > >> 1048576000 bytes (0.9 G) copied, 9.997542 s, 100 M/s > > > > >> 1048576000 bytes (0.9 G) copied, 10.109727 s, 99 M/s > > IMHO, the above number is much like decompressing in the arm64 little cores. > > Thanks, > Gao Xiang > > > > > > > > 2020ë…„ 8ì›” 11ì�¼ (í™”) 오후 4:55, Chao Yu 님ì�´ > > > 작성: > > > > > > > > On 2020/8/11 15:15, Gao Xiang wrote: > > > > > On Tue, Aug 11, 2020 at 12:37:53PM +0900, Daeho Jeong wrote: > > > > >> From: Daeho Jeong > > > > >> > > > > >> By profiling f2fs compression works, I've found vmap() callings are > > > > >> bottlenecks of f2fs decompression path. Changing these with > > > > >> vm_map_ram(), we can enhance f2fs decompression speed pretty much. > > > > >> > > > > >> [Verification] > > > > >> dd if=/dev/zero of=dummy bs=1m count=1000 > > > > >> echo 3 > /proc/sys/vm/drop_caches > > > > >> dd if=dummy of=/dev/zero bs=512k > > > > >> > > > > >> - w/o compression - > > > > >> 1048576000 bytes (0.9 G) copied, 1.999384 s, 500 M/s > > > > >> 1048576000 bytes (0.9 G) copied, 2.035988 s, 491 M/s > > > > >> 1048576000 bytes (0.9 G) copied, 2.039457 s, 490 M/s > > > > >> > > > > >> - before patch - > > > > >> 1048576000 bytes (0.9 G) copied, 9.146217 s, 109 M/s > > > > >> 1048576000 bytes (0.9 G) copied, 9.997542 s, 100 M/s > > > > >> 1048576000 bytes (0.9 G) copied, 10.109727 s, 99 M/s > > > > >> > > > > >> - after patch - > > > > >> 1048576000 bytes (0.9 G) copied, 2.253441 s, 444 M/s > > > > >> 1048576000 bytes (0.9 G) copied, 2.739764 s, 365 M/s > > > > >> 1048576000 bytes (0.9 G) copied, 2.185649 s, 458 M/s > > > > > > > > > > Indeed, vmap() approach has some impact on the whole > > > > > workflow. But I don't think the gap is such significant, > > > > > maybe it relates to unlocked cpufreq (and big little > > > > > core difference if it's on some arm64 board). > > > > > > > > Agreed, > > > > > > > > I guess there should be other reason causing the large performance > > > > gap, scheduling, frequency, or something else. > > > > > > > > > > > > > > > > > > > > > > > > ___ > > > > > Linux-f2fs-devel mailing list > > > > > linux-f2fs-de...@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > > > > . > > > > > > > >
Re: [PATCH RESEND] KVM: MIPS/VZ: Fix build error caused by 'kvm_run' cleanup
On 11/08/20 11:31, Xingxing Su wrote:
> Commit c34b26b98caca48ec9ee9 ("KVM: MIPS: clean up redundant 'kvm_run'
> parameters") remove the 'kvm_run' parameter in kvm_vz_gpsi_lwc2.
>
> The following build error:
>
> arch/mips/kvm/vz.c: In function ‘kvm_trap_vz_handle_gpsi’:
> arch/mips/kvm/vz.c:1243:43: error: ‘run’ undeclared (first use
> in this function)
>er = kvm_vz_gpsi_lwc2(inst, opc, cause, run, vcpu);
>^~~
> arch/mips/kvm/vz.c:1243:43: note: each undeclared identifier is reported only
> once for each function it appears in
> scripts/Makefile.build:283: recipe for target 'arch/mips/kvm/vz.o' failed
> make[2]: *** [arch/mips/kvm/vz.o] Error 1
> scripts/Makefile.build:500: recipe for target 'arch/mips/kvm' failed
> make[1]: *** [arch/mips/kvm] Error 2
> Makefile:1785: recipe for target 'arch/mips' failed
> make: *** [arch/mips] Error 2
>
> Signed-off-by: Xingxing Su
> ---
> +cc Paolo Bonzini and k...@vger.kernel.org.
>
> arch/mips/kvm/vz.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/mips/kvm/vz.c b/arch/mips/kvm/vz.c
> index 3932f76..49c6a2a 100644
> --- a/arch/mips/kvm/vz.c
> +++ b/arch/mips/kvm/vz.c
> @@ -1142,7 +1142,6 @@ static enum emulation_result kvm_vz_gpsi_cache(union
> mips_instruction inst,
> #ifdef CONFIG_CPU_LOONGSON64
> static enum emulation_result kvm_vz_gpsi_lwc2(union mips_instruction inst,
> u32 *opc, u32 cause,
> - struct kvm_run *run,
> struct kvm_vcpu *vcpu)
> {
> unsigned int rs, rd;
> @@ -1240,7 +1239,7 @@ static enum emulation_result
> kvm_trap_vz_handle_gpsi(u32 cause, u32 *opc,
> #endif
> #ifdef CONFIG_CPU_LOONGSON64
> case lwc2_op:
> - er = kvm_vz_gpsi_lwc2(inst, opc, cause, run, vcpu);
> + er = kvm_vz_gpsi_lwc2(inst, opc, cause, vcpu);
> break;
> #endif
> case spec3_op:
>
Queued, thanks.
Paolo
Re: btrfs crash in kobject_del while running xfstest
Somehow the copy-paste of Chris Mason's name failed (user error
on my end), sorry about that Chris!
On 8/11/20 4:17 AM, John Hubbard wrote:
Hi,
Here's an early warning of a possible problem.
I'm seeing a new btrfs crash when running xfstests, as of
00e4db51259a5f936fec1424b884f029479d3981 ("Merge tag
'perf-tools-2020-08-10' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux") in linux.git.
This doesn't crash in v5.8, so I attempted to bisect, but ended up with
the net-next merge commit as the offending one: commit
47ec5303d73ea344e84f46660fff693c57641386 ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next"), which
doesn't really help because it's 2088 files changed, of course.
I'm attaching the .config that I used.
This is easily reproducible via something like (change to match your setup,
of course):
sudo TEST_DEV=/dev/nvme0n1p8 TEST_DIR=/xfstest_btrfs \
SCRATCH_DEV=/dev/nvme0n1p9 SCRATCH_MNT=/xfstest_scratch ./check \
btrfs/002
which leads to:
[ 586.097360] BTRFS info (device nvme0n1p8): disk space caching is enabled
[ 586.103232] BTRFS info (device nvme0n1p8): has skinny extents
[ 586.115169] BTRFS info (device nvme0n1p8): enabling ssd optimizations
[ 586.308264] BTRFS: device fsid 5dfff89d-8f8d-42ac-8538-acb95164d0be devid 1 transid 5
/dev/nvme0n1p9 scanned by mkfs.btrfs (6374)
[ 586.342776] BTRFS info (device nvme0n1p9): disk space caching is enabled
[ 586.348585] BTRFS info (device nvme0n1p9): has skinny extents
[ 586.353413] BTRFS info (device nvme0n1p9): flagging fs with big metadata
feature
[ 586.368129] BTRFS info (device nvme0n1p9): enabling ssd optimizations
[ 586.373996] BTRFS info (device nvme0n1p9): checking UUID tree
[ 586.387449] BUG: kernel NULL pointer dereference, address: 0018
[ 586.393485] #PF: supervisor read access in kernel mode
[ 586.397623] #PF: error_code(0x) - not-present page
[ 586.401763] PGD 0 P4D 0
[ 586.403219] Oops: [#1] SMP PTI
[ 586.405650] CPU: 1 PID: 6405 Comm: umount Not tainted 5.8.0-hubbard-github+
#171
[ 586.412118] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./X99-UD3P-CF, BIOS
F1 02/10/2015
[ 586.421360] RIP: 0010:kobject_del+0x1/0x20
[ 586.424427] Code: 48 c7 43 18 00 00 00 00 5b 5d c3 c3 be 01 00 00 00 48 89 df e8 60 1b 00 00 eb
c9 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 55 <48> 8b 6f 18 e8 86 ff ff ff 48 89 ef 5d e9 cd fe ff
ff 66 66 2e 0f
[ 586.442644] RSP: 0018:c90009ef7e08 EFLAGS: 00010246
[ 586.446914] RAX: RBX: 9608 RCX: 0006
[ 586.453149] RDX: 8ee4b000 RSI: 82669a00 RDI:
[ 586.459390] RBP: R08: R09: 0001
[ 586.465631] R10: 0001 R11: R12: 9608
[ 586.471866] R13: R14: R15:
[ 586.478106] FS: 7f5595739c80() GS:9fc4()
knlGS:
[ 586.485325] CS: 0010 DS: ES: CR0: 80050033
[ 586.490129] CR2: 0018 CR3: 000896d5a006 CR4: 001706e0
[ 586.496372] Call Trace:
[ 586.497807] btrfs_sysfs_del_qgroups+0xa5/0xe0 [btrfs]
[ 586.502017] close_ctree+0x1c5/0x2b6 [btrfs]
[ 586.505307] ? fsnotify_destroy_marks+0x24/0x124
[ 586.508948] generic_shutdown_super+0x67/0x100
[ 586.512408] kill_anon_super+0x14/0x30
[ 586.515159] btrfs_kill_super+0x12/0x20 [btrfs]
[ 586.518704] deactivate_locked_super+0x36/0x90
[ 586.522159] cleanup_mnt+0x12d/0x190
[ 586.524720] task_work_run+0x5c/0xa0
[ 586.527285] exit_to_user_mode_loop+0xb9/0xc0
[ 586.530648] exit_to_user_mode_prepare+0xab/0xe0
[ 586.534276] syscall_exit_to_user_mode+0x17/0x50
[ 586.537908] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 586.541984] RIP: 0033:0x7f55959896fb
[ 586.544531] Code: 07 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 90 f3 0f 1e fa 31 f6 e9 05 00 00 00
0f 1f 44 00 00 f3 0f 1e fa b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 5d 07 0c 00 f7
d8 64 89 01 48
[ 586.562775] RSP: 002b:7fffcc431228 EFLAGS: 0246 ORIG_RAX:
00a6
[ 586.569485] RAX: RBX: 7f5595ab31e4 RCX: 7f55959896fb
[ 586.575753] RDX: RSI: RDI: 5601fb16bb80
[ 586.582020] RBP: 5601fb16b970 R08: R09: 7fffcc42ffa0
[ 586.588278] R10: 5601fb16c930 R11: 0246 R12: 5601fb16bb80
[ 586.594534] R13: R14: 5601fb16ba68 R15:
[ 586.600805] Modules linked in: xfs rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace
fscache bpfilter dm_mirror dm_region_hash dm_log dm_mod iTCO_wdt iTCO_vendor_support
x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul btrfs ghash_clmulni_intel aesni_intel
blake2b_generic crypto_simd xor cryptd zstd_compress glue_helper input_leds raid6_pq libcrc32c
lpc_ich i2c_i801 mfd_core mei_me
Re: [PATCH RFC v2] sched/fair: simplify the work when reweighting entity(Internet mail)
Hi, > On Aug 11, 2020, at 5:50 PM, Dietmar Eggemann > wrote: > > On 06/08/2020 18:14, Jiang Biao wrote: >> From: Jiang Biao >> >> If a se is on_rq when reweighting entity, all we need should be >> updating the load of cfs_rq, other dequeue/enqueue work could be >> redundant, such as, >> * nr_running--/nr_running++ >> >> Even though the following dequeue/enqueue path would never be reached >> * account_numa_dequeue/account_numa_enqueue >> * list_del/list_add from/into cfs_tasks >> but it could be a little confusing. >> >> Simplifying the logic could be helpful to reduce a litte overhead for >> hot path, and make it cleaner and more readable. > > LGTM. I guess you have to resend it w/o the RFC tag. Will do soon. > > Maybe you can rework the patch header a little? > > Something like this: > > The code in reweight_entity() can be simplified. > > For a sched entity on the rq, the entity accounting can be replaced by > cfs_rq instantaneous load updates currently called from within the > entity accounting. > > Even though an entity on the rq can't represent a task in > reweight_entity() (a task is always dequeued before calling this > function) and so the numa task accounting and the rq->cfs_tasks list > management of the entity accounting are never called, the redundant > cfs_rq->nr_running decrement/increment will be avoided. That’s a much better. I’ll pick the header if you don’t mind. :) Thanks a lot for your kindly reply and detailed explanation. Regards, Jiang > >> >> Signed-off-by: Jiang Biao >> --- >> v2<-v1: >> - Amend the commit log. >> >> kernel/sched/fair.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 04fa8dbcfa4d..18a8fc7bd0de 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -3086,7 +3086,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq, >> struct sched_entity *se, >> /* commit outstanding execution time */ >> if (cfs_rq->curr == se) >> update_curr(cfs_rq); >> -account_entity_dequeue(cfs_rq, se); >> +update_load_sub(_rq->load, se->load.weight); >> } >> dequeue_load_avg(cfs_rq, se); >> >> @@ -3102,7 +3102,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq, >> struct sched_entity *se, >> >> enqueue_load_avg(cfs_rq, se); >> if (se->on_rq) >> -account_entity_enqueue(cfs_rq, se); >> +update_load_add(_rq->load, se->load.weight); >> >> }
[PATCH] locking/rwsem: remove redundant semicolon of down_write_nest_lock
From: Guchun Chen
Otherwise, braces are needed when using it.
Signed-off-by: Guchun Chen
Reviewed-by: Christian König
---
include/linux/rwsem.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 7e5b2a4eb560..7a5bf5d50489 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -179,7 +179,7 @@ extern void _down_write_nest_lock(struct rw_semaphore *sem,
struct lockdep_map *
do { \
typecheck(struct lockdep_map *, &(nest_lock)->dep_map); \
_down_write_nest_lock(sem, &(nest_lock)->dep_map); \
-} while (0);
+} while (0)
/*
* Take/release a lock when not the owner will release it.
--
2.25.1
Re: lockdep splat ("possible circular locking dependency detected") with PL011 on 5.8
On Tue, Aug 11, 2020 at 12:38:41PM +0200, pet...@infradead.org wrote:
> On Tue, Aug 11, 2020 at 11:13:13AM +0100, Will Deacon wrote:
> > Using magic-sysrq via a keyboard interrupt over the serial console results
> > in
> > the following lockdep splat with the PL011 UART driver on v5.8. I can
> > reproduce
> > the issue under QEMU with arm64 defconfig + PROVE_LOCKING.
> >
> > Any chance somebody could take a look, please? It's a little annoying,
> > because it means when I uses magic-sysrq to increase the loglevel prior
> > to testing something else, lockdep gets disabled as a result.
> >
>
> Going by msm_serial, the thing to do is something like this:
>
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 8efd7c2a34fe..1717790ece2b 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -308,8 +308,9 @@ static void pl011_write(unsigned int val, const struct
> uart_amba_port *uap,
> */
> static int pl011_fifo_to_tty(struct uart_amba_port *uap)
> {
> - u16 status;
> unsigned int ch, flag, fifotaken;
> + int sysrq;
> + u16 status;
>
> for (fifotaken = 0; fifotaken != 256; fifotaken++) {
> status = pl011_read(uap, REG_FR);
> @@ -344,10 +345,12 @@ static int pl011_fifo_to_tty(struct uart_amba_port *uap)
> flag = TTY_FRAME;
> }
>
> - if (uart_handle_sysrq_char(>port, ch & 255))
> - continue;
> + spin_unlock(>port.lock);
> + sysrq = uart_handle_sysrq_char(>port, ch & 255);
> + spin_lock(>port.lock);
>
> - uart_insert_char(>port, ch, UART011_DR_OE, ch, flag);
> + if (!sysrq)
> + uart_insert_char(>port, ch, UART011_DR_OE, ch,
> flag);
> }
>
> return fifotaken;
Cheers, that seems to do the trick:
Tested-by: Will Deacon
but what I don't understand is why I haven't run into this before, and why
nobody else seems to be reporting it!
I'll try some older kernels to see if it ever worked.
Will
Re: [PATCH 1/2] ASoC: q6afe-dai: add dummy register read function
On 11/08/2020 12:04, Stephan Gerhold wrote:
On Tue, Aug 11, 2020 at 11:25:51AM +0100, Srinivas Kandagatla wrote:
Most of the DAPM widgets for DSP ASoC components reuse reg field
of the widgets for its internal calculations, however these are not
real registers. So read/writes to these numbers are not really
valid. However ASoC core will read these registers to get default
state during startup.
Actually q6afe-dai does not seem to make use of the register number.
The DAPM widgets all look like
SND_SOC_DAPM_AIF_IN("HDMI_RX", NULL, 0,0, 0, 0),
/* (wname,stname, wchan, wreg, wshift, winvert)
Wouldn't it be better to replace wreg = 0 with SND_SOC_NOPM in this case
so the read/write won't happen at all?
That should work, let me try that!
--srini
q6routing on the other hand does make use of wreg, so this would not
work there...
Also: If I remember correctly the ASoC core will also attempt to write
to these "registers" when starting to play some audio, so you might also
need to implement component->write().
Stephan
Re: [PATCH] net: untag pointer in sockptr_is_kernel
On Tue, Aug 11, 2020 at 06:27:04PM +0800, Miles Chen wrote: > From: Miles Chen > > sockptr_is_kernel() uses (sockptr.kernel >= TASK_SIZE) to tell > if the pointer is kernel space or user space. When user space uses > the "top byte ignored" feature such as HWAsan, we must untag > the pointer before checking against TASK_SIZE. > > sockptr_is_kernel() will view a tagged user pointer as a kernel pointer > and use memcpy directly and causes a kernel crash. Dave merged a patch from me to rever the optimized sockptr implementation for now. If we bring it back we should fold in your fix.
[Resend PATCH 1/6] mm/memcg: warning on !memcg after readahead page charged
Since readahead page is charged on memcg too, in theory we don't have to
check this exception now. Before safely remove them all, add a warning
for the unexpected !memcg.
Signed-off-by: Alex Shi
Acked-by: Michal Hocko
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Vladimir Davydov
Cc: Andrew Morton
Cc: cgro...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
include/linux/mmdebug.h | 13 +
mm/memcontrol.c | 15 ---
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h
index 2ad72d2c8cc5..4ed52879ce55 100644
--- a/include/linux/mmdebug.h
+++ b/include/linux/mmdebug.h
@@ -37,6 +37,18 @@
BUG(); \
} \
} while (0)
+#define VM_WARN_ON_ONCE_PAGE(cond, page) ({ \
+ static bool __section(.data.once) __warned; \
+ int __ret_warn_once = !!(cond); \
+ \
+ if (unlikely(__ret_warn_once && !__warned)) { \
+ dump_page(page, "VM_WARN_ON_ONCE_PAGE(" __stringify(cond)")");\
+ __warned = true;\
+ WARN_ON(1); \
+ } \
+ unlikely(__ret_warn_once); \
+})
+
#define VM_WARN_ON(cond) (void)WARN_ON(cond)
#define VM_WARN_ON_ONCE(cond) (void)WARN_ON_ONCE(cond)
#define VM_WARN_ONCE(cond, format...) (void)WARN_ONCE(cond, format)
@@ -48,6 +60,7 @@
#define VM_BUG_ON_MM(cond, mm) VM_BUG_ON(cond)
#define VM_WARN_ON(cond) BUILD_BUG_ON_INVALID(cond)
#define VM_WARN_ON_ONCE(cond) BUILD_BUG_ON_INVALID(cond)
+#define VM_WARN_ON_ONCE_PAGE(cond, page) BUILD_BUG_ON_INVALID(cond)
#define VM_WARN_ONCE(cond, format...) BUILD_BUG_ON_INVALID(cond)
#define VM_WARN(cond, format...) BUILD_BUG_ON_INVALID(cond)
#endif
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 130093bdf74b..299382fc55a9 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1322,10 +1322,8 @@ struct lruvec *mem_cgroup_page_lruvec(struct page *page,
struct pglist_data *pgd
}
memcg = page->mem_cgroup;
- /*
-* Swapcache readahead pages are added to the LRU - and
-* possibly migrated - before they are charged.
-*/
+ /* Readahead page is charged too, to see if other page uncharged */
+ VM_WARN_ON_ONCE_PAGE(!memcg, page);
if (!memcg)
memcg = root_mem_cgroup;
@@ -6906,8 +6904,9 @@ void mem_cgroup_migrate(struct page *oldpage, struct page
*newpage)
if (newpage->mem_cgroup)
return;
- /* Swapcache readahead pages can get replaced before being charged */
memcg = oldpage->mem_cgroup;
+ /* Readahead page is charged too, to see if other page uncharged */
+ VM_WARN_ON_ONCE_PAGE(!memcg, oldpage);
if (!memcg)
return;
@@ -7104,7 +7103,8 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t
entry)
memcg = page->mem_cgroup;
- /* Readahead page, never charged */
+ /* Readahead page is charged too, to see if other page uncharged */
+ VM_WARN_ON_ONCE_PAGE(!memcg, page);
if (!memcg)
return;
@@ -7168,7 +7168,8 @@ int mem_cgroup_try_charge_swap(struct page *page,
swp_entry_t entry)
memcg = page->mem_cgroup;
- /* Readahead page, never charged */
+ /* Readahead page is charged too, to see if other page uncharged */
+ VM_WARN_ON_ONCE_PAGE(!memcg, page);
if (!memcg)
return 0;
--
1.8.3.1
[Resend PATCH 3/6] mm/thp: move lru_add_page_tail func to huge_memory.c
The func is only used in huge_memory.c, defining it in other file with a
CONFIG_TRANSPARENT_HUGEPAGE macro restrict just looks weird.
Let's move it THP. And make it static as Hugh Dickin suggested.
Signed-off-by: Alex Shi
Reviewed-by: Kirill A. Shutemov
Cc: Andrew Morton
Cc: Johannes Weiner
Cc: Matthew Wilcox
Cc: Hugh Dickins
Cc: linux-kernel@vger.kernel.org
Cc: linux...@kvack.org
---
include/linux/swap.h | 2 --
mm/huge_memory.c | 30 ++
mm/swap.c| 33 -
3 files changed, 30 insertions(+), 35 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 661046994db4..43e6b3458f58 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -338,8 +338,6 @@ extern void lru_note_cost(struct lruvec *lruvec, bool file,
unsigned int nr_pages);
extern void lru_note_cost_page(struct page *);
extern void lru_cache_add(struct page *);
-extern void lru_add_page_tail(struct page *page, struct page *page_tail,
-struct lruvec *lruvec, struct list_head *head);
extern void activate_page(struct page *);
extern void mark_page_accessed(struct page *);
extern void lru_add_drain(void);
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 90733cefa528..bc905e7079bf 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2315,6 +2315,36 @@ static void remap_page(struct page *page)
}
}
+static void lru_add_page_tail(struct page *page, struct page *page_tail,
+ struct lruvec *lruvec, struct list_head *list)
+{
+ VM_BUG_ON_PAGE(!PageHead(page), page);
+ VM_BUG_ON_PAGE(PageCompound(page_tail), page);
+ VM_BUG_ON_PAGE(PageLRU(page_tail), page);
+ lockdep_assert_held(_pgdat(lruvec)->lru_lock);
+
+ if (!list)
+ SetPageLRU(page_tail);
+
+ if (likely(PageLRU(page)))
+ list_add_tail(_tail->lru, >lru);
+ else if (list) {
+ /* page reclaim is reclaiming a huge page */
+ get_page(page_tail);
+ list_add_tail(_tail->lru, list);
+ } else {
+ /*
+* Head page has not yet been counted, as an hpage,
+* so we must account for each subpage individually.
+*
+* Put page_tail on the list at the correct position
+* so they all end up in order.
+*/
+ add_page_to_lru_list_tail(page_tail, lruvec,
+ page_lru(page_tail));
+ }
+}
+
static void __split_huge_page_tail(struct page *head, int tail,
struct lruvec *lruvec, struct list_head *list)
{
diff --git a/mm/swap.c b/mm/swap.c
index d16d65d9b4e0..c674fb441fe9 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -935,39 +935,6 @@ void __pagevec_release(struct pagevec *pvec)
}
EXPORT_SYMBOL(__pagevec_release);
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-/* used by __split_huge_page_refcount() */
-void lru_add_page_tail(struct page *page, struct page *page_tail,
- struct lruvec *lruvec, struct list_head *list)
-{
- VM_BUG_ON_PAGE(!PageHead(page), page);
- VM_BUG_ON_PAGE(PageCompound(page_tail), page);
- VM_BUG_ON_PAGE(PageLRU(page_tail), page);
- lockdep_assert_held(_pgdat(lruvec)->lru_lock);
-
- if (!list)
- SetPageLRU(page_tail);
-
- if (likely(PageLRU(page)))
- list_add_tail(_tail->lru, >lru);
- else if (list) {
- /* page reclaim is reclaiming a huge page */
- get_page(page_tail);
- list_add_tail(_tail->lru, list);
- } else {
- /*
-* Head page has not yet been counted, as an hpage,
-* so we must account for each subpage individually.
-*
-* Put page_tail on the list at the correct position
-* so they all end up in order.
-*/
- add_page_to_lru_list_tail(page_tail, lruvec,
- page_lru(page_tail));
- }
-}
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
-
static void __pagevec_lru_add_fn(struct page *page, struct lruvec *lruvec,
void *arg)
{
--
1.8.3.1
[Resend PATCH 4/6] mm/thp: clean up lru_add_page_tail
Since the first parameter is only used by head page, it's better to make
it explicit.
Signed-off-by: Alex Shi
Reviewed-by: Kirill A. Shutemov
Cc: Andrew Morton
Cc: Johannes Weiner
Cc: Matthew Wilcox
Cc: Hugh Dickins
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
mm/huge_memory.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index bc905e7079bf..8cecd39bd8b7 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2315,19 +2315,19 @@ static void remap_page(struct page *page)
}
}
-static void lru_add_page_tail(struct page *page, struct page *page_tail,
+static void lru_add_page_tail(struct page *head, struct page *page_tail,
struct lruvec *lruvec, struct list_head *list)
{
- VM_BUG_ON_PAGE(!PageHead(page), page);
- VM_BUG_ON_PAGE(PageCompound(page_tail), page);
- VM_BUG_ON_PAGE(PageLRU(page_tail), page);
+ VM_BUG_ON_PAGE(!PageHead(head), head);
+ VM_BUG_ON_PAGE(PageCompound(page_tail), head);
+ VM_BUG_ON_PAGE(PageLRU(page_tail), head);
lockdep_assert_held(_pgdat(lruvec)->lru_lock);
if (!list)
SetPageLRU(page_tail);
- if (likely(PageLRU(page)))
- list_add_tail(_tail->lru, >lru);
+ if (likely(PageLRU(head)))
+ list_add_tail(_tail->lru, >lru);
else if (list) {
/* page reclaim is reclaiming a huge page */
get_page(page_tail);
--
1.8.3.1
[Resend PATCH 5/6] mm/thp: remove code path which never got into
split_huge_page() will never call on a page which isn't on lru list, so
this code never got a chance to run, and should not be run, to add tail
pages on a lru list which head page isn't there.
Although the bug was never triggered, it'better be removed for code
correctness, and add a warn for unexpected calling.
Signed-off-by: Alex Shi
Reviewed-by: Kirill A. Shutemov
Cc: Kirill A. Shutemov
Cc: Andrew Morton
Cc: Johannes Weiner
Cc: Matthew Wilcox
Cc: Hugh Dickins
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
mm/huge_memory.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 8cecd39bd8b7..d55e3006c63f 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2332,17 +2332,8 @@ static void lru_add_page_tail(struct page *head, struct
page *page_tail,
/* page reclaim is reclaiming a huge page */
get_page(page_tail);
list_add_tail(_tail->lru, list);
- } else {
- /*
-* Head page has not yet been counted, as an hpage,
-* so we must account for each subpage individually.
-*
-* Put page_tail on the list at the correct position
-* so they all end up in order.
-*/
- add_page_to_lru_list_tail(page_tail, lruvec,
- page_lru(page_tail));
- }
+ } else
+ VM_WARN_ON(!PageLRU(head));
}
static void __split_huge_page_tail(struct page *head, int tail,
--
1.8.3.1
[Resend PATCH 2/6] mm/memcg: remove useless check on page->mem_cgroup
If we disabled memcg by cgroup_disable=memory, the swap charges are still called. Let's return from the funcs earlier and keep WARN_ON monitor. Signed-off-by: Alex Shi Reviewed-by: Roman Gushchin Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Andrew Morton Cc: cgro...@vger.kernel.org Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org --- mm/memcontrol.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 299382fc55a9..419cf565f40b 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -7098,6 +7098,9 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t entry) VM_BUG_ON_PAGE(PageLRU(page), page); VM_BUG_ON_PAGE(page_count(page), page); + if (mem_cgroup_disabled()) + return; + if (cgroup_subsys_on_dfl(memory_cgrp_subsys)) return; @@ -7163,6 +7166,9 @@ int mem_cgroup_try_charge_swap(struct page *page, swp_entry_t entry) struct mem_cgroup *memcg; unsigned short oldid; + if (mem_cgroup_disabled()) + return 0; + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) return 0; -- 1.8.3.1
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
On Tue, Aug 11, 2020 at 12:21:24PM +0200, Michal Hocko wrote: > On Tue 11-08-20 11:18:07, Uladzislau Rezki wrote: > > On Mon, Aug 10, 2020 at 09:25:25PM +0200, Michal Hocko wrote: > > > On Mon 10-08-20 18:07:39, Uladzislau Rezki wrote: > > > > > On Sun 09-08-20 22:43:53, Uladzislau Rezki (Sony) wrote: > [...] > > > > As i described before, calling the __get_free_page(0) with 0 as argument > > > > will solve the (a). How correctly is it? From my point of view the logic > > > > that bypass the wakeup path should be explicitly defined. > > > > > > gfp_mask == 0 is GFP_NOWAIT (aka an atomic allocation request) which > > > doesn't wake up kswapd. So if the wakeup is a problem then this would be > > > a way to go. > > > > > What do you mean Michal? gfp_mask 0 != GFP_NOWAIT: > > > > #define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM) > > > > it does wakeup of the kswapd. Or am i missing something? Please comment. > > If we are about to avoid the kswapd, should we define something special? > > > > #define GFP_NOWWAKE_KSWAPD 0 > > Sorry, I was more cryptic than necessary. What I meant is that > GFP_NOWAIT is the basic non-sleepable allocation. It does wake up > kswapd but a lack of it can be expressed GFP_NOWAIT & ~__GFP_KSWAPD_RECLAIM > which is 0, now. The mouthfull variant is better for future > maintainability. > OK. I got it anyway. Just decided to clarify. -- Vlad Rezki
[Resend PATCH 6/6] mm/thp: narrow lru locking
lru_lock and page cache xa_lock have no reason with current sequence,
put them together isn't necessary. let's narrow the lru locking, but
left the local_irq_disable to block interrupt re-entry and statistic update.
Hugh Dickins point: split_huge_page_to_list() was already silly,to be
using the _irqsave variant: it's just been taking sleeping locks, so
would already be broken if entered with interrupts enabled.
so we can save passing flags argument down to __split_huge_page().
Signed-off-by: Alex Shi
Signed-off-by: Wei Yang
Reviewed-by: Kirill A. Shutemov
Cc: Hugh Dickins
Cc: Kirill A. Shutemov
Cc: Andrea Arcangeli
Cc: Johannes Weiner
Cc: Matthew Wilcox
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
mm/huge_memory.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index d55e3006c63f..e9c31d91da8c 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2399,7 +2399,7 @@ static void __split_huge_page_tail(struct page *head, int
tail,
}
static void __split_huge_page(struct page *page, struct list_head *list,
- pgoff_t end, unsigned long flags)
+ pgoff_t end)
{
struct page *head = compound_head(page);
pg_data_t *pgdat = page_pgdat(head);
@@ -2408,8 +2408,6 @@ static void __split_huge_page(struct page *page, struct
list_head *list,
unsigned long offset = 0;
int i;
- lruvec = mem_cgroup_page_lruvec(head, pgdat);
-
/* complete memcg works before add pages to LRU */
mem_cgroup_split_huge_fixup(head);
@@ -2421,6 +2419,11 @@ static void __split_huge_page(struct page *page, struct
list_head *list,
xa_lock(_cache->i_pages);
}
+ /* prevent PageLRU to go away from under us, and freeze lru stats */
+ spin_lock(>lru_lock);
+
+ lruvec = mem_cgroup_page_lruvec(head, pgdat);
+
for (i = HPAGE_PMD_NR - 1; i >= 1; i--) {
__split_huge_page_tail(head, i, lruvec, list);
/* Some pages can be beyond i_size: drop them from page cache */
@@ -2440,6 +2443,8 @@ static void __split_huge_page(struct page *page, struct
list_head *list,
}
ClearPageCompound(head);
+ spin_unlock(>lru_lock);
+ /* Caller disabled irqs, so they are still disabled here */
split_page_owner(head, HPAGE_PMD_ORDER);
@@ -2457,8 +2462,7 @@ static void __split_huge_page(struct page *page, struct
list_head *list,
page_ref_add(head, 2);
xa_unlock(>mapping->i_pages);
}
-
- spin_unlock_irqrestore(>lru_lock, flags);
+ local_irq_enable();
remap_page(head);
@@ -2597,12 +2601,10 @@ bool can_split_huge_page(struct page *page, int
*pextra_pins)
int split_huge_page_to_list(struct page *page, struct list_head *list)
{
struct page *head = compound_head(page);
- struct pglist_data *pgdata = NODE_DATA(page_to_nid(head));
struct deferred_split *ds_queue = get_deferred_split_queue(head);
struct anon_vma *anon_vma = NULL;
struct address_space *mapping = NULL;
int count, mapcount, extra_pins, ret;
- unsigned long flags;
pgoff_t end;
VM_BUG_ON_PAGE(is_huge_zero_page(head), head);
@@ -2663,9 +2665,8 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
unmap_page(head);
VM_BUG_ON_PAGE(compound_mapcount(head), head);
- /* prevent PageLRU to go away from under us, and freeze lru stats */
- spin_lock_irqsave(>lru_lock, flags);
-
+ /* block interrupt reentry in xa_lock and spinlock */
+ local_irq_disable();
if (mapping) {
XA_STATE(xas, >i_pages, page_index(head));
@@ -2695,7 +2696,7 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
__dec_node_page_state(head, NR_FILE_THPS);
}
- __split_huge_page(page, list, end, flags);
+ __split_huge_page(page, list, end);
if (PageSwapCache(head)) {
swp_entry_t entry = { .val = page_private(head) };
@@ -2714,7 +2715,7 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
spin_unlock(_queue->split_queue_lock);
fail: if (mapping)
xa_unlock(>i_pages);
- spin_unlock_irqrestore(>lru_lock, flags);
+ local_irq_enable();
remap_page(head);
ret = -EBUSY;
}
--
1.8.3.1
Re: [PATCH 1/2] ASoC: q6afe-dai: add dummy register read function
On Tue, Aug 11, 2020 at 11:25:51AM +0100, Srinivas Kandagatla wrote:
> Most of the DAPM widgets for DSP ASoC components reuse reg field
> of the widgets for its internal calculations, however these are not
> real registers. So read/writes to these numbers are not really
> valid. However ASoC core will read these registers to get default
> state during startup.
>
Actually q6afe-dai does not seem to make use of the register number.
The DAPM widgets all look like
SND_SOC_DAPM_AIF_IN("HDMI_RX", NULL, 0,0, 0, 0),
/* (wname,stname, wchan, wreg, wshift, winvert)
Wouldn't it be better to replace wreg = 0 with SND_SOC_NOPM in this case
so the read/write won't happen at all?
q6routing on the other hand does make use of wreg, so this would not
work there...
Also: If I remember correctly the ASoC core will also attempt to write
to these "registers" when starting to play some audio, so you might also
need to implement component->write().
Stephan
Re: [RFC] libperf: Add support for user space counter access
On Tue, Aug 11, 2020 at 12:50:27PM +0200, Jiri Olsa wrote: > if it works for all events, which I'm not sure of That's what we have cap_user_rdpmc for.
Re: [RFC PATCH] sched/numa: fix bug in update_task_scan_period
On Tue, Aug 11, 2020 at 04:30:31PM +0800, ? wrote: > When p->numa_faults_locality[2] > 0, numa_scan_period is doubled, but > this array will never be cleared, which causes scanning period always > reaching its max value. This patch clears numa_faults_locality after > numa_scan_period being doubled to fix this bug. > An out label at the end of the function to clears numa_faults_locality would also work with a comment explaining why. That aside, what is the user-visible impact of the patch? If there are no useful faults or migration failures, it makes sense that scanning is very slow until the situation changes. The corner case is that a migration failure might keep the scan rate slower than it should be but the flip side is that fixing it might increase the scan rate and still incur migration failures which introduces overhead with no gain. -- Mel Gorman SUSE Labs
[PATCH] ASoC: qcom: add a dedicated menuconfig
Currently list of Qualcomm drivers is growing, so put them in to a proper menu so that it does not mix up with other ASOC configs in menuconfig. Signed-off-by: Srinivas Kandagatla --- sound/soc/qcom/Kconfig | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig index 5d6b2466a2f2..be6b8d0e2f70 100644 --- a/sound/soc/qcom/Kconfig +++ b/sound/soc/qcom/Kconfig @@ -1,11 +1,13 @@ # SPDX-License-Identifier: GPL-2.0-only -config SND_SOC_QCOM +menuconfig SND_SOC_QCOM tristate "ASoC support for QCOM platforms" depends on ARCH_QCOM || COMPILE_TEST help Say Y or M if you want to add support to use audio devices in Qualcomm Technologies SOC-based platforms. +if SND_SOC_QCOM + config SND_SOC_LPASS_CPU tristate select REGMAP_MMIO @@ -26,7 +28,6 @@ config SND_SOC_LPASS_APQ8016 config SND_SOC_STORM tristate "ASoC I2S support for Storm boards" - depends on SND_SOC_QCOM select SND_SOC_LPASS_IPQ806X select SND_SOC_MAX98357A help @@ -35,7 +36,6 @@ config SND_SOC_STORM config SND_SOC_APQ8016_SBC tristate "SoC Audio support for APQ8016 SBC platforms" - depends on SND_SOC_QCOM select SND_SOC_LPASS_APQ8016 select SND_SOC_QCOM_COMMON help @@ -110,3 +110,5 @@ config SND_SOC_SDM845 To add support for audio on Qualcomm Technologies Inc. SDM845 SoC-based systems. Say Y if you want to use audio device on this SoCs. + +endif #SND_SOC_QCOM -- 2.21.0
Re: [PATCH 1/1] x86/hyperv: Make hv_setup_sched_clock inline
On Mon, Aug 10, 2020 at 10:08:41PM +0200, Thomas Gleixner wrote: > Michael Kelley writes: > > Make hv_setup_sched_clock inline so the reference to pv_ops works > > correctly with objtool updates to detect noinstr violations. > > See https://lore.kernel.org/patchwork/patch/1283635/ > > > > Signed-off-by: Michael Kelley > > Acked-by: Thomas Gleixner Thomas and Peter, thank you for your acks. I have applied to hyperv-fixes and plan to submit it to Linus in a few days' time. Thomas, let me know if you want this patch to go through the tip tree. I will revert it from hyperv-fixes if that's the case. Wei.
Re: [PATCH 5.8 00/38] 5.8.1-rc1 review
On Mon, Aug 10, 2020 at 8:53 PM Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.8.1 release. > There are 38 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 12 Aug 2020 15:17:47 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.1-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.8.y > and the diffstat can be found below. > > thanks, > > greg k-h > Successfully booted on my Asus machine running x86_64 No kernel regressions found. -- Thanks and Regards Yours Truly, Puranjay Mohan
Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver
Hi!
> +/* LP5009 and LP5012 registers */
> +#define LP5012_BNK_BRT 0x03
> +#define LP5012_BNKA_CLR 0x04
> +#define LP5012_BNKB_CLR 0x05
> +#define LP5012_BNKC_CLR 0x06
> +#define LP5012_LED0_BRT 0x07
> +#define LP5012_LED1_BRT 0x08
> +#define LP5012_LED2_BRT 0x09
> +#define LP5012_LED3_BRT 0x0a
> +#define LP5012_OUT0_CLR 0x0b
> +#define LP5012_OUT1_CLR 0x0c
> +#define LP5012_OUT2_CLR 0x0d
> +#define LP5012_OUT3_CLR 0x0e
> +#define LP5012_OUT4_CLR 0x0f
> +#define LP5012_OUT5_CLR 0x10
> +#define LP5012_OUT6_CLR 0x11
> +#define LP5012_OUT7_CLR 0x12
> +#define LP5012_OUT8_CLR 0x13
> +#define LP5012_OUT9_CLR 0x14
> +#define LP5012_OUT10_CLR 0x15
> +#define LP5012_OUT11_CLR 0x16
> +#define LP5012_RESET 0x17
> +
> +/* LP5018 and LP5024 registers */
> +#define LP5024_BNK_BRT 0x03
> +#define LP5024_BNKA_CLR 0x04
> +#define LP5024_BNKB_CLR 0x05
> +#define LP5024_BNKC_CLR 0x06
> +#define LP5024_LED0_BRT 0x07
> +#define LP5024_LED1_BRT 0x08
> +#define LP5024_LED2_BRT 0x09
> +#define LP5024_LED3_BRT 0x0a
> +#define LP5024_LED4_BRT 0x0b
> +#define LP5024_LED5_BRT 0x0c
> +#define LP5024_LED6_BRT 0x0d
> +#define LP5024_LED7_BRT 0x0e
> +
> +#define LP5024_OUT0_CLR 0x0f
> +#define LP5024_OUT1_CLR 0x10
> +#define LP5024_OUT2_CLR 0x11
> +#define LP5024_OUT3_CLR 0x12
> +#define LP5024_OUT4_CLR 0x13
> +#define LP5024_OUT5_CLR 0x14
> +#define LP5024_OUT6_CLR 0x15
> +#define LP5024_OUT7_CLR 0x16
> +#define LP5024_OUT8_CLR 0x17
> +#define LP5024_OUT9_CLR 0x18
> +#define LP5024_OUT10_CLR 0x19
> +#define LP5024_OUT11_CLR 0x1a
> +#define LP5024_OUT12_CLR 0x1b
> +#define LP5024_OUT13_CLR 0x1c
> +#define LP5024_OUT14_CLR 0x1d
> +#define LP5024_OUT15_CLR 0x1e
> +#define LP5024_OUT16_CLR 0x1f
> +#define LP5024_OUT17_CLR 0x20
> +#define LP5024_OUT18_CLR 0x21
> +#define LP5024_OUT19_CLR 0x22
> +#define LP5024_OUT20_CLR 0x23
> +#define LP5024_OUT21_CLR 0x24
> +#define LP5024_OUT22_CLR 0x25
> +#define LP5024_OUT23_CLR 0x26
> +#define LP5024_RESET 0x27
> +
> +/* LP5030 and LP5036 registers */
> +#define LP5036_LED_CFG1 0x03
> +#define LP5036_BNK_BRT 0x04
> +#define LP5036_BNKA_CLR 0x05
> +#define LP5036_BNKB_CLR 0x06
> +#define LP5036_BNKC_CLR 0x07
> +#define LP5036_LED0_BRT 0x08
> +#define LP5036_LED1_BRT 0x09
> +#define LP5036_LED2_BRT 0x0a
> +#define LP5036_LED3_BRT 0x0b
> +#define LP5036_LED4_BRT 0x0c
> +#define LP5036_LED5_BRT 0x0d
> +#define LP5036_LED6_BRT 0x0e
> +#define LP5036_LED7_BRT 0x0f
> +#define LP5036_LED8_BRT 0x10
> +#define LP5036_LED9_BRT 0x11
> +#define LP5036_LED10_BRT 0x12
> +#define LP5036_LED11_BRT 0x13
> +
> +#define LP5036_OUT0_CLR 0x14
> +#define LP5036_OUT1_CLR 0x15
> +#define LP5036_OUT2_CLR 0x16
> +#define LP5036_OUT3_CLR 0x17
> +#define LP5036_OUT4_CLR 0x18
> +#define LP5036_OUT5_CLR 0x19
> +#define LP5036_OUT6_CLR 0x1a
> +#define LP5036_OUT7_CLR 0x1b
> +#define LP5036_OUT8_CLR 0x1c
> +#define LP5036_OUT9_CLR 0x1d
> +#define LP5036_OUT10_CLR 0x1e
> +#define LP5036_OUT11_CLR 0x1f
> +#define LP5036_OUT12_CLR 0x20
> +#define LP5036_OUT13_CLR 0x21
> +#define LP5036_OUT14_CLR 0x22
> +#define LP5036_OUT15_CLR 0x23
> +#define LP5036_OUT16_CLR 0x24
> +#define LP5036_OUT17_CLR 0x25
> +#define LP5036_OUT18_CLR 0x26
> +#define LP5036_OUT19_CLR 0x27
> +#define LP5036_OUT20_CLR 0x28
> +#define LP5036_OUT21_CLR 0x29
> +#define LP5036_OUT22_CLR 0x2a
> +#define LP5036_OUT23_CLR 0x2b
> +#define LP5036_OUT24_CLR 0x2c
> +#define LP5036_OUT25_CLR 0x2d
> +#define LP5036_OUT26_CLR 0x2e
> +#define LP5036_OUT27_CLR 0x2f
> +#define LP5036_OUT28_CLR 0x30
> +#define LP5036_OUT29_CLR 0x31
> +#define LP5036_OUT30_CLR 0x32
> +#define LP5036_OUT31_CLR 0x33
> +#define LP5036_OUT32_CLR 0x34
> +#define LP5036_OUT33_CLR 0x35
> +#define LP5036_OUT34_CLR 0x36
> +#define LP5036_OUT35_CLR 0x37
> +#define LP5036_RESET 0x38
> +static const struct reg_default lp5012_reg_defs[] = {
...
> + {LP5012_OUT1_CLR, 0x00},
> + {LP5012_OUT2_CLR, 0x00},
> + {LP5012_OUT3_CLR, 0x00},
> + {LP5012_OUT4_CLR, 0x00},
> +
Re: [PATCH v2 2/2] init/Kconfig: Increase default log buffer size from 128 KB to 512 KB
On Tue 2020-08-11 11:29:24, Paul Menzel wrote: > Commit f17a32e97e (let LOG_BUF_SHIFT default to 17) from 2008 was the > last time, the the default log buffer size bump was increased. > > Machines have evolved, and on current hardware, enough memory is > present, and some devices have over 200 PCI devices, like a two socket > Skylake-E server, resulting a lot of lines. > > Therefore, increase the default from 128 KB to 512 KB. Anyone, with > limited memory, can still lower it. > > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -681,9 +681,9 @@ config IKHEADERS > kheaders.ko is built which can be loaded on-demand to get access to > headers. > > config LOG_BUF_SHIFT > - int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" > + int "Kernel log buffer size (17 => 128KB, 19 => 512KB)" > range 12 25 > - default 17 > + default 19 > depends on PRINTK > help > Select the minimal kernel log buffer size as a power of 2. Honestly, I do not have experience with changing the defaults. People hacking small devices might complain. Well, this can be solved by increasing the default only when BASE_FULL is set. I am personally fine with increasing the default when BASE_FULL is set. The amount of messages is growing over time because of increasing complexity of both the hardware and software. Fortunately also the amount of available memory is growing. Well, this should get discussed in wider audience. Adding some people into CC. JFYI, it started with report of lost messages, see https://lore.kernel.org/lkml/264bfbae-122d-9c41-59ea-6413f91bd...@molgen.mpg.de/ Best Regards, Petr
Re: [RFC] libperf: Add support for user space counter access
On Mon, Aug 10, 2020 at 12:11:23PM -0600, Rob Herring wrote: > On Sat, Aug 8, 2020 at 4:22 AM Jiri Olsa wrote: > > > > On Fri, Aug 07, 2020 at 05:05:17PM -0600, Rob Herring wrote: > > > x86 and arm64 can both support direct access of event counters in > > > userspace. The access sequence is less than trivial and currently exists > > > in perf test code (tools/perf/arch/x86/tests/rdpmc.c) with copies in > > > projects such as PAPI and libpfm4. > > > > > > Patches to add arm64 userspace support are pending[1]. > > > > > > For this RFC, looking for a yes, seems like a good idea, or no, go away we > > > don't want this in libperf. > > > > hi, > > looks great! > > > > I wanted to add this for very long time.. so yes, we want this ;-) > > Thanks for the quick feedback. Would this be better implemented as a > fast path for perf_evsel__read()? If so, how to get the mmap data if it works for all events, which I'm not sure of > which is associated with a evlist rather than a evsel? not sure what you mean, you can mmap evsel, not evlist jirka
Re: [PATCH V2] serial: qcom_geni_serial: To correct QUP Version detection logic
Hi, Paras Sharma writes: > The current implementation reduces the sampling rate by half > if qup HW version greater is than 2.5 by checking if the geni ^^^ is greater than could, possibly, be fixed while applying. > SE major version is greater than 2 and geni SE minor version > is greater than 5. > > This implementation fails when the version is 3 or greater. > > Hence by adding the another check for geni SE major version, > this problem can be solved. > > Signed-off-by: Paras Sharma > --- > drivers/tty/serial/qcom_geni_serial.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/qcom_geni_serial.c > b/drivers/tty/serial/qcom_geni_serial.c > index 3aa29d2..a9f92d8 100644 > --- a/drivers/tty/serial/qcom_geni_serial.c > +++ b/drivers/tty/serial/qcom_geni_serial.c > @@ -995,7 +995,8 @@ static void qcom_geni_serial_set_termios(struct uart_port > *uport, > sampling_rate = UART_OVERSAMPLING; > /* Sampling rate is halved for IP versions >= 2.5 */ > ver = geni_se_get_qup_hw_version(>se); > - if (GENI_SE_VERSION_MAJOR(ver) >= 2 && GENI_SE_VERSION_MINOR(ver) >= 5) > + if ((GENI_SE_VERSION_MAJOR(ver) >= 2 && GENI_SE_VERSION_MINOR(ver) >= 5) > + || GENI_SE_VERSION_MAJOR(ver) >= 3) it looks like having a single GENI_SE_VERSION() that returns MAJOR and MINOR without STEP would look better here. Then you could use: if (GENI_SE_VERSION(ver) >= 0x2005) and it would work for any future version. Not a strong opinion, though -- balbi signature.asc Description: PGP signature
Re: [PATCH net] drivers/net/wan/x25_asy: Added needed_headroom and a skb->len check
> > > 2) The code quality of this driver is actually very low, and I also > > > hope to improve it gradually. Actually this driver had been completely > > > broken for many years and no one had noticed this until I fixed it in > > > commit 8fdcabeac398 (drivers/net/wan/x25_asy: Fix to make it work) > > > last month. > > > > Just curious: how come that netif_rx could be removed? > > When receiving data, the driver should only submit skb to upper layers > after it has been processed by the lapb module, i.e., it should only > call netif_rx in the function x25_asy_data_indication. The removed > netif_rx is in the function x25_asy_bump. This function is responsible > for passing the skb to the lapb module to process. It doesn't make > sense to call netif_rx here. If we call netif_rx here, we may pass > control frames that shouldn't be passed to upper layers (and have been > consumed and freed by the lapb module) to upper layers. Ah of course. Thanks for explaining. > > One thing to keep in mind is that AF_PACKET sockets are not the normal > > datapath. AF_X25 sockets are. But you mention that you also exercise > > the upper layer? That gives confidence that these changes are not > > accidentally introducing regressions for the default path while fixing > > oddly crafted packets with (root only for a reason) packet sockets. > > Yes, I test with AF_X25 sockets too to make sure the changes are OK. > I usually test AF_X25 sockets with: > https://github.com/hyanggi/testing_linux/blob/master/network_x25/x25/server.c > https://github.com/hyanggi/testing_linux/blob/master/network_x25/x25/client.c Excellent. Thanks for the link. Good to know that these changes are getting real code coverage. > I became interested in X.25 when I was trying different address > families that Linux supported. I tried AF_X25 sockets. And then I > tried to use the X.25 link layer directly through AF_PACKET. I believe > both AF_X25 sockets and AF_PACKET sockets need to work without > problems with X.25 drivers - lapbether and x25_asy. There is another > X.25 driver (hdlc_x25) in the kernel. I haven't been able to run that > driver. But that driver seems to be the real driver which is really > used, and I know Martin Schiller is an active user and > developer of that driver. Great, sounds like we might have additional LAPB and X25 maintainers soon? :) MAINTAINERS lists Andrew Hendry as maintainer for X.25. Please do CC them.
Re: [PATCH 2/2] KVM: arm64: Only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is not set
On 08/11/2020 11:27 AM, Will Deacon wrote:
When an MMU notifier call results in unmapping a range that spans multiple
PGDs, we end up calling into cond_resched_lock() when crossing a PGD boundary,
since this avoids running into RCU stalls during VM teardown. Unfortunately,
if the VM is destroyed as a result of OOM, then blocking is not permitted
and the call to the scheduler triggers the following BUG():
| BUG: sleeping function called from invalid context at
arch/arm64/kvm/mmu.c:394
| in_atomic(): 1, irqs_disabled(): 0, non_block: 1, pid: 36, name: oom_reaper
| INFO: lockdep is turned off.
| CPU: 3 PID: 36 Comm: oom_reaper Not tainted 5.8.0 #1
| Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
| Call trace:
| dump_backtrace+0x0/0x284
| show_stack+0x1c/0x28
| dump_stack+0xf0/0x1a4
| ___might_sleep+0x2bc/0x2cc
| unmap_stage2_range+0x160/0x1ac
| kvm_unmap_hva_range+0x1a0/0x1c8
| kvm_mmu_notifier_invalidate_range_start+0x8c/0xf8
| __mmu_notifier_invalidate_range_start+0x218/0x31c
| mmu_notifier_invalidate_range_start_nonblock+0x78/0xb0
| __oom_reap_task_mm+0x128/0x268
| oom_reap_task+0xac/0x298
| oom_reaper+0x178/0x17c
| kthread+0x1e4/0x1fc
| ret_from_fork+0x10/0x30
Use the new 'flags' argument to kvm_unmap_hva_range() to ensure that we
only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is set in the notifier
flags.
Cc:
Fixes: 8b3405e345b5 ("kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd")
Cc: Marc Zyngier
Cc: Suzuki K Poulose
Cc: James Morse
Signed-off-by: Will Deacon
---
Reviewed-by: Suzuki K Poulose
