date:20201024

Em Fri, 23 Oct 2020 13:47:57 -0600
Jonathan Corbet  escreveu:

> On Fri, 23 Oct 2020 21:39:07 +0200
> Peter Zijlstra  wrote:
> 
> > > >  /**
> > > > - * struct refcount_t - variant of atomic_t specialized for reference 
> > > > counts
> > > > + * struct refcount_struct - variant of atomic_t specialized for 
> > > > reference counts
> > > 
> > > Hm, this is a weird one. Yes, it's actually "struct refcount_struct",
> > > but the usage should be refcount_t (through the typedef). I'm not sure
> > > what the right way to document this is.
> > 
> > Yeah, this is wrong. If this is due to a kernel doc warning, the kernel
> > doc machinery is wrong *again*.  

This issue has nothing to do with warnings. The problem here is that
"struct" is a markup for structs, and not for typedefs.

> 
> ...except that, since refcount_t is a typedef, "struct refcount_t" doesn't
> actually exist.  Whether it works properly after doing s/struct// remains
> to be seen...

If the intent is to document the struct and its internal fields,
this kernel-doc should work:

/**
 * struct refcount_struct - variant of atomic_t specialized for 
reference counts
 * @refs: atomic_t counter field
 *
 * The counter saturates at REFCOUNT_SATURATED and will not move once
 * there. This avoids wrapping the counter and causing 'spurious'
 * use-after-free bugs.
 */

Which produces this result:

.. c:struct:: refcount_struct

   variant of atomic_t specialized for reference counts

**Definition**

::

  struct refcount_struct {
atomic_t refs;
  };

**Members**

``refs``
  atomic_t counter field

(description)

See, in this case, the identifier is not opaque: its members are
documented at the html (or man) output.

If you want, instead, to document the typedef, this is the
proper way:

/**
 * typedef refcount_t - variant of atomic_t specialized for reference 
counts
 *
 * The counter saturates at REFCOUNT_SATURATED and will not move once
 * there. This avoids wrapping the counter and causing 'spurious'
 * use-after-free bugs.
 */

It will handle this one as an opaque type, meaning that it won't be 
showing the "refs" field - even if you forget to drop the @refs: 
at the markup. The result will be:

.. c:type:: refcount_t

   variant of atomic_t specialized for reference counts

(description)

-

If you want both, then you would either split struct and typedef, e. g.
with something like:

/**
 * struct refcount_struct - variant of atomic_t specialized for 
reference counts
 * @refs: atomic_t counter field
 *
 * The counter saturates at REFCOUNT_SATURATED and will not move once
 * there. This avoids wrapping the counter and causing 'spurious'
 * use-after-free bugs.
 */
struct refcount_struct {
atomic_t refs;
};

/**
 * typedef refcount_t - variant of atomic_t specialized for reference 
counts
 * @refs: atomic_t counter field
 *
 * The counter saturates at REFCOUNT_SATURATED and will not move once
 * there. This avoids wrapping the counter and causing 'spurious'
 * use-after-free bugs.
 */
typedef struct refcount_struct refcount_t;

Or, you could add the member at the description field. E. g. something
like this:

/**
 * typedef refcount_t - variant of atomic_t specialized for reference 
counts
 *
 * The counter saturates at REFCOUNT_SATURATED and will not move once
 * there. This avoids wrapping the counter and causing 'spurious'
 * use-after-free bugs.
 *
 * Members:
 *   ``refs``
 *atomic_t counter field
 */
typedef struct refcount_struct {
atomic_t refs;
} refcount_t;

If you want to test it, you can run kernel-doc directly, to see how
it will parse it. For ReST output, that's the syntax:

./scripts/kernel-doc --sphinx-version 3 include/linux/refcount.h

Thanks,
Mauro

Re: [PATCH] KVM: x86/mmu: Avoid modulo operator on 64-bit value to fix i386 build

On 24/10/20 05:11, Sean Christopherson wrote:
> Replace a modulo operator with the more common pattern for computing the
> gfn "offset" of a huge page to fix an i386 build error.
> 
>   arch/x86/kvm/mmu/tdp_mmu.c:212: undefined reference to `__umoddi3'
> 
> Fixes: 2f2fad0897cb ("kvm: x86/mmu: Add functions to handle changed TDP 
> SPTEs")
> Reported-by: Daniel Díaz 
> Signed-off-by: Sean Christopherson 
> ---
> 
> Linus, do you want to take this directly so that it's in rc1?  I don't
> know whether Paolo will be checking mail before then

Yes, I am.  I also have another bugfix, I was going to wait a couple
days for any -rc1 issues to pop up but they came up faster than that.

Paolo

Re: [PATCH v3 01/56] scripts: kernel-doc: fix typedef parsing

Em Fri, 23 Oct 2020 11:22:26 -0600
Jonathan Corbet  escreveu:

> On Fri, 23 Oct 2020 18:32:48 +0200
> Mauro Carvalho Chehab  wrote:
> 
> > The include/linux/genalloc.h file defined this typedef:
> > 
> > typedef unsigned long (*genpool_algo_t)(unsigned long *map,unsigned 
> > long size,unsigned long start,unsigned int nr,void *data, struct gen_pool 
> > *pool, unsigned long start_addr);
> > 
> > Because it has a type composite of two words (unsigned long),
> > the parser gets the typedef name wrong:
> > 
> > .. c:macro:: long
> > 
> >**Typedef**: Allocation callback function type definition
> > 
> > Fix the regex in order to accept composite types when
> > defining a typedef for a function pointer.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  scripts/kernel-doc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> > index 99cd8418ff8a..311d213ee74d 100755
> > --- a/scripts/kernel-doc
> > +++ b/scripts/kernel-doc
> > @@ -1438,7 +1438,7 @@ sub dump_typedef($$) {
> >  $x =~ s@/\*.*?\*/@@gos;# strip comments.
> >  
> >  # Parse function prototypes
> > -if ($x =~ /typedef\s+(\w+)\s*\(\*\s*(\w\S+)\s*\)\s*\((.*)\);/ ||
> > +if ($x =~ /typedef\s+(\w+\s*){1,}\(\*\s*(\w\S+)\s*\)\s*\((.*)\);/ ||  
> 
> I sure wish we could find a way to make all these regexes more
> understandable and maintainable.  Reviewing a change like this is ... fun.

Yeah. Regexes can be take a while to check. Btw, there's a site that
is really cool to check things:

https://regex101.com/

Unfortunately, it doesn't support Perl flavor. So, you may still
need to double-check if Perl will handle the regex the same way[1].

[1] One of the differences I found is with regards to match repetitions
https://perldoc.perl.org/perlrequick#Matching-repetitions
This works on both Python and Perl:
(foo){0,2}
But this only works on Python:
(foo){,2}

> 
> Anyway, it seems to work, but it does now include trailing whitespace in
> the type portion.  So, for example, from include/linux/xarray.h:
> 
>   typedef void (*xa_update_node_t)(struct xa_node *node);
> 
> The type is parsed as "void " where it was "void" before.  The only ill
> effect I can see is that some non-breaking spaces get inserted into the
> HTML output, but perhaps it's worth stripping off that trailing space
> anyway?

Ok, I'll work on a second version addressing it.

Thanks,
Mauro

Re: [PATCH] docs: driver-api: remove a duplicated index entry

Em Wed, 21 Oct 2020 15:13:44 -0600
Jonathan Corbet  escreveu:

> On Thu, 15 Oct 2020 11:12:06 +0200
> Mauro Carvalho Chehab  wrote:
> 
> > The ipmb file was added twice at index.rst. That
> > sounds to be because the same patch was applied twice,
> > via different git trees:
> > 
> > commit f6ae22d64433fd8e08654adad7966299da931bb9
> > Author: Mauro Carvalho Chehab 
> > Commit: Jonathan Corbet 
> > 
> > docs: ipmb: place it at driver-api and convert to ReST
> > 
> > commit ac499fba98c3c65078fd84fa0a62cd6f6d5837ed
> > Author: Mauro Carvalho Chehab 
> > Commit: Corey Minyard 
> > 
> > docs: ipmb: place it at driver-api and convert to ReST
> > 
> > With Sphinx 4.0.0 development tree, a new warning is produced
> > due to that:
> > 
> > .../Documentation/driver-api/index.rst:14: WARNING: duplicated entry 
> > found in toctree: driver-api/ipmb
> > 
> > The fix is trivial: just drop the duplicated line.
> > 
> > Fixes: f6ae22d64433 ("docs: ipmb: place it at driver-api and convert to 
> > ReST")
> > Fixes: ac499fba98c3 ("docs: ipmb: place it at driver-api and convert to 
> > ReST")
> > Signed-off-by: Mauro Carvalho Chehab   
> 
> Interesting...I wonder how applying the patch twice could lead to the line
> being inserted in two completely different locations like that?  Anyway,
> I've applied this one, hopefully nobody else will do the same :)

Probably this was due to some manual conflict resolution when applying
one of the versions of it ;-)

No big harm, and with newer Sphinx versions, we should be able 
to detect similar cases in the future.

Thanks,
Mauro

[PATCH v2] AMD_SFH: Fix for incorrect Sensor index

2020-10-24 Thread Sandeep Singh

From: Sandeep Singh 

Add fix for incorrect sensor index and minor code clean-up.

Reported-by: Mandoli 
Reported-by: Richard Neumann 
Signed-off-by: Sandeep Singh 
Fixes: SFH: PCIe driver to add support of AMD sensor fusion hub (4f567b9f8141)
---
Changes since v1:(https://lkml.org/lkml/2020/10/23/172)
-> Add Reported by : Richard Neumann

 drivers/hid/amd-sfh-hid/amd_sfh_pcie.c |  6 +++---
 .../amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h  | 14 --
 2 files changed, 3 insertions(+), 17 deletions(-)

diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c 
b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
index 9c5eb442e1a6..a51c7b76283b 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
@@ -20,9 +20,9 @@
 #define DRIVER_NAME"pcie_mp2_amd"
 #define DRIVER_DESC"AMD(R) PCIe MP2 Communication Driver"
 
-#define ACEL_ENBIT(1)
-#define GYRO_ENBIT(2)
-#define MAGNO_EN   BIT(3)
+#define ACEL_ENBIT(0)
+#define GYRO_ENBIT(1)
+#define MAGNO_EN   BIT(2)
 #define ALS_EN BIT(19)
 
 void amd_start_sensor(struct amd_mp2_dev *privdata, struct amd_mp2_sensor_info 
info)
diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h 
b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
index ac9a01cc1454..095c471d8fd6 100644
--- a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
+++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
@@ -16,11 +16,6 @@ enum desc_type {
feature_size,
 };
 
-struct _hid_report_descriptor {
-   u8 bDescriptorType;
-   u8 wDescriptorLength;
-};
-
 struct common_feature_property {
/* common properties */
u8 report_id;
@@ -38,15 +33,6 @@ struct common_input_property {
u8 event_type;
 } __packed;
 
-struct _hid_device_descriptor {
-   u8 bLength;
-   u8 bDescriptorType;
-   u8 bcdHID[2];
-   u8 bCountryCode;
-   u8 bNumDescriptors;
-   struct _hid_report_descriptor *reports;
-};
-
 struct accel3_feature_report {
struct common_feature_property common_property;
/* properties specific to this sensor */
-- 
2.25.1

Re: [RFC] Have insn decoder functions return success/failure

2020-10-24 Thread Masami Hiramatsu

On Sat, 24 Oct 2020 01:27:41 +0200
Borislav Petkov  wrote:

> On Fri, Oct 23, 2020 at 07:47:04PM +0900, Masami Hiramatsu wrote:
> > Thanks! I look forward to it.
> 
> Ok, here's a first stab, it is a single big diff and totally untested
> but it should show what I mean. I've made some notes while converting,
> as I went along.

Thanks, so will you split this into several patches, since I saw some
cleanups in this patch?

> 
> Have a look at insn_decode() and its call sites: they are almost trivial
> now because caller needs simply to do:
> 
>   if (insn_decode(insn, buffer, ...))
> 
> and not care about any helper functions.

Yeah, that's good to me because in the most cases, user needs prefix,
length or total decoded info.

BTW, it seems you returns 1 for errors, I rather like -EINVAL or -EILSEQ
for errors so that user can also write

 if (insn_decode() < 0)
   ...

I think "positive" and "zero" pair can easily mislead user to "true" and
"false" trap.

> For some of the call sites it still makes sense to do a piecemeal insn
> decoding and I've left them this way but they can be converted too, if
> one wants.

Yeah, for the kprobes, if you see the insn_init() and insn_get_length()
those can be replaced with one insn_decode(). 

> In any case, just have a look please and lemme know if that looks OKish.
> I'll do the actual splitting and testing afterwards.

Except for the return value, it looks good to me.

Thank you,

-- 
Masami Hiramatsu

Re: [RFC] Have insn decoder functions return success/failure

2020-10-24 Thread Masami Hiramatsu

On Fri, 23 Oct 2020 17:12:49 -0700
Andy Lutomirski  wrote:

> On Fri, Oct 23, 2020 at 4:27 PM Borislav Petkov  wrote:
> >
> > On Fri, Oct 23, 2020 at 07:47:04PM +0900, Masami Hiramatsu wrote:
> > > Thanks! I look forward to it.
> >
> > Ok, here's a first stab, it is a single big diff and totally untested
> > but it should show what I mean. I've made some notes while converting,
> > as I went along.
> >
> > Have a look at insn_decode() and its call sites: they are almost trivial
> > now because caller needs simply to do:
> >
> > if (insn_decode(insn, buffer, ...))
> >
> > and not care about any helper functions.
> >
> > For some of the call sites it still makes sense to do a piecemeal insn
> > decoding and I've left them this way but they can be converted too, if
> > one wants.
> >
> > In any case, just have a look please and lemme know if that looks OKish.
> > I'll do the actual splitting and testing afterwards.
> >
> > And what Andy wants can't be done with the decoder because it already
> > gets a fixed size buffer and length - it doesn't do the fetching. The
> > caller does.
> >
> > What you wanna do:
> >
> > > len = min(15, remaining bytes in page);
> > > fetch len bytes;
> > > insn_init();
> > > ret = insn_decode_fully();
> >
> > <--- you can't always know here whether the insn is valid if you don't
> > have all the bytes. But you can always fetch *all* bytes and then give
> > it to the decoder for checking.
> >
> > Also, this doesn't make any sense: try insn decode on a subset of bytes
> > and then if it fails, try it on the whole set of bytes. Why even try the
> > subset - it will almost always fail.
> 
> I disagree.  A real CPU does exactly what I'm describing.  If I stick
> 0xcc at the end of a page and a make the next page not-present, I get
> #BP, not #PF.  But if I stick 0x0F at the end of a page and mark the
> next page not-present, I get #PF.  If we're trying to decode an
> instruction in user memory, we can kludge it by trying to fetch 15
> bytes and handling -EFAULT by fetching fewer bytes, but that's gross
> and doesn't really have the right semantics.  What we actually want is
> to fetch up to the page boundary and try to decode it.  If it's a
> valid instruction or if it's definitely invalid, we're done.
> Otherwise we fetch across the page boundary.
> 
> Eventually we should wrap this whole mess up in an insn_decode_user()
> helper that does the right thing.  And we can then make that helper
> extra fancy by getting PKRU and EPT-hacker-execute-only right, whereas
> we currently get these cases wrong.

+1. To handle the user-space (untrusted) instruction, we need to
take more care about page boundary and presense. Also less side-effect
is perferrable.

Thank you,

-- 
Masami Hiramatsu

Re: [PATCH v3 23/56] PCI: fix kernel-doc markups

Em Fri, 23 Oct 2020 12:43:25 -0500
Bjorn Helgaas  escreveu:

> If you have the opportunity, I would prefer to capitalize the subject
> to follow the drivers/pci convention, e.g.,
> 
>   PCI: Fix ...

Ok. If you want to apply it directly, feel free to change it
at the patch.

Otherwise, I'll do it on a next rebase.

> 
> On Fri, Oct 23, 2020 at 06:33:10PM +0200, Mauro Carvalho Chehab wrote:
> > Some identifiers have different names between their prototypes
> > and the kernel-doc markup.  
> 
> How did you find these?  I build with "make W=1", which finds some
> kernel-doc errors, but it didn't find these.  If there's a scanner for
> these, I could fix things like this before merging them.

This is a new check. See patch 56/56.

Right now, kernel-doc will just silently ignore the identifier
from kernel-doc markup and use the one defined at the function
or data struct prototype.

Once all the issues gets fixed, patch 56/56 can be merged.

> 
> > Signed-off-by: Mauro Carvalho Chehab   
> 
> I'd be happy to take this myself, but if you want to merge the whole
> series together:
> 
> Acked-by: Bjorn Helgaas 

Either way works for me, although IMO it should be simpler if
you could pick it directly, as it will avoid potential
merge conflicts if such patches go via their usual trees.

> 
> > ---
> >  drivers/pci/p2pdma.c | 10 +-
> >  drivers/pci/pci-driver.c |  4 ++--
> >  drivers/pci/pci.c|  2 +-
> >  drivers/pci/probe.c  |  4 ++--
> >  drivers/pci/slot.c   |  5 +++--
> >  5 files changed, 13 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> > index de1c331dbed4..bace04145c5f 100644
> > --- a/drivers/pci/p2pdma.c
> > +++ b/drivers/pci/p2pdma.c
> > @@ -609,7 +609,7 @@ bool pci_has_p2pmem(struct pci_dev *pdev)
> >  EXPORT_SYMBOL_GPL(pci_has_p2pmem);
> >  
> >  /**
> > - * pci_p2pmem_find - find a peer-to-peer DMA memory device compatible with
> > + * pci_p2pmem_find_many - find a peer-to-peer DMA memory device compatible 
> > with
> >   * the specified list of clients and shortest distance (as determined
> >   * by pci_p2pmem_dma())
> >   * @clients: array of devices to check (NULL-terminated)
> > @@ -674,7 +674,7 @@ struct pci_dev *pci_p2pmem_find_many(struct device 
> > **clients, int num_clients)
> >  EXPORT_SYMBOL_GPL(pci_p2pmem_find_many);
> >  
> >  /**
> > - * pci_alloc_p2p_mem - allocate peer-to-peer DMA memory
> > + * pci_alloc_p2pmem - allocate peer-to-peer DMA memory
> >   * @pdev: the device to allocate memory from
> >   * @size: number of bytes to allocate
> >   *
> > @@ -727,7 +727,7 @@ void pci_free_p2pmem(struct pci_dev *pdev, void *addr, 
> > size_t size)
> >  EXPORT_SYMBOL_GPL(pci_free_p2pmem);
> >  
> >  /**
> > - * pci_virt_to_bus - return the PCI bus address for a given virtual
> > + * pci_p2pmem_virt_to_bus - return the PCI bus address for a given virtual
> >   * address obtained with pci_alloc_p2pmem()
> >   * @pdev: the device the memory was allocated from
> >   * @addr: address of the memory that was allocated
> > @@ -859,7 +859,7 @@ static int __pci_p2pdma_map_sg(struct 
> > pci_p2pdma_pagemap *p2p_pgmap,
> >  }
> >  
> >  /**
> > - * pci_p2pdma_map_sg - map a PCI peer-to-peer scatterlist for DMA
> > + * pci_p2pdma_map_sg_attrs - map a PCI peer-to-peer scatterlist for DMA
> >   * @dev: device doing the DMA request
> >   * @sg: scatter list to map
> >   * @nents: elements in the scatterlist
> > @@ -896,7 +896,7 @@ int pci_p2pdma_map_sg_attrs(struct device *dev, struct 
> > scatterlist *sg,
> >  EXPORT_SYMBOL_GPL(pci_p2pdma_map_sg_attrs);
> >  
> >  /**
> > - * pci_p2pdma_unmap_sg - unmap a PCI peer-to-peer scatterlist that was
> > + * pci_p2pdma_unmap_sg_attrs - unmap a PCI peer-to-peer scatterlist that 
> > was
> >   * mapped with pci_p2pdma_map_sg()
> >   * @dev: device doing the DMA request
> >   * @sg: scatter list to map
> > diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> > index 8b587fc97f7b..591ab353844a 100644
> > --- a/drivers/pci/pci-driver.c
> > +++ b/drivers/pci/pci-driver.c
> > @@ -90,7 +90,7 @@ static void pci_free_dynids(struct pci_driver *drv)
> >  }
> >  
> >  /**
> > - * store_new_id - sysfs frontend to pci_add_dynid()
> > + * new_id_store - sysfs frontend to pci_add_dynid()
> >   * @driver: target device driver
> >   * @buf: buffer for scanning device ID data
> >   * @count: input size
> > @@ -158,7 +158,7 @@ static ssize_t new_id_store(struct device_driver 
> > *driver, const char *buf,
> >  static DRIVER_ATTR_WO(new_id);
> >  
> >  /**
> > - * store_remove_id - remove a PCI device ID from this driver
> > + * remove_id_store - remove a PCI device ID from this driver
> >   * @driver: target device driver
> >   * @buf: buffer for scanning device ID data
> >   * @count: input size
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 6d4d5a2f923d..8b9bea8ba751 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -3480,7 +3480,7 @@ bool

Re: [PATCH v2] nvme-rdma: handle nvme completion data length

On Fri, Oct 23, 2020 at 11:01:40AM -0700, Sagi Grimberg wrote:
>>   +  /* received data length checking */
>> +if (unlikely(wc->byte_len < len)) {
>> +/* zero bytes message could be ignored */
>> +if (!wc->byte_len) {
>> +nvme_rdma_post_recv(queue, qe);
>> +return;
>> +}
>
> Nothing in the spec defines zero-length messages, hence we cannot
> support something that is not standard. If your array needs this,
> please submit a TPAR to the NVMe TWG.

We'll still need sanity checking instead of the recount underflow,
I think tearing down the connection here and kicking off error recovery
is probably the best idea.

RE: [PATCH 1/2] i2c: imx: use devm_request_threaded_irq to simplify code

2020-10-24 Thread Peng Fan

> Subject: Re: [PATCH 1/2] i2c: imx: use devm_request_threaded_irq to simplify
> code
> 
> On Fri, 23 Oct 2020 at 10:27,  wrote:
> >
> > From: Peng Fan 
> >
> > Use devm_request_threaded_irq to simplify code
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  drivers/i2c/busses/i2c-imx.c | 10 +++---
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-imx.c
> > b/drivers/i2c/busses/i2c-imx.c index e6f8d6e45a15..ba9d639223ec 100644
> > --- a/drivers/i2c/busses/i2c-imx.c
> > +++ b/drivers/i2c/busses/i2c-imx.c
> > @@ -1216,8 +1216,8 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> > goto rpm_disable;
> >
> > /* Request IRQ */
> > -   ret = request_threaded_irq(irq, i2c_imx_isr, NULL, IRQF_SHARED,
> > -  pdev->name, i2c_imx);
> > +   ret = devm_request_threaded_irq(>dev, irq, i2c_imx_isr,
> NULL, IRQF_SHARED,
> > +   pdev->name, i2c_imx);
> 
> Really? You silently revert commit e50e4f0b85be ("i2c: imx: Fix external abort
> on interrupt in exit paths"). This is not a simplification but serious 
> change. NAK.
> At least without proper reasoning of why this is suddenly safe.

Oh, I need look at git history before. But
Is it because i2c interrupt enabled too early? I'll try your case on i.MX8M 
platform.

Regards,
Peng.

> 
> Best regards,
> Krzysztof
> Best regards,
> Krzysztof

RE: [PATCH 2/2] i2c: imx: remove id_table entry

2020-10-24 Thread Peng Fan

> Subject: Re: [PATCH 2/2] i2c: imx: remove id_table entry
> 
> On Fri, Oct 23, 2020 at 04:18:23PM +0800, peng@nxp.com wrote:
> > From: Peng Fan 
> >
> > The legacy platform device code has been removed under
> > arch/arm/mach-imx, so we no need id_table entry here.
> 
> Cc: Greg, Geert, Angelo,
> 
> Aren't you breaking Coldfire platforms?

Ok, I see coldfire still use use imx1-i2c. Could we remove imx21-i2c or still
keep it?

Thanks
Peng.

> 
> Best regards,
> Krzysztof
> 
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  drivers/i2c/busses/i2c-imx.c | 14 --
> >  1 file changed, 14 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-imx.c
> > b/drivers/i2c/busses/i2c-imx.c index ba9d639223ec..7ea36a78abb0
> 100644
> > --- a/drivers/i2c/busses/i2c-imx.c
> > +++ b/drivers/i2c/busses/i2c-imx.c
> > @@ -233,19 +233,6 @@ static struct imx_i2c_hwdata vf610_i2c_hwdata =
> {
> >
> >  };
> >
> > -static const struct platform_device_id imx_i2c_devtype[] = {
> > -   {
> > -   .name = "imx1-i2c",
> > -   .driver_data = (kernel_ulong_t)_i2c_hwdata,
> > -   }, {

Re: [PATCH v6] fat: Add KUnit tests for checksums and timestamps

2020-10-24 Thread OGAWA Hirofumi

David Gow  writes:

> diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
> index 66532a71e8fd..4e66f7e8defc 100644
> --- a/fs/fat/Kconfig
> +++ b/fs/fat/Kconfig
> @@ -115,3 +115,15 @@ config FAT_DEFAULT_UTF8
> Say Y if you use UTF-8 encoding for file names, N otherwise.
>  
> See  for more information.
> +
> +config FAT_KUNIT_TEST
> + tristate "Unit Tests for FAT filesystems" if !KUNIT_ALL_TESTS
> + depends on KUNIT && (MSDOS_FS || VFAT_FS)
> + default KUNIT_ALL_TESTS
> + help
> +   This builds the FAT KUnit tests
> +
> +   For more information on KUnit and unit tests in general, please refer
> +   to the KUnit documentation in Documentation/dev-tools/kunit
> +
> +   If unsure, say N

Maybe, the following would be better? With this, it looks like kunit
works whether depends on or select.

Thanks.

diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
index ca31993..c1229d4 100644
--- a/fs/fat/Kconfig2020-09-02 20:48:54.967175266 +0900
+++ b/fs/fat/Kconfig2020-10-24 16:44:07.734324397 +0900
@@ -77,7 +77,7 @@ config VFAT_FS
 
 config FAT_DEFAULT_CODEPAGE
int "Default codepage for FAT"
-   depends on MSDOS_FS || VFAT_FS
+   depends on FAT_FS
default 437
help
  This option should be set to the codepage of your FAT filesystems.
@@ -115,3 +115,15 @@ config FAT_DEFAULT_UTF8
  Say Y if you use UTF-8 encoding for file names, N otherwise.
 
  See  for more information.
+
+config FAT_KUNIT_TEST
+   tristate "Unit Tests for FAT filesystems" if !KUNIT_ALL_TESTS
+   depends on KUNIT && FAT_FS
+   default KUNIT_ALL_TESTS
+   help
+ This builds the FAT KUnit tests
+
+ For more information on KUnit and unit tests in general, please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit
+
+ If unsure, say N
_
-- 
OGAWA Hirofumi

Re: [PATCH v1 1/2] mm: cma: introduce cma_release_nowait()

Btw, I think we also need to use this nonblocking version from
dma_free_contiguous.  dma_free* is defined to not block.  In practice
callers mostly care if they also did GFP_ATOMIC allocations, which
don't dip into CMA, but I think we do have a problem.

[PATCH] KVM: vmx: rename pi_init to avoid conflict with paride

allyesconfig results in:

ld: drivers/block/paride/paride.o: in function `pi_init':
(.text+0x1340): multiple definition of `pi_init'; 
arch/x86/kvm/vmx/posted_intr.o:posted_intr.c:(.init.text+0x0): first defined 
here
make: *** [Makefile:1164: vmlinux] Error 1

because commit:

commit cdd0996c2d51cd417f9a60a282c034f3fa28
Author: Xiaoyao Li 
Date:   Wed Sep 23 11:31:11 2020 -0700

KVM: VMX: Extract posted interrupt support to separate files

added another pi_init(), though one already existed in the paride code.

Reported-by: Jens Axboe 
Signed-off-by: Paolo Bonzini 
---
 arch/x86/kvm/vmx/posted_intr.c | 2 +-
 arch/x86/kvm/vmx/posted_intr.h | 4 ++--
 arch/x86/kvm/vmx/vmx.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86/kvm/vmx/posted_intr.c
index e4e7adff818c..f02962dcc72c 100644
--- a/arch/x86/kvm/vmx/posted_intr.c
+++ b/arch/x86/kvm/vmx/posted_intr.c
@@ -222,7 +222,7 @@ void pi_wakeup_handler(void)
spin_unlock(_cpu(blocked_vcpu_on_cpu_lock, cpu));
 }
 
-void __init pi_init(int cpu)
+void __init pi_init_cpu(int cpu)
 {
INIT_LIST_HEAD(_cpu(blocked_vcpu_on_cpu, cpu));
spin_lock_init(_cpu(blocked_vcpu_on_cpu_lock, cpu));
diff --git a/arch/x86/kvm/vmx/posted_intr.h b/arch/x86/kvm/vmx/posted_intr.h
index e53b97f82097..0bdc41391c5b 100644
--- a/arch/x86/kvm/vmx/posted_intr.h
+++ b/arch/x86/kvm/vmx/posted_intr.h
@@ -91,9 +91,9 @@ void vmx_vcpu_pi_put(struct kvm_vcpu *vcpu);
 int pi_pre_block(struct kvm_vcpu *vcpu);
 void pi_post_block(struct kvm_vcpu *vcpu);
 void pi_wakeup_handler(void);
-void __init pi_init(int cpu);
+void __init pi_init_cpu(int cpu);
 bool pi_has_pending_interrupt(struct kvm_vcpu *vcpu);
 int pi_update_irte(struct kvm *kvm, unsigned int host_irq, uint32_t guest_irq,
   bool set);
 
-#endif /* __KVM_X86_VMX_POSTED_INTR_H */
\ No newline at end of file
+#endif /* __KVM_X86_VMX_POSTED_INTR_H */
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 755896797a81..281c405c7ea3 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -8004,7 +8004,7 @@ static int __init vmx_init(void)
for_each_possible_cpu(cpu) {
INIT_LIST_HEAD(_cpu(loaded_vmcss_on_cpu, cpu));
 
-   pi_init(cpu);
+   pi_init_cpu(cpu);
}
 
 #ifdef CONFIG_KEXEC_CORE
-- 
2.26.2

[PATCH] KVM: ioapic: break infinite recursion on lazy EOI

From: Vitaly Kuznetsov 

During shutdown the IOAPIC trigger mode is reset to edge triggered
while the vfio-pci INTx is still registered with a resampler.
This allows us to get into an infinite loop:

ioapic_set_irq
  -> ioapic_lazy_update_eoi
  -> kvm_ioapic_update_eoi_one
  -> kvm_notify_acked_irq
  -> kvm_notify_acked_gsi
  -> (via irq_acked fn ptr) irqfd_resampler_ack
  -> kvm_set_irq
  -> (via set fn ptr) kvm_set_ioapic_irq
  -> kvm_ioapic_set_irq
  -> ioapic_set_irq

Commit 7faab2faca0c acknowledges that this recursion loop exists
and tries to avoid it at the call to ioapic_lazy_update_eoi, but at
this point the scenario is already set, we have an edge interrupt with
resampler on the same gsi.

Fortunately, the only user of irq ack notifiers (in addition to resamplefd)
is i8254 timer interrupt reinjection.  These are edge-triggered, so in
principle they would need the call to kvm_ioapic_update_eoi_one from
ioapic_lazy_update_eoi, but they already disable AVIC(*), so they don't
need the lazy EOI behavior.  Therefore, remove the call to
kvm_ioapic_update_eoi_one from ioapic_lazy_update_eoi.

This fixes CVE-2020-27152.  Note that this issue cannot happen with
SR-IOV assigned devices because virtual functions do not have INTx,
only MSI.

Suggested-by: Paolo Bonzini 
Tested-by: Alex Williamson 
Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: Paolo Bonzini 
---
 arch/x86/kvm/ioapic.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
index d057376bd3d3..698969e18fe3 100644
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -197,12 +197,9 @@ static void ioapic_lazy_update_eoi(struct kvm_ioapic 
*ioapic, int irq)
 
/*
 * If no longer has pending EOI in LAPICs, update
-* EOI for this vetor.
+* EOI for this vector.
 */
rtc_irq_eoi(ioapic, vcpu, entry->fields.vector);
-   kvm_ioapic_update_eoi_one(vcpu, ioapic,
- entry->fields.trig_mode,
- irq);
break;
}
 }
-- 
2.26.2

Re: [RFC] Have insn decoder functions return success/failure

2020-10-24 Thread Borislav Petkov

On Fri, Oct 23, 2020 at 05:12:49PM -0700, Andy Lutomirski wrote:
> I disagree.  A real CPU does exactly what I'm describing.  If I stick

A real modern CPU fetches up to 32 bytes insn window which it tries
to decode etc. I don't know, though, what it does when that fetch
encounters a fault - I will have to ask people. I'm not sure it would
even try to feed a shorter stream of bytes to the decoder but lemme
ask...

> 0xcc at the end of a page and a make the next page not-present, I get
> #BP, not #PF.  But if I stick 0x0F at the end of a page and mark the
> next page not-present, I get #PF.  If we're trying to decode an
> instruction in user memory, we can kludge it by trying to fetch 15
> bytes and handling -EFAULT by fetching fewer bytes, but that's gross
> and doesn't really have the right semantics.  What we actually want is
> to fetch up to the page boundary and try to decode it.  If it's a
> valid instruction or if it's definitely invalid, we're done.
> Otherwise we fetch across the page boundary.

We can do that but why would you put all that logic in the insn decoder?
Is that use case sooo important?

I mean, it would work that way anyway *even* *now* - the insn decoder
will tell you that the insn it decoded wasn't valid and you, as a
caller, know that you didn't fetch the whole 15 bytes so that means
that you still need to fetch some more. You've got all the relevant
information.

> Eventually we should wrap this whole mess up in an insn_decode_user()
> helper that does the right thing.

Oh sure, you can do that easily. Just put the logic which determines
that it copied a shorter buffer and that it attempts to decode the
shorter buffer first in it. Yah, that can work.

> And we can then make that helper
> extra fancy by getting PKRU and EPT-hacker-execute-only right, whereas
> we currently get these cases wrong.
> 
> Does this make sense?

Sure, but you could point me to those cases so that I can get a better
idea what they do exactly.

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] PM / s2idle: Export s2idle_set_ops

On Thu, Oct 22, 2020 at 02:17:47PM +0800, Claude Yen wrote:
> This series based on 5.9-rc1
> 
> As suspend_set_ops is exported in commit a5e4fd8783a2
> ("PM / Suspend: Export suspend_set_ops, suspend_valid_only_mem"),
> exporting s2idle_set_ops to make kernel module setup s2idle ops too.
> 
> In this way, kernel module can hook platform suspend functions
> regardless of Suspend-to-Ram(S2R) or Suspend-to-Idle(S2I)

Where is the actual users of the export?

Re: [RFC] Have insn decoder functions return success/failure

2020-10-24 Thread Borislav Petkov

On Sat, Oct 24, 2020 at 04:13:15PM +0900, Masami Hiramatsu wrote:
> Thanks, so will you split this into several patches, since I saw some
> cleanups in this patch?

Oh, most definitely. This was just a preview of where this is going...

> Yeah, that's good to me because in the most cases, user needs prefix,
> length or total decoded info.
> 
> BTW, it seems you returns 1 for errors, I rather like -EINVAL or -EILSEQ
> for errors so that user can also write
> 
>  if (insn_decode() < 0)
>...
> 
> I think "positive" and "zero" pair can easily mislead user to "true" and
> "false" trap.

Ok, sure, makes sense.

> Yeah, for the kprobes, if you see the insn_init() and insn_get_length()
> those can be replaced with one insn_decode().

Ok.

> Except for the return value, it looks good to me.

Thanks!

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v2 8/8] x86/ioapic: Generate RTE directly from parent irqchip's MSI message

On Fri, 2020-10-23 at 23:28 +0200, Thomas Gleixner wrote:
> On Fri, Oct 23 2020 at 11:10, David Woodhouse wrote:
> > On 22 October 2020 22:43:52 BST, Thomas Gleixner  wrote:
> > It makes the callers slightly more readable, not having to cast to 
> > uint32_t* from the struct.
> > 
> > I did ponder defining a new struct with bitfields named along the
> > lines of 'msi_addr_bits_19_to_4', but that seemed like overkill.
> 
> I did something like this in the meantime, because all of this just
> sucks.
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git x86/apic
> 
> Hot of the press and completely untested.

Hm, your struct IO_APIC_route_entry isn't actually a union; you've
defined a 128-bit structure with the IR fields *following* the non-IR
fields. But there *is* a union in io_apic.c, of that 128-bit structure
and two uint32_ts. Suspect that wasn't quite what you intended. I'll
prod at it this morning and turn it into a single union of the three,
and give it some testing.

Also, my "Move MSI support into hpet.c" patch¹ got updated to
s/CONFIG_PCI_MSI/CONFIG_GENERIC_MSI_IRQ/ at about line 53 for the MSI-
related variable declarations, which was going to be in the next
version I posted.

I was also hoping Paolo was going to take the patch which just defines
the KVM_FEATURE_MSI_EXT_DEST_ID bit² ASAP, so that we end up with a
second patch³ that *just* wires it up to x86_init.msi_ext_dest_id() for
KVM.

¹ https://git.infradead.org/users/dwmw2/linux.git/commitdiff/734719c1f4
² https://git.infradead.org/users/dwmw2/linux.git/commitdiff/3f371d6749
³ https://git.infradead.org/users/dwmw2/linux.git/commitdiff/8399e14eb5

> Yes, we can't avoid the bit swizzling at all. But it can be made more
> readable.

Hm, I was about to concede that your version is a bit more readable.

But then I got to your new __ipi_msi_compose_msg() and realised that it
isn't working because it's setting the 0xFEE base address in the _low_
bits, somehow...

msg->arch_addr_lo.base_address = X86_MSI_BASE_ADDRESS_LOW;
printk("1 Compose MSI message %x/%x\n", msg->address_lo, msg->data);
msg->arch_addr_lo.dest_mode_logical = apic->dest_mode_logical;
printk("2 Compose MSI message %x/%x\n", msg->address_lo, msg->data);
msg->arch_addr_lo.destid_0_7 = cfg->dest_apicid & 0xFF;
printk("3 Compose MSI message %x/%x\n", msg->address_lo, msg->data);

[1.793874] 1 Compose MSI message fee/0
[1.794310] 2 Compose MSI message fee/0
[1.794768] 3 Compose MSI message f02/0

And now I wish it was just a simple shift instead of an unholy maze of
overlapping unions of bitfields. But I'll make more coffee and stare at
it harder...

> Yes, that code is horrid, but adding a comment to that effect when
> changing it is not asked too much, right?

Sure. I just actually hadn't noticed that setting the dest/vector bits
right there was entirely redundant in the first place.

> I'm still wrapping my head around getting rid of this thing completely
> because now it's just a subset of your KVM case with the only
> restriction that I/O-APIC cannot be affined to any CPU with a APIC id
> greater than 255.

It was only ever that restriction anyway, wasn't it? Hyper-V PCI has
its own MSI handling, and there's no HPET so it was only ever the
I/OAPIC which was problematic there.

There are Hyper-V VM sizes with 416 vCPUs which depend on this today,
and which don't have the 15-bit MSI extension. Removing hyperv-iommu
would prevent us from using all the vCPUs on those. You *could* make
hyperv-iommu decline to initialise if x86_init.msi_ext_dest_id()
returns true though⁴.

⁴ https://git.infradead.org/users/dwmw2/linux.git/commitdiff/633ccf0d42

smime.p7s
Description: S/MIME cryptographic signature

Re: [linux-sunxi] [PATCH 01/14] phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes

2020-10-24 Thread Paul Kocialkowski

Hi Jernej,

On Fri 23 Oct 20, 20:18, Jernej Škrabec wrote:
> Dne petek, 23. oktober 2020 ob 19:45:33 CEST je Paul Kocialkowski napisal(a):
> > As some D-PHY controllers support both Rx and Tx mode, we need a way for
> > users to explicitly request one or the other. For instance, Rx mode can
> > be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI.
> > 
> > Introduce new MIPI D-PHY PHY submodes to use with PHY_MODE_MIPI_DPHY.
> > The default (zero value) is kept to Tx so only the rkisp1 driver, which
> > uses D-PHY in Rx mode, needs to be adapted.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/staging/media/rkisp1/rkisp1-isp.c |  3 ++-
> >  include/linux/phy/phy-mipi-dphy.h | 13 +
> 
> I think some changes are missing in this patch. For example, 
> phy_set_mode_ext() must be modified to take another argument, otherwise 
> change 
> of rkisp1-isp driver doesn't make much sense.

Thanks for looking into this! As you can see in:
https://elixir.bootlin.com/linux/latest/source/include/linux/phy/phy.h#L213

phy_set_mode_ext already takes a submode argument (which is already used for
USB mode selection, for instance) and phy_set_mode is just a macro which calls
phy_set_mode_ext with submode set to 0.

In our case, that means that most current users of phy_set_mode with
PHY_MODE_MIPI_DPHY will select Tx mode by default, so there is no particular
need for adaptation. Only the rkisp1 driver uses PHY_MODE_MIPI_DPHY for Rx,
so this one was changed to use phy_set_mode_ext with PHY_MIPI_DPHY_SUBMODE_RX
instead.

As a result, there should be no missing changes. Do you agree?

Cheers,

Paul

> Best regards,
> Jernej
> 
> >  2 files changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/media/rkisp1/rkisp1-isp.c b/drivers/staging/
> media/rkisp1/rkisp1-isp.c
> > index 6ec1e9816e9f..0afbce00121e 100644
> > --- a/drivers/staging/media/rkisp1/rkisp1-isp.c
> > +++ b/drivers/staging/media/rkisp1/rkisp1-isp.c
> > @@ -902,7 +902,8 @@ static int rkisp1_mipi_csi2_start(struct rkisp1_isp 
> *isp,
> >  
> > phy_mipi_dphy_get_default_config(pixel_clock, isp->sink_fmt-
> >bus_width,
> >  sensor->lanes, cfg);
> > -   phy_set_mode(sensor->dphy, PHY_MODE_MIPI_DPHY);
> > +   phy_set_mode_ext(cdev->dphy, PHY_MODE_MIPI_DPHY,
> > +PHY_MIPI_DPHY_SUBMODE_RX);
> > phy_configure(sensor->dphy, );
> > phy_power_on(sensor->dphy);
> >  
> > diff --git a/include/linux/phy/phy-mipi-dphy.h b/include/linux/phy/phy-mipi-
> dphy.h
> > index a877ffee845d..0f57ef46a8b5 100644
> > --- a/include/linux/phy/phy-mipi-dphy.h
> > +++ b/include/linux/phy/phy-mipi-dphy.h
> > @@ -6,6 +6,19 @@
> >  #ifndef __PHY_MIPI_DPHY_H_
> >  #define __PHY_MIPI_DPHY_H_
> >  
> > +/**
> > + * enum phy_mipi_dphy_submode - MIPI D-PHY sub-mode
> > + *
> > + * A MIPI D-PHY can be used to transmit or receive data.
> > + * Since some controllers can support both, the direction to enable is 
> specified
> > + * with the PHY sub-mode. Transmit is assumed by default with phy_set_mode.
> > + */
> > +
> > +enum phy_mipi_dphy_submode {
> > +   PHY_MIPI_DPHY_SUBMODE_TX = 0,
> > +   PHY_MIPI_DPHY_SUBMODE_RX,
> > +};
> > +
> >  /**
> >   * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
> >   *
> > -- 
> > 2.28.0
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> > To view this discussion on the web, visit https://groups.google.com/d/msgid/
> linux-sunxi/20201023174546.504028-2-paul.kocialkowski%40bootlin.com.
> > 
> 
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v2 8/8] x86/ioapic: Generate RTE directly from parent irqchip's MSI message

On Sat, 2020-10-24 at 09:26 +0100, David Woodhouse wrote:
> 
> And now I wish it was just a simple shift instead of an unholy maze of
> overlapping unions of bitfields. But I'll make more coffee and stare at
> it harder...

Hah, it really *was* unions of the bitfields. This boots...

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index c65e89bedc93..3e14adba34ba 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -65,6 +65,8 @@ union IO_APIC_reg_03 {
 };
 
 struct IO_APIC_route_entry {
+  union {
+struct {
u64 vector  :  8,
delivery_mode   :  3,
dest_mode_logical   :  1,
@@ -77,7 +79,8 @@ struct IO_APIC_route_entry {
reserved_1  : 17,
virt_destid_8_14:  7,
destid_0_7  :  8;
-
+};
+struct {
u64 ir_shared_0 :  8,
ir_zero :  3,
ir_index_15 :  1,
@@ -85,6 +88,8 @@ struct IO_APIC_route_entry {
ir_reserved_0   : 31,
ir_format   :  1,
ir_index_0_14   : 15;
+};
+  };
 } __attribute__ ((packed));
 
 struct irq_alloc_info;
diff --git a/arch/x86/include/asm/msi.h b/arch/x86/include/asm/msi.h
index 8cf82d134b78..ef9dfaa4603f 100644
--- a/arch/x86/include/asm/msi.h
+++ b/arch/x86/include/asm/msi.h
@@ -25,6 +25,7 @@ typedef struct x86_msi_data {
 
 typedef struct x86_msi_addr_lo {
union {
+   struct {
u32 reserved_0  :  2,
dest_mode_logical   :  1,
redirect_hint   :  1,
@@ -32,13 +33,15 @@ typedef struct x86_msi_addr_lo {
virt_destid_8_14:  7,
destid_0_7  :  8,
base_address: 12;
-
+   };
+   struct {
u32 dmar_reserved_0 :  2,
dmar_index_15   :  1,
dmar_subhandle_valid:  1,
dmar_format :  1,
dmar_index_0_14 : 15,
dmar_base_address   : 12;
+   };
};
 } __attribute__ ((packed)) arch_msi_msg_addr_lo_t;
 #define arch_msi_msg_addr_lo   x86_msi_addr_lo



smime.p7s
Description: S/MIME cryptographic signature

Greetings dear friend,

2020-10-24 Thread Mrs. Aisha Gaddafi




Greetings dear friend,

My names are Aisha Gaddafi the only daughter of the former Libyan leader 
Muammar Gaddafi.

You have been recommended by your countries Chamber of Commerce to receive a 
donation of one million United State Dollars (US$1, 000, 000, 00) from me. This 
donation is meant to help and assist the poor, orphans and the sick in your 
area. I decided to make this donation to assist mankind after recovering part 
of my inheritance abroad from the Libyan transition Government.

Dear beloved I will like you to bear in mind that this is a work for charity to 
humanity in this pandemic period , if you are willing and ready for this 
project send the below information.

Full Names
Contact Address
Phone Number
Age
Country of origin
Attached copy of your ID

Yours Aisha Gaddafi

Re: [RFC PATCH v3 9/9] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows

2020-10-24 Thread Dan Scally

On 24/10/2020 02:24, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
Thank you for reviewing it - very helpful comments
>
> On Mon, Oct 19, 2020 at 11:59:03PM +0100, Daniel Scally wrote:
>> Currently on platforms designed for Windows, connections between CIO2 and
>> sensors are not properly defined in DSDT. This patch extends the ipu3-cio2
>> driver to compensate by building software_node connections, parsing the
>> connection properties from the sensor's SSDB buffer.
>>
>> Suggested-by: Jordan Hand 
>> Signed-off-by: Daniel Scally 
>> ---
>> Changes in v3:
>>  - Rather than overwriting the device's primary fwnode, we now
>>  simply assign a secondary. Some of the preceding patches alter the
>>  existing driver code and v4l2 framework to allow for that.
>>  - Rather than reprobe() the sensor after connecting the devices in
>>  cio2-bridge we create the software_nodes right away. In this case,
>>  sensor drivers will have to defer probing until they detect that a
>>  fwnode graph is connecting them to the CIO2 device.
>>  - Error paths in connect_supported_devices() moved outside the
>>  loop
>>  - Replaced pr_*() with dev_*() throughout
>>  - Moved creation of software_node / property_entry arrays to stack
>>  - A lot of formatting changes.
>>
>>  MAINTAINERS   |   1 +
>>  drivers/media/pci/intel/ipu3/Kconfig  |  18 +
>>  drivers/media/pci/intel/ipu3/Makefile |   3 +-
>>  drivers/media/pci/intel/ipu3/cio2-bridge.c| 327 ++
>>  drivers/media/pci/intel/ipu3/cio2-bridge.h|  94 +
>>  drivers/media/pci/intel/ipu3/ipu3-cio2-main.c |  21 ++
>>  drivers/media/pci/intel/ipu3/ipu3-cio2.h  |   9 +
>>  7 files changed, 472 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.c
>>  create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 5d768d5ad..4c9c646c7 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -8848,6 +8848,7 @@ INTEL IPU3 CSI-2 CIO2 DRIVER
>>  M:  Yong Zhi 
>>  M:  Sakari Ailus 
>>  M:  Bingbu Cao 
>> +M:  Dan Scally 
>>  R:  Tianshu Qiu 
>>  L:  linux-me...@vger.kernel.org
>>  S:  Maintained
>> diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
>> b/drivers/media/pci/intel/ipu3/Kconfig
>> index 82d7f17e6..d14cbceae 100644
>> --- a/drivers/media/pci/intel/ipu3/Kconfig
>> +++ b/drivers/media/pci/intel/ipu3/Kconfig
>> @@ -16,3 +16,21 @@ config VIDEO_IPU3_CIO2
>>Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
>>connected camera.
>>The module will be called ipu3-cio2.
>> +
>> +config CIO2_BRIDGE
>> +bool "IPU3 CIO2 Sensors Bridge"
>> +depends on VIDEO_IPU3_CIO2
>> +help
>> +  This extension provides an API for the ipu3-cio2 driver to create
>> +  connections to cameras that are hidden in SSDB buffer in ACPI. It
>> +  can be used to enable support for cameras in detachable / hybrid
>> +  devices that ship with Windows.
>> +
>> +  Say Y here if your device is a detachable / hybrid laptop that comes
>> +  with Windows installed by the OEM, for example:
>> +
>> +- Some Microsoft Surface models
>> +- The Lenovo Miix line
>> +- Dell 7285
>> +
>> +  If in doubt, say N here.
>> diff --git a/drivers/media/pci/intel/ipu3/Makefile 
>> b/drivers/media/pci/intel/ipu3/Makefile
>> index b4e3266d9..933777e6e 100644
>> --- a/drivers/media/pci/intel/ipu3/Makefile
>> +++ b/drivers/media/pci/intel/ipu3/Makefile
>> @@ -1,4 +1,5 @@
>>  # SPDX-License-Identifier: GPL-2.0-only
>>  obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
>>  
>> -ipu3-cio2-y += ipu3-cio2-main.o
>> \ No newline at end of file
>> +ipu3-cio2-y += ipu3-cio2-main.o
>> +ipu3-cio2-$(CONFIG_CIO2_BRIDGE) += cio2-bridge.o
>> diff --git a/drivers/media/pci/intel/ipu3/cio2-bridge.c 
>> b/drivers/media/pci/intel/ipu3/cio2-bridge.c
>> new file mode 100644
>> index 0..bbe072f04
>> --- /dev/null
>> +++ b/drivers/media/pci/intel/ipu3/cio2-bridge.c
>> @@ -0,0 +1,327 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Author: Dan Scally 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "cio2-bridge.h"
>> +
>> +/*
>> + * Extend this array with ACPI Hardware ID's of devices known to be
>> + * working
>> + */
>> +static const char * const supported_devices[] = {
>> +"INT33BE",
>> +"OVTI2680",
>> +};
>> +
>> +static struct software_node cio2_hid_node = { CIO2_HID };
>> +
>> +static struct cio2_bridge bridge;
> While there shouldn't be more than one CIO2 instance, we try to develop
> drivers in a way that avoids global per-device variables. Could all this
> be allocated dynamically, with the pointer returned by
> cio2_bridge_build() and stored in the cio2_device structure ?
Yes, ok, I'll make that change.
>> +
>>

Re: [PATCH v2 1/4] tracing/dynevent: Delegate parsing to create function

2020-10-24 Thread Masami Hiramatsu

Hi Tom,

Thanks for the update!

On Fri, 23 Oct 2020 15:33:52 -0500
Tom Zanussi  wrote:

> From: Masami Hiramatsu 
> 
> Delegate command parsing to each create function so that the
> command syntax can be customized.
> 
> Signed-off-by: Masami Hiramatsu 
> [ zanu...@kernel.org: added synthetic event modifications ]

Since you've customized the synth_event parser, could you update
the patch description? (Or split this into 2 patches)

> Signed-off-by: Tom Zanussi 
> ---
>  kernel/trace/trace.c  |  23 +---
>  kernel/trace/trace.h  |   3 +-
>  kernel/trace/trace_dynevent.c |  35 +++---
>  kernel/trace/trace_dynevent.h |   4 +-
>  kernel/trace/trace_events_synth.c | 186 --
>  kernel/trace/trace_kprobe.c   |  33 +++---
>  kernel/trace/trace_probe.c|  17 +++
>  kernel/trace/trace_probe.h|   1 +
>  kernel/trace/trace_uprobe.c   |  17 ++-
>  9 files changed, 174 insertions(+), 145 deletions(-)

[..]
> @@ -1223,26 +1176,43 @@ static int __create_synth_event(int argc, const char 
> *name, const char **argv)
>   goto out;
>   }
>  
> - for (i = 0; i < argc - 1; i++) {
> - if (strcmp(argv[i], ";") == 0)
> - continue;
> + tmp_fields = saved_fields = kstrdup(raw_fields, GFP_KERNEL);
> + if (!tmp_fields) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + while ((field_str = strsep(_fields, ";")) != NULL) {
>   if (n_fields == SYNTH_FIELDS_MAX) {
>   synth_err(SYNTH_ERR_TOO_MANY_FIELDS, 0);
>   ret = -EINVAL;
>   goto err;
>   }
>  
> - field = parse_synth_field(argc - i, [i], );
> + argv = argv_split(GFP_KERNEL, field_str, );
> + if (!argv) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + if (!argc)
> + continue;
> +
> + field = parse_synth_field(argc, argv);
>   if (IS_ERR(field)) {
> + argv_free(argv);
>   ret = PTR_ERR(field);
>   goto err;
>   }
> +
> + argv_free(argv);
> +
>   fields[n_fields++] = field;
>   i += consumed - 1;

You may not need this line (and "consumed") anymore?

>   }
>  
> - if (i < argc && strcmp(argv[i], ";") != 0) {
> - synth_err(SYNTH_ERR_INVALID_FIELD, errpos(argv[i]));
> + if (n_fields == 0) {
> + synth_err(SYNTH_ERR_CMD_INCOMPLETE, 0);
>   ret = -EINVAL;
>   goto err;
>   }
> @@ -1261,6 +1231,8 @@ static int __create_synth_event(int argc, const char 
> *name, const char **argv)
>   out:
>   mutex_unlock(_mutex);
>  
> + kfree(saved_fields);
> +
>   return ret;
>   err:
>   for (i = 0; i < n_fields; i++)
> @@ -1378,18 +1350,35 @@ int synth_event_delete(const char *event_name)
>  }
>  EXPORT_SYMBOL_GPL(synth_event_delete);
>  
> -static int create_or_delete_synth_event(int argc, char **argv)
> +static int create_or_delete_synth_event(const char *raw_command)
>  {
> - const char *name = argv[0];
> - int ret;
> + char **argv, *name = NULL, *fields;
> + int argc = 0, ret = 0;
> +
> + last_cmd_set(raw_command);
> +
> + argv = argv_split(GFP_KERNEL, raw_command, );
> + if (!argv)
> + return -ENOMEM;

If you are sure the first argument is the name, you don't need
to use argv_split, but just strpbrk(raw_command, " \t"), something
like this.

raw_command = skip_spaces(raw_command);
p = strpbrk(raw_command, " \t");
if (!p)
return -EINVAL;

name = kmemdup_nul(raw_command, p - raw_command, GFP_KERNEL);
field = skip_spaces(p);

...

ret = __create_synth_event(name, fields);
free:
kfree(name);

(BTW, we should have find_spaces() instead of slow strpbrk().)


Thank you,


-- 
Masami Hiramatsu

[GIT PULL] KVM fixes for Linux 5.10-rc1

Linus,

The following changes since commit 29cf0f5007a215b51feb0ae25ca5353480d53ead:

  kvm: x86/mmu: NX largepage recovery for TDP MMU (2020-10-23 03:42:16 -0400)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

for you to fetch changes up to 77377064c3a94911339f13ce113b3abf265e06da:

  KVM: ioapic: break infinite recursion on lazy EOI (2020-10-24 04:42:06 -0400)


Two fixes for the pull request, and an unrelated bugfix for
a host hang.



Paolo Bonzini (1):
  KVM: vmx: rename pi_init to avoid conflict with paride

Sean Christopherson (1):
  KVM: x86/mmu: Avoid modulo operator on 64-bit value to fix i386 build

Vitaly Kuznetsov (1):
  KVM: ioapic: break infinite recursion on lazy EOI

 arch/x86/kvm/ioapic.c  | 5 +
 arch/x86/kvm/mmu/tdp_mmu.c | 2 +-
 arch/x86/kvm/vmx/posted_intr.c | 2 +-
 arch/x86/kvm/vmx/posted_intr.h | 4 ++--
 arch/x86/kvm/vmx/vmx.c | 2 +-
 5 files changed, 6 insertions(+), 9 deletions(-)

[PATCH v3] checkpatch: extend attributes check to handle more patterns

2020-10-24 Thread Dwaipayan Ray

It is generally preferred that the macros from
include/linux/compiler_attributes.h are used, unless there
is a reason not to.

checkpatch currently checks __attribute__ for each of
packed, aligned, printf, scanf, and weak. Other declarations
in compiler_attributes.h are not handled.

Add a generic test to check the presence of such attributes.
Some attributes require more specific handling and are kept
separate.

New attributes which are now handled are:

__alias__(#symbol)
__always_inline__
__assume_aligned__(a, ## __VA_ARGS__)
__cold__
__const__
__copy__(symbol)
__designated_init__
__externally_visible__
__gnu_inline__
__malloc__
__mode__(x)
__no_caller_saved_registers__
__noclone__
__fallthrough__
__noinline__
__nonstring__
__noreturn__
__pure__
__unused__
__used__

Link: 
https://lore.kernel.org/linux-kernel-mentees/3ec15b41754b01666d94b76ce51b9832c2dd577a.ca...@perches.com/
Suggested-by: Joe Perches 
Signed-off-by: Dwaipayan Ray 
---
 scripts/checkpatch.pl | 105 +++---
 1 file changed, 69 insertions(+), 36 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 7e505688257a..01d83d345b4c 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6155,50 +6155,83 @@ sub process {
}
}
 
-# Check for __attribute__ packed, prefer __packed
+# Check for compiler attributes
if ($realfile !~ m@\binclude/uapi/@ &&
-   $line =~ /\b__attribute__\s*\(\s*\(.*\bpacked\b/) {
-   WARN("PREFER_PACKED",
-"__packed is preferred over 
__attribute__((packed))\n" . $herecurr);
-   }
+   $line =~ /__attribute__\s*\(\s*($balanced_parens)\s*\)/) {
+   my $attr = $1;
+   $attr =~ s/\s*\(\s*(.*)\)\s*/$1/;
+
+   my %attr_list = (
+   "alias" => "__alias",
+   "aligned"   => "__aligned",
+   "always_inline" => 
"__always_inline",
+   "assume_aligned"=> 
"__assume_aligned",
+   "cold"  => "__cold",
+   "const" => "__const",
+   "copy"  => "__copy",
+   "designated_init"   => 
"__designated_init",
+   "externally_visible"=> "__visible",
+   "fallthrough"   => 
"fallthrough",
+   "gnu_inline"=> 
"__gnu_inline",
+   "malloc"=> "__malloc",
+   "mode"  => "__mode",
+   "no_caller_saved_registers" => 
"__no_caller_saved_registers",
+   "noclone"   => "__noclone",
+   "noinline"  => "noinline",
+   "nonstring" => 
"__nonstring",
+   "noreturn"  => "__noreturn",
+   "packed"=> "__packed",
+   "pure"  => "__pure",
+   "used"  => "__used"
+   );
+
+   if ($attr =~ /^(\w+)\s*(${balanced_parens})?/) {
+   my $curr_attr = $1;
+   my $params = '';
+   $params = $2 if defined($2);
+   $curr_attr =~ s/^[\s_]+|[\s_]+$//g;
+
+   if (exists($attr_list{$curr_attr})) {
+   my $new = $attr_list{$curr_attr};
+   WARN("PREFER_DEFINED_ATTRIBUTE_MACRO",
+"$new$params is preffered over 
__attribute__(($attr))\n" . $herecurr);
+   }
+   }
 
-# Check for __attribute__ aligned, prefer __aligned
-   if ($realfile !~ m@\binclude/uapi/@ &&
-   $line =~ /\b__attribute__\s*\(\s*\(.*aligned/) {
-   WARN("PREFER_ALIGNED",
-"__aligned(size) is preferred over 
__attribute__((aligned(size)))\n" . $herecurr);
-   }
+   # Check for __attribute__ format(printf, prefer __printf
+   if ($attr =~ /^_*format_*\s*\(\s*printf/) {
+   if (WARN("PREFER_DEFINED_ATTRIBUTE_MACRO",
+

Re: [PATCH v2 8/8] x86/ioapic: Generate RTE directly from parent irqchip's MSI message

On 24/10/20 10:26, David Woodhouse wrote:
> I was also hoping Paolo was going to take the patch which just defines
> the KVM_FEATURE_MSI_EXT_DEST_ID bit² ASAP, so that we end up with a
> second patch³ that *just* wires it up to x86_init.msi_ext_dest_id() for
> KVM.
> 
> ¹ https://git.infradead.org/users/dwmw2/linux.git/commitdiff/734719c1f4
> ² https://git.infradead.org/users/dwmw2/linux.git/commitdiff/3f371d6749
> ³ https://git.infradead.org/users/dwmw2/linux.git/commitdiff/8399e14eb5

Yes, I am going to take it.

I was already sort of playing with fire with the 5.10 pull request (and
with me being lousy in general during the 5.10 development period, to be
honest), so I left it for rc2 or rc3.  It's just docs and it happened to
conflict with another documentation patch that had gone in through Jon
Corbet's tree.

Paolo

[ANNOUNCE] v5.9.1-rt19

2020-10-24 Thread Sebastian Andrzej Siewior

Dear RT folks!

I'm pleased to announce the v5.9.1-rt19 patch set. 

Changes since v5.9.1-rt18:

  - Mike Galbraith reported a possible circular locking dependency with
a seqcount. Backported a patch from upstream solving the issue.

  - David Runge reported a crash in the block layer.

  - The migrate-disable series by Peter Zijlstra has been update to v4.

  - Mike Galbraith reported a possible hang due to the new printk code.
Dropped a patch from the printk code which was causing the problem
as suggested by John Ogness.

  - The rtmutex clean up in v5.9-rc8-rt12 restructured the code path and
removed the blk_schedule_flush_plug() invocation from the locking
path. It turns out that it is still required and has been added
back.

  - A small rtmutex related clean up:

- Remove rt_mutex_lock_killable(), it has no users.

- Use _mutex_lock_io_nested() for _mutex_lock_io() to avoid
  duplicated code.

Known issues
 - It has been pointed out that due to changes to the printk code the
   internal buffer representation changed. This is only an issue if tools
   like `crash' are used to extract the printk buffer from a kernel memory
   image.

The delta patch against v5.9.1-rt18 is appended below and can be found here:
 
 
https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.9/incr/patch-5.9.1-rt18-rt19.patch.xz

You can get this release via the git tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git 
v5.9.1-rt19

The RT patch against v5.9.1 can be found here:


https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.9/older/patch-5.9.1-rt19.patch.xz

The split quilt queue is available at:


https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.9/older/patches-5.9.1-rt19.tar.xz

Sebastian

diff --git a/block/blk-mq.c b/block/blk-mq.c
index e37aa31332b70..99d2fb51e0e84 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -647,7 +647,7 @@ static inline bool blk_mq_complete_need_ipi(struct request 
*rq)
 {
int cpu = raw_smp_processor_id();
 
-   if (!IS_ENABLED(CONFIG_SMP) ||
+   if (!IS_ENABLED(CONFIG_SMP) || IS_ENABLED(CONFIG_PREEMPT_RT) ||
!test_bit(QUEUE_FLAG_SAME_COMP, >q->queue_flags))
return false;
 
diff --git a/include/linux/mutex_rt.h b/include/linux/mutex_rt.h
index 7179367bfb5e2..f0b2e07cd5c57 100644
--- a/include/linux/mutex_rt.h
+++ b/include/linux/mutex_rt.h
@@ -29,7 +29,6 @@ struct mutex {
 
 extern void __mutex_do_init(struct mutex *lock, const char *name, struct 
lock_class_key *key);
 extern void __lockfunc _mutex_lock(struct mutex *lock);
-extern void __lockfunc _mutex_lock_io(struct mutex *lock);
 extern void __lockfunc _mutex_lock_io_nested(struct mutex *lock, int subclass);
 extern int __lockfunc _mutex_lock_interruptible(struct mutex *lock);
 extern int __lockfunc _mutex_lock_killable(struct mutex *lock);
@@ -46,7 +45,7 @@ extern void __lockfunc _mutex_unlock(struct mutex *lock);
 #define mutex_lock_killable(l) _mutex_lock_killable(l)
 #define mutex_trylock(l)   _mutex_trylock(l)
 #define mutex_unlock(l)_mutex_unlock(l)
-#define mutex_lock_io(l)   _mutex_lock_io(l);
+#define mutex_lock_io(l)   _mutex_lock_io_nested(l, 0);
 
 #define __mutex_owner(l)   ((l)->lock.owner)
 
@@ -77,7 +76,7 @@ do {  
\
 # define mutex_lock_killable_nested(l, s) \
_mutex_lock_killable(l)
 # define mutex_lock_nest_lock(lock, nest_lock) mutex_lock(lock)
-# define mutex_lock_io_nested(l, s)_mutex_lock_io(l)
+# define mutex_lock_io_nested(l, s)_mutex_lock_io_nested(l, s)
 #endif
 
 # define mutex_init(mutex) \
diff --git a/include/linux/rtmutex.h b/include/linux/rtmutex.h
index 5308cd7f0..b02009f530263 100644
--- a/include/linux/rtmutex.h
+++ b/include/linux/rtmutex.h
@@ -112,7 +112,6 @@ extern void rt_mutex_lock(struct rt_mutex *lock);
 #endif
 
 extern int rt_mutex_lock_interruptible(struct rt_mutex *lock);
-extern int rt_mutex_lock_killable(struct rt_mutex *lock);
 extern int rt_mutex_trylock(struct rt_mutex *lock);
 
 extern void rt_mutex_unlock(struct rt_mutex *lock);
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index f73c7eb68f27c..76e44e6c01004 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -173,6 +173,19 @@ static inline void seqcount_lockdep_reader_access(const 
seqcount_t *s)
  * @lock:  Pointer to the associated lock
  */
 
+#define seqcount_LOCKNAME_init(s, _lock, lockname) \
+   do {\
+   seqcount_##lockname##_t *s = (s);   \
+   seqcount_init(&s->seqcount);\
+   __SEQ_LOCK(s->lock = (_lock));  \
+   } while (0)
+

[GIT PULL] x86/seves fixes for v5.10-rc1

2020-10-24 Thread Borislav Petkov

Hi Linus,

please pull three SEV-ES fixes for 5.10. They got ready around the same
time the merge window opened so I gave them some additional testing and
soaking time before sending them your way.

Please pull,
thx.

---
The following changes since commit da9803dfd3955bd2f9909d55e23f188ad76dbe58:

  Merge tag 'x86_seves_for_v5.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2020-10-14 10:21:34 
-0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
tags/x86_seves_fixes_for_v5.10_rc1

for you to fetch changes up to b17a45b6e53f6613118b2e5cfc4a992cc50deb2c:

  x86/boot/64: Explicitly map boot_params and command line (2020-10-19 19:39:50 
+0200)


Three fixes to SEV-ES to correct setting up the new early pagetable
on 5-level paging machines, to always map boot_params and the kernel
cmdline, and disable stack protector for ../compressed/head{32,64}.c.
(Arvind Sankar)


Arvind Sankar (3):
  x86/boot/64: Initialize 5-level paging variables earlier
  x86/head/64: Disable stack protection for head$(BITS).o
  x86/boot/64: Explicitly map boot_params and command line

 arch/x86/boot/compressed/head_64.S  |  3 +++
 arch/x86/boot/compressed/ident_map_64.c | 27 +++
 arch/x86/boot/compressed/kaslr.c|  8 
 arch/x86/boot/compressed/pgtable_64.c   | 16 
 arch/x86/kernel/Makefile|  2 ++
 5 files changed, 40 insertions(+), 16 deletions(-)

-- 
Regards/Gruss,
Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG 
Nürnberg

Re: [PATCH v4] checkpatch: fix false positives in REPEATED_WORD warning

2020-10-24 Thread Aditya

On 24/10/20 7:07 am, Joe Perches wrote:
> On Sat, 2020-10-24 at 05:38 +0530, Aditya Srivastava wrote: 
>> A quick evaluation on v5.6..v5.8 showed that this fix reduces
>> REPEATED_WORD warnings from 2797 to 907.
> 
> How many of these 907 remaining are still false positive?
>  
>> A quick manual check found all cases are related to hex output or
>> list command outputs in commit messages.
> 
> You mean 1890 of the 2797 are now no longer reported and all 1890
> were false positives yes?
> 

Yes. In v5.6..5.8, there were 2797 warnings for REPEATED_WORD, after
these changes, they are reduced to 907.
However, many among these 907 must have been fixed by Dwaipayan's
patch. I'll replace it with 1890 instead, for the better.

>>  pos($rawline) = 1 if (!$in_commit_log);
>>  while ($rawline =~ /\b($word_pattern) 
>> (?=($word_pattern))/g) {
>>  
>>
>> @@ -3074,6 +3076,17 @@ sub process {
>>  next if ($start_char =~ /^\S$/);
>>  next if (index(" \t.,;?!", $end_char) == -1);
>>  
>>
>> +# avoid repeating hex occurrences like 'ff 
>> ff fe 09 ...'
>> +my %allow_repeated_words = (
>> +add => '',
>> +added => '',
>> +bad => '',
>> +be => '',
>> +);
> 
> If perl caches this local hash declaration, fine,
> but I think it better to use 'our %allow_repeated_words'
> and move it so it's only declared using the file scope.
> 

I ran checkpatch over few commits, it was working fine. But I'll move
it to file scope, using 'our'. That should do as well.

>> +if ($first =~ /\b[0-9a-f]{2,}\b/) {
> 
> This regex matches only lower case so it wouldn't match "Add".
> 
> I think this regex would be clearer using
>   /^[0-9a-f]+$/i or /^[A-Fa-f0-9]+$/
> 
> 

Missed it. Will do.

Thanks
Aditya

Re: [RFC PATCH v3 9/9] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows

2020-10-24 Thread Laurent Pinchart

Hi Daniel,

On Sat, Oct 24, 2020 at 09:50:07AM +0100, Dan Scally wrote:
> On 24/10/2020 02:24, Laurent Pinchart wrote:
>
> > On Mon, Oct 19, 2020 at 11:59:03PM +0100, Daniel Scally wrote:
> >> Currently on platforms designed for Windows, connections between CIO2 and
> >> sensors are not properly defined in DSDT. This patch extends the ipu3-cio2
> >> driver to compensate by building software_node connections, parsing the
> >> connection properties from the sensor's SSDB buffer.
> >>
> >> Suggested-by: Jordan Hand 
> >> Signed-off-by: Daniel Scally 
> >> ---
> >> Changes in v3:
> >>- Rather than overwriting the device's primary fwnode, we now
> >>simply assign a secondary. Some of the preceding patches alter the
> >>existing driver code and v4l2 framework to allow for that.
> >>- Rather than reprobe() the sensor after connecting the devices in
> >>cio2-bridge we create the software_nodes right away. In this case,
> >>sensor drivers will have to defer probing until they detect that a
> >>fwnode graph is connecting them to the CIO2 device.
> >>- Error paths in connect_supported_devices() moved outside the
> >>loop
> >>- Replaced pr_*() with dev_*() throughout
> >>- Moved creation of software_node / property_entry arrays to stack
> >>- A lot of formatting changes.
> >>
> >>  MAINTAINERS   |   1 +
> >>  drivers/media/pci/intel/ipu3/Kconfig  |  18 +
> >>  drivers/media/pci/intel/ipu3/Makefile |   3 +-
> >>  drivers/media/pci/intel/ipu3/cio2-bridge.c| 327 ++
> >>  drivers/media/pci/intel/ipu3/cio2-bridge.h|  94 +
> >>  drivers/media/pci/intel/ipu3/ipu3-cio2-main.c |  21 ++
> >>  drivers/media/pci/intel/ipu3/ipu3-cio2.h  |   9 +
> >>  7 files changed, 472 insertions(+), 1 deletion(-)
> >>  create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.c
> >>  create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.h
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 5d768d5ad..4c9c646c7 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -8848,6 +8848,7 @@ INTEL IPU3 CSI-2 CIO2 DRIVER
> >>  M:Yong Zhi 
> >>  M:Sakari Ailus 
> >>  M:Bingbu Cao 
> >> +M:Dan Scally 
> >>  R:Tianshu Qiu 
> >>  L:linux-me...@vger.kernel.org
> >>  S:Maintained
> >> diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
> >> b/drivers/media/pci/intel/ipu3/Kconfig
> >> index 82d7f17e6..d14cbceae 100644
> >> --- a/drivers/media/pci/intel/ipu3/Kconfig
> >> +++ b/drivers/media/pci/intel/ipu3/Kconfig
> >> @@ -16,3 +16,21 @@ config VIDEO_IPU3_CIO2
> >>  Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
> >>  connected camera.
> >>  The module will be called ipu3-cio2.
> >> +
> >> +config CIO2_BRIDGE
> >> +  bool "IPU3 CIO2 Sensors Bridge"
> >> +  depends on VIDEO_IPU3_CIO2
> >> +  help
> >> +This extension provides an API for the ipu3-cio2 driver to create
> >> +connections to cameras that are hidden in SSDB buffer in ACPI. It
> >> +can be used to enable support for cameras in detachable / hybrid
> >> +devices that ship with Windows.
> >> +
> >> +Say Y here if your device is a detachable / hybrid laptop that comes
> >> +with Windows installed by the OEM, for example:
> >> +
> >> +  - Some Microsoft Surface models
> >> +  - The Lenovo Miix line
> >> +  - Dell 7285
> >> +
> >> +If in doubt, say N here.
> >> diff --git a/drivers/media/pci/intel/ipu3/Makefile 
> >> b/drivers/media/pci/intel/ipu3/Makefile
> >> index b4e3266d9..933777e6e 100644
> >> --- a/drivers/media/pci/intel/ipu3/Makefile
> >> +++ b/drivers/media/pci/intel/ipu3/Makefile
> >> @@ -1,4 +1,5 @@
> >>  # SPDX-License-Identifier: GPL-2.0-only
> >>  obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
> >>  
> >> -ipu3-cio2-y += ipu3-cio2-main.o
> >> \ No newline at end of file
> >> +ipu3-cio2-y += ipu3-cio2-main.o
> >> +ipu3-cio2-$(CONFIG_CIO2_BRIDGE) += cio2-bridge.o
> >> diff --git a/drivers/media/pci/intel/ipu3/cio2-bridge.c 
> >> b/drivers/media/pci/intel/ipu3/cio2-bridge.c
> >> new file mode 100644
> >> index 0..bbe072f04
> >> --- /dev/null
> >> +++ b/drivers/media/pci/intel/ipu3/cio2-bridge.c
> >> @@ -0,0 +1,327 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +// Author: Dan Scally 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include "cio2-bridge.h"
> >> +
> >> +/*
> >> + * Extend this array with ACPI Hardware ID's of devices known to be
> >> + * working
> >> + */
> >> +static const char * const supported_devices[] = {
> >> +  "INT33BE",
> >> +  "OVTI2680",
> >> +};
> >> +
> >> +static struct software_node cio2_hid_node = { CIO2_HID };
> >> +
> >> +static struct cio2_bridge bridge;
> >
> > While there shouldn't be more than one CIO2 instance, we try to develop
> > drivers in a way that

Does LOCKDEP work on ARM64?

2020-10-24 Thread Dmitry Vyukov

Hello ARM64/LOCKDEP maintainers,

I've started experimenting with running syzkaller on ARM64 using
QEMU/TCG. Total execution speed is very low and it ran just a handful
of tests, but I am seeing massive amounts of locking bugs. Most of
these were not observed on x86_64, while x86_64 ran gazillions of
tests by now and most of these are trivial to trigger (depend only on
call stack) and they do not look ARM64-specific. So I wonder:
1. Are there any known issues with LOCKDEP on ARM64?
2. Or are all these real and it's x86_64 LOCKDEP that's misbehaving?
3. Or are both x86_64 and ARM64 fine and these are just somehow ARM64-specific?

Here are details. Kernel is on
f9893351acaecf0a414baf9942b48d5bb5c688c6 (recent upstream HEAD).
Kernel config:
https://gist.githubusercontent.com/dvyukov/c92a1e08f3f7e22b1f0387096d98b18b/raw/9f79f83c3b018ac27a040649f7d0fef36b63b960/gistfile1.txt

Here is one "Invalid wait context". It looks like just a put_user
inside of syscall function:
https://gist.githubusercontent.com/dvyukov/15639a949278a981c8eb125b3088a6b8/raw/286117bc292578c07c8afbf0fa563cd5528821e7/gistfile1.txt

Here is one "bad unlock balance detected". The looks well balanced and
the code path is well exercised:
https://gist.githubusercontent.com/dvyukov/805f867823b9f77a26c2ebedec5b9b9e/raw/2e6605fb5c90f56ebd1ccda78d613b5c219dfb82/gistfile1.txt

Here is one "workqueue leaked lock". Again, lock/unlock are very local
and there is no control flow in between:
https://gist.githubusercontent.com/dvyukov/4d18d35a79d7e74bf66d6e7ec3794ec0/raw/1ff3e2a5d3a825eb0d196af1f81c67a47fa3a2f6/gistfile1.txt

Here is one confusing "bad unlock balance detected":
https://gist.githubusercontent.com/dvyukov/e222fa34e04104678c52a5b5b1ad15a3/raw/943c6ebbc022418b89fa63b6282fa1f1f40a276a/gistfile1.txt

Here is one confusing "suspicious RCU usage":
https://gist.githubusercontent.com/dvyukov/77b0ec246e1db86e549a80e4a11ec218/raw/0bce97be186c0a6617d8835a694443ed1aa2a98a/gistfile1.txt

Overall I have more than 50 of these now.

Re: [PATCH v2 8/8] x86/ioapic: Generate RTE directly from parent irqchip's MSI message




On 24 October 2020 10:13:36 BST, Paolo Bonzini  wrote:
>On 24/10/20 10:26, David Woodhouse wrote:
>> I was also hoping Paolo was going to take the patch which just
>defines
>> the KVM_FEATURE_MSI_EXT_DEST_ID bit² ASAP, so that we end up with a
>> second patch³ that *just* wires it up to x86_init.msi_ext_dest_id()
>for
>> KVM.
>> 
>> ¹
>https://git.infradead.org/users/dwmw2/linux.git/commitdiff/734719c1f4
>> ²
>https://git.infradead.org/users/dwmw2/linux.git/commitdiff/3f371d6749
>> ³
>https://git.infradead.org/users/dwmw2/linux.git/commitdiff/8399e14eb5
>
>Yes, I am going to take it.
>
>I was already sort of playing with fire with the 5.10 pull request (and
>with me being lousy in general during the 5.10 development period, to
>be
>honest), so I left it for rc2 or rc3.  It's just docs and it happened
>to
>conflict with another documentation patch that had gone in through Jon
>Corbet's tree.

OK, thanks. I'll rework Thomas's tree with that first and the other changes I'd 
mentioned in my parts, as well as fixing up that unholy chimæra of struct/union 
in which we set some bitfields from each side of the union, test and push it 
out later today.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

ld.lld: warning: fs/built-in.a(cifs/smb2pdu.o):(.data..L__unnamed_19) is being placed in '.data..L__unnamed_19'

2020-10-24 Thread kernel test robot

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f11901ed723d1351843771c3a84b03a253bbf8b2
commit: 511ac89e591ab9affce17a8be4c45f6c2bb837f0 smb3.1.1: print warning if 
server does not support requested encryption type
date:   5 days ago
config: powerpc64-randconfig-r004-20201022 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
147b9497e79a98a8614b2b5eb4ba653b44f6b6f0)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=511ac89e591ab9affce17a8be4c45f6c2bb837f0
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 511ac89e591ab9affce17a8be4c45f6c2bb837f0
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross 
ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_25) is 
being placed in '.data..L__unnamed_25'
   ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_26) is 
being placed in '.data..L__unnamed_26'
   ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_20) is 
being placed in '.data..L__unnamed_20'
   ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_21) is 
being placed in '.data..L__unnamed_21'
   ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_27) is 
being placed in '.data..L__unnamed_27'
   ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_33) is 
being placed in '.data..L__unnamed_33'
   ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_29) is 
being placed in '.data..L__unnamed_29'
   ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_30) is 
being placed in '.data..L__unnamed_30'
   ld.lld: warning: fs/built-in.a(cifs/dir.o):(.data..L__unnamed_1) is being 
placed in '.data..L__unnamed_1'
   ld.lld: warning: fs/built-in.a(cifs/dir.o):(.data..L__unnamed_2) is being 
placed in '.data..L__unnamed_2'
   ld.lld: warning: fs/built-in.a(cifs/dir.o):(.data..L__unnamed_3) is being 
placed in '.data..L__unnamed_3'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_1) is being 
placed in '.data..L__unnamed_1'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_4) is being 
placed in '.data..L__unnamed_4'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_7) is being 
placed in '.data..L__unnamed_7'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_8) is being 
placed in '.data..L__unnamed_8'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_11) is being 
placed in '.data..L__unnamed_11'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_12) is being 
placed in '.data..L__unnamed_12'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_3) is being 
placed in '.data..L__unnamed_3'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_5) is being 
placed in '.data..L__unnamed_5'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_6) is being 
placed in '.data..L__unnamed_6'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_9) is being 
placed in '.data..L__unnamed_9'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_10) is being 
placed in '.data..L__unnamed_10'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_14) is being 
placed in '.data..L__unnamed_14'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_13) is being 
placed in '.data..L__unnamed_13'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_15) is being 
placed in '.data..L__unnamed_15'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_16) is being 
placed in '.data..L__unnamed_16'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_18) is being 
placed in '.data..L__unnamed_18'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_17) is being 
placed in '.data..L__unnamed_17'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_20) is being 
placed in '.data..L__unnamed_20'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_19) is being 
placed in '.data..L__unnamed_19'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_21) is being 
placed in '.data..L__unnamed_21'
   ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_22) is being 
placed in '.data..L__unnamed_22'
   ld.lld: warning:

[PATCH v5] checkpatch: fix false positives in REPEATED_WORD warning

2020-10-24 Thread Aditya Srivastava

Presence of hexadecimal address or symbol results in false warning
message by checkpatch.pl.

For example, running checkpatch on commit b8ad540dd4e4 ("mptcp: fix
memory leak in mptcp_subflow_create_socket()") results in warning:

WARNING:REPEATED_WORD: Possible repeated word: 'ff'
00 00 00 00 00 00 00 00 00 2f 30 0a 81 88 ff ff  ./0.

Similarly, the presence of list command output in commit results in
an unnecessary warning.

For example, running checkpatch on commit 899e5ffbf246 ("perf record:
Introduce --switch-output-event") gives:

WARNING:REPEATED_WORD: Possible repeated word: 'root'
  dr-xr-x---. 12 root root4096 Apr 27 17:46 ..

Here, it reports 'ff' and 'root' to be repeated, but it is in fact part
of some address or code, where it has to be repeated.

In these cases, the intent of the warning to find stylistic issues in
commit messages is not met and the warning is just completely wrong in
this case.

To avoid these warnings, add an additional regex check for the
directory permission pattern and avoid checking the line for this
class of warning. Similarly, to avoid hex pattern, check if the word
consists of hex symbols and skip this warning if it is not among the
common english words formed using hex letters.

A quick evaluation on v5.6..v5.8 showed that this fix reduces
REPEATED_WORD warnings by the frequency of 1890.

A quick manual check found all cases are related to hex output or
list command outputs in commit messages.

Signed-off-by: Aditya Srivastava 
---
 scripts/checkpatch.pl | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 7e505688257a..519da711cb12 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -853,6 +853,13 @@ our $declaration_macros = qr{(?x:
(?:SKCIPHER_REQUEST|SHASH_DESC|AHASH_REQUEST)_ON_STACK\s*\(
 )};
 
+our %allow_repeated_words = (
+   add => '',
+   added => '',
+   bad => '',
+   be => '',
+);
+
 sub deparenthesize {
my ($string) = @_;
return "" if (!defined($string));
@@ -3049,7 +3056,9 @@ sub process {
}
 
 # check for repeated words separated by a single space
-   if ($rawline =~ /^\+/ || $in_commit_log) {
+# avoid false positive from list command eg, '-rw-r--r-- 1 root root'
+   if (($rawline =~ /^\+/ || $in_commit_log) &&
+   $rawline !~ /[bcCdDlMnpPs\?-][rwxsStT-]{9}/) {
pos($rawline) = 1 if (!$in_commit_log);
while ($rawline =~ /\b($word_pattern) 
(?=($word_pattern))/g) {
 
@@ -3074,6 +3083,11 @@ sub process {
next if ($start_char =~ /^\S$/);
next if (index(" \t.,;?!", $end_char) == -1);
 
+# avoid repeating hex occurrences like 'ff ff 
fe 09 ...'
+if ($first =~ /\b[0-9a-f]{2,}\b/i) {
+next if 
(!exists($allow_repeated_words{lc($first)}));
+}
+
if (WARN("REPEATED_WORD",
 "Possible repeated word: '$first'\n" . 
$herecurr) &&
$fix) {
-- 
2.17.1

Re: [PATCH v2 1/3] powerpc/uaccess: Don't use "m<>" constraint with GCC 4.9

2020-10-24 Thread Michael Ellerman

On Tue, 20 Oct 2020 07:40:07 + (UTC), Christophe Leroy wrote:
> GCC 4.9 sometimes fails to build with "m<>" constraint in
> inline assembly.
> 
>   CC  lib/iov_iter.o
> In file included from ./arch/powerpc/include/asm/cmpxchg.h:6:0,
>  from ./arch/powerpc/include/asm/atomic.h:11,
>  from ./include/linux/atomic.h:7,
>  from ./include/linux/crypto.h:15,
>  from ./include/crypto/hash.h:11,
>  from lib/iov_iter.c:2:
> lib/iov_iter.c: In function 'iovec_from_user.part.30':
> ./arch/powerpc/include/asm/uaccess.h:287:2: error: 'asm' operand has 
> impossible constraints
>   __asm__ __volatile__(\
>   ^
> ./include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
>  # define unlikely(x) __builtin_expect(!!(x), 0)
>   ^
> ./arch/powerpc/include/asm/uaccess.h:583:34: note: in expansion of macro 
> 'unsafe_op_wrap'
>  #define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
>   ^
> ./arch/powerpc/include/asm/uaccess.h:329:10: note: in expansion of macro 
> '__get_user_asm'
>   case 4: __get_user_asm(x, (u32 __user *)ptr, retval, "lwz"); break; \
>   ^
> ./arch/powerpc/include/asm/uaccess.h:363:3: note: in expansion of macro 
> '__get_user_size_allowed'
>__get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \
>^
> ./arch/powerpc/include/asm/uaccess.h:100:2: note: in expansion of macro 
> '__get_user_nocheck'
>   __get_user_nocheck((x), (ptr), sizeof(*(ptr)), false)
>   ^
> ./arch/powerpc/include/asm/uaccess.h:583:49: note: in expansion of macro 
> '__get_user_allowed'
>  #define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
>  ^
> lib/iov_iter.c:1663:3: note: in expansion of macro 'unsafe_get_user'
>unsafe_get_user(len, [i].iov_len, uaccess_end);
>^
> make[1]: *** [scripts/Makefile.build:283: lib/iov_iter.o] Error 1
> 
> [...]

Patch 1 applied to powerpc/fixes.

[1/3] powerpc/uaccess: Don't use "m<>" constraint with GCC 4.9
  https://git.kernel.org/powerpc/c/592bbe9c505d9a0ef69260f8c8263df47da2698e

cheers

[PATCH] switch "random: fast init done" message from NOTICE to INFO.

2020-10-24 Thread Rob Landley

From: Rob Landley 

If you loglevel=4 you get zero kernel boot messages, but at loglevel=5
the shell prompt is overwritten on devices that boot to a serial console
a second after it comes up, and if the prompt is "#" it's easy to think the
boot's hung.

Signed-off-by: Rob Landley 
---

 drivers/char/random.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index d20ba1b104ca..91daf9113204 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -895,7 +895,7 @@ static int crng_fast_load(const char *cp, size_t len)
if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
invalidate_batched_entropy();
crng_init = 1;
-   pr_notice("fast init done\n");
+   pr_info("fast init done\n");
}
return 1;
 }

[GIT PULL] Please pull powerpc/linux.git powerpc-5.10-2 tag

2020-10-24 Thread Michael Ellerman

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Linus,

Please pull powerpc fixes for 5.10:

The following changes since commit ffd0b25ca049a477cb757e5bcf2d5e1664d12e5d:

  Revert "powerpc/pci: unmap legacy INTx interrupts when a PHB is removed" 
(2020-10-15 13:42:49 +1100)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-5.10-2

for you to fetch changes up to 4ff753feab021242144818b9a3ba011238218145:

  powerpc/pseries: Avoid using addr_to_pfn in real mode (2020-10-22 14:34:45 
+1100)

- --
powerpc fixes for 5.10 #2

A fix for undetected data corruption on Power9 Nimbus <= DD2.1 in the emulation
of VSX loads. The affected CPUs were not widely available.

Two fixes for machine check handling in guests under PowerVM.

A fix for our recent changes to SMP setup, when CONFIG_CPUMASK_OFFSTACK=y.

Three fixes for races in the handling of some of our powernv sysfs attributes.

One change to remove TM from the set of Power10 CPU features.

A couple of other minor fixes.

Thanks to:
  Aneesh Kumar K.V, Christophe Leroy, Ganesh Goudar, Jordan Niethe, Mahesh
  Salgaonkar, Michael Neuling, Oliver O'Halloran, Qian Cai, Srikar Dronamraju,
  Vasant Hegde.

- --
Aneesh Kumar K.V (1):
  powerpc/opal_elog: Handle multiple writes to ack attribute

Christophe Leroy (1):
  powerpc/uaccess: Don't use "m<>" constraint with GCC 4.9

Ganesh Goudar (2):
  powerpc/mce: Avoid nmi_enter/exit in real mode on pseries hash
  powerpc/pseries: Avoid using addr_to_pfn in real mode

Jordan Niethe (1):
  powerpc/64s: Remove TM from Power10 features

Michael Neuling (2):
  powerpc: Fix undetected data corruption with P9N DD2.1 VSX CI load 
emulation
  selftests/powerpc: Make alignment handler test P9N DD2.1 vector CI load 
workaround

Oliver O'Halloran (1):
  powerpc/eeh: Fix eeh_dev_check_failure() for PE#0

Srikar Dronamraju (2):
  powerpc/smp: Remove unnecessary variable
  powerpc/smp: Use GFP_ATOMIC while allocating tmp mask

Vasant Hegde (2):
  powerpc/powernv/dump: Fix race while processing OPAL dump
  powerpc/powernv/dump: Handle multiple writes to ack attribute


 arch/powerpc/include/asm/asm-const.h  |  13 +++
 arch/powerpc/include/asm/cputable.h   |   2 +-
 arch/powerpc/include/asm/uaccess.h|   4 +-
 arch/powerpc/kernel/cputable.c|  13 ++-
 arch/powerpc/kernel/eeh.c |   5 -
 arch/powerpc/kernel/mce.c |   7 +-
 arch/powerpc/kernel/smp.c |  70 
++--
 arch/powerpc/kernel/traps.c   |   2 +-
 arch/powerpc/platforms/powernv/opal-dump.c|  52 ++---
 arch/powerpc/platforms/powernv/opal-elog.c|  11 +-
 arch/powerpc/platforms/pseries/ras.c  | 118 

 tools/testing/selftests/powerpc/alignment/alignment_handler.c |   8 +-
 12 files changed, 185 insertions(+), 120 deletions(-)
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl+UBeUACgkQUevqPMjh
pYBHUA//THLt6DJlSPPqn8LQZQGT76Gx82cKyy9DQ7/Elcl13xcuq3XbhHD5asi0
QbJGbLhRqpRhtmj3c8BCYAygi5FXZWH4IeN6FK8xoZGR2bi/gY7VkhIUSzFAHnRi
PFXafzb8eWVS7O5k8xbxrjxdOAu8SjEzywG5I8PPn5IWFwhUwjGosv81QtxJOLVc
V9WwuTBK87nfvoMdfcl3YJXRs+4vKOQQ0Gqa5vTVTUmgdbJOqJi1MvLULnSnKxTJ
G+XplOeSI1N3gk+E2cycPasghTYziTtzEyrTHe0Uufgx+9t6VuN1g2zL81kDA7U9
10Oqqry4Z66V2BhGrDMnXKYGeQNGRO8vNLT2DuuZd5XTN/LpV0knJHm/9F2E+5zl
T+GgQwS0IhXDcbS70TcbxXHPyBe2/eXRH1+rkSlAEjl656JVbKefgi1VUsqSzkjH
JBF2+zCodYelbbnRP89Aj5/03t+VeHbNC/1jixoYDHR7drXiU2XQqjfFZeCHvxOQ
YCznpoC84gcDupGC5q4op3tHBmvULJn0KaHYWryaAEWlCxjdVcjBis48B+GQVww8
JnDMC5WGVvAAxPHc74EkyEvdROx4Q+8UeOj+TXnrRlowEF8Wymxcvy7NUn2Bqq2J
VsRCUzLIReKCckdJQ/+SxG8eb9JUxQRWG76+Q9zzTHbdaBSWuMc=
=9Oxg
-END PGP SIGNATURE-

[PATCH v7 2/3] Input: Add Novatek NT36xxx touchscreen driver

From: AngeloGioacchino Del Regno 

This is a driver for the Novatek in-cell touch controller and
supports various chips from the NT36xxx family, currently
including NT36525, NT36672A, NT36676F, NT36772 and NT36870.

Functionality like wake gestures and firmware flashing is not
included: I am not aware of any of these DrIC+Touch combo
chips not including a non-volatile memory and it should be
highly unlikely to find one, since the touch firmware is
embedded into the DriverIC one, which is obviously necessary
to drive the display unit.

However, the necessary address for the firmware update
procedure was included into the address table in this driver
so, in the event that someone finds the need to implement it
for a reason or another, it will be pretty straightforward to.

This driver is lightly based on the downstream implementation [1].
[1] https://github.com/Rasenkai/caf-tsoft-Novatek-nt36xxx

Signed-off-by: AngeloGioacchino Del Regno 
---
 drivers/input/touchscreen/Kconfig   |  12 +
 drivers/input/touchscreen/Makefile  |   1 +
 drivers/input/touchscreen/nt36xxx.c | 895 
 3 files changed, 908 insertions(+)
 create mode 100644 drivers/input/touchscreen/nt36xxx.c

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 35c867b2d9a7..6d118b967021 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -605,6 +605,18 @@ config TOUCHSCREEN_MTOUCH
  To compile this driver as a module, choose M here: the
  module will be called mtouch.
 
+config TOUCHSCREEN_NT36XXX
+   tristate "Novatek NT36XXX In-Cell I2C touchscreen controller"
+   depends on I2C
+   help
+ Say Y here if you have a Novatek NT36xxx series In-Cell
+ touchscreen connected to your system over I2C.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called nt36xxx.
+
 config TOUCHSCREEN_IMX6UL_TSC
tristate "Freescale i.MX6UL touchscreen controller"
depends on (OF && GPIOLIB) || COMPILE_TEST
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 30d1e1b42492..424a555e03d5 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_TOUCHSCREEN_MIGOR)   += migor_ts.o
 obj-$(CONFIG_TOUCHSCREEN_MMS114)   += mms114.o
 obj-$(CONFIG_TOUCHSCREEN_MTOUCH)   += mtouch.o
 obj-$(CONFIG_TOUCHSCREEN_MK712)+= mk712.o
+obj-$(CONFIG_TOUCHSCREEN_NT36XXX)  += nt36xxx.o
 obj-$(CONFIG_TOUCHSCREEN_HP600)+= hp680_ts_input.o
 obj-$(CONFIG_TOUCHSCREEN_HP7XX)+= jornada720_ts.o
 obj-$(CONFIG_TOUCHSCREEN_IPAQ_MICRO)   += ipaq-micro-ts.o
diff --git a/drivers/input/touchscreen/nt36xxx.c 
b/drivers/input/touchscreen/nt36xxx.c
new file mode 100644
index ..cd37b1ab1cf5
--- /dev/null
+++ b/drivers/input/touchscreen/nt36xxx.c
@@ -0,0 +1,895 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for Novatek NT36xxx series touchscreens
+ *
+ * Copyright (C) 2010 - 2017 Novatek, Inc.
+ * Copyright (C) 2020 AngeloGioacchino Del Regno 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* FW Param address */
+#define NT36XXX_FW_ADDR 0x01
+
+/* Number of bytes for chip identification */
+#define NT36XXX_ID_LEN_MAX 6
+
+/* Touch info */
+#define TOUCH_DEFAULT_MAX_WIDTH  1080
+#define TOUCH_DEFAULT_MAX_HEIGHT 2246
+#define TOUCH_MAX_FINGER_NUM10
+#define TOUCH_MAX_PRESSURE  1000
+
+/* Point data length */
+#define POINT_DATA_LEN 65
+
+/* Global pages */
+#define NT36XXX_PAGE_CHIP_INFO 0x0001f64e
+#define NT36XXX_PAGE_CRC   0x0003f135
+
+/* Misc */
+#define NT36XXX_NUM_SUPPLIES2
+#define NT36XXX_MAX_RETRIES 5
+#define NT36XXX_MAX_FW_RST_RETRY 50
+
+struct nt36xxx_abs_object {
+   u16 x;
+   u16 y;
+   u16 z;
+   u8 tm;
+};
+
+struct nt36xxx_fw_info {
+   u8 fw_ver;
+   u8 x_num;
+   u8 y_num;
+   u8 max_buttons;
+   u16 abs_x_max;
+   u16 abs_y_max;
+   u16 nvt_pid;
+};
+
+struct nt36xxx_mem_map {
+   u32 evtbuf_addr;
+   u32 pipe0_addr;
+   u32 pipe1_addr;
+   u32 flash_csum_addr;
+   u32 flash_data_addr;
+};
+
+struct nt36xxx_i2c {
+   struct i2c_client *hw_client;
+   struct i2c_client *fw_client;
+   struct regmap *regmap;
+   struct regmap *fw_regmap;
+   struct input_dev *input;
+   struct regulator_bulk_data *supplies;
+   struct gpio_desc *reset_gpio;
+
+   struct mutex lock;
+
+   struct touchscreen_properties prop;
+   struct nt36xxx_fw_info fw_info;
+   struct nt36xxx_abs_object abs_obj;
+
+   const struct nt36xxx_mem_map *mmap;
+};
+
+enum nt36xxx_chips {
+   NT36525_IC = 0,
+   NT36672A_IC,
+   NT36676F_IC,
+   NT36772_IC,
+

[PATCH v7 0/3] Add Novatek NT36xxx touchscreen driver

From: AngeloGioacchino Del Regno 

This patch series adds support for the Novatek NT36xxx Series' In-Cell
touchscreen (integrated into the DriverIC).

This patch series has been tested against the following devices:
 - Sony Xperia 10(SDM630 Ganges Kirin)
 - Sony Xperia 10 Plus   (SDM636 Ganges Mermaid)

Changes in v2:
- Fixed sparse warnings from lkp kernel test robot

Changes in v3 (as requested by Dmitry Torokhov):
- Using shorthand u16/u32 (sorry for the overlook!)
- Now using more input and touchscreen APIs
- Fixed useless workqueue involvements
- Removed useless locking
- Switched reads and writes to use regmap
- Moved header contents to nt36xxx.c
- Fixed reset gpio handling
- Other cleanups
- P.S.: Thanks, Dmitry!

Changes in v4:
- Fixed regmap read length for CRC_ERR_FLAG final check
- Fixed YAML binding, as requested by Krzysztof Kozlowski

Changes in v5:
- Replaced subsystem maintainer's name with .. mine,
  usage of additionalProperties to unevaluatedProperties
  and a typo fix for reset-gpios as per Rob Herring's review
- Changed compatible string as per Krzysztof K. request
- Renamed the novatek,nt36xxx.yaml file to just nt36xxx.yaml
  in order to now reflect the driver name instead of the DT
  compatible
- Fixed blank line at EOF

Changes in v6:
- Removed include of_gpio.h, added mod_devicetable.h and
  gpio/consumer.h
- Added kerneldoc to relevant functions/enum
- Used traditional patterns for error checking where possible
- Documented calls to usleep/msleep
- Using be16_to_cpu / get_unaligned_be16 where possible
- Added helper for CRC error check on retrieved buffer
- Decreased indentation in the CRC reboot recovery function
- Removed instances of error code sum
- Dropped all likely/unlikely optimization as per request
- Removed redundant reset_gpio checks
- Dropped of_match_ptr and ifdefs for CONFIG_OF

Changes in v7:
- Fixed typo in nt36xxx.c

AngeloGioacchino Del Regno (3):
  dt-bindings: Add vendor prefix for Novatek Microelectronics Corp.
  Input: Add Novatek NT36xxx touchscreen driver
  dt-bindings: touchscreen: Add binding for Novatek NT36xxx series
driver

 .../bindings/input/touchscreen/nt36xxx.yaml   |  59 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 drivers/input/touchscreen/Kconfig |  12 +
 drivers/input/touchscreen/Makefile|   1 +
 drivers/input/touchscreen/nt36xxx.c   | 895 ++
 5 files changed, 969 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/nt36xxx.yaml
 create mode 100644 drivers/input/touchscreen/nt36xxx.c

-- 
2.28.0

[PATCH v7 1/3] dt-bindings: Add vendor prefix for Novatek Microelectronics Corp.

From: AngeloGioacchino Del Regno 

Add prefix for Novatek Microelectronics Corp.

Signed-off-by: AngeloGioacchino Del Regno 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 66e45112a8d7..f98ea0af487d 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -740,6 +740,8 @@ patternProperties:
 description: Nokia
   "^nordic,.*":
 description: Nordic Semiconductor
+  "^novatek,.*":
+description: Novatek Microelectronics Corp.
   "^novtech,.*":
 description: NovTech, Inc.
   "^nutsboard,.*":
-- 
2.28.0

[PATCH v7 3/3] dt-bindings: touchscreen: Add binding for Novatek NT36xxx series driver

From: AngeloGioacchino Del Regno 

Add binding for the Novatek NT36xxx series touchscreen driver.

Signed-off-by: AngeloGioacchino Del Regno 
---
 .../bindings/input/touchscreen/nt36xxx.yaml   | 59 +++
 1 file changed, 59 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/nt36xxx.yaml

diff --git a/Documentation/devicetree/bindings/input/touchscreen/nt36xxx.yaml 
b/Documentation/devicetree/bindings/input/touchscreen/nt36xxx.yaml
new file mode 100644
index ..1486b20d6c49
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/nt36xxx.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/nt36xxx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT36xxx series touchscreen controller Bindings
+
+maintainers:
+  - AngeloGioacchino Del Regno 
+
+allOf:
+  - $ref: touchscreen.yaml#
+
+properties:
+  compatible:
+const: novatek,nt36525
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  reset-gpios:
+maxItems: 1
+
+  vdd-supply:
+description: Power supply regulator for VDD pin
+
+  vio-supply:
+description: Power supply regulator on VDD-IO pin
+
+unevaluatedProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+examples:
+  - |
+#include 
+#include 
+
+i2c {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  touchscreen@62 {
+compatible = "novatek,nt36525";
+reg = <0x62>;
+interrupt-parent = <>;
+interrupts = <45 IRQ_TYPE_EDGE_RISING>;
+reset-gpio = < 102 GPIO_ACTIVE_HIGH>;
+  };
+};
+
+...
-- 
2.28.0

Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

2020-10-24 Thread Topi Miettinen


On 23.10.2020 12.02, Catalin Marinas wrote:

On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:

Regardless, it makes sense to me to have the kernel load the executable
itself with BTI enabled by default. I prefer gaining Catalin's suggested
patch[2]. :)

[...]

[2] https://lore.kernel.org/linux-arm-kernel/20201022093104.GB1229@gaia/


I think I first heard the idea at Mark R ;).

It still needs glibc changes to avoid the mprotect(), or at least ignore
the error. Since this is an ABI change and we don't know which kernels
would have it backported, maybe better to still issue the mprotect() but
ignore the failure.


What about kernel adding an auxiliary vector as a flag to indicate that 
BTI is supported and recommended by the kernel? Then dynamic loader 
could use that to detect that a) the main executable is BTI protected 
and there's no need to mprotect() it and b) PROT_BTI flag should be 
added to all PROT_EXEC pages.


In absence of the vector, the dynamic loader might choose to skip doing 
PROT_BTI at all (since the main executable isn't protected anyway 
either, or maybe even the kernel is up-to-date but it knows that it's 
not recommended for some reason, or maybe the kernel is so ancient that 
it doesn't know about BTI). Optionally it could still read the flag from 
ELF later (for compatibility with old kernels) and then do the 
mprotect() dance, which may trip seccomp filters, possibly fatally.


-Topi

Re: [PATCH v8 -tip 02/26] sched: Introduce sched_class::pick_task()

2020-10-24 Thread Vineeth Pillai


Hi Aubrey,


On 10/23/20 10:48 PM, Li, Aubrey wrote:



2. Do you see the issue in v7? Not much if at all has changed in this
part of the code from v7 -> v8 but could be something in the newer
kernel.


IIRC, I can run uperf successfully on v7.
I'm on tip/master 2d3e8c9424c9 (origin/master) "Merge branch 'linus'."
Please let me know if this is a problem, or you have a repo I can pull
for testing.

Here is a repo with v8 series on top of v5.9 release:
https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/log/?h=coresched-v5.9

I didn't see NULL pointer dereference BUG of this repo, will post performance
data later.

There has been a change in tip in pick_next_entity which caused
removal of a coresched related change to fix the crash. Could
you please try this patch on top of the posted v8 and see if this
works?

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 93a3b874077d..4cae5ac48b60 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4428,12 +4428,14 @@ pick_next_entity(struct cfs_rq *cfs_rq, struct 
sched_entity *curr)
    se = second;
    }

-   if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) < 1) {
+   if (left && cfs_rq->next &&
+   wakeup_preempt_entity(cfs_rq->next, left) < 1) {
    /*
 * Someone really wants this to run. If it's not unfair, run it.
 */
    se = cfs_rq->next;
-   } else if (cfs_rq->last && wakeup_preempt_entity(cfs_rq->last, left) < 
1) {
+   } else if (left && cfs_rq->last &&
+   wakeup_preempt_entity(cfs_rq->last, left) < 1) {
    /*
 * Prefer last buddy, try to return the CPU to a preempted task.


There reason for left being NULL needs to be investigated. This was
there from v1 and we did not yet get to it. I shall try to debug later
this week.

Kindly test this patch and let us know if it fixes the crash.

Thanks,
Vineeth

[PATCH v5] net: macb: add support for high speed interface

2020-10-24 Thread Parshuram Thombare

This patch adds support for 10GBASE-R interface to the linux driver for
Cadence's ethernet controller.
This controller has separate MAC's and PCS'es for low and high speed paths.
High speed PCS supports 100M, 1G, 2.5G, 5G and 10G through rate adaptation
implementation. However, since it doesn't support auto negotiation, linux
driver is modified to support 10GBASE-R instead of USXGMII. 

Signed-off-by: Parshuram Thombare 
---
Changes between v4 and v5:
1. Correctly programming MAC bits mac_config.

Changes between v3 and v4:
1. Adapted new phylink pcs_ops for low speed PCS.
2. Moved high speed MAC configuration from pcs_config
   to mac_config.

Changes between v2 and v3:
1. Replace USXGMII interface by 10GBASE-R interface.
2. Adapted new phylink pcs_ops for high speed PCS.
3. Added pcs_get_state for high speed PCS.

---
 drivers/net/ethernet/cadence/macb.h  |  44 +++
 drivers/net/ethernet/cadence/macb_main.c | 128 +--
 2 files changed, 166 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index 5de47f6..1f5da4e 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -77,10 +77,12 @@
 #define MACB_RBQPH 0x04D4
 
 /* GEM register offsets. */
+#define GEM_NCR0x /* Network Control */
 #define GEM_NCFGR  0x0004 /* Network Config */
 #define GEM_USRIO  0x000c /* User IO */
 #define GEM_DMACFG 0x0010 /* DMA Configuration */
 #define GEM_JML0x0048 /* Jumbo Max Length */
+#define GEM_HS_MAC_CONFIG  0x0050 /* GEM high speed config */
 #define GEM_HRB0x0080 /* Hash Bottom */
 #define GEM_HRT0x0084 /* Hash Top */
 #define GEM_SA1B   0x0088 /* Specific1 Bottom */
@@ -166,6 +168,9 @@
 #define GEM_DCFG7  0x0298 /* Design Config 7 */
 #define GEM_DCFG8  0x029C /* Design Config 8 */
 #define GEM_DCFG10 0x02A4 /* Design Config 10 */
+#define GEM_DCFG12 0x02AC /* Design Config 12 */
+#define GEM_USX_CONTROL0x0A80 /* High speed PCS control 
register */
+#define GEM_USX_STATUS 0x0A88 /* High speed PCS status register */
 
 #define GEM_TXBDCTRL   0x04cc /* TX Buffer Descriptor control register */
 #define GEM_RXBDCTRL   0x04d0 /* RX Buffer Descriptor control register */
@@ -272,11 +277,19 @@
 #define MACB_IRXFCS_OFFSET 19
 #define MACB_IRXFCS_SIZE   1
 
+/* GEM specific NCR bitfields. */
+#define GEM_ENABLE_HS_MAC_OFFSET   31
+#define GEM_ENABLE_HS_MAC_SIZE 1
+
 /* GEM specific NCFGR bitfields. */
+#define GEM_FD_OFFSET  1 /* Full duplex */
+#define GEM_FD_SIZE1
 #define GEM_GBE_OFFSET 10 /* Gigabit mode enable */
 #define GEM_GBE_SIZE   1
 #define GEM_PCSSEL_OFFSET  11
 #define GEM_PCSSEL_SIZE1
+#define GEM_PAE_OFFSET 13 /* Pause enable */
+#define GEM_PAE_SIZE   1
 #define GEM_CLK_OFFSET 18 /* MDC clock division */
 #define GEM_CLK_SIZE   3
 #define GEM_DBW_OFFSET 21 /* Data bus width */
@@ -461,11 +474,17 @@
 #define MACB_REV_OFFSET0
 #define MACB_REV_SIZE  16
 
+/* Bitfield in HS_MAC_CONFIG */
+#define GEM_HS_MAC_SPEED_OFFSET0
+#define GEM_HS_MAC_SPEED_SIZE  3
+
 /* Bitfields in DCFG1. */
 #define GEM_IRQCOR_OFFSET  23
 #define GEM_IRQCOR_SIZE1
 #define GEM_DBWDEF_OFFSET  25
 #define GEM_DBWDEF_SIZE3
+#define GEM_NO_PCS_OFFSET  0
+#define GEM_NO_PCS_SIZE1
 
 /* Bitfields in DCFG2. */
 #define GEM_RX_PKT_BUFF_OFFSET 20
@@ -500,6 +519,28 @@
 #define GEM_RXBD_RDBUFF_OFFSET 8
 #define GEM_RXBD_RDBUFF_SIZE   4
 
+/* Bitfields in DCFG12. */
+#define GEM_HIGH_SPEED_OFFSET  26
+#define GEM_HIGH_SPEED_SIZE1
+
+/* Bitfields in USX_CONTROL. */
+#define GEM_USX_CTRL_SPEED_OFFSET  14
+#define GEM_USX_CTRL_SPEED_SIZE3
+#define GEM_SERDES_RATE_OFFSET 12
+#define GEM_SERDES_RATE_SIZE   2
+#define GEM_RX_SCR_BYPASS_OFFSET   9
+#define GEM_RX_SCR_BYPASS_SIZE 1
+#define GEM_TX_SCR_BYPASS_OFFSET   8
+#define GEM_TX_SCR_BYPASS_SIZE 1
+#define GEM_TX_EN_OFFSET   1
+#define GEM_TX_EN_SIZE 1
+#define GEM_SIGNAL_OK_OFFSET   0
+#define GEM_SIGNAL_OK_SIZE 1
+
+/* Bitfields in USX_STATUS. */
+#define GEM_USX_BLOCK_LOCK_OFFSET  0
+#define GEM_USX_BLOCK_LOCK_SIZE1
+
 /* Bitfields in TISUBN */

Re: [PATCH v39 15/24] x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION

2020-10-24 Thread Jarkko Sakkinen

On Fri, Oct 23, 2020 at 07:19:05AM -0700, Dave Hansen wrote:
> On 10/23/20 3:17 AM, Jarkko Sakkinen wrote:
> > On Tue, Oct 20, 2020 at 02:19:26PM -0700, Dave Hansen wrote:
> >> On 10/2/20 9:50 PM, Jarkko Sakkinen wrote:
> >>> + * Failure to explicitly request access to a restricted attribute will 
> >>> cause
> >>> + * sgx_ioc_enclave_init() to fail.  Currently, the only restricted 
> >>> attribute
> >>> + * is access to the PROVISION_KEY.
> >> Could we also justify why access is restricted, please?  Maybe:
> >>
> >>Access is restricted because PROVISION_KEY is burned uniquely
> >>into each each processor, making it a perfect unique identifier
> >>with privacy and fingerprinting implications.
> >>
> >> Are there any other reasons for doing it this way?
> > AFAIK, if I interperet the SDM correctl, PROVISION_KEY and
> > PROVISION_SEALING_KEY also have random salt added, i.e. they change
> > every boot cycle.
> > 
> > There is "RAND = yes" on those keys in Table 40-64 of Intel SDM volume
> > 3D :-)
> 
> Does that mean there are no privacy implications from access to the
> provisioning keys?  If that's true, why do we need a separate permission
> framework for creating provisioning enclaves?

As I've understood it, the key material for those keys is not even
required in the current SGX architecture, it was used in the legacy EPID
scheme, but the attribute itself is useful.

Let's assume that we have some sort of quoting enclave Q, which guards a
public key pair, which signs quotes of other enclaves. Let's assume we
have an attestation server A, which will enable some capabilities [*],
if it receives a quote signed with that public key pair.

1. E gets the report key with EGETKEY.
2. E constructs REPORTDATA (37.16) and TARGETINFO (37.17) structures.
   The former describes the enclaves contents and attributes and latter
   the target, i.e. Q in this artitificial example.
3. E calls EREPORT to generate a structure called REPORT MAC'd with the
   *targets* report key. It knows, which key to usue from REPORTDATA.
4. The runtime will then pass this to Q.
5. Q will check if ATTRIBUTE.PROVISION_KEY is set. If it is, Q will
   know that the enclave is allowed to get attested. Then it will
   sign the report with the guarded public key pair and send it to
   the attestation server.

The example is artificial, e.g. there could be something more complex,
but the idea is essentially this.

[*] With TPM and measured boot this could be to open network for a data
center node. Quote is just the term used for a signed measurement in
remote attestation schemes generally.

/Jarkko

Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

2020-10-24 Thread Topi Miettinen


On 23.10.2020 20.52, Salvatore Mesoraca wrote:

Hi,

On Thu, 22 Oct 2020 at 23:24, Topi Miettinen  wrote:

SARA looks interesting. What is missing is a prctl() to enable all W^X
protections irrevocably for the current process, then systemd could
enable it for services with MemoryDenyWriteExecute=yes.


SARA actually has a procattr[0] interface to do just that.
There is also a library[1] to help using it.


That means that /proc has to be available and writable at that point, so 
setting up procattrs has to be done before mount namespaces are set up. 
In general, it would be nice for sandboxing facilities in kernel if 
there would be a way to start enforcing restrictions only at next 
execve(), like setexeccon() for SELinux and aa_change_onexec() for 
AppArmor. Otherwise the exact order of setting up various sandboxing 
options can be very tricky to arrange correctly, since each option may 
have a subtle effect to the sandboxing features enabled later. In case 
of SARA, the operations done between shuffling the mount namespace and 
before execve() shouldn't be affected so it isn't important. Even if it 
did (a new sandboxing feature in the future would need trampolines or 
JIT code generation), maybe the procattr file could be opened early but 
it could be written closer to execve().


-Topi

Re: [PATCH v39 15/24] x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION

2020-10-24 Thread Jarkko Sakkinen

On Fri, Oct 23, 2020 at 04:23:55PM +0200, Jethro Beekman wrote:
> On 2020-10-23 12:17, Jarkko Sakkinen wrote:
> > On Tue, Oct 20, 2020 at 02:19:26PM -0700, Dave Hansen wrote:
> >> On 10/2/20 9:50 PM, Jarkko Sakkinen wrote:
> >>> + * Failure to explicitly request access to a restricted attribute will 
> >>> cause
> >>> + * sgx_ioc_enclave_init() to fail.  Currently, the only restricted 
> >>> attribute
> >>> + * is access to the PROVISION_KEY.
> >>
> >> Could we also justify why access is restricted, please?  Maybe:
> >>
> >>Access is restricted because PROVISION_KEY is burned uniquely
> >>into each each processor, making it a perfect unique identifier
> >>with privacy and fingerprinting implications.
> >>
> >> Are there any other reasons for doing it this way?
> > 
> > AFAIK, if I interperet the SDM correctl, PROVISION_KEY and
> > PROVISION_SEALING_KEY also have random salt added, i.e. they change
> > every boot cycle.
> > 
> > There is "RAND = yes" on those keys in Table 40-64 of Intel SDM volume
> > 3D :-)
> > 
> 
> This is nonsense. The whole point of sealing keys is that they don't
> change every boot. If did they they'd have no value over enclave
> memory. RAND means that the KEYID field from the KEYREQUEST is
> included in the derivation (as noted in the source row of the table
> you looked at).

I just looked that the column name is RAND, the row is called "Provision
key" and the cell has "Yes" in it.

> --
> Jethro Beekman | Fortanix

/Jarkko

Re: [BUG] Error applying setting, reverse things back on lot of devices

2020-10-24 Thread Michał Miosław

On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote:
> On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote:
> > On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote:
> > > Hello
> > > 
> > > On next-20201016, booting my sun8i-r40-bananapi-m2-ultra, the boot end 
> > > without at least stmmac working.
> > > [0.00] Booting Linux on physical CPU 0x0
> > > [0.00] Linux version 
> > > 5.9.0-next-20201016-00055-g98489213ff7c-dirty (compile@Red) 
> > > (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 9.3.0-r1 p3) 9.3.0, GNU ld 
> > > (Gentoo 2.33.1 p2) 2.33.1) #162 SMP Tue Oct 20 08:10:25 CEST 2020
> > > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), 
> > > cr=10c5387d
> > > [0.00] CPU: div instructions available: patching division code
> > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> > > instruction cache
> > > [0.00] OF: fdt: Machine model: Banana Pi BPI-M2-Ultra
> > > [0.00] Memory policy: Data cache writealloc
> > > [0.00] cma: Reserved 16 MiB at 0xbec0
> > > [0.00] Zone ranges:
> > > [0.00]   Normal   [mem 0x4000-0x6fff]
> > > [0.00]   HighMem  [mem 0x7000-0xbfff]
> > > [0.00] Movable zone start for each node
> > > [0.00] Early memory node ranges
> > > [0.00]   node   0: [mem 0x4000-0xbfff]
> > > [0.00] Initmem setup node 0 [mem 
> > > 0x4000-0xbfff]
> > > [0.00] psci: probing for conduit method from DT.
> > > [0.00] psci: Using PSCI v0.1 Function IDs from DT
> > > [0.00] percpu: Embedded 15 pages/cpu s30924 r8192 d22324 u61440
> > > [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 
> > > 522752
> > > [0.00] Kernel command line: console=ttyS0,115200n8 root=/dev/ram0 
> > > ip=dhcp trace_event=initcall:*,module:* trace_options=stacktrace ip=dhcp
> > > [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
> > > bytes, linear)
> > > [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 
> > > bytes, linear)
> > > [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
> > > [0.00] Memory: 2020320K/2097152K available (7168K kernel code, 
> > > 934K rwdata, 2252K rodata, 1024K init, 248K bss, 60448K reserved, 16384K 
> > > cma-reserved, 1294324K highmem)
> > > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> > > [0.00] rcu: Hierarchical RCU implementation.
> > > [0.00] rcu:   RCU event tracing is enabled.
> > > [0.00] rcu:   RCU restricting CPUs from NR_CPUS=8 to 
> > > nr_cpu_ids=4.
> > > [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 
> > > 10 jiffies.
> > > [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, 
> > > nr_cpu_ids=4
> > > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> > > [0.00] GIC: Using split EOI/Deactivate mode
> > > [0.00] random: get_random_bytes called from 
> > > start_kernel+0x320/0x4ac with crng_init=0
> > > [0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
> > > [0.00] clocksource: arch_sys_counter: mask: 0xff 
> > > max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
> > > [0.07] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps 
> > > every 4398046511097ns
> > > [0.20] Switching to timer-based delay loop, resolution 41ns
> > > [0.000176] Console: colour dummy device 80x30
> > > [0.000230] Calibrating delay loop (skipped), value calculated using 
> > > timer frequency.. 48.00 BogoMIPS (lpj=24)
> > > [0.000251] pid_max: default: 32768 minimum: 301
> > > [0.000395] Mount-cache hash table entries: 2048 (order: 1, 8192 
> > > bytes, linear)
> > > [0.000414] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 
> > > bytes, linear)
> > > [0.001117] CPU: Testing write buffer coherency: ok
> > > [0.001420] /cpus/cpu@0 missing clock-frequency property
> > > [0.001442] /cpus/cpu@1 missing clock-frequency property
> > > [0.001459] /cpus/cpu@2 missing clock-frequency property
> > > [0.001477] /cpus/cpu@3 missing clock-frequency property
> > > [0.001490] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
> > > [0.002001] Setting up static identity map for 0x4010 - 0x40100060
> > > [0.002119] rcu: Hierarchical SRCU implementation.
> > > [0.002580] smp: Bringing up secondary CPUs ...
> > > [0.013271] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
> > > [0.024063] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
> > > [0.034784] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
> > > [0.034880] smp: Brought up 1 node, 4 CPUs
> > > [0.034904] SMP: Total of 4 processors activated (192.00 BogoMIPS).
> > > [0.034912] CPU: All CPU(s)

[PATCH v1] mm/migrate: fix comment spelling

2020-10-24 Thread Long Li

The word in the comment is misspelled, it should be "include".

Signed-off-by: Long Li 
---
 mm/migrate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index 5ca5842df5db..d79640ab8aa1 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1694,7 +1694,7 @@ static int move_pages_and_store_status(struct mm_struct 
*mm, int node,
 * Positive err means the number of failed
 * pages to migrate.  Since we are going to
 * abort and return the number of non-migrated
-* pages, so need to incude the rest of the
+* pages, so need to include the rest of the
 * nr_pages that have not been attempted as
 * well.
 */
-- 
2.17.1

Re: [PATCH v5] checkpatch: fix false positives in REPEATED_WORD warning

2020-10-24 Thread Joe Perches

On Sat, 2020-10-24 at 15:52 +0530, Aditya Srivastava wrote:
> Presence of hexadecimal address or symbol results in false warning
> message by checkpatch.pl.

Thanks Aditya, this looks OK to me.
Andrew can you please pick up this patch on top of Dwaipayan's?

1: https://lore.kernel.org/lkml/20201017162732.152351-1-dwaipayanr...@gmail.com/
2: https://lore.kernel.org/lkml/20201024102253.13614-1-yashsri...@gmail.com/

Re: [BUG] Error applying setting, reverse things back on lot of devices

On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote:
> On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote:
> > On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote:
> > > Hello
> > > 
> > > On next-20201016, booting my sun8i-r40-bananapi-m2-ultra, the boot end 
> > > without at least stmmac working.
> > > [0.00] Booting Linux on physical CPU 0x0
> > > [0.00] Linux version 
> > > 5.9.0-next-20201016-00055-g98489213ff7c-dirty (compile@Red) 
> > > (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 9.3.0-r1 p3) 9.3.0, GNU ld 
> > > (Gentoo 2.33.1 p2) 2.33.1) #162 SMP Tue Oct 20 08:10:25 CEST 2020
> > > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), 
> > > cr=10c5387d
> > > [0.00] CPU: div instructions available: patching division code
> > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> > > instruction cache
> > > [0.00] OF: fdt: Machine model: Banana Pi BPI-M2-Ultra
> > > [0.00] Memory policy: Data cache writealloc
> > > [0.00] cma: Reserved 16 MiB at 0xbec0
> > > [0.00] Zone ranges:
> > > [0.00]   Normal   [mem 0x4000-0x6fff]
> > > [0.00]   HighMem  [mem 0x7000-0xbfff]
> > > [0.00] Movable zone start for each node
> > > [0.00] Early memory node ranges
> > > [0.00]   node   0: [mem 0x4000-0xbfff]
> > > [0.00] Initmem setup node 0 [mem 
> > > 0x4000-0xbfff]
> > > [0.00] psci: probing for conduit method from DT.
> > > [0.00] psci: Using PSCI v0.1 Function IDs from DT
> > > [0.00] percpu: Embedded 15 pages/cpu s30924 r8192 d22324 u61440
> > > [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 
> > > 522752
> > > [0.00] Kernel command line: console=ttyS0,115200n8 root=/dev/ram0 
> > > ip=dhcp trace_event=initcall:*,module:* trace_options=stacktrace ip=dhcp
> > > [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
> > > bytes, linear)
> > > [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 
> > > bytes, linear)
> > > [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
> > > [0.00] Memory: 2020320K/2097152K available (7168K kernel code, 
> > > 934K rwdata, 2252K rodata, 1024K init, 248K bss, 60448K reserved, 16384K 
> > > cma-reserved, 1294324K highmem)
> > > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> > > [0.00] rcu: Hierarchical RCU implementation.
> > > [0.00] rcu:   RCU event tracing is enabled.
> > > [0.00] rcu:   RCU restricting CPUs from NR_CPUS=8 to 
> > > nr_cpu_ids=4.
> > > [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 
> > > 10 jiffies.
> > > [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, 
> > > nr_cpu_ids=4
> > > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> > > [0.00] GIC: Using split EOI/Deactivate mode
> > > [0.00] random: get_random_bytes called from 
> > > start_kernel+0x320/0x4ac with crng_init=0
> > > [0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
> > > [0.00] clocksource: arch_sys_counter: mask: 0xff 
> > > max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
> > > [0.07] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps 
> > > every 4398046511097ns
> > > [0.20] Switching to timer-based delay loop, resolution 41ns
> > > [0.000176] Console: colour dummy device 80x30
> > > [0.000230] Calibrating delay loop (skipped), value calculated using 
> > > timer frequency.. 48.00 BogoMIPS (lpj=24)
> > > [0.000251] pid_max: default: 32768 minimum: 301
> > > [0.000395] Mount-cache hash table entries: 2048 (order: 1, 8192 
> > > bytes, linear)
> > > [0.000414] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 
> > > bytes, linear)
> > > [0.001117] CPU: Testing write buffer coherency: ok
> > > [0.001420] /cpus/cpu@0 missing clock-frequency property
> > > [0.001442] /cpus/cpu@1 missing clock-frequency property
> > > [0.001459] /cpus/cpu@2 missing clock-frequency property
> > > [0.001477] /cpus/cpu@3 missing clock-frequency property
> > > [0.001490] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
> > > [0.002001] Setting up static identity map for 0x4010 - 0x40100060
> > > [0.002119] rcu: Hierarchical SRCU implementation.
> > > [0.002580] smp: Bringing up secondary CPUs ...
> > > [0.013271] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
> > > [0.024063] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
> > > [0.034784] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
> > > [0.034880] smp: Brought up 1 node, 4 CPUs
> > > [0.034904] SMP: Total of 4 processors activated (192.00 BogoMIPS).
> > > [0.034912] CPU: All CPU(s)

[RFC net-next 2/5] net: phy: add a shutdown procedure

In case of a board which uses a shared IRQ we can easily end up with an
IRQ storm after a forced reboot.

For example, a 'reboot -f' will trigger a call to the .shutdown()
callbacks of all devices. Because phylib does not implement that hook,
the PHY is not quiesced, thus it can very well leave its IRQ enabled.

At the next boot, if that IRQ line is found asserted by the first PHY
driver that uses it, but _before_ the driver that is _actually_ keeping
the shared IRQ asserted is probed, the IRQ is not going to be
acknowledged, thus it will keep being fired preventing the boot process
of the kernel to continue. This is even worse when the second PHY driver
is a module.

To fix this, implement the .shutdown() callback and disable the
interrupts if these are used.

Note that we are still susceptible to IRQ storms if the previous kernel
exited with a panic or if the bootloader left the shared IRQ active, but
there is absolutely nothing we can do about these cases.

Cc: Alexandru Ardelean 
Cc: Andre Edich 
Cc: Antoine Tenart 
Cc: Baruch Siach 
Cc: Christophe Leroy 
Cc: Dan Murphy 
Cc: Divya Koppera 
Cc: Florian Fainelli 
Cc: Hauke Mehrtens 
Cc: Heiner Kallweit 
Cc: Jerome Brunet 
Cc: Kavya Sree Kotagiri 
Cc: Linus Walleij 
Cc: Marco Felsch 
Cc: Marek Vasut 
Cc: Martin Blumenstingl 
Cc: Mathias Kresin 
Cc: Maxim Kochetkov 
Cc: Michael Walle 
Cc: Neil Armstrong 
Cc: Nisar Sayed 
Cc: Oleksij Rempel 
Cc: Philippe Schenker 
Cc: Willy Liu 
Cc: Yuiko Oshino 
Signed-off-by: Ioana Ciornei 
---
 drivers/net/phy/phy_device.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 5dab6be6fc38..413a0a2c5d51 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2947,6 +2947,13 @@ static int phy_remove(struct device *dev)
return 0;
 }
 
+static void phy_shutdown(struct device *dev)
+{
+   struct phy_device *phydev = to_phy_device(dev);
+
+   phy_disable_interrupts(phydev);
+}
+
 /**
  * phy_driver_register - register a phy_driver with the PHY layer
  * @new_driver: new phy_driver to register
@@ -2970,6 +2977,7 @@ int phy_driver_register(struct phy_driver *new_driver, 
struct module *owner)
new_driver->mdiodrv.driver.bus = _bus_type;
new_driver->mdiodrv.driver.probe = phy_probe;
new_driver->mdiodrv.driver.remove = phy_remove;
+   new_driver->mdiodrv.driver.shutdown = phy_shutdown;
new_driver->mdiodrv.driver.owner = owner;
new_driver->mdiodrv.driver.probe_type = PROBE_FORCE_SYNCHRONOUS;
 
-- 
2.28.0

[RFC net-next 1/5] net: phy: export phy_error and phy_trigger_machine

These functions are currently used by phy_interrupt() to either signal
an error condition or to trigger the link state machine. In an attempt
to actually support shared PHY IRQs, export these two functions so that
the actual PHY drivers can use them.

Cc: Alexandru Ardelean 
Cc: Andre Edich 
Cc: Antoine Tenart 
Cc: Baruch Siach 
Cc: Christophe Leroy 
Cc: Dan Murphy 
Cc: Divya Koppera 
Cc: Florian Fainelli 
Cc: Hauke Mehrtens 
Cc: Heiner Kallweit 
Cc: Jerome Brunet 
Cc: Kavya Sree Kotagiri 
Cc: Linus Walleij 
Cc: Marco Felsch 
Cc: Marek Vasut 
Cc: Martin Blumenstingl 
Cc: Mathias Kresin 
Cc: Maxim Kochetkov 
Cc: Michael Walle 
Cc: Neil Armstrong 
Cc: Nisar Sayed 
Cc: Oleksij Rempel 
Cc: Philippe Schenker 
Cc: Willy Liu 
Cc: Yuiko Oshino 
Signed-off-by: Ioana Ciornei 
---
 drivers/net/phy/phy.c | 6 --
 include/linux/phy.h   | 2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 35525a671400..477bdf2f94df 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -493,10 +493,11 @@ EXPORT_SYMBOL(phy_queue_state_machine);
  *
  * @phydev: the phy_device struct
  */
-static void phy_trigger_machine(struct phy_device *phydev)
+void phy_trigger_machine(struct phy_device *phydev)
 {
phy_queue_state_machine(phydev, 0);
 }
+EXPORT_SYMBOL(phy_trigger_machine);
 
 static void phy_abort_cable_test(struct phy_device *phydev)
 {
@@ -924,7 +925,7 @@ void phy_stop_machine(struct phy_device *phydev)
  * Must not be called from interrupt context, or while the
  * phydev->lock is held.
  */
-static void phy_error(struct phy_device *phydev)
+void phy_error(struct phy_device *phydev)
 {
WARN_ON(1);
 
@@ -934,6 +935,7 @@ static void phy_error(struct phy_device *phydev)
 
phy_trigger_machine(phydev);
 }
+EXPORT_SYMBOL(phy_error);
 
 /**
  * phy_disable_interrupts - Disable the PHY interrupts from the PHY side
diff --git a/include/linux/phy.h b/include/linux/phy.h
index eb3cb1a98b45..566b39f6cd64 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1570,8 +1570,10 @@ void phy_drivers_unregister(struct phy_driver *drv, int 
n);
 int phy_driver_register(struct phy_driver *new_driver, struct module *owner);
 int phy_drivers_register(struct phy_driver *new_driver, int n,
 struct module *owner);
+void phy_error(struct phy_device *phydev);
 void phy_state_machine(struct work_struct *work);
 void phy_queue_state_machine(struct phy_device *phydev, unsigned long jiffies);
+void phy_trigger_machine(struct phy_device *phydev);
 void phy_mac_interrupt(struct phy_device *phydev);
 void phy_start_machine(struct phy_device *phydev);
 void phy_stop_machine(struct phy_device *phydev);
-- 
2.28.0

[RFC net-next 4/5] net: phy: at803x: implement generic .handle_interrupt() callback

In an attempt to actually support shared IRQs in phylib, we now move the
responsibility of triggering the phylib state machine or just returning
IRQ_NONE, based on the IRQ status register, to the PHY driver. Having
3 different IRQ handling callbacks (.handle_interrupt(),
.did_interrupt() and .ack_interrupt() ) is confusing so let the PHY
driver implement directly an IRQ handler like any other device driver.
Make this driver follow the new convention.

Cc: Oleksij Rempel 
Cc: Michael Walle 
Signed-off-by: Ioana Ciornei 
---
 drivers/net/phy/at803x.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index ed601a7e46a0..106c6f53755f 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -628,6 +628,24 @@ static int at803x_config_intr(struct phy_device *phydev)
return err;
 }
 
+static irqreturn_t at803x_handle_interrupt(struct phy_device *phydev)
+{
+   int irq_status;
+
+   irq_status = phy_read(phydev, AT803X_INTR_STATUS);
+   if (irq_status < 0) {
+   phy_error(phydev);
+   return IRQ_NONE;
+   }
+
+   if (irq_status == 0)
+   return IRQ_NONE;
+
+   phy_trigger_machine(phydev);
+
+   return IRQ_HANDLED;
+}
+
 static void at803x_link_change_notify(struct phy_device *phydev)
 {
/*
@@ -1064,6 +1082,7 @@ static struct phy_driver at803x_driver[] = {
.read_status= at803x_read_status,
.ack_interrupt  = at803x_ack_interrupt,
.config_intr= at803x_config_intr,
+   .handle_interrupt   = at803x_handle_interrupt,
.get_tunable= at803x_get_tunable,
.set_tunable= at803x_set_tunable,
.cable_test_start   = at803x_cable_test_start,
@@ -1084,6 +1103,7 @@ static struct phy_driver at803x_driver[] = {
/* PHY_BASIC_FEATURES */
.ack_interrupt  = at803x_ack_interrupt,
.config_intr= at803x_config_intr,
+   .handle_interrupt   = at803x_handle_interrupt,
 }, {
/* Qualcomm Atheros AR8031/AR8033 */
PHY_ID_MATCH_EXACT(ATH8031_PHY_ID),
@@ -1102,6 +1122,7 @@ static struct phy_driver at803x_driver[] = {
.aneg_done  = at803x_aneg_done,
.ack_interrupt  = _ack_interrupt,
.config_intr= _config_intr,
+   .handle_interrupt   = at803x_handle_interrupt,
.get_tunable= at803x_get_tunable,
.set_tunable= at803x_set_tunable,
.cable_test_start   = at803x_cable_test_start,
@@ -1122,6 +1143,7 @@ static struct phy_driver at803x_driver[] = {
/* PHY_BASIC_FEATURES */
.ack_interrupt  = at803x_ack_interrupt,
.config_intr= at803x_config_intr,
+   .handle_interrupt   = at803x_handle_interrupt,
.cable_test_start   = at803x_cable_test_start,
.cable_test_get_status  = at803x_cable_test_get_status,
 }, {
@@ -1134,6 +1156,7 @@ static struct phy_driver at803x_driver[] = {
/* PHY_BASIC_FEATURES */
.ack_interrupt  = _ack_interrupt,
.config_intr= _config_intr,
+   .handle_interrupt   = at803x_handle_interrupt,
.cable_test_start   = at803x_cable_test_start,
.cable_test_get_status  = at803x_cable_test_get_status,
.read_status= at803x_read_status,
-- 
2.28.0

[RFC net-next 3/5] net: phy: make .ack_interrupt() optional

As a first step into making phylib and all PHY drivers to actually
have support for shared IRQs, make the .ack_interrupt() callback
optional.

After all drivers have been moved to implement the generic
interrupt handle, the phy_drv_supports_irq() check will be
changed again to only require the .handle_interrupts() callback.

Cc: Alexandru Ardelean 
Cc: Andre Edich 
Cc: Antoine Tenart 
Cc: Baruch Siach 
Cc: Christophe Leroy 
Cc: Dan Murphy 
Cc: Divya Koppera 
Cc: Florian Fainelli 
Cc: Hauke Mehrtens 
Cc: Heiner Kallweit 
Cc: Jerome Brunet 
Cc: Kavya Sree Kotagiri 
Cc: Linus Walleij 
Cc: Marco Felsch 
Cc: Marek Vasut 
Cc: Martin Blumenstingl 
Cc: Mathias Kresin 
Cc: Maxim Kochetkov 
Cc: Michael Walle 
Cc: Neil Armstrong 
Cc: Nisar Sayed 
Cc: Oleksij Rempel 
Cc: Philippe Schenker 
Cc: Willy Liu 
Cc: Yuiko Oshino 
Signed-off-by: Ioana Ciornei 
---
 drivers/net/phy/phy_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 413a0a2c5d51..f54f483d7fd6 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2815,7 +2815,7 @@ EXPORT_SYMBOL(phy_get_internal_delay);
 
 static bool phy_drv_supports_irq(struct phy_driver *phydrv)
 {
-   return phydrv->config_intr && phydrv->ack_interrupt;
+   return phydrv->config_intr && (phydrv->ack_interrupt || 
phydrv->handle_interrupt);
 }
 
 /**
-- 
2.28.0

[RFC net-next 5/5] net: phy: at803x: remove the use of .ack_interrupt()

In preparation of removing the .ack_interrupt() callback, we must replace
its occurrences (aka phy_clear_interrupt), from the 2 places where it is
called from (phy_enable_interrupts and phy_disable_interrupts), with
equivalent functionality.

This means that clearing interrupts now becomes something that the PHY
driver is responsible of doing, before enabling interrupts and after
clearing them. Make this driver follow the new contract.

Cc: Oleksij Rempel 
Cc: Michael Walle 
Signed-off-by: Ioana Ciornei 
---
 drivers/net/phy/at803x.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 106c6f53755f..aba198adf62d 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -614,6 +614,11 @@ static int at803x_config_intr(struct phy_device *phydev)
value = phy_read(phydev, AT803X_INTR_ENABLE);
 
if (phydev->interrupts == PHY_INTERRUPT_ENABLED) {
+   /* Clear any pending interrupts */
+   err = at803x_ack_interrupt(phydev);
+   if (err)
+   return err;
+
value |= AT803X_INTR_ENABLE_AUTONEG_ERR;
value |= AT803X_INTR_ENABLE_SPEED_CHANGED;
value |= AT803X_INTR_ENABLE_DUPLEX_CHANGED;
@@ -621,9 +626,14 @@ static int at803x_config_intr(struct phy_device *phydev)
value |= AT803X_INTR_ENABLE_LINK_SUCCESS;
 
err = phy_write(phydev, AT803X_INTR_ENABLE, value);
-   }
-   else
+   } else {
err = phy_write(phydev, AT803X_INTR_ENABLE, 0);
+   if (err)
+   return err;
+
+   /* Clear any pending interrupts */
+   err = at803x_ack_interrupt(phydev);
+   }
 
return err;
 }
@@ -1080,7 +1090,6 @@ static struct phy_driver at803x_driver[] = {
.resume = at803x_resume,
/* PHY_GBIT_FEATURES */
.read_status= at803x_read_status,
-   .ack_interrupt  = at803x_ack_interrupt,
.config_intr= at803x_config_intr,
.handle_interrupt   = at803x_handle_interrupt,
.get_tunable= at803x_get_tunable,
@@ -1101,7 +1110,6 @@ static struct phy_driver at803x_driver[] = {
.suspend= at803x_suspend,
.resume = at803x_resume,
/* PHY_BASIC_FEATURES */
-   .ack_interrupt  = at803x_ack_interrupt,
.config_intr= at803x_config_intr,
.handle_interrupt   = at803x_handle_interrupt,
 }, {
@@ -1120,7 +1128,6 @@ static struct phy_driver at803x_driver[] = {
/* PHY_GBIT_FEATURES */
.read_status= at803x_read_status,
.aneg_done  = at803x_aneg_done,
-   .ack_interrupt  = _ack_interrupt,
.config_intr= _config_intr,
.handle_interrupt   = at803x_handle_interrupt,
.get_tunable= at803x_get_tunable,
@@ -1141,7 +1148,6 @@ static struct phy_driver at803x_driver[] = {
.suspend= at803x_suspend,
.resume = at803x_resume,
/* PHY_BASIC_FEATURES */
-   .ack_interrupt  = at803x_ack_interrupt,
.config_intr= at803x_config_intr,
.handle_interrupt   = at803x_handle_interrupt,
.cable_test_start   = at803x_cable_test_start,
@@ -1154,7 +1160,6 @@ static struct phy_driver at803x_driver[] = {
.resume = at803x_resume,
.flags  = PHY_POLL_CABLE_TEST,
/* PHY_BASIC_FEATURES */
-   .ack_interrupt  = _ack_interrupt,
.config_intr= _config_intr,
.handle_interrupt   = at803x_handle_interrupt,
.cable_test_start   = at803x_cable_test_start,
-- 
2.28.0

[RFC net-next 0/5] net: phy: add support for shared interrupts

This patch set aims to actually add support for shared interrupts in
phylib and not only for multi-PHY devices. While we are at it,
streamline the interrupt handling in phylib.

For a bit of context, at the moment, there are multiple phy_driver ops
that deal with this subject:

- .config_intr() - Enable/disable the interrupt line.

- .ack_interrupt() - Should quiesce any interrupts that may have been
  fired.  It's also used by phylib in conjunction with .config_intr() to
  clear any pending interrupts after the line was disabled, and before
  it is going to be enabled.

- .did_interrupt() - Intended for multi-PHY devices with a shared IRQ
  line and used by phylib to discern which PHY from the package was the
  one that actually fired the interrupt.

- .handle_interrupt() - Completely overrides the default interrupt
  handling logic from phylib. The PHY driver is responsible for checking
  if any interrupt was fired by the respective PHY and choose
  accordingly if it's the one that should trigger the link state machine.

>From my point of view, the interrupt handling in phylib has become
somewhat confusing with all these callbacks that actually read the same
PHY register - the interrupt status.  A more streamlined approach would
be to just move the responsibility to write an interrupt handler to the
driver (as any other device driver does) and make .handle_interrupt()
the only way to deal with interrupts.

Another advantage with this approach would be that phylib would gain
support for shared IRQs between different PHY (not just multi-PHY
devices), something which at the moment would require extending every
PHY driver anyway in order to implement their .did_interrupt() callback
and duplicate the same logic as in .ack_interrupt(). The disadvantage
of making .did_interrupt() mandatory would be that we are slightly
changing the semantics of the phylib API and that would increase
confusion instead of reducing it.

What I am proposing is the following:

- As a first step, make the .ack_interrupt() callback optional so that
  we do not break any PHY driver amid the transition.

- Every PHY driver gains a .handle_interrupt() implementation that, for
  the most part, would look like below:

irq_status = phy_read(phydev, INTR_STATUS);
if (irq_status < 0) {
phy_error(phydev);
return IRQ_NONE;
}

if (irq_status == 0)
return IRQ_NONE;

phy_trigger_machine(phydev);

return IRQ_HANDLED;

- Remove each PHY driver's implementation of the .ack_interrupt() by
  actually taking care of quiescing any pending interrupts before
  enabling/after disabling the interrupt line.

- Finally, after all drivers have been ported, remove the
  .ack_interrupt() and .did_interrupt() callbacks from phy_driver.

This RFC just contains the patches for phylib and a single driver -
Atheros. The rest can be found on my Github branch here: TODO
They will be submitted as a multi-part series once the merge window
closes.

I do not have access to most of these PHY's, therefore I Cc-ed the
latest contributors to the individual PHY drivers in order to have
access, hopefully, to more regression testing.

Ioana Ciornei (5):
  net: phy: export phy_error and phy_trigger_machine
  net: phy: add a shutdown procedure
  net: phy: make .ack_interrupt() optional
  net: phy: at803x: implement generic .handle_interrupt() callback
  net: phy: at803x: remove the use of .ack_interrupt()

 drivers/net/phy/at803x.c | 42 ++--
 drivers/net/phy/phy.c|  6 --
 drivers/net/phy/phy_device.c | 10 -
 include/linux/phy.h  |  2 ++
 4 files changed, 50 insertions(+), 10 deletions(-)

Cc: Alexandru Ardelean 
Cc: Andre Edich 
Cc: Antoine Tenart 
Cc: Baruch Siach 
Cc: Christophe Leroy 
Cc: Dan Murphy 
Cc: Divya Koppera 
Cc: Florian Fainelli 
Cc: Hauke Mehrtens 
Cc: Heiner Kallweit 
Cc: Jerome Brunet 
Cc: Kavya Sree Kotagiri 
Cc: Linus Walleij 
Cc: Marco Felsch 
Cc: Marek Vasut 
Cc: Martin Blumenstingl 
Cc: Mathias Kresin 
Cc: Maxim Kochetkov 
Cc: Michael Walle 
Cc: Neil Armstrong 
Cc: Nisar Sayed 
Cc: Oleksij Rempel 
Cc: Philippe Schenker 
Cc: Willy Liu 
Cc: Yuiko Oshino 

-- 
2.28.0

Re: [PATCH v8 -tip 02/26] sched: Introduce sched_class::pick_task()

2020-10-24 Thread Vineeth Pillai





On 10/24/20 7:10 AM, Vineeth Pillai wrote:


diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 93a3b874077d..4cae5ac48b60 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4428,12 +4428,14 @@ pick_next_entity(struct cfs_rq *cfs_rq, struct 
sched_entity *curr)

    se = second;
    }

-   if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) 
< 1) {

+   if (left && cfs_rq->next &&
+   wakeup_preempt_entity(cfs_rq->next, left) < 1) {
    /*
 * Someone really wants this to run. If it's not 
unfair, run it.

 */
    se = cfs_rq->next;
-   } else if (cfs_rq->last && wakeup_preempt_entity(cfs_rq->last, 
left) < 1) {

+   } else if (left && cfs_rq->last &&
+   wakeup_preempt_entity(cfs_rq->last, left) < 1) {
    /*
 * Prefer last buddy, try to return the CPU to a 
preempted task.



There reason for left being NULL needs to be investigated. This was
there from v1 and we did not yet get to it. I shall try to debug later
this week.


Thinking more about it and looking at the crash, I think that
'left == NULL' can happen in pick_next_entity for core scheduling.
If a cfs_rq has only one task that is running, then it will be
dequeued and 'left = __pick_first_entity()' will be NULL as the
cfs_rq will be empty. This would not happen outside of coresched
because we never call pick_tack() before put_prev_task() which
will enqueue the task back.

With core scheduling, a cpu can call pick_task() for its sibling while
the sibling is still running the active task and put_prev_task has yet
not been called. This can result in 'left == NULL'. So I think the
above fix is appropriate when core scheduling is active. It could be
cleaned up a bit though.

Thanks,
Vineeth

[RESEND v2] ASoC: tegra20-spdif: remove "default m"

Make tegra20-spdif default to N as all other drivers do.
Add the selection to defconfigs instead.

Signed-off-by: Michał Mirosław 
Fixes: 774fec338bfc ("ASoC: Tegra: Implement SPDIF CPU DAI")
---
 v2: add the symbol to defconfig as suggested by Thierry Reding
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 arch/arm/configs/tegra_defconfig| 1 +
 sound/soc/tegra/Kconfig | 1 -
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index e9e76e32f10f..19342ac738a5 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -743,6 +743,7 @@ CONFIG_SND_SOC_STM32_I2S=m
 CONFIG_SND_SUN4I_CODEC=m
 CONFIG_SND_SOC_TEGRA=m
 CONFIG_SND_SOC_TEGRA20_I2S=m
+CONFIG_SND_SOC_TEGRA20_SPDIF=m
 CONFIG_SND_SOC_TEGRA30_I2S=m
 CONFIG_SND_SOC_TEGRA_RT5640=m
 CONFIG_SND_SOC_TEGRA_WM8753=m
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index fff5fae0db30..08526eb50484 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -225,6 +225,7 @@ CONFIG_SND_HDA_CODEC_HDMI=y
 CONFIG_SND_SOC=y
 CONFIG_SND_SOC_TEGRA=y
 CONFIG_SND_SOC_TEGRA20_I2S=y
+CONFIG_SND_SOC_TEGRA20_SPDIF=y
 CONFIG_SND_SOC_TEGRA30_I2S=y
 CONFIG_SND_SOC_TEGRA_RT5640=y
 CONFIG_SND_SOC_TEGRA_WM8753=y
diff --git a/sound/soc/tegra/Kconfig b/sound/soc/tegra/Kconfig
index 3d91bd3e59cd..a62cc87551ac 100644
--- a/sound/soc/tegra/Kconfig
+++ b/sound/soc/tegra/Kconfig
@@ -39,7 +39,6 @@ config SND_SOC_TEGRA20_I2S
 config SND_SOC_TEGRA20_SPDIF
tristate "Tegra20 SPDIF interface"
depends on SND_SOC_TEGRA
-   default m
help
  Say Y or M if you want to add support for the Tegra20 SPDIF interface.
  You will also need to select the individual machine drivers to support
-- 
2.20.1

[PATCH 2/3] kconfig: qconf: use a variable to pass packages to pkg-config

2020-10-24 Thread Masahiro Yamada

The variable, PKG, is defined at the beginning of this script.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/qconf-cfg.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/qconf-cfg.sh b/scripts/kconfig/qconf-cfg.sh
index d1eb2407c35d..fa564cd795b7 100755
--- a/scripts/kconfig/qconf-cfg.sh
+++ b/scripts/kconfig/qconf-cfg.sh
@@ -11,7 +11,7 @@ if [ -z "$(command -v pkg-config)" ]; then
 fi
 
 if pkg-config --exists $PKG; then
-   echo cflags=\"-std=c++11 -fPIC $(pkg-config --cflags Qt5Core Qt5Gui 
Qt5Widgets)\"
+   echo cflags=\"-std=c++11 -fPIC $(pkg-config --cflags $PKG)\"
echo libs=\"$(pkg-config --libs $PKG)\"
echo moc=\"$(pkg-config --variable=host_bins Qt5Core)/moc\"
exit 0
-- 
2.25.1

[PATCH 1/3] kconfig: qconf: drop Qt4 support

2020-10-24 Thread Masahiro Yamada

It is possible to keep this compatible with both Qt4 and Qt5, but not
worth the efforts any more; it would require us to test this on both of
them, and prevent us from using new features in Qt5.

Qt5 was released in 2012, and now widely available.

Drop the Qt4 support.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/qconf-cfg.sh | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/scripts/kconfig/qconf-cfg.sh b/scripts/kconfig/qconf-cfg.sh
index 02ccc0ae1031..d1eb2407c35d 100755
--- a/scripts/kconfig/qconf-cfg.sh
+++ b/scripts/kconfig/qconf-cfg.sh
@@ -2,7 +2,6 @@
 # SPDX-License-Identifier: GPL-2.0
 
 PKG="Qt5Core Qt5Gui Qt5Widgets"
-PKG2="QtCore QtGui"
 
 if [ -z "$(command -v pkg-config)" ]; then
echo >&2 "*"
@@ -18,15 +17,8 @@ if pkg-config --exists $PKG; then
exit 0
 fi
 
-if pkg-config --exists $PKG2; then
-   echo cflags=\"$(pkg-config --cflags $PKG2)\"
-   echo libs=\"$(pkg-config --libs $PKG2)\"
-   echo moc=\"$(pkg-config --variable=moc_location QtCore)\"
-   exit 0
-fi
-
 echo >&2 "*"
-echo >&2 "* Could not find Qt via pkg-config."
-echo >&2 "* Please install either Qt 4.8 or 5.x. and make sure it's in 
PKG_CONFIG_PATH"
+echo >&2 "* Could not find Qt5 via pkg-config."
+echo >&2 "* Please install Qt5 and make sure it's in PKG_CONFIG_PATH"
 echo >&2 "*"
 exit 1
-- 
2.25.1

[PATCH 3/3] kconfig: qconf: convert to Qt5 new signal/slot connection syntax

2020-10-24 Thread Masahiro Yamada

Now that the Qt4 support was dropped, we can use the new connection
syntax supported by Qt5. It provides compile-time checking of the
validity of the connection.

Previously, the connection between signals and slots were checked
only run-time.

Commit d85de3399f97 ("kconfig: qconf: fix signal connection to invalid
slots") fixed wrong slots.

This change makes it possible to catch such mistakes easily.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/qconf.cc | 136 ++-
 1 file changed, 78 insertions(+), 58 deletions(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index f7eb093614f2..cbe749b44b1a 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -310,15 +310,16 @@ ConfigList::ConfigList(QWidget *parent, const char *name)
 
setHeaderLabels(QStringList() << "Option" << "Name" << "Value");
 
-   connect(this, SIGNAL(itemSelectionChanged(void)),
-   SLOT(updateSelection(void)));
+   connect(this, ::itemSelectionChanged,
+   this, ::updateSelection);
 
if (name) {
configSettings->beginGroup(name);
showName = configSettings->value("/showName", false).toBool();
optMode = (enum optionMode)configSettings->value("/optionMode", 
0).toInt();
configSettings->endGroup();
-   connect(configApp, SIGNAL(aboutToQuit()), SLOT(saveSettings()));
+   connect(configApp, ::aboutToQuit,
+   this, ::saveSettings);
}
 
showColumn(promptColIdx);
@@ -888,10 +889,10 @@ void ConfigList::contextMenuEvent(QContextMenuEvent *e)
headerPopup = new QMenu(this);
action = new QAction("Show Name", this);
action->setCheckable(true);
-   connect(action, SIGNAL(toggled(bool)),
-   SLOT(setShowName(bool)));
-   connect(this, SIGNAL(showNameChanged(bool)),
-   action, SLOT(setChecked(bool)));
+   connect(action, ::toggled,
+   this, ::setShowName);
+   connect(this, ::showNameChanged,
+   action, ::setChecked);
action->setChecked(showName);
headerPopup->addAction(action);
}
@@ -936,15 +937,18 @@ ConfigInfoView::ConfigInfoView(QWidget* parent, const 
char *name)
configSettings->beginGroup(objectName());
setShowDebug(configSettings->value("/showDebug", 
false).toBool());
configSettings->endGroup();
-   connect(configApp, SIGNAL(aboutToQuit()), SLOT(saveSettings()));
+   connect(configApp, ::aboutToQuit,
+   this, ::saveSettings);
}
 
contextMenu = createStandardContextMenu();
QAction *action = new QAction("Show Debug Info", contextMenu);
 
action->setCheckable(true);
-   connect(action, SIGNAL(toggled(bool)), SLOT(setShowDebug(bool)));
-   connect(this, SIGNAL(showDebugChanged(bool)), action, 
SLOT(setChecked(bool)));
+   connect(action, ::toggled,
+   this, ::setShowDebug);
+   connect(this, ::showDebugChanged,
+   action, ::setChecked);
action->setChecked(showDebug());
contextMenu->addSeparator();
contextMenu->addAction(action);
@@ -1231,11 +1235,13 @@ ConfigSearchWindow::ConfigSearchWindow(ConfigMainWindow 
*parent)
layout2->setSpacing(6);
layout2->addWidget(new QLabel("Find:", this));
editField = new QLineEdit(this);
-   connect(editField, SIGNAL(returnPressed()), SLOT(search()));
+   connect(editField, ::returnPressed,
+   this, ::search);
layout2->addWidget(editField);
searchButton = new QPushButton("Search", this);
searchButton->setAutoDefault(false);
-   connect(searchButton, SIGNAL(clicked()), SLOT(search()));
+   connect(searchButton, ::clicked,
+   this, ::search);
layout2->addWidget(searchButton);
layout1->addLayout(layout2);
 
@@ -1244,10 +1250,10 @@ ConfigSearchWindow::ConfigSearchWindow(ConfigMainWindow 
*parent)
list = new ConfigList(split, "search");
list->mode = listMode;
info = new ConfigInfoView(split, "search");
-   connect(list, SIGNAL(menuChanged(struct menu *)),
-   info, SLOT(setInfo(struct menu *)));
-   connect(list, SIGNAL(menuChanged(struct menu *)),
-   parent, SLOT(setMenuLink(struct menu *)));
+   connect(list, ::menuChanged,
+   info, ::setInfo);
+   connect(list, ::menuChanged,
+   parent, ::setMenuLink);
 
layout1->addWidget(split);
 
@@ -1267,7 +1273,8 @@ ConfigSearchWindow::ConfigSearchWindow(ConfigMainWindow 
*parent)
if (ok)
split->setSizes(sizes);
configSettings->endGroup();
-   connect(configApp, SIGNAL(aboutToQuit()),

Re: [PATCH v2 8/8] x86/ioapic: Generate RTE directly from parent irqchip's MSI message

On Sat, 2020-10-24 at 11:13 +0100, David Woodhouse wrote:
> OK, thanks. I'll rework Thomas's tree with that first and the other
> changes I'd mentioned in my parts, as well as fixing up that unholy
> chimæra of struct/union in which we set some bitfields from each side
> of the union, test and push it out later today.

OK, pushed out to 
https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/x86/apic]

It's Thomas's tree plus the struct/union fixes and other things I
mentioned earlier, a few comment fixes in the 'Generate RTE directly
from parent irqchip' patch, but the most interesting part is finishing
the job of the 'Cleanup IO/APIC route entry structs' patch...

From 54b623fc2b03eadb76485b4ca0ade3e79acf6c27 Mon Sep 17 00:00:00 2001
From: Thomas Gleixner 
Date: Thu, 22 Oct 2020 14:48:18 +0200
Subject: [PATCH 124/137] x86/ioapic: Cleanup IO/APIC route entry structs

Having two seperate structs for the I/O-APIC RTE entries (non-remapped and
DMAR remapped) requires type casts and makes it hard to map.

Combine them in IO_APIC_routing_entry by defining a union of two 64bit
bitfields. Use naming which reflects which bits are shared and which bits
are actually different for the operating modes.

[dwmw2: Fix it up and finish the job, pulling the 32-bit w1,w2 words for
register access into the same union and eliminating a few more
places where bits were accessed through masks and shifts.]

Signed-off-by: Thomas Gleixner 
Signed-off-by: David Woodhouse 
---
 arch/x86/include/asm/io_apic.h  |  78 ++-
 arch/x86/kernel/apic/io_apic.c  | 144 +---
 drivers/iommu/amd/iommu.c   |   8 +-
 drivers/iommu/hyperv-iommu.c|   4 +-
 drivers/iommu/intel/irq_remapping.c |  19 ++--
 5 files changed, 108 insertions(+), 145 deletions(-)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index a1a26f6d3aa4..73da644b2f0d 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -13,15 +13,6 @@
  * Copyright (C) 1997, 1998, 1999, 2000 Ingo Molnar
  */
 
-/* I/O Unit Redirection Table */
-#define IO_APIC_REDIR_VECTOR_MASK  0x000FF
-#define IO_APIC_REDIR_DEST_LOGICAL 0x00800
-#define IO_APIC_REDIR_DEST_PHYSICAL0x0
-#define IO_APIC_REDIR_SEND_PENDING (1 << 12)
-#define IO_APIC_REDIR_REMOTE_IRR   (1 << 14)
-#define IO_APIC_REDIR_LEVEL_TRIGGER(1 << 15)
-#define IO_APIC_REDIR_MASKED   (1 << 16)
-
 /*
  * The structure of the IO-APIC:
  */
@@ -65,52 +56,39 @@ union IO_APIC_reg_03 {
 };
 
 struct IO_APIC_route_entry {
-   __u32   vector  :  8,
-   delivery_mode   :  3,   /* 000: FIXED
-* 001: lowest prio
-* 111: ExtINT
-*/
-   dest_mode   :  1,   /* 0: physical, 1: logical */
-   delivery_status :  1,
-   polarity:  1,
-   irr :  1,
-   trigger :  1,   /* 0: edge, 1: level */
-   mask:  1,   /* 0: enabled, 1: disabled */
-   __reserved_2: 15;
-
-   __u32   __reserved_3: 24,
-   dest:  8;
-} __attribute__ ((packed));
-
-struct IR_IO_APIC_route_entry {
-   __u64   vector  : 8,
-   zero: 3,
-   index2  : 1,
-   delivery_status : 1,
-   polarity: 1,
-   irr : 1,
-   trigger : 1,
-   mask: 1,
-   reserved: 31,
-   format  : 1,
-   index   : 15;
+   union {
+   struct {
+   u64 vector  :  8,
+   delivery_mode   :  3,
+   dest_mode_logical   :  1,
+   delivery_status :  1,
+   active_low  :  1,
+   irr :  1,
+   is_level:  1,
+   masked  :  1,
+   reserved_0  : 15,
+   reserved_1  : 24,
+   destid_0_7  :  8;
+   };
+   struct {
+   u64 ir_shared_0 :  8,
+   ir_zero :  3,
+   ir_index_15 :  1,
+   ir_shared_1 :  5,
+   ir_reserved_0   : 31,
+   ir_format   :  1,
+   ir_index_0_14   : 15;
+   };
+

[PATCH v8 4/4] input: elants: support 0x66 reply opcode for reporting touches

From: Dmitry Osipenko 

eKTF3624 touchscreen firmware uses two variants of the reply opcodes for
reporting touch events: one is 0x63 (used by older firmware) and other is
0x66 (used by newer firmware). The 0x66 variant is equal to 0x63 of
eKTH3500, while 0x63 needs small adjustment of the touch pressure value.

Nexus 7 tablet device has eKTF3624 touchscreen and it uses 0x66 opcode for
reporting touch events, let's support it now. Other devices, eg. ASUS TF300T,
use 0x63.

Note: CMD_HEADER_REK is used for replying to calibration requests, it has
the same 0x66 opcode number which eKTF3624 uses for reporting touches.
The calibration replies are handled separately from the the rest of the
commands in the driver by entering into ELAN_WAIT_RECALIBRATION state
and thus this change shouldn't change the old behavior.

Signed-off-by: Dmitry Osipenko 
Tested-by: Michał Mirosław 
Signed-off-by: Michał Mirosław 
---
 drivers/input/touchscreen/elants_i2c.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index c24d8cdc4251..1cbda6f20d07 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -61,6 +61,15 @@
 #define QUEUE_HEADER_NORMAL0X63
 #define QUEUE_HEADER_WAIT  0x64
 
+/*
+ * Depending on firmware version, eKTF3624 touchscreens may utilize one of
+ * these opcodes for the touch events: 0x63 and 0x66. The 0x63 is used by
+ * older firmware version and differs from 0x66 such that touch pressure
+ * value needs to be adjusted. The 0x66 opcode of newer firmware is equal
+ * to 0x63 of eKTH3500.
+ */
+#define QUEUE_HEADER_NORMAL2   0x66
+
 /* Command header definition */
 #define CMD_HEADER_WRITE   0x54
 #define CMD_HEADER_READ0x53
@@ -1052,7 +1061,6 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
switch (ts->buf[FW_HDR_TYPE]) {
case CMD_HEADER_HELLO:
case CMD_HEADER_RESP:
-   case CMD_HEADER_REK:
break;
 
case QUEUE_HEADER_WAIT:
@@ -1072,6 +1080,7 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
break;
 
case QUEUE_HEADER_NORMAL:
+   case QUEUE_HEADER_NORMAL2:
report_count = ts->buf[FW_HDR_COUNT];
if (report_count == 0 || report_count > 3) {
dev_err(>dev,
-- 
2.20.1

[PATCH v8 0/4] input: elants: Support Asus TF300T and Nexus 7 touchscreens

This series cleans up the driver a bit and implements changes needed to
support EKTF3624-based touchscreen used in Asus TF300T, Google Nexus 7
and similar Tegra3-based tablets.

---
v2: extended with Dmitry's patches (replaced v1 patches 3 and 4)
v3: rebased for v5.7-rc1
v4: rebased onto v5.7-rc2+ (current Linus' master)
update "remove unused axes" and "refactor
  elants_i2c_execute_command()" patches after review
add David's patch converting DT binding to YAML
v5: rebased onto dtor/input/for-linus
v6: rebased onto newer dtor/input/for-linus
remove yet unused constants from patch 1
added a new drive-by cleanup (last patch)
v7: rebased onto current dtor/input/for-next
v8: rebased onto current dtor/input/for-linus again
---

Dmitry Osipenko (1):
  input: elants: support 0x66 reply opcode for reporting touches

Michał Mirosław (3):
  input: elants: document some registers and values
  input: elants: support old touch report format
  input: elants: read touchscreen size for EKTF3624

 drivers/input/touchscreen/elants_i2c.c | 149 +
 1 file changed, 127 insertions(+), 22 deletions(-)

-- 
2.20.1

[PATCH v8 3/4] input: elants: read touchscreen size for EKTF3624

EKTF3624 as present in Asus TF300T tablet has touchscreen size encoded
in different registers.

Signed-off-by: Michał Mirosław 
Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
---
 drivers/input/touchscreen/elants_i2c.c | 84 --
 1 file changed, 79 insertions(+), 5 deletions(-)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index f1bf3e000e96..c24d8cdc4251 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -35,7 +35,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -43,6 +43,10 @@
 /* Device, Driver information */
 #define DEVICE_NAME"elants_i2c"
 
+/* Device IDs */
+#define EKTH3500   0
+#define EKTF3624   1
+
 /* Convert from rows or columns into resolution */
 #define ELAN_TS_RESOLUTION(n, m)   (((n) - 1) * (m))
 
@@ -94,6 +98,8 @@
 #define E_ELAN_INFO_REK0xD0
 #define E_ELAN_INFO_TEST_VER   0xE0
 #define E_ELAN_INFO_FW_ID  0xF0
+#define E_INFO_X_RES   0x60
+#define E_INFO_Y_RES   0x63
 #define E_INFO_OSR 0xD6
 #define E_INFO_PHY_SCAN0xD7
 #define E_INFO_PHY_DRIVER  0xD8
@@ -157,6 +163,7 @@ struct elants_data {
 
bool wake_irq_enabled;
bool keep_power_in_suspend;
+   u8 chip_id;
 
/* Must be last to be used for DMA operations */
u8 buf[MAX_PACKET_SIZE] cacheline_aligned;
@@ -434,7 +441,58 @@ static int elants_i2c_query_bc_version(struct elants_data 
*ts)
return 0;
 }
 
-static int elants_i2c_query_ts_info(struct elants_data *ts)
+static int elants_i2c_query_ts_info_ektf(struct elants_data *ts)
+{
+   struct i2c_client *client = ts->client;
+   int error;
+   u8 resp[4];
+   u16 phy_x, phy_y;
+   const u8 get_xres_cmd[] = {
+   CMD_HEADER_READ, E_INFO_X_RES, 0x00, 0x00
+   };
+   const u8 get_yres_cmd[] = {
+   CMD_HEADER_READ, E_INFO_Y_RES, 0x00, 0x00
+   };
+
+   /* Get X/Y size in mm */
+   error = elants_i2c_execute_command(client, get_xres_cmd,
+  sizeof(get_xres_cmd),
+  resp, sizeof(resp), 1,
+  "get X size");
+   if (error)
+   return error;
+
+   phy_x = resp[2] | ((resp[3] & 0xF0) << 4);
+
+   error = elants_i2c_execute_command(client, get_yres_cmd,
+  sizeof(get_yres_cmd),
+  resp, sizeof(resp), 1,
+  "get Y size");
+   if (error)
+   return error;
+
+   phy_y = resp[2] | ((resp[3] & 0xF0) << 4);
+
+   if (!phy_x || !phy_y) {
+   dev_warn(>dev,
+"invalid size data: %d x %d mm\n",
+phy_x, phy_y);
+   return 0;
+   }
+
+   dev_dbg(>dev, "phy_x=%d, phy_y=%d\n", phy_x, phy_y);
+
+   /* calculate resolution from size */
+   ts->x_max = 2240-1;
+   ts->x_res = DIV_ROUND_CLOSEST(ts->prop.max_x, phy_x);
+
+   ts->y_max = 1408-1;
+   ts->y_res = DIV_ROUND_CLOSEST(ts->prop.max_y, phy_y);
+
+   return 0;
+}
+
+static int elants_i2c_query_ts_info_ekth(struct elants_data *ts)
 {
struct i2c_client *client = ts->client;
int error;
@@ -588,8 +646,20 @@ static int elants_i2c_initialize(struct elants_data *ts)
error = elants_i2c_query_fw_version(ts);
if (!error)
error = elants_i2c_query_test_version(ts);
-   if (!error)
-   error = elants_i2c_query_ts_info(ts);
+
+   switch (ts->chip_id) {
+   case EKTH3500:
+   if (!error)
+   error = elants_i2c_query_ts_info_ekth(ts);
+   break;
+   case EKTF3624:
+   if (!error)
+   error = elants_i2c_query_ts_info_ektf(ts);
+   break;
+   default:
+   unreachable();
+   break;
+   }
 
if (error)
ts->iap_mode = ELAN_IAP_RECOVERY;
@@ -1266,6 +1336,9 @@ static int elants_i2c_probe(struct i2c_client *client,
ts->client = client;
i2c_set_clientdata(client, ts);
 
+   if (client->dev.of_node)
+   ts->chip_id = (uintptr_t)of_device_get_match_data(>dev);
+
ts->vcc33 = devm_regulator_get(>dev, "vcc33");
if (IS_ERR(ts->vcc33)) {
error = PTR_ERR(ts->vcc33);
@@ -1495,7 +1568,8 @@ MODULE_DEVICE_TABLE(acpi, elants_acpi_id);
 
 #ifdef CONFIG_OF
 static const struct of_device_id elants_of_match[] = {
-   { .compatible = "elan,ekth3500" },
+   { .compatible = "elan,ekth3500", .data = (void *)EKTH3500 },
+   { .compatible = "elan,ektf3624", .data = (void *)EKTF3624 },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, elants_of_match);
--

[PATCH v8 2/4] input: elants: support old touch report format

Support ELAN touchpad sensor with older firmware as found on eg. Asus
Transformer Pads.

Signed-off-by: Michał Mirosław 
Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
---
 drivers/input/touchscreen/elants_i2c.c | 36 ++
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index d51cb910fba1..f1bf3e000e96 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -69,6 +69,7 @@
 #define CMD_HEADER_REK 0x66
 
 /* FW position data */
+#define PACKET_SIZE_OLD40
 #define PACKET_SIZE55
 #define MAX_CONTACT_NUM10
 #define FW_POS_HEADER  0
@@ -853,7 +854,8 @@ static int elants_i2c_fw_update(struct elants_data *ts)
  * Event reporting.
  */
 
-static void elants_i2c_mt_event(struct elants_data *ts, u8 *buf)
+static void elants_i2c_mt_event(struct elants_data *ts, u8 *buf,
+   size_t report_len)
 {
struct input_dev *input = ts->input;
unsigned int n_fingers;
@@ -866,7 +868,8 @@ static void elants_i2c_mt_event(struct elants_data *ts, u8 
*buf)
buf[FW_POS_STATE];
 
dev_dbg(>client->dev,
-   "n_fingers: %u, state: %04x\n",  n_fingers, finger_state);
+   "n_fingers: %u, state: %04x, report_len: %zu\n",
+   n_fingers, finger_state, report_len);
 
/* Note: all fingers have the same tool type */
tool_type = buf[FW_POS_TOOL_TYPE] & BIT(0) ?
@@ -880,8 +883,16 @@ static void elants_i2c_mt_event(struct elants_data *ts, u8 
*buf)
pos = [FW_POS_XY + i * 3];
x = (((u16)pos[0] & 0xf0) << 4) | pos[1];
y = (((u16)pos[0] & 0x0f) << 8) | pos[2];
-   p = buf[FW_POS_PRESSURE + i];
-   w = buf[FW_POS_WIDTH + i];
+   if (report_len == PACKET_SIZE_OLD) {
+   w = buf[FW_POS_WIDTH + i / 2];
+   w >>= 4 * (~i & 1); // little-endian-nibbles
+   w |= w << 4;
+   w |= !w;
+   p = w;
+   } else {
+   p = buf[FW_POS_PRESSURE + i];
+   w = buf[FW_POS_WIDTH + i];
+   }
 
dev_dbg(>client->dev, "i=%d x=%d y=%d p=%d w=%d\n",
i, x, y, p, w);
@@ -913,7 +924,8 @@ static u8 elants_i2c_calculate_checksum(u8 *buf)
return checksum;
 }
 
-static void elants_i2c_event(struct elants_data *ts, u8 *buf)
+static void elants_i2c_event(struct elants_data *ts, u8 *buf,
+size_t report_len)
 {
u8 checksum = elants_i2c_calculate_checksum(buf);
 
@@ -927,7 +939,7 @@ static void elants_i2c_event(struct elants_data *ts, u8 
*buf)
 "%s: unknown packet type: %02x\n",
 __func__, buf[FW_POS_HEADER]);
else
-   elants_i2c_mt_event(ts, buf);
+   elants_i2c_mt_event(ts, buf, report_len);
 }
 
 static irqreturn_t elants_i2c_irq(int irq, void *_dev)
@@ -985,7 +997,8 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
break;
 
case QUEUE_HEADER_SINGLE:
-   elants_i2c_event(ts, >buf[HEADER_SIZE]);
+   elants_i2c_event(ts, >buf[HEADER_SIZE],
+ts->buf[FW_HDR_LENGTH]);
break;
 
case QUEUE_HEADER_NORMAL:
@@ -998,17 +1011,18 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
}
 
report_len = ts->buf[FW_HDR_LENGTH] / report_count;
-   if (report_len != PACKET_SIZE) {
+   if (report_len != PACKET_SIZE &&
+   report_len != PACKET_SIZE_OLD) {
dev_err(>dev,
-   "mismatching report length: %*ph\n",
+   "unsupported report length: %*ph\n",
HEADER_SIZE, ts->buf);
break;
}
 
for (i = 0; i < report_count; i++) {
u8 *buf = ts->buf + HEADER_SIZE +
-   i * PACKET_SIZE;
-   elants_i2c_event(ts, buf);
+ i * report_len;
+   elants_i2c_event(ts, buf, report_len);
}
break;
 
-- 
2.20.1

[PATCH v8 1/4] input: elants: document some registers and values

Add information found in downstream kernels, to make the code less
magic.

Signed-off-by: Michał Mirosław 
Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
---
 drivers/input/touchscreen/elants_i2c.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index 50c348297e38..d51cb910fba1 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -82,7 +82,7 @@
 
 #define HEADER_REPORT_10_FINGER0x62
 
-/* Header (4 bytes) plus 3 fill 10-finger packets */
+/* Header (4 bytes) plus 3 full 10-finger packets */
 #define MAX_PACKET_SIZE169
 
 #define BOOT_TIME_DELAY_MS 50
@@ -97,6 +97,10 @@
 #define E_INFO_PHY_SCAN0xD7
 #define E_INFO_PHY_DRIVER  0xD8
 
+/* FW write command, 0x54 0x?? 0x0, 0x01 */
+#define E_POWER_STATE_SLEEP0x50
+#define E_POWER_STATE_RESUME   0x58
+
 #define MAX_RETRIES3
 #define MAX_FW_UPDATE_RETRIES  30
 
@@ -269,8 +273,8 @@ static int elants_i2c_calibrate(struct elants_data *ts)
 {
struct i2c_client *client = ts->client;
int ret, error;
-   static const u8 w_flashkey[] = { 0x54, 0xC0, 0xE1, 0x5A };
-   static const u8 rek[] = { 0x54, 0x29, 0x00, 0x01 };
+   static const u8 w_flashkey[] = { CMD_HEADER_WRITE, 0xC0, 0xE1, 0x5A };
+   static const u8 rek[] = { CMD_HEADER_WRITE, 0x29, 0x00, 0x01 };
static const u8 rek_resp[] = { CMD_HEADER_REK, 0x66, 0x66, 0x66 };
 
disable_irq(client->irq);
@@ -1388,7 +1392,9 @@ static int __maybe_unused elants_i2c_suspend(struct 
device *dev)
 {
struct i2c_client *client = to_i2c_client(dev);
struct elants_data *ts = i2c_get_clientdata(client);
-   const u8 set_sleep_cmd[] = { 0x54, 0x50, 0x00, 0x01 };
+   const u8 set_sleep_cmd[] = {
+   CMD_HEADER_WRITE, E_POWER_STATE_SLEEP, 0x00, 0x01
+   };
int retry_cnt;
int error;
 
@@ -1425,7 +1431,9 @@ static int __maybe_unused elants_i2c_resume(struct device 
*dev)
 {
struct i2c_client *client = to_i2c_client(dev);
struct elants_data *ts = i2c_get_clientdata(client);
-   const u8 set_active_cmd[] = { 0x54, 0x58, 0x00, 0x01 };
+   const u8 set_active_cmd[] = {
+   CMD_HEADER_WRITE, E_POWER_STATE_RESUME, 0x00, 0x01
+   };
int retry_cnt;
int error;
 
-- 
2.20.1

Re: For review: seccomp_user_notif(2) manual page

2020-10-24 Thread Michael Kerrisk (man-pages)

Hello Jann,

On 10/17/20 2:25 AM, Jann Horn wrote:
> On Fri, Oct 16, 2020 at 8:29 PM Michael Kerrisk (man-pages)
>  wrote:
>> On 10/15/20 10:32 PM, Jann Horn wrote:
>>> On Thu, Oct 15, 2020 at 1:24 PM Michael Kerrisk (man-pages)
>>>  wrote:
 On 9/30/20 5:53 PM, Jann Horn wrote:
> On Wed, Sep 30, 2020 at 1:07 PM Michael Kerrisk (man-pages)
>  wrote:
>> I knew it would be a big ask, but below is kind of the manual page
>> I was hoping you might write [1] for the seccomp user-space notification
>> mechanism. Since you didn't (and because 5.9 adds various new pieces
>> such as SECCOMP_ADDFD_FLAG_SETFD and SECCOMP_IOCTL_NOTIF_ADDFD
>> that also will need documenting [2]), I did :-). But of course I may
>> have made mistakes...
>>> [...]
>>3. The supervisor process will receive notification events on the
>>   listening  file  descriptor.   These  events  are  returned as
>>   structures of type seccomp_notif.  Because this structure  and
>>   its  size may evolve over kernel versions, the supervisor must
>>   first determine the size of  this  structure  using  the  sec‐
>>   comp(2)  SECCOMP_GET_NOTIF_SIZES  operation,  which  returns a
>>   structure of type seccomp_notif_sizes.  The  supervisor  allo‐
>>   cates a buffer of size seccomp_notif_sizes.seccomp_notif bytes
>>   to receive notification events.   In  addition,the  supervisor
>>   allocates  another  buffer  of  size  seccomp_notif_sizes.sec‐
>>   comp_notif_resp  bytes  for  the  response  (a   struct   sec‐
>>   comp_notif_resp  structure) that it will provide to the kernel
>>   (and thus the target process).
>>
>>4. The target process then performs its workload, which  includes
>>   system  calls  that  will be controlled by the seccomp filter.
>>   Whenever one of these system calls causes the filter to return
>>   the  SECCOMP_RET_USER_NOTIF  action value, the kernel does not
>>   execute the system call;  instead,  execution  of  the  target
>>   process is temporarily blocked inside the kernel and a notifi‐
>
> where "blocked" refers to the interruptible, restartable kind - if the
> child receives a signal with an SA_RESTART signal handler in the
> meantime, it'll leave the syscall, go through the signal handler, then
> restart the syscall again and send the same request to the supervisor
> again. so the supervisor may see duplicate syscalls.

 So, I partially demonstrated what you describe here, for two example
 system calls (epoll_wait() and pause()). But I could not exactly
 demonstrate things as I understand you to be describing them. (So,
 I'm not sure whether I have not understood you correctly, or
 if things are not exactly as you describe them.)

 Here's a scenario (A) that I tested:

 1. Target installs seccomp filters for a blocking syscall
(epoll_wait() or pause(), both of which should never restart,
regardless of SA_RESTART)
 2. Target installs SIGINT handler with SA_RESTART
 3. Supervisor is sleeping (i.e., is not blocked in
SECCOMP_IOCTL_NOTIF_RECV operation).
 4. Target makes a blocking system call (epoll_wait() or pause()).
 5. SIGINT gets delivered to target; handler gets called;
***and syscall gets restarted by the kernel***

 That last should never happen, of course, and is a result of the
 combination of both the user-notify filter and the SA_RESTART flag.
 If one or other is not present, then the system call is not
 restarted.

 So, as you note below, the UAPI gets broken a little.

 However, from your description above I had understood that
 something like the following scenario (B) could occur:

 1. Target installs seccomp filters for a blocking syscall
(epoll_wait() or pause(), both of which should never restart,
regardless of SA_RESTART)
 2. Target installs SIGINT handler with SA_RESTART
 3. Supervisor performs SECCOMP_IOCTL_NOTIF_RECV operation (which
blocks).
 4. Target makes a blocking system call (epoll_wait() or pause()).
 5. Supervisor gets seccomp user-space notification (i.e.,
SECCOMP_IOCTL_NOTIF_RECV ioctl() returns
 6. SIGINT gets delivered to target; handler gets called;
and syscall gets restarted by the kernel
 7. Supervisor performs another SECCOMP_IOCTL_NOTIF_RECV operation
which gets another notification for the restarted system call.

 However, I don't observe such behavior. In step 6, the syscall
 does not get restarted by the kernel, but instead returns -1/EINTR.
 Perhaps I have misconstructed my experiment in the second case, or
 perhaps I've misunderstood what you meant, or is it possibly

[PATCH] arch/Kconfig: fix a few trivial spelling mistakes in Kconfig

2020-10-24 Thread Colin King

From: Colin Ian King 

There are a couple of trivial spelling mistakes, fix these.

Signed-off-by: Colin Ian King 
---
 arch/Kconfig | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 56b6ccc0e32d..ce4e84366418 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -261,7 +261,7 @@ config ARCH_HAS_SET_DIRECT_MAP
 
 #
 # Select if the architecture provides the arch_dma_set_uncached symbol to
-# either provide an uncached segement alias for a DMA allocation, or
+# either provide an uncached segment alias for a DMA allocation, or
 # to remap the page tables in place.
 #
 config ARCH_HAS_DMA_SET_UNCACHED
@@ -314,14 +314,14 @@ config ARCH_32BIT_OFF_T
 config HAVE_ASM_MODVERSIONS
bool
help
- This symbol should be selected by an architecure if it provides
+ This symbol should be selected by an architecture if it provides
   to support the module versioning for symbols
  exported from assembly code.
 
 config HAVE_REGS_AND_STACK_ACCESS_API
bool
help
- This symbol should be selected by an architecure if it supports
+ This symbol should be selected by an architecture if it supports
  the API needed to access registers and stack entries from pt_regs,
  declared in asm/ptrace.h
  For example the kprobes-based event tracer needs this API.
@@ -336,7 +336,7 @@ config HAVE_RSEQ
 config HAVE_FUNCTION_ARG_ACCESS_API
bool
help
- This symbol should be selected by an architecure if it supports
+ This symbol should be selected by an architecture if it supports
  the API needed to access function arguments from pt_regs,
  declared in asm/ptrace.h
 
-- 
2.27.0

swap file broken with ext4 fast-commit

2020-10-24 Thread Andrea Righi

I'm getting the following error if I try to create and activate a swap
file defined on an ext4 filesystem:

 [   34.406479] swapon: file is not committed

The swap file is created in the root filesystem (ext4 mounted with the
following options):

$ grep " / " /proc/mounts
/dev/vda1 / ext4 rw,relatime 0 0

No matter how long I wait or how many times I run sync, I'm still
getting the same error and the swap file is never activated.

A git bisect shows that this issue has been introduced by the following
commit:

 aa75f4d3daae ("ext4: main fast-commit commit path")

Simple test case to reproduce the problem:

 # fallocate -l 8G /swapfile
 # chmod 0600 /swapfile
 # mkswap /swapfile
 # swapon /swapfile

Maybe we're missing to mark the inode as clean somewhere, even if the
transation is committed to the journal?

Thanks,
-Andrea

Re: [PATCH v3] checkpatch: fix false positives in REPEATED_WORD warning

2020-10-24 Thread Aditya

On 24/10/20 12:36 am, Lukas Bulwahn wrote:
> 
> 
> On Fri, 23 Oct 2020, Aditya Srivastava wrote:
> 
>> Presence of hexadecimal address or symbol results in false warning
>> message by checkpatch.pl.
>>
> 
> I think this strategy now makes sense and has the right complexity for a 
> good heuristics in this case.
> 
> Nice job, Aditya.
> 
> Are you ready for a next challenge of this kind? Would you like to work on 
> further rules that can be improved with your evaluation approach?
> 
> Lukas
> 

Yes, I would like work on further rules.

Thanks
Aditya

Re: swap file broken with ext4 fast-commit

2020-10-24 Thread Andrea Righi

On Sat, Oct 24, 2020 at 03:13:37PM +0200, Andrea Righi wrote:
> I'm getting the following error if I try to create and activate a swap
> file defined on an ext4 filesystem:
> 
>  [   34.406479] swapon: file is not committed
> 
> The swap file is created in the root filesystem (ext4 mounted with the
> following options):
> 
> $ grep " / " /proc/mounts
> /dev/vda1 / ext4 rw,relatime 0 0
> 
> No matter how long I wait or how many times I run sync, I'm still
> getting the same error and the swap file is never activated.
> 
> A git bisect shows that this issue has been introduced by the following
> commit:
> 
>  aa75f4d3daae ("ext4: main fast-commit commit path")
> 
> Simple test case to reproduce the problem:
> 
>  # fallocate -l 8G /swapfile
>  # chmod 0600 /swapfile
>  # mkswap /swapfile
>  # swapon /swapfile
> 
> Maybe we're missing to mark the inode as clean somewhere, even if the
> transation is committed to the journal?

I think I see the problem. There's something wrong in
ext4_inode_datasync_dirty(), it looks like the logic to check if the
inode is dirty is quite the opposite.

I'll test and send a patch soon.

-Andrea

Re: [PATCH] drm/i915: Fix a crash in shmem_pin_map() error handling

2020-10-24 Thread Dan Carpenter

On Fri, Oct 23, 2020 at 02:19:41PM +0200, Christoph Hellwig wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c 
> > b/drivers/gpu/drm/i915/gt/shmem_utils.c
> > index f011ea42487e..7eb542018219 100644
> > --- a/drivers/gpu/drm/i915/gt/shmem_utils.c
> > +++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
> > @@ -52,8 +52,9 @@ struct file *shmem_create_from_object(struct 
> > drm_i915_gem_object *obj)
> >  void *shmem_pin_map(struct file *file)
> >  {
> > struct page **pages;
> > -   size_t n_pages, i;
> > +   size_t n_pages;
> > void *vaddr;
> > +   int i;
> >  
> > n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
> > pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
> 
> This assumes we never have more than INT_MAX worth of pages before
> a failure. 

Doh.  Yeah.  My bad.

regards,
dan carpenter

Re: [RFC PATCH 2/6] fpga: dfl: export network configuration info for DFL based FPGA



On 10/23/20 1:45 AM, Xu Yilun wrote:
> This patch makes preparation for supporting DFL Ether Group private
> feature driver, which reads bitstream_id.vendor_net_cfg field to
> determin the interconnection of network components on FPGA device.
>
> Signed-off-by: Xu Yilun 
> ---
>  drivers/fpga/dfl-fme-main.c | 10 ++
>  drivers/fpga/dfl.c  | 21 +
>  drivers/fpga/dfl.h  | 12 
>  include/linux/dfl.h |  2 ++
>  4 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> index 77ea04d..a2b8ba0 100644
> --- a/drivers/fpga/dfl-fme-main.c
> +++ b/drivers/fpga/dfl-fme-main.c
> @@ -46,14 +46,8 @@ static DEVICE_ATTR_RO(ports_num);
>  static ssize_t bitstream_id_show(struct device *dev,
>struct device_attribute *attr, char *buf)
>  {
> - void __iomem *base;
> - u64 v;
> -
> - base = dfl_get_feature_ioaddr_by_id(dev, FME_FEATURE_ID_HEADER);
> -
> - v = readq(base + FME_HDR_BITSTREAM_ID);
> -
> - return scnprintf(buf, PAGE_SIZE, "0x%llx\n", (unsigned long long)v);
> + return scnprintf(buf, PAGE_SIZE, "0x%llx\n",
> +  (unsigned long long)dfl_get_bitstream_id(dev));
should use sysfs_emit()
>  }
>  static DEVICE_ATTR_RO(bitstream_id);
>  
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index bc35750..ca3c678 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -537,6 +537,27 @@ void dfl_driver_unregister(struct dfl_driver *dfl_drv)
>  }
>  EXPORT_SYMBOL(dfl_driver_unregister);
>  
> +int dfl_dev_get_vendor_net_cfg(struct dfl_device *dfl_dev)
> +{
> + struct device *fme_dev;
> + u64 v;
> +
> + if (!dfl_dev)
> + return -EINVAL;
> +
> + if (dfl_dev->type == FME_ID)
> + fme_dev = dfl_dev->dev.parent;
> + else
> + fme_dev = dfl_dev->cdev->fme_dev;
> +
> + if (!fme_dev)
> + return -EINVAL;
> +
> + v = dfl_get_bitstream_id(fme_dev);
> + return (int)FIELD_GET(FME_BID_VENDOR_NET_CFG, v);
> +}
> +EXPORT_SYMBOL_GPL(dfl_dev_get_vendor_net_cfg);
> +
>  #define is_header_feature(feature) ((feature)->id == FEATURE_ID_FIU_HEADER)
>  
>  /**
> diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
> index 2b82c96..6c7a6961 100644
> --- a/drivers/fpga/dfl.h
> +++ b/drivers/fpga/dfl.h
> @@ -104,6 +104,9 @@
>  #define FME_CAP_CACHE_SIZE   GENMASK_ULL(43, 32) /* cache size in KB */
>  #define FME_CAP_CACHE_ASSOC  GENMASK_ULL(47, 44) /* Associativity */
>  
> +/* FME BITSTREAM_ID Register Bitfield */
> +#define FME_BID_VENDOR_NET_CFG   GENMASK_ULL(35, 32) /* vendor net 
> cfg */

Are there any other similar #defines that could be added here for completeness?

> +
>  /* FME Port Offset Register Bitfield */
>  /* Offset to port device feature header */
>  #define FME_PORT_OFST_DFH_OFST   GENMASK_ULL(23, 0)
> @@ -397,6 +400,15 @@ static inline bool is_dfl_feature_present(struct device 
> *dev, u16 id)
>   return !!dfl_get_feature_ioaddr_by_id(dev, id);
>  }
>  
> +static inline u64 dfl_get_bitstream_id(struct device *dev)
> +{
> + void __iomem *base;
> +
> + base = dfl_get_feature_ioaddr_by_id(dev, FME_FEATURE_ID_HEADER);
> +
> + return readq(base + FME_HDR_BITSTREAM_ID);
> +}

This is is a generic change and should be split out.

Tom

> +
>  static inline
>  struct device *dfl_fpga_pdata_to_parent(struct dfl_feature_platform_data 
> *pdata)
>  {
> diff --git a/include/linux/dfl.h b/include/linux/dfl.h
> index e1b2471..5ee2b1e 100644
> --- a/include/linux/dfl.h
> +++ b/include/linux/dfl.h
> @@ -67,6 +67,8 @@ struct dfl_driver {
>  #define to_dfl_dev(d) container_of(d, struct dfl_device, dev)
>  #define to_dfl_drv(d) container_of(d, struct dfl_driver, drv)
>  
> +int dfl_dev_get_vendor_net_cfg(struct dfl_device *dfl_dev);
> +
>  /*
>   * use a macro to avoid include chaining to get THIS_MODULE.
>   */

[PATCH] ext4: properly check for dirty state in ext4_inode_datasync_dirty()

2020-10-24 Thread Andrea Righi

ext4_inode_datasync_dirty() needs to return 'true' if the inode is
dirty, 'false' otherwise, but the logic seems to be incorrectly changed
by commit aa75f4d3daae ("ext4: main fast-commit commit path").

This introduces a problem with swap files that are always failing to be
activated, showing this error in dmesg:

 [   34.406479] swapon: file is not committed

Simple test case to reproduce the problem:

  # fallocate -l 8G swapfile
  # chmod 0600 swapfile
  # mkswap swapfile
  # swapon swapfile

Fix the logic to return the proper state of the inode.

Link: https://lore.kernel.org/lkml/20201024131333.GA32124@xps-13-7390
Fixes: aa75f4d3daae ("ext4: main fast-commit commit path")
Signed-off-by: Andrea Righi 
---
 fs/ext4/inode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 03c2253005f0..a890a17ab7e1 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3308,8 +3308,8 @@ static bool ext4_inode_datasync_dirty(struct inode *inode)
if (journal) {
if (jbd2_transaction_committed(journal,
EXT4_I(inode)->i_datasync_tid))
-   return true;
-   return atomic_read(_SB(inode->i_sb)->s_fc_subtid) >=
+   return false;
+   return atomic_read(_SB(inode->i_sb)->s_fc_subtid) <
EXT4_I(inode)->i_fc_committed_subtid;
}
 
-- 
2.27.0

[no subject]

2020-10-24 Thread george mike

Hallo

Mein Name ist George Mike. Ich bin von Beruf Rechtsanwalt. Ich möchte
Ihnen anbieten
der nächste Verwandte meines Klienten. Sie erben die Summe von (8,5
Millionen US-Dollar)
Dollar, die mein Kunde vor seinem Tod auf der Bank gelassen hat.

Mein Kunde ist ein Staatsbürger Ihres Landes, der mit seiner Frau bei
einem Autounfall ums Leben gekommen ist
und einziger Sohn. Ich habe Anspruch auf 50% des Gesamtfonds, 50% darauf
sein für dich.
Bitte kontaktieren Sie meine private E-Mail hier für weitere
Informationen: georgemike7...@gmail.com

Vielen Dank im Voraus,
Mr. George Mike,

[PATCH 2/2] mailbox: stm32-ipcc: remove duplicate error message

2020-10-24 Thread Martin Kaiser

platform_get_irq_byname already prints an error message if the requested irq
was not found. Don't print another message in the driver.

Signed-off-by: Martin Kaiser 
---
 drivers/mailbox/stm32-ipcc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mailbox/stm32-ipcc.c b/drivers/mailbox/stm32-ipcc.c
index ef966887aa15..ab8fe56af948 100644
--- a/drivers/mailbox/stm32-ipcc.c
+++ b/drivers/mailbox/stm32-ipcc.c
@@ -257,9 +257,6 @@ static int stm32_ipcc_probe(struct platform_device *pdev)
for (i = 0; i < IPCC_IRQ_NUM; i++) {
ipcc->irqs[i] = platform_get_irq_byname(pdev, irq_name[i]);
if (ipcc->irqs[i] < 0) {
-   if (ipcc->irqs[i] != -EPROBE_DEFER)
-   dev_err(dev, "no IRQ specified %s\n",
-   irq_name[i]);
ret = ipcc->irqs[i];
goto err_clk;
}
-- 
2.20.1

[PATCH 1/2] mailbox: stm32-ipcc: add COMPILE_TEST dependency

2020-10-24 Thread Martin Kaiser

This allows compiling the driver on architectures where the hardware is not
available. Most other mailbox drivers support this as well.

Signed-off-by: Martin Kaiser 
---

I used this for testing the trivial patch that removes the duplicate error
message. Also, compiling the driver on x86_64 worked without errors.

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

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 05b1009e2820..abbf5d67ffa2 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -201,7 +201,7 @@ config BCM_FLEXRM_MBOX
 
 config STM32_IPCC
tristate "STM32 IPCC Mailbox"
-   depends on MACH_STM32MP157
+   depends on MACH_STM32MP157 || COMPILE_TEST
help
  Mailbox implementation for STMicroelectonics STM32 family chips
  with hardware for Inter-Processor Communication Controller (IPCC)
-- 
2.20.1

Re: [RFC net-next 0/5] net: phy: add support for shared interrupts

On Sat, Oct 24, 2020 at 03:14:07PM +0300, Ioana Ciornei wrote:

> This RFC just contains the patches for phylib and a single driver -
> Atheros. The rest can be found on my Github branch here: TODO
> They will be submitted as a multi-part series once the merge window
> closes.
> 

It seems that I forgot to add a link to the Github branch. Here it is:

https://github.com/IoanaCiornei/linux/commits/phylib-shared-irq

Re

2020-10-24 Thread Geogiakendy

Dear beneficiary,

I am happy to let you know that we have successfully concluded the
deal two weeks ago. The total funds were successfully transferred to
the new bank account in Venezuela.

You are a good person and I appreciate your efforts and support during
the transactions. I have decided to compensate you with the total
amount of $800,000.00 USD.

I have deposited a total sum of$800,000.00 USD with the bank and I
have instructed my account officer in the bank to send the money to
you through ATM VISA CARD as soon as you contact her.Therefore you
should contact my account officer Mrs. Roselyne Johnson and instruct
her to send the $800,000.00 USD to you via ATM CARD.Contact Person:
Mrs. Roselyne Johnson.

E-Mail :(ccserviceor...@gmail.com)

Please note that I will move to Venezuela today through Emirate
airline and I may not be able to communicate with you soon because I
will be very busy in Venezuela.Remember to send your information to
her as sated below for easy communication with her.

a) Your Full Name ==
b) Your home country ===
c) Your Home Address =
d) Your phone number =

Please you should manage the money. it is a token of my appreciation
for your efforts and attempts to help me during the transaction. Also
you should remember to invest your money in a good business as we
discussed.

Best regards.
Mr.Phillips Umeh.

Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

2020-10-24 Thread Salvatore Mesoraca

On Sat, 24 Oct 2020 at 12:34, Topi Miettinen  wrote:
>
> On 23.10.2020 20.52, Salvatore Mesoraca wrote:
> > Hi,
> >
> > On Thu, 22 Oct 2020 at 23:24, Topi Miettinen  wrote:
> >> SARA looks interesting. What is missing is a prctl() to enable all W^X
> >> protections irrevocably for the current process, then systemd could
> >> enable it for services with MemoryDenyWriteExecute=yes.
> >
> > SARA actually has a procattr[0] interface to do just that.
> > There is also a library[1] to help using it.
>
> That means that /proc has to be available and writable at that point, so
> setting up procattrs has to be done before mount namespaces are set up.
> In general, it would be nice for sandboxing facilities in kernel if
> there would be a way to start enforcing restrictions only at next
> execve(), like setexeccon() for SELinux and aa_change_onexec() for
> AppArmor. Otherwise the exact order of setting up various sandboxing
> options can be very tricky to arrange correctly, since each option may
> have a subtle effect to the sandboxing features enabled later. In case
> of SARA, the operations done between shuffling the mount namespace and
> before execve() shouldn't be affected so it isn't important. Even if it
> did (a new sandboxing feature in the future would need trampolines or
> JIT code generation), maybe the procattr file could be opened early but
> it could be written closer to execve().

A new "apply on exec" procattr file seems reasonable and relatively easy to add.
As Kees pointed out, the main obstacle here is the fact that SARA is
not upstream :(

Salvatore

[GIT PULL] dma-mapping fixes for 5.10

The following changes since commit 270315b8235e3d10c2e360cff56c2f9e0915a252:

  Merge tag 'riscv-for-linus-5.10-mw0' of 
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux (2020-10-19 18:18:30 
-0700)

are available in the Git repository at:

  git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.10-1

for you to fetch changes up to 6857a5ebaabc5b9d989872700b4b71dd2a6d6453:

  dma-mapping: document dma_{alloc,free}_pages (2020-10-23 12:07:46 +0200)


dma-mapping fixes for 5.10:

 - document the new document dma_{alloc,free}_pages API
 - two fixups for the dma-mapping.h split


Christoph Hellwig (3):
  ARM/sa: add a missing include of dma-map-ops.h
  dma-mapping: move more functions to dma-map-ops.h
  dma-mapping: document dma_{alloc,free}_pages

 Documentation/core-api/dma-api.rst | 49 +-
 arch/arm/common/sa.c   |  2 +-
 include/linux/dma-map-ops.h| 23 ++
 include/linux/dma-mapping.h| 24 ---
 kernel/dma/remap.c |  2 +-
 5 files changed, 68 insertions(+), 32 deletions(-)

Re: [RFC PATCH 1/6] docs: networking: add the document for DFL Ether Group driver



On 10/23/20 1:45 AM, Xu Yilun wrote:
> This patch adds the document for DFL Ether Group driver.
>
> Signed-off-by: Xu Yilun 
> ---
>  .../networking/device_drivers/ethernet/index.rst   |   1 +
>  .../ethernet/intel/dfl-eth-group.rst   | 102 
> +
>  2 files changed, 103 insertions(+)
>  create mode 100644 
> Documentation/networking/device_drivers/ethernet/intel/dfl-eth-group.rst
>
> diff --git a/Documentation/networking/device_drivers/ethernet/index.rst 
> b/Documentation/networking/device_drivers/ethernet/index.rst
> index cbb75a18..eb7c443 100644
> --- a/Documentation/networking/device_drivers/ethernet/index.rst
> +++ b/Documentation/networking/device_drivers/ethernet/index.rst
> @@ -26,6 +26,7 @@ Contents:
> freescale/gianfar
> google/gve
> huawei/hinic
> +   intel/dfl-eth-group
> intel/e100
> intel/e1000
> intel/e1000e
> diff --git 
> a/Documentation/networking/device_drivers/ethernet/intel/dfl-eth-group.rst 
> b/Documentation/networking/device_drivers/ethernet/intel/dfl-eth-group.rst
> new file mode 100644
> index 000..525807e
> --- /dev/null
> +++ b/Documentation/networking/device_drivers/ethernet/intel/dfl-eth-group.rst
> @@ -0,0 +1,102 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +===
> +DFL device driver for Ether Group private feature on Intel(R) PAC N3000
> +===
> +
> +This is the driver for Ether Group private feature on Intel(R)
> +PAC (Programmable Acceleration Card) N3000.
> +
> +The Intel(R) PAC N3000 is a FPGA based SmartNIC platform for multi-workload
> +networking application acceleration. A simple diagram below to for the board:
> +
> + ++
> + |  FPGA  |
> +++   +---+   +---+  +--+  +---+   
> +--+
> +|QSFP|---|retimer|---|Line Side  |--|User logic|--|Host Side  |---|XL710 
> |
> +++   +---+   |Ether Group|  |  |  |Ether Group|   |Ethernet  
> |
> + |(PHY + MAC)|  |wiring &  |  |(MAC + PHY)|   
> |Controller|
> + +---+  |offloading|  +---+   
> +--+
> + |  +--+  |
> + ||
> + ++
> +
> +The FPGA is composed of FPGA Interface Module (FIM) and Accelerated Function
> +Unit (AFU). The FIM implements the basic functionalities for FPGA access,
> +management and reprograming, while the AFU is the FPGA reprogramable region 
> for
> +users.
> +
> +The Line Side & Host Side Ether Groups are soft IP blocks embedded in FIM. 
> They
The Line Side and Host Side Ether Groups are soft IP blocks embedded in the FIM.
> +are internally wire connected to AFU and communicate with AFU with MAC 
> packets.
are internally connected to the AFU and communicate with the AFU using MAC 
packets
> +The user logic is developed by the FPGA users and re-programmed to AFU,
The user logic is application dependent, supplied by the FPGA developer and 
used to reprogram the AFU.
> +providing the user defined wire connections between line side & host side 
> data
between Line Side and Host Side
> +interfaces, as well as the MAC layer offloading.
> +
> +There are 2 types of interfaces for the Ether Groups:
> +
> +1. The data interfaces connects the Ether Groups and the AFU, host has no
The data interface which connects
> +ability to control the data stream . So the FPGA is like a pipe between the
> +host ethernet controller and the retimer chip.
> +
> +2. The management interfaces connects the Ether Groups to the host, so host
The management interface which connects
> +could access the Ether Group registers for configuration and statistics
> +reading.
> +
> +The Intel(R) PAC N3000 could be programmed to various configurations (with
N3000 can be
> +different link numbers and speeds, e.g. 8x10G, 4x25G ...). It is done by
This is done
> +programing different variants of the Ether Group IP blocks, and doing
> +corresponding configuration to the retimer chips.
programming different variants of the Ether Group IP blocks and retimer 
configuration.
> +
> +The DFL Ether Group driver registers netdev for each line side link. Users
registers a netdev
> +could use standard commands (ethtool, ip, ifconfig) for configuration and
> +link state/statistics reading. For host side links, they are always connected
> +to the host ethernet controller, so they should always have same features as
> +the host ethernet controller. There is no need to register netdevs for them.
> +The driver just enables these links on probe.
> +
> +The retimer chips are managed by onboard BMC (Board Management Controller)
> +firmware, host driver is not capable to

Re: [RFC PATCH v3 7/9] ipu3-cio2: Check if pci_dev->dev's fwnode is a software_node in cio2_parse_firmware() and set FWNODE_GRAPH_DEVICE_DISABLED if so

2020-10-24 Thread Sakari Ailus

On Sat, Oct 24, 2020 at 03:39:55AM +0300, Laurent Pinchart wrote:
> Hi Sakari
> 
> On Wed, Oct 21, 2020 at 01:49:10AM +0300, Sakari Ailus wrote:
> > On Tue, Oct 20, 2020 at 08:56:07PM +0100, Dan Scally wrote:
> > > On 20/10/2020 13:06, Sakari Ailus wrote:
> > > > On Tue, Oct 20, 2020 at 12:19:58PM +0300, Andy Shevchenko wrote:
> > > >> On Mon, Oct 19, 2020 at 11:59:01PM +0100, Daniel Scally wrote:
> > > >>> fwnode_graph_get_endpoint_by_id() will optionally parse enabled 
> > > >>> devices
> > > >>> only; that status being determined through the .device_is_available() 
> > > >>> op
> > > >>> of the device's fwnode. As software_nodes don't have that operation 
> > > >>> and
> > > >>> adding it is meaningless, we instead need to check if the device's 
> > > >>> fwnode
> > > >>> is a software_node and if so pass the appropriate flag to disable that
> > > >>> check
> > > >> Period.
> > > >>
> > > >> I'm wondering if actually this can be hidden in 
> > > >> fwnode_graph_get_endpoint_by_id().
> > > > The device availability test is actually there for a reason. Some 
> > > > firmware
> > > > implementations put all the potential devices in the tables and only one
> > > > (of some) of them are available.
> > > >
> > > > Could this be implemented so that if the node is a software node, then 
> > > > get
> > > > its parent and then see if that is available?
> > > >
> > > > I guess that could be implemented in software node ops. Any opinions?
> > > Actually when considering the cio2 device, it seems that
> > > set_secondary_fwnode() actually overwrites the _primary_, given
> > > fwnode_is_primary(dev->fwnode) returns false. So in at least some cases,
> > > this wouldn't work.
> > 
> > Ouch. I wonder when this happens --- have you checked what's the primary
> > there? I guess it might be if it's a PCI device without the corresponding
> > ACPI device node?
> > 
> > I remember you had an is_available implementation that just returned true
> > for software nodes in an early version of the set? I think it would still
> > be a lesser bad in this case.
> 
> How about the following ?

Looks good to me.

> 
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 81bd01ed4042..ea44ba846299 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -706,9 +706,14 @@ EXPORT_SYMBOL_GPL(fwnode_handle_put);
>  /**
>   * fwnode_device_is_available - check if a device is available for use
>   * @fwnode: Pointer to the fwnode of the device.
> + *
> + * For fwnode node types that don't implement the .device_is_available()
> + * operation, such as software nodes, this function returns true.
>   */
>  bool fwnode_device_is_available(const struct fwnode_handle *fwnode)
>  {
> + if (!fwnode_has_op(fwnode, device_is_available))
> + return true;
>   return fwnode_call_bool_op(fwnode, device_is_available);
>  }
>  EXPORT_SYMBOL_GPL(fwnode_device_is_available);
> 

-- 
Sakari Ailus

Re: [RFC PATCH 5/6] ethernet: dfl-eth-group: add DFL eth group private feature driver

2020-10-24 Thread Andrew Lunn

> +++ b/Documentation/ABI/testing/sysfs-class-net-dfl-eth-group
> @@ -0,0 +1,19 @@
> +What:/sys/class/net//tx_pause_frame_quanta
> +Date:Oct 2020
> +KernelVersion:   5.11
> +Contact: Xu Yilun 
> +Description:
> + Read-Write. Value representing the tx pause quanta of Pause
> + flow control frames to be sent to remote partner. Read the file
> + for the actual tx pause quanta value. Write the file to set
> + value of the tx pause quanta.
> +

Is this really configuring the quanta? My very limited understanding
is that the quanta is defined as 512 bit times. For this to work, you
are going to have to modify the quanta on both ends of the link,
otherwise increasing the quanta is actually going to shorten the pause
time.

> +What:/sys/class/net//tx_pause_frame_holdoff
> +Date:Oct 2020
> +KernelVersion:   5.11
> +Contact: Xu Yilun 
> +Description:
> + Read-Write. Value representing the separation between 2
> + consecutive XOFF flow control frames. Read the file for the
> + actual separation value. Write the file to set value of the
> + separation.

This is the wrong API for this. Please extend the ethtool -A|--pause
API. Now that it is netlink, adding extra attributes should be simple.

Andrew

Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()

2020-10-24 Thread Dr. Greg

On Tue, Oct 20, 2020 at 09:40:00AM -0700, Sean Christopherson wrote:

Good morning, I hope the week has gone well for everyone.

> On Tue, Oct 20, 2020 at 05:01:18AM -0500, Dr. Greg wrote:
> >
> > With respect to the security issue at hand, the only relevant issue
> > would seem to be if a page had write permissions at one time in its
> > trajectory to having execute permisions, isn't this correct?

> No.  RW->RX has different properties than RWX.  E.g. an enclave that
> dynamically loads code is not the same thing as an enclave that
> allows simultaneously writing and executing a page.

Yes, it is certainly correct that a platform administrator may want to
restrict RWX, given that it makes an enclave susceptible to potential
arbitrary code execution if there is a programming error in the
enclave.

However, I think it is important for everyone interested in these
issues, to reflect back on what started all of this and that was
Andy's concern that the initial incantations of the driver allowed
execution of arbitrary memory without the ability of the LSM to get a
'look' at the code/memory.

My point in all of this is that a permissions trajectory for an
enclave that allows for write permissions on a path that terminates in
X permissions opens the door for arbitrary memory execution that the
platform security architect has no insight into or that the LSM will
have any control over.

There is no guarantee that dynamically loaded code has to come into
the enclave via anything that the operating system has visibility
into.  If the enclave can toggle RW->RX it is free to dynamically load
code, in encrypted form over the network and then execute it.

In fact, I would posit that this model will be a primary use for
dynamic code loading.  The SGX user community views 'confidential
computing' as much about protecting visibility into algorithms and
code as it is about data that is being operated on.  In certain
unnamed venues where I have consulted it is the primary concern.

So in the broadest sense, we have spent a year worrying about if and
how the LSM will have visibility into enclave based code and in the
end the only really relevant security mechanism available is limiting
page permission transitions that prevent dynamic code loading.  Modulo
of course the issue with RWX, where a platform owner may elect to try
and prevent an enclave writer from shooting themselves in the foot.

The issue at hand is that the primary security threat of the
technology is the same as what the user community wants to use it for.
Joanna Rutkowska called that out a half decade ago when she first
reviewed the technology.

> > The next paragraph of my reply wasn't included in your reply, but I
> > did state that the mprotect hook would be relevant if its purpose was
> > to disallow this permission trajectory and in the process disable
> > enclave dynamic code loading and execution.
> > 
> > So to assist everyone in understanding this issue and the security
> > implications involved, is the ultimate purpose of the mprotect hook to
> > disable dynamic code loading?

> No, it's to provide line of sight to enforcing granular LSM checks
> on enclave pages.  Jumping back to the RWX thing, as a defense in
> depth measure, a policy owner could set an SELinux policy to never
> allow RWX, even for enclaves that dynamically load code.
>
> Whether or not having per-page granluarity on enclave permission
> checks is valuable/interesting is debatable, e.g. it's why LSM
> integration is notably absent from the this series.  But, adding the
> ->mprotect() hook is relatively cheap and can always be removed if
> it's deemed unnecessary in the long run.  The reverse is not true;
> omitting ->mprotect() commits the kernel to an ABI that is either
> ugly and potentially painful (require all enclaves to declare full
> RWX permissions), or flat out prevents adding granular LSM support
> in the future (do nothing).

I believe your analysis with respect to the ability to remove
->mprotect is flawed.  The long standing consensus has been that
functionality never gets broken.  Once ->mprotect is a component of
the ABI it would have to be left intact since it could potentially
break things that elected to use it.  On the other hand there is a
long standing history of adding functionality.

I can't bring myself to believe that LSM's are going to be written
that will be making enclave security decisions on a page by page
basis.  Given what I have written above, I think all of this comes
down to giving platform administrators one of three decisions, in
order of most to least secure:

1.) Block dynamic code loading and execution.

2.) Block access to RWX pages.

3.) The wild west - no restrictions on enclave page protection manipulation.

>From a security perspective I would argue for the wisdom of making
option 1 unconditional via a kernel command-line parameter.

It may be that ->mprotect is the right mechanism to implement this.
If that is the case, frame the

Re: [RFC PATCH 3/6] fpga: dfl: add an API to get the base device for dfl device



On 10/23/20 1:45 AM, Xu Yilun wrote:
> This patch adds an API for dfl devices to find which physical device
> owns the DFL.
>
> This patch makes preparation for supporting DFL Ether Group private
> feature driver. It uses this information to determine which retimer
> device physically connects to which ether group.
device is physically
>
> Signed-off-by: Xu Yilun 
> ---
>  drivers/fpga/dfl.c  | 9 +
>  include/linux/dfl.h | 1 +
>  2 files changed, 10 insertions(+)
>
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index ca3c678..52d18e6 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -558,6 +558,15 @@ int dfl_dev_get_vendor_net_cfg(struct dfl_device 
> *dfl_dev)
>  }
>  EXPORT_SYMBOL_GPL(dfl_dev_get_vendor_net_cfg);
>  
> +struct device *dfl_dev_get_base_dev(struct dfl_device *dfl_dev)
> +{
> + if (!dfl_dev || !dfl_dev->cdev)
> + return NULL;
> +
> + return dfl_dev->cdev->parent;
> +}
> +EXPORT_SYMBOL_GPL(dfl_dev_get_base_dev);

This name is awkward. maybe

dfl_dev_parent() or dfl_dev_base()


> +
>  #define is_header_feature(feature) ((feature)->id == FEATURE_ID_FIU_HEADER)
>  
>  /**
> diff --git a/include/linux/dfl.h b/include/linux/dfl.h
> index 5ee2b1e..dd313f2 100644
> --- a/include/linux/dfl.h
> +++ b/include/linux/dfl.h
> @@ -68,6 +68,7 @@ struct dfl_driver {
>  #define to_dfl_drv(d) container_of(d, struct dfl_driver, drv)
>  
>  int dfl_dev_get_vendor_net_cfg(struct dfl_device *dfl_dev);
> +struct device *dfl_dev_get_base_dev(struct dfl_device *dfl_dev);

Because this is an external interface these should have comments

This is another generic change and should be split out of the patchset.

I believe the generic changes would have an easier time being accepted and 
could be done in parallel as the harder part of the private features is worked 
out.

Tom

>  
>  /*
>   * use a macro to avoid include chaining to get THIS_MODULE.

Re: [PATCH] arch/Kconfig: fix a few trivial spelling mistakes in Kconfig

2020-10-24 Thread Randy Dunlap

On 10/24/20 5:55 AM, Colin King wrote:
> From: Colin Ian King 
> 
> There are a couple of trivial spelling mistakes, fix these.
> 
> Signed-off-by: Colin Ian King 

Acked-by: Randy Dunlap 

Thanks.

> ---
>  arch/Kconfig | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 56b6ccc0e32d..ce4e84366418 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -261,7 +261,7 @@ config ARCH_HAS_SET_DIRECT_MAP
>  
>  #
>  # Select if the architecture provides the arch_dma_set_uncached symbol to
> -# either provide an uncached segement alias for a DMA allocation, or
> +# either provide an uncached segment alias for a DMA allocation, or
>  # to remap the page tables in place.
>  #
>  config ARCH_HAS_DMA_SET_UNCACHED
> @@ -314,14 +314,14 @@ config ARCH_32BIT_OFF_T
>  config HAVE_ASM_MODVERSIONS
>   bool
>   help
> -   This symbol should be selected by an architecure if it provides
> +   This symbol should be selected by an architecture if it provides
>  to support the module versioning for symbols
> exported from assembly code.
>  
>  config HAVE_REGS_AND_STACK_ACCESS_API
>   bool
>   help
> -   This symbol should be selected by an architecure if it supports
> +   This symbol should be selected by an architecture if it supports
> the API needed to access registers and stack entries from pt_regs,
> declared in asm/ptrace.h
> For example the kprobes-based event tracer needs this API.
> @@ -336,7 +336,7 @@ config HAVE_RSEQ
>  config HAVE_FUNCTION_ARG_ACCESS_API
>   bool
>   help
> -   This symbol should be selected by an architecure if it supports
> +   This symbol should be selected by an architecture if it supports
> the API needed to access function arguments from pt_regs,
> declared in asm/ptrace.h
>  
> 


-- 
~Randy

Re: [PATCH 1/2] Block layer filter - second version

2020-10-24 Thread Greg KH

On Wed, Oct 21, 2020 at 12:04:08PM +0300, Sergei Shtepa wrote:
> Signed-off-by: Sergei Shtepa 

I know I don't take patches without any changelog text.

Maybe some maintainers are more lax...

Also, "second version" doesn't belong in the subject line, the
documentation shows how to properly version patch series, please do
that.

thanks,

greg k-h

> ---
>  block/Kconfig   |  11 ++
>  block/Makefile  |   1 +
>  block/blk-core.c|  52 +--
>  block/blk-filter-internal.h |  29 
>  block/blk-filter.c  | 286 
>  block/partitions/core.c |  14 +-
>  fs/block_dev.c  |   6 +-
>  fs/direct-io.c  |   2 +-
>  fs/iomap/direct-io.c|   2 +-
>  include/linux/bio.h |   4 +-
>  include/linux/blk-filter.h  |  76 ++
>  include/linux/genhd.h   |   8 +-
>  kernel/power/swap.c |   2 +-
>  mm/page_io.c|   4 +-
>  14 files changed, 471 insertions(+), 26 deletions(-)
>  create mode 100644 block/blk-filter-internal.h
>  create mode 100644 block/blk-filter.c
>  create mode 100644 include/linux/blk-filter.h
> 
> diff --git a/block/Kconfig b/block/Kconfig
> index bbad5e8bbffe..a308801b4376 100644
> --- a/block/Kconfig
> +++ b/block/Kconfig
> @@ -204,6 +204,17 @@ config BLK_INLINE_ENCRYPTION_FALLBACK
> by falling back to the kernel crypto API when inline
> encryption hardware is not present.
>  
> +config BLK_FILTER
> + bool "Enable support for block layer filters"
> + default y
> + depends on MODULES
> + help
> +   Enabling this lets third-party kernel modules intercept
> +   bio requests for any block device. This allows them to implement
> +   changed block tracking and snapshots without any reconfiguration of
> +   the existing setup. For example, this option allows snapshotting of
> +   a block device without adding it to LVM.
> +
>  menu "Partition Types"
>  
>  source "block/partitions/Kconfig"
> diff --git a/block/Makefile b/block/Makefile
> index 8d841f5f986f..b8ee50b8e031 100644
> --- a/block/Makefile
> +++ b/block/Makefile
> @@ -38,3 +38,4 @@ obj-$(CONFIG_BLK_SED_OPAL)  += sed-opal.o
>  obj-$(CONFIG_BLK_PM) += blk-pm.o
>  obj-$(CONFIG_BLK_INLINE_ENCRYPTION)  += keyslot-manager.o blk-crypto.o
>  obj-$(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) += blk-crypto-fallback.o
> +obj-$(CONFIG_BLK_FILTER) += blk-filter.o
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 10c08ac50697..cc06402af695 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1216,23 +1216,20 @@ blk_qc_t submit_bio_noacct(struct bio *bio)
>  EXPORT_SYMBOL(submit_bio_noacct);
>  
>  /**
> - * submit_bio - submit a bio to the block device layer for I/O
> - * @bio: The  bio which describes the I/O
> - *
> - * submit_bio() is used to submit I/O requests to block devices.  It is 
> passed a
> - * fully set up  bio that describes the I/O that needs to be done.  
> The
> - * bio will be send to the device described by the bi_disk and bi_partno 
> fields.
> + * submit_bio_direct - submit a bio to the block device layer for I/O
> + * bypass filter.
> + * @bio:  The bio describing the location in memory and on the device.
>   *
> - * The success/failure status of the request, along with notification of
> - * completion, is delivered asynchronously through the ->bi_end_io() callback
> - * in @bio.  The bio must NOT be touched by thecaller until ->bi_end_io() has
> - * been called.
> + * Description:
> + *This is a version of submit_bio() that shall only be used for I/O
> + *that cannot be intercepted by block layer filters.
> + *All file systems and other upper level users of the block layer
> + *should use submit_bio() instead.
> + *Use this function to access the swap partition and directly access
> + *the block device file.
>   */
> -blk_qc_t submit_bio(struct bio *bio)
> +blk_qc_t submit_bio_direct(struct bio *bio)
>  {
> - if (blkcg_punt_bio_submit(bio))
> - return BLK_QC_T_NONE;
> -
>   /*
>* If it's a regular read/write or a barrier with data attached,
>* go through the normal accounting stuff before submission.
> @@ -1282,8 +1279,35 @@ blk_qc_t submit_bio(struct bio *bio)
>  
>   return submit_bio_noacct(bio);
>  }
> +EXPORT_SYMBOL(submit_bio_direct);
> +
> +/**
> + * submit_bio - submit a bio to the block device layer for I/O
> + * @bio: The  bio which describes the I/O
> + *
> + * submit_bio() is used to submit I/O requests to block devices.  It is 
> passed a
> + * fully set up  bio that describes the I/O that needs to be done.  
> The
> + * bio will be send to the device described by the bi_disk and bi_partno 
> fields.
> + *
> + * The success/failure status of the request, along with notification of
> + * completion, is delivered asynchronously through the ->bi_end_io() callback
> + * in @bio.  The bio must NOT be touched by thecaller until ->bi_end_io() has

[PATCH] net/sunrpc: Fix return value from proc_do_xprt()

2020-10-24 Thread Alex Dewar

Commit c09f56b8f68d ("net/sunrpc: Fix return value for sysctl
sunrpc.transports") attempted to add error checking for the call to
memory_read_from_buffer(), however its return value was assigned to a
size_t variable, so any negative values would be lost in the cast. Fix
this.

Addresses-Coverity-ID: 1498033: Control flow issues (NO_EFFECT)
Fixes: c09f56b8f68d ("net/sunrpc: Fix return value for sysctl 
sunrpc.transports")
Signed-off-by: Alex Dewar 
---
 net/sunrpc/sysctl.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/sunrpc/sysctl.c b/net/sunrpc/sysctl.c
index a18b36b5422d..c95a2b84dd95 100644
--- a/net/sunrpc/sysctl.c
+++ b/net/sunrpc/sysctl.c
@@ -62,6 +62,7 @@ rpc_unregister_sysctl(void)
 static int proc_do_xprt(struct ctl_table *table, int write,
void *buffer, size_t *lenp, loff_t *ppos)
 {
+   ssize_t bytes_read;
char tmpbuf[256];
size_t len;
 
@@ -70,12 +71,14 @@ static int proc_do_xprt(struct ctl_table *table, int write,
return 0;
}
len = svc_print_xprts(tmpbuf, sizeof(tmpbuf));
-   *lenp = memory_read_from_buffer(buffer, *lenp, ppos, tmpbuf, len);
+   bytes_read = memory_read_from_buffer(buffer, *lenp, ppos, tmpbuf, len);
 
-   if (*lenp < 0) {
+   if (bytes_read < 0) {
*lenp = 0;
return -EINVAL;
}
+
+   *lenp = bytes_read;
return 0;
 }
 
-- 
2.29.1

Re: [RFC PATCH 4/6] ethernet: m10-retimer: add support for retimers on Intel MAX 10 BMC