Re: [PATCH] staging: r8188eu: remove unused members of struct xmit_buf

[Dan Carpenter]

On Mon, Jul 13, 2020 at 04:16:07PM +0300, Dan Carpenter wrote:
> On Sun, Jul 12, 2020 at 03:38:21PM +0300, Ivan Safonov wrote:
> > Remove unused members of struct xmit_buf: alloc_sz, ff_hwaddr,
> > dma_transfer_addr, bpending and last.
> > 
> > Signed-off-by: Ivan Safonov 
> > ---
> >  drivers/staging/rtl8188eu/include/rtw_xmit.h  | 5 -
> >  drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 1 -
> >  2 files changed, 6 deletions(-)
> > 
> > diff --git a/drivers/staging/rtl8188eu/include/rtw_xmit.h 
> > b/drivers/staging/rtl8188eu/include/rtw_xmit.h
> > index 12d16e98176a..3c03987c81a1 100644
> > --- a/drivers/staging/rtl8188eu/include/rtw_xmit.h
> > +++ b/drivers/staging/rtl8188eu/include/rtw_xmit.h
> > @@ -193,14 +193,9 @@ struct xmit_buf {
> > void *priv_data;
> > u16 ext_tag; /*  0: Normal xmitbuf, 1: extension xmitbuf. */
> > u16 flags;
> > -   u32 alloc_sz;
> > u32  len;
> > struct submit_ctx *sctx;
> > -   u32 ff_hwaddr;
> > struct urb *pxmit_urb[8];
> > -   dma_addr_t dma_transfer_addr;   /* (in) dma addr for transfer_buffer */
> > -   u8 bpending[8];
> > -   int last[8];
> >  };
> >  
> >  struct xmit_frame {
> > diff --git a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c 
> > b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
> > index 017e1d628461..61ced1160951 100644
> > --- a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
> > +++ b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
> > @@ -24,7 +24,6 @@ int rtw_os_xmit_resource_alloc(struct adapter *padapter,
> > return _FAIL;
> >  
> > pxmitbuf->pbuf = PTR_ALIGN(pxmitbuf->pallocated_buf, XMITBUF_ALIGN_SZ);
> 
> Not related to this patch but kmalloc always returns data which is at
> least ARCH_KMALLOC_MINALIGN aligned which is never less than
> XMITBUF_ALIGN_SZ (4) so this is a no-op.

The alignment in the driver is pretty crazy because it's all unnecessary
and so complicated.  Every allocation is 4 bytes extra so we can align
it later.

Also every buffer is called "pbuf" which stands for pointer to buffer.
"pallocated_buf" is not really useful either.

I tried to look at this to see if we could change the alignment, and
it's complicated because of the naming and the alignment.

regards,
dan carpenter

[PATCH][next] drm/i915/selftest: fix an error return path where err is not being set

[Colin King]

From: Colin Ian King 

There is an error condition where err is not being set and an uninitialized
garbage value in err is being returned.  Fix this by assigning err to an
appropriate error return value before taking the error exit path.

Addresses-Coverity: ("Uninitialized scalar value")
Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across 
noa_wait")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/selftests/i915_perf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c 
b/drivers/gpu/drm/i915/selftests/i915_perf.c
index deb6dec1b5ab..7aa73bb03381 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf.c
+++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
@@ -329,6 +329,7 @@ static int live_noa_gpr(void *arg)
cs = intel_ring_begin(rq, 2 * 32 + 2);
if (IS_ERR(cs)) {
i915_request_add(rq);
+   err = PTR_ERR(cs);
goto out_rq;
}
 
-- 
2.27.0

Re: [PATCH] pinctrl: qcom: Handle broken PDC dual edge case on sc7180

[Maulik Shah]

Hi,

On 7/10/2020 9:40 PM, Doug Anderson wrote:

Hi,

On Fri, Jul 10, 2020 at 2:03 AM Marc Zyngier  wrote:

Hi Doug,

On Wed, 08 Jul 2020 22:16:25 +0100,
Douglas Anderson  wrote:

As per Qualcomm, there is a PDC hardware issue (with the specific IP
rev that exists on sc7180) that causes the PDC not to work properly
when configured to handle dual edges.

Let's work around this by emulating only ever letting our parent see
requests for single edge interrupts on affected hardware.

Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
Signed-off-by: Douglas Anderson 
---
As far as I can tell everything here should work and the limited
testing I'm able to give it shows that, in fact, I can detect both
edges.

Please give this an extra thorough review since it's trying to find
the exact right place to insert this code and I'm not massively
familiar with all the frameworks.

If someone has hardware where it's easy to stress test this that'd be
wonderful too.  The board I happen to have in front of me doesn't have
any easy-to-toggle GPIOs where I can just poke a button or a switch to
generate edges.  My testing was done by hacking the "write protect"
GPIO on my board into gpio-keys as a dual-edge interrupt and then
sending commands to our security chip to toggle it--not exactly great
for testing to make sure there are no race conditions if the interrupt
bounces a lot.

This looks positively awful (the erratum, not the patch). Is there an
actual description of the problem, outlining the circumstances that
triggers this issue? The PDC really never fails to disappoint...

Hopefully someone from Qualcomm can chime in here.  My entire
knowledge of the errata comes from:

https://lore.kernel.org/r/c747043d-c69e-4153-f2ca-16f1fc306...@codeaurora.org

...and I tried to copy the exact phrasing that Rajendra gave.
PDC irqchip not detecting dual edge interrupts is not really a bug. PDC 
closely works in hierarchy with
GIC and GIC also doesn't support dual edge IRQs.  Dual edge feature is 
added in later HW revisions to support

similar usecases.

Regardless of dual edge feature,  as i mentioned in below link
if the drivers requests the intended edge of the interrupt then it works 
as expected.

(Drivers never need/use both the edges at a same time).
but if we are not intending to change/update each driver which use dual 
edge, this patch takes care of
same by requesting only one edge at a time, albeit its done from irqchip 
driver as opposed to client driver.


https://lore.kernel.org/linux-arm-msm/56fb02df-372d-935a-cc39-c13289d65...@codeaurora.org/

Thanks,
Maulik



  drivers/pinctrl/qcom/pinctrl-msm.c| 80 +++
  drivers/pinctrl/qcom/pinctrl-msm.h|  4 ++
  drivers/pinctrl/qcom/pinctrl-sc7180.c |  1 +
  3 files changed, 85 insertions(+)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 83b7d64bc4c1..45ca09ebb7b3 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -860,6 +860,79 @@ static void msm_gpio_irq_ack(struct irq_data *d)
   raw_spin_unlock_irqrestore(&pctrl->lock, flags);
  }

+/**
+ * msm_gpio_update_dual_edge_parent() - Prime next edge for IRQs handled by 
parent.
+ * @d: The irq dta.
+ *
+ * This is much like msm_gpio_update_dual_edge_pos() but for IRQs that are
+ * normally handled by the parent irqchip.  The logic here is slightly
+ * different due to what's easy to do with our parent, but in principle it's
+ * the same.
+ */
+static void msm_gpio_update_dual_edge_parent(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
+ const struct msm_pingroup *g = &pctrl->soc->groups[d->hwirq];
+ unsigned long flags;
+ int loop_limit = 100;

I guess this is a "finger up in the air" type of limit?

Yes, the same "finger up in the air" as
msm_gpio_update_dual_edge_pos() in the same file.  My function comment
refers to the other function to try to tie them together at least a
little.



+ unsigned int val;
+ unsigned int type;
+
+ /* Read the value and make a guess about what edge we need to catch */
+ val = msm_readl_io(pctrl, g) & BIT(g->in_bit);

What does this value represent? The input line value?

Yes.  Coped from msm_gpio_update_dual_edge_pos().



+ type = val ? IRQ_TYPE_EDGE_FALLING : IRQ_TYPE_EDGE_RISING;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);

What is this lock protecting you against? In both cases, you are
already under the irq_desc lock, with interrupts disabled.

We are?  I put a breakpoint when the IRQ hits and did a bt.  I see
this (I happen to be on 5.4 at the moment, so hopefully the same as
mainline):

  kgdb_breakpoint+0x3c/0x74
  msm_gpio_update_dual_edge_parent+0x58/0x17c
  msm_gpio_handle_dual_edge_parent_irq+0x1c/0x30
  __handle_domain_irq+0x84/0xc4
  gic_handle_irq+0x170/0x220
  el1_irq+0xd0/0x180

I think the stack is missing a few thing

Re: [PATCH v2 2/2] PM / devfreq: Add governor flags to clarify the features

[Dmitry Osipenko]

13.07.2020 15:26, Chanwoo Choi пишет:
...
>> BTW, I'm curious what do you think about hiding the unsupported debugfs
> 
> Do you mean that sysfs?

Yes, sysfs :)

>> attributes per-device instead of returning the -EACCES?
> 
> I considered the hiding of sysfs node too instead of -EACCES.

If there is no real userspace (used by a non-developer crowd) that
relies on the attributes presence, then it could be fine to change the
behaviour, IMO.

I know that PowerTOP utility uses the 'trans_stat' attribute, but not
sure about the other attributes.

> But,
> For a long time, devfreq showed the sysfs interface of all devfreq devices
> regardless of the kind of devfreq governor. It means that devfreq keeps
> the ABI interface. If devfreq hides the unsupported sysfs node
> according to the type of governor, it will break the ABI.

I didn't notice that it's an ABI already [1]. Should be better not to
change the ABI if there is userspace already relying on the old
behaviour, otherwise it may be okay to make changes until it will be too
late, also given that this is still a "testing" ABI.

[1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-devfreq

Although, the doc doesn't say anything about -EACCES/-EINVAL, so isn't
it an ABI change already? Doesn't doc need to be updated in order to
reflect the ABI change?

For example, doc says that userspace shouldn't care about attribute
values which are irrelevant for a selected governor, like in the case of
the 'polling_interval' attribute. The doc doesn't say that userspace may
get a error.

> Although I knew that maybe performance/powersave/userspace didn't use
> the 'polling_interval' node, I just returned -EACCESS.

The 'polling_interval', 'min/max_freq' and the new 'timer' attributes
are all the governor attributes.

Would be nice to have a per-device `governor/` directory containing all
the governor-specific attributes (without the unrelated attributes), but
perhaps it's a bit too late to change it now?

Re: [PATCH v2 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

[Jon Hunter]

On 10/07/2020 10:44, Zhenyu Ye wrote:
> Add __TLBI_VADDR_RANGE macro and rewrite __flush_tlb_range().
> 
> When cpu supports TLBI feature, the minimum range granularity is
> decided by 'scale', so we can not flush all pages by one instruction
> in some cases.
> 
> For example, when the pages = 0xe81a, let's start 'scale' from
> maximum, and find right 'num' for each 'scale':
> 
> 1. scale = 3, we can flush no pages because the minimum range is
>2^(5*3 + 1) = 0x1.
> 2. scale = 2, the minimum range is 2^(5*2 + 1) = 0x800, we can
>flush 0xe800 pages this time, the num = 0xe800/0x800 - 1 = 0x1c.
>Remaining pages is 0x1a;
> 3. scale = 1, the minimum range is 2^(5*1 + 1) = 0x40, no page
>can be flushed.
> 4. scale = 0, we flush the remaining 0x1a pages, the num =
>0x1a/0x2 - 1 = 0xd.
> 
> However, in most scenarios, the pages = 1 when flush_tlb_range() is
> called. Start from scale = 3 or other proper value (such as scale =
> ilog2(pages)), will incur extra overhead.
> So increase 'scale' from 0 to maximum, the flush order is exactly
> opposite to the example.
> 
> Signed-off-by: Zhenyu Ye 


After this change I am seeing the following build errors ...

/tmp/cckzq3FT.s: Assembler messages:
/tmp/cckzq3FT.s:854: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x7'
/tmp/cckzq3FT.s:870: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x7'
/tmp/cckzq3FT.s:1095: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x7'
/tmp/cckzq3FT.s:: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x7'
/tmp/cckzq3FT.s:1964: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x7'
/tmp/cckzq3FT.s:1980: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x7'
/tmp/cckzq3FT.s:2286: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x7'
/tmp/cckzq3FT.s:2302: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x7'
/tmp/cckzq3FT.s:4833: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x6'
/tmp/cckzq3FT.s:4849: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x6'
/tmp/cckzq3FT.s:5090: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x6'
/tmp/cckzq3FT.s:5106: Error: unknown or missing operation name at operand 1 -- 
`tlbi rvae1is,x6'
/tmp/cckzq3FT.s:874: Error: attempt to move .org backwards
/tmp/cckzq3FT.s:1115: Error: attempt to move .org backwards
/tmp/cckzq3FT.s:1984: Error: attempt to move .org backwards
/tmp/cckzq3FT.s:2306: Error: attempt to move .org backwards
/tmp/cckzq3FT.s:4853: Error: attempt to move .org backwards
/tmp/cckzq3FT.s:5110: Error: attempt to move .org backwards
scripts/Makefile.build:280: recipe for target 'arch/arm64/mm/hugetlbpage.o' 
failed
make[3]: *** [arch/arm64/mm/hugetlbpage.o] Error 1
scripts/Makefile.build:497: recipe for target 'arch/arm64/mm' failed
make[2]: *** [arch/arm64/mm] Error 2

Cheers
Jon

-- 
nvpublic

Re: [PATCH v6 1/2] sched/uclamp: Add a new sysctl to control RT default boost value

[Qais Yousef]

On 07/13/20 15:35, Peter Zijlstra wrote:
> On Mon, Jul 13, 2020 at 01:12:46PM +0100, Qais Yousef wrote:
> > On 07/13/20 13:21, Peter Zijlstra wrote:
> 
> > > It's monday, and I cannot get my brain working.. I cannot decipher the
> > > comments you have with the smp_[rw]mb(), what actual ordering do they
> > > enforce?
> > 
> > It was a  bit of a paranoia to ensure that readers on other cpus see the new
> > value after this point.
> 
> IIUC that's not something any barrier can provide.
> 
> Barriers can only order between (at least) two memory operations:
> 
>   X = 1;  y = Y;
>   smp_wmb();  smp_rmb();
>   Y = 1;  x = X;
> 
> guarantees that if y == 1, then x must also be 1. Because the left hand
> side orders the store of Y after the store of X, while the right hand
> side order the load of X after the load of Y. Therefore, if the first
> load observes the last store, the second load must observe the first
> store.
> 
> Without a second variable, barriers can't guarantee _anything_. Which is
> why any barrier comment should refer to at least two variables.

Hmmm okay. I thought this will order the write with the read. In my head if,
for example, the write was stuck in the write buffer of CPU0, then a read on
CPU1 would wait for this to be committed before carrying on and issue a read.

So I was reading this as don't issue new reads before current writes are done.

I need to go back and read memory-barriers.rst. It's been 10 years since I last
read it..

> 
> > > Also, your synchronize_rcu() relies on write_lock() beeing
> > > non-preemptible, which isn't true on PREEMPT_RT.
> > > 
> > > The below seems simpler...
> 
> > Hmm maybe I am missing something obvious, but beside the race with fork; I 
> > was
> > worried about another race and that's what the synchronize_rcu() is trying 
> > to
> > handle.
> > 
> > It's the classic preemption in the middle of RMW operation race.
> > 
> > copy_process()  sysctl_uclamp
> > 
> >   sched_post_fork()
> > __uclamp_sync_rt()
> >   // read sysctl
> >   // PREEMPT
> >   for_each_process_thread()
> >   // RESUME
> >   // write syctl to p
> > 
> 
> > 2. sysctl_uclamp happens *during* sched_post_fork()
> > 
> > There's the risk of the classic preemption in the middle of RMW where 
> > another
> > CPU could have changed the shared variable after the current CPU has already
> > read it, but before writing it back.
> 
> Aah.. I see.
> 
> > I protect this with rcu_read_lock() which as far as I know synchronize_rcu()
> > will ensure if we do the update during this section; we'll wait for it to
> > finish. New forkees entering the rcu_read_lock() section will be okay 
> > because
> > they should see the new value.
> > 
> > spinlocks() and mutexes seemed inferior to this approach.
> 
> Well, didn't we just write in another patch that p->uclamp_* was
> protected by both rq->lock and p->pi_lock?

__setscheduler_uclamp() path is holding these locks, not sure by design or it
just happened this path holds the lock. I can't see the lock in the
uclamp_fork() path. But it's hard sometimes to unfold the layers of callers,
especially not all call sites are annotated for which lock is assumed to be
held.

Is it safe to hold the locks in uclamp_fork() while the task is still being
created? My new code doesn't hold it of course.

We can enforce this rule if you like. Though rcu critical section seems lighter
weight to me.

If all of this does indeed start looking messy we can put the update in
a delayed worker and schedule that instead of doing synchronous setup.

Or go back to task_woken_rt() with a cached per-rq variable of
sysctl_util_min_rt that is more likely to be cache hot compared to the global
sysctl_util_min_rt variable.

Thanks

--
Qais Yousef

Re: [PATCH] Revert "ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb"

[Kalle Valo]

Viktor Jägersküpper  writes:

> Kalle Valo wrote:
>> Viktor Jägersküpper  writes:
>> 
>>> Kalle Valo writes:
 Roman Mamedov  writes:

> On Sat,  4 Apr 2020 12:18:38 +0800
> Qiujun Huang  wrote:
>
>> In ath9k_hif_usb_rx_cb interface number is assumed to be 0.
>> usb_ifnum_to_if(urb->dev, 0)
>> But it isn't always true.
>>
>> The case reported by syzbot:
>> https://lore.kernel.org/linux-usb/666c9c05a1c05...@google.com
>> usb 2-1: new high-speed USB device number 2 using dummy_hcd
>> usb 2-1: config 1 has an invalid interface number: 2 but max is 0
>> usb 2-1: config 1 has no interface number 0
>> usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice=
>> 1.08
>> usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>> general protection fault, probably for non-canonical address
>> 0xdc15:  [#1] SMP KASAN
>> KASAN: null-ptr-deref in range [0x00a8-0x00af]
>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0
>>
>> Call Trace
>> __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
>> usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
>> dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
>> call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
>> expire_timers kernel/time/timer.c:1449 [inline]
>> __run_timers kernel/time/timer.c:1773 [inline]
>> __run_timers kernel/time/timer.c:1740 [inline]
>> run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
>> __do_softirq+0x21e/0x950 kernel/softirq.c:292
>> invoke_softirq kernel/softirq.c:373 [inline]
>> irq_exit+0x178/0x1a0 kernel/softirq.c:413
>> exiting_irq arch/x86/include/asm/apic.h:546 [inline]
>> smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146
>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
>>
>> Reported-and-tested-by: 
>> syzbot+40d5d2e8a4680952f...@syzkaller.appspotmail.com
>> Signed-off-by: Qiujun Huang 
>
> This causes complete breakage of ath9k operation across all the stable 
> kernel
> series it got backported to, and I guess the mainline as well. Please see:
> https://bugzilla.kernel.org/show_bug.cgi?id=208251
> https://bugzilla.redhat.com/show_bug.cgi?id=1848631

 So there's no fix for this? I was under impression that someone fixed
 this, but maybe I'm mixing with something else.

 If this is not fixed can someone please submit a patch to revert the
 offending commit (or commits) so that we get ath9k working again?

>>>
>>> This reverts commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05
>>> ("ath9k: Fix general protection fault
>>> in ath9k_hif_usb_rx_cb") because the driver gets stuck like this:
>>>
>>>   [5.778803] usb 1-5: Manufacturer: ATHEROS
>>>   [   21.697488] usb 1-5: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw 
>>> requested
>>>   [   21.701377] usbcore: registered new interface driver ath9k_htc
>>>   [ 22.053705] usb 1-5: ath9k_htc: Transferred FW:
>>> ath9k_htc/htc_9271-1.4.0.fw, size: 51008
>>>   [   22.306182] ath9k_htc 1-5:1.0: ath9k_htc: HTC initialized with 33 
>>> credits
>>>   [  115.708513] ath9k_htc: Failed to initialize the device
>>>   [  115.708683] usb 1-5: ath9k_htc: USB layer deinitialized
>>>
>>> Reported-by: Roman Mamedov 
>>> Ref: https://bugzilla.kernel.org/show_bug.cgi?id=208251
>>> Fixes: 2bbcaaee1fcb ("ath9k: Fix general protection fault in 
>>> ath9k_hif_usb_rx_cb")
>>> Tested-by: Viktor Jägersküpper 
>>> Signed-off-by: Viktor Jägersküpper 
>>> ---
>>>
>>> I couldn't find any fix for this, so here is the patch which reverts the
>>> offending commit. I have tested it with 5.8.0-rc3 and with 5.7.4.
>>>
>>> Feel free to change the commit message if it is necessary or appropriate, I 
>>> am
>>> just a user affected by this bug.
>> 
>> This was badly formatted:
>> 
>> https://patchwork.kernel.org/patch/11636783/
>> 
>> But v2 looks correct:
>> 
>> https://patchwork.kernel.org/patch/11637341/
>> 
>> Thanks, I'll take a closer look at this as soon as I can.
>> 
>
> Hi Kalle,
>
> it seems you didn't have time for this so far. If you don't have time at the
> moment, is there someone else who can fix this? Reverting the commit is just 
> the
> first and easy option and fixing this properly can be done after that.

I was on vacation, I will get to your patch in the next few days.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 1/2] dt-bindings: leds: pca955x: Add IBM implementation compatible string

[Eddie James]

On 7/11/20 8:48 AM, Pavel Machek wrote:

Hi!


IBM created an implementation of the PCA9552 on a PIC16F
microcontroller. Document the new compatible string for this device.

Is the implementation opensource?



Hi, no it is not.





Signed-off-by: Eddie James 
+++ b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
@@ -9,6 +9,7 @@ Required properties:
"nxp,pca9550"
"nxp,pca9551"
"nxp,pca9552"
+   "nxp,pca9552-ibm"
"nxp,pca9553"

Is it good idea to use nxp prefix for something that is
software-defined and not built by nxp?



Yea I suppose not...



Would ibm,pca9552 be better, or maybe even sw,pca9552 to indicate that
is not real hardware, but software emulation?



How about ibm,pca9552-sw? Someone suggested that just adding "sw" could 
be a problem if another company does the same thing but it isn't compatible.



Thanks for taking a look!

Eddie




Best regards,
Pavel

Re: [PATCH 2/2] leds: pca955x: Add an IBM software implementation of the PCA9552 chip

[Eddie James]

On 7/9/20 3:50 PM, Andy Shevchenko wrote:

On Thu, Jul 9, 2020 at 11:16 PM Eddie James  wrote:

IBM created an implementation of the PCA9552 on a PIC16F
microcontroller. The I2C device addresses are different from the
hardware PCA9552, so add a new compatible string and associated
platform data to be able to probe this device.

This is weird. I would rather expect ibm prefix with corresponding part number.



Yep I agree now, see my note to Pavel just now.


Thanks,

Eddie





+   pca9552_ibm,
+   [pca9552_ibm] = {
+   { "pca9552-ibm", pca9552_ibm },
+   { .compatible = "nxp,pca9552-ibm", .data = (void *)pca9552_ibm },

[PATCH] isdn/capi: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/isdn/capi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/isdn/capi/Kconfig b/drivers/isdn/capi/Kconfig
index cc408ad9aafb..fdb43a632215 100644
--- a/drivers/isdn/capi/Kconfig
+++ b/drivers/isdn/capi/Kconfig
@@ -5,7 +5,7 @@ config ISDN_CAPI
  This provides CAPI (the Common ISDN Application Programming
  Interface) Version 2.0, a standard making it easy for programs to
  access ISDN hardware in a device independent way. (For details see
- .)  CAPI supports making and accepting voice
+ .)  CAPI supports making and accepting voice
  and data connections, controlling call options and protocols,
  as well as ISDN supplementary services like call forwarding or
  three-party conferences (if supported by the specific hardware
-- 
2.27.0

Re: [TEGRA194_CPUFREQ PATCH v4 3/4] cpufreq: Add Tegra194 cpufreq driver

[Sumit Gupta]

On 26-06-20, 21:13, Sumit Gupta wrote:

+static int tegra194_cpufreq_probe(struct platform_device *pdev)
+{
+ struct tegra194_cpufreq_data *data;
+ struct tegra_bpmp *bpmp;
+ int err, i;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->num_clusters = MAX_CLUSTERS;
+ data->tables = devm_kcalloc(&pdev->dev, data->num_clusters,
+ sizeof(*data->tables), GFP_KERNEL);
+ if (!data->tables)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, data);
+
+ bpmp = tegra_bpmp_get(&pdev->dev);
+ if (IS_ERR(bpmp))
+ return PTR_ERR(bpmp);
+
+ read_counters_wq = alloc_workqueue("read_counters_wq", __WQ_LEGACY, 1);
+ if (!read_counters_wq) {
+ dev_err(&pdev->dev, "fail to create_workqueue\n");
+ err = -EINVAL;
+ goto put_bpmp;


This will call destroy_workqueue() eventually and it will crash your
kernel.

Apart from this, this stuff looks okay. Don't resend the patch just
yet (and if required, send only this patch using --in-reply-to flag
for git send email). Lets wait for an Ack from Rob for the first two
patches.


Sorry for the delayed response as i was on PTO.
Thank you for the feedback.

Have posted a v5 based on v4 patch set.


+ }
+


--
viresh

[PATCH v2 1/3] dt-bindings: USB: Add bindings for new Ingenic SoCs.

[Zhou Yanjie]

Add the USB PHY bindings for the JZ4780 SoC, the X1000 SoC and
the X1830 SoC from Ingenic.

Tested-by: 周正 (Zhou Zheng) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
Acked-by: Rob Herring 
---

Notes:
v1->v2:
Add bindings for the JZ4780 SoC.

 Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml 
b/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml
index a81b0b1a2226..2d61166ea5cf 100644
--- a/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml
+++ b/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml
@@ -4,10 +4,11 @@
 $id: http://devicetree.org/schemas/usb/ingenic,jz4770-phy.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: Ingenic JZ4770 USB PHY devicetree bindings
+title: Ingenic SoCs USB PHY devicetree bindings
 
 maintainers:
   - Paul Cercueil 
+  - 周琰杰 (Zhou Yanjie) 
 
 properties:
   $nodename:
@@ -16,6 +17,9 @@ properties:
   compatible:
 enum:
   - ingenic,jz4770-phy
+  - ingenic,jz4780-phy
+  - ingenic,x1000-phy
+  - ingenic,x1830-phy
 
   reg:
 maxItems: 1
-- 
2.11.0

[PATCH v2 0/3] Add USB PHY support for new Ingenic SoCs.

[Zhou Yanjie]

v1->v2:
Add support for the JZ4780 SoC.

周琰杰 (Zhou Yanjie) (3):
  dt-bindings: USB: Add bindings for new Ingenic SoCs.
  USB: PHY: JZ4770: Add support for new Ingenic SoCs.
  USB: PHY: JZ4770: Reformat the code to align it.

 .../bindings/usb/ingenic,jz4770-phy.yaml   |   6 +-
 drivers/usb/phy/Kconfig|   4 +-
 drivers/usb/phy/phy-jz4770.c   | 256 ++---
 3 files changed, 181 insertions(+), 85 deletions(-)

-- 
2.11.0

[PATCH v2 3/3] USB: PHY: JZ4770: Reformat the code to align it.

[Zhou Yanjie]

Reformat the code (add one level of indentation before the values),
to align the code in the macro definition section.

Tested-by: 周正 (Zhou Zheng) 
Co-developed-by: 漆鹏振 (Qi Pengzhen) 
Signed-off-by: 漆鹏振 (Qi Pengzhen) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
---

Notes:
v2:
New patch.

 drivers/usb/phy/phy-jz4770.c | 100 +--
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/drivers/usb/phy/phy-jz4770.c b/drivers/usb/phy/phy-jz4770.c
index d1055c908943..65e517290912 100644
--- a/drivers/usb/phy/phy-jz4770.c
+++ b/drivers/usb/phy/phy-jz4770.c
@@ -15,71 +15,71 @@
 #include 
 #include 
 
-#define REG_USBPCR_OFFSET  0x00
-#define REG_USBRDT_OFFSET  0x04
-#define REG_USBVBFIL_OFFSET0x08
-#define REG_USBPCR1_OFFSET 0x0c
+#define REG_USBPCR_OFFSET  0x00
+#define REG_USBRDT_OFFSET  0x04
+#define REG_USBVBFIL_OFFSET0x08
+#define REG_USBPCR1_OFFSET 0x0c
 
 /*USB Parameter Control Register*/
-#define USBPCR_USB_MODEBIT(31)
-#define USBPCR_AVLD_REGBIT(30)
-#define USBPCR_INCR_MASK   BIT(27)
-#define USBPCR_COMMONONN   BIT(25)
-#define USBPCR_VBUSVLDEXT  BIT(24)
-#define USBPCR_VBUSVLDEXTSEL   BIT(23)
-#define USBPCR_POR BIT(22)
-#define USBPCR_SIDDQ   BIT(21)
-#define USBPCR_OTG_DISABLE BIT(20)
-#define USBPCR_TXPREEMPHTUNE   BIT(6)
-
-#define USBPCR_IDPULLUP_LSB28
-#define USBPCR_IDPULLUP_MASK   GENMASK(29, USBPCR_IDPULLUP_LSB)
-#define USBPCR_IDPULLUP_ALWAYS (0x2 << USBPCR_IDPULLUP_LSB)
-#define USBPCR_IDPULLUP_SUSPEND(0x1 << USBPCR_IDPULLUP_LSB)
-#define USBPCR_IDPULLUP_OTG(0x0 << USBPCR_IDPULLUP_LSB)
-
-#define USBPCR_COMPDISTUNE_LSB 17
-#define USBPCR_COMPDISTUNE_MASKGENMASK(19, USBPCR_COMPDISTUNE_LSB)
-#define USBPCR_COMPDISTUNE_DFT (0x4 << USBPCR_COMPDISTUNE_LSB)
-
-#define USBPCR_OTGTUNE_LSB 14
-#define USBPCR_OTGTUNE_MASKGENMASK(16, USBPCR_OTGTUNE_LSB)
-#define USBPCR_OTGTUNE_DFT (0x4 << USBPCR_OTGTUNE_LSB)
-
-#define USBPCR_SQRXTUNE_LSB11
-#define USBPCR_SQRXTUNE_MASK   GENMASK(13, USBPCR_SQRXTUNE_LSB)
+#define USBPCR_USB_MODEBIT(31)
+#define USBPCR_AVLD_REGBIT(30)
+#define USBPCR_INCR_MASK   BIT(27)
+#define USBPCR_COMMONONN   BIT(25)
+#define USBPCR_VBUSVLDEXT  BIT(24)
+#define USBPCR_VBUSVLDEXTSEL   BIT(23)
+#define USBPCR_POR BIT(22)
+#define USBPCR_SIDDQ   BIT(21)
+#define USBPCR_OTG_DISABLE BIT(20)
+#define USBPCR_TXPREEMPHTUNE   BIT(6)
+
+#define USBPCR_IDPULLUP_LSB28
+#define USBPCR_IDPULLUP_MASK   GENMASK(29, USBPCR_IDPULLUP_LSB)
+#define USBPCR_IDPULLUP_ALWAYS (0x2 << USBPCR_IDPULLUP_LSB)
+#define USBPCR_IDPULLUP_SUSPEND(0x1 << USBPCR_IDPULLUP_LSB)
+#define USBPCR_IDPULLUP_OTG(0x0 << USBPCR_IDPULLUP_LSB)
+
+#define USBPCR_COMPDISTUNE_LSB 17
+#define USBPCR_COMPDISTUNE_MASKGENMASK(19, 
USBPCR_COMPDISTUNE_LSB)
+#define USBPCR_COMPDISTUNE_DFT (0x4 << USBPCR_COMPDISTUNE_LSB)
+
+#define USBPCR_OTGTUNE_LSB 14
+#define USBPCR_OTGTUNE_MASKGENMASK(16, USBPCR_OTGTUNE_LSB)
+#define USBPCR_OTGTUNE_DFT (0x4 << USBPCR_OTGTUNE_LSB)
+
+#define USBPCR_SQRXTUNE_LSB11
+#define USBPCR_SQRXTUNE_MASK   GENMASK(13, USBPCR_SQRXTUNE_LSB)
 #define USBPCR_SQRXTUNE_DCR_20PCT  (0x7 << USBPCR_SQRXTUNE_LSB)
-#define USBPCR_SQRXTUNE_DFT(0x3 << USBPCR_SQRXTUNE_LSB)
+#define USBPCR_SQRXTUNE_DFT(0x3 << USBPCR_SQRXTUNE_LSB)
 
-#define USBPCR_TXFSLSTUNE_LSB  7
-#define USBPCR_TXFSLSTUNE_MASK GENMASK(10, USBPCR_TXFSLSTUNE_LSB)
+#define USBPCR_TXFSLSTUNE_LSB  7
+#define USBPCR_TXFSLSTUNE_MASK GENMASK(10, USBPCR_TXFSLSTUNE_LSB)
 #define USBPCR_TXFSLSTUNE_DCR_50PPT(0xf << USBPCR_TXFSLSTUNE_LSB)
 #define USBPCR_TXFSLSTUNE_DCR_25PPT(0x7 << USBPCR_TXFSLSTUNE_LSB)
-#define USBPCR_TXFSLSTUNE_DFT  (0x3 << USBPCR_TXFSLSTUNE_LSB)
+#define USBPCR_TXFSLSTUNE_DFT  (0x3 << USBPCR_TXFSLSTUNE_LSB)
 #define USBPCR_TXFSLSTUNE_INC_25PPT(0x1 << USBPCR_TXFSLSTUNE_LSB)
 #define USBPCR_TXFSLSTUNE_INC_50PPT(0x0 << USBPCR_TXFSLSTUNE_LSB)
 
-#define USBPCR_TXHSXVTUNE_LSB  4
-#define USBPCR_TXHSXVTUNE_MASK GENMASK(5, USBPCR_TXHSXVTUNE_LSB)
-#define USBPCR_TXHSXVTUNE_DFT  (0x3 << USBPCR_TXHSXVTUNE_LSB)
+#define USBPCR_TXHSXVTUNE_LSB  4
+#define USBPCR_TXHSXVTUNE_MASK GENMASK(5, USBPCR_TXHSXVTUNE_LSB)
+#define USBPCR_TXHSXVTUNE_DFT  (0x3 << USBPCR_TXHSXVTUNE_LSB)
 #define USBPCR_TXHSXVTUNE_DCR_15MV (0x1 << USBPCR_TXHSXVTUNE_LSB)
 
-#define USBPCR_TXRISETUNE_LSB  4
-#define USBPCR_TXRISETUNE_MASK GENMASK(5, USBPCR

Re: [PATCH v2 1/3] arch_topology, sched/core: Cleanup thermal pressure definition

[Thara Gopinath]

On 7/12/20 12:59 PM, Valentin Schneider wrote:

The following commit:

   14533a16c46d ("thermal/cpu-cooling, sched/core: Move the 
arch_set_thermal_pressure() API to generic scheduler code")

moved the definition of arch_set_thermal_pressure() to sched/core.c, but
kept its declaration in linux/arch_topology.h. When building e.g. an x86
kernel with CONFIG_SCHED_THERMAL_PRESSURE=y, cpufreq_cooling.c ends up
getting the declaration of arch_set_thermal_pressure() from
include/linux/arch_topology.h, which is somewhat awkward.

On top of this, sched/core.c unconditionally defines
o The thermal_pressure percpu variable
o arch_set_thermal_pressure()

while arch_scale_thermal_pressure() does nothing unless redefined by the
architecture.

arch_*() functions are meant to be defined by architectures, so revert the
aforementioned commit and re-implement it in a way that keeps
arch_set_thermal_pressure() architecture-definable, and doesn't define the
thermal pressure percpu variable for kernels that don't need
it (CONFIG_SCHED_THERMAL_PRESSURE=n).

Signed-off-by: Valentin Schneider 
---


Reviewed-by: Thara Gopinath 


  arch/arm/include/asm/topology.h   |  3 ++-
  arch/arm64/include/asm/topology.h |  3 ++-
  drivers/base/arch_topology.c  | 11 +++
  include/linux/arch_topology.h |  4 ++--
  include/linux/sched/topology.h|  7 +++
  kernel/sched/core.c   | 11 ---
  6 files changed, 24 insertions(+), 15 deletions(-)

diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index 435aba289fc5..e0593cf095d0 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -16,8 +16,9 @@
  /* Enable topology flag updates */
  #define arch_update_cpu_topology topology_update_cpu_topology
  
-/* Replace task scheduler's default thermal pressure retrieve API */

+/* Replace task scheduler's default thermal pressure API */
  #define arch_scale_thermal_pressure topology_get_thermal_pressure
+#define arch_set_thermal_pressure   topology_set_thermal_pressure
  
  #else
  
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h

index 0cc835ddfcd1..e042f6527981 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -34,8 +34,9 @@ void topology_scale_freq_tick(void);
  /* Enable topology flag updates */
  #define arch_update_cpu_topology topology_update_cpu_topology
  
-/* Replace task scheduler's default thermal pressure retrieve API */

+/* Replace task scheduler's default thermal pressure API */
  #define arch_scale_thermal_pressure topology_get_thermal_pressure
+#define arch_set_thermal_pressure   topology_set_thermal_pressure
  
  #include 
  
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c

index 4d0a0038b476..d14cab7dfa3c 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -54,6 +54,17 @@ void topology_set_cpu_scale(unsigned int cpu, unsigned long 
capacity)
per_cpu(cpu_scale, cpu) = capacity;
  }
  
+DEFINE_PER_CPU(unsigned long, thermal_pressure);

+
+void arch_set_thermal_pressure(const struct cpumask *cpus,
+  unsigned long th_pressure)
+{
+   int cpu;
+
+   for_each_cpu(cpu, cpus)
+   WRITE_ONCE(per_cpu(thermal_pressure, cpu), th_pressure);
+}
+
  static ssize_t cpu_capacity_show(struct device *dev,
 struct device_attribute *attr,
 char *buf)
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index 0566cb3314ef..69b1dabe39dc 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -39,8 +39,8 @@ static inline unsigned long topology_get_thermal_pressure(int 
cpu)
return per_cpu(thermal_pressure, cpu);
  }
  
-void arch_set_thermal_pressure(struct cpumask *cpus,

-  unsigned long th_pressure);
+void topology_set_thermal_pressure(const struct cpumask *cpus,
+  unsigned long th_pressure);
  
  struct cpu_topology {

int thread_id;
diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index fb11091129b3..764222d637b7 100644
--- a/include/linux/sched/topology.h
+++ b/include/linux/sched/topology.h
@@ -232,6 +232,13 @@ unsigned long arch_scale_thermal_pressure(int cpu)
  }
  #endif
  
+#ifndef arch_set_thermal_pressure

+static __always_inline
+void arch_set_thermal_pressure(const struct cpumask *cpus,
+  unsigned long th_pressure)
+{ }
+#endif
+
  static inline int task_node(const struct task_struct *p)
  {
return cpu_to_node(task_cpu(p));
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ff0519551188..90b44f3840e4 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3731,17 +3731,6 @@ unsigned long long task_sched_runtime(struct task_struct 
*p)
return ns;
  }
  
-DEFINE_PER_CPU(unsigned long, therm

[PATCH v2] staging: comedi: s626: Remove pci-dma-compat wrapper APIs.

[Suraj Upadhyay]

The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.

The patch has been generated with the coccinelle script below
and compile-tested.


- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL


- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE


- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE


- PCI_DMA_NONE
+ DMA_NONE

@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(&E1->dev, E2, E3, GFP_ATOMIC)

@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(&E1->dev, E2, E3, GFP_ATOMIC)

@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(&E1->dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(&E1->dev, E2, E3, (enum dma_data_direction)E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(&E1->dev, E2, E3, (enum dma_data_direction)E4)

@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(&E1->dev, E2, E3, E4, (enum dma_data_direction)E5)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(&E1->dev, E2, E3, (enum dma_data_direction)E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(&E1->dev, E2, E3, (enum dma_data_direction)E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(&E1->dev, E2, E3, (enum dma_data_direction)E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(&E1->dev, E2, E3, (enum dma_data_direction)E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(&E1->dev, E2, E3, (enum dma_data_direction)E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(&E1->dev, E2, E3, (enum dma_data_direction)E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(&E1->dev, E2, E3, (enum dma_data_direction)E4)

@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(&E1->dev, E2)

@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(&E1->dev, E2)

@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(&E1->dev, E2)

Signed-off-by: Suraj Upadhyay 
---
Changes:
v2: Converted the GFP_ATOMIC flag to GFP_KERNEL to suit for the
context. On reviewer's advise.

 drivers/staging/comedi/drivers/s626.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 084a8e7b9fc2..e7aba937d896 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -2130,13 +2130,15 @@ static int s626_allocate_dma_buffers(struct 
comedi_device *dev)
void *addr;
dma_addr_t appdma;
 
-   addr = pci_alloc_consistent(pcidev, S626_DMABUF_SIZE, &appdma);
+   addr = dma_alloc_coherent(&pcidev->dev, S626_DMABUF_SIZE, &appdma,
+ GFP_KERNEL);
if (!addr)
return -ENOMEM;
devpriv->ana_buf.logical_base = addr;
devpriv->ana_buf.physical_base = appdma;
 
-   addr = pci_alloc_consistent(pcidev, S626_DMABUF_SIZE, &appdma);
+   addr = dma_alloc_coherent(&pcidev->dev, S626_DMABUF_SIZE, &appdma,
+ GFP_KERNEL);
if (!addr)
return -ENOMEM;
devpriv->rps_buf.logical_base = addr;
@@ -2154,13 +2156,13 @@ static void s626_free_dma_buffers(struct comedi_device 
*dev)
return;
 
if (devpriv->rps_buf.logical_base)
-   pci_free_consistent(pcidev, S626_DMABUF_SIZE,
-   devpriv->rps_buf.logical_base,
-   devpriv->rps_buf.physical_base);
+   dma_free_coherent(&pcidev->dev, S626_DMABUF_SIZE,
+ devpriv->rps_buf.logical_base,
+ devpriv->rps_buf.physical_base);
if (devpriv->ana_buf.logical_base)
-   pci_free_consistent(pcidev, S626_DMABUF_SIZE,
-   devpriv->ana_buf.logical_base,
-   devpriv->ana_buf.physical_base);
+   dma_free_coherent(&pcidev->dev, S626_DMABUF_SIZE,
+ devpriv->ana_buf.logical_base,
+ devpriv->ana_buf.physical_base);
 }
 
 static int s626_initialize(struct comedi_device *dev)
-- 
2.17.1



signature.asc
Description: PGP signature

[PATCH v2 2/3] USB: PHY: JZ4770: Add support for new Ingenic SoCs.

[Zhou Yanjie]

Add support for probing the phy-jz4770 driver on the JZ4780 SoC,
the X1000 SoC and the X1830 SoC from Ingenic.

Tested-by: 周正 (Zhou Zheng) 
Co-developed-by: 漆鹏振 (Qi Pengzhen) 
Signed-off-by: 漆鹏振 (Qi Pengzhen) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
---

Notes:
v1->v2:
Add support for the JZ4780 SoC.

 drivers/usb/phy/Kconfig  |   4 +-
 drivers/usb/phy/phy-jz4770.c | 178 ---
 2 files changed, 137 insertions(+), 45 deletions(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 4b3fa78995cf..775f0dd7b5f5 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -185,11 +185,11 @@ config USB_ULPI_VIEWPORT
  controllers with a viewport register (e.g. Chipidea/ARC controllers).
 
 config JZ4770_PHY
-   tristate "Ingenic JZ4770 Transceiver Driver"
+   tristate "Ingenic SoCs Transceiver Driver"
depends on MIPS || COMPILE_TEST
select USB_PHY
help
  This driver provides PHY support for the USB controller found
- on the JZ4770 SoC from Ingenic.
+ on the JZ4770/JZ4780/X1000/X1830 SoC from Ingenic.
 
 endmenu
diff --git a/drivers/usb/phy/phy-jz4770.c b/drivers/usb/phy/phy-jz4770.c
index 8f62dc2a90ff..d1055c908943 100644
--- a/drivers/usb/phy/phy-jz4770.c
+++ b/drivers/usb/phy/phy-jz4770.c
@@ -1,12 +1,15 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Ingenic JZ4770 USB PHY driver
+ * Ingenic SoCs USB PHY driver
  * Copyright (c) Paul Cercueil 
+ * Copyright (c) 漆鹏振 (Qi Pengzhen) 
+ * Copyright (c) 周琰杰 (Zhou Yanjie) 
  */
 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -17,11 +20,10 @@
 #define REG_USBVBFIL_OFFSET0x08
 #define REG_USBPCR1_OFFSET 0x0c
 
-/* USBPCR */
+/*USB Parameter Control Register*/
 #define USBPCR_USB_MODEBIT(31)
 #define USBPCR_AVLD_REGBIT(30)
-#define USBPCR_INCRM   BIT(27)
-#define USBPCR_CLK12_ENBIT(26)
+#define USBPCR_INCR_MASK   BIT(27)
 #define USBPCR_COMMONONN   BIT(25)
 #define USBPCR_VBUSVLDEXT  BIT(24)
 #define USBPCR_VBUSVLDEXTSEL   BIT(23)
@@ -32,46 +34,80 @@
 
 #define USBPCR_IDPULLUP_LSB28
 #define USBPCR_IDPULLUP_MASK   GENMASK(29, USBPCR_IDPULLUP_LSB)
-#define USBPCR_IDPULLUP_ALWAYS (3 << USBPCR_IDPULLUP_LSB)
-#define USBPCR_IDPULLUP_SUSPEND(1 << USBPCR_IDPULLUP_LSB)
-#define USBPCR_IDPULLUP_OTG(0 << USBPCR_IDPULLUP_LSB)
+#define USBPCR_IDPULLUP_ALWAYS (0x2 << USBPCR_IDPULLUP_LSB)
+#define USBPCR_IDPULLUP_SUSPEND(0x1 << USBPCR_IDPULLUP_LSB)
+#define USBPCR_IDPULLUP_OTG(0x0 << USBPCR_IDPULLUP_LSB)
 
 #define USBPCR_COMPDISTUNE_LSB 17
 #define USBPCR_COMPDISTUNE_MASKGENMASK(19, USBPCR_COMPDISTUNE_LSB)
-#define USBPCR_COMPDISTUNE_DFT 4
+#define USBPCR_COMPDISTUNE_DFT (0x4 << USBPCR_COMPDISTUNE_LSB)
 
 #define USBPCR_OTGTUNE_LSB 14
 #define USBPCR_OTGTUNE_MASKGENMASK(16, USBPCR_OTGTUNE_LSB)
-#define USBPCR_OTGTUNE_DFT 4
+#define USBPCR_OTGTUNE_DFT (0x4 << USBPCR_OTGTUNE_LSB)
 
 #define USBPCR_SQRXTUNE_LSB11
 #define USBPCR_SQRXTUNE_MASK   GENMASK(13, USBPCR_SQRXTUNE_LSB)
-#define USBPCR_SQRXTUNE_DFT3
+#define USBPCR_SQRXTUNE_DCR_20PCT  (0x7 << USBPCR_SQRXTUNE_LSB)
+#define USBPCR_SQRXTUNE_DFT(0x3 << USBPCR_SQRXTUNE_LSB)
 
 #define USBPCR_TXFSLSTUNE_LSB  7
 #define USBPCR_TXFSLSTUNE_MASK GENMASK(10, USBPCR_TXFSLSTUNE_LSB)
-#define USBPCR_TXFSLSTUNE_DFT  3
+#define USBPCR_TXFSLSTUNE_DCR_50PPT(0xf << USBPCR_TXFSLSTUNE_LSB)
+#define USBPCR_TXFSLSTUNE_DCR_25PPT(0x7 << USBPCR_TXFSLSTUNE_LSB)
+#define USBPCR_TXFSLSTUNE_DFT  (0x3 << USBPCR_TXFSLSTUNE_LSB)
+#define USBPCR_TXFSLSTUNE_INC_25PPT(0x1 << USBPCR_TXFSLSTUNE_LSB)
+#define USBPCR_TXFSLSTUNE_INC_50PPT(0x0 << USBPCR_TXFSLSTUNE_LSB)
+
+#define USBPCR_TXHSXVTUNE_LSB  4
+#define USBPCR_TXHSXVTUNE_MASK GENMASK(5, USBPCR_TXHSXVTUNE_LSB)
+#define USBPCR_TXHSXVTUNE_DFT  (0x3 << USBPCR_TXHSXVTUNE_LSB)
+#define USBPCR_TXHSXVTUNE_DCR_15MV (0x1 << USBPCR_TXHSXVTUNE_LSB)
 
 #define USBPCR_TXRISETUNE_LSB  4
 #define USBPCR_TXRISETUNE_MASK GENMASK(5, USBPCR_TXRISETUNE_LSB)
-#define USBPCR_TXRISETUNE_DFT  3
+#define USBPCR_TXRISETUNE_DFT  (0x3 << USBPCR_TXRISETUNE_LSB)
 
 #define USBPCR_TXVREFTUNE_LSB  0
 #define USBPCR_TXVREFTUNE_MASK GENMASK(3, USBPCR_TXVREFTUNE_LSB)
-#define USBPCR_TXVREFTUNE_DFT  5
+#define USBPCR_TXVREFTUNE_INC_25PPT(0x7 << USBPCR_TXVREFTUNE_LSB)
+#define USBPCR_TXVREFTUNE_DFT  (0x5 << USBPCR_TXVREFTUNE_LSB)
 
-/* USBRDT */
+/*USB Reset Detect Timer Register*/
+#define USBRDT_UTMI_RSTBIT(27)
+#define USBRDT_HB_MASK BIT(26)
 #define USBRDT_VBFIL_LD_EN BIT(25)
 #define USBRDT_IDDIG_ENBIT(24)
 #define USBRDT_IDDIG_REG   BIT(23)
-
-#define USBRDT_USBRDT_LSB  0
-#define USBRDT_USBRDT_MASK GENMASK(22, USBRDT_USBRDT_LSB)
-
-/* USBPCR1 */
-#define USBPCR1_UHC_POWON  BIT(5)
+#define USBRDT_VBFIL_ENBIT(2)
+
+/*USB Parameter Contro

Re: [PATCH] ia64: Replace HTTP links with HTTPS ones

[Jonathan Corbet]

On Mon, 13 Jul 2020 16:10:36 +0200
"Alexander A. Klimov"  wrote:

> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index 1fa2fe2ef053..f21f121a8f42 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -223,7 +223,7 @@ config SMP
> will run faster if you say N here.
>  
> See also the SMP-HOWTO available at
> -   .
> +   .

No such HOWTO exists; far better to just delete this sentence entirely.

jon

Re: [PATCH v2] fpga: dfl: pci: add device id for Intel FPGA PAC N3000

[Tom Rix]

> @@ -64,6 +64,7 @@ static void cci_pci_free_irq(struct pci_dev *pcidev)
>  #define PCIE_DEVICE_ID_PF_INT_5_X0xBCBD
>  #define PCIE_DEVICE_ID_PF_INT_6_X0xBCC0
>  #define PCIE_DEVICE_ID_PF_DSC_1_X0x09C4
> +#define PCIE_DEVICE_ID_INTEL_PAC_N3000   0x0B30

My point about consistency.  These are all intel  and all should have their pf 
parts removed.

 #define PCIE_DEVICE_ID_INTEL_INT_5_X   0xBCBD
 #define PCIE_DEVICE_ID_INTEL_INT_6_X   0xBCC0
 #define PCIE_DEVICE_ID_INTEL_DSC_1_X   0x09C4

Let's revisit this for the d5005.

trix

[PATCH] Staging: vc04_services: Fix unsigned int warnings

[Baidyanath Kundu]

This patch fixes the checkpatch.pl warning:

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'

Signed-off-by: Baidyanath Kundu 
---
 .../staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c   | 4 ++--
 .../vc04_services/include/linux/raspberrypi/vchiq.h   | 8 
 .../vc04_services/interface/vchiq_arm/vchiq_core.c| 6 +++---
 drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 4 ++--
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
index 8c9ddd86fbbd..292fcee9d6f2 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
@@ -9,7 +9,7 @@
 
 struct bcm2835_audio_instance {
struct device *dev;
-   unsigned service_handle;
+   unsigned int service_handle;
struct completion msg_avail_comp;
struct mutex vchi_mutex;
struct bcm2835_alsa_stream *alsa_stream;
@@ -91,7 +91,7 @@ static int bcm2835_audio_send_simple(struct 
bcm2835_audio_instance *instance,
 
 static enum vchiq_status audio_vchi_callback(enum vchiq_reason reason,
 struct vchiq_header *header,
-unsigned handle, void *userdata)
+unsigned int handle, void 
*userdata)
 {
struct bcm2835_audio_instance *instance = 
vchiq_get_service_userdata(handle);
struct vc_audio_msg *m;
diff --git a/drivers/staging/vc04_services/include/linux/raspberrypi/vchiq.h 
b/drivers/staging/vc04_services/include/linux/raspberrypi/vchiq.h
index cb9ef9a4150b..18d63df368c4 100644
--- a/drivers/staging/vc04_services/include/linux/raspberrypi/vchiq.h
+++ b/drivers/staging/vc04_services/include/linux/raspberrypi/vchiq.h
@@ -84,11 +84,11 @@ extern enum vchiq_status vchiq_open_service(struct 
vchiq_instance *instance,
 extern enum vchiq_status vchiq_close_service(unsigned int service);
 extern enum vchiq_status vchiq_use_service(unsigned int service);
 extern enum vchiq_status vchiq_release_service(unsigned int service);
-extern void vchiq_msg_queue_push(unsigned handle, struct vchiq_header *header);
+extern void vchiq_msg_queue_push(unsigned int handle, struct vchiq_header 
*header);
 extern void   vchiq_release_message(unsigned int service,
struct vchiq_header *header);
-extern int vchiq_queue_kernel_message(unsigned handle, void *data,
- unsigned size);
+extern int vchiq_queue_kernel_message(unsigned int handle, void *data,
+ unsigned int size);
 extern enum vchiq_status vchiq_bulk_transmit(unsigned int service,
const void *data, unsigned int size, void *userdata,
enum vchiq_bulk_mode mode);
@@ -98,6 +98,6 @@ extern enum vchiq_status vchiq_bulk_receive(unsigned int 
service,
 extern void *vchiq_get_service_userdata(unsigned int service);
 extern enum vchiq_status vchiq_get_peer_version(unsigned int handle,
   short *peer_version);
-extern struct vchiq_header *vchiq_msg_hold(unsigned handle);
+extern struct vchiq_header *vchiq_msg_hold(unsigned int handle);
 
 #endif /* VCHIQ_H */
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 1bc4ce577614..af64cde82d36 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -2275,7 +2275,7 @@ vchiq_init_state(struct vchiq_state *state, struct 
vchiq_slot_zero *slot_zero)
return VCHIQ_ERROR;
 }
 
-void vchiq_msg_queue_push(unsigned handle, struct vchiq_header *header)
+void vchiq_msg_queue_push(unsigned int handle, struct vchiq_header *header)
 {
struct vchiq_service *service = find_service_by_handle(handle);
int pos;
@@ -2293,7 +2293,7 @@ void vchiq_msg_queue_push(unsigned handle, struct 
vchiq_header *header)
 }
 EXPORT_SYMBOL(vchiq_msg_queue_push);
 
-struct vchiq_header *vchiq_msg_hold(unsigned handle)
+struct vchiq_header *vchiq_msg_hold(unsigned int handle)
 {
struct vchiq_service *service = find_service_by_handle(handle);
struct vchiq_header *header;
@@ -3214,7 +3214,7 @@ vchiq_queue_message(unsigned int handle,
return status;
 }
 
-int vchiq_queue_kernel_message(unsigned handle, void *data, unsigned size)
+int vchiq_queue_kernel_message(unsigned int handle, void *data, unsigned int 
size)
 {
enum vchiq_status status;
 
diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c 
b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index a075cd63da7f..dc767730db43 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -163,7 +163,7 @@ struct mmal_msg_context {
 };
 
 struct vchiq_m

Re: [PATCH] mmc: sdio: Move SDIO IDs from rsi_sdio driver to common include file

[Kalle Valo]

Ulf Hansson  writes:

> On Mon, 29 Jun 2020 at 09:22, Pali Rohár  wrote:
>>
>> Define appropriate macro names for consistency with other macros.
>>
>> Signed-off-by: Pali Rohár 
>
> Applied for next, thanks!
>
> If it turns out that it's a better idea to funnel this via Kale's
> wireless tree, then I can drop it - and you may consider this as an
> ack instead.

I'm not expecting any conflicts with this so going via mmc tree is fine
with me.

Acked-by: Kalle Valo 

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v2 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

[Zhenyu Ye]

Hi Jon,

On 2020/7/13 22:27, Jon Hunter wrote:
> After this change I am seeing the following build errors ...
> 
> /tmp/cckzq3FT.s: Assembler messages:
> /tmp/cckzq3FT.s:854: Error: unknown or missing operation name at operand 1 -- 
> `tlbi rvae1is,x7'
> /tmp/cckzq3FT.s:870: Error: unknown or missing operation name at operand 1 -- 
> `tlbi rvae1is,x7'
> /tmp/cckzq3FT.s:1095: Error: unknown or missing operation name at operand 1 
> -- `tlbi rvae1is,x7'
> /tmp/cckzq3FT.s:: Error: unknown or missing operation name at operand 1 
> -- `tlbi rvae1is,x7'
> /tmp/cckzq3FT.s:1964: Error: unknown or missing operation name at operand 1 
> -- `tlbi rvae1is,x7'
> /tmp/cckzq3FT.s:1980: Error: unknown or missing operation name at operand 1 
> -- `tlbi rvae1is,x7'
> /tmp/cckzq3FT.s:2286: Error: unknown or missing operation name at operand 1 
> -- `tlbi rvae1is,x7'
> /tmp/cckzq3FT.s:2302: Error: unknown or missing operation name at operand 1 
> -- `tlbi rvae1is,x7'
> /tmp/cckzq3FT.s:4833: Error: unknown or missing operation name at operand 1 
> -- `tlbi rvae1is,x6'
> /tmp/cckzq3FT.s:4849: Error: unknown or missing operation name at operand 1 
> -- `tlbi rvae1is,x6'
> /tmp/cckzq3FT.s:5090: Error: unknown or missing operation name at operand 1 
> -- `tlbi rvae1is,x6'
> /tmp/cckzq3FT.s:5106: Error: unknown or missing operation name at operand 1 
> -- `tlbi rvae1is,x6'
> /tmp/cckzq3FT.s:874: Error: attempt to move .org backwards
> /tmp/cckzq3FT.s:1115: Error: attempt to move .org backwards
> /tmp/cckzq3FT.s:1984: Error: attempt to move .org backwards
> /tmp/cckzq3FT.s:2306: Error: attempt to move .org backwards
> /tmp/cckzq3FT.s:4853: Error: attempt to move .org backwards
> /tmp/cckzq3FT.s:5110: Error: attempt to move .org backwards
> scripts/Makefile.build:280: recipe for target 'arch/arm64/mm/hugetlbpage.o' 
> failed
> make[3]: *** [arch/arm64/mm/hugetlbpage.o] Error 1
> scripts/Makefile.build:497: recipe for target 'arch/arm64/mm' failed
> make[2]: *** [arch/arm64/mm] Error 2
> 
> Cheers
> Jon
> 

The code must be built with binutils >= 2.30.
Maybe I should add  a check on whether binutils supports ARMv8.4-a 
instructions...

Thanks,
Zhenyu

[PATCH] kobject: documentation: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 Documentation/core-api/kobject.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/core-api/kobject.rst 
b/Documentation/core-api/kobject.rst
index e93dc8cf52dd..2739f8b72575 100644
--- a/Documentation/core-api/kobject.rst
+++ b/Documentation/core-api/kobject.rst
@@ -6,7 +6,7 @@ Everything you never wanted to know about kobjects, ksets, and 
ktypes
 :Last updated: December 19, 2007
 
 Based on an original article by Jon Corbet for lwn.net written October 1,
-2003 and located at http://lwn.net/Articles/51437/
+2003 and located at https://lwn.net/Articles/51437/
 
 Part of the difficulty in understanding the driver model - and the kobject
 abstraction upon which it is built - is that there is no obvious starting
-- 
2.27.0

Re: [PATCH v1 0/2] ipw2x00: use generic power management

[Kalle Valo]

Vaibhav Gupta  writes:

> Linux Kernel Mentee: Remove Legacy Power Management.
>
> The purpose of this patch series is to remove legacy power management 
> callbacks
> from amd ethernet drivers.
>
> The callbacks performing suspend() and resume() operations are still calling
> pci_save_state(), pci_set_power_state(), etc. and handling the power 
> management
> themselves, which is not recommended.
>
> The conversion requires the removal of the those function calls and change the
> callback definition accordingly and make use of dev_pm_ops structure.
>
> All patches are compile-tested only.
>
> Vaibhav Gupta (2):
>   ipw2100: use generic power management
>   ipw2200: use generic power management
>
>  drivers/net/wireless/intel/ipw2x00/ipw2100.c | 31 +---
>  drivers/net/wireless/intel/ipw2x00/ipw2200.c | 30 +--

amd ethernet drivers? That must be a copy paste error. But no need to
resend because of this.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[PATCH v9 3/4] drm/bridge/sii8620: fix resource acquisition error handling

[Andrzej Hajda]

In case of error during resource acquisition driver should print error
message only in case it is not deferred probe, using dev_err_probe helper
solves the issue. Moreover it records defer probe reason for debugging.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 92acd336aa89..389c1f029774 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2299,10 +2299,9 @@ static int sii8620_probe(struct i2c_client *client,
INIT_LIST_HEAD(&ctx->mt_queue);
 
ctx->clk_xtal = devm_clk_get(dev, "xtal");
-   if (IS_ERR(ctx->clk_xtal)) {
-   dev_err(dev, "failed to get xtal clock from DT\n");
-   return PTR_ERR(ctx->clk_xtal);
-   }
+   if (IS_ERR(ctx->clk_xtal))
+   return dev_err_probe(dev, PTR_ERR(ctx->clk_xtal),
+"failed to get xtal clock from DT\n");
 
if (!client->irq) {
dev_err(dev, "no irq provided\n");
@@ -2313,16 +2312,14 @@ static int sii8620_probe(struct i2c_client *client,
sii8620_irq_thread,
IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
"sii8620", ctx);
-   if (ret < 0) {
-   dev_err(dev, "failed to install IRQ handler\n");
-   return ret;
-   }
+   if (ret < 0)
+   return dev_err_probe(dev, ret,
+"failed to install IRQ handler\n");
 
ctx->gpio_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
-   if (IS_ERR(ctx->gpio_reset)) {
-   dev_err(dev, "failed to get reset gpio from DT\n");
-   return PTR_ERR(ctx->gpio_reset);
-   }
+   if (IS_ERR(ctx->gpio_reset))
+   return dev_err_probe(dev, PTR_ERR(ctx->gpio_reset),
+"failed to get reset gpio from DT\n");
 
ctx->supplies[0].supply = "cvcc10";
ctx->supplies[1].supply = "iovcc18";
-- 
2.17.1

[PATCH v9 1/4] driver core: add device probe log helper

[Andrzej Hajda]

During probe every time driver gets resource it should usually check for
error printk some message if it is not -EPROBE_DEFER and return the error.
This pattern is simple but requires adding few lines after any resource
acquisition code, as a result it is often omitted or implemented only
partially.
dev_err_probe helps to replace such code sequences with simple call,
so code:
if (err != -EPROBE_DEFER)
dev_err(dev, ...);
return err;
becomes:
return dev_err_probe(dev, err, ...);

Signed-off-by: Andrzej Hajda 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Mark Brown 
---
 drivers/base/core.c| 42 ++
 include/linux/device.h |  3 +++
 2 files changed, 45 insertions(+)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 67d39a90b45c..3a827c82933f 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3953,6 +3953,48 @@ define_dev_printk_level(_dev_info, KERN_INFO);
 
 #endif
 
+/**
+ * dev_err_probe - probe error check and log helper
+ * @dev: the pointer to the struct device
+ * @err: error value to test
+ * @fmt: printf-style format string
+ * @...: arguments as specified in the format string
+ *
+ * This helper implements common pattern present in probe functions for error
+ * checking: print debug or error message depending if the error value is
+ * -EPROBE_DEFER and propagate error upwards.
+ * It replaces code sequence:
+ * if (err != -EPROBE_DEFER)
+ * dev_err(dev, ...);
+ * else
+ * dev_dbg(dev, ...);
+ * return err;
+ * with
+ * return dev_err_probe(dev, err, ...);
+ *
+ * Returns @err.
+ *
+ */
+int dev_err_probe(const struct device *dev, int err, const char *fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   va_start(args, fmt);
+   vaf.fmt = fmt;
+   vaf.va = &args;
+
+   if (err != -EPROBE_DEFER)
+   dev_err(dev, "error %d: %pV", err, &vaf);
+   else
+   dev_dbg(dev, "error %d: %pV", err, &vaf);
+
+   va_end(args);
+
+   return err;
+}
+EXPORT_SYMBOL_GPL(dev_err_probe);
+
 static inline bool fwnode_is_primary(struct fwnode_handle *fwnode)
 {
return fwnode && !IS_ERR(fwnode->secondary);
diff --git a/include/linux/device.h b/include/linux/device.h
index 15460a5ac024..6b2272ae9af8 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -964,6 +964,9 @@ void device_link_remove(void *consumer, struct device 
*supplier);
 void device_links_supplier_sync_state_pause(void);
 void device_links_supplier_sync_state_resume(void);
 
+extern __printf(3, 4)
+int dev_err_probe(const struct device *dev, int err, const char *fmt, ...);
+
 /* Create alias, so I can be autoloaded. */
 #define MODULE_ALIAS_CHARDEV(major,minor) \
MODULE_ALIAS("char-major-" __stringify(major) "-" __stringify(minor))
-- 
2.17.1

[PATCH v9 0/4] driver core: add probe error check helper

[Andrzej Hajda]

Hi All,

Thanks for comments.

Changes since v8:
- fixed typo in function name,
- removed cocci script (added by mistake)

Changes since v7:
- improved commit message
- added R-Bs

Changes since v6:
- removed leftovers from old naming scheme in commit descritions,
- added R-Bs.

Changes since v5:
- removed patch adding macro, dev_err_probe(dev, PTR_ERR(ptr), ...) should be 
used instead,
- added dev_dbg logging in case of -EPROBE_DEFER,
- renamed functions and vars according to comments,
- extended docs,
- cosmetics.

Original message (with small adjustments):

Recently I took some time to re-check error handling in drivers probe code,
and I have noticed that number of incorrect resource acquisition error handling
increased and there are no other propositions which can cure the situation.

So I have decided to resend my old proposition of probe_err helper which should
simplify resource acquisition error handling, it also extend it with adding 
defer
probe reason to devices_deferred debugfs property, which should improve 
debugging
experience for developers/testers.

I have also added two patches showing usage and benefits of the helper.

My dirty/ad-hoc cocci scripts shows that this helper can be used in at least 
2700 places
saving about 3500 lines of code.

Regards
Andrzej


Andrzej Hajda (4):
  driver core: add device probe log helper
  driver core: add deferring probe reason to devices_deferred property
  drm/bridge/sii8620: fix resource acquisition error handling
  drm/bridge: lvds-codec: simplify error handling

 drivers/base/base.h  |  3 ++
 drivers/base/core.c  | 46 
 drivers/base/dd.c| 23 +-
 drivers/gpu/drm/bridge/lvds-codec.c  | 10 ++
 drivers/gpu/drm/bridge/sil-sii8620.c | 21 ++---
 include/linux/device.h   |  3 ++
 6 files changed, 86 insertions(+), 20 deletions(-)

-- 
2.17.1

[PATCH v9 2/4] driver core: add deferring probe reason to devices_deferred property

[Andrzej Hajda]

/sys/kernel/debug/devices_deferred property contains list of deferred devices.
This list does not contain reason why the driver deferred probe, the patch
improves it.
The natural place to set the reason is dev_err_probe function introduced
recently, ie. if dev_err_probe will be called with -EPROBE_DEFER instead of
printk the message will be attached to a deferred device and printed when user
reads devices_deferred property.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Mark Brown 
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Rafael J. Wysocki 
---
v9:
- fixed typo in function name
v8:
- improved commit message
---
 drivers/base/base.h |  3 +++
 drivers/base/core.c |  8 ++--
 drivers/base/dd.c   | 23 ++-
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/base/base.h b/drivers/base/base.h
index 95c22c0f9036..c3562adf4789 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -93,6 +93,7 @@ struct device_private {
struct klist_node knode_class;
struct list_head deferred_probe;
struct device_driver *async_driver;
+   char *deferred_probe_reason;
struct device *device;
u8 dead:1;
 };
@@ -134,6 +135,8 @@ extern void device_release_driver_internal(struct device 
*dev,
 extern void driver_detach(struct device_driver *drv);
 extern int driver_probe_device(struct device_driver *drv, struct device *dev);
 extern void driver_deferred_probe_del(struct device *dev);
+extern void device_set_deferred_probe_reason(const struct device *dev,
+struct va_format *vaf);
 static inline int driver_match_device(struct device_driver *drv,
  struct device *dev)
 {
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 3a827c82933f..d04d19458795 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3963,6 +3963,8 @@ define_dev_printk_level(_dev_info, KERN_INFO);
  * This helper implements common pattern present in probe functions for error
  * checking: print debug or error message depending if the error value is
  * -EPROBE_DEFER and propagate error upwards.
+ * In case of -EPROBE_DEFER it sets also defer probe reason, which can be
+ * checked later by reading devices_deferred debugfs attribute.
  * It replaces code sequence:
  * if (err != -EPROBE_DEFER)
  * dev_err(dev, ...);
@@ -3984,10 +3986,12 @@ int dev_err_probe(const struct device *dev, int err, 
const char *fmt, ...)
vaf.fmt = fmt;
vaf.va = &args;
 
-   if (err != -EPROBE_DEFER)
+   if (err != -EPROBE_DEFER) {
dev_err(dev, "error %d: %pV", err, &vaf);
-   else
+   } else {
+   device_set_deferred_probe_reason(dev, &vaf);
dev_dbg(dev, "error %d: %pV", err, &vaf);
+   }
 
va_end(args);
 
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9a1d940342ac..7555b31bdfdc 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "base.h"
 #include "power/power.h"
@@ -136,6 +137,8 @@ void driver_deferred_probe_del(struct device *dev)
if (!list_empty(&dev->p->deferred_probe)) {
dev_dbg(dev, "Removed from deferred list\n");
list_del_init(&dev->p->deferred_probe);
+   kfree(dev->p->deferred_probe_reason);
+   dev->p->deferred_probe_reason = NULL;
}
mutex_unlock(&deferred_probe_mutex);
 }
@@ -211,6 +214,23 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
 }
 
+/**
+ * device_set_deferred_probe_reason() - Set defer probe reason message for 
device
+ * @dev: the pointer to the struct device
+ * @vaf: the pointer to va_format structure with message
+ */
+void device_set_deferred_probe_reason(const struct device *dev, struct 
va_format *vaf)
+{
+   const char *drv = dev_driver_string(dev);
+
+   mutex_lock(&deferred_probe_mutex);
+
+   kfree(dev->p->deferred_probe_reason);
+   dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s: %pV", drv, 
vaf);
+
+   mutex_unlock(&deferred_probe_mutex);
+}
+
 /*
  * deferred_devs_show() - Show the devices in the deferred probe pending list.
  */
@@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s, void 
*data)
mutex_lock(&deferred_probe_mutex);
 
list_for_each_entry(curr, &deferred_probe_pending_list, deferred_probe)
-   seq_printf(s, "%s\n", dev_name(curr->device));
+   seq_printf(s, "%s\t%s", dev_name(curr->device),
+  curr->device->p->deferred_probe_reason ?: "\n");
 
mutex_unlock(&deferred_probe_mutex);
 
-- 
2.17.1

[PATCH v9 4/4] drm/bridge: lvds-codec: simplify error handling

[Andrzej Hajda]

Using dev_err_probe code has following advantages:
- shorter code,
- recorded defer probe reason for debugging,
- uniform error code logging.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/lvds-codec.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/lvds-codec.c 
b/drivers/gpu/drm/bridge/lvds-codec.c
index 24fb1befdfa2..f19d9f7a5db2 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -71,13 +71,9 @@ static int lvds_codec_probe(struct platform_device *pdev)
lvds_codec->connector_type = (uintptr_t)of_device_get_match_data(dev);
lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
 GPIOD_OUT_HIGH);
-   if (IS_ERR(lvds_codec->powerdown_gpio)) {
-   int err = PTR_ERR(lvds_codec->powerdown_gpio);
-
-   if (err != -EPROBE_DEFER)
-   dev_err(dev, "powerdown GPIO failure: %d\n", err);
-   return err;
-   }
+   if (IS_ERR(lvds_codec->powerdown_gpio))
+   return dev_err_probe(dev, PTR_ERR(lvds_codec->powerdown_gpio),
+"powerdown GPIO failure\n");
 
/* Locate the panel DT node. */
panel_node = of_graph_get_remote_node(dev->of_node, 1, 0);
-- 
2.17.1

Re: [PATCH v2 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

[Jon Hunter]

On 13/07/2020 15:39, Zhenyu Ye wrote:
> Hi Jon,
> 
> On 2020/7/13 22:27, Jon Hunter wrote:
>> After this change I am seeing the following build errors ...
>>
>> /tmp/cckzq3FT.s: Assembler messages:
>> /tmp/cckzq3FT.s:854: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x7'
>> /tmp/cckzq3FT.s:870: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x7'
>> /tmp/cckzq3FT.s:1095: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x7'
>> /tmp/cckzq3FT.s:: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x7'
>> /tmp/cckzq3FT.s:1964: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x7'
>> /tmp/cckzq3FT.s:1980: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x7'
>> /tmp/cckzq3FT.s:2286: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x7'
>> /tmp/cckzq3FT.s:2302: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x7'
>> /tmp/cckzq3FT.s:4833: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x6'
>> /tmp/cckzq3FT.s:4849: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x6'
>> /tmp/cckzq3FT.s:5090: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x6'
>> /tmp/cckzq3FT.s:5106: Error: unknown or missing operation name at operand 1 
>> -- `tlbi rvae1is,x6'
>> /tmp/cckzq3FT.s:874: Error: attempt to move .org backwards
>> /tmp/cckzq3FT.s:1115: Error: attempt to move .org backwards
>> /tmp/cckzq3FT.s:1984: Error: attempt to move .org backwards
>> /tmp/cckzq3FT.s:2306: Error: attempt to move .org backwards
>> /tmp/cckzq3FT.s:4853: Error: attempt to move .org backwards
>> /tmp/cckzq3FT.s:5110: Error: attempt to move .org backwards
>> scripts/Makefile.build:280: recipe for target 'arch/arm64/mm/hugetlbpage.o' 
>> failed
>> make[3]: *** [arch/arm64/mm/hugetlbpage.o] Error 1
>> scripts/Makefile.build:497: recipe for target 'arch/arm64/mm' failed
>> make[2]: *** [arch/arm64/mm] Error 2
>>
>> Cheers
>> Jon
>>
> 
> The code must be built with binutils >= 2.30.
> Maybe I should add  a check on whether binutils supports ARMv8.4-a 
> instructions...

Yes I believe so.

Cheers
Jon

-- 
nvpublic

Re: [v5] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings

[Rob Herring]

On Fri, 10 Jul 2020 19:27:49 +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for the device tree bindings for the same.
> 
> Signed-off-by: Krishna Manikandan 
> 
> Changes in v2:
>   - Changed dpu to DPU (Sam Ravnborg)
>   - Fixed indentation issues (Sam Ravnborg)
>   - Added empty line between different properties (Sam Ravnborg)
>   - Replaced reference txt files with  their corresponding
> yaml files (Sam Ravnborg)
>   - Modified the file to use "|" only when it is
> necessary (Sam Ravnborg)
> 
> Changes in v3:
>   - Corrected the license used (Rob Herring)
>   - Added maxItems for properties (Rob Herring)
>   - Dropped generic descriptions (Rob Herring)
>   - Added ranges property (Rob Herring)
>   - Corrected the indendation (Rob Herring)
>   - Added additionalProperties (Rob Herring)
>   - Split dsi file into two, one for dsi controller
> and another one for dsi phy per target (Rob Herring)
>   - Corrected description for pinctrl-names (Rob Herring)
>   - Corrected the examples used in yaml file (Rob Herring)
>   - Delete dsi.txt and dpu.txt (Rob Herring)
> 
> Changes in v4:
>   - Move schema up by one level (Rob Herring)
>   - Add patternProperties for mdp node (Rob Herring)
>   - Corrected description of some properties (Rob Herring)
> 
> Changes in v5:
>   - Correct the indentation (Rob Herring)
>   - Remove unnecessary description from properties (Rob Herring)
>   - Correct the number of interconnect entries (Rob Herring)
>   - Add interconnect names for sc7180 (Rob Herring)
>   - Add description for ports (Rob Herring)
>   - Remove common properties (Rob Herring)
>   - Add unevalutatedProperties (Rob Herring)
>   - Reference existing dsi controller yaml in the common
> dsi controller file (Rob Herring)
>   - Correct the description of clock names to include only the
> clocks that are required (Rob Herring)
>   - Remove properties which are already covered under the common
> binding (Rob Herring)
>   - Add dsi phy supply nodes which are required for sc7180 and
> sdm845 targets (Rob Herring)
>   - Add type ref for syscon-sfpb (Rob Herring)
> ---
>  .../bindings/display/dsi-controller.yaml   |   4 +-
>  .../bindings/display/msm/dpu-sc7180.yaml   | 230 +++
>  .../bindings/display/msm/dpu-sdm845.yaml   | 210 ++
>  .../devicetree/bindings/display/msm/dpu.txt| 141 
>  .../display/msm/dsi-common-controller.yaml | 178 +++
>  .../display/msm/dsi-controller-sc7180.yaml | 115 ++
>  .../display/msm/dsi-controller-sdm845.yaml | 115 ++
>  .../bindings/display/msm/dsi-phy-sc7180.yaml   |  79 +++
>  .../bindings/display/msm/dsi-phy-sdm845.yaml   |  81 +++
>  .../devicetree/bindings/display/msm/dsi-phy.yaml   |  79 +++
>  .../devicetree/bindings/display/msm/dsi.txt| 246 
> -
>  11 files changed, 1089 insertions(+), 389 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
>  delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-common-controller.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-controller-sdm845.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-phy-sdm845.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy.yaml
>  delete mode 100644 Documentation/devicetree/bindings/display/msm/dsi.txt
> 


My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.example.dt.yaml:
 example-0: dsi@ae94000:reg:0: [0, 183058432, 0, 1024] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dpu-sdm845.example.dt.yaml:
 example-0: mdss@ae0:reg:0: [0, 182452224, 0, 4096] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.example.dt.yaml:
 example-0: dsi-phy@ae94400:reg:0: [0, 183059456, 0, 512] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.example.dt.yaml:
 example-0: dsi-phy@ae94400:reg:1: [0, 183059968, 0, 640] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/d

[PATCH 3/3] habanalabs: update hl_boot_if.h from firmware

[Oded Gabbay]

Update the boot interface file from the latest version from firmware.
Defines for secure boot were added.

Signed-off-by: Oded Gabbay 
---
 .../misc/habanalabs/include/common/hl_boot_if.h| 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/misc/habanalabs/include/common/hl_boot_if.h 
b/drivers/misc/habanalabs/include/common/hl_boot_if.h
index c22d134e73af..bb67cafc6e00 100644
--- a/drivers/misc/habanalabs/include/common/hl_boot_if.h
+++ b/drivers/misc/habanalabs/include/common/hl_boot_if.h
@@ -44,6 +44,15 @@
  * The NIC FW loading and initialization
  * failed. This means NICs are not usable.
  *
+ * CPU_BOOT_ERR0_SECURITY_NOT_RDY  Chip security initialization has been
+ * started, but is not ready yet - chip
+ * cannot be accessed.
+ *
+ * CPU_BOOT_ERR0_SECURITY_FAIL Security related tasks have failed.
+ * The tasks are security init (root of
+ * trust), boot authentication (chain of
+ * trust), data packets authentication.
+ *
  * CPU_BOOT_ERR0_ENABLED   Error registers enabled.
  * This is a main indication that the
  * running FW populates the error
@@ -57,6 +66,8 @@
 #define CPU_BOOT_ERR0_BMC_WAIT_SKIPPED (1 << 4)
 #define CPU_BOOT_ERR0_NIC_DATA_NOT_RDY (1 << 5)
 #define CPU_BOOT_ERR0_NIC_FW_FAIL  (1 << 6)
+#define CPU_BOOT_ERR0_SECURITY_NOT_RDY (1 << 7)
+#define CPU_BOOT_ERR0_SECURITY_FAIL(1 << 8)
 #define CPU_BOOT_ERR0_ENABLED  (1 << 31)
 
 enum cpu_boot_status {
@@ -79,7 +90,10 @@ enum cpu_boot_status {
CPU_BOOT_STATUS_BMC_WAITING_SKIPPED, /* deprecated - will be removed */
/* Last boot loader progress status, ready to receive commands */
CPU_BOOT_STATUS_READY_TO_BOOT = 15,
+   /* Internal Boot finished, ready for boot-fit */
CPU_BOOT_STATUS_WAITING_FOR_BOOT_FIT = 16,
+   /* Internal Security has been initialized, device can be accessed */
+   CPU_BOOT_STATUS_SECURITY_READY = 17,
 };
 
 enum kmd_msg {
-- 
2.17.1

[PATCH 2/3] habanalabs: create common folder

[Oded Gabbay]

For internal needs of our CI we need to move all the common code into a
common folder instead of putting them in the root folder of the driver.

Same applies to the common header files under include/

Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/Makefile  | 11 +--
 drivers/misc/habanalabs/common/Makefile   |  9 +
 drivers/misc/habanalabs/{ => common}/asid.c   |  0
 drivers/misc/habanalabs/{ => common}/command_buffer.c |  0
 .../misc/habanalabs/{ => common}/command_submission.c |  0
 drivers/misc/habanalabs/{ => common}/context.c|  0
 drivers/misc/habanalabs/{ => common}/debugfs.c|  0
 drivers/misc/habanalabs/{ => common}/device.c |  0
 drivers/misc/habanalabs/{ => common}/firmware_if.c|  2 +-
 drivers/misc/habanalabs/{ => common}/habanalabs.h |  4 ++--
 drivers/misc/habanalabs/{ => common}/habanalabs_drv.c |  0
 .../misc/habanalabs/{ => common}/habanalabs_ioctl.c   |  0
 drivers/misc/habanalabs/{ => common}/hl_dma_fence.c   |  0
 drivers/misc/habanalabs/{ => common}/hl_dma_fence.h   |  0
 drivers/misc/habanalabs/{ => common}/hw_queue.c   |  0
 drivers/misc/habanalabs/{ => common}/hwmon.c  |  0
 drivers/misc/habanalabs/{ => common}/irq.c|  0
 drivers/misc/habanalabs/{ => common}/memory.c |  0
 drivers/misc/habanalabs/{ => common}/mmu.c|  0
 drivers/misc/habanalabs/{ => common}/pci.c|  0
 drivers/misc/habanalabs/{ => common}/sysfs.c  |  0
 drivers/misc/habanalabs/gaudi/Makefile|  2 +-
 drivers/misc/habanalabs/gaudi/gaudiP.h|  2 +-
 drivers/misc/habanalabs/goya/goyaP.h  |  2 +-
 .../misc/habanalabs/include/{ => common}/armcp_if.h   |  0
 .../misc/habanalabs/include/{ => common}/hl_boot_if.h |  0
 .../misc/habanalabs/include/{ => common}/qman_if.h|  0
 27 files changed, 20 insertions(+), 12 deletions(-)
 create mode 100644 drivers/misc/habanalabs/common/Makefile
 rename drivers/misc/habanalabs/{ => common}/asid.c (100%)
 rename drivers/misc/habanalabs/{ => common}/command_buffer.c (100%)
 rename drivers/misc/habanalabs/{ => common}/command_submission.c (100%)
 rename drivers/misc/habanalabs/{ => common}/context.c (100%)
 rename drivers/misc/habanalabs/{ => common}/debugfs.c (100%)
 rename drivers/misc/habanalabs/{ => common}/device.c (100%)
 rename drivers/misc/habanalabs/{ => common}/firmware_if.c (99%)
 rename drivers/misc/habanalabs/{ => common}/habanalabs.h (99%)
 rename drivers/misc/habanalabs/{ => common}/habanalabs_drv.c (100%)
 rename drivers/misc/habanalabs/{ => common}/habanalabs_ioctl.c (100%)
 rename drivers/misc/habanalabs/{ => common}/hl_dma_fence.c (100%)
 rename drivers/misc/habanalabs/{ => common}/hl_dma_fence.h (100%)
 rename drivers/misc/habanalabs/{ => common}/hw_queue.c (100%)
 rename drivers/misc/habanalabs/{ => common}/hwmon.c (100%)
 rename drivers/misc/habanalabs/{ => common}/irq.c (100%)
 rename drivers/misc/habanalabs/{ => common}/memory.c (100%)
 rename drivers/misc/habanalabs/{ => common}/mmu.c (100%)
 rename drivers/misc/habanalabs/{ => common}/pci.c (100%)
 rename drivers/misc/habanalabs/{ => common}/sysfs.c (100%)
 rename drivers/misc/habanalabs/include/{ => common}/armcp_if.h (100%)
 rename drivers/misc/habanalabs/include/{ => common}/hl_boot_if.h (100%)
 rename drivers/misc/habanalabs/include/{ => common}/qman_if.h (100%)

diff --git a/drivers/misc/habanalabs/Makefile b/drivers/misc/habanalabs/Makefile
index 83b0e9ac35d6..a786c0a7de9a 100644
--- a/drivers/misc/habanalabs/Makefile
+++ b/drivers/misc/habanalabs/Makefile
@@ -3,16 +3,15 @@
 # Makefile for HabanaLabs AI accelerators driver
 #
 
-obj-m  := habanalabs.o
+obj-$(CONFIG_HABANA_AI) := habanalabs.o
 
-habanalabs-y := habanalabs_drv.o device.o context.o asid.o habanalabs_ioctl.o \
-   command_buffer.o hw_queue.o irq.o sysfs.o hwmon.o memory.o \
-   command_submission.o mmu.o firmware_if.o pci.o hl_dma_fence.o
-
-habanalabs-$(CONFIG_DEBUG_FS) += debugfs.o
+include $(src)/common/Makefile
+habanalabs-y += $(HL_COMMON_FILES)
 
 include $(src)/goya/Makefile
 habanalabs-y += $(HL_GOYA_FILES)
 
 include $(src)/gaudi/Makefile
 habanalabs-y += $(HL_GAUDI_FILES)
+
+habanalabs-$(CONFIG_DEBUG_FS) += common/debugfs.o
diff --git a/drivers/misc/habanalabs/common/Makefile 
b/drivers/misc/habanalabs/common/Makefile
new file mode 100644
index ..1e149f5852c6
--- /dev/null
+++ b/drivers/misc/habanalabs/common/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0-only
+subdir-ccflags-y += -I$(src)/common
+
+HL_COMMON_FILES := common/habanalabs_drv.o common/device.o common/context.o \
+   common/asid.o common/habanalabs_ioctl.o \
+   common/command_buffer.o common/hw_queue.o common/irq.o \
+   common/sysfs.o common/hwmon.o common/memory.o \
+   common/command_submission.o common/mmu.o common/firmware_if.o \
+   common/pci.o common/

[PATCH 1/3] habanalabs: implement dma-fence mechanism

[Oded Gabbay]

From: Ofir Bitton 

Instead of using standard dma-fence mechanism designed for GPU's, we
introduce our own implementation based on the former one. This
implementation is much more sparse than the original, contains only
mandatory functionality required by the driver.

Signed-off-by: Ofir Bitton 
Cc: Greg Kroah-Hartman 
Cc: Daniel Vetter 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/Makefile |   2 +-
 drivers/misc/habanalabs/command_submission.c | 120 ++-
 drivers/misc/habanalabs/context.c|  10 +-
 drivers/misc/habanalabs/habanalabs.h |  12 +-
 drivers/misc/habanalabs/hl_dma_fence.c   | 338 +++
 drivers/misc/habanalabs/hl_dma_fence.h   | 148 
 drivers/misc/habanalabs/hw_queue.c   |   2 +-
 7 files changed, 519 insertions(+), 113 deletions(-)
 create mode 100644 drivers/misc/habanalabs/hl_dma_fence.c
 create mode 100644 drivers/misc/habanalabs/hl_dma_fence.h

diff --git a/drivers/misc/habanalabs/Makefile b/drivers/misc/habanalabs/Makefile
index 421ebd903069..83b0e9ac35d6 100644
--- a/drivers/misc/habanalabs/Makefile
+++ b/drivers/misc/habanalabs/Makefile
@@ -7,7 +7,7 @@ obj-m   := habanalabs.o
 
 habanalabs-y := habanalabs_drv.o device.o context.o asid.o habanalabs_ioctl.o \
command_buffer.o hw_queue.o irq.o sysfs.o hwmon.o memory.o \
-   command_submission.o mmu.o firmware_if.o pci.o
+   command_submission.o mmu.o firmware_if.o pci.o hl_dma_fence.o
 
 habanalabs-$(CONFIG_DEBUG_FS) += debugfs.o
 
diff --git a/drivers/misc/habanalabs/command_submission.c 
b/drivers/misc/habanalabs/command_submission.c
index 54f2f5afdd2a..a3d9223424c6 100644
--- a/drivers/misc/habanalabs/command_submission.c
+++ b/drivers/misc/habanalabs/command_submission.c
@@ -18,15 +18,6 @@ static long _hl_cs_wait_ioctl(struct hl_device *hdev,
struct hl_ctx *ctx, u64 timeout_us, u64 seq);
 static void cs_do_release(struct kref *ref);
 
-static void hl_sob_reset(struct kref *ref)
-{
-   struct hl_hw_sob *hw_sob = container_of(ref, struct hl_hw_sob,
-   kref);
-   struct hl_device *hdev = hw_sob->hdev;
-
-   hdev->asic_funcs->reset_sob(hdev, hw_sob);
-}
-
 void hl_sob_reset_error(struct kref *ref)
 {
struct hl_hw_sob *hw_sob = container_of(ref, struct hl_hw_sob,
@@ -38,77 +29,6 @@ void hl_sob_reset_error(struct kref *ref)
hw_sob->q_idx, hw_sob->sob_id);
 }
 
-static const char *hl_fence_get_driver_name(struct dma_fence *fence)
-{
-   return "HabanaLabs";
-}
-
-static const char *hl_fence_get_timeline_name(struct dma_fence *fence)
-{
-   struct hl_cs_compl *hl_cs_compl =
-   container_of(fence, struct hl_cs_compl, base_fence);
-
-   return dev_name(hl_cs_compl->hdev->dev);
-}
-
-static bool hl_fence_enable_signaling(struct dma_fence *fence)
-{
-   return true;
-}
-
-static void hl_fence_release(struct dma_fence *fence)
-{
-   struct hl_cs_compl *hl_cs_cmpl =
-   container_of(fence, struct hl_cs_compl, base_fence);
-   struct hl_device *hdev = hl_cs_cmpl->hdev;
-
-   /* EBUSY means the CS was never submitted and hence we don't have
-* an attached hw_sob object that we should handle here
-*/
-   if (fence->error == -EBUSY)
-   goto free;
-
-   if ((hl_cs_cmpl->type == CS_TYPE_SIGNAL) ||
-   (hl_cs_cmpl->type == CS_TYPE_WAIT)) {
-
-   dev_dbg(hdev->dev,
-   "CS 0x%llx type %d finished, sob_id: %d, sob_val: 
0x%x\n",
-   hl_cs_cmpl->cs_seq,
-   hl_cs_cmpl->type,
-   hl_cs_cmpl->hw_sob->sob_id,
-   hl_cs_cmpl->sob_val);
-
-   /*
-* A signal CS can get completion while the corresponding wait
-* for signal CS is on its way to the PQ. The wait for signal CS
-* will get stuck if the signal CS incremented the SOB to its
-* max value and there are no pending (submitted) waits on this
-* SOB.
-* We do the following to void this situation:
-* 1. The wait for signal CS must get a ref for the signal CS as
-*soon as possible in cs_ioctl_signal_wait() and put it
-*before being submitted to the PQ but after it incremented
-*the SOB refcnt in init_signal_wait_cs().
-* 2. Signal/Wait for signal CS will decrement the SOB refcnt
-*here.
-* These two measures guarantee that the wait for signal CS will
-* reset the SOB upon completion rather than the signal CS and
-* hence the above scenario is avoided.
-*/
-   kref_put(&hl_cs_cmpl->hw_sob->kref, hl_sob_reset);
-   }
-
-free:
-   kfree_rcu(hl

[PATCH 16/25] arch: arm: mach-at91: pm: Move prototypes to mutually included header

[Lee Jones]

Both the caller and the supplier's source file should have access to
the include file containing the prototypes.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/pinctrl-at91.c:1637:6: warning: no previous prototype for 
‘at91_pinctrl_gpio_suspend’ [-Wmissing-prototypes]
 1637 | void at91_pinctrl_gpio_suspend(void)
 | ^
 drivers/pinctrl/pinctrl-at91.c:1661:6: warning: no previous prototype for 
‘at91_pinctrl_gpio_resume’ [-Wmissing-prototypes]
 1661 | void at91_pinctrl_gpio_resume(void)
 | ^~~~

Cc: Russell King 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Ludovic Desroches 
Signed-off-by: Lee Jones 
---
 arch/arm/mach-at91/pm.c | 17 ++---
 drivers/pinctrl/pinctrl-at91.c  |  1 +
 include/linux/platform_data/atmel.h |  5 +
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 074bde64064e4..59f2a2d6fbbb8 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -25,17 +25,6 @@
 #include "generic.h"
 #include "pm.h"
 
-/*
- * FIXME: this is needed to communicate between the pinctrl driver and
- * the PM implementation in the machine. Possibly part of the PM
- * implementation should be moved down into the pinctrl driver and get
- * called as part of the generic suspend/resume path.
- */
-#ifdef CONFIG_PINCTRL_AT91
-extern void at91_pinctrl_gpio_suspend(void);
-extern void at91_pinctrl_gpio_resume(void);
-#endif
-
 struct at91_soc_pm {
int (*config_shdwc_ws)(void __iomem *shdwc, u32 *mode, u32 *polarity);
int (*config_pmc_ws)(void __iomem *pmc, u32 mode, u32 polarity);
@@ -325,6 +314,12 @@ static void at91_pm_suspend(suspend_state_t state)
 static int at91_pm_enter(suspend_state_t state)
 {
 #ifdef CONFIG_PINCTRL_AT91
+   /*
+* FIXME: this is needed to communicate between the pinctrl driver and
+* the PM implementation in the machine. Possibly part of the PM
+* implementation should be moved down into the pinctrl driver and get
+* called as part of the generic suspend/resume path.
+*/
at91_pinctrl_gpio_suspend();
 #endif
 
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 9c52130876597..37997e5ab0538 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -22,6 +22,7 @@
 #include 
 /* Since we request GPIOs from ourself */
 #include 
+#include 
 
 #include "pinctrl-at91.h"
 #include "core.h"
diff --git a/include/linux/platform_data/atmel.h 
b/include/linux/platform_data/atmel.h
index 99e6069c5fd89..666ef482ea8c0 100644
--- a/include/linux/platform_data/atmel.h
+++ b/include/linux/platform_data/atmel.h
@@ -28,4 +28,9 @@ static inline int at91_suspend_entering_slow_clock(void)
 }
 #endif
 
+#ifdef CONFIG_PINCTRL_AT91
+void at91_pinctrl_gpio_suspend(void);
+void at91_pinctrl_gpio_resume(void);
+#endif
+
 #endif /* __ATMEL_H__ */
-- 
2.25.1

[PATCH 02/25] pinctrl: sirf: pinctrl-atlas7: Fix a bunch of documentation misdemeanours

[Lee Jones]

>From ill formatted kerneldoc, to incomplete *and* incorrect struct headers,
through to formatting issues and missing attribute descriptions.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/sirf/pinctrl-atlas7.c:197: warning: Function parameter or 
member 'id' not described in 'atlas7_pad_config'
 drivers/pinctrl/sirf/pinctrl-atlas7.c:221: warning: Function parameter or 
member 'func' not described in 'atlas7_pad_status'
 drivers/pinctrl/sirf/pinctrl-atlas7.c:221: warning: Function parameter or 
member 'pull' not described in 'atlas7_pad_status'
 drivers/pinctrl/sirf/pinctrl-atlas7.c:221: warning: Function parameter or 
member 'dstr' not described in 'atlas7_pad_status'
 drivers/pinctrl/sirf/pinctrl-atlas7.c:221: warning: Function parameter or 
member 'reserved' not described in 'atlas7_pad_status'
 drivers/pinctrl/sirf/pinctrl-atlas7.c:359: warning: Cannot understand  * @dev: 
a pointer back to containing device
 on line 359 - I thought it was a doc line
 drivers/pinctrl/sirf/pinctrl-atlas7.c:4794: warning: Function parameter or 
member 'pad_type' not described in 'atlas7_pull_info'
 drivers/pinctrl/sirf/pinctrl-atlas7.c:4917: warning: Function parameter or 
member 'reserved' not described in 'atlas7_ds_info'
 drivers/pinctrl/sirf/pinctrl-atlas7.c:5617: warning: Function parameter or 
member 'a7gc' not described in 'atlas7_gpio_to_bank'
 drivers/pinctrl/sirf/pinctrl-atlas7.c:5617: warning: Function parameter or 
member 'gpio' not described in 'atlas7_gpio_to_bank'

Cc: Barry Song 
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/sirf/pinctrl-atlas7.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/pinctrl/sirf/pinctrl-atlas7.c 
b/drivers/pinctrl/sirf/pinctrl-atlas7.c
index 50df9e0844142..e54a6e3cafd23 100644
--- a/drivers/pinctrl/sirf/pinctrl-atlas7.c
+++ b/drivers/pinctrl/sirf/pinctrl-atlas7.c
@@ -169,7 +169,7 @@ struct dt_params {
 
 /**
  * struct atlas7_pad_conf - Atlas7 Pad Configuration
- * @id The ID of this Pad.
+ * @id:The ID of this Pad.
  * @type:  The type of this Pad.
  * @mux_reg:   The mux register offset.
  * This register contains the mux.
@@ -210,7 +210,7 @@ struct atlas7_pad_config {
.ad_ctrl_bit = adb, \
}
 
-/**
+/*
  * struct atlas7_pad_status - Atlas7 Pad status
  */
 struct atlas7_pad_status {
@@ -355,10 +355,6 @@ struct atlas7_gpio_chip {
struct atlas7_gpio_bank banks[];
 };
 
-/**
- * @dev: a pointer back to containing device
- * @virtbase: the offset to the controller in virtual memory
- */
 struct atlas7_pmx {
struct device *dev;
struct pinctrl_dev *pctl;
@@ -376,7 +372,7 @@ struct atlas7_pmx {
  * refer to A7DA IO Summary - CS-314158-DD-4E.xls
  */
 
-/*Pads in IOC RTC & TOP */
+/* Pads in IOC RTC & TOP */
 static const struct pinctrl_pin_desc atlas7_ioc_pads[] = {
/* RTC PADs */
PINCTRL_PIN(0, "rtc_gpio_0"),
@@ -4781,10 +4777,10 @@ struct map_data {
 
 /**
  * struct atlas7_pull_info - Atlas7 Pad pull info
- * @type:The type of this Pad.
- * @mask:The mas value of this pin's pull bits.
- * @v2s: The map of pull register value to pull status.
- * @s2v: The map of pull status to pull register value.
+ * @pad_type:  The type of this Pad.
+ * @mask:  The mas value of this pin's pull bits.
+ * @v2s:   The map of pull register value to pull status.
+ * @s2v:   The map of pull status to pull register value.
  */
 struct atlas7_pull_info {
u8 pad_type;
@@ -4908,6 +4904,7 @@ static const struct atlas7_ds_ma_info atlas7_ma2ds_map[] 
= {
  * @type:  The type of this Pad.
  * @mask:  The mask value of this pin's pull bits.
  * @imval: The immediate value of drives trength register.
+ * @reserved:  Reserved space
  */
 struct atlas7_ds_info {
u8 type;
@@ -5609,7 +5606,7 @@ static int __init atlas7_pinmux_init(void)
 arch_initcall(atlas7_pinmux_init);
 
 
-/**
+/*
  * The Following is GPIO Code
  */
 static inline struct
-- 
2.25.1

[PATCH 06/25] pinctrl: samsung: pinctrl-samsung: Demote obvious misuse of kerneldoc to standard comment blocks

[Lee Jones]

No attempt has been made to document either of the demoted functions here.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/samsung/pinctrl-samsung.c:1149: warning: Function parameter or 
member 'dev' not described in 'samsung_pinctrl_suspend'
 drivers/pinctrl/samsung/pinctrl-samsung.c:1199: warning: Function parameter or 
member 'dev' not described in 'samsung_pinctrl_resume'

Cc: Tomasz Figa 
Cc: Krzysztof Kozlowski 
Cc: Sylwester Nawrocki 
Cc: Thomas Abraham 
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/samsung/pinctrl-samsung.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c 
b/drivers/pinctrl/samsung/pinctrl-samsung.c
index f26574ef234ab..608eb5a07248e 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1140,7 +1140,7 @@ static int samsung_pinctrl_probe(struct platform_device 
*pdev)
return 0;
 }
 
-/**
+/*
  * samsung_pinctrl_suspend - save pinctrl state for suspend
  *
  * Save data for all banks handled by this device.
@@ -1187,7 +1187,7 @@ static int __maybe_unused samsung_pinctrl_suspend(struct 
device *dev)
return 0;
 }
 
-/**
+/*
  * samsung_pinctrl_resume - restore pinctrl state from suspend
  *
  * Restore one of the banks that was saved during suspend.
-- 
2.25.1

[PATCH 01/25] pinctrl: actions: pinctrl-owl: Supply missing 'struct owl_pinctrl' attribute descriptions

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/actions/pinctrl-owl.c:52: warning: Function parameter or 
member 'clk' not described in 'owl_pinctrl'
 drivers/pinctrl/actions/pinctrl-owl.c:52: warning: Function parameter or 
member 'irq_chip' not described in 'owl_pinctrl'
 drivers/pinctrl/actions/pinctrl-owl.c:52: warning: Function parameter or 
member 'num_irq' not described in 'owl_pinctrl'
 drivers/pinctrl/actions/pinctrl-owl.c:52: warning: Function parameter or 
member 'irq' not described in 'owl_pinctrl'

Cc: "Andreas Färber" 
Cc: Manivannan Sadhasivam 
Cc: David Liu 
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/actions/pinctrl-owl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/pinctrl/actions/pinctrl-owl.c 
b/drivers/pinctrl/actions/pinctrl-owl.c
index 5a0c8e87aa7cd..7efdfb4f3e9ba 100644
--- a/drivers/pinctrl/actions/pinctrl-owl.c
+++ b/drivers/pinctrl/actions/pinctrl-owl.c
@@ -35,8 +35,12 @@
  * @pctrldev: pinctrl handle
  * @chip: gpio chip
  * @lock: spinlock to protect registers
+ * @clk: clock control
  * @soc: reference to soc_data
  * @base: pinctrl register base address
+ * @irq_chip: IRQ chip information
+ * @num_irq: number of possible interrupts
+ * @irq: interrupt numbers
  */
 struct owl_pinctrl {
struct device *dev;
-- 
2.25.1

[PATCH 00/25] Rid W=1 warnings in Pinctrl

[Lee Jones]

This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.

After these patches are applied, the build system no longer
complains about any W=0 nor W=1 level warnings in drivers/pinctrl.

Hurrah!

Lee Jones (25):
  pinctrl: actions: pinctrl-owl: Supply missing 'struct owl_pinctrl'
attribute descriptions
  pinctrl: sirf: pinctrl-atlas7: Fix a bunch of documentation
misdemeanours
  pinctrl: bcm: pinctrl-bcm281xx: Demote obvious misuse of kerneldoc to
standard comment blocks
  pinctrl: bcm: pinctrl-iproc-gpio: Rename incorrectly documented
function param
  pinctrl: qcom: pinctrl-msm: Complete 'struct msm_pinctrl'
documentation
  pinctrl: samsung: pinctrl-samsung: Demote obvious misuse of kerneldoc
to standard comment blocks
  pinctrl: samsung: pinctrl-s3c24xx: Fix formatting issues
  pinctrl: samsung: pinctrl-s3c64xx: Fix formatting issues
  pinctrl: qcom: pinctrl-msm8976: Remove unused variable
'nav_tsync_groups'
  pinctrl: mediatek: pinctrl-mtk-common-v2: Mark
'mtk_default_register_base_names' as __maybe_unused
  pinctrl: core: Fix a bunch of kerneldoc issues
  pinctrl: pinmux: Add some missing parameter descriptions
  pinctrl: devicetree: Add one new attribute description and rename
another two
  pinctrl: pinconf-generic: Add function parameter description 'pctldev'
  pinctrl: pinctrl-at91-pio4: PM related attribute descriptions
  arch: arm: mach-at91: pm: Move prototypes to mutually included header
  pinctrl: pinctrl-at91: Demote non-kerneldoc header and complete
another
  pinctrl: pinctrl-bm1880: Rename ill documented struct attribute
entries
  pinctrl: pinctrl-rockchip: Fix a bunch of kerneldoc misdemeanours
  pinctrl: pinctrl-rza1: Demote some kerneldoc headers and fix others
  pinctrl: pinctrl-single: Fix struct/function documentation blocks
  pinctrl: tegra: pinctrl-tegra194: Do not initialise field twice
  pinctrl: meson: pinctrl-meson-a1: Remove unused const variable
'i2c_slave_groups'
  pinctrl: mvebu: pinctrl-armada-37xx: Update documentation block for
'struct armada_37xx_pin_group'
  pinctrl: pinctrl-amd: Do not define 'struct acpi_device_id' when
!CONFIG_ACPI

 arch/arm/mach-at91/pm.c   | 17 +
 drivers/pinctrl/actions/pinctrl-owl.c |  4 
 drivers/pinctrl/bcm/pinctrl-bcm281xx.c|  6 ++---
 drivers/pinctrl/bcm/pinctrl-iproc-gpio.c  |  2 +-
 drivers/pinctrl/core.c| 12 +-
 drivers/pinctrl/devicetree.c  |  5 ++--
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  |  2 +-
 drivers/pinctrl/meson/pinctrl-meson-a1.c  |  5 
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c   |  7 +++---
 drivers/pinctrl/pinconf-generic.c |  3 ++-
 drivers/pinctrl/pinctrl-amd.c |  2 ++
 drivers/pinctrl/pinctrl-at91-pio4.c   |  2 ++
 drivers/pinctrl/pinctrl-at91.c|  7 +-
 drivers/pinctrl/pinctrl-bm1880.c  |  4 ++--
 drivers/pinctrl/pinctrl-rockchip.c| 22 +
 drivers/pinctrl/pinctrl-rza1.c| 24 +--
 drivers/pinctrl/pinctrl-single.c  | 13 +++---
 drivers/pinctrl/pinmux.c  |  5 +++-
 drivers/pinctrl/qcom/pinctrl-msm.c|  6 -
 drivers/pinctrl/qcom/pinctrl-msm8976.c|  3 ---
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c |  6 ++---
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c |  6 ++---
 drivers/pinctrl/samsung/pinctrl-samsung.c |  4 ++--
 drivers/pinctrl/sirf/pinctrl-atlas7.c | 21 +++-
 drivers/pinctrl/tegra/pinctrl-tegra194.c  |  1 -
 include/linux/platform_data/atmel.h   |  5 
 26 files changed, 107 insertions(+), 87 deletions(-)

-- 
2.25.1

[PATCH 14/25] pinctrl: pinconf-generic: Add function parameter description 'pctldev'

[Lee Jones]

Fix a spelling/typo while we're here.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/pinconf-generic.c:242: warning: Function parameter or member 
'pctldev' not described in 'pinconf_generic_parse_dt_config'

Signed-off-by: Lee Jones 
---
 drivers/pinctrl/pinconf-generic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinconf-generic.c 
b/drivers/pinctrl/pinconf-generic.c
index dfef471201f60..1e225d5139888 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -231,9 +231,10 @@ static void parse_dt_cfg(struct device_node *np,
  * pinconf_generic_parse_dt_config()
  * parse the config properties into generic pinconfig values.
  * @np: node containing the pinconfig properties
+ * @pctldev: pincontrol device
  * @configs: array with nconfigs entries containing the generic pinconf values
  *   must be freed when no longer necessary.
- * @nconfigs: umber of configurations
+ * @nconfigs: number of configurations
  */
 int pinconf_generic_parse_dt_config(struct device_node *np,
struct pinctrl_dev *pctldev,
-- 
2.25.1

[PATCH 21/25] pinctrl: pinctrl-single: Fix struct/function documentation blocks

[Lee Jones]

Add some missing attributes/parameter descriptions, remove other
superfluous ones, add struct header titles and fix misspellings.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/pinctrl-single.c:50: warning: Function parameter or member 
'mask' not described in 'pcs_func_vals'
 drivers/pinctrl/pinctrl-single.c:97: warning: Function parameter or member 
'conf' not described in 'pcs_function'
 drivers/pinctrl/pinctrl-single.c:97: warning: Function parameter or member 
'nconfs' not described in 'pcs_function'
 drivers/pinctrl/pinctrl-single.c:659: warning: Function parameter or member 
'pin_pos' not described in 'pcs_add_pin'
 drivers/pinctrl/pinctrl-single.c:985: warning: Excess function parameter 
'pctldev' description in 'pcs_parse_one_pinctrl_entry'
 drivers/pinctrl/pinctrl-single.c:1357: warning: Cannot understand  * @reg: 
   virtual address of interrupt register
 drivers/pinctrl/pinctrl-single.c:1377: warning: Function parameter or member 
'pcs_soc' not described in 'pcs_irq_set'
 drivers/pinctrl/pinctrl-single.c:1377: warning: Function parameter or member 
'irq' not described in 'pcs_irq_set'
 drivers/pinctrl/pinctrl-single.c:1377: warning: Function parameter or member 
'enable' not described in 'pcs_irq_set'
 drivers/pinctrl/pinctrl-single.c:1458: warning: Function parameter or member 
'pcs_soc' not described in 'pcs_irq_handle'
 drivers/pinctrl/pinctrl-single.c:1458: warning: Excess function parameter 
'pcs_irq' description in 'pcs_irq_handle'
 drivers/pinctrl/pinctrl-single.c:1506: warning: Excess function parameter 
'irq' description in 'pcs_irq_chain_handler'

Cc: Tony Lindgren 
Cc: Haojian Zhuang 
Cc: linux-o...@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/pinctrl-single.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index e6d1cf25782ce..542578d0bda2d 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -42,6 +42,7 @@
  * struct pcs_func_vals - mux function register offset and value pair
  * @reg:   register virtual address
  * @val:   register value
+ * @mask:  mask
  */
 struct pcs_func_vals {
void __iomem *reg;
@@ -83,6 +84,8 @@ struct pcs_conf_type {
  * @nvals: number of entries in vals array
  * @pgnames:   array of pingroup names the function uses
  * @npgnames:  number of pingroup names the function uses
+ * @conf:  array of pin configurations
+ * @nconfs:number of pin configurations available
  * @node:  list node
  */
 struct pcs_function {
@@ -653,6 +656,7 @@ static const struct pinconf_ops pcs_pinconf_ops = {
  * pcs_add_pin() - add a pin to the static per controller pin array
  * @pcs: pcs driver instance
  * @offset: register offset from base
+ * @pin_pos: unused
  */
 static int pcs_add_pin(struct pcs_device *pcs, unsigned offset,
unsigned pin_pos)
@@ -959,7 +963,6 @@ static int pcs_parse_pinconf(struct pcs_device *pcs, struct 
device_node *np,
 
 /**
  * pcs_parse_one_pinctrl_entry() - parses a device tree mux entry
- * @pctldev: pin controller device
  * @pcs: pinctrl driver instance
  * @np: device node of the mux entry
  * @map: map entry
@@ -1353,7 +1356,9 @@ static int pcs_add_gpio_func(struct device_node *node, 
struct pcs_device *pcs)
}
return ret;
 }
+
 /**
+ * struct pcs_interrupt
  * @reg:   virtual address of interrupt register
  * @hwirq: hardware irq number
  * @irq:   virtual irq number
@@ -1368,6 +1373,9 @@ struct pcs_interrupt {
 
 /**
  * pcs_irq_set() - enables or disables an interrupt
+ * @pcs_soc: SoC specific settings
+ * @irq: interrupt
+ * @enable: enable or disable the interrupt
  *
  * Note that this currently assumes one interrupt per pinctrl
  * register that is typically used for wake-up events.
@@ -1448,7 +1456,7 @@ static int pcs_irq_set_wake(struct irq_data *d, unsigned 
int state)
 
 /**
  * pcs_irq_handle() - common interrupt handler
- * @pcs_irq: interrupt data
+ * @pcs_soc: SoC specific settings
  *
  * Note that this currently assumes we have one interrupt bit per
  * mux register. This interrupt is typically used for wake-up events.
@@ -1496,7 +1504,6 @@ static irqreturn_t pcs_irq_handler(int irq, void *d)
 
 /**
  * pcs_irq_handle() - handler for the dedicated chained interrupt case
- * @irq: interrupt
  * @desc: interrupt descriptor
  *
  * Use this if you have a separate interrupt for each
-- 
2.25.1

[PATCH 20/25] pinctrl: pinctrl-rza1: Demote some kerneldoc headers and fix others

[Lee Jones]

Some description blocks are void of any description/documentation,
others are missing 'struct' identifiers, there are also a couple of
misspellings of function parameter names.  Fix all of them.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/pinctrl-rza1.c:81: warning: cannot understand function 
prototype: 'struct rza1_bidir_pin '
 drivers/pinctrl/pinctrl-rza1.c:90: warning: cannot understand function 
prototype: 'struct rza1_bidir_entry '
 drivers/pinctrl/pinctrl-rza1.c:98: warning: cannot understand function 
prototype: 'struct rza1_swio_pin '
 drivers/pinctrl/pinctrl-rza1.c:108: warning: cannot understand function 
prototype: 'struct rza1_swio_entry '
 drivers/pinctrl/pinctrl-rza1.c:116: warning: cannot understand function 
prototype: 'struct rza1_pinmux_conf '
 drivers/pinctrl/pinctrl-rza1.c:443: warning: cannot understand function 
prototype: 'struct rza1_mux_conf '
 drivers/pinctrl/pinctrl-rza1.c:462: warning: cannot understand function 
prototype: 'struct rza1_port '
 drivers/pinctrl/pinctrl-rza1.c:482: warning: cannot understand function 
prototype: 'struct rza1_pinctrl '
 drivers/pinctrl/pinctrl-rza1.c:546: warning: Function parameter or member 
'port' not described in 'rza1_pinmux_get_flags'
 drivers/pinctrl/pinctrl-rza1.c:546: warning: Function parameter or member 
'pin' not described in 'rza1_pinmux_get_flags'
 drivers/pinctrl/pinctrl-rza1.c:546: warning: Function parameter or member 
'func' not described in 'rza1_pinmux_get_flags'
 drivers/pinctrl/pinctrl-rza1.c:546: warning: Function parameter or member 
'rza1_pctl' not described in 'rza1_pinmux_get_flags'
 drivers/pinctrl/pinctrl-rza1.c:575: warning: Function parameter or member 
'port' not described in 'rza1_set_bit'
 drivers/pinctrl/pinctrl-rza1.c:575: warning: Function parameter or member 
'reg' not described in 'rza1_set_bit'
 drivers/pinctrl/pinctrl-rza1.c:575: warning: Function parameter or member 
'bit' not described in 'rza1_set_bit'
 drivers/pinctrl/pinctrl-rza1.c:575: warning: Function parameter or member 
'set' not described in 'rza1_set_bit'
 drivers/pinctrl/pinctrl-rza1.c:672: warning: Function parameter or member 
'rza1_pctl' not described in 'rza1_pin_mux_single'
 drivers/pinctrl/pinctrl-rza1.c:672: warning: Excess function parameter 
'pinctrl' description in 'rza1_pin_mux_single'

Cc: Geert Uytterhoeven 
Cc: Jacopo Mondi 
Cc: linux-renesas-...@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/pinctrl-rza1.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rza1.c b/drivers/pinctrl/pinctrl-rza1.c
index 38a14bbced5f6..511f232ab7bc2 100644
--- a/drivers/pinctrl/pinctrl-rza1.c
+++ b/drivers/pinctrl/pinctrl-rza1.c
@@ -75,7 +75,7 @@
  * RZ/A1 pinmux flags
  */
 
-/**
+/*
  * rza1_bidir_pin - describe a single pin that needs bidir flag applied.
  */
 struct rza1_bidir_pin {
@@ -83,7 +83,7 @@ struct rza1_bidir_pin {
u8 func: 4;
 };
 
-/**
+/*
  * rza1_bidir_entry - describe a list of pins that needs bidir flag applied.
  *   Each struct rza1_bidir_entry describes a port.
  */
@@ -92,7 +92,7 @@ struct rza1_bidir_entry {
const struct rza1_bidir_pin *pins;
 };
 
-/**
+/*
  * rza1_swio_pin - describe a single pin that needs swio flag applied.
  */
 struct rza1_swio_pin {
@@ -102,7 +102,7 @@ struct rza1_swio_pin {
u16 input: 1;
 };
 
-/**
+/*
  * rza1_swio_entry - describe a list of pins that needs swio flag applied
  */
 struct rza1_swio_entry {
@@ -110,7 +110,7 @@ struct rza1_swio_entry {
const struct rza1_swio_pin *pins;
 };
 
-/**
+/*
  * rza1_pinmux_conf - group together bidir and swio pinmux flag tables
  */
 struct rza1_pinmux_conf {
@@ -431,7 +431,7 @@ static const struct rza1_pinmux_conf rza1l_pmx_conf = {
  * RZ/A1 types
  */
 /**
- * rza1_mux_conf - describes a pin multiplexing operation
+ * struct rza1_mux_conf - describes a pin multiplexing operation
  *
  * @id: the pin identifier from 0 to RZA1_NPINS
  * @port: the port where pin sits on
@@ -450,7 +450,7 @@ struct rza1_mux_conf {
 };
 
 /**
- * rza1_port - describes a pin port
+ * struct rza1_port - describes a pin port
  *
  * This is mostly useful to lock register writes per-bank and not globally.
  *
@@ -467,12 +467,12 @@ struct rza1_port {
 };
 
 /**
- * rza1_pinctrl - RZ pincontroller device
+ * struct rza1_pinctrl - RZ pincontroller device
  *
  * @dev: parent device structure
  * @mutex: protect [pinctrl|pinmux]_generic functions
  * @base: logical address base
- * @nports: number of pin controller ports
+ * @nport: number of pin controller ports
  * @ports: pin controller banks
  * @pins: pin array for pinctrl core
  * @desc: pincontroller desc for pinctrl core
@@ -536,7 +536,7 @@ static inline int rza1_pinmux_get_swio(unsigned int port,
return -ENOENT;
 }
 
-/**
+/*
  * rza1_pinmux_get_flags() - return pinmux flags associated to a pin
  */
 static unsigned int rza1_pinmux_get_flags(unsigned int port, unsigne

[PATCH 17/25] pinctrl: pinctrl-at91: Demote non-kerneldoc header and complete another

[Lee Jones]

The documentation header for 'struct at91_pinctrl_mux_ops' was missing
entries for {g,s}et_drivestrength and {g,s}et_slewrate.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/pinctrl-at91.c:77: warning: cannot understand function 
prototype: 'enum drive_strength_bit '
 drivers/pinctrl/pinctrl-at91.c:187: warning: Function parameter or member 
'get_drivestrength' not described in 'at91_pinctrl_mux_ops'
 drivers/pinctrl/pinctrl-at91.c:187: warning: Function parameter or member 
'set_drivestrength' not described in 'at91_pinctrl_mux_ops'
 drivers/pinctrl/pinctrl-at91.c:187: warning: Function parameter or member 
'get_slewrate' not described in 'at91_pinctrl_mux_ops'
 drivers/pinctrl/pinctrl-at91.c:187: warning: Function parameter or member 
'set_slewrate' not described in 'at91_pinctrl_mux_ops'

Cc: Ludovic Desroches 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Jean-Christophe PLAGNIOL-VILLARD 
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/pinctrl-at91.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 37997e5ab0538..77e1b9ed3a634 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -66,7 +66,7 @@ static int gpio_banks;
 #define DEBOUNCE_VAL_SHIFT 17
 #define DEBOUNCE_VAL   (0x3fff << DEBOUNCE_VAL_SHIFT)
 
-/**
+/*
  * These defines will translated the dt binding settings to our internal
  * settings. They are not necessarily the same value as the register setting.
  * The actual drive strength current of low, medium and high must be looked up
@@ -162,6 +162,10 @@ struct at91_pin_group {
  * @set_pulldown: enable/disable pulldown
  * @get_schmitt_trig: get schmitt trigger status
  * @disable_schmitt_trig: disable schmitt trigger
+ * @get_drivestrength: get driver strength
+ * @set_drivestrength: set driver strength
+ * @get_slewrate: get slew rate
+ * @set_slewrate: set slew rate
  * @irq_type: return irq type
  */
 struct at91_pinctrl_mux_ops {
-- 
2.25.1

[PATCH 25/25] pinctrl: pinctrl-amd: Do not define 'struct acpi_device_id' when !CONFIG_ACPI

[Lee Jones]

Since ACPI_PTR() is used to NULLify the value when !CONFIG_ACPI,
'struct amd_gpio_acpi_match' becomes defined but unused.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/pinctrl-amd.c:959:36: warning: ‘amd_gpio_acpi_match’ defined 
but not used [-Wunused-const-variable=]
 959 | static const struct acpi_device_id amd_gpio_acpi_match[] = {

Cc: Ken Xue 
Cc: "Wu, Jeff" 
Cc: Nehal Shah 
Cc: Sundar S K 
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/pinctrl-amd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index c34e6a950b3f6..ccf6120311193 100644
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -956,12 +956,14 @@ static int amd_gpio_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_ACPI
 static const struct acpi_device_id amd_gpio_acpi_match[] = {
{ "AMD0030", 0 },
{ "AMDI0030", 0},
{ },
 };
 MODULE_DEVICE_TABLE(acpi, amd_gpio_acpi_match);
+#endif
 
 static struct platform_driver amd_gpio_driver = {
.driver = {
-- 
2.25.1

[PATCH 23/25] pinctrl: meson: pinctrl-meson-a1: Remove unused const variable 'i2c_slave_groups'

[Lee Jones]

It has never been used.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/meson/pinctrl-meson-a1.c:749:27: warning: ‘i2c_slave_groups’ 
defined but not used [-Wunused-const-variable=]
 749 | static const char const i2c_slave_groups[] = {
 | ^~~~

Cc: Kevin Hilman 
Cc: Qianggui Song 
Cc: linux-amlo...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/meson/pinctrl-meson-a1.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson-a1.c 
b/drivers/pinctrl/meson/pinctrl-meson-a1.c
index 0bcec03f344aa..8abf750eac7ee 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-a1.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-a1.c
@@ -746,11 +746,6 @@ static const char * const i2c3_groups[] = {
"i2c3_sck_x", "i2c3_sda_x", "i2c3_sck_f", "i2c3_sda_f",
 };
 
-static const char * const i2c_slave_groups[] = {
-   "i2c_slave_sda_a", "i2c_slave_sck_a",
-   "i2c_slave_sda_f", "i2c_slave_sck_f",
-};
-
 static const char * const spi_a_groups[] = {
"spi_a_mosi_x2", "spi_a_ss0_x3", "spi_a_sclk_x4", "spi_a_miso_x5",
"spi_a_mosi_x7", "spi_a_miso_x8", "spi_a_ss0_x9", "spi_a_sclk_x10",
-- 
2.25.1

Re: [PATCH v3] PCI: aardvark: Don't touch PCIe registers if no card connected

[Pali Rohár]

On Monday 13 July 2020 12:23:25 Lorenzo Pieralisi wrote:
> I will go over the thread again but I suspect I can merge the patch even
> though I still believe there is work to be done to understand the issue
> we are facing.

Just to note that pci-mvebu.c also checks if pcie link is up before
trying to access the real PCIe interface registers, similarly as in my
patch.

[PATCH 13/25] pinctrl: devicetree: Add one new attribute description and rename another two

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/devicetree.c:27: warning: Function parameter or member 'map' 
not described in 'pinctrl_dt_map'
 drivers/pinctrl/devicetree.c:27: warning: Function parameter or member 
'num_maps' not described in 'pinctrl_dt_map'
 drivers/pinctrl/devicetree.c:409: warning: Function parameter or member 
'out_args' not described in 'pinctrl_parse_index_with_args'
 drivers/pinctrl/devicetree.c:409: warning: Excess function parameter 
'out_arts' description in 'pinctrl_parse_index_with_args'

Signed-off-by: Lee Jones 
---
 drivers/pinctrl/devicetree.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index c6fe7d64c9137..5eff8c2965528 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -17,7 +17,8 @@
  * struct pinctrl_dt_map - mapping table chunk parsed from device tree
  * @node: list node for struct pinctrl's @dt_maps field
  * @pctldev: the pin controller that allocated this struct, and will free it
- * @maps: the mapping table entries
+ * @map: the mapping table entries
+ * @num_maps: number of mapping table entries
  */
 struct pinctrl_dt_map {
struct list_head node;
@@ -397,7 +398,7 @@ static int pinctrl_copy_args(const struct device_node *np,
  * @np: pointer to device node with the property
  * @list_name: property that contains the list
  * @index: index within the list
- * @out_arts: entries in the list pointed by index
+ * @out_args: entries in the list pointed by index
  *
  * Finds the selected element in a pinctrl array consisting of an index
  * within the controller and a number of u32 entries specified for each
-- 
2.25.1

[PATCH 11/25] pinctrl: core: Fix a bunch of kerneldoc issues

[Lee Jones]

Most are likely due to bitrot/API slip.  Some are formatting issues.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/core.c:167: warning: Function parameter or member 'pin' not 
described in 'pin_get_name'
 drivers/pinctrl/core.c:167: warning: Excess function parameter 'name' 
description in 'pin_get_name'
 drivers/pinctrl/core.c:584: warning: Function parameter or member 'selector' 
not described in 'pinctrl_generic_get_group'
 drivers/pinctrl/core.c:584: warning: Excess function parameter 'gselector' 
description in 'pinctrl_generic_get_group'
 drivers/pinctrl/core.c:1356: error: Cannot parse struct or union!
 drivers/pinctrl/core.c:1458: warning: Function parameter or member 'map' not 
described in 'pinctrl_unregister_mappings'
 drivers/pinctrl/core.c:1458: warning: Excess function parameter 'maps' 
description in 'pinctrl_unregister_mappings'
 drivers/pinctrl/core.c:2239: warning: Function parameter or member 'pctldev' 
not described in 'devm_pinctrl_register_and_init'

Signed-off-by: Lee Jones 
---
 drivers/pinctrl/core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 821242bb4b16a..3e8d1630d29ed 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -161,7 +161,7 @@ int pin_get_from_name(struct pinctrl_dev *pctldev, const 
char *name)
 /**
  * pin_get_name_from_id() - look up a pin name from a pin id
  * @pctldev: the pin control device to lookup the pin on
- * @name: the name of the pin to look up
+ * @pin: pin number/id to look up
  */
 const char *pin_get_name(struct pinctrl_dev *pctldev, const unsigned pin)
 {
@@ -577,7 +577,7 @@ EXPORT_SYMBOL_GPL(pinctrl_generic_get_group_pins);
 /**
  * pinctrl_generic_get_group() - returns a pin group based on the number
  * @pctldev: pin controller device
- * @gselector: group number
+ * @selector: group number
  */
 struct group_desc *pinctrl_generic_get_group(struct pinctrl_dev *pctldev,
 unsigned int selector)
@@ -1329,7 +1329,7 @@ static void devm_pinctrl_release(struct device *dev, void 
*res)
 }
 
 /**
- * struct devm_pinctrl_get() - Resource managed pinctrl_get()
+ * devm_pinctrl_get() - Resource managed pinctrl_get()
  * @dev: the device to obtain the handle for
  *
  * If there is a need to explicitly destroy the returned struct pinctrl,
@@ -1451,7 +1451,7 @@ EXPORT_SYMBOL_GPL(pinctrl_register_mappings);
 
 /**
  * pinctrl_unregister_mappings() - unregister a set of pin controller mappings
- * @maps: the pincontrol mappings table passed to pinctrl_register_mappings()
+ * @map: the pincontrol mappings table passed to pinctrl_register_mappings()
  * when registering the mappings.
  */
 void pinctrl_unregister_mappings(const struct pinctrl_map *map)
@@ -2226,9 +2226,9 @@ EXPORT_SYMBOL_GPL(devm_pinctrl_register);
  * @dev: parent device for this pin controller
  * @pctldesc: descriptor for this pin controller
  * @driver_data: private pin controller data for this pin controller
+ * @pctldev: pin controller device
  *
- * Returns an error pointer if pincontrol register failed. Otherwise
- * it returns valid pinctrl handle.
+ * Returns zero on success or an error number on failure.
  *
  * The pinctrl device will be automatically released when the device is 
unbound.
  */
-- 
2.25.1

[PATCH 15/25] pinctrl: pinctrl-at91-pio4: PM related attribute descriptions

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/pinctrl-at91-pio4.c:132: warning: Function parameter or member 
'pm_wakeup_sources' not described in 'atmel_pioctrl'
 drivers/pinctrl/pinctrl-at91-pio4.c:132: warning: Function parameter or member 
'pm_suspend_backup' not described in 'atmel_pioctrl'

Cc: Ludovic Desroches 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/pinctrl-at91-pio4.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c 
b/drivers/pinctrl/pinctrl-at91-pio4.c
index 54222ccddfb19..8e5a5053a47e2 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -106,6 +106,8 @@ struct atmel_pin {
  * @irq_domain: irq domain for the gpio controller.
  * @irqs: table containing the hw irq number of the bank. The index of the
  * table is the bank id.
+ * @pm_wakeup_sources: bitmap of wakeup sources (lines)
+ * @pm_suspend_backup: backup/restore register values on suspend/resume
  * @dev: device entry for the Atmel PIO controller.
  * @node: node of the Atmel PIO controller.
  */
-- 
2.25.1

[PATCH 12/25] pinctrl: pinmux: Add some missing parameter descriptions

[Lee Jones]

And rename another which has probably bitrotted.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/pinmux.c:83: warning: Function parameter or member 'pctldev' 
not described in 'pinmux_can_be_used_for_gpio'
 drivers/pinctrl/pinmux.c:108: warning: Function parameter or member 'pctldev' 
not described in 'pin_request'
 drivers/pinctrl/pinmux.c:261: warning: Function parameter or member 'gpio' not 
described in 'pinmux_request_gpio'
 drivers/pinctrl/pinmux.c:751: warning: Function parameter or member 'selector' 
not described in 'pinmux_generic_get_function'
 drivers/pinctrl/pinmux.c:751: warning: Excess function parameter 
'group_selector' description in 'pinmux_generic_get_function'

Signed-off-by: Lee Jones 
---
 drivers/pinctrl/pinmux.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 9503ddf2edc76..bab888fe3f8e3 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -74,6 +74,7 @@ int pinmux_validate_map(const struct pinctrl_map *map, int i)
  * pinmux_can_be_used_for_gpio() - check if a specific pin
  * is either muxed to a different function or used as gpio.
  *
+ * @pctldev: the associated pin controller device
  * @pin: the pin number in the global pin space
  *
  * Controllers not defined as strict will always return true,
@@ -96,6 +97,7 @@ bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev, 
unsigned pin)
 
 /**
  * pin_request() - request a single pin to be muxed in, typically for GPIO
+ * @pctldev: the associated pin controller device
  * @pin: the pin number in the global pin space
  * @owner: a representation of the owner of this pin; typically the device
  * name that controls its mux function, or the requested GPIO name
@@ -254,6 +256,7 @@ static const char *pin_free(struct pinctrl_dev *pctldev, 
int pin,
  * @pctldev: pin controller device affected
  * @pin: the pin to mux in for GPIO
  * @range: the applicable GPIO range
+ * @gpio: number of requested GPIO
  */
 int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
@@ -744,7 +747,7 @@ EXPORT_SYMBOL_GPL(pinmux_generic_get_function_groups);
 /**
  * pinmux_generic_get_function() - returns a function based on the number
  * @pctldev: pin controller device
- * @group_selector: function number
+ * @selector: function number
  */
 struct function_desc *pinmux_generic_get_function(struct pinctrl_dev *pctldev,
  unsigned int selector)
-- 
2.25.1

[PATCH 18/25] pinctrl: pinctrl-bm1880: Rename ill documented struct attribute entries

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/pinctrl-bm1880.c:40: warning: Function parameter or member 
'pctrldev' not described in 'bm1880_pinctrl'
 drivers/pinctrl/pinctrl-bm1880.c:40: warning: Function parameter or member 
'pinconf' not described in 'bm1880_pinctrl'

Cc: Manivannan Sadhasivam 
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/pinctrl-bm1880.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-bm1880.c b/drivers/pinctrl/pinctrl-bm1880.c
index d1a7d98367870..a8e267237435f 100644
--- a/drivers/pinctrl/pinctrl-bm1880.c
+++ b/drivers/pinctrl/pinctrl-bm1880.c
@@ -22,12 +22,12 @@
 /**
  * struct bm1880_pinctrl - driver data
  * @base:  Pinctrl base address
- * @pctrl: Pinctrl device
+ * @pctrldev:  Pinctrl device
  * @groups:Pingroups
  * @ngroups:   Number of @groups
  * @funcs: Pinmux functions
  * @nfuncs:Number of @funcs
- * @pconf: Pinconf data
+ * @pinconf:   Pinconf data
  */
 struct bm1880_pinctrl {
void __iomem *base;
-- 
2.25.1

[PATCH 09/25] pinctrl: qcom: pinctrl-msm8976: Remove unused variable 'nav_tsync_groups'

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/qcom/pinctrl-msm8976.c:802:27: warning: ‘nav_tsync_groups’ 
defined but not used [-Wunused-const-variable=]
 802 | static const char
 const nav_tsync_groups[] = {
 | ^~~~

Cc: Andy Gross 
Cc: Bjorn Andersson 
Cc: Del Regno 
Cc: linux-arm-...@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/qcom/pinctrl-msm8976.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm8976.c 
b/drivers/pinctrl/qcom/pinctrl-msm8976.c
index 183f0b2d9f8e8..ec43edf9b660a 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm8976.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm8976.c
@@ -799,9 +799,6 @@ static const char * const pa_indicator_groups[] = {
 static const char * const modem_tsync_groups[] = {
"gpio93",
 };
-static const char * const nav_tsync_groups[] = {
-   "gpio93",
-};
 static const char * const ssbi_wtr1_groups[] = {
"gpio79", "gpio94",
 };
-- 
2.25.1

[PATCH 24/25] pinctrl: mvebu: pinctrl-armada-37xx: Update documentation block for 'struct armada_37xx_pin_group'

[Lee Jones]

Correct misspellings and provide missing entries.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c:68: warning: Function parameter or 
member 'start_pin' not described in 'armada_37xx_pin_group'
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c:68: warning: Function parameter or 
member 'val' not described in 'armada_37xx_pin_group'
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c:68: warning: Function parameter or 
member 'extra_pin' not described in 'armada_37xx_pin_group'
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c:68: warning: Function parameter or 
member 'extra_npins' not described in 'armada_37xx_pin_group'

Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Sebastian Hesselbarth 
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index 5f125bd6279dd..953126bf6657b 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -45,13 +45,14 @@
  * The pins of a pinmux groups are composed of one or two groups of contiguous
  * pins.
  * @name:  Name of the pin group, used to lookup the group.
- * @start_pins:Index of the first pin of the main range of pins 
belonging to
+ * @start_pin: Index of the first pin of the main range of pins belonging to
  * the group
  * @npins: Number of pins included in the first range
  * @reg_mask:  Bit mask matching the group in the selection register
- * @extra_pins:Index of the first pin of the optional second range of 
pins
+ * @val:   Value to write to the registers for a given function
+ * @extra_pin: Index of the first pin of the optional second range of pins
  * belonging to the group
- * @npins: Number of pins included in the second optional range
+ * @extra_npins:Number of pins included in the second optional range
  * @funcs: A list of pinmux functions that can be selected for this group.
  * @pins:  List of the pins included in the group
  */
-- 
2.25.1

[PATCH 07/25] pinctrl: samsung: pinctrl-s3c24xx: Fix formatting issues

[Lee Jones]

Kerneldoc struct titles must be followed by whitespace.  Also attributes
need to be in the format '@.*: ' else the checker gets confused.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/samsung/pinctrl-s3c24xx.c:100: warning: cannot understand 
function prototype: 'struct s3c24xx_eint_domain_data '

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Tomasz Figa 
Cc: Sylwester Nawrocki 
Cc: Heiko Stuebner 
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
index 9bd0a3de101dd..5e24838a582f5 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
@@ -80,7 +80,7 @@ static const struct samsung_pin_bank_type bank_type_2bit = {
}
 
 /**
- * struct s3c24xx_eint_data: EINT common data
+ * struct s3c24xx_eint_data - EINT common data
  * @drvdata: pin controller driver data
  * @domains: IRQ domains of particular EINT interrupts
  * @parents: mapped parent irqs in the main interrupt controller
@@ -92,10 +92,10 @@ struct s3c24xx_eint_data {
 };
 
 /**
- * struct s3c24xx_eint_domain_data: per irq-domain data
+ * struct s3c24xx_eint_domain_data - per irq-domain data
  * @bank: pin bank related to the domain
  * @eint_data: common data
- * eint0_3_parent_only: live eints 0-3 only in the main intc
+ * @eint0_3_parent_only: live eints 0-3 only in the main intc
  */
 struct s3c24xx_eint_domain_data {
struct samsung_pin_bank *bank;
-- 
2.25.1

[PATCH 10/25] pinctrl: mediatek: pinctrl-mtk-common-v2: Mark 'mtk_default_register_base_names' as __maybe_unused

[Lee Jones]

Not all sourcefiles which end up including pinctrl-mtk-common-v2.h make use
of 'mtk_default_register_base_names' and there is nowhere we can place the
definition to void the need for __maybe_unused except its own headerfile,
which seems like overkill.  So instead we tell the compiler that it's okay
for it to be unused by some of the consumers.

Fixes the following W=1 kernel build warning(s):

 In file included from drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c:19:
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: 
‘mtk_default_register_base_names’ defined but not used 
[-Wunused-const-variable=]
 83 | static const char const mtk_default_register_base_names[] = {
 | ^~~
 In file included from drivers/pinctrl/mediatek/pinctrl-moore.h:25,
 from drivers/pinctrl/mediatek/pinctrl-moore.c:12:
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: 
‘mtk_default_register_base_names’ defined but not used 
[-Wunused-const-variable=]
 83 | static const char const mtk_default_register_base_names[] = {
 | ^~~
 In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
 from drivers/pinctrl/mediatek/pinctrl-paris.c:15:
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: 
‘mtk_default_register_base_names’ defined but not used 
[-Wunused-const-variable=]
 83 | static const char const mtk_default_register_base_names[] = {
 | ^~~
 In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
 from drivers/pinctrl/mediatek/pinctrl-mtk-mt6797.h:15,
 from drivers/pinctrl/mediatek/pinctrl-mt6797.c:13:
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: 
‘mtk_default_register_base_names’ defined but not used 
[-Wunused-const-variable=]
 83 | static const char const mtk_default_register_base_names[] = {
 | ^~~
 In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
 from drivers/pinctrl/mediatek/pinctrl-mtk-mt8183.h:12,
 from drivers/pinctrl/mediatek/pinctrl-mt8183.c:9:
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: 
‘mtk_default_register_base_names’ defined but not used 
[-Wunused-const-variable=]
 83 | static const char const mtk_default_register_base_names[] = {
 | ^~~
 In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
 from drivers/pinctrl/mediatek/pinctrl-mtk-mt6765.h:12,
 from drivers/pinctrl/mediatek/pinctrl-mt6765.c:10:
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: 
‘mtk_default_register_base_names’ defined but not used 
[-Wunused-const-variable=]
 83 | static const char const mtk_default_register_base_names[] = {
 | ^~~

Cc: Sean Wang 
Cc: Matthias Brugger 
Cc: linux-media...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index 27df087363960..45aa0fdbe3306 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -80,7 +80,7 @@ enum {
DRV_GRP_MAX,
 };
 
-static const char * const mtk_default_register_base_names[] = {
+static const char * const mtk_default_register_base_names[] __maybe_unused = {
"base",
 };
 
-- 
2.25.1

[PATCH 08/25] pinctrl: samsung: pinctrl-s3c64xx: Fix formatting issues

[Lee Jones]

Kerneldoc struct titles must be followed by whitespace else the
checker gets confused.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/samsung/pinctrl-s3c64xx.c:212: warning: cannot understand 
function prototype: 'struct s3c64xx_eint0_domain_data '

Cc: Tomasz Figa 
Cc: Krzysztof Kozlowski 
Cc: Sylwester Nawrocki 
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
index f97f8179f2b1b..b8166e3fe4cef 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
@@ -193,7 +193,7 @@ static const struct samsung_pin_bank_type 
bank_type_2bit_alive = {
}
 
 /**
- * struct s3c64xx_eint0_data: EINT0 common data
+ * struct s3c64xx_eint0_data - EINT0 common data
  * @drvdata: pin controller driver data
  * @domains: IRQ domains of particular EINT0 interrupts
  * @pins: pin offsets inside of banks of particular EINT0 interrupts
@@ -205,7 +205,7 @@ struct s3c64xx_eint0_data {
 };
 
 /**
- * struct s3c64xx_eint0_domain_data: EINT0 per-domain data
+ * struct s3c64xx_eint0_domain_data - EINT0 per-domain data
  * @bank: pin bank related to the domain
  * @eints: EINT0 interrupts related to the domain
  */
@@ -215,7 +215,7 @@ struct s3c64xx_eint0_domain_data {
 };
 
 /**
- * struct s3c64xx_eint_gpio_data: GPIO EINT data
+ * struct s3c64xx_eint_gpio_data - GPIO EINT data
  * @drvdata: pin controller driver data
  * @domains: array of domains related to EINT interrupt groups
  */
-- 
2.25.1

[PATCH 19/25] pinctrl: pinctrl-rockchip: Fix a bunch of kerneldoc misdemeanours

[Lee Jones]

Demote headers which are clearly not kerneldoc, provide titles for
struct definition blocks, fix API slip (bitrot) misspellings and
provide some missing entries.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/pinctrl-rockchip.c:82: warning: cannot understand function 
prototype: 'struct rockchip_iomux '
 drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 
'DRV_TYPE_IO_DEFAULT' not described in enum 'rockchip_pin_drv_type'
 drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 
'DRV_TYPE_IO_1V8_OR_3V0' not described in enum 'rockchip_pin_drv_type'
 drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 
'DRV_TYPE_IO_1V8_ONLY' not described in enum 'rockchip_pin_drv_type'
 drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 
'DRV_TYPE_IO_1V8_3V0_AUTO' not described in enum 'rockchip_pin_drv_type'
 drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 
'DRV_TYPE_IO_3V3_ONLY' not described in enum 'rockchip_pin_drv_type'
 drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_MAX' not 
described in enum 'rockchip_pin_drv_type'
 drivers/pinctrl/pinctrl-rockchip.c:106: warning: Enum value 
'PULL_TYPE_IO_DEFAULT' not described in enum 'rockchip_pin_pull_type'
 drivers/pinctrl/pinctrl-rockchip.c:106: warning: Enum value 
'PULL_TYPE_IO_1V8_ONLY' not described in enum 'rockchip_pin_pull_type'
 drivers/pinctrl/pinctrl-rockchip.c:106: warning: Enum value 'PULL_TYPE_MAX' 
not described in enum 'rockchip_pin_pull_type'
 drivers/pinctrl/pinctrl-rockchip.c:109: warning: Cannot understand  * 
@drv_type: drive strength variant using rockchip_perpin_drv_type
 on line 109 - I thought it was a doc line
 drivers/pinctrl/pinctrl-rockchip.c:122: warning: Cannot understand  * 
@reg_base: register base of the gpio bank
 on line 109 - I thought it was a doc line
 drivers/pinctrl/pinctrl-rockchip.c:325: warning: Function parameter or member 
'route_location' not described in 'rockchip_mux_route_data'
 drivers/pinctrl/pinctrl-rockchip.c:328: warning: Cannot understand  */
 on line 109 - I thought it was a doc line
 drivers/pinctrl/pinctrl-rockchip.c:375: warning: Function parameter or member 
'data' not described in 'rockchip_pin_group'
 drivers/pinctrl/pinctrl-rockchip.c:387: warning: Function parameter or member 
'ngroups' not described in 'rockchip_pmx_func'

Cc: Heiko Stuebner 
Cc: Jean-Christophe PLAGNIOL-VILLARD 
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/pinctrl-rockchip.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index c07324d1f2657..c96d810635ad6 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -63,7 +63,7 @@ enum rockchip_pinctrl_type {
RK3399,
 };
 
-/**
+/*
  * Encode variants of iomux registers into a type variable
  */
 #define IOMUX_GPIO_ONLYBIT(0)
@@ -74,6 +74,7 @@ enum rockchip_pinctrl_type {
 #define IOMUX_WIDTH_2BIT   BIT(5)
 
 /**
+ * struct rockchip_iomux
  * @type: iomux variant using IOMUX_* constants
  * @offset: if initialized to -1 it will be autocalculated, by specifying
  * an initial offset value the relevant source offset can be reset
@@ -84,7 +85,7 @@ struct rockchip_iomux {
int offset;
 };
 
-/**
+/*
  * enum type index corresponding to rockchip_perpin_drv_list arrays index.
  */
 enum rockchip_pin_drv_type {
@@ -96,7 +97,7 @@ enum rockchip_pin_drv_type {
DRV_TYPE_MAX
 };
 
-/**
+/*
  * enum type index corresponding to rockchip_pull_list arrays index.
  */
 enum rockchip_pin_pull_type {
@@ -106,6 +107,7 @@ enum rockchip_pin_pull_type {
 };
 
 /**
+ * struct rockchip_drv
  * @drv_type: drive strength variant using rockchip_perpin_drv_type
  * @offset: if initialized to -1 it will be autocalculated, by specifying
  * an initial offset value the relevant source offset can be reset
@@ -119,8 +121,9 @@ struct rockchip_drv {
 };
 
 /**
+ * struct rockchip_pin_bank
  * @reg_base: register base of the gpio bank
- * @reg_pull: optional separate register for additional pull settings
+ * @regmap_pull: optional separate register for additional pull settings
  * @clk: clock of the gpio bank
  * @irq: interrupt of the gpio bank
  * @saved_masks: Saved content of GPIO_INTEN at suspend time.
@@ -138,6 +141,8 @@ struct rockchip_drv {
  * @gpio_chip: gpiolib chip
  * @grange: gpio range
  * @slock: spinlock for the gpio bank
+ * @toggle_edge_mode: bit mask to toggle (falling/rising) edge mode
+ * @recalced_mask: bit mask to indicate a need to recalulate the mask
  * @route_mask: bits describing the routing pins of per bank
  */
 struct rockchip_pin_bank {
@@ -312,6 +317,7 @@ enum rockchip_mux_route_location {
  * @bank_num: bank number.
  * @pin: index at register or used to calc index.
  * @func: the min pin.
+ * @route_location: the mux route location (same, pmu, 

[PATCH 22/25] pinctrl: tegra: pinctrl-tegra194: Do not initialise field twice

[Lee Jones]

Both PIN_PINGROUP_ENTRY_Y() and DRV_PINGROUP_ENTRY_Y() macros are
called for each of the 2 pin groups defined here, and both of them
initialise 'drv_reg', causing the compiler to complain.

Only initialise 'drv_reg' once.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/tegra/pinctrl-tegra194.c:71:14: warning: initialized field 
overwritten [-Woverride-init]
 71 | .drv_reg = ((r)), | ^
 drivers/pinctrl/tegra/pinctrl-tegra194.c:105:2: note: in expansion of macro 
‘DRV_PINGROUP_ENTRY_Y’
 105 | DRV_PINGROUP_ENTRY_Y(0x14004, 12, 5, 20, 5, -1, -1, -1, -1, 0)
 | ^~~~
 drivers/pinctrl/tegra/pinctrl-tegra194.c:124:3: note: in expansion of macro 
‘drive_pex_l5_clkreq_n_pgg0’
 124 | drive_##pg_name, | ^~
 drivers/pinctrl/tegra/pinctrl-tegra194.c:128:2: note: in expansion of macro 
‘PINGROUP’
 128 | PINGROUP(pex_l5_clkreq_n_pgg0, PE5, RSVD1, RSVD2, RSVD3, 0x14000, 0,
 | ^~~~
 drivers/pinctrl/tegra/pinctrl-tegra194.c:71:14: note: (near initialization for 
‘tegra194_groups[0].drv_reg’)
 71 | .drv_reg = ((r)), | ^
 drivers/pinctrl/tegra/pinctrl-tegra194.c:105:2: note: in expansion of macro 
‘DRV_PINGROUP_ENTRY_Y’
 105 | DRV_PINGROUP_ENTRY_Y(0x14004, 12, 5, 20, 5, -1, -1, -1, -1, 0)
 | ^~~~
 drivers/pinctrl/tegra/pinctrl-tegra194.c:124:3: note: in expansion of macro 
‘drive_pex_l5_clkreq_n_pgg0’
 124 | drive_##pg_name, | ^~
 drivers/pinctrl/tegra/pinctrl-tegra194.c:128:2: note: in expansion of macro 
‘PINGROUP’
 128 | PINGROUP(pex_l5_clkreq_n_pgg0, PE5, RSVD1, RSVD2, RSVD3, 0x14000, 0,
 | ^~~~
 drivers/pinctrl/tegra/pinctrl-tegra194.c:71:14: warning: initialized field 
overwritten [-Woverride-init]
 71 | .drv_reg = ((r)), | ^
 drivers/pinctrl/tegra/pinctrl-tegra194.c:107:2: note: in expansion of macro 
‘DRV_PINGROUP_ENTRY_Y’
 107 | DRV_PINGROUP_ENTRY_Y(0x1400c, 12, 5, 20, 5, -1, -1, -1, -1, 0)
 | ^~~~
 drivers/pinctrl/tegra/pinctrl-tegra194.c:124:3: note: in expansion of macro 
‘drive_pex_l5_rst_n_pgg1’
 124 | drive_##pg_name, | ^~
 drivers/pinctrl/tegra/pinctrl-tegra194.c:130:2: note: in expansion of macro 
‘PINGROUP’
 130 | PINGROUP(pex_l5_rst_n_pgg1, PE5, RSVD1, RSVD2, RSVD3, 0x14008, 0,
 | ^~~~
 drivers/pinctrl/tegra/pinctrl-tegra194.c:71:14: note: (near initialization for 
‘tegra194_groups[1].drv_reg’)
 71 | .drv_reg = ((r)), | ^
 drivers/pinctrl/tegra/pinctrl-tegra194.c:107:2: note: in expansion of macro 
‘DRV_PINGROUP_ENTRY_Y’
 107 | DRV_PINGROUP_ENTRY_Y(0x1400c, 12, 5, 20, 5, -1, -1, -1, -1, 0)
 | ^~~~
 drivers/pinctrl/tegra/pinctrl-tegra194.c:124:3: note: in expansion of macro 
‘drive_pex_l5_rst_n_pgg1’
 124 | drive_##pg_name, | ^~
 drivers/pinctrl/tegra/pinctrl-tegra194.c:130:2: note: in expansion of macro 
‘PINGROUP’
 130 | PINGROUP(pex_l5_rst_n_pgg1, PE5, RSVD1, RSVD2, RSVD3, 0x14008, 0,
 | ^~~~

Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: linux-te...@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/tegra/pinctrl-tegra194.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pinctrl/tegra/pinctrl-tegra194.c 
b/drivers/pinctrl/tegra/pinctrl-tegra194.c
index 2e0b5f7bb095b..c94ba17243c87 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra194.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra194.c
@@ -98,7 +98,6 @@ static struct tegra_function tegra194_functions[] = {
.sfsel_bit = 10,\
.schmitt_bit = schmitt_b,   \
.drvtype_bit = 13,  \
-   .drv_reg = -1,  \
.parked_bitmask = 0
 
 #define drive_pex_l5_clkreq_n_pgg0 \
-- 
2.25.1

[PATCH 05/25] pinctrl: qcom: pinctrl-msm: Complete 'struct msm_pinctrl' documentation

[Lee Jones]

Add missing descriptions for attributes and fix 1 formatting issue.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/qcom/pinctrl-msm.c:75: warning: Function parameter or member 
'desc' not described in 'msm_pinctrl'
 drivers/pinctrl/qcom/pinctrl-msm.c:75: warning: Function parameter or member 
'irq_chip' not described in 'msm_pinctrl'
 drivers/pinctrl/qcom/pinctrl-msm.c:75: warning: Function parameter or member 
'intr_target_use_scm' not described in 'msm_pinctrl'
 drivers/pinctrl/qcom/pinctrl-msm.c:75: warning: Function parameter or member 
'soc' not described in 'msm_pinctrl'
 drivers/pinctrl/qcom/pinctrl-msm.c:75: warning: Function parameter or member 
'phys_base' not described in 'msm_pinctrl'

Cc: Bjorn Andersson 
Cc: Andy Gross 
Cc: linux-arm-...@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/qcom/pinctrl-msm.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 83b7d64bc4c14..56b36d4b54668 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -40,16 +40,20 @@
  * @dev:device handle.
  * @pctrl:  pinctrl handle.
  * @chip:   gpiochip handle.
+ * @desc:   pin controller descriptor
  * @restart_nb: restart notifier block.
+ * @irq_chip:   irq chip information
  * @irq:parent irq for the TLMM irq_chip.
+ * @intr_target_use_scm: route irq to application cpu using scm calls
  * @lock:   Spinlock to protect register resources as well
  *  as msm_pinctrl data structures.
  * @enabled_irqs:   Bitmap of currently enabled irqs.
  * @dual_edge_irqs: Bitmap of irqs that need sw emulated dual edge
  *  detection.
  * @skip_wake_irqs: Skip IRQs that are handled by wakeup interrupt controller
- * @soc;Reference to soc_data of platform specific data.
+ * @soc:Reference to soc_data of platform specific data.
  * @regs:   Base addresses for the TLMM tiles.
+ * @phys_base:  Physical base address
  */
 struct msm_pinctrl {
struct device *dev;
-- 
2.25.1

[PATCH 04/25] pinctrl: bcm: pinctrl-iproc-gpio: Rename incorrectly documented function param

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/bcm/pinctrl-iproc-gpio.c:141: warning: Function parameter or 
member 'chip' not described in 'iproc_set_bit'
 drivers/pinctrl/bcm/pinctrl-iproc-gpio.c:141: warning: Excess function 
parameter 'iproc_gpio' description in 'iproc_set_bit'

Cc: Ray Jui 
Cc: Scott Branden 
Cc: bcm-kernel-feedback-l...@broadcom.com
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c 
b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index a38f0d5f47ce9..e2bd2dce6bb41 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -131,7 +131,7 @@ static inline unsigned iproc_pin_to_gpio(unsigned pin)
  *  iproc_set_bit - set or clear one bit (corresponding to the GPIO pin) in a
  *  Iproc GPIO register
  *
- *  @iproc_gpio: Iproc GPIO device
+ *  @chip: Iproc GPIO device
  *  @reg: register offset
  *  @gpio: GPIO pin
  *  @set: set or clear
-- 
2.25.1

Re: [PATCH v2 1/2] mm, memcg: reclaim more aggressively before high allocator throttling

[Shakeel Butt]

On Mon, Jul 13, 2020 at 4:42 AM Chris Down  wrote:
>
> In Facebook production, we've seen cases where cgroups have been put
> into allocator throttling even when they appear to have a lot of slack
> file caches which should be trivially reclaimable.
>
> Looking more closely, the problem is that we only try a single cgroup
> reclaim walk for each return to usermode before calculating whether or
> not we should throttle. This single attempt doesn't produce enough
> pressure to shrink for cgroups with a rapidly growing amount of file
> caches prior to entering allocator throttling.
>
> As an example, we see that threads in an affected cgroup are stuck in
> allocator throttling:
>
> # for i in $(cat cgroup.threads); do
> > grep over_high "/proc/$i/stack"
> > done
> [<0>] mem_cgroup_handle_over_high+0x10b/0x150
> [<0>] mem_cgroup_handle_over_high+0x10b/0x150
> [<0>] mem_cgroup_handle_over_high+0x10b/0x150
>
> ...however, there is no I/O pressure reported by PSI, despite a lot of
> slack file pages:
>
> # cat memory.pressure
> some avg10=78.50 avg60=84.99 avg300=84.53 total=5702440903
> full avg10=78.50 avg60=84.99 avg300=84.53 total=5702116959
> # cat io.pressure
> some avg10=0.00 avg60=0.00 avg300=0.00 total=78051391
> full avg10=0.00 avg60=0.00 avg300=0.00 total=78049640
> # grep _file memory.stat
> inactive_file 1370939392
> active_file 661635072
>
> This patch changes the behaviour to retry reclaim either until the
> current task goes below the 10ms grace period, or we are making no
> reclaim progress at all. In the latter case, we enter reclaim throttling
> as before.
>
> To a user, there's no intuitive reason for the reclaim behaviour to
> differ from hitting memory.high as part of a new allocation, as opposed
> to hitting memory.high because someone lowered its value. As such this
> also brings an added benefit: it unifies the reclaim behaviour between
> the two.
>
> There's precedent for this behaviour: we already do reclaim retries when
> writing to memory.{high,max}, in max reclaim, and in the page allocator
> itself.
>
> Signed-off-by: Chris Down 
> Cc: Andrew Morton 
> Cc: Johannes Weiner 
> Cc: Tejun Heo 
> Cc: Michal Hocko 

Reviewed-by: Shakeel Butt 

[PATCH 03/25] pinctrl: bcm: pinctrl-bcm281xx: Demote obvious misuse of kerneldoc to standard comment blocks

[Lee Jones]

There has been little to no attempt to document any of the demoted
structures here.  These are obviously not kerneldoc headers.

Fixes the following W=1 kernel build warning(s):

 drivers/pinctrl/bcm/pinctrl-bcm281xx.c:65: warning: cannot understand function 
prototype: 'enum bcm281xx_pin_type '
 drivers/pinctrl/bcm/pinctrl-bcm281xx.c:79: warning: cannot understand function 
prototype: 'struct bcm281xx_pin_function '
 drivers/pinctrl/bcm/pinctrl-bcm281xx.c:89: warning: cannot understand function 
prototype: 'struct bcm281xx_pinctrl_data '

Cc: Florian Fainelli 
Cc: Ray Jui 
Cc: Scott Branden 
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: YueHaibing 
Signed-off-by: Lee Jones 
---
 drivers/pinctrl/bcm/pinctrl-bcm281xx.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c 
b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
index 71e6661783006..9ab1f427286a7 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
@@ -59,7 +59,7 @@
 #define BCM281XX_HDMI_PIN_REG_MODE_MASK0x0010
 #define BCM281XX_HDMI_PIN_REG_MODE_SHIFT   4
 
-/**
+/*
  * bcm281xx_pin_type - types of pin register
  */
 enum bcm281xx_pin_type {
@@ -73,7 +73,7 @@ static enum bcm281xx_pin_type std_pin = BCM281XX_PIN_TYPE_STD;
 static enum bcm281xx_pin_type i2c_pin = BCM281XX_PIN_TYPE_I2C;
 static enum bcm281xx_pin_type hdmi_pin = BCM281XX_PIN_TYPE_HDMI;
 
-/**
+/*
  * bcm281xx_pin_function- define pin function
  */
 struct bcm281xx_pin_function {
@@ -82,7 +82,7 @@ struct bcm281xx_pin_function {
const unsigned ngroups;
 };
 
-/**
+/*
  * bcm281xx_pinctrl_data - Broadcom-specific pinctrl data
  * @reg_base - base of pinctrl registers
  */
-- 
2.25.1

[PATCH] leds: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 Documentation/devicetree/bindings/leds/leds-lm3532.txt  | 2 +-
 Documentation/devicetree/bindings/leds/leds-lm3601x.txt | 4 ++--
 Documentation/devicetree/bindings/leds/leds-lm36274.txt | 2 +-
 Documentation/devicetree/bindings/leds/leds-lm3692x.txt | 2 +-
 Documentation/devicetree/bindings/leds/leds-lm3697.txt  | 2 +-
 Documentation/devicetree/bindings/leds/leds-lp8860.txt  | 2 +-
 drivers/leds/leds-lm3532.c  | 4 ++--
 drivers/leds/leds-lm3601x.c | 2 +-
 drivers/leds/leds-lm36274.c | 2 +-
 drivers/leds/leds-lm3692x.c | 2 +-
 drivers/leds/leds-lm3697.c  | 2 +-
 11 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/leds-lm3532.txt 
b/Documentation/devicetree/bindings/leds/leds-lm3532.txt
index 53793213dd52..097490a5ff91 100644
--- a/Documentation/devicetree/bindings/leds/leds-lm3532.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lm3532.txt
@@ -102,4 +102,4 @@ led-controller@38 {
 };
 
 For more product information please see the links below:
-http://www.ti.com/product/LM3532
+https://www.ti.com/product/LM3532
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt 
b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
index 095dafb6ec7f..17e940025dc2 100644
--- a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
@@ -47,5 +47,5 @@ led-controller@64 {
 }
 
 For more product information please see the links below:
-http://www.ti.com/product/LM36010
-http://www.ti.com/product/LM36011
+https://www.ti.com/product/LM36010
+https://www.ti.com/product/LM36011
diff --git a/Documentation/devicetree/bindings/leds/leds-lm36274.txt 
b/Documentation/devicetree/bindings/leds/leds-lm36274.txt
index 39c230d59a4d..de6f4931fb31 100644
--- a/Documentation/devicetree/bindings/leds/leds-lm36274.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lm36274.txt
@@ -82,4 +82,4 @@ lm36274@11 {
 };
 
 For more product information please see the link below:
-http://www.ti.com/lit/ds/symlink/lm36274.pdf
+https://www.ti.com/lit/ds/symlink/lm36274.pdf
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt 
b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
index 501468aa4d38..b1103d961d6c 100644
--- a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
@@ -62,4 +62,4 @@ led-controller@36 {
 }
 
 For more product information please see the link below:
-http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
+https://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3697.txt 
b/Documentation/devicetree/bindings/leds/leds-lm3697.txt
index 63992d732959..221b37b6049b 100644
--- a/Documentation/devicetree/bindings/leds/leds-lm3697.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lm3697.txt
@@ -70,4 +70,4 @@ led-controller@36 {
 }
 
 For more product information please see the link below:
-http://www.ti.com/lit/ds/symlink/lm3697.pdf
+https://www.ti.com/lit/ds/symlink/lm3697.pdf
diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt 
b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
index 9863220db4ba..8bb25749a3da 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
@@ -47,4 +47,4 @@ led-controller@2d {
 }
 
 For more product information please see the link below:
-http://www.ti.com/product/lp8860-q1
+https://www.ti.com/product/lp8860-q1
diff --git a/drivers/leds/leds-lm3

Re: [Freedreno] [PATCH 0/9] drm/msm: Avoid possible infinite probe deferral and speed booting

[Jeffrey Hugo]

On Mon, Jul 13, 2020 at 8:11 AM Rob Herring  wrote:
>
> On Fri, Jul 10, 2020 at 5:02 PM Douglas Anderson  
> wrote:
> >
> > I found that if I ever had a little mistake in my kernel config,
> > or device tree, or graphics driver that my system would sit in a loop
> > at bootup trying again and again and again.  An example log was:
>
> Why do we care about optimizing the error case?
>
> >   msm ae0.mdss: bound ae01000.mdp (ops 0xffe596e951f8)
> >   msm_dsi ae94000.dsi: ae94000.dsi supply gdsc not found, using dummy 
> > regulator
> >   msm_dsi_manager_register: failed to register mipi dsi host for DSI 0
> >   [drm:ti_sn_bridge_probe] *ERROR* could not find any panel node
> >   ...
> >
> > I finally tracked it down where this was happening:
> >   - msm_pdev_probe() is called.
> >   - msm_pdev_probe() registers drivers.  Registering drivers kicks
> > off processing of probe deferrals.
> >   - component_master_add_with_match() could return -EPROBE_DEFER.
> > making msm_pdev_probe() return -EPROBE_DEFER.
> >   - When msm_pdev_probe() returned the processing of probe deferrals
> > happens.
> >   - Loop back to the start.
> >
> > It looks like we can fix this by marking "mdss" as a "simple-bus".
> > I have no idea if people consider this the right thing to do or a
> > hack.  Hopefully it's the right thing to do.  :-)
>
> It's a simple test. Do the child devices have any dependency on the
> parent to probe and/or function? If so, not a simple-bus.
>
> > Once I do this I notice that my boot gets marginally faster (you
> > don't need to probe the sub devices over and over) and also if I
>
> Can you quantify that?
>
> Have you run with devlinks enabled. You need a command line option to
> enable. That too should reduce deferred probes.
>
> > have a problem it doesn't loop forever (on my system it still
> > gets upset about some stuck clocks in that case, but at least I
> > can boot up).
>
> Deferred probe only runs when a device is added, so it's not like it
> is continually running.

But it is.  I've hit this as well, but haven't attempted a fix.

So we have a parent device, with several sub devices.  The parent
device probes which causes the sub devices to probe.  One of the sub
devices successfully probes, and another fails with EPROBE_DEFER.
This both caused the probe defer framework to immediately schedule
processing the probe defer queue, and also cause all of the chile
devices and the parent device to be removed to probe defer later.
Since the system state doesn't change (one of the sub devices actually
requires an independent other device to have probed), the system ends
up an an infinite probe defer loop.

Re: [PATCH v9 1/4] driver core: add device probe log helper

[Andy Shevchenko]

On Mon, Jul 13, 2020 at 5:43 PM Andrzej Hajda  wrote:
>
> During probe every time driver gets resource it should usually check for
> error printk some message if it is not -EPROBE_DEFER and return the error.
> This pattern is simple but requires adding few lines after any resource
> acquisition code, as a result it is often omitted or implemented only
> partially.
> dev_err_probe helps to replace such code sequences with simple call,
> so code:
> if (err != -EPROBE_DEFER)
> dev_err(dev, ...);
> return err;
> becomes:
> return dev_err_probe(dev, err, ...);
>

FWIW,
Reviewed-by: Andy Shevchenko 

> Signed-off-by: Andrzej Hajda 
> Reviewed-by: Rafael J. Wysocki 
> Reviewed-by: Mark Brown 
> ---
>  drivers/base/core.c| 42 ++
>  include/linux/device.h |  3 +++
>  2 files changed, 45 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 67d39a90b45c..3a827c82933f 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -3953,6 +3953,48 @@ define_dev_printk_level(_dev_info, KERN_INFO);
>
>  #endif
>
> +/**
> + * dev_err_probe - probe error check and log helper
> + * @dev: the pointer to the struct device
> + * @err: error value to test
> + * @fmt: printf-style format string
> + * @...: arguments as specified in the format string
> + *
> + * This helper implements common pattern present in probe functions for error
> + * checking: print debug or error message depending if the error value is
> + * -EPROBE_DEFER and propagate error upwards.
> + * It replaces code sequence:
> + * if (err != -EPROBE_DEFER)
> + * dev_err(dev, ...);
> + * else
> + * dev_dbg(dev, ...);
> + * return err;
> + * with
> + * return dev_err_probe(dev, err, ...);
> + *
> + * Returns @err.
> + *
> + */
> +int dev_err_probe(const struct device *dev, int err, const char *fmt, ...)
> +{
> +   struct va_format vaf;
> +   va_list args;
> +
> +   va_start(args, fmt);
> +   vaf.fmt = fmt;
> +   vaf.va = &args;

> +   if (err != -EPROBE_DEFER)

I would rather see positive conditional (slightly better to parse when
read), but here I think it's more or less equal.

> +   dev_err(dev, "error %d: %pV", err, &vaf);
> +   else
> +   dev_dbg(dev, "error %d: %pV", err, &vaf);

> +   va_end(args);
> +
> +   return err;
> +}
> +EXPORT_SYMBOL_GPL(dev_err_probe);
> +
>  static inline bool fwnode_is_primary(struct fwnode_handle *fwnode)
>  {
> return fwnode && !IS_ERR(fwnode->secondary);
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 15460a5ac024..6b2272ae9af8 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -964,6 +964,9 @@ void device_link_remove(void *consumer, struct device 
> *supplier);
>  void device_links_supplier_sync_state_pause(void);
>  void device_links_supplier_sync_state_resume(void);
>
> +extern __printf(3, 4)
> +int dev_err_probe(const struct device *dev, int err, const char *fmt, ...);
> +
>  /* Create alias, so I can be autoloaded. */
>  #define MODULE_ALIAS_CHARDEV(major,minor) \
> MODULE_ALIAS("char-major-" __stringify(major) "-" __stringify(minor))
> --
> 2.17.1
>


-- 
With Best Regards,
Andy Shevchenko

[PATCH v4 1/3] devres: provide devm_krealloc()

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Implement the managed variant of krealloc(). This function works with
all memory allocated by devm_kmalloc() (or devres functions using it
implicitly like devm_kmemdup(), devm_kstrdup() etc.).

Managed realloc'ed chunks can be manually released with devm_kfree().

Signed-off-by: Bartosz Golaszewski 
---
 .../driver-api/driver-model/devres.rst|  1 +
 drivers/base/devres.c | 67 +++
 include/linux/device.h|  2 +
 3 files changed, 70 insertions(+)

diff --git a/Documentation/driver-api/driver-model/devres.rst 
b/Documentation/driver-api/driver-model/devres.rst
index efc21134f..f318a5c0033c1 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -354,6 +354,7 @@ MEM
   devm_kmalloc()
   devm_kmalloc_array()
   devm_kmemdup()
+  devm_krealloc()
   devm_kstrdup()
   devm_kvasprintf()
   devm_kzalloc()
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index ed615d3b9cf15..1775d35462300 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -837,6 +837,73 @@ void *devm_kmalloc(struct device *dev, size_t size, gfp_t 
gfp)
 }
 EXPORT_SYMBOL_GPL(devm_kmalloc);
 
+/**
+ * devm_krealloc - Resource-managed krealloc()
+ * @dev: Device to re-allocate memory for
+ * @ptr: Pointer to the memory chunk to re-allocate
+ * @new_size: New allocation size
+ * @gfp: Allocation gfp flags
+ *
+ * Managed krealloc(). Resizes the memory chunk allocated with devm_kmalloc().
+ * Behaves similarly to regular krealloc(): if @ptr is NULL or ZERO_SIZE_PTR,
+ * it's the equivalent of devm_kmalloc(). If new_size is zero, it returns
+ * ZERO_SIZE_PTR. This function doesn't change the order in which the release
+ * callback for the re-alloc'ed devres will be called (except when falling back
+ * to devm_kmalloc()). The contents of the memory are preserved up to the
+ * lesser of new and old sizes.
+ */
+void *devm_krealloc(struct device *dev, void *ptr, size_t new_size, gfp_t gfp)
+{
+   struct devres *old_dr, *new_dr;
+   struct list_head old_head;
+   unsigned long flags;
+   size_t total_size;
+   void *ret = NULL;
+
+   if (unlikely(!new_size)) {
+   devm_kfree(dev, ptr);
+   return ZERO_SIZE_PTR;
+   }
+
+   if (unlikely(ZERO_OR_NULL_PTR(ptr)))
+   return devm_kmalloc(dev, new_size, gfp);
+
+   if (WARN_ON(is_kernel_rodata((unsigned long)ptr)))
+   /*
+* We cannot reliably realloc a const string returned by
+* devm_kstrdup_const().
+*/
+   return NULL;
+
+   if (!check_dr_size(new_size, &total_size))
+   return NULL;
+
+   spin_lock_irqsave(&dev->devres_lock, flags);
+
+   old_dr = find_dr(dev, devm_kmalloc_release, devm_kmalloc_match, ptr);
+   if (!old_dr) {
+   spin_unlock_irqrestore(&dev->devres_lock, flags);
+   WARN(1, "Memory chunk not managed or managed by a different 
device.");
+   return NULL;
+   }
+
+   old_head = old_dr->node.entry;
+
+   new_dr = krealloc(old_dr, total_size, gfp);
+   if (!new_dr) {
+   spin_unlock_irqrestore(&dev->devres_lock, flags);
+   return NULL;
+   }
+
+   if (new_dr != old_dr)
+   list_replace(&old_head, &new_dr->node.entry);
+
+   ret = new_dr->data;
+   spin_unlock_irqrestore(&dev->devres_lock, flags);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(devm_krealloc);
+
 /**
  * devm_kstrdup - Allocate resource managed space and
  *copy an existing string into that.
diff --git a/include/linux/device.h b/include/linux/device.h
index 7322c51e9c0c7..f64f408431593 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -206,6 +206,8 @@ int devres_release_group(struct device *dev, void *id);
 
 /* managed devm_k.alloc/kfree for device drivers */
 void *devm_kmalloc(struct device *dev, size_t size, gfp_t gfp) __malloc;
+void *devm_krealloc(struct device *dev, void *ptr, size_t size,
+   gfp_t gfp) __must_check;
 __printf(3, 0) char *devm_kvasprintf(struct device *dev, gfp_t gfp,
 const char *fmt, va_list ap) __malloc;
 __printf(3, 4) char *devm_kasprintf(struct device *dev, gfp_t gfp,
-- 
2.26.1

[PATCH v4 3/3] iio: adc: xilinx-xadc: use devm_krealloc()

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Use the managed variant of krealloc() and shrink the code a bit.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/iio/adc/xilinx-xadc-core.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/adc/xilinx-xadc-core.c 
b/drivers/iio/adc/xilinx-xadc-core.c
index d7fecab9252e4..5bdbe502e983a 100644
--- a/drivers/iio/adc/xilinx-xadc-core.c
+++ b/drivers/iio/adc/xilinx-xadc-core.c
@@ -1094,6 +1094,7 @@ MODULE_DEVICE_TABLE(of, xadc_of_match_table);
 static int xadc_parse_dt(struct iio_dev *indio_dev, struct device_node *np,
unsigned int *conf)
 {
+   struct device *dev = indio_dev->dev.parent;
struct xadc *xadc = iio_priv(indio_dev);
struct iio_chan_spec *channels, *chan;
struct device_node *chan_node, *child;
@@ -1138,7 +1139,8 @@ static int xadc_parse_dt(struct iio_dev *indio_dev, 
struct device_node *np,
*conf |= XADC_CONF0_MUX | XADC_CONF0_CHAN(ext_mux_chan);
}
 
-   channels = kmemdup(xadc_channels, sizeof(xadc_channels), GFP_KERNEL);
+   channels = devm_kmemdup(dev, xadc_channels,
+   sizeof(xadc_channels), GFP_KERNEL);
if (!channels)
return -ENOMEM;
 
@@ -1174,8 +1176,9 @@ static int xadc_parse_dt(struct iio_dev *indio_dev, 
struct device_node *np,
of_node_put(chan_node);
 
indio_dev->num_channels = num_channels;
-   indio_dev->channels = krealloc(channels, sizeof(*channels) *
-   num_channels, GFP_KERNEL);
+   indio_dev->channels = devm_krealloc(dev, channels,
+   sizeof(*channels) * num_channels,
+   GFP_KERNEL);
/* If we can't resize the channels array, just use the original */
if (!indio_dev->channels)
indio_dev->channels = channels;
@@ -1229,14 +1232,14 @@ static int xadc_probe(struct platform_device *pdev)
 
ret = xadc_parse_dt(indio_dev, pdev->dev.of_node, &conf0);
if (ret)
-   goto err_device_free;
+   return ret;
 
if (xadc->ops->flags & XADC_FLAGS_BUFFERED) {
ret = iio_triggered_buffer_setup(indio_dev,
&iio_pollfunc_store_time, &xadc_trigger_handler,
&xadc_buffer_ops);
if (ret)
-   goto err_device_free;
+   return ret;
 
xadc->convst_trigger = xadc_alloc_trigger(indio_dev, "convst");
if (IS_ERR(xadc->convst_trigger)) {
@@ -1354,8 +1357,6 @@ static int xadc_probe(struct platform_device *pdev)
 err_triggered_buffer_cleanup:
if (xadc->ops->flags & XADC_FLAGS_BUFFERED)
iio_triggered_buffer_cleanup(indio_dev);
-err_device_free:
-   kfree(indio_dev->channels);
 
return ret;
 }
@@ -1375,7 +1376,6 @@ static int xadc_remove(struct platform_device *pdev)
cancel_delayed_work_sync(&xadc->zynq_unmask_work);
clk_disable_unprepare(xadc->clk);
kfree(xadc->data);
-   kfree(indio_dev->channels);
 
return 0;
 }
-- 
2.26.1

[PATCH v4 0/3] devres: provide and use devm_krealloc()

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Regular krealloc() obviously can't work with managed memory. This series
implements devm_krealloc() and adds the first users with hope that this
helper will be adopted by other drivers currently using non-managed
krealloc().

Some additional changes to the code modified by main patches are included.

v1 -> v2:
- remove leftover call to hwmon_device_unregister() from pmbus_core.c
- add a patch extending devm_kmalloc() to handle zero size case
- use WARN_ON() instead of WARN_ONCE() in devm_krealloc() when passed
  a pointer to non-managed memory
- correctly handle the case when devm_krealloc() is passed a pointer to
  memory in .rodata (potentially returned by devm_kstrdup_const())
- correctly handle ZERO_SIZE_PTR passed as the ptr argument in devm_krealloc()

v2 -> v3:
- drop already applied patches
- collect Acks
- add an additional user in iio

v3 -> v4:
- add the kerneldoc for devm_krealloc()
- WARN() outside of spinlock
- rename local variable

Bartosz Golaszewski (3):
  devres: provide devm_krealloc()
  hwmon: pmbus: use more devres helpers
  iio: adc: xilinx-xadc: use devm_krealloc()

 .../driver-api/driver-model/devres.rst|  1 +
 drivers/base/devres.c | 67 +++
 drivers/hwmon/pmbus/pmbus_core.c  | 28 +++-
 drivers/iio/adc/xilinx-xadc-core.c| 16 ++---
 include/linux/device.h|  2 +
 5 files changed, 87 insertions(+), 27 deletions(-)

-- 
2.26.1

[PATCH v4 2/3] hwmon: pmbus: use more devres helpers

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Shrink pmbus code by using devm_hwmon_device_register_with_groups()
and devm_krealloc() instead of their non-managed variants.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Guenter Roeck 
---
 drivers/hwmon/pmbus/pmbus_core.c | 28 +---
 1 file changed, 9 insertions(+), 19 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 44535add3a4a1..91839979cf6c1 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -1018,9 +1018,9 @@ static int pmbus_add_attribute(struct pmbus_data *data, 
struct attribute *attr)
 {
if (data->num_attributes >= data->max_attributes - 1) {
int new_max_attrs = data->max_attributes + 
PMBUS_ATTR_ALLOC_SIZE;
-   void *new_attrs = krealloc(data->group.attrs,
-  new_max_attrs * sizeof(void *),
-  GFP_KERNEL);
+   void *new_attrs = devm_krealloc(data->dev, data->group.attrs,
+   new_max_attrs * sizeof(void *),
+   GFP_KERNEL);
if (!new_attrs)
return -ENOMEM;
data->group.attrs = new_attrs;
@@ -2534,7 +2534,7 @@ int pmbus_do_probe(struct i2c_client *client, const 
struct i2c_device_id *id,
 
ret = pmbus_find_attributes(client, data);
if (ret)
-   goto out_kfree;
+   return ret;
 
/*
 * If there are no attributes, something is wrong.
@@ -2542,35 +2542,27 @@ int pmbus_do_probe(struct i2c_client *client, const 
struct i2c_device_id *id,
 */
if (!data->num_attributes) {
dev_err(dev, "No attributes found\n");
-   ret = -ENODEV;
-   goto out_kfree;
+   return -ENODEV;
}
 
data->groups[0] = &data->group;
memcpy(data->groups + 1, info->groups, sizeof(void *) * groups_num);
-   data->hwmon_dev = hwmon_device_register_with_groups(dev, client->name,
-   data, data->groups);
+   data->hwmon_dev = devm_hwmon_device_register_with_groups(dev,
+   client->name, data, data->groups);
if (IS_ERR(data->hwmon_dev)) {
-   ret = PTR_ERR(data->hwmon_dev);
dev_err(dev, "Failed to register hwmon device\n");
-   goto out_kfree;
+   return PTR_ERR(data->hwmon_dev);
}
 
ret = pmbus_regulator_register(data);
if (ret)
-   goto out_unregister;
+   return ret;
 
ret = pmbus_init_debugfs(client, data);
if (ret)
dev_warn(dev, "Failed to register debugfs\n");
 
return 0;
-
-out_unregister:
-   hwmon_device_unregister(data->hwmon_dev);
-out_kfree:
-   kfree(data->group.attrs);
-   return ret;
 }
 EXPORT_SYMBOL_GPL(pmbus_do_probe);
 
@@ -2580,8 +2572,6 @@ int pmbus_do_remove(struct i2c_client *client)
 
debugfs_remove_recursive(data->debugfs);
 
-   hwmon_device_unregister(data->hwmon_dev);
-   kfree(data->group.attrs);
return 0;
 }
 EXPORT_SYMBOL_GPL(pmbus_do_remove);
-- 
2.26.1

Re: [PATCH v6 2/2] devicetree: hwmon: shtc1: Add sensirion,shtc1.yaml

[Rob Herring]

On Sun, 12 Jul 2020 12:44:10 +0800, Chris Ruehl wrote:
> Add documentation for the newly added DTS support in the shtc1 driver.
> To align with the drivers logic to have high precision by default
> a boolean sensirion,low_precision is used to switch to low precision.
> 
> Signed-off-by: Chris Ruehl 
> ---
>  .../bindings/hwmon/sensirion,shtc1.yaml   | 57 +++
>  1 file changed, 57 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

Documentation/devicetree/bindings/hwmon/sensirion,shtc1.example.dts:24.13-26: 
Warning (reg_format): /example-0/i2c1/shtc3@70:reg: property has invalid length 
(4 bytes) (#address-cells == 2, #size-cells == 1)
Documentation/devicetree/bindings/hwmon/sensirion,shtc1.example.dt.yaml: 
Warning (pci_device_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/hwmon/sensirion,shtc1.example.dt.yaml: 
Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/hwmon/sensirion,shtc1.example.dt.yaml: 
Warning (simple_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/hwmon/sensirion,shtc1.example.dt.yaml: 
Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/hwmon/sensirion,shtc1.example.dt.yaml: 
Warning (spi_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/hwmon/sensirion,shtc1.example.dts:22.20-26.13:
 Warning (avoid_default_addr_size): /example-0/i2c1/shtc3@70: Relying on 
default #address-cells value
Documentation/devicetree/bindings/hwmon/sensirion,shtc1.example.dts:22.20-26.13:
 Warning (avoid_default_addr_size): /example-0/i2c1/shtc3@70: Relying on 
default #size-cells value
Documentation/devicetree/bindings/hwmon/sensirion,shtc1.example.dt.yaml: 
Warning (unique_unit_address): Failed prerequisite 'avoid_default_addr_size'


See https://patchwork.ozlabs.org/patch/1327453

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

[PATCH] lib: reciprocal_div: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 include/linux/reciprocal_div.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/reciprocal_div.h b/include/linux/reciprocal_div.h
index 585ce89c0f33..362f6d772e27 100644
--- a/include/linux/reciprocal_div.h
+++ b/include/linux/reciprocal_div.h
@@ -11,7 +11,7 @@
  *
  * The assembler implementation from Agner Fog, which this code is
  * based on, can be found here:
- * http://www.agner.org/optimize/asmlib.zip
+ * https://www.agner.org/optimize/asmlib.zip
  *
  * This optimization for A/B is helpful if the divisor B is mostly
  * runtime invariant. The reciprocal of B is calculated in the
-- 
2.27.0

Re: [RFC PATCH 0/4] thermal: Introduce support for monitoring falling temperature

[Daniel Lezcano]

On 10/07/2020 15:51, Thara Gopinath wrote:
> Thermal framework today supports monitoring for rising temperatures and
> subsequently initiating cooling action in case of a thermal trip point
> being crossed. There are scenarios where a SoC need some warming action to
> be activated if the temperature falls below a cetain permissible limit.
> Since warming action can be considered mirror opposite of cooling action,
> most of the thermal framework can be re-used to achieve this.
> 
> This patch series is yet another attempt to add support for monitoring
> falling temperature in thermal framework. Unlike the first attempt[1]
> (where a new property was added to thermal trip point binding to indicate
> direction of temperature monitoring), this series introduces a new trip
> point type (THERMAL_TRIP_COLD) to indicate a trip point at which falling
> temperature monitoring must be triggered. This patch series uses Daniel
> Lezcano's recently added thermal genetlink interface[2] to notify userspace
> of falling temperature and rising temperature at the cold trip point. This
> will enable a user space engine to trigger the relevant mitigation for
> falling temperature. At present, no support is added to any of the thermal
> governors to monitor and mitigate falling temperature at the cold trip
> point;rather all governors return doing nothing if triggered for a cold
> trip point. As future extension, monitoring of falling temperature can be
> added to the relevant thermal governor. 

I agree we need a cold trip point in order to introduce the functioning
temperature range in the thermal framework.

Rui, what is your opinion ?



-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH][next] drm/i915/selftest: fix an error return path where err is not being set

[Chris Wilson]

Quoting Colin King (2020-07-13 15:25:51)
> From: Colin Ian King 
> 
> There is an error condition where err is not being set and an uninitialized
> garbage value in err is being returned.  Fix this by assigning err to an
> appropriate error return value before taking the error exit path.
> 
> Addresses-Coverity: ("Uninitialized scalar value")
> Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across 
> noa_wait")
> Signed-off-by: Colin Ian King 

Thanks, pushed.
-Chris

Re: [PATCH v5] ima: move APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime

[Bruno Meneguele]

On Fri, Jul 10, 2020 at 04:25:16PM -0300, Bruno Meneguele wrote:
> On Fri, Jul 10, 2020 at 02:54:48PM -0400, Mimi Zohar wrote:
> > On Fri, 2020-07-10 at 15:34 -0300, Bruno Meneguele wrote:
> > > On Fri, Jul 10, 2020 at 03:03:38PM -0300, Bruno Meneguele wrote:
> > > > On Fri, Jul 10, 2020 at 01:23:24PM -0400, Mimi Zohar wrote:
> > > > > On Thu, 2020-07-09 at 13:46 -0300, Bruno Meneguele wrote:
> > > > > > APPRAISE_BOOTPARAM has been marked as dependent on !ARCH_POLICY in 
> > > > > > compile
> > > > > > time, enforcing the appraisal whenever the kernel had the arch 
> > > > > > policy option
> > > > > > enabled.
> > > > > 
> > > > > > However it breaks systems where the option is set but the system 
> > > > > > didn't
> > > > > > boot in a "secure boot" platform. In this scenario, anytime an 
> > > > > > appraisal
> > > > > > policy (i.e. ima_policy=appraisal_tcb) is used it will be forced, 
> > > > > > without
> > > > > > giving the user the opportunity to label the filesystem, before 
> > > > > > enforcing
> > > > > > integrity.
> > > > > > 
> > > > > > Considering the ARCH_POLICY is only effective when secure boot is 
> > > > > > actually
> > > > > > enabled this patch remove the compile time dependency and move it 
> > > > > > to a
> > > > > > runtime decision, based on the secure boot state of that platform.
> > > > > 
> > > > > Perhaps we could simplify this patch description a bit?
> > > > > 
> > > > > The IMA_APPRAISE_BOOTPARAM config allows enabling different
> > > > > "ima_appraise=" modes - log, fix, enforce - at run time, but not when
> > > > > IMA architecture specific policies are enabled.  This prevents
> > > > > properly labeling the filesystem on systems where secure boot is
> > > > > supported, but not enabled on the platform.  Only when secure boot is
> > > > > enabled, should these IMA appraise modes be disabled.
> > > > > 
> > > > > This patch removes the compile time dependency and makes it a runtime
> > > > > decision, based on the secure boot state of that platform.
> > > > > 
> > > > 
> > > > Sounds good to me.
> > > > 
> > > > > 
> > > > > 
> > > > > > diff --git a/security/integrity/ima/ima_appraise.c 
> > > > > > b/security/integrity/ima/ima_appraise.c
> > > > > > index a9649b04b9f1..884de471b38a 100644
> > > > > > --- a/security/integrity/ima/ima_appraise.c
> > > > > > +++ b/security/integrity/ima/ima_appraise.c
> > > > > > @@ -19,6 +19,11 @@
> > > > > >  static int __init default_appraise_setup(c
> > > > > 
> > > > > > har *str)
> > > > > >  {
> > > > > >  #ifdef CONFIG_IMA_APPRAISE_BOOTPARAM
> > > > > > +   if (arch_ima_get_secureboot()) {
> > > > > > +   pr_info("appraise boot param ignored: secure boot 
> > > > > > enabled");
> > > > > 
> > > > > Instead of a generic statement, is it possible to include the actual
> > > > > option being denied?  Perhaps something like: "Secure boot enabled,
> > > > > ignoring %s boot command line option"
> > > > > 
> > > > > Mimi
> > > > > 
> > > > 
> > > > Yes, sure.
> > > > 
> > > 
> > > Btw, would it make sense to first make sure we have a valid "str"
> > > option and not something random to print?
> > >  
> > > diff --git a/security/integrity/ima/ima_appraise.c 
> > > b/security/integrity/ima/ima_appraise.c
> > > index a9649b04b9f1..1f1175531d3e 100644
> > > --- a/security/integrity/ima/ima_appraise.c
> > > +++ b/security/integrity/ima/ima_appraise.c
> > > @@ -25,6 +25,16 @@ static int __init default_appraise_setup(char *str)
> > > ima_appraise = IMA_APPRAISE_LOG;
> > > else if (strncmp(str, "fix", 3) == 0)
> > > ima_appraise = IMA_APPRAISE_FIX;
> > > +   else
> > > +   pr_info("invalid \"%s\" appraise option");
> > > +
> > > +   if (arch_ima_get_secureboot()) {
> > > +   if (!is_ima_appraise_enabled()) {
> > > +   pr_info("Secure boot enabled: ignoring 
> > > ima_appraise=%s boot parameter option",
> > > +   str);
> > > +   ima_appraise = IMA_APPRAISE_ENFORCE;
> > > +   }
> > > +   }
> > 
> > Providing feedback is probably a good idea.  However, the
> > "arch_ima_get_secureboot" test can't come after setting
> > "ima_appraise."
> > 
> 
> Sorry, but I'm not sure if I got the reason to why it can't be done
> after: would it be basically to prevent any further processing about
> ima_appraise as a matter of security principle? Or maybe to keep the
> dependency between secureboot and bootparam truly strict? 
> 
> Or are there something else I'm missing?
> 

I'm going to send a v6 with the pr_info() placed in the beginning
directly printing 'str', thus we can have the actual issue solved. 

Then later I send another patches to handle the other cases of limiting
'str' printing and also giving the user a feedback about invalid
ima_appraise= options. So we can discuss further on that.

Thanks Mimi.

> > Mimi
> > 
> > >  #endif
> > > return 1;
> > >  }
> > > 
> > > 
> > > The "

Re: [RFC PATCH 1/4] dt-bindings:thermal:Add cold trip point type

[Daniel Lezcano]

On 10/07/2020 15:51, Thara Gopinath wrote:
> Extend thermal trip point type property to include "cold" trip type
> indicating point in the temperature domain below which a warming action
> must be intiated.
> 
> Signed-off-by: Thara Gopinath 
> ---
>  Documentation/devicetree/bindings/thermal/thermal.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
> b/Documentation/devicetree/bindings/thermal/thermal.txt
> index f78bec19ca35..1689d9ba1471 100644
> --- a/Documentation/devicetree/bindings/thermal/thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -87,6 +87,7 @@ Required properties:
>   "active":   A trip point to enable active cooling
>   "passive":  A trip point to enable passive cooling
>   "hot":  A trip point to notify emergency
> + "cold": A trip point to enable warming
>   "critical": Hardware not reliable.
>Type: string


thermal.txt should have been removed. Perhaps, a patch is missing. The
thermal.txt has been converted into 3 yaml schema.

The change should be in thermal-zones.yaml.


-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [Tech-board-discuss] [Ksummit-discuss] [PATCH v3] CodingStyle: Inclusive Terminology

[James Bottomley]

On Mon, 2020-07-13 at 10:02 +0200, Takashi Iwai wrote:
> On Wed, 08 Jul 2020 20:14:27 +0200,
> Dan Williams wrote:
> > 
> > +Recommended replacements for 'blacklist/whitelist' are:
> > +'denylist / allowlist'
> > +'blocklist / passlist'
> 
> I started looking through the tree now and noticed there are lots of
> patterns like "whitelisted" or "blacklisted".  How can the words fit
> for those?  Actually, there are two cases like:
> 
> - Foo is blacklisted
> - Allow to load the non-whitelisted cards
> 
> Currently I'm replacing the former with "Foo is in denylist", but not
> sure about the latter case.  I thought Kees mentioned about this, but
> don't remember the proposal...

Remember these are suggestions for going forwards, not requirements for
changing everything.  We tend to be a community that likes make work
projects because they're easier to do than solving the hard problems,
but since we have over 100k occurrences of the various words in the
kernel, changing them all would cause massive churn and disrupt forward
development, which would cause way more harm than any gain from the
change.

James

Re: [PATCH v5 1/2] dt-bindings: phy: Add USB PHY support for Intel LGM SoC

[Rob Herring]

On Mon, 13 Jul 2020 16:54:52 +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan 
> 
> Add the dt-schema to support USB PHY on Intel LGM SoC
> 
> Signed-off-by: Ramuthevar Vadivel Murugan 
> 
> Reviewed-by: Rob Herring 
> ---
>  .../devicetree/bindings/phy/intel,lgm-usb-phy.yaml | 53 
> ++
>  1 file changed, 53 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml: $id: relative 
path/filename doesn't match actual path or filename
expected: http://devicetree.org/schemas/phy/intel,lgm-usb-phy.yaml#


See https://patchwork.ozlabs.org/patch/1327785

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

Re: [PATCH v5 1/2] dt-bindings: phy: Add USB PHY support for Intel LGM SoC

[Rob Herring]

On Mon, Jul 13, 2020 at 04:54:52PM +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan 
> 
> Add the dt-schema to support USB PHY on Intel LGM SoC
> 
> Signed-off-by: Ramuthevar Vadivel Murugan 
> 
> Reviewed-by: Rob Herring 
> ---
>  .../devicetree/bindings/phy/intel,lgm-usb-phy.yaml | 53 
> ++
>  1 file changed, 53 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml 
> b/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
> new file mode 100644
> index ..0fc76cd23774
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/intel,lgm-usb-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel LGM USB PHY Device Tree Bindings
> +
> +maintainers:
> +  - Vadivel Murugan Ramuthevar 
> +
> +properties:
> +  compatible:
> +const: intel,lgm-usb-phy
> +
> +  reg:
> +maxItems: 1
> +
> +  clocks:
> +maxItems: 1
> +
> +  resets:
> +items:
> +  - description: USB PHY and Host controller reset
> +  - description: APB BUS reset
> +  - description: General Hardware reset
> +
> +  reset-names:
> +items:
> +  - const: phy
> +  - const: apb
> +  - const: phy31
> +
> +required:
> +  - compatible
> +  - clocks
> +  - reg
> +  - resets
> +  - reset-names
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +usb_phy: usb_phy@e7e0 {

usb-phy@...

> +compatible = "intel,lgm-usb-phy";
> +reg = <0xe7e0 0x1>;
> +clocks = <&cgu0 153>;
> +resets = <&rcu 0x70 0x24>,
> + <&rcu 0x70 0x26>,
> + <&rcu 0x70 0x28>;
> +reset-names = "phy", "apb", "phy31";
> +};
> -- 
> 2.11.0
> 

Re: [PATCH 0/9] drm/msm: Avoid possible infinite probe deferral and speed booting

[Doug Anderson]

Hi,

On Mon, Jul 13, 2020 at 7:11 AM Rob Herring  wrote:
>
> On Fri, Jul 10, 2020 at 5:02 PM Douglas Anderson  
> wrote:
> >
> > I found that if I ever had a little mistake in my kernel config,
> > or device tree, or graphics driver that my system would sit in a loop
> > at bootup trying again and again and again.  An example log was:
>
> Why do we care about optimizing the error case?

It actually results in a _fully_ infinite loop.  That is: if anything
small causes a component of DRM to fail to probe then the whole system
doesn't boot because it just loops trying to probe over and over
again.  The messages I put in the commit message are printed over and
over and over again.


> >   msm ae0.mdss: bound ae01000.mdp (ops 0xffe596e951f8)
> >   msm_dsi ae94000.dsi: ae94000.dsi supply gdsc not found, using dummy 
> > regulator
> >   msm_dsi_manager_register: failed to register mipi dsi host for DSI 0
> >   [drm:ti_sn_bridge_probe] *ERROR* could not find any panel node
> >   ...
> >
> > I finally tracked it down where this was happening:
> >   - msm_pdev_probe() is called.
> >   - msm_pdev_probe() registers drivers.  Registering drivers kicks
> > off processing of probe deferrals.
> >   - component_master_add_with_match() could return -EPROBE_DEFER.
> > making msm_pdev_probe() return -EPROBE_DEFER.
> >   - When msm_pdev_probe() returned the processing of probe deferrals
> > happens.
> >   - Loop back to the start.
> >
> > It looks like we can fix this by marking "mdss" as a "simple-bus".
> > I have no idea if people consider this the right thing to do or a
> > hack.  Hopefully it's the right thing to do.  :-)
>
> It's a simple test. Do the child devices have any dependency on the
> parent to probe and/or function? If so, not a simple-bus.

Great!  You can see in the earlier patch in the series that the very
first thing that happens when the parent device probes is that it
calls devm_of_platform_populate().  That means no dependencies, right?
 So that means it's fine/correct to add "simple-bus" here?


> > Once I do this I notice that my boot gets marginally faster (you
> > don't need to probe the sub devices over and over) and also if I
>
> Can you quantify that?

I'd say < 100 us.  I can try to quantify more if needed, but it wasn't
the point of this patch.


> Have you run with devlinks enabled. You need a command line option to
> enable. That too should reduce deferred probes.

Ah, good idea!  I will try it.  However, even with devlinks, if there
is any chance of deferred probes then we need a fix like this.  The
point of the patch isn't about speeding things up but about avoiding
an infinite loop at bootup due to a small bug.


> > have a problem it doesn't loop forever (on my system it still
> > gets upset about some stuck clocks in that case, but at least I
> > can boot up).
>
> Deferred probe only runs when a device is added, so it's not like it
> is continually running.

If you don't mind looking at the code patch, see:

https://lore.kernel.org/r/20200710160131.4.I358ea82de218ea5f4406572ade23f5e121297555@changeid/

Specifically you can see that each time we try to probe we were
calling of_platform_populate().  That appeared to be enough to trigger
things.


-Doug

Re: [PATCH v9 4/7] iommu/arm-smmu: Add a pointer to the attached device to smmu_domain

[Will Deacon]

On Fri, Jun 26, 2020 at 02:00:38PM -0600, Jordan Crouse wrote:
> Add a link to the pointer to the struct device that is attached to a
> domain. This makes it easy to get the pointer if it is needed in the
> implementation specific code.
> 
> Signed-off-by: Jordan Crouse 
> ---
> 
>  drivers/iommu/arm-smmu.c | 6 --
>  drivers/iommu/arm-smmu.h | 1 +
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 048de2681670..060139452c54 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -668,7 +668,8 @@ static void arm_smmu_write_context_bank(struct 
> arm_smmu_device *smmu, int idx)
>  }
>  
>  static int arm_smmu_init_domain_context(struct iommu_domain *domain,
> - struct arm_smmu_device *smmu)
> + struct arm_smmu_device *smmu,
> + struct device *dev)
>  {
>   int irq, start, ret = 0;
>   unsigned long ias, oas;
> @@ -801,6 +802,7 @@ static int arm_smmu_init_domain_context(struct 
> iommu_domain *domain,
>   cfg->asid = cfg->cbndx;
>  
>   smmu_domain->smmu = smmu;
> + smmu_domain->dev = dev;
>  
>   pgtbl_cfg = (struct io_pgtable_cfg) {
>   .pgsize_bitmap  = smmu->pgsize_bitmap,
> @@ -1190,7 +1192,7 @@ static int arm_smmu_attach_dev(struct iommu_domain 
> *domain, struct device *dev)
>   return ret;
>  
>   /* Ensure that the domain is finalised */
> - ret = arm_smmu_init_domain_context(domain, smmu);
> + ret = arm_smmu_init_domain_context(domain, smmu, dev);
>   if (ret < 0)
>   goto rpm_put;
>  
> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> index 5f2de20e883b..d33cfe26b2f5 100644
> --- a/drivers/iommu/arm-smmu.h
> +++ b/drivers/iommu/arm-smmu.h
> @@ -345,6 +345,7 @@ struct arm_smmu_domain {
>   struct mutexinit_mutex; /* Protects smmu pointer */
>   spinlock_t  cb_lock; /* Serialises ATS1* ops and 
> TLB syncs */
>   struct iommu_domain domain;
> + struct device   *dev;   /* Device attached to this 
> domain */

This really doesn't feel right to me -- you can generally have multiple
devices attached to a domain and they can come and go without the domain
being destroyed. Perhaps you could instead identify the GPU during
cfg_probe() and squirrel that information away somewhere?

The rest of the series looks ok to me.

Will

Re: [PATCH] virtio_balloon: clear modern features under legacy

[Alexander Duyck]

On Sun, Jul 12, 2020 at 8:10 AM Michael S. Tsirkin  wrote:
>
> On Fri, Jul 10, 2020 at 09:13:41AM -0700, Alexander Duyck wrote:
> > On Fri, Jul 10, 2020 at 4:31 AM Michael S. Tsirkin  wrote:
> > >
> > > Page reporting features were never supported by legacy hypervisors.
> > > Supporting them poses a problem: should we use native endian-ness (like
> > > current code assumes)? Or little endian-ness like the virtio spec says?
> > > Rather than try to figure out, and since results of
> > > incorrect endian-ness are dire, let's just block this configuration.
> > >
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Michael S. Tsirkin 
> >
> > So I am not sure about the patch description. In the case of page
> > poison and free page reporting I don't think we are defining anything
> > that doesn't already have a definition of how to use in legacy.
> > Specifically the virtio_balloon_config is already defined as having
> > all fields as little endian in legacy mode, and there is a definition
> > for all of the fields in a virtqueue and how they behave in legacy
> > mode.
> >
> > As far as I can see the only item that may be an issue is the command
> > ID being supplied via the virtqueue for free page hinting, which
> > appears to be in native endian-ness. Otherwise it would have fallen
> > into the same category since it is making use of virtio_balloon_config
> > and a virtqueue for supplying the page location and length.
>
>
>
> So as you point out correctly balloon spec says all fields are little
> endian.  Fair enough.
> Problem is when virtio 1 is not negotiated, then this is not what the
> driver assumes for any except a handlful of fields.
>
> But yes it mostly works out.
>
> For example:
>
>
> static void update_balloon_size(struct virtio_balloon *vb)
> {
> u32 actual = vb->num_pages;
>
> /* Legacy balloon config space is LE, unlike all other devices. */
> if (!virtio_has_feature(vb->vdev, VIRTIO_F_VERSION_1))
> actual = (__force u32)cpu_to_le32(actual);
>
> virtio_cwrite(vb->vdev, struct virtio_balloon_config, actual,
>   &actual);
> }
>
>
> this is LE even without VIRTIO_F_VERSION_1, so matches spec.
>
> /* Start with poison val of 0 representing general init */
> __u32 poison_val = 0;
>
> /*
>  * Let the hypervisor know that we are expecting a
>  * specific value to be written back in balloon pages.
>  */
> if (!want_init_on_free())
> memset(&poison_val, PAGE_POISON, sizeof(poison_val));
>
> virtio_cwrite(vb->vdev, struct virtio_balloon_config,
>   poison_val, &poison_val);
>
>
> actually this writes a native endian-ness value. All bytes happen to be
> the same though, and host only cares about 0 or non 0 ATM.

So we are safe assuming it is a repeating value, but for correctness
maybe we should make certain to cast this as a le32 value. I can
submit a patch to do that.

> As you say correctly the command id is actually assumed native endian:
>
>
> static u32 virtio_balloon_cmd_id_received(struct virtio_balloon *vb)
> {
> if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID,
>&vb->config_read_bitmap))
> virtio_cread(vb->vdev, struct virtio_balloon_config,
>  free_page_hint_cmd_id,
>  &vb->cmd_id_received_cache);
>
> return vb->cmd_id_received_cache;
> }
>
>
> So guest assumes native, host assumes LE.

This wasn't even the one I was talking about, but now that you point
it out this is definately bug. The command ID I was talking about was
the one being passed via the descriptor ring. That one I believe is
native on both sides.

>
>
>
> > > ---
> > >  drivers/virtio/virtio_balloon.c | 9 +
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/virtio/virtio_balloon.c 
> > > b/drivers/virtio/virtio_balloon.c
> > > index 5d4b891bf84f..b9bc03345157 100644
> > > --- a/drivers/virtio/virtio_balloon.c
> > > +++ b/drivers/virtio/virtio_balloon.c
> > > @@ -1107,6 +1107,15 @@ static int virtballoon_restore(struct 
> > > virtio_device *vdev)
> > >
> > >  static int virtballoon_validate(struct virtio_device *vdev)
> > >  {
> > > +   /*
> > > +* Legacy devices never specified how modern features should 
> > > behave.
> > > +* E.g. which endian-ness to use? Better not to assume anything.
> > > +*/
> > > +   if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> > > +   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT);
> > > +   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
> > > +   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_REPORTING);
> > > +   }
> > > /*
> > >  * Inform the hypervisor that our pages are poisoned or
> > > 

Re: [PATCH] iommu/arm-smmu: Add a init_context_bank implementation hook

[Will Deacon]

On Thu, Jun 11, 2020 at 04:36:56PM -0600, Jordan Crouse wrote:
> Add a new implementation hook to allow the implementation specific code
> to tweek the context bank configuration just before it gets written.
> The first user will be the Adreno GPU implementation to turn on
> SCTLR.HUPCF to ensure that a page fault doesn't terminating pending
> transactions. Doing so could hang the GPU if one of the terminated
> transactions is a CP read.
> 
> This depends on the arm-smmu adreno SMMU implementation [1].
> 
> [1] https://patchwork.kernel.org/patch/11600943/
> 
> Signed-off-by: Jordan Crouse 
> ---
> 
>  drivers/iommu/arm-smmu-qcom.c | 13 +
>  drivers/iommu/arm-smmu.c  | 28 +---
>  drivers/iommu/arm-smmu.h  | 11 +++
>  3 files changed, 37 insertions(+), 15 deletions(-)

This looks straightforward enough, but I don't want to merge this without
a user and Sai's series has open questions afaict.

Will

[PATCH] ACPI: Only create numa nodes from entries in SRAT or SRAT emulation.

[Jonathan Cameron]

Here, I will use the term Proximity Domains for the ACPI description and
Numa Nodes for the in kernel representation.

Until ACPI 6.3 it was arguably possible to interpret the specification as
allowing _PXM in DSDT and similar to define additional Proximity Domains.

The reality was that was never the intent, and a 'clarification' was added
in ACPI 6.3 [1].  In practice I think the kernel has never allowed any other
interpretaion, except possibly on adhoc base within some out of tree driver
(using it very very carefully given potential to crash when using various
standard calls such as devm_kzalloc).

Proximity Domains are always defined in SRAT.  In ACPI, there are methods
defined in ACPI to allow their characteristics to be tweaked later but
Proximity Domains have to be referenced in this table at boot, thus
allowing Linux to instantiate relevant Numa Node data structures.

We ran into a problem when enabling _PXM handling for PCI devices and found
there were boards out there advertising devices in proximity domains that
didn't exist [2].

The fix suggested here is to modfiy the function acpi_map_pxm_to_node.
This function is both used to create and lookup proximity domains.
A parameter is added to specify whether it should create a new
proximity domain when it encounters a Proximity Domain ID that it
hasn't seen before.

Naturally there is a quirk.  For SRAT ITS entries on ARM64 the handling is
done with an additional pass of SRAT, potentially later in the boot. We
could modify that behaviour so we could identify the existence of Proximity
Domains unique to the ITS structures, and handle them as a special case
of a Genric Initiator (once support for those merges) however...

Currently (5.8-rc2) setting the Proximity Domain of an ITS to one that hasn't
been instantiated by being specified in another type of SRAT resource entry
results in:

ITS [mem 0x20210-0x20211]
ITS@0x00020210: Using ITS number 0
Unable to handle kernel paging request at virtual address 1a08
Mem abort info:
ESR = 0x9604
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0004
CM = 0, WnR = 0
[1a08] user address but active_mm is swapper
Internal error: Oops: 9604 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G   A  5.8.0-rc2 #483
pstate: 8089 (Nzcv daIf -PAN -UAO BTYPE=--)
pc : __alloc_pages_nodemask+0xe8/0x338
lr : __alloc_pages_nodemask+0xc0/0x338
sp : a81540c139b0
x29: a81540c139b0 x28: 0001
x27: 0100 x26: a81540c1ad38
x25:  x24: 
x23: a81540c23c00 x22: 0004
x21: 0002 x20: 1a00
x19: 0100 x18: 0010
x17: 0001f000 x16: 007f
x15: a81540c24070 x14: 
x13: a815c0c137d7 x12: a81540c137e4
x11: a81540c3e000 x10: a81540ecee68
x9 : a8153f0f61d8 x8 : a81540ecf000
x7 : 0141 x6 : a81540ecf401
x5 :  x4 : 
x3 :  x2 : 
x1 : 0081 x0 : 1a00
Call trace:
 __alloc_pages_nodemask+0xe8/0x338
 alloc_pages_node.constprop.0+0x34/0x40
 its_probe_one+0x2f8/0xb18
 gic_acpi_parse_madt_its+0x108/0x150
 acpi_table_parse_entries_array+0x17c/0x264
 acpi_table_parse_entries+0x48/0x6c
 acpi_table_parse_madt+0x30/0x3c
 its_init+0x1c4/0x644
 gic_init_bases+0x4b8/0x4ec
 gic_acpi_init+0x134/0x264
 acpi_match_madt+0x4c/0x84
 acpi_table_parse_entries_array+0x17c/0x264
 acpi_table_parse_entries+0x48/0x6c
 acpi_table_parse_madt+0x30/0x3c
 __acpi_probe_device_table+0x8c/0xe8
 irqchip_init+0x3c/0x48
 init_IRQ+0xcc/0x100
 start_kernel+0x33c/0x548

As we die in this case in existing kernels, we can be fairly sure that no one
actually has such a firmware in production.  As such this patch avoids the
complexity that would be needed to handle this corner case, and simply does
not allow the ITS entry parsing code to instantiate new Numa Nodes.  If one
is encountered that does not already exist, then NO_NUMA_NODE is assigned
and a warning printed just as if the value had been greater than allowed
Numa Nodes.

"SRAT: Invalid NUMA node -1 in ITS affinity"

I have only tested this for now on our ARM64 Kunpeng920 servers and
a range of qemu x86 and arm64 configurations.

Note minor merge issue with Dan William's series [3].  Merge fixes should be
straight forward.

[1] Note in ACPI Specification 6.3 5.2.16 System Resource Affinity Table (SRAT)
[2] https://patchwork.kernel.org/patch/1059/
[3] https://lore.kernel.org/patchwork/cover/1271398/

Signed-off-by: Jonathan Cameron 
---

Possible open questions:
* should we warn about a broken firmware trying to assign any device
  to a non existent Proximity Domain?
* previously an smmuv3 in IORT with a Proximity Domain set to a non existent
  value would have resulted in a failure to add the devi

Re: [PATCH] spi: spidev: Add compatible for external SPI ports on Kontron boards

[Mark Brown]

On Mon, Jul 13, 2020 at 03:19:52PM +0200, Frieder Schrempf wrote:

> I would have expected that there is some kind of existing userspace API to
> load an overlay manually, but it seems like there isn't!?

> So what's the reasoning behind this? How can I solve this in a
> mainline-compliant way, meaning without either keeping downstream patches to
> bind spidev to my device or writing and maintaining code that does the
> overlay loading?

Basically the reasoning is that nobody's done it rather than any grand
design not to do it.  There's some issues for more complex connectors
present on multiple boards with mapping the same connector onto multiple
boards where a resource on the connector might be provided by different
things on the base board so it's not quite as trivial for them as it
should be.


signature.asc
Description: PGP signature

[PATCH] mailbox: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/mailbox/omap-mailbox.c | 2 +-
 drivers/mailbox/ti-msgmgr.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 5978a35aac6d..93fe08aef3ca 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -3,7 +3,7 @@
  * OMAP mailbox driver
  *
  * Copyright (C) 2006-2009 Nokia Corporation. All rights reserved.
- * Copyright (C) 2013-2019 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2013-2019 Texas Instruments Incorporated - https://www.ti.com
  *
  * Contact: Hiroshi DOYU 
  *  Suman Anna 
diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index 88047d835211..0130628f4d9d 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -2,7 +2,7 @@
 /*
  * Texas Instruments' Message Manager Driver
  *
- * Copyright (C) 2015-2017 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2015-2017 Texas Instruments Incorporated - https://www.ti.com/
  * Nishanth Menon
  */
 
-- 
2.27.0

[PATCH] net: phy: fix mdio-mscc-miim build

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

PHYLIB is not selected by mdio-mscc-miim but it uses mdio devres helpers.
Explicitly select MDIO_DEVRES in this driver's Kconfig entry.

Reported-by: kernel test robot 
Fixes: 1814cff26739 ("net: phy: add a Kconfig option for mdio_devres")
Signed-off-by: Bartosz Golaszewski 
---
 drivers/net/phy/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 7ffa8a4529a8e..dd20c2c27c2f6 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -185,6 +185,7 @@ config MDIO_MOXART
 config MDIO_MSCC_MIIM
tristate "Microsemi MIIM interface support"
depends on HAS_IOMEM
+   select MDIO_DEVRES
help
  This driver supports the MIIM (MDIO) interface found in the network
  switches of the Microsemi SoCs; it is recommended to switch on
-- 
2.26.1

Re: [PATCH v2] iommu/arm-smmu: Mark qcom_smmu_client_of_match as possibly unused

[Joerg Roedel]

On Mon, Jul 13, 2020 at 02:33:26PM +0100, Will Deacon wrote:
> I can't see this in Joerg's tree or in linux-next. Joerg: did you pick this
> one up? (I thought you did, but I can't find it!).

Yes, its in the tree and and will be pushed soon. I'll also send it to
Linus today.


Joerg

Re: [PATCH net-next v1 5/5] net: phy: micrel: ksz886x/ksz8081: add cabletest support

[Andrew Lunn]

> > Hi Oleksij
> > 
> > Do the PHY register read/writes pass through the DSA driver for the
> > 8873?  I was wondering if the switch could intercept reads/writes on
> > port1 for KSZ8081_LMD and return EOPNOTSUPP? That would be a more
> > robust solution than DT properties, which are going to get forgotten.
> 
> Yes, it was my first idea as well. But this switch allows direct MDIO
> access to the PHYs and this PHY driver could be used without DSA driver.
> Not sure if we should support both variants?
> 
> Beside, the Port 1 need at least one more quirk. The pause souport is
> announced but is not working. Should we some how clear Puase bit in the PHY 
> and
> tell PHY framework to not use it? What is the best way to do it?

It all seems rather odd, the way one PHY is messed up, but the other
works. Does this PHY exist as a standalone device, not integrated into
the switch? Do the same erratas apply to such a standalone device?

If the issues are just limited to integrated PHYs, there is maybe
something you can do via DSA:

in slave.c:

static int dsa_slave_phy_setup(struct net_device *slave_dev)
{
...
if (ds->ops->get_phy_flags)
phy_flags = ds->ops->get_phy_flags(ds, dp->index);

ret = phylink_of_phy_connect(dp->pl, port_dn, phy_flags);

It is either B53 or SF2 which uses this, i forget which. flags get
or'ed into phydev->dev_flags. These are device specific flags. So you
could define a bit to represent this errata. And then in the PHY
driver do whatever needs to be done when you see the flag set for a
specific PHY.

If Pause is broken, then yes, it would be good to remove the Pause
from the available features, and return an error if requested to use
it.

   Andrew

Re: [PATCH] net: phy: fix mdio-mscc-miim build

[Andrew Lunn]

On Mon, Jul 13, 2020 at 05:12:07PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> PHYLIB is not selected by mdio-mscc-miim but it uses mdio devres helpers.
> Explicitly select MDIO_DEVRES in this driver's Kconfig entry.
> 
> Reported-by: kernel test robot 
> Fixes: 1814cff26739 ("net: phy: add a Kconfig option for mdio_devres")
> Signed-off-by: Bartosz Golaszewski 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH] KVM: nVMX: properly pad struct kvm_vmx_nested_state_hdr

[Sean Christopherson]

On Mon, Jul 13, 2020 at 10:28:24AM +0200, Vitaly Kuznetsov wrote:
> Holes in structs which are userspace ABI are undesireable.
> 
> Fixes: 83d31e5271ac ("KVM: nVMX: fixes for preemption timer migration")
> Signed-off-by: Vitaly Kuznetsov 
> ---
>  Documentation/virt/kvm/api.rst  | 2 +-
>  arch/x86/include/uapi/asm/kvm.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 320788f81a05..7beccda11978 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -4345,7 +4345,7 @@ Errors:
>   struct {
>   __u16 flags;
>   } smm;
> -
> + __u16 pad;

I don't think this is sufficient.  Before 83d31e5271ac, the struct was:

struct kvm_vmx_nested_state_hdr {
__u64 vmxon_pa;
__u64 vmcs12_pa;

struct {
__u16 flags;
} smm;
};

which most/all compilers will pad out to 24 bytes on a 64-bit system.  And
although smm.flags is padded to 8 bytes, it's initialized as a 2 byte value.

714 struct kvm_vmx_nested_state_hdr boo;
715 u64 val;
716
717 BUILD_BUG_ON(sizeof(boo) != 3*8);
718 boo.smm.flags = 0;
   0x810148a9 <+41>:xor%eax,%eax
   0x810148ab <+43>:mov%ax,0x18(%rsp)

719
720 val = *((volatile u64 *)(&boo.smm.flags));
   0x810148b0 <+48>:mov0x18(%rsp),%rax


Which means that userspace built for the old kernel will potentially send in
garbage for the new 'flags' field due to it being uninitialized stack data,
even with the layout after this patch.

struct kvm_vmx_nested_state_hdr {
__u64 vmxon_pa;
__u64 vmcs12_pa;

struct {
__u16 flags;
} smm;
__u16 pad;
__u32 flags;
__u64 preemption_timer_deadline;
};

So to be backwards compatible I believe we need to add a __u32 pad as well,
and to not cause internal padding issues, either make the new 'flags' a
__u64 or pad that as well (or add and check a reserved __32).  Making flags
a __64 seems like the least wasteful approach, e.g.

struct kvm_vmx_nested_state_hdr {
__u64 vmxon_pa;
__u64 vmcs12_pa;

struct {
__u16 flags;
} smm;
__u16 pad16;
__u32 pad32;
__u64 flags;
__u64 preemption_timer_deadline;
};


>   __u32 flags;
>   __u64 preemption_timer_deadline;
>};
> diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
> index 0780f97c1850..aae3df1cbd01 100644
> --- a/arch/x86/include/uapi/asm/kvm.h
> +++ b/arch/x86/include/uapi/asm/kvm.h
> @@ -414,7 +414,7 @@ struct kvm_vmx_nested_state_hdr {
>   struct {
>   __u16 flags;
>   } smm;
> -
> + __u16 pad;
>   __u32 flags;
>   __u64 preemption_timer_deadline;
>  };
> -- 
> 2.25.4
> 

[PATCH] [media] cx18: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/media/pci/cx18/cx18-cards.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/cx18/cx18-cards.c 
b/drivers/media/pci/cx18/cx18-cards.c
index ecbe76f1ca63..f5a30959a367 100644
--- a/drivers/media/pci/cx18/cx18-cards.c
+++ b/drivers/media/pci/cx18/cx18-cards.c
@@ -35,7 +35,7 @@ static struct cx18_card_tuner_i2c cx18_i2c_nxp = {
.tv= { 0x61, 0x60, I2C_CLIENT_END },
 };
 
-/* Please add new PCI IDs to: http://pci-ids.ucw.cz/
+/* Please add new PCI IDs to: https://pci-ids.ucw.cz/
This keeps the PCI ID database up to date. Note that the entries
must be added under vendor 0x (Conexant) as subsystem IDs.
New vendor IDs should still be added to the vendor ID list. */
-- 
2.27.0

RE: [PATCH] cpufreq: intel_pstate: Fix active mode setting from command line

[Doug Smythies]

Hi Rafael,

Thank you.

On 2020.07.13 06:59 Rafael J. Wysocki wrote:
> 
> From: Rafael J. Wysocki 
> 
> If intel_pstate starts in the passive mode by default (that happens
> when the processor in the system doesn't support HWP), passing
> intel_pstate=active in the kernel command line doesn't work, so
> fix that.
> 
> Fixes: 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default 
> without HWP")
> Reported-by: Doug Smythies 
> Signed-off-by: Rafael J. Wysocki 

Acked-by: Doug Smythies 

> ---
>  drivers/cpufreq/intel_pstate.c |8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -2534,7 +2534,7 @@ static struct cpufreq_driver intel_cpufr
>   .name   = "intel_cpufreq",
>  };
> 
> -static struct cpufreq_driver *default_driver = &intel_pstate;
> +static struct cpufreq_driver *default_driver;
> 
>  static void intel_pstate_driver_cleanup(void)
>  {
> @@ -2828,6 +2828,7 @@ static int __init intel_pstate_init(void
>   hwp_active++;
>   hwp_mode_bdw = id->driver_data;
>   intel_pstate.attr = hwp_cpufreq_attrs;
> + default_driver = &intel_pstate;
>   goto hwp_cpu_matched;
>   }
>   } else {
> @@ -2845,7 +2846,8 @@ static int __init intel_pstate_init(void
>   return -ENODEV;
>   }
>   /* Without HWP start in the passive mode. */
> - default_driver = &intel_cpufreq;
> + if (!default_driver)
> + default_driver = &intel_cpufreq;
> 
>  hwp_cpu_matched:
>   /*
> @@ -2899,6 +2901,8 @@ static int __init intel_pstate_setup(cha
> 
>   if (!strcmp(str, "disable")) {
>   no_load = 1;
> + } else if (!strcmp(str, "active")) {
> + default_driver = &intel_pstate;
>   } else if (!strcmp(str, "passive")) {
>   default_driver = &intel_cpufreq;
>   no_hwp = 1;
> 

Re: [RFC PATCH] interconnect: qcom: add functions to query addr/cmds for a path

[Georgi Djakov]

On 7/1/20 07:25, Jonathan Marek wrote:
> The a6xx GMU can vote for ddr and cnoc bandwidth, but it needs to be able
> to query the interconnect driver for bcm addresses and commands.

It's not very clear to me how the GMU firmware would be dealing with this? Does
anyone have an idea whether the GMU makes any bandwidth decisions? Or is it just
a static configuration and it just enables/disables a TCS?

I think that we can query the address from the cmd-db, but we have to know the
bcm names and the path. All the BCM/TCS information looks to be very low-level
and implementation specific, so exposing it through an API is not very good,
but hard-coding all this information is not good either.

Thanks,
Georgi

> 
> I'm not sure what is the best way to go about implementing this, this is
> what I came up with.
> 
> I included a quick example of how this can be used by the a6xx driver to
> fill out the GMU bw_table (two ddr bandwidth levels in this example, note
> this would be using the frequency table in dts and not hardcoded values).
> 
> Signed-off-by: Jonathan Marek 
> ---
>  drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 20 ---
>  drivers/interconnect/qcom/icc-rpmh.c  | 50 +++
>  include/soc/qcom/icc.h| 11 ++
>  3 files changed, 68 insertions(+), 13 deletions(-)

Re: [PATCH] pinctrl: qcom: Handle broken PDC dual edge case on sc7180

[Doug Anderson]

Hi,

On Sat, Jul 11, 2020 at 2:16 AM Marc Zyngier  wrote:
>
> On Fri, 10 Jul 2020 17:10:55 +0100,
> Doug Anderson  wrote:
> >
> > Hi,
> >
> > On Fri, Jul 10, 2020 at 2:03 AM Marc Zyngier  wrote:
> > >
> > > Hi Doug,
>
> [...]
>
> > >
> > > > + type = val ? IRQ_TYPE_EDGE_FALLING : IRQ_TYPE_EDGE_RISING;
> > > > +
> > > > + raw_spin_lock_irqsave(&pctrl->lock, flags);
> > >
> > > What is this lock protecting you against? In both cases, you are
> > > already under the irq_desc lock, with interrupts disabled.
> >
> > We are?  I put a breakpoint when the IRQ hits and did a bt.  I see
> > this (I happen to be on 5.4 at the moment, so hopefully the same as
> > mainline):
> >
> >  kgdb_breakpoint+0x3c/0x74
> >  msm_gpio_update_dual_edge_parent+0x58/0x17c
> >  msm_gpio_handle_dual_edge_parent_irq+0x1c/0x30
> >  __handle_domain_irq+0x84/0xc4
> >  gic_handle_irq+0x170/0x220
> >  el1_irq+0xd0/0x180
> >
> > I think the stack is missing a few things due to aggressive inlining
> > from my compiler, so the true backtrace would be:
> >
> > msm_gpio_handle_dual_edge_parent_irq()
> > generic_handle_irq_desc()
> > generic_handle_irq()
> > __handle_domain_irq()
> > handle_domain_irq()
> > gic_handle_irq()
> >
> > The first place that got the "desc" was generic_handle_irq() and it
> > got it via irq_to_desc().  That doesn't seem to do any locking.  Then
> > generic_handle_irq_desc() just calls a function pointer so no locking
> > there either.
> >
> > ...ah, but maybe what you're saying is that
> > msm_gpio_handle_dual_edge_parent_irq() should be holding "desc->lock"
> > around the call to msm_gpio_update_dual_edge_parent()?  I can do that.
>
> No, I mentally did a fast-forward to moving this hack into the irq
> flow, rather than doing before entering the flow. handle_fasteoi_irq
> will take the lock, but obviously not with the current state of this
> patch.
>
> >
> >
> > > > + do {
> > > > + /* Set the parent to catch the next edge */
> > > > + irq_chip_set_type_parent(d, type);
> > > > +
> > > > + /*
> > > > +  * Possibly the line changed between when we last read 
> > > > "val"
> > > > +  * (and decided what edge we needed) and when set the 
> > > > edge.
> > > > +  * If the value didn't change (or changed and then changed
> > > > +  * back) then we're done.
> > > > +  */
> > >
> > > If the line changed, shouldn't you actually inject a new interrupt
> > > altogether? By changing the polarity more than once, you are
> > > effectively loosing edges that should have triggered an interrupt.
> >
> > Are you sure this is needed?  My understanding of edge triggered
> > interrupts is that until the interrupt handler is called that all
> > edges can be coalesced into a single interrupt.
>
> It really depends on whether the edges are semantically different, and
> I'm not sure you can decide this at the interrupt controller
> level. The core IRQ code doesn't give you a way to discriminate
> between those, but endpoint drivers could, and could get terminally
> confused if the see two rising edges without a falling edge in
> between.

I have added discussion about this in the commit message for v2.
Hopefully it looks OK.  NOTE: it's actually quite common for pinctrl
hardware to only support single edge and require dual edge emulation
in solftware.  I think there are at least 4-5 examples that I found
pretty easily.  ...so I think any drivers that are expecting dual
edges to come from an external pin will have code to account for this.


> > It's only after the
> > interrupt handler is called that it's important to capture new edges.
> > So if you have this:
> >
> > a) Be busy processing another unrelated interrupt
> > b) 5 edges happen on the line
> > c) Other interrupt finishes
> > d) Edge interrupt is acked and handler is called
> >
> > You'll only get one call to the interrupt handler even though there
> > were 5 edges, right?  It's only important that you queue another
> > interrupt if that interrupt happens after the true interrupt handler
> > (the one acting on the edge) has started.
> >
> > ...actually, in theory you'll get _either_ one or two calls to the
> > interrupt handler depending on timing, since the above could also
> > happen as:
> >
> > a) Be busy processing another unrelated interrupt
> > b) 4 edges happen on the line
> > c) Other interrupt finishes
> > d) Edge interrupt is acked and ...
> > e) 1 more edge happens on the line
> > f) ...handler is called
> > g) Edge interrupt is acked and handler is called
> >
> >
> > As long as msm_gpio_update_dual_edge_parent() is called _before_ the
> > true interrupt handler is called then what I have should be fine,
> > right?
>
> I don't disagree with any of that, except that being fine at the
> irqchip level doesn't necessarily mean being fine at the endpoint
> driver level. On the other hand, the HW looks terminally broken, so
> maybe it doesn't matter as the drivers will ha

[PATCH v2] pinctrl: qcom: Handle broken/missing PDC dual edge IRQs on sc7180

[Douglas Anderson]

Depending on how you look at it, you can either say that:
a) There is a PDC hardware issue (with the specific IP rev that exists
   on sc7180) that causes the PDC not to work properly when configured
   to handle dual edges.
b) The dual edge feature of the PDC hardware was only added in later
   HW revisions and thus isn't in all hardware.

Regardless of how you look at it, let's work around the lack of dual
edge support by only ever letting our parent see requests for single
edge interrupts on affected hardware.

NOTE: it's possible that a driver requesting a dual edge interrupt
might get several edges coalesced into a single IRQ.  For instance if
a line starts low and then goes high and low again, the driver that
requested the IRQ is not guaranteed to be called twice.  However, it
is guaranteed that once the driver's interrupt handler starts running
its first instruction that any new edges coming in will cause the
interrupt to fire again.  This is relatively commonplace for dual-edge
gpio interrupts (many gpio controllers require software to emulate
dual edge with single edge) so client drivers should be setup to
handle it.

Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
Signed-off-by: Douglas Anderson 
---
As far as I can tell everything here should work and the limited
testing I'm able to give it shows that, in fact, I can detect both
edges.

I specifically left off Reviewed-by and Tested-by tags from v2 becuase
I felt that the implementation had changed just enough to invalidate
previous reviews / testing.  Hopefully it's not too much of a hassle
for folks to re-review and re-test.

Changes in v2:
- Use handle_fasteoi_ack_irq() and switch edges in the Ack now.
- If we change types, switch back to the normal handle_fasteoi_irq().
- No extra locking.
- Properly print an error if we hit 100 loops w/ no stability.
- Beefed up the commit message.

 drivers/pinctrl/qcom/Kconfig  |  2 +
 drivers/pinctrl/qcom/pinctrl-msm.c| 74 ++-
 drivers/pinctrl/qcom/pinctrl-msm.h|  4 ++
 drivers/pinctrl/qcom/pinctrl-sc7180.c |  1 +
 4 files changed, 79 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index ff1ee159dca2..f8ff30cdafa6 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -7,6 +7,8 @@ config PINCTRL_MSM
select PINCONF
select GENERIC_PINCONF
select GPIOLIB_IRQCHIP
+   select IRQ_DOMAIN_HIERARCHY
+   select IRQ_FASTEOI_HIERARCHY_HANDLERS
 
 config PINCTRL_APQ8064
tristate "Qualcomm APQ8064 pin controller driver"
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 83b7d64bc4c1..eae8f421ff63 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -832,6 +832,52 @@ static void msm_gpio_irq_unmask(struct irq_data *d)
msm_gpio_irq_clear_unmask(d, false);
 }
 
+/**
+ * msm_gpio_update_dual_edge_parent() - Prime next edge for IRQs handled by 
parent.
+ * @d: The irq dta.
+ *
+ * This is much like msm_gpio_update_dual_edge_pos() but for IRQs that are
+ * normally handled by the parent irqchip.  The logic here is slightly
+ * different due to what's easy to do with our parent, but in principle it's
+ * the same.
+ */
+static void msm_gpio_update_dual_edge_parent(struct irq_data *d)
+{
+   struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+   struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
+   const struct msm_pingroup *g = &pctrl->soc->groups[d->hwirq];
+   int loop_limit = 100;
+   unsigned int val;
+   unsigned int type;
+
+   /* Read the value and make a guess about what edge we need to catch */
+   val = msm_readl_io(pctrl, g) & BIT(g->in_bit);
+   type = val ? IRQ_TYPE_EDGE_FALLING : IRQ_TYPE_EDGE_RISING;
+
+   do {
+   /* Set the parent to catch the next edge */
+   irq_chip_set_type_parent(d, type);
+
+   /*
+* Possibly the line changed between when we last read "val"
+* (and decided what edge we needed) and when set the edge.
+* If the value didn't change (or changed and then changed
+* back) then we're done.
+*/
+   val = msm_readl_io(pctrl, g) & BIT(g->in_bit);
+   if (type == IRQ_TYPE_EDGE_RISING) {
+   if (!val)
+   return;
+   type = IRQ_TYPE_EDGE_FALLING;
+   } else if (type == IRQ_TYPE_EDGE_FALLING) {
+   if (val)
+   return;
+   type = IRQ_TYPE_EDGE_RISING;
+   }
+   } while (loop_limit-- > 0);
+   dev_err(pctrl->dev, "dual-edge irq failed to stabilize\n");
+}
+
 static void msm_gpio_irq_ack(struct irq_data *d)
 {
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
@@ -840,8 +886,11 @@ s

[PATCH v4] ALSA: line6: add hw monitor volume control for POD HD500

[Vasily Khoruzhick]

Add hw monitor volume control for POD HD500. The same change may
work for HD500X but I don't have it to test.

Signed-off-by: Vasily Khoruzhick 
---
v4: add NULL check for kmalloc-ed buffer
v3: - use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL
- use GFP_KERNEL instead of GFP_ATOMIC for allocating a message
- use lower case for float lookup table
v2: clamp volume value to [0, ARRAY_SIZE() -1] in
podhd_set_monitor_level()

 sound/usb/line6/driver.c |   3 +-
 sound/usb/line6/driver.h |   4 ++
 sound/usb/line6/podhd.c  | 127 ++-
 3 files changed, 132 insertions(+), 2 deletions(-)

diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 7629116f570e..3e07251b80e3 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -97,7 +97,7 @@ static void line6_stop_listen(struct usb_line6 *line6)
 /*
Send raw message in pieces of wMaxPacketSize bytes.
 */
-static int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
+int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
  int size)
 {
int i, done = 0;
@@ -132,6 +132,7 @@ static int line6_send_raw_message(struct usb_line6 *line6, 
const char *buffer,
 
return done;
 }
+EXPORT_SYMBOL_GPL(line6_send_raw_message);
 
 /*
Notification of completion of asynchronous request transmission.
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index 1a4e3700c80c..62c686bed0ca 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -108,6 +108,8 @@ enum {
LINE6_CAP_CONTROL_MIDI = 1 << 4,
/* device provides low-level information */
LINE6_CAP_CONTROL_INFO = 1 << 5,
+   /* device provides hardware monitoring volume control */
+   LINE6_CAP_HWMON_CTL =   1 << 6,
 };
 
 /*
@@ -185,6 +187,8 @@ extern int line6_read_data(struct usb_line6 *line6, 
unsigned address,
   void *data, unsigned datalen);
 extern int line6_read_serial_number(struct usb_line6 *line6,
u32 *serial_number);
+extern int line6_send_raw_message(struct usb_line6 *line6,
+   const char *buffer, int size);
 extern int line6_send_raw_message_async(struct usb_line6 *line6,
const char *buffer, int size);
 extern int line6_send_sysex_message(struct usb_line6 *line6,
diff --git a/sound/usb/line6/podhd.c b/sound/usb/line6/podhd.c
index e39dc85c355a..1557483ec657 100644
--- a/sound/usb/line6/podhd.c
+++ b/sound/usb/line6/podhd.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "driver.h"
@@ -37,6 +38,9 @@ struct usb_line6_podhd {
 
/* Firmware version */
int firmware_version;
+
+   /* Monitor level */
+   int monitor_level;
 };
 
 #define line6_to_podhd(x)  container_of(x, struct usb_line6_podhd, line6)
@@ -250,6 +254,118 @@ static void podhd_disconnect(struct usb_line6 *line6)
}
 }
 
+static const unsigned int float_zero_to_one_lookup[] = {
+0x, 0x3c23d70a, 0x3ca3d70a, 0x3cf5c28f, 0x3d23d70a, 0x3d4d,
+0x3d75c28f, 0x3d8f5c29, 0x3da3d70a, 0x3db851ec, 0x3dcd, 0x3de147ae,
+0x3df5c28f, 0x3e051eb8, 0x3e0f5c29, 0x3e1a, 0x3e23d70a, 0x3e2e147b,
+0x3e3851ec, 0x3e428f5c, 0x3e4d, 0x3e570a3d, 0x3e6147ae, 0x3e6b851f,
+0x3e75c28f, 0x3e80, 0x3e851eb8, 0x3e8a3d71, 0x3e8f5c29, 0x3e947ae1,
+0x3e9a, 0x3e9eb852, 0x3ea3d70a, 0x3ea8f5c3, 0x3eae147b, 0x3eb3,
+0x3eb851ec, 0x3ebd70a4, 0x3ec28f5c, 0x3ec7ae14, 0x3ecd, 0x3ed1eb85,
+0x3ed70a3d, 0x3edc28f6, 0x3ee147ae, 0x3ee6, 0x3eeb851f, 0x3ef0a3d7,
+0x3ef5c28f, 0x3efae148, 0x3f00, 0x3f028f5c, 0x3f051eb8, 0x3f07ae14,
+0x3f0a3d71, 0x3f0d, 0x3f0f5c29, 0x3f11eb85, 0x3f147ae1, 0x3f170a3d,
+0x3f1a, 0x3f1c28f6, 0x3f1eb852, 0x3f2147ae, 0x3f23d70a, 0x3f26,
+0x3f28f5c3, 0x3f2b851f, 0x3f2e147b, 0x3f30a3d7, 0x3f33, 0x3f35c28f,
+0x3f3851ec, 0x3f3ae148, 0x3f3d70a4, 0x3f40, 0x3f428f5c, 0x3f451eb8,
+0x3f47ae14, 0x3f4a3d71, 0x3f4d, 0x3f4f5c29, 0x3f51eb85, 0x3f547ae1,
+0x3f570a3d, 0x3f5a, 0x3f5c28f6, 0x3f5eb852, 0x3f6147ae, 0x3f63d70a,
+0x3f66, 0x3f68f5c3, 0x3f6b851f, 0x3f6e147b, 0x3f70a3d7, 0x3f73,
+0x3f75c28f, 0x3f7851ec, 0x3f7ae148, 0x3f7d70a4, 0x3f80
+};
+
+static void podhd_set_monitor_level(struct usb_line6_podhd *podhd, int value)
+{
+   unsigned int fl;
+   static const unsigned char msg[16] = {
+   /* Chunk is 0xc bytes (without first word) */
+   0x0c, 0x00,
+   /* First chunk in the message */
+   0x01, 0x00,
+   /* Message size is 2 4-byte words */
+   0x02, 0x00,
+   /* Unknown */
+   0x04, 0x41,
+   /* Unknown */
+   0x04, 0x00, 0x13, 0x00,
+   /* Volume, LE float32, 0.0 - 1.0 */
+   0x00, 0x00, 0x00, 0x00
+   };
+   unsigned char *

Re: [PATCH] drm/bridge: sil_sii8620: initialize return of sii8620_readb

[Andrzej Hajda]

On 12.07.2020 17:24, t...@redhat.com wrote:
> From: Tom Rix 
>
> clang static analysis flags this error
>
> sil-sii8620.c:184:2: warning: Undefined or garbage value
>returned to caller [core.uninitialized.UndefReturn]
>  return ret;
>  ^~
>
> sii8620_readb calls sii8620_read_buf.
> sii8620_read_buf can return without setting its output
> pararmeter 'ret'.
>
> So initialize ret.
>
> Fixes: ce6e153f414a ("drm/bridge: add Silicon Image SiI8620 driver")
>
> Signed-off-by: Tom Rix 
> ---
>   drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 3540e4931383..da933d477e5f 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -178,7 +178,7 @@ static void sii8620_read_buf(struct sii8620 *ctx, u16 
> addr, u8 *buf, int len)
>   
>   static u8 sii8620_readb(struct sii8620 *ctx, u16 addr)
>   {
> - u8 ret;
> + u8 ret = 0;


In theory it shouldn't cause any harm, but this protections makes things 
simpler.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej


>   
>   sii8620_read_buf(ctx, addr, &ret, 1);
>   return ret;

Re: [PATCH] kobject: documentation: Replace HTTP links with HTTPS ones

[Jonathan Corbet]

On Mon, 13 Jul 2020 16:41:03 +0200
"Alexander A. Klimov"  wrote:

> diff --git a/Documentation/core-api/kobject.rst 
> b/Documentation/core-api/kobject.rst
> index e93dc8cf52dd..2739f8b72575 100644
> --- a/Documentation/core-api/kobject.rst
> +++ b/Documentation/core-api/kobject.rst
> @@ -6,7 +6,7 @@ Everything you never wanted to know about kobjects, ksets, 
> and ktypes
>  :Last updated: December 19, 2007
>  
>  Based on an original article by Jon Corbet for lwn.net written October 1,
> -2003 and located at http://lwn.net/Articles/51437/
> +2003 and located at https://lwn.net/Articles/51437/

Applied, thanks.

jon

[PATCH] media: imon: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/media/rc/imon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index ed95244da894..a7962ca2ac8e 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -795,7 +795,7 @@ static ssize_t show_associate_remote(struct device *d,
else
strscpy(buf, "closed\n", PAGE_SIZE);
 
-   dev_info(d, "Visit http://www.lirc.org/html/imon-24g.html for 
instructions on how to associate your iMON 2.4G DT/LT remote\n");
+   dev_info(d, "Visit https://www.lirc.org/html/imon-24g.html for 
instructions on how to associate your iMON 2.4G DT/LT remote\n");
mutex_unlock(&ictx->lock);
return strlen(buf);
 }
-- 
2.27.0

Re: [RFC PATCH v2 3/5] mm: extend memfd with ability to create "secret" memory areas

[Mike Rapoport]

On Mon, Jul 13, 2020 at 01:58:12PM +0300, Kirill A. Shutemov wrote:
> On Mon, Jul 06, 2020 at 08:20:49PM +0300, Mike Rapoport wrote:
> > From: Mike Rapoport 
> > 
> > Extend memfd_create() system call with the ability to create memory areas
> > visible only in the context of the owning process and not mapped not only
> > to other processes but in the kernel page tables as well.
> > 
> > The user will create a file descriptor using the memfd_create system call.
> > The user than has to use ioctl() to define the desired protection mode for
> > the memory associated with that file descriptor and only when the mode is
> > set it is possible to mmap() the memory. For instance, the following
> > exapmple will create an uncached mapping (error handling is omitted):
> > 
> > fd = memfd_create("secret", MFD_SECRET);
> 
> I'm not convinced that it belong to memfd. You don't share anything with
> memfd, but the syscall.
 
I've chosen memfd because it implements file descriptor for memory
access. Indeed, there similarities end and this can be entirely new
system call.
And, TBH, I was too lazy to wire up a new syscall for RFC :)

> > ioctl(fd, MFD_SECRET_UNCACHED);
> > ftruncate(fd. MAP_SIZE);
> 
> Mix of tabs and spaces?

Will fix.

> > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
> >fd, 0);
> > 
> > Signed-off-by: Mike Rapoport 
> > ---
> >  include/linux/memfd.h  |   9 ++
> >  include/uapi/linux/magic.h |   1 +
> >  include/uapi/linux/memfd.h |   6 +
> >  mm/Kconfig |   3 +
> >  mm/Makefile|   1 +
> >  mm/memfd.c |  10 +-
> >  mm/secretmem.c | 247 +
> >  7 files changed, 275 insertions(+), 2 deletions(-)
> >  create mode 100644 mm/secretmem.c
> > 
> > diff --git a/include/linux/memfd.h b/include/linux/memfd.h
> > index 4f1600413f91..d3ca7285f51a 100644
> > --- a/include/linux/memfd.h
> > +++ b/include/linux/memfd.h
> > @@ -13,4 +13,13 @@ static inline long memfd_fcntl(struct file *f, unsigned 
> > int c, unsigned long a)
> >  }
> >  #endif
> >  
> > +#ifdef CONFIG_MEMFD_SECRETMEM
> > +extern struct file *secretmem_file_create(const char *name, unsigned int 
> > flags);
> > +#else
> > +static inline struct file *secretmem_file_create(const char *name, 
> > unsigned int flags)
> > +{
> > +   return ERR_PTR(-EINVAL);
> > +}
> > +#endif
> > +
> >  #endif /* __LINUX_MEMFD_H */
> > diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
> > index f3956fc11de6..35687dcb1a42 100644
> > --- a/include/uapi/linux/magic.h
> > +++ b/include/uapi/linux/magic.h
> > @@ -97,5 +97,6 @@
> >  #define DEVMEM_MAGIC   0x454d444d  /* "DMEM" */
> >  #define Z3FOLD_MAGIC   0x33
> >  #define PPC_CMM_MAGIC  0xc7571590
> > +#define SECRETMEM_MAGIC0x5345434d  /* "SECM" */
> >  
> >  #endif /* __LINUX_MAGIC_H__ */
> > diff --git a/include/uapi/linux/memfd.h b/include/uapi/linux/memfd.h
> > index 7a8a26751c23..3320a79b638d 100644
> > --- a/include/uapi/linux/memfd.h
> > +++ b/include/uapi/linux/memfd.h
> > @@ -8,6 +8,12 @@
> >  #define MFD_CLOEXEC0x0001U
> >  #define MFD_ALLOW_SEALING  0x0002U
> >  #define MFD_HUGETLB0x0004U
> > +#define MFD_SECRET 0x0008U
> > +
> > +/* ioctls for secret memory */
> > +#define MFD_SECRET_IOCTL '-'
> > +#define MFD_SECRET_EXCLUSIVE   _IOW(MFD_SECRET_IOCTL, 0x13, unsigned 
> > long)
> > +#define MFD_SECRET_UNCACHED_IOW(MFD_SECRET_IOCTL, 0x14, unsigned 
> > long)
> >  
> >  /*
> >   * Huge page size encoding when MFD_HUGETLB is specified, and a huge page
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index f2104cc0d35c..20dfcc54cc7a 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -872,4 +872,7 @@ config ARCH_HAS_HUGEPD
> >  config MAPPING_DIRTY_HELPERS
> >  bool
> >  
> > +config MEMFD_SECRETMEM
> > +def_bool MEMFD_CREATE && ARCH_HAS_SET_DIRECT_MAP
> > +
> >  endmenu
> > diff --git a/mm/Makefile b/mm/Makefile
> > index 6e9d46b2efc9..a9459c8a655a 100644
> > --- a/mm/Makefile
> > +++ b/mm/Makefile
> > @@ -121,3 +121,4 @@ obj-$(CONFIG_MEMFD_CREATE) += memfd.o
> >  obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o
> >  obj-$(CONFIG_PTDUMP_CORE) += ptdump.o
> >  obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
> > +obj-$(CONFIG_MEMFD_SECRETMEM) += secretmem.o
> > diff --git a/mm/memfd.c b/mm/memfd.c
> > index 2647c898990c..3e1cc37e0389 100644
> > --- a/mm/memfd.c
> > +++ b/mm/memfd.c
> > @@ -245,7 +245,8 @@ long memfd_fcntl(struct file *file, unsigned int cmd, 
> > unsigned long arg)
> >  #define MFD_NAME_PREFIX_LEN (sizeof(MFD_NAME_PREFIX) - 1)
> >  #define MFD_NAME_MAX_LEN (NAME_MAX - MFD_NAME_PREFIX_LEN)
> >  
> > -#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUGETLB)
> > +#define MFD_SECRET_MASK (MFD_CLOEXEC | MFD_SECRET)
> > +#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUG