Re: [PATCH v2 2/2] iommu/iova: Free global iova rcache on iova alloc failure

[Vijayanand Jitta]

On 9/28/2020 6:11 PM, Vijayanand Jitta wrote:
> 
> 
> On 9/18/2020 8:11 PM, Robin Murphy wrote:
>> On 2020-08-20 13:49, vji...@codeaurora.org wrote:
>>> From: Vijayanand Jitta 
>>>
>>> When ever an iova alloc request fails we free the iova
>>> ranges present in the percpu iova rcaches and then retry
>>> but the global iova rcache is not freed as a result we could
>>> still see iova alloc failure even after retry as global
>>> rcache is holding the iova's which can cause fragmentation.
>>> So, free the global iova rcache as well and then go for the
>>> retry.
>>>
>>> Signed-off-by: Vijayanand Jitta 
>>> ---
>>>   drivers/iommu/iova.c | 23 +++
>>>   include/linux/iova.h |  6 ++
>>>   2 files changed, 29 insertions(+)
>>>
>>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>>> index 4e77116..5836c87 100644
>>> --- a/drivers/iommu/iova.c
>>> +++ b/drivers/iommu/iova.c
>>> @@ -442,6 +442,7 @@ struct iova *find_iova(struct iova_domain *iovad,
>>> unsigned long pfn)
>>>   flush_rcache = false;
>>>   for_each_online_cpu(cpu)
>>>   free_cpu_cached_iovas(cpu, iovad);
>>> +    free_global_cached_iovas(iovad);
>>>   goto retry;
>>>   }
>>>   @@ -1055,5 +1056,27 @@ void free_cpu_cached_iovas(unsigned int cpu,
>>> struct iova_domain *iovad)
>>>   }
>>>   }
>>>   +/*
>>> + * free all the IOVA ranges of global cache
>>> + */
>>> +void free_global_cached_iovas(struct iova_domain *iovad)
>>
>> As John pointed out last time, this should be static and the header
>> changes dropped.
>>
>> (TBH we should probably register our own hotplug notifier instance for a
>> flush queue, so that external code has no need to poke at the per-CPU
>> caches either)
>>
>> Robin.
>>
> 
> Right, I have made it static and dropped header changes in v3.
> can you please review that.
> 
> Thanks,
> Vijay

Please review v4 instead of v3, I have updated other patch as well in v4.

Thanks,
Vijay
>>> +{
>>> +    struct iova_rcache *rcache;
>>> +    unsigned long flags;
>>> +    int i, j;
>>> +
>>> +    for (i = 0; i < IOVA_RANGE_CACHE_MAX_SIZE; ++i) {
>>> +    rcache = >rcaches[i];
>>> +    spin_lock_irqsave(>lock, flags);
>>> +    for (j = 0; j < rcache->depot_size; ++j) {
>>> +    iova_magazine_free_pfns(rcache->depot[j], iovad);
>>> +    iova_magazine_free(rcache->depot[j]);
>>> +    rcache->depot[j] = NULL;
>>> +    }
>>> +    rcache->depot_size = 0;
>>> +    spin_unlock_irqrestore(>lock, flags);
>>> +    }
>>> +}
>>> +
>>>   MODULE_AUTHOR("Anil S Keshavamurthy ");
>>>   MODULE_LICENSE("GPL");
>>> diff --git a/include/linux/iova.h b/include/linux/iova.h
>>> index a0637ab..a905726 100644
>>> --- a/include/linux/iova.h
>>> +++ b/include/linux/iova.h
>>> @@ -163,6 +163,7 @@ int init_iova_flush_queue(struct iova_domain *iovad,
>>>   struct iova *split_and_remove_iova(struct iova_domain *iovad,
>>>   struct iova *iova, unsigned long pfn_lo, unsigned long pfn_hi);
>>>   void free_cpu_cached_iovas(unsigned int cpu, struct iova_domain
>>> *iovad);
>>> +void free_global_cached_iovas(struct iova_domain *iovad);
>>>   #else
>>>   static inline int iova_cache_get(void)
>>>   {
>>> @@ -270,6 +271,11 @@ static inline void free_cpu_cached_iovas(unsigned
>>> int cpu,
>>>    struct iova_domain *iovad)
>>>   {
>>>   }
>>> +
>>> +static inline void free_global_cached_iovas(struct iova_domain *iovad)
>>> +{
>>> +}
>>> +
>>>   #endif
>>>     #endif
>>>
> 

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 4/5] iio: adc: vf610_adc: Replace indio_dev->mlock with own device lock

[Alexandru Ardelean]

On Tue, Sep 29, 2020 at 7:15 PM Jonathan Cameron  wrote:
>
> On Mon, 28 Sep 2020 16:13:32 +0300
> Mircea Caprioru  wrote:
>
> > From: Sergiu Cuciurean 
> >
> > As part of the general cleanup of indio_dev->mlock, this change replaces
> > it with a local lock on the device's state structure.
> >
> > This is part of a bigger cleanup.
> > Link: 
> > https://lore.kernel.org/linux-iio/CA+U=dsoo6yabe5odlp+efnpgfdjk5zeqecegkqjxxcvehlw...@mail.gmail.com/
> >
> > Signed-off-by: Sergiu Cuciurean 
> > Signed-off-by: Mircea Caprioru 
>
> There are more problems in the locking in here than just this one.
> See below.  The taking of mlock like this was what originally motivated
> the efforts to hide it away from drivers.
>
> In this particular case I don't think a local lock is the correct solution.
>
> Thanks,
>
> Jonathan
>
>
> > ---
> >  drivers/iio/adc/vf610_adc.c | 28 
> >  1 file changed, 20 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
> > index 1d794cf3e3f1..b7d583993f0b 100644
> > --- a/drivers/iio/adc/vf610_adc.c
> > +++ b/drivers/iio/adc/vf610_adc.c
> > @@ -168,6 +168,15 @@ struct vf610_adc {
> >
> >   struct completion completion;
> >   u16 buffer[8];
>
> Side note.  That buffer isn't correctly aligned.  I'll add this one to
> my next series fixing those.
>
> > + /*
> > +  * Lock to protect the device state during a potential concurrent
> > +  * read access from userspace. Reading a raw value requires a sequence
> > +  * of register writes, then a wait for a completion callback,
> > +  * and finally a register read, during which userspace could issue
> > +  * another read request. This lock protects a read access from
> > +  * ocurring before another one has finished.
> > +  */
> > + struct mutex lock;
> >  };
> >
> >  static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
> > @@ -464,11 +473,11 @@ static int vf610_set_conversion_mode(struct iio_dev 
> > *indio_dev,
> >  {
> >   struct vf610_adc *info = iio_priv(indio_dev);
> >
> > - mutex_lock(_dev->mlock);
> > + mutex_lock(>lock);
> Hmm. So there is a bit of a question on what the locking here is doing.
> (see below for a different use of mlock).
>
> What it will do currently is to prevent the conversion mode changing whilst
> we are in buffered mode.  It will also protect against concurrent
> calls of this function.
>
> I would replace this with iio_device_claim_direct_mode() rather than a
> local lock.

This raises a new question: if there's any drivers that we missed [for
iio_device_claim_direct_mode()].
While I was aware of iio_device_claim_direct_mode(), I missed this
fact when pushing the mlock cleanup.

Oh well, I'll do a quick audit over the current drivers that were converted.
Hopefully I don't find anything :P

>
> >   info->adc_feature.conv_mode = mode;
> >   vf610_adc_calculate_rates(info);
> >   vf610_adc_hw_init(info);
> > - mutex_unlock(_dev->mlock);
> > + mutex_unlock(>lock);
> >
> >   return 0;
> >  }
> > @@ -632,9 +641,9 @@ static int vf610_read_raw(struct iio_dev *indio_dev,
> >   switch (mask) {
> >   case IIO_CHAN_INFO_RAW:
> >   case IIO_CHAN_INFO_PROCESSED:
> > - mutex_lock(_dev->mlock);
> > + mutex_lock(>lock);
> >   if (iio_buffer_enabled(indio_dev)) {
> > - mutex_unlock(_dev->mlock);
> > + mutex_unlock(>lock);
>
> Should be use iio_device_claim_direct_mode()
>
> mlock is being taken here to stop us entering buffered mode.
>
> Whilst I'd rather a driver didn't rely on internal details of
> IIO, it is rather fiddly to get the locking right when there is a completion
> going on, so I think here you are safe to do so.
>
> >   return -EBUSY;
> >   }
> >
> > @@ -645,11 +654,11 @@ static int vf610_read_raw(struct iio_dev *indio_dev,
> >   ret = wait_for_completion_interruptible_timeout
> >   (>completion, VF610_ADC_TIMEOUT);
> >   if (ret == 0) {
> > - mutex_unlock(_dev->mlock);
> > + mutex_unlock(>lock);
> >   return -ETIMEDOUT;
> >   }
> >   if (ret < 0) {
> > - mutex_unlock(_dev->mlock);
> > + mutex_unlock(>lock);
> >   return ret;
> >   }
> >
> > @@ -668,11 +677,11 @@ static int vf610_read_raw(struct iio_dev *indio_dev,
> >
> >   break;
> >   default:
> > - mutex_unlock(_dev->mlock);
> > + mutex_unlock(>lock);
> >   return -EINVAL;
> >   }
> >
> > - mutex_unlock(_dev->mlock);
> > + mutex_unlock(>lock);
> >   return IIO_VAL_INT;
> >
> >   case IIO_CHAN_INFO_SCALE:
> > @@ -807,6 +816,9 @@ static int 

Re: [PATCH v2 3/3] iommu/tegra-smmu: Add PCI support

[Dmitry Osipenko]

30.09.2020 08:29, Nicolin Chen пишет:
> Hi Dmitry,
> 
> On Wed, Sep 30, 2020 at 08:10:07AM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 03:30, Nicolin Chen пишет:
>>> -   group->group = iommu_group_alloc();
>>> +   group->group = pci ? pci_device_group(dev) : iommu_group_alloc();
>>
>> This will be nicer to write as:
>>
>> if (dev_is_pci(dev))
>> group->group = pci_device_group(dev);
>> else
>> group->group = generic_device_group(dev);
> 
> Why is that nicer? I don't feel mine is hard to read at all...
> 

Previously you said that you're going to add USB support, so I assume
there will be something about USB.

It's also a kinda common style that majority of Tegra drivers use in
upstream kernel. But yours variant is good too if there won't be a need
to change it later on.

[PATCH v2 2/4] iio: adc: at91_adc: const-ify some driver data

[Alexandru Ardelean]

The main intent is to get rid of the cast for the void-pointer returned by
of_device_get_match_data().

This requires const-ifying the 'caps' and 'registers' references on the
at91_adc_state struct.

The caps can be obtained also from the old platform_data (in the
at91_adc_probe_pdata() function), but that cast is not touched in this
patch, since the old platform_data should be removed/cleaned-away.
Also, that cast deals with converting a kernel_ulong_t type to a pointer.
So, updating that cast doesn't yield any benefit.

Signed-off-by: Alexandru Ardelean 
---
 drivers/iio/adc/at91_adc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index c9ec0a4a357e..7d846a2852a5 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -202,7 +202,7 @@ struct at91_adc_state {
struct mutexlock;
u8  num_channels;
void __iomem*reg_base;
-   struct at91_adc_reg_desc *registers;
+   const struct at91_adc_reg_desc *registers;
u32 startup_time;
u8  sample_hold_time;
boolsleep_mode;
@@ -214,7 +214,7 @@ struct at91_adc_state {
u32 res;/* resolution used for 
convertions */
boollow_res;/* the resolution corresponds 
to the lowest one */
wait_queue_head_t   wq_data_avail;
-   struct at91_adc_caps*caps;
+   const struct at91_adc_caps  *caps;
 
/*
 * Following ADC channels are shared by touchscreen:
@@ -550,7 +550,7 @@ static int at91_adc_configure_trigger(struct iio_trigger 
*trig, bool state)
 {
struct iio_dev *idev = iio_trigger_get_drvdata(trig);
struct at91_adc_state *st = iio_priv(idev);
-   struct at91_adc_reg_desc *reg = st->registers;
+   const struct at91_adc_reg_desc *reg = st->registers;
u32 status = at91_adc_readl(st, reg->trigger_register);
int value;
u8 bit;
@@ -876,7 +876,7 @@ static int at91_adc_probe_dt(struct iio_dev *idev,
if (!node)
return -EINVAL;
 
-   st->caps = (struct at91_adc_caps *)of_device_get_match_data(>dev);
+   st->caps = of_device_get_match_data(>dev);
 
st->use_external = of_property_read_bool(node, 
"atmel,adc-use-external-triggers");
 
-- 
2.17.1

[PATCH v2 3/4] iio: adc: at91_adc: add Kconfig dependency on the OF symbol

[Alexandru Ardelean]

This tries to solve a warning reported by the lkp bot:

>> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable
>> 'at91_adc_dt_ids' [-Wunused-const-variable]
   static const struct of_device_id at91_adc_dt_ids[] = {
^
   1 warning generated.

This shows up with 'compiler: clang version 12.0.0' and W=1 (as the bot
mentions).

Forward declarations for global variables can be a bit weird; forward
function declarations are more common.

Maybe another fix for this would have been to prefix with 'extern' the
'at91_adc_dt_ids' variable, thus making it more friendly as a forward
declaration. It would look weird, but it would work.

But, we can avoid that forward declaration altogether simply by obtaining
the private data with of_device_get_match_data().

This appeared after commit 4027860dcc4c ("iio: Kconfig: at91_adc: add
COMPILE_TEST dependency to driver"), which put this driver on the lkp's bot
radar.

Fixes: 4027860dcc4c ("iio: Kconfig: at91_adc: add COMPILE_TEST dependency to 
driver")
Reported-by: kernel test robot 
Signed-off-by: Alexandru Ardelean 
---
 drivers/iio/adc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 91ae90514aff..17e9ceb9c6c4 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -295,7 +295,7 @@ config ASPEED_ADC
 config AT91_ADC
tristate "Atmel AT91 ADC"
depends on ARCH_AT91 || COMPILE_TEST
-   depends on INPUT && SYSFS
+   depends on INPUT && SYSFS && OF
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
help
-- 
2.17.1

[PATCH v2 0/4] iio: adc: at91: misc driver cleanups

[Alexandru Ardelean]

This whole thing started because the lkp bot haunted me for a while with
this build warning:

>> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable
>> 'at91_adc_dt_ids' [-Wunused-const-variable]
   static const struct of_device_id at91_adc_dt_ids[] = {
^
   1 warning generated.

The fix may likely be patch 'iio: adc: at91_adc: add Kconfig dependency
on the OF symbol'; was pointed out by Jonathan.

Changelog v1 -> v2:
- 
https://lore.kernel.org/linux-iio/CA+U=dspd11n-pxxnny_5csznp50irr7h16zxtcxo8fk+v48...@mail.gmail.com/T/#m7c0efef4dc623776fe8bafdb5f734b0eaca50f82
- for patch 'iio: adc: at91_adc: use of_device_get_match_data() helper'
  changed description; it's just tidy-up patch, not a fix
- added 2 more patches:
  - iio: adc: at91_adc: add Kconfig dependency on the OF symbol
  - iio: adc: at91_adc: remove of_match_ptr() usage

Alexandru Ardelean (4):
  iio: adc: at91_adc: use of_device_get_match_data() helper
  iio: adc: at91_adc: const-ify some driver data
  iio: adc: at91_adc: add Kconfig dependency on the OF symbol
  iio: adc: at91_adc: remove of_match_ptr() usage

 drivers/iio/adc/Kconfig|  2 +-
 drivers/iio/adc/at91_adc.c | 13 +
 2 files changed, 6 insertions(+), 9 deletions(-)

-- 
2.17.1

[PATCH v2 4/4] iio: adc: at91_adc: remove of_match_ptr() usage

[Alexandru Ardelean]

Since the driver should be allowed to build without OF support, the
of_match_ptr() is redundant.

Signed-off-by: Alexandru Ardelean 
---
 drivers/iio/adc/at91_adc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 7d846a2852a5..473bffe84fbd 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -1466,7 +1466,7 @@ static struct platform_driver at91_adc_driver = {
.id_table = at91_adc_ids,
.driver = {
   .name = DRIVER_NAME,
-  .of_match_table = of_match_ptr(at91_adc_dt_ids),
+  .of_match_table = at91_adc_dt_ids,
   .pm = _adc_pm_ops,
},
 };
-- 
2.17.1

[PATCH v2 1/4] iio: adc: at91_adc: use of_device_get_match_data() helper

[Alexandru Ardelean]

This is a small tidy-up. The of_device_get_match_data() helper retrieves
the driver data from the OF table, without needed to explicitly know the
table variable (since it can retrieve it from the driver object).

Signed-off-by: Alexandru Ardelean 
---
 drivers/iio/adc/at91_adc.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 9b2c548fae95..c9ec0a4a357e 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -829,8 +829,6 @@ static u32 calc_startup_ticks_9x5(u32 startup_time, u32 
adc_clk_khz)
return ticks;
 }
 
-static const struct of_device_id at91_adc_dt_ids[];
-
 static int at91_adc_probe_dt_ts(struct device_node *node,
struct at91_adc_state *st, struct device *dev)
 {
@@ -878,8 +876,7 @@ static int at91_adc_probe_dt(struct iio_dev *idev,
if (!node)
return -EINVAL;
 
-   st->caps = (struct at91_adc_caps *)
-   of_match_device(at91_adc_dt_ids, >dev)->data;
+   st->caps = (struct at91_adc_caps *)of_device_get_match_data(>dev);
 
st->use_external = of_property_read_bool(node, 
"atmel,adc-use-external-triggers");
 
-- 
2.17.1

Re: [PATCH v2 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Nicolin Chen]

On Wed, Sep 30, 2020 at 08:20:50AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 08:10, Dmitry Osipenko пишет:
> > 30.09.2020 03:30, Nicolin Chen пишет:
> >>  static void tegra_smmu_release_device(struct device *dev)
> > 
> > The tegra_get_memory_controller() uses of_find_device_by_node(), hence
> > tegra_smmu_release_device() should put_device(mc) in order to balance
> > back the refcounting.
> > 
> 
> Actually, the put_device(mc) should be right after
> tegra_get_memory_controller() in tegra_smmu_probe_device() because SMMU
> is a part of MC, hence MC can't just go away.

Will add it. Thanks for pointing it out!

[tip: ras/core] x86/mce: Add Skylake quirk for patrol scrub reported errors

[tip-bot2 for Borislav Petkov]

The following commit has been merged into the ras/core branch of tip:

Commit-ID: fd258dc4442c5c1c069c6b5b42bfe7d10cddda95
Gitweb:
https://git.kernel.org/tip/fd258dc4442c5c1c069c6b5b42bfe7d10cddda95
Author:Borislav Petkov 
AuthorDate:Tue, 29 Sep 2020 19:13:12 -07:00
Committer: Borislav Petkov 
CommitterDate: Wed, 30 Sep 2020 07:43:56 +02:00

x86/mce: Add Skylake quirk for patrol scrub reported errors

The patrol scrubber in Skylake and Cascade Lake systems can be configured
to report uncorrected errors using a special signature in the machine
check bank and to signal using CMCI instead of machine check.

Update the severity calculation mechanism to allow specifying the model,
minimum stepping and range of machine check bank numbers.

Add a new rule to detect the special signature (on model 0x55, stepping
>=4 in any of the memory controller banks).

 [ bp: Rewrite it.
   aegl: Productize it. ]

Suggested-by: Youquan Song 
Signed-off-by: Borislav Petkov 
Co-developed-by: Tony Luck 
Signed-off-by: Tony Luck 
Signed-off-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20200930021313.31810-2-tony.l...@intel.com
---
 arch/x86/kernel/cpu/mce/severity.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/mce/severity.c 
b/arch/x86/kernel/cpu/mce/severity.c
index e1da619..567ce09 100644
--- a/arch/x86/kernel/cpu/mce/severity.c
+++ b/arch/x86/kernel/cpu/mce/severity.c
@@ -9,9 +9,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
+#include 
+#include 
+
 #include "internal.h"
 
 /*
@@ -40,9 +42,14 @@ static struct severity {
unsigned char context;
unsigned char excp;
unsigned char covered;
+   unsigned char cpu_model;
+   unsigned char cpu_minstepping;
+   unsigned char bank_lo, bank_hi;
char *msg;
 } severities[] = {
 #define MCESEV(s, m, c...) { .sev = MCE_ ## s ## _SEVERITY, .msg = m, ## c }
+#define BANK_RANGE(l, h) .bank_lo = l, .bank_hi = h
+#define MODEL_STEPPING(m, s) .cpu_model = m, .cpu_minstepping = s
 #define  KERNEL.context = IN_KERNEL
 #define  USER  .context = IN_USER
 #define  KERNEL_RECOV  .context = IN_KERNEL_RECOV
@@ -97,7 +104,6 @@ static struct severity {
KEEP, "Corrected error",
NOSER, BITCLR(MCI_STATUS_UC)
),
-
/*
 * known AO MCACODs reported via MCE or CMC:
 *
@@ -113,6 +119,18 @@ static struct severity {
AO, "Action optional: last level cache writeback error",
SER, MASK(MCI_UC_AR|MCACOD, MCI_STATUS_UC|MCACOD_L3WB)
),
+   /*
+* Quirk for Skylake/Cascade Lake. Patrol scrubber may be configured
+* to report uncorrected errors using CMCI with a special signature.
+* UC=0, MSCOD=0x0010, MCACOD=binary(000X  1100 ) reported
+* in one of the memory controller banks.
+* Set severity to "AO" for same action as normal patrol scrub error.
+*/
+   MCESEV(
+   AO, "Uncorrected Patrol Scrub Error",
+   SER, MASK(MCI_STATUS_UC|MCI_ADDR|0xeff0, 
MCI_ADDR|0x001000c0),
+   MODEL_STEPPING(INTEL_FAM6_SKYLAKE_X, 4), BANK_RANGE(13, 18)
+   ),
 
/* ignore OVER for UCNA */
MCESEV(
@@ -324,6 +342,12 @@ static int mce_severity_intel(struct mce *m, int tolerant, 
char **msg, bool is_e
continue;
if (s->excp && excp != s->excp)
continue;
+   if (s->cpu_model && boot_cpu_data.x86_model != s->cpu_model)
+   continue;
+   if (s->cpu_minstepping && boot_cpu_data.x86_stepping < 
s->cpu_minstepping)
+   continue;
+   if (s->bank_lo && (m->bank < s->bank_lo || m->bank > 
s->bank_hi))
+   continue;
if (msg)
*msg = s->msg;
s->covered = 1;

[tip: ras/core] x86/mce: Drop AMD-specific "DEFERRED" case from Intel severity rule list

[tip-bot2 for Tony Luck]

The following commit has been merged into the ras/core branch of tip:

Commit-ID: ed9705e4ad1c19ae51ed0cb4c112f9eb6dfc69fc
Gitweb:
https://git.kernel.org/tip/ed9705e4ad1c19ae51ed0cb4c112f9eb6dfc69fc
Author:Tony Luck 
AuthorDate:Tue, 29 Sep 2020 19:13:13 -07:00
Committer: Borislav Petkov 
CommitterDate: Wed, 30 Sep 2020 07:49:58 +02:00

x86/mce: Drop AMD-specific "DEFERRED" case from Intel severity rule list

Way back in v3.19 Intel and AMD shared the same machine check severity
grading code. So it made sense to add a case for AMD DEFERRED errors in
commit

  e3480271f592 ("x86, mce, severity: Extend the the mce_severity mechanism to 
handle UCNA/DEFERRED error")

But later in v4.2 AMD switched to a separate grading function in
commit

  bf80bbd7dcf5 ("x86/mce: Add an AMD severities-grading function")

Belatedly drop the DEFERRED case from the Intel rule list.

Signed-off-by: Tony Luck 
Signed-off-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20200930021313.31810-3-tony.l...@intel.com
---
 arch/x86/kernel/cpu/mce/severity.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/mce/severity.c 
b/arch/x86/kernel/cpu/mce/severity.c
index 567ce09..e072246 100644
--- a/arch/x86/kernel/cpu/mce/severity.c
+++ b/arch/x86/kernel/cpu/mce/severity.c
@@ -97,10 +97,6 @@ static struct severity {
EXCP, KERNEL_RECOV, MCGMASK(MCG_STATUS_RIPV, 0)
),
MCESEV(
-   DEFERRED, "Deferred error",
-   NOSER, 
MASK(MCI_STATUS_UC|MCI_STATUS_DEFERRED|MCI_STATUS_POISON, MCI_STATUS_DEFERRED)
-   ),
-   MCESEV(
KEEP, "Corrected error",
NOSER, BITCLR(MCI_STATUS_UC)
),

Re: [PATCH v2 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Nicolin Chen]

On Wed, Sep 30, 2020 at 08:11:52AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> > +   /* An invalid mc pointer means mc and smmu drivers are not ready */
> > +   if (IS_ERR_OR_NULL(mc))
> 
> tegra_get_memory_controller() doesn't return NULL.

Well, I don't want to assume that it'd do that forever, and the
NULL check of IS_ERR_OR_NULL is marked "unlikely" so it doesn't
hurt to have.

Re: [PATCH v2 1/3] memory: tegra: Add helper function tegra_get_memory_controller

[Nicolin Chen]

On Wed, Sep 30, 2020 at 08:12:10AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> ...
> >  int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long 
> > rate);
> >  unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc);
> > +struct tegra_mc *tegra_get_memory_controller(void);
> >  
> >  #endif /* __SOC_TEGRA_MC_H__ */
> > 
> 
> This will conflict with the tegra20-devfreq driver, you should change it
> as well.

Will remove that in v3.

Thanks

Re: [PATCH v2 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Dmitry Osipenko]

30.09.2020 08:39, Nicolin Chen пишет:
> On Wed, Sep 30, 2020 at 08:24:02AM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 03:30, Nicolin Chen пишет:
>>> +   /*
>>> +* IOMMU core allows -ENODEV return to carry on. So bypass any call
>>> +* from bus_set_iommu() during tegra_smmu_probe(), as a device will
>>> +* call in again via of_iommu_configure when fwspec is prepared.
>>> +*/
>>> +   if (!mc->smmu || !fwspec || fwspec->ops != _smmu_ops)
>>> return ERR_PTR(-ENODEV);
>>
>> The !mc->smmu can't be true.
> 
> Are you sure? I have removed the "mc->smmu = smmu" in probe() with
> this change. So the only time "mc->smmu == !NULL" is after probe()
> of SMMU driver is returned. As my comments says, tegra_smmu_probe()
> calls in this function via bus_set_iommu(), so mc->smmu can be NULL
> in this case.
> 

I missed that.

Re: [PATCH v2 1/2] iommu/iova: Retry from last rb tree node if iova search fails

[Vijayanand Jitta]

On 9/18/2020 7:48 PM, Robin Murphy wrote:
> On 2020-08-20 13:49, vji...@codeaurora.org wrote:
>> From: Vijayanand Jitta 
>>
>> When ever a new iova alloc request comes iova is always searched
>> from the cached node and the nodes which are previous to cached
>> node. So, even if there is free iova space available in the nodes
>> which are next to the cached node iova allocation can still fail
>> because of this approach.
>>
>> Consider the following sequence of iova alloc and frees on
>> 1GB of iova space
>>
>> 1) alloc - 500MB
>> 2) alloc - 12MB
>> 3) alloc - 499MB
>> 4) free -  12MB which was allocated in step 2
>> 5) alloc - 13MB
>>
>> After the above sequence we will have 12MB of free iova space and
>> cached node will be pointing to the iova pfn of last alloc of 13MB
>> which will be the lowest iova pfn of that iova space. Now if we get an
>> alloc request of 2MB we just search from cached node and then look
>> for lower iova pfn's for free iova and as they aren't any, iova alloc
>> fails though there is 12MB of free iova space.
>>
>> To avoid such iova search failures do a retry from the last rb tree node
>> when iova search fails, this will search the entire tree and get an iova
>> if its available.
>>
>> Signed-off-by: Vijayanand Jitta 
>> ---
>>   drivers/iommu/iova.c | 23 +--
>>   1 file changed, 17 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>> index 49fc01f..4e77116 100644
>> --- a/drivers/iommu/iova.c
>> +++ b/drivers/iommu/iova.c
>> @@ -184,8 +184,9 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>>   struct rb_node *curr, *prev;
>>   struct iova *curr_iova;
>>   unsigned long flags;
>> -    unsigned long new_pfn;
>> +    unsigned long new_pfn, low_pfn_new;
>>   unsigned long align_mask = ~0UL;
>> +    unsigned long high_pfn = limit_pfn, low_pfn = iovad->start_pfn;
>>     if (size_aligned)
>>   align_mask <<= fls_long(size - 1);
>> @@ -198,15 +199,25 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>>     curr = __get_cached_rbnode(iovad, limit_pfn);
>>   curr_iova = rb_entry(curr, struct iova, node);
>> +    low_pfn_new = curr_iova->pfn_hi + 1;
> 
> Could we call "low_pfn_new" something like "retry_pfn" instead? This
> code already has unavoidable readability struggles with so many
> different "pfn"s in play, so having two different meanings of "new"
> really doesn't help.
> 
> Other than that, I think this looks OK (IIRC it's basically what I
> originally suggested), so with the naming tweaked,
> 
> Reviewed-by: Robin Murphy 
> 

Thanks for review, I have renamed it to retry_pfn in v4.

Thanks,
Vijay
>> +
>> +retry:
>>   do {
>> -    limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
>> -    new_pfn = (limit_pfn - size) & align_mask;
>> +    high_pfn = min(high_pfn, curr_iova->pfn_lo);
>> +    new_pfn = (high_pfn - size) & align_mask;
>>   prev = curr;
>>   curr = rb_prev(curr);
>>   curr_iova = rb_entry(curr, struct iova, node);
>> -    } while (curr && new_pfn <= curr_iova->pfn_hi);
>> -
>> -    if (limit_pfn < size || new_pfn < iovad->start_pfn) {
>> +    } while (curr && new_pfn <= curr_iova->pfn_hi && new_pfn >=
>> low_pfn);
>> +
>> +    if (high_pfn < size || new_pfn < low_pfn) {
>> +    if (low_pfn == iovad->start_pfn && low_pfn_new < limit_pfn) {
>> +    high_pfn = limit_pfn;
>> +    low_pfn = low_pfn_new;
>> +    curr = >anchor.node;
>> +    curr_iova = rb_entry(curr, struct iova, node);
>> +    goto retry;
>> +    }
>>   iovad->max32_alloc_size = size;
>>   goto iova32_full;
>>   }
>>

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v4 2/2] iommu/iova: Free global iova rcache on iova alloc failure

[vjitta]

From: Vijayanand Jitta 

When ever an iova alloc request fails we free the iova
ranges present in the percpu iova rcaches and then retry
but the global iova rcache is not freed as a result we could
still see iova alloc failure even after retry as global
rcache is holding the iova's which can cause fragmentation.
So, free the global iova rcache as well and then go for the
retry.

Signed-off-by: Vijayanand Jitta 
---
 drivers/iommu/iova.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index c3a1a8e..64ce082 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -442,6 +442,7 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long 
size,
flush_rcache = false;
for_each_online_cpu(cpu)
free_cpu_cached_iovas(cpu, iovad);
+   free_global_cached_iovas(iovad);
goto retry;
}
 
@@ -1057,5 +1058,26 @@ void free_cpu_cached_iovas(unsigned int cpu, struct 
iova_domain *iovad)
}
 }
 
+/*
+ * free all the IOVA ranges of global cache
+ */
+static void free_global_cached_iovas(struct iova_domain *iovad)
+{
+   struct iova_rcache *rcache;
+   unsigned long flags;
+   int i, j;
+
+   for (i = 0; i < IOVA_RANGE_CACHE_MAX_SIZE; ++i) {
+   rcache = >rcaches[i];
+   spin_lock_irqsave(>lock, flags);
+   for (j = 0; j < rcache->depot_size; ++j) {
+   iova_magazine_free_pfns(rcache->depot[j], iovad);
+   iova_magazine_free(rcache->depot[j]);
+   rcache->depot[j] = NULL;
+   }
+   rcache->depot_size = 0;
+   spin_unlock_irqrestore(>lock, flags);
+   }
+}
 MODULE_AUTHOR("Anil S Keshavamurthy ");
 MODULE_LICENSE("GPL");
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation
2.7.4

[PATCH v4 1/2] iommu/iova: Retry from last rb tree node if iova search fails

[vjitta]

From: Vijayanand Jitta 

When ever a new iova alloc request comes iova is always searched
from the cached node and the nodes which are previous to cached
node. So, even if there is free iova space available in the nodes
which are next to the cached node iova allocation can still fail
because of this approach.

Consider the following sequence of iova alloc and frees on
1GB of iova space

1) alloc - 500MB
2) alloc - 12MB
3) alloc - 499MB
4) free -  12MB which was allocated in step 2
5) alloc - 13MB

After the above sequence we will have 12MB of free iova space and
cached node will be pointing to the iova pfn of last alloc of 13MB
which will be the lowest iova pfn of that iova space. Now if we get an
alloc request of 2MB we just search from cached node and then look
for lower iova pfn's for free iova and as they aren't any, iova alloc
fails though there is 12MB of free iova space.

To avoid such iova search failures do a retry from the last rb tree node
when iova search fails, this will search the entire tree and get an iova
if its available.

Signed-off-by: Vijayanand Jitta 
Reviewed-by: Robin Murphy 
---
 drivers/iommu/iova.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 30d969a..c3a1a8e 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -184,8 +184,9 @@ static int __alloc_and_insert_iova_range(struct iova_domain 
*iovad,
struct rb_node *curr, *prev;
struct iova *curr_iova;
unsigned long flags;
-   unsigned long new_pfn;
+   unsigned long new_pfn, retry_pfn;
unsigned long align_mask = ~0UL;
+   unsigned long high_pfn = limit_pfn, low_pfn = iovad->start_pfn;
 
if (size_aligned)
align_mask <<= fls_long(size - 1);
@@ -198,15 +199,25 @@ static int __alloc_and_insert_iova_range(struct 
iova_domain *iovad,
 
curr = __get_cached_rbnode(iovad, limit_pfn);
curr_iova = rb_entry(curr, struct iova, node);
+   retry_pfn = curr_iova->pfn_hi + 1;
+
+retry:
do {
-   limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
-   new_pfn = (limit_pfn - size) & align_mask;
+   high_pfn = min(high_pfn, curr_iova->pfn_lo);
+   new_pfn = (high_pfn - size) & align_mask;
prev = curr;
curr = rb_prev(curr);
curr_iova = rb_entry(curr, struct iova, node);
-   } while (curr && new_pfn <= curr_iova->pfn_hi);
-
-   if (limit_pfn < size || new_pfn < iovad->start_pfn) {
+   } while (curr && new_pfn <= curr_iova->pfn_hi && new_pfn >= low_pfn);
+
+   if (high_pfn < size || new_pfn < low_pfn) {
+   if (low_pfn == iovad->start_pfn && retry_pfn < limit_pfn) {
+   high_pfn = limit_pfn;
+   low_pfn = retry_pfn;
+   curr = >anchor.node;
+   curr_iova = rb_entry(curr, struct iova, node);
+   goto retry;
+   }
iovad->max32_alloc_size = size;
goto iova32_full;
}
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation
2.7.4

Re: [PATCH v3 2/3] dmaengine: add peripheral configuration

[Peter Ujfalusi]

Hi Vinod,

On 29/09/2020 11.06, Peter Ujfalusi wrote:
> 
> I know that you want this to be as generic as much as it is possible,
> but do we really want to?
> GPIv2 will also handle I2S peripheral, other vendor's similar solution
> would require different sets of parameters unique to their IPs?
> 
> How we are going to handle similar setups for DMA which is used for
> networking, SPI/I2C/I2S/NAND/display/capture, etc?
> 
> Imho these settings are really part of the peripheral's domain and not
> the DMA. It is just a small detail that instead of direct register
> writes, your setup is using the DMA descriptors to write.
> It is similar to what I use as metadata (part of the descriptor belongs
> and owned by the client driver).
> 
> I think it would be better to have:
> 
> enum dmaengine_peripheral {
>   DMAENGINE_PERIPHERAL_GPI_SPI = 1,
>   DMAENGINE_PERIPHERAL_GPI_UART,
>   DMAENGINE_PERIPHERAL_GPI_I2C,
>   DMAENGINE_PERIPHERAL_XYZ_SPI,
>   DMAENGINE_PERIPHERAL_XYZ_AASRC,
>   DMAENGINE_PERIPHERAL_ABC_CAM,
>   ...
>   DMAENGINE_PERIPHERAL_LAST,
> };
> 
> enum dmaengine_peripheral peripheral_type;
> void *peripheral_config;

TI have an AASRC (Audio Asynchronous Sample Rate Converted) in j721e and
to configure the DMA side (AASRC_PDMA) we need special configuration
parameters passed from the AASRC driver to the DMA channel.
This peripheral config extension would be perfect for it, but the
parameters I would need is not generic in any ways.

The other thing which might need to be considered is to have src/dst
pair of this. When we do DMA_DEV_TO_DEV, it would help to figure out
which side we should apply which config (if you have the same type of
device on both ends with different config?).


> and that's it. The set_config is specific to GPI.
> It can be debated where the structs should be defined, in the generic
> dmaengine.h or in include/linux/dma/ as controller specific
> (gpi_peripheral.h) or a generic one, like dmaengine_peripheral.h
> 
> The SPI/I2C/UART client of yours would pass the GPI specific struct as
> in any case it has to know what is the DMA it is serviced by.
> 
>> +};
>>  /**
>>   * struct dma_slave_config - dma slave channel runtime config
>>   * @direction: whether the data shall go in or out on this slave
>> @@ -418,6 +506,8 @@ enum dma_slave_buswidth {
>>   * @slave_id: Slave requester id. Only valid for slave channels. The dma
>>   * slave peripheral will have unique id as dma requester which need to be
>>   * pass as slave config.
>> + * @peripheral: peripheral configuration for programming peripheral for
>> + * dmaengine transfer
>>   *
>>   * This struct is passed in as configuration data to a DMA engine
>>   * in order to set up a certain channel for DMA transport at runtime.
>> @@ -443,6 +533,7 @@ struct dma_slave_config {
>>  u32 dst_port_window_size;
>>  bool device_fc;
>>  unsigned int slave_id;
>> +struct dmaengine_peripheral_config *peripheral;
>>  };
>>  
>>  /**
>>
> 
> - Péter
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v2 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Nicolin Chen]

On Wed, Sep 30, 2020 at 08:39:54AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> >  static int tegra_smmu_attach_dev(struct iommu_domain *domain,
> >  struct device *dev)
> >  {
> > +   struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> > struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
> > struct tegra_smmu_as *as = to_smmu_as(domain);
> > -   struct device_node *np = dev->of_node;
> > -   struct of_phandle_args args;
> > unsigned int index = 0;
> > int err = 0;
> >  
> > -   while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells", index,
> > -  )) {
> > -   unsigned int swgroup = args.args[0];
> > -
> > -   if (args.np != smmu->dev->of_node) {
> > -   of_node_put(args.np);
> > -   continue;
> > -   }
> > -
> > -   of_node_put(args.np);
> > +   if (!fwspec || fwspec->ops != _smmu_ops)
> > +   return -ENOENT;
> 
> s/_smmu_ops/smmu->iommu.ops/
> 
> Secondly, is it even possible that fwspec could be NULL here or that
> fwspec->ops != smmu->ops?

I am following what's in the arm-smmu driver, as I think it'd be
a common practice to do such a check in such a way.

Re: [PATCH v2 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Nicolin Chen]

On Wed, Sep 30, 2020 at 08:24:02AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> > +   /*
> > +* IOMMU core allows -ENODEV return to carry on. So bypass any call
> > +* from bus_set_iommu() during tegra_smmu_probe(), as a device will
> > +* call in again via of_iommu_configure when fwspec is prepared.
> > +*/
> > +   if (!mc->smmu || !fwspec || fwspec->ops != _smmu_ops)
> > return ERR_PTR(-ENODEV);
> 
> The !mc->smmu can't be true.

Are you sure? I have removed the "mc->smmu = smmu" in probe() with
this change. So the only time "mc->smmu == !NULL" is after probe()
of SMMU driver is returned. As my comments says, tegra_smmu_probe()
calls in this function via bus_set_iommu(), so mc->smmu can be NULL
in this case.

Re: [PATCH v2 3/3] iommu/tegra-smmu: Add PCI support

[Nicolin Chen]

On Wed, Sep 30, 2020 at 08:10:35AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> >  void tegra_smmu_remove(struct tegra_smmu *smmu)
> >  {
> > +   bus_set_iommu(_bus_type, NULL);
> 
> Why only platform_bus? Is this really needed at all?

I see qcom_iommu.c file set to NULL in remove(), Probably should
have added pci_bus_type too though.

Or are you sure that there's no need at all?

Re: [PATCH v2 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Dmitry Osipenko]

30.09.2020 03:30, Nicolin Chen пишет:
>  static int tegra_smmu_attach_dev(struct iommu_domain *domain,
>struct device *dev)
>  {
> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>   struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
>   struct tegra_smmu_as *as = to_smmu_as(domain);
> - struct device_node *np = dev->of_node;
> - struct of_phandle_args args;
>   unsigned int index = 0;
>   int err = 0;
>  
> - while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells", index,
> -)) {
> - unsigned int swgroup = args.args[0];
> -
> - if (args.np != smmu->dev->of_node) {
> - of_node_put(args.np);
> - continue;
> - }
> -
> - of_node_put(args.np);
> + if (!fwspec || fwspec->ops != _smmu_ops)
> + return -ENOENT;

s/_smmu_ops/smmu->iommu.ops/

Secondly, is it even possible that fwspec could be NULL here or that
fwspec->ops != smmu->ops?

Re: [PATCH v5] ipvs: adjust the debug info in function set_tcp_state

[yue longguang]

It's  done.


On Wed, Sep 30, 2020 at 1:08 PM Julian Anastasov  wrote:
>
>
> Hello,
>
> On Mon, 28 Sep 2020, longguang.yue wrote:
>
> > Outputting client,virtual,dst addresses info when tcp state changes,
> > which makes the connection debug more clear
> >
> > Signed-off-by: longguang.yue 
>
> OK, v5 can be used instead of fixing v4.
>
> Acked-by: Julian Anastasov 
>
> > ---
> Changelogs:
>   v5: fix indentation
>   v4: fix checkpatch
>   v3: fix checkpatch
>   v2: IP_VS_DBG_BUF outputs src,virtual,dst of ip_vs_conn
>   v1: fix the inverse of src and dst address
>
> longguang.yue, at this place after --- you can add info
> for changes between versions, eg:
> v5: fix indentation
>
> Use this for other patches, so that we know what is
> changed between versions.
>
> >  net/netfilter/ipvs/ip_vs_proto_tcp.c | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c 
> > b/net/netfilter/ipvs/ip_vs_proto_tcp.c
> > index dc2e7da2742a..7da51390cea6 100644
> > --- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
> > +++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
> > @@ -539,8 +539,8 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct 
> > ip_vs_conn *cp,
> >   if (new_state != cp->state) {
> >   struct ip_vs_dest *dest = cp->dest;
> >
> > - IP_VS_DBG_BUF(8, "%s %s [%c%c%c%c] %s:%d->"
> > -   "%s:%d state: %s->%s conn->refcnt:%d\n",
> > + IP_VS_DBG_BUF(8, "%s %s [%c%c%c%c] c:%s:%d v:%s:%d "
> > +   "d:%s:%d state: %s->%s conn->refcnt:%d\n",
> > pd->pp->name,
> > ((state_off == TCP_DIR_OUTPUT) ?
> >  "output " : "input "),
> > @@ -548,10 +548,12 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct 
> > ip_vs_conn *cp,
> > th->fin ? 'F' : '.',
> > th->ack ? 'A' : '.',
> > th->rst ? 'R' : '.',
> > -   IP_VS_DBG_ADDR(cp->daf, >daddr),
> > -   ntohs(cp->dport),
> > IP_VS_DBG_ADDR(cp->af, >caddr),
> > ntohs(cp->cport),
> > +   IP_VS_DBG_ADDR(cp->af, >vaddr),
> > +   ntohs(cp->vport),
> > +   IP_VS_DBG_ADDR(cp->daf, >daddr),
> > +   ntohs(cp->dport),
> > tcp_state_name(cp->state),
> > tcp_state_name(new_state),
> > refcount_read(>refcnt));
> > --
> > 2.20.1 (Apple Git-117)
>
> Regards
>
> --
> Julian Anastasov 
>

RE: [PATCH] PCI: layerscape: Change back to the default error response behavior

[Z.q. Hou]

Hi Bjorn,

Thanks a lot for your comments!

> -Original Message-
> From: Bjorn Helgaas 
> Sent: 2020年9月29日 23:03
> To: Z.q. Hou 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; lorenzo.pieral...@arm.com;
> r...@kernel.org; bhelg...@google.com; M.h. Lian
> ; Roy Zang ; Mingkai Hu
> ; Leo Li 
> Subject: Re: [PATCH] PCI: layerscape: Change back to the default error
> response behavior
> 
> On Tue, Sep 29, 2020 at 09:13:28PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > In the current error response behavior, it will send a SLVERR response
> > to device's internal AXI slave system interface when the PCIe
> > controller experiences an erroneous completion (UR, CA and CT) from an
> > external completer for its outbound non-posted request, which will
> > result in SError and crash the kernel directly.
> 
> Possible wording:
> 
>   As currently configured, when the PCIe controller receives a
>   Completion with UR or CA status, or a Completion Timeout occurs, it
>   sends a SLVERR response to the internal AXI slave system interface,
>   which results in SError and a kernel crash.
> 
> Please add a blank line between paragraphs, and s/This patch change back
> it/Change it/ below.
> 
> > This patch change back it to the default behavior to increase the
> > robustness of the kernel. In the default behavior, it always sends an
> > OKAY response to the internal AXI slave interface when the controller
> > gets these erroneous completions. And the AER driver will report and
> > try to recover these errors.
> 
> This reverts 84d897d69938 ("PCI: layerscape: Change default error response
> behavior"), so please mention that in the commit log, probably as:
> 
> Fixes: 84d897d69938 ("PCI: layerscape: Change default error response
> behavior")
> 
> Maybe it also needs a stable tag, e.g., v4.15+?

Thanks for your good suggestions! Will fix in v2.

> 
> Since this is a pure revert, whatever problem 84d897d69938 fixed must now
> be fixed in some other way.  Otherwise, this revert would just be
> reintroducing the problem fixed by 84d897d69938.
> 
> This commit log should mention that what that other fix is.
> 
> AER is only a reporting mechanism, it is asynchronous to the instruction
> stream, and it's optional (may not be implemented in the hardware, and may
> not be supported by the kernel), so I'm not super convinced that it can be the
> answer to this problem.
>

The commit 84d897d69938 ("PCI: layerscape: Change default error response 
behavior") doesn't fix any issue, it just enable a feature of DesignWare PCIe 
IP that it allows error response to AXI slave interface, which are not enabled 
on all other platforms with DWC IP. As mentioned in that commit it will also 
send an OKAY response to AXI slave interface for erroneous completion of 
non-post transaction including CFG and MEM_rd transactions, however upstream 
won't support for platforms aborting on CFG accesses, so we have to change it 
back to the default error response behavior and bear the error of MEM_rd isn't 
forwarded, just like other DWC IP platforms.

I remember the SError interrupt mechanism is also asynchronous abort and it is 
only a reporting mechanism. Contrast with the AER, it will make the kernel 
crash. So both of these 2 mechanism cannot ensure the data integrity, generally 
the upper layer data transfer protocol has its own mechanism to ensure the data 
integrity, it's not a issue for almost users. If one really wants a kernel 
crash when there is error of MEM_rd, he can enable this in his local code.

Thanks,
Zhiqiang
 
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  drivers/pci/controller/dwc/pci-layerscape.c | 11 ---
> >  1 file changed, 11 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape.c
> > b/drivers/pci/controller/dwc/pci-layerscape.c
> > index f24f79a70d9a..e92ab8a77046 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> > @@ -30,8 +30,6 @@
> >
> >  /* PEX Internal Configuration Registers */
> >  #define PCIE_STRFMR1   0x71c /* Symbol Timer & Filter Mask
> Register1 */
> > -#define PCIE_ABSERR0x8d0 /* Bridge Slave Error Response
> Register */
> > -#define PCIE_ABSERR_SETTING0x9401 /* Forward error of
> non-posted request */
> >
> >  #define PCIE_IATU_NUM  6
> >
> > @@ -123,14 +121,6 @@ static int ls_pcie_link_up(struct dw_pcie *pci)
> > return 1;
> >  }
> >
> > -/* Forward error response of outbound non-posted requests */ -static
> > void ls_pcie_fix_error_response(struct ls_pcie *pcie) -{
> > -   struct dw_pcie *pci = pcie->pci;
> > -
> > -   iowrite32(PCIE_ABSERR_SETTING, pci->dbi_base + PCIE_ABSERR);
> > -}
> > -
> >  static int ls_pcie_host_init(struct pcie_port *pp)  {
> > struct dw_pcie *pci = to_dw_pcie_from_pp(pp); @@ -142,7 +132,6 @@
> > static int ls_pcie_host_init(struct pcie_port *pp)
> >  * 

Re: [PATCH v3 2/2] hwmon: intel-m10-bmc-hwmon: add hwmon support for Intel MAX 10 BMC

[Guenter Roeck]

On 9/20/20 11:17 PM, Xu Yilun wrote:
> This patch adds hwmon functionality for Intel MAX 10 BMC chip. This BMC
> chip connects to a set of sensor chips to monitor current, voltage,
> thermal and power of different components on board. The BMC firmware is
> responsible for sensor data sampling and recording in shared registers.
> Host driver reads the sensor data from these shared registers and
> exposes them to users as hwmon interfaces.
> 
> Signed-off-by: Xu Yilun 
> Signed-off-by: Wu Hao 
> Signed-off-by: Matthew Gerlach 
> Signed-off-by: Tom Rix 

Reviewed-by: Guenter Roeck 

> ---
> v2: add the Documentation
> refactor the code, provide static hwmon_channel_info
> remove Unnecessary hwmon-sysfs.h
> make the sensor data table const
> v3: make the data tables a pointer array indexed by hwmon_sensor_types
> some minor fixes
> ---
>  Documentation/hwmon/index.rst   |   1 +
>  Documentation/hwmon/intel-m10-bmc-hwmon.rst |  78 +++
>  drivers/hwmon/Kconfig   |  11 +
>  drivers/hwmon/Makefile  |   1 +
>  drivers/hwmon/intel-m10-bmc-hwmon.c | 334 
> 
>  5 files changed, 425 insertions(+)
>  create mode 100644 Documentation/hwmon/intel-m10-bmc-hwmon.rst
>  create mode 100644 drivers/hwmon/intel-m10-bmc-hwmon.c
> 
> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
> index a926f1a..4bcb1a7 100644
> --- a/Documentation/hwmon/index.rst
> +++ b/Documentation/hwmon/index.rst
> @@ -74,6 +74,7 @@ Hardware Monitoring Kernel Drivers
> ina209
> ina2xx
> ina3221
> +   intel-m10-bmc-hwmon
> ir35221
> ir38064
> isl68137
> diff --git a/Documentation/hwmon/intel-m10-bmc-hwmon.rst 
> b/Documentation/hwmon/intel-m10-bmc-hwmon.rst
> new file mode 100644
> index 000..3d148c6
> --- /dev/null
> +++ b/Documentation/hwmon/intel-m10-bmc-hwmon.rst
> @@ -0,0 +1,78 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Kernel driver intel-m10-bmc-hwmon
> +=
> +
> +Supported chips:
> +
> + * Intel MAX 10 BMC for Intel PAC N3000
> +
> +   Prefix: 'n3000bmc-hwmon'
> +
> +Author: Xu Yilun 
> +
> +
> +Description
> +---
> +
> +This driver adds the temperature, voltage, current and power reading
> +support for the Intel MAX 10 Board Management Controller (BMC) chip.
> +The BMC chip is integrated in some Intel Programmable Acceleration
> +Cards (PAC). It connects to a set of sensor chips to monitor the
> +sensor data of different components on the board. The BMC firmware is
> +responsible for sensor data sampling and recording in shared
> +registers. The host driver reads the sensor data from these shared
> +registers and exposes them to users as hwmon interfaces.
> +
> +The BMC chip is implemented using the Intel MAX 10 CPLD. It could be
> +reprogramed to some variants in order to support different Intel
> +PACs. The driver is designed to be able to distinguish between the
> +variants, but now it only supports the BMC for Intel PAC N3000.
> +
> +
> +Sysfs attributes
> +
> +
> +The following attributes are supported:
> +
> +- Intel MAX 10 BMC for Intel PAC N3000:
> +
> +=== 
> ===
> +tempX_input Temperature of the component (specified by 
> tempX_label)
> +tempX_max   Temperature maximum setpoint of the component
> +tempX_crit  Temperature critical setpoint of the component
> +tempX_max_hyst  Hysteresis for temperature maximum of the component
> +tempX_crit_hyst Hysteresis for temperature critical of the component
> +temp1_label "Board Temperature"
> +temp2_label "FPGA Die Temperature"
> +temp3_label "QSFP0 Temperature"
> +temp4_label "QSFP1 Temperature"
> +temp5_label "Retimer A Temperature"
> +temp6_label "Retimer A SerDes Temperature"
> +temp7_label "Retimer B Temperature"
> +temp8_label "Retimer B SerDes Temperature"
> +
> +inX_input   Measured voltage of the component (specified by
> +inX_label)
> +in0_label   "QSFP0 Supply Voltage"
> +in1_label   "QSFP1 Supply Voltage"
> +in2_label   "FPGA Core Voltage"
> +in3_label   "12V Backplane Voltage"
> +in4_label   "1.2V Voltage"
> +in5_label   "12V AUX Voltage"
> +in6_label   "1.8V Voltage"
> +in7_label   "3.3V Voltage"
> +
> +currX_input Measured current of the component (specified by
> +currX_label)
> +curr1_label "FPGA Core Current"
> +curr2_label "12V Backplane Current"
> +curr3_label "12V AUX Current"
> +
> +powerX_inputMeasured power of the component (specified by
> +powerX_label)
> +power1_label"Board Power"
> +
> 

[PATCH v3 2/4] dt-bindings: PCI: uniphier-ep: Add iATU register description

[Kunihiko Hayashi]

In the dt-bindings, "atu" reg-names is required to get the register space
for iATU in Synopsis DWC version 4.80 or later.

Signed-off-by: Kunihiko Hayashi 
---
 .../bindings/pci/socionext,uniphier-pcie-ep.yaml | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml 
b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
index f0558b9..f4292d2 100644
--- a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
@@ -23,14 +23,22 @@ properties:
 const: socionext,uniphier-pro5-pcie-ep
 
   reg:
-maxItems: 4
+minItems: 4
+maxItems: 5
 
   reg-names:
-items:
-  - const: dbi
-  - const: dbi2
-  - const: link
-  - const: addr_space
+oneOf:
+  - items:
+- const: dbi
+- const: dbi2
+- const: link
+- const: addr_space
+  - items:
+- const: dbi
+- const: dbi2
+- const: link
+- const: addr_space
+- const: atu
 
   clocks:
 maxItems: 2
-- 
2.7.4

[PATCH v3 3/4] PCI: dwc: Add common iATU register support

[Kunihiko Hayashi]

This gets iATU register area from reg property that has reg-names "atu".
In Synopsys DWC version 4.80 or later, since iATU register area is
separated from core register area, this area is necessary to get from
DT independently.

Cc: Murali Karicheri 
Cc: Jingoo Han 
Cc: Gustavo Pimentel 
Suggested-by: Rob Herring 
Signed-off-by: Kunihiko Hayashi 
---
 drivers/pci/controller/dwc/pcie-designware.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 3fe859f..b6b39af 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include "../../pci.h"
@@ -548,11 +549,15 @@ void dw_pcie_setup(struct dw_pcie *pci)
u32 val;
struct device *dev = pci->dev;
struct device_node *np = dev->of_node;
+   struct platform_device *pdev = to_platform_device(dev);
 
if (pci->version >= 0x480A || (!pci->version &&
   dw_pcie_iatu_unroll_enabled(pci))) {
pci->iatu_unroll_enabled = true;
if (!pci->atu_base)
+   pci->atu_base =
+   devm_platform_ioremap_resource_byname(pdev, "atu");
+   if (IS_ERR(pci->atu_base))
pci->atu_base = pci->dbi_base + DEFAULT_DBI_ATU_OFFSET;
}
dev_dbg(pci->dev, "iATU unroll: %s\n", pci->iatu_unroll_enabled ?
-- 
2.7.4

[PATCH v3 4/4] PCI: keystone: Remove iATU register mapping

[Kunihiko Hayashi]

After applying "PCI: dwc: Add common iATU register support",
there is no need to set own iATU in the Keystone driver itself.

Cc: Murali Karicheri 
Cc: Jingoo Han 
Cc: Gustavo Pimentel 
Suggested-by: Rob Herring 
Signed-off-by: Kunihiko Hayashi 
Reviewed-by: Rob Herring 
---
 drivers/pci/controller/dwc/pci-keystone.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-keystone.c 
b/drivers/pci/controller/dwc/pci-keystone.c
index b554812..a222728 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -1154,7 +1154,6 @@ static int __init ks_pcie_probe(struct platform_device 
*pdev)
struct keystone_pcie *ks_pcie;
struct device_link **link;
struct gpio_desc *gpiod;
-   void __iomem *atu_base;
struct resource *res;
unsigned int version;
void __iomem *base;
@@ -1275,23 +1274,12 @@ static int __init ks_pcie_probe(struct platform_device 
*pdev)
goto err_get_sync;
}
 
-   if (pci->version >= 0x480A) {
-   atu_base = devm_platform_ioremap_resource_byname(pdev, "atu");
-   if (IS_ERR(atu_base)) {
-   ret = PTR_ERR(atu_base);
-   goto err_get_sync;
-   }
-
-   pci->atu_base = atu_base;
-
+   if (pci->version >= 0x480A)
ret = ks_pcie_am654_set_mode(dev, mode);
-   if (ret < 0)
-   goto err_get_sync;
-   } else {
+   else
ret = ks_pcie_set_mode(dev);
-   if (ret < 0)
-   goto err_get_sync;
-   }
+   if (ret < 0)
+   goto err_get_sync;
 
switch (mode) {
case DW_PCIE_RC_TYPE:
-- 
2.7.4

[PATCH v3 0/4] PCI: dwc: Move iATU register mapping to common framework

[Kunihiko Hayashi]

This moves iATU register mapping in the Keystone driver to common
framework. And this adds "iatu" property description to the dt-bindings
for UniPhier PCIe host and endpoint controller.

This series is split from the previous patches:
https://www.spinics.net/lists/linux-pci/msg97608.html
"[PATCH v6 0/6] PCI: uniphier: Add features for UniPhier PCIe host controller"

This has been confirmed with PCIe version 4.80 controller on UniPhier platform.
Please comfirm this series on Keystone platform if necessary.

Changes since v2:
- dt-bindings: Fix errors from dt_binding_check

Changes since v1:
- Use to_platform_device() instead of of_find_device_by_node()
- Add Reviewed-by: line to 4th patch for keystone
- dt-bindings: Add description for uniphier-ep

Kunihiko Hayashi (4):
  dt-bindings: PCI: uniphier: Add iATU register description
  dt-bindings: PCI: uniphier-ep: Add iATU register description
  PCI: dwc: Add common iATU register support
  PCI: keystone: Remove iATU register mapping

 .../bindings/pci/socionext,uniphier-pcie-ep.yaml | 20 ++--
 .../devicetree/bindings/pci/uniphier-pcie.txt|  1 +
 drivers/pci/controller/dwc/pci-keystone.c| 20 
 drivers/pci/controller/dwc/pcie-designware.c |  5 +
 4 files changed, 24 insertions(+), 22 deletions(-)

-- 
2.7.4

[PATCH v3 1/4] dt-bindings: PCI: uniphier: Add iATU register description

[Kunihiko Hayashi]

In the dt-bindings, "atu" reg-names is required to get the register space
for iATU in Synopsys DWC version 4.80 or later.

Signed-off-by: Kunihiko Hayashi 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/pci/uniphier-pcie.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt 
b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
index 1fa2c59..c4b7381 100644
--- a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
@@ -16,6 +16,7 @@ Required properties:
 "dbi"- controller configuration registers
 "link"   - SoC-specific glue layer registers
 "config" - PCIe configuration space
+"atu"- iATU registers for DWC version 4.80 or later
 - clocks: A phandle to the clock gate for PCIe glue layer including
the host controller.
 - resets: A phandle to the reset line for PCIe glue layer including
-- 
2.7.4

Re: [PATCH v2 3/3] iommu/tegra-smmu: Add PCI support

[Nicolin Chen]

Hi Dmitry,

On Wed, Sep 30, 2020 at 08:10:07AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> > -   group->group = iommu_group_alloc();
> > +   group->group = pci ? pci_device_group(dev) : iommu_group_alloc();
> 
> This will be nicer to write as:
> 
> if (dev_is_pci(dev))
> group->group = pci_device_group(dev);
> else
> group->group = generic_device_group(dev);

Why is that nicer? I don't feel mine is hard to read at all...

Re: [PATCH 03/22] kvm: mmu: Init / Uninit the TDP MMU

[Sean Christopherson]

Nit on all the shortlogs, can you use "KVM: x86/mmu" instead of "kvm: mmu"?

On Fri, Sep 25, 2020 at 02:22:43PM -0700, Ben Gardon wrote:
> diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> new file mode 100644
> index 0..8241e18c111e6
> --- /dev/null
> +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#include "tdp_mmu.h"
> +
> +static bool __read_mostly tdp_mmu_enabled = true;
> +module_param_named(tdp_mmu, tdp_mmu_enabled, bool, 0644);

Do y'all actually toggle tdp_mmu_enabled while VMs are running?  I can see
having a per-VM capability, or a read-only module param, but a writable
module param is... interesting.

> +static bool is_tdp_mmu_enabled(void)
> +{
> + if (!READ_ONCE(tdp_mmu_enabled))
> + return false;
> +
> + if (WARN_ONCE(!tdp_enabled,
> +   "Creating a VM with TDP MMU enabled requires TDP."))

This should be enforced, i.e. clear tdp_mmu_enabled if !tdp_enabled.  As is,
it's a user triggerable WARN, which is not good, e.g. with PANIC_ON_WARN.

> + return false;
> +
> + return true;
> +}

Re: [PATCH 00/10] rpmsg: Make RPMSG name service modular

[Guennadi Liakhovetski]

Hi Mathieu,

On Mon, Sep 28, 2020 at 01:33:08PM -0600, Mathieu Poirier wrote:
> Hey Guennadi,
> 
> On Mon, Sep 28, 2020 at 11:49:42AM +0200, Guennadi Liakhovetski wrote:
> > (re-sending, mailing list delivery attempts last Friday failed)
> > 
> 
> I got your email on Friday but had to tend to other things.

Sure, no problem, you got it directly because you were on CC, but it didn't 
make it to the mailing lists - you can check archives, it isn't there :-/ 
But thanks to your reply now it's also on the lists.

> > Hi Mathieu,
> > 
> > On Thu, Sep 24, 2020 at 12:18:53PM -0600, Mathieu Poirier wrote:
> > > On Thu, Sep 24, 2020 at 08:53:56AM +0200, Guennadi Liakhovetski wrote:
> > 
> > [snip]
> > 
> > > > Yes, the current rpmsg-virtio code does create *one* rpmsg device when 
> > > > an NS announcement arrives.
> > > 
> > > Currently an rpmsg_device is created each time a NS announcement is 
> > > received.  
> > 
> > Are there really cases when an NS announcement is sent multiple times by a 
> > remote? But not for the same name-space, at least in virtio_rpmsg_bus.c 
> > there's a check for a duplicate announcement in rpmsg_create_channel().
> > 
> > > > Whereas with this patch set the first rpmsg 
> > > > device would be created to probe the NS service driver and the next one 
> > > > would still be created following the code borrowed from rpmsg-virtio 
> > > > when an NS announcement arrives. And I don't see how those two devices 
> > > > now make sense, sorry. I understand one device per channel, but two, of 
> > > > which one is for a certain endpoing only, whereas other endpoints don't 
> > > > create their devices, don't seem very logical to me.
> > > 
> > > In the current implementation the NS service channel is created 
> > > automatically
> > > when instantiating an rproc_vdev.
> > 
> > I think the terminology is slightly incorrect above. It isn't a channel, 
> > it's 
> > an endpoint. A channel is a synonym of a device in RPMsg (from rpmsg.txt):
> > 
> > "Every rpmsg device is a communication channel with a remote processor (thus
> > rpmsg devices are called channels)."
> > 
> > > An official rpmsg_device is not needed since
> > > it is implicit.
> > 
> > Agree.
> > 
> > > With this set (and as you noted above) an rpmsg_device to
> > > represent the NS service is registered, the same way other services such 
> > > as
> > > rpmsg_chrdev are.
> > 
> > Oh, I think I'm getting it now. I think now I understand where the 
> > disagreement lies. If I understand correctly in your model each remote 
> > processor can provide multiple *devices* / *channels*. E.g. a remote
> 
> That is correct
>  
> > processor can provide a character device, a network device etc. Each of 
> > those devices / channels would send a namespace announcement to the 
> > main processor, which then would create a respective device and probe 
> > the respective driver - all with the same remote processor over the same 
> > RPMsg bus. I understand this concept and in fact I find it logical.
> > 
> 
> Ok
> 
> > However, since I have no experience with real life RPMsg implementations 
> > I am basing my understanding of RPMsg on the little and scarce and 
> > non-conclusive documentation that I can find online. E.g. on
> > 
> > https://github.com/OpenAMP/open-amp/wiki/RPMsg-Messaging-Protocol
> > 
> > which says:
> > 
> > "Every remote core in RPMsg component is represented by RPMsg device that 
> > provides a communication channel between master and remote, hence RPMsg 
> > devices are also known as channels"
> > 
> > So, according to that definition you cannot have a remote processor, 
> > doing both a character and a network devices. However, in kernel's 
> > rpmsg.txt an *almost exact* copy of that sentence is the quote, that 
> > I've already provided above, with a subtle but important difference:
> > 
> > "Every rpmsg device is a communication channel with a remote processor 
> > (thus rpmsg devices are called channels)."
> 
> The documentation isn't easy to follow and personally got very confused when I
> started getting involved with the remoteproc/rpmsg subsystems.  I have the
> intention of doing a good revamp but there is never enough time. 
> 
> > 
> > It doesn't explicitly say, that there can be multiple devices per 
> > remote processor, but it doesn't specify, that there can be only one 
> > (TM) either, so, implicitly there can be many :-/ So, with this model, 
> > yes, I can understand, how a single instance of the RPMsg bus (in 
> > VirtIO case a pair of virtual queues) can have just *one* namespace 
> > service and serve *multiple* devices channels. In that case yes, the 
> > namespace service can be a separate device.
> 
> I will spin off a V2 of this set and we'll go from there.  I also want to get 
> a
> look at Kishon's patchset that Arnaud and Vincent were referring to before
> making up my mind about how to move foward with your vhost RPMSG API patchset.

I should have a look at the remaining patches from your 

Re: [PATCH v2 3/3] iommu/tegra-smmu: Add PCI support

[Nicolin Chen]

On Wed, Sep 30, 2020 at 08:10:00AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> ...
> > +#ifdef CONFIG_PCI
> > +   if (!iommu_present(_bus_type)) {
> 
> Could you please explain why this check is needed?

That's referencing what's in the arm-smmu.c file, since it does
not hurt to have a check.

Re: [PATCH 1/2] iio: adc: at91_adc: use of_device_get_match_data() helper

[Alexandru Ardelean]

On Tue, Sep 29, 2020 at 6:55 PM Jonathan Cameron  wrote:
>
> On Mon, 28 Sep 2020 15:54:23 +0300
> Alexandru Ardelean  wrote:
>
> > This tries to solve a warning reported by the lkp bot:
> >
> > >> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable
> > >> 'at91_adc_dt_ids' [-Wunused-const-variable]
> >static const struct of_device_id at91_adc_dt_ids[] = {
> > ^
> >1 warning generated.
> >
> > This shows up with 'compiler: clang version 12.0.0' and W=1 (as the bot
> > mentions).
> >
> > Forward declarations for global variables can be a bit weird; forward
> > function declarations are more common.
> Hi,
>
> That's not the forward declaration that it is complaining about...

Also, silly me here.
I was just annoyed with the email from the bot, so I didn't dig too
deep to understand.

>
> It's a reasonable patch anyway, but doesn't fix that warning which is
> about of_match_ptr and the lack of #ifdef CONFIG_OF around the
> actual definition.
>
> For the bug warning, I'd add add a Kconfig dependency on OF.
> It doesn't make any sense to allow building this driver without that.
>
> So resend this as a simple tidy up patch and another one adding
> that build dependency.
>
> Thanks,
>
> Jonathan
>
> >
> > Maybe another fix for this would have been to prefix with 'extern' the
> > 'at91_adc_dt_ids' variable, thus making it more friendly as a forward
> > declaration. It would look weird, but it would work.
> >
> > But, we can avoid that forward declaration altogether simply by obtaining
> > the private data with of_device_get_match_data().
> >
> > This appeared after commit 4027860dcc4c ("iio: Kconfig: at91_adc: add
> > COMPILE_TEST dependency to driver"), which put this driver on the lkp's bot
> > radar.
> >
> > Reported-by: kernel test robot 
> > Signed-off-by: Alexandru Ardelean 
> > ---
> >  drivers/iio/adc/at91_adc.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> > index 9b2c548fae95..c9ec0a4a357e 100644
> > --- a/drivers/iio/adc/at91_adc.c
> > +++ b/drivers/iio/adc/at91_adc.c
> > @@ -829,8 +829,6 @@ static u32 calc_startup_ticks_9x5(u32 startup_time, u32 
> > adc_clk_khz)
> >   return ticks;
> >  }
> >
> > -static const struct of_device_id at91_adc_dt_ids[];
> > -
> >  static int at91_adc_probe_dt_ts(struct device_node *node,
> >   struct at91_adc_state *st, struct device *dev)
> >  {
> > @@ -878,8 +876,7 @@ static int at91_adc_probe_dt(struct iio_dev *idev,
> >   if (!node)
> >   return -EINVAL;
> >
> > - st->caps = (struct at91_adc_caps *)
> > - of_match_device(at91_adc_dt_ids, >dev)->data;
> > + st->caps = (struct at91_adc_caps 
> > *)of_device_get_match_data(>dev);
> >
> >   st->use_external = of_property_read_bool(node, 
> > "atmel,adc-use-external-triggers");
> >
>

Re: [PATCH 1/2] iio: adc: at91_adc: use of_device_get_match_data() helper

[Alexandru Ardelean]

On Tue, Sep 29, 2020 at 6:55 PM Jonathan Cameron  wrote:
>
> On Mon, 28 Sep 2020 15:54:23 +0300
> Alexandru Ardelean  wrote:
>
> > This tries to solve a warning reported by the lkp bot:
> >
> > >> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable
> > >> 'at91_adc_dt_ids' [-Wunused-const-variable]
> >static const struct of_device_id at91_adc_dt_ids[] = {
> > ^
> >1 warning generated.
> >
> > This shows up with 'compiler: clang version 12.0.0' and W=1 (as the bot
> > mentions).
> >
> > Forward declarations for global variables can be a bit weird; forward
> > function declarations are more common.
> Hi,
>
> That's not the forward declaration that it is complaining about...
>
> It's a reasonable patch anyway, but doesn't fix that warning which is
> about of_match_ptr and the lack of #ifdef CONFIG_OF around the
> actual definition.
>
> For the bug warning, I'd add add a Kconfig dependency on OF.
> It doesn't make any sense to allow building this driver without that.
>
> So resend this as a simple tidy up patch and another one adding
> that build dependency.
>

At this point it might make sense to also remove the of_match_ptr() helper.
If adding the OF build dependency, the of_match_ptr() would always
return non-NULL.

> Thanks,
>
> Jonathan
>
> >
> > Maybe another fix for this would have been to prefix with 'extern' the
> > 'at91_adc_dt_ids' variable, thus making it more friendly as a forward
> > declaration. It would look weird, but it would work.
> >
> > But, we can avoid that forward declaration altogether simply by obtaining
> > the private data with of_device_get_match_data().
> >
> > This appeared after commit 4027860dcc4c ("iio: Kconfig: at91_adc: add
> > COMPILE_TEST dependency to driver"), which put this driver on the lkp's bot
> > radar.
> >
> > Reported-by: kernel test robot 
> > Signed-off-by: Alexandru Ardelean 
> > ---
> >  drivers/iio/adc/at91_adc.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> > index 9b2c548fae95..c9ec0a4a357e 100644
> > --- a/drivers/iio/adc/at91_adc.c
> > +++ b/drivers/iio/adc/at91_adc.c
> > @@ -829,8 +829,6 @@ static u32 calc_startup_ticks_9x5(u32 startup_time, u32 
> > adc_clk_khz)
> >   return ticks;
> >  }
> >
> > -static const struct of_device_id at91_adc_dt_ids[];
> > -
> >  static int at91_adc_probe_dt_ts(struct device_node *node,
> >   struct at91_adc_state *st, struct device *dev)
> >  {
> > @@ -878,8 +876,7 @@ static int at91_adc_probe_dt(struct iio_dev *idev,
> >   if (!node)
> >   return -EINVAL;
> >
> > - st->caps = (struct at91_adc_caps *)
> > - of_match_device(at91_adc_dt_ids, >dev)->data;
> > + st->caps = (struct at91_adc_caps 
> > *)of_device_get_match_data(>dev);
> >
> >   st->use_external = of_property_read_bool(node, 
> > "atmel,adc-use-external-triggers");
> >
>

Re: [PATCH] [v2] wireless: Initial driver submission for pureLiFi devices

[Srinivasan Raju]

> I stopped here.
>
> Thanks

Thanks for your comments Leon, I will resubmit after the changes

Thanks
Srini

[tip: efi/urgent] efi: Add definition of EFI_MEMORY_CPU_CRYPTO and ability to report it

[tip-bot2 for Ard Biesheuvel]

The following commit has been merged into the efi/urgent branch of tip:

Commit-ID: 6277e374b0b07c1a93c829f0a27e38739b3b7a1b
Gitweb:
https://git.kernel.org/tip/6277e374b0b07c1a93c829f0a27e38739b3b7a1b
Author:Ard Biesheuvel 
AuthorDate:Thu, 24 Sep 2020 13:52:24 +02:00
Committer: Ard Biesheuvel 
CommitterDate: Fri, 25 Sep 2020 23:29:04 +02:00

efi: Add definition of EFI_MEMORY_CPU_CRYPTO and ability to report it

Incorporate the definition of EFI_MEMORY_CPU_CRYPTO from the UEFI
specification v2.8, and wire it into our memory map dumping routine
as well.

To make a bit of space in the output buffer, which is provided by
the various callers, shorten the descriptive names of the memory
types.

Reviewed-by: Laszlo Ersek 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/efi.c | 47 ++---
 include/linux/efi.h|  1 +-
 2 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 3aa07c3..ebb59e5 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -714,7 +714,7 @@ void __init efi_systab_report_header(const efi_table_hdr_t 
*systab_hdr,
vendor);
 }
 
-static __initdata char memory_type_name[][20] = {
+static __initdata char memory_type_name[][13] = {
"Reserved",
"Loader Code",
"Loader Data",
@@ -722,14 +722,14 @@ static __initdata char memory_type_name[][20] = {
"Boot Data",
"Runtime Code",
"Runtime Data",
-   "Conventional Memory",
-   "Unusable Memory",
-   "ACPI Reclaim Memory",
-   "ACPI Memory NVS",
-   "Memory Mapped I/O",
-   "MMIO Port Space",
+   "Conventional",
+   "Unusable",
+   "ACPI Reclaim",
+   "ACPI Mem NVS",
+   "MMIO",
+   "MMIO Port",
"PAL Code",
-   "Persistent Memory",
+   "Persistent",
 };
 
 char * __init efi_md_typeattr_format(char *buf, size_t size,
@@ -756,26 +756,27 @@ char * __init efi_md_typeattr_format(char *buf, size_t 
size,
if (attr & ~(EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT |
 EFI_MEMORY_WB | EFI_MEMORY_UCE | EFI_MEMORY_RO |
 EFI_MEMORY_WP | EFI_MEMORY_RP | EFI_MEMORY_XP |
-EFI_MEMORY_NV | EFI_MEMORY_SP |
+EFI_MEMORY_NV | EFI_MEMORY_SP | EFI_MEMORY_CPU_CRYPTO |
 EFI_MEMORY_RUNTIME | EFI_MEMORY_MORE_RELIABLE))
snprintf(pos, size, "|attr=0x%016llx]",
 (unsigned long long)attr);
else
snprintf(pos, size,
-
"|%3s|%2s|%2s|%2s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
-attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
-attr & EFI_MEMORY_MORE_RELIABLE ? "MR" : "",
-attr & EFI_MEMORY_SP  ? "SP"  : "",
-attr & EFI_MEMORY_NV  ? "NV"  : "",
-attr & EFI_MEMORY_XP  ? "XP"  : "",
-attr & EFI_MEMORY_RP  ? "RP"  : "",
-attr & EFI_MEMORY_WP  ? "WP"  : "",
-attr & EFI_MEMORY_RO  ? "RO"  : "",
-attr & EFI_MEMORY_UCE ? "UCE" : "",
-attr & EFI_MEMORY_WB  ? "WB"  : "",
-attr & EFI_MEMORY_WT  ? "WT"  : "",
-attr & EFI_MEMORY_WC  ? "WC"  : "",
-attr & EFI_MEMORY_UC  ? "UC"  : "");
+
"|%3s|%2s|%2s|%2s|%2s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
+attr & EFI_MEMORY_RUNTIME  ? "RUN" : "",
+attr & EFI_MEMORY_MORE_RELIABLE? "MR"  : "",
+attr & EFI_MEMORY_CPU_CRYPTO   ? "CC"  : "",
+attr & EFI_MEMORY_SP   ? "SP"  : "",
+attr & EFI_MEMORY_NV   ? "NV"  : "",
+attr & EFI_MEMORY_XP   ? "XP"  : "",
+attr & EFI_MEMORY_RP   ? "RP"  : "",
+attr & EFI_MEMORY_WP   ? "WP"  : "",
+attr & EFI_MEMORY_RO   ? "RO"  : "",
+attr & EFI_MEMORY_UCE  ? "UCE" : "",
+attr & EFI_MEMORY_WB   ? "WB"  : "",
+attr & EFI_MEMORY_WT   ? "WT"  : "",
+attr & EFI_MEMORY_WC   ? "WC"  : "",
+attr & EFI_MEMORY_UC   ? "UC"  : "");
return buf;
 }
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 73db1ae..f216c02 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -122,6 +122,7 @@ typedef struct {

[tip: efi/urgent] efi/arm64: libstub: Deal gracefully with EFI_RNG_PROTOCOL failure

[tip-bot2 for Ard Biesheuvel]

The following commit has been merged into the efi/urgent branch of tip:

Commit-ID: d32de9130f6c79533508e2c7879f18997bfbe2a0
Gitweb:
https://git.kernel.org/tip/d32de9130f6c79533508e2c7879f18997bfbe2a0
Author:Ard Biesheuvel 
AuthorDate:Sat, 26 Sep 2020 10:52:42 +02:00
Committer: Ard Biesheuvel 
CommitterDate: Tue, 29 Sep 2020 15:41:52 +02:00

efi/arm64: libstub: Deal gracefully with EFI_RNG_PROTOCOL failure

Currently, on arm64, we abort on any failure from efi_get_random_bytes()
other than EFI_NOT_FOUND when it comes to setting the physical seed for
KASLR, but ignore such failures when obtaining the seed for virtual
KASLR or for early seeding of the kernel's entropy pool via the config
table. This is inconsistent, and may lead to unexpected boot failures.

So let's permit any failure for the physical seed, and simply report
the error code if it does not equal EFI_NOT_FOUND.

Cc:  # v5.8+
Reported-by: Heinrich Schuchardt 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/libstub/arm64-stub.c | 8 +---
 drivers/firmware/efi/libstub/fdt.c| 4 +---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm64-stub.c 
b/drivers/firmware/efi/libstub/arm64-stub.c
index e5bfac7..04f5d79 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -62,10 +62,12 @@ efi_status_t handle_kernel_image(unsigned long *image_addr,
status = efi_get_random_bytes(sizeof(phys_seed),
  (u8 *)_seed);
if (status == EFI_NOT_FOUND) {
-   efi_info("EFI_RNG_PROTOCOL unavailable, no 
randomness supplied\n");
+   efi_info("EFI_RNG_PROTOCOL unavailable, KASLR 
will be disabled\n");
+   efi_nokaslr = true;
} else if (status != EFI_SUCCESS) {
-   efi_err("efi_get_random_bytes() failed\n");
-   return status;
+   efi_err("efi_get_random_bytes() failed (0x%lx), 
KASLR will be disabled\n",
+   status);
+   efi_nokaslr = true;
}
} else {
efi_info("KASLR disabled on kernel command line\n");
diff --git a/drivers/firmware/efi/libstub/fdt.c 
b/drivers/firmware/efi/libstub/fdt.c
index 11ecf3c..368cd60 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -136,7 +136,7 @@ static efi_status_t update_fdt(void *orig_fdt, unsigned 
long orig_fdt_size,
if (status)
goto fdt_set_fail;
 
-   if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
+   if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && !efi_nokaslr) {
efi_status_t efi_status;
 
efi_status = efi_get_random_bytes(sizeof(fdt_val64),
@@ -145,8 +145,6 @@ static efi_status_t update_fdt(void *orig_fdt, unsigned 
long orig_fdt_size,
status = fdt_setprop_var(fdt, node, "kaslr-seed", 
fdt_val64);
if (status)
goto fdt_set_fail;
-   } else if (efi_status != EFI_NOT_FOUND) {
-   return efi_status;
}
}
 

[tip: efi/urgent] efi/libstub: Fix missing-prototypes in string.c

[tip-bot2 for Tian Tao]

The following commit has been merged into the efi/urgent branch of tip:

Commit-ID: aad0f3d693bbb356b9478879ecd245d4f7a2beb0
Gitweb:
https://git.kernel.org/tip/aad0f3d693bbb356b9478879ecd245d4f7a2beb0
Author:Tian Tao 
AuthorDate:Mon, 21 Sep 2020 09:53:23 +08:00
Committer: Ard Biesheuvel 
CommitterDate: Fri, 25 Sep 2020 23:29:04 +02:00

efi/libstub: Fix missing-prototypes in string.c

Fix the following warnings.
drivers/firmware/efi/libstub/string.c:83:20: warning: no previous
prototype for ‘simple_strtoull’ [-Wmissing-prototypes]
drivers/firmware/efi/libstub/string.c:108:6: warning: no previous
prototype for ‘simple_strtol’ [-Wmissing-prototypes]

Signed-off-by: Tian Tao 
Link: 
https://lore.kernel.org/r/1600653203-57909-1-git-send-email-tiant...@hisilicon.com
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/libstub/string.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/efi/libstub/string.c 
b/drivers/firmware/efi/libstub/string.c
index 1ac2f87..5d13e43 100644
--- a/drivers/firmware/efi/libstub/string.c
+++ b/drivers/firmware/efi/libstub/string.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 

[tip: efi/urgent] efi: Delete deprecated parameter comments

[tip-bot2 for Tian Tao]

The following commit has been merged into the efi/urgent branch of tip:

Commit-ID: f5344e5d6ccb9ddf377202690a135bc64607c621
Gitweb:
https://git.kernel.org/tip/f5344e5d6ccb9ddf377202690a135bc64607c621
Author:Tian Tao 
AuthorDate:Thu, 24 Sep 2020 10:20:18 +08:00
Committer: Ard Biesheuvel 
CommitterDate: Fri, 25 Sep 2020 23:29:04 +02:00

efi: Delete deprecated parameter comments

Delete deprecated parameter comments to  fix warnings reported by make
W=1.
drivers/firmware/efi/vars.c:428: warning: Excess function parameter
'atomic' description in 'efivar_init'

Signed-off-by: Tian Tao 
Link: 
https://lore.kernel.org/r/1600914018-12697-1-git-send-email-tiant...@hisilicon.com
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/vars.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 973eef2..274b0ee 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -414,7 +414,6 @@ static void dup_variable_bug(efi_char16_t *str16, 
efi_guid_t *vendor_guid,
  * efivar_init - build the initial list of EFI variables
  * @func: callback function to invoke for every variable
  * @data: function-specific data to pass to @func
- * @atomic: do we need to execute the @func-loop atomically?
  * @duplicates: error if we encounter duplicates on @head?
  * @head: initialised head of variable list
  *

[tip: efi/urgent] efivarfs: Replace invalid slashes with exclamation marks in dentries.

[tip-bot2 for Michael Schaller]

The following commit has been merged into the efi/urgent branch of tip:

Commit-ID: 336af6a4686d885a067ecea8c3c3dd129ba4fc75
Gitweb:
https://git.kernel.org/tip/336af6a4686d885a067ecea8c3c3dd129ba4fc75
Author:Michael Schaller 
AuthorDate:Fri, 25 Sep 2020 09:45:02 +02:00
Committer: Ard Biesheuvel 
CommitterDate: Fri, 25 Sep 2020 23:29:04 +02:00

efivarfs: Replace invalid slashes with exclamation marks in dentries.

Without this patch efivarfs_alloc_dentry creates dentries with slashes in
their name if the respective EFI variable has slashes in its name. This in
turn causes EIO on getdents64, which prevents a complete directory listing
of /sys/firmware/efi/efivars/.

This patch replaces the invalid shlashes with exclamation marks like
kobject_set_name_vargs does for /sys/firmware/efi/vars/ to have consistently
named dentries under /sys/firmware/efi/vars/ and /sys/firmware/efi/efivars/.

Signed-off-by: Michael Schaller 
Link: https://lore.kernel.org/r/20200925074502.150448-1-mi...@google.com
Signed-off-by: Ard Biesheuvel 
---
 fs/efivarfs/super.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
index 28bb568..15880a6 100644
--- a/fs/efivarfs/super.c
+++ b/fs/efivarfs/super.c
@@ -141,6 +141,9 @@ static int efivarfs_callback(efi_char16_t *name16, 
efi_guid_t vendor,
 
name[len + EFI_VARIABLE_GUID_LEN+1] = '\0';
 
+   /* replace invalid slashes like kobject_set_name_vargs does for 
/sys/firmware/efi/vars. */
+   strreplace(name, '/', '!');
+
inode = efivarfs_get_inode(sb, d_inode(root), S_IFREG | 0644, 0,
   is_removable);
if (!inode)

Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers

[Jiri Slaby]

On 29. 09. 20, 14:34, Peilin Ye wrote:
> the work in general? I couldn't think of how do we clean up subsystems
> one by one, while keeping a `console_font` in `struct vc_data`.

Hi,

feel free to change struct vc_data's content as you need, of course.
Only the UAPI _definitions_ have to be preserved (like struct console_font).

thanks,
-- 
js
suse labs

Re: [PATCH v3 2/2] hwmon: pmbus: max20730: adjust the vout reading given voltage divider

[Guenter Roeck]

On Thu, Sep 24, 2020 at 09:54:44PM +, Chu Lin wrote:
> Problem:
> We use voltage dividers so that the voltage presented at the voltage
> sense pins is confusing. We might need to convert these readings to more
> meaningful readings given the voltage divider.
> 
> Solution:
> Read the voltage divider resistance from dts and convert the voltage
> reading to a more meaningful reading.
> 
> Testing:
> max20730 with voltage divider
> 
> Signed-off-by: Chu Lin 
> ---

  
Change log goes here. If it is missing, I won't know what changed.
That means I will have to dig out older patch versions to compare.
That costs time and will hold up both this patch as well as all other
patches which I still have to review.

Please keep this in mind when submitting patch revisions without change log.


Worse, this is v3, and I had given v2 a Reviewed-by: tag which was dropped.
This means I have to compare the two versions to figure out what changed,
probably just to find out that nothing has changed since v2.

Patches like this are the reason why various patches won't make it into
the next kernel release. Sorry, I just don't have as much time as people
seem to think I have.

Guenter

>  drivers/hwmon/pmbus/max20730.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/hwmon/pmbus/max20730.c b/drivers/hwmon/pmbus/max20730.c
> index a151a2b588a5..fbf2f1e6c969 100644
> --- a/drivers/hwmon/pmbus/max20730.c
> +++ b/drivers/hwmon/pmbus/max20730.c
> @@ -31,6 +31,7 @@ struct max20730_data {
>   struct pmbus_driver_info info;
>   struct mutex lock;  /* Used to protect against parallel writes */
>   u16 mfr_devset1;
> + u32 vout_voltage_divider[2];
>  };
>  
>  #define to_max20730_data(x)  container_of(x, struct max20730_data, info)
> @@ -114,6 +115,14 @@ static int max20730_read_word_data(struct i2c_client 
> *client, int page,
>   max_c = max_current[data->id][(data->mfr_devset1 >> 5) & 0x3];
>   ret = val_to_direct(max_c, PSC_CURRENT_OUT, info);
>   break;
> + case PMBUS_READ_VOUT:
> + ret = pmbus_read_word_data(client, page, phase, reg);
> + if (ret > 0 && data->vout_voltage_divider[0] && 
> data->vout_voltage_divider[1]) {
> + u64 temp = DIV_ROUND_CLOSEST_ULL((u64)ret * 
> data->vout_voltage_divider[1],
> +  
> data->vout_voltage_divider[0]);
> + ret = clamp_val(temp, 0, 0x);
> + }
> + break;
>   default:
>   ret = -ENODATA;
>   break;
> @@ -364,6 +373,15 @@ static int max20730_probe(struct i2c_client *client,
>   data->id = chip_id;
>   mutex_init(>lock);
>   memcpy(>info, _info[chip_id], sizeof(data->info));
> + if (of_property_read_u32_array(client->dev.of_node, 
> "vout-voltage-divider",
> +data->vout_voltage_divider,
> +ARRAY_SIZE(data->vout_voltage_divider)) 
> != 0)
> + memset(data->vout_voltage_divider, 0, 
> sizeof(data->vout_voltage_divider));
> + if (data->vout_voltage_divider[1] < data->vout_voltage_divider[0]) {
> + dev_err(dev,
> + "The total resistance of voltage divider is less than 
> output resistance\n");
> + return -ENODEV;
> + }
>  
>   ret = i2c_smbus_read_word_data(client, MAX20730_MFR_DEVSET1);
>   if (ret < 0)

Re: [PATCH 02/22] kvm: mmu: Introduce tdp_iter

[Sean Christopherson]

On Fri, Sep 25, 2020 at 02:22:42PM -0700, Ben Gardon wrote:
> diff --git a/arch/x86/kvm/mmu/tdp_iter.c b/arch/x86/kvm/mmu/tdp_iter.c
> new file mode 100644
> index 0..ee90d62d2a9b1
> --- /dev/null
> +++ b/arch/x86/kvm/mmu/tdp_iter.c
> @@ -0,0 +1,163 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#include "mmu_internal.h"
> +#include "tdp_iter.h"
> +
> +/*
> + * Recalculates the pointer to the SPTE for the current GFN and level and
> + * reread the SPTE.
> + */
> +static void tdp_iter_refresh_sptep(struct tdp_iter *iter)
> +{
> + iter->sptep = iter->pt_path[iter->level - 1] +
> + SHADOW_PT_INDEX(iter->gfn << PAGE_SHIFT, iter->level);
> + iter->old_spte = READ_ONCE(*iter->sptep);
> +}
> +
> +/*
> + * Sets a TDP iterator to walk a pre-order traversal of the paging structure
> + * rooted at root_pt, starting with the walk to translate goal_gfn.
> + */
> +void tdp_iter_start(struct tdp_iter *iter, u64 *root_pt, int root_level,
> + gfn_t goal_gfn)
> +{
> + WARN_ON(root_level < 1);
> + WARN_ON(root_level > PT64_ROOT_MAX_LEVEL);
> +
> + iter->goal_gfn = goal_gfn;
> + iter->root_level = root_level;
> + iter->level = root_level;
> + iter->pt_path[iter->level - 1] = root_pt;
> +
> + iter->gfn = iter->goal_gfn -
> + (iter->goal_gfn % KVM_PAGES_PER_HPAGE(iter->level));

Maybe use the params, if only to avoid the line wrap?

iter->gfn = goal_gfn - (goal_gfn % KVM_PAGES_PER_HPAGE(root_level));

Actually, peeking further into the file, this calculation is repeated in both
try_step_up and try_step_down,  probably worth adding a helper of some form.

> + tdp_iter_refresh_sptep(iter);
> +
> + iter->valid = true;
> +}
> +
> +/*
> + * Given an SPTE and its level, returns a pointer containing the host virtual
> + * address of the child page table referenced by the SPTE. Returns null if
> + * there is no such entry.
> + */
> +u64 *spte_to_child_pt(u64 spte, int level)
> +{
> + u64 *pt;
> + /* There's no child entry if this entry isn't present */
> + if (!is_shadow_present_pte(spte))
> + return NULL;
> +
> + /* There is no child page table if this is a leaf entry. */
> + if (is_last_spte(spte, level))
> + return NULL;

I'd collapse the checks and their comments.

> +
> + pt = (u64 *)__va(spte_to_pfn(spte) << PAGE_SHIFT);
> + return pt;

No need for the local variable or the explicit cast.

/* There's no child if this entry is non-present or a leaf entry. */
if (!is_shadow_present_pte(spte) || is_last_spte(spte, level))
return NULL;

return __va(spte_to_pfn(spte) << PAGE_SHIFT);

> +}

...

> +void tdp_iter_next(struct tdp_iter *iter)
> +{
> + bool done;
> +
> + done = try_step_down(iter);
> + if (done)
> + return;
> +
> + done = try_step_side(iter);
> + while (!done) {
> + if (!try_step_up(iter)) {
> + iter->valid = false;
> + break;
> + }
> + done = try_step_side(iter);
> + }

At the risk of being too clever:

bool done;

if (try_step_down(iter))
return;

do {
done = try_step_side(iter);
} while (!done && try_step_up(iter));

iter->valid = done;

> +}

Re: [PATCH v2 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Dmitry Osipenko]

30.09.2020 03:30, Nicolin Chen пишет:
> + /*
> +  * IOMMU core allows -ENODEV return to carry on. So bypass any call
> +  * from bus_set_iommu() during tegra_smmu_probe(), as a device will
> +  * call in again via of_iommu_configure when fwspec is prepared.
> +  */
> + if (!mc->smmu || !fwspec || fwspec->ops != _smmu_ops)
>   return ERR_PTR(-ENODEV);

The !mc->smmu can't be true.

RE: [PATCH 2/8] usb: cdns3: Split core.c into cdns3-plat and core.c file

[Pawel Laszczak]

>
>On Mon, 2020-09-28 at 14:27 +0200, Pawel Laszczak wrote:
>> Patch splits file core.c into core.c containing the common reusable code
>> and cnd3-plat.c containing device platform specific code. These changes
>> are required to make possible reuse DRD part of CDNS3 driver in CDNSP
>> driver.
>>
>> Signed-off-by: Pawel Laszczak 
>> ---
>>  drivers/usb/cdns3/Makefile |   2 +-
>>  drivers/usb/cdns3/cdns3-plat.c | 209 +
>>  drivers/usb/cdns3/core.c   | 181 +++-
>>  drivers/usb/cdns3/core.h   |   8 +-
>>  4 files changed, 234 insertions(+), 166 deletions(-)
>>  create mode 100644 drivers/usb/cdns3/cdns3-plat.c
>>
>> diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
>> index d47e341a6f39..a1fe9612053a 100644
>> --- a/drivers/usb/cdns3/Makefile
>> +++ b/drivers/usb/cdns3/Makefile
>> @@ -2,7 +2,7 @@
>>  # define_trace.h needs to know how to find our header
>>  CFLAGS_trace.o  := -I$(src)
>>
>> -cdns3-y := core.o drd.o
>> +cdns3-y := cdns3-plat.o core.o drd.o
>>
>>  obj-$(CONFIG_USB_CDNS3) += cdns3.o
>>  cdns3-$(CONFIG_USB_CDNS3_GADGET)+= gadget.o ep0.o
>> diff --git a/drivers/usb/cdns3/cdns3-plat.c b/drivers/usb/cdns3/cdns3-plat.c
>> new file mode 100644
>> index ..f35e9dca30fe
>> --- /dev/null
>> +++ b/drivers/usb/cdns3/cdns3-plat.c
>> @@ -0,0 +1,209 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Cadence USBSS DRD Driver.
>> + *
>> + * Copyright (C) 2018-2020 Cadence.
>> + * Copyright (C) 2017-2018 NXP
>> + * Copyright (C) 2019 Texas Instrumentsq
>> + *
>> + *
>> + * Author: Peter Chen 
>> + * Pawel Laszczak 
>> + * Roger Quadros 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "core.h"
>> +
>> +/**
>> + * cdns3_plat_probe - probe for cdns3 core device
>> + * @pdev: Pointer to cdns3 core platform device
>> + *
>> + * Returns 0 on success otherwise negative errno
>> + */
>> +static int cdns3_plat_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = >dev;
>> +struct resource *res;
>> +struct cdns3 *cdns;
>> +void __iomem *regs;
>> +int ret;
>> +
>> +cdns = devm_kzalloc(dev, sizeof(*cdns), GFP_KERNEL);
>> +if (!cdns)
>> +return -ENOMEM;
>> +
>> +cdns->dev = dev;
>> +
>> +platform_set_drvdata(pdev, cdns);
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "host");
>> +if (!res) {
>> +dev_err(dev, "missing host IRQ\n");
>> +return -ENODEV;
>> +}
>> +
>> +cdns->xhci_res[0] = *res;
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "xhci");
>> +if (!res) {
>> +dev_err(dev, "couldn't get xhci resource\n");
>> +return -ENXIO;
>> +}
>> +
>> +cdns->xhci_res[1] = *res;
>> +
>> +cdns->dev_irq = platform_get_irq_byname(pdev, "peripheral");
>> +if (cdns->dev_irq == -EPROBE_DEFER)
>> +return cdns->dev_irq;
>> +
>> +if (cdns->dev_irq < 0)
>> +dev_err(dev, "couldn't get peripheral irq\n");
>Use platform_get_irq_byname_optional? otherwise no need print this log,
>platform_get_irq_byname() will print it.

Hi Chnfeng, 

It's the original code from core.c file. I don't want to change any part of 
code 
in original code core.c, except what is necessary to make the code reusable.
Maybe the better choice is to fix it in separate patch. 
I will send such patch before next version. 

Thanks 

>
>> +
>> +regs = devm_platform_ioremap_resource_byname(pdev, "dev");
>> +if (IS_ERR(regs))
>> +return PTR_ERR(regs);
>> +cdns->dev_regs  = regs;
>> +
>> +cdns->otg_irq = platform_get_irq_byname(pdev, "otg");
>> +if (cdns->otg_irq == -EPROBE_DEFER)
>> +return cdns->otg_irq;
>> +
>> +if (cdns->otg_irq < 0) {
>> +dev_err(dev, "couldn't get otg irq\n");
>> +return cdns->otg_irq;
>> +}
>ditto
>
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otg");
>> +if (!res) {
>> +dev_err(dev, "couldn't get otg resource\n");
>> +return -ENXIO;
>> +}
>> +
>> +cdns->otg_res = *res;
>> +
>> +cdns->usb2_phy = devm_phy_optional_get(dev, "cdns3,usb2-phy");
>> +if (IS_ERR(cdns->usb2_phy))
>> +return PTR_ERR(cdns->usb2_phy);
>> +
>> +ret = phy_init(cdns->usb2_phy);
>> +if (ret)
>> +return ret;
>> +
>> +cdns->usb3_phy = devm_phy_optional_get(dev, "cdns3,usb3-phy");
>> +if (IS_ERR(cdns->usb3_phy))
>> +return PTR_ERR(cdns->usb3_phy);
>> +
>> +ret = phy_init(cdns->usb3_phy);
>> +if (ret)
>> +goto err_phy3_init;
>> +
>> +ret = phy_power_on(cdns->usb2_phy);
>> +if (ret)
>> +goto err_phy2_power_on;
>> +
>> +ret = phy_power_on(cdns->usb3_phy);
>> +if (ret)

[tip: efi/core] efi: pstore: disentangle from deprecated efivars module

[tip-bot2 for Ard Biesheuvel]

The following commit has been merged into the efi/core branch of tip:

Commit-ID: 232f4eb6393f42f7f9418560ae9228e747fc6faf
Gitweb:
https://git.kernel.org/tip/232f4eb6393f42f7f9418560ae9228e747fc6faf
Author:Ard Biesheuvel 
AuthorDate:Wed, 23 Sep 2020 09:56:14 +02:00
Committer: Ard Biesheuvel 
CommitterDate: Tue, 29 Sep 2020 19:40:57 +02:00

efi: pstore: disentangle from deprecated efivars module

The EFI pstore implementation relies on the 'efivars' abstraction,
which encapsulates the EFI variable store in a way that can be
overridden by other backing stores, like the Google SMI one.

On top of that, the EFI pstore implementation also relies on the
efivars.ko module, which is a separate layer built on top of the
'efivars' abstraction that exposes the [deprecated] sysfs entries
for each variable that exists in the backing store.

Since the efivars.ko module is deprecated, and all users appear to
have moved to the efivarfs file system instead, let's prepare for
its removal, by removing EFI pstore's dependency on it.

Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/Kconfig  |  2 +-
 drivers/firmware/efi/efi-pstore.c | 76 --
 drivers/firmware/efi/efivars.c| 41 +
 include/linux/efi.h   |  4 +--
 4 files changed, 74 insertions(+), 49 deletions(-)

diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 3939699..dd8d108 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -26,7 +26,7 @@ config EFI_ESRT
 
 config EFI_VARS_PSTORE
tristate "Register efivars backend for pstore"
-   depends on EFI_VARS && PSTORE
+   depends on PSTORE
default y
help
  Say Y here to enable use efivars as a backend to pstore. This
diff --git a/drivers/firmware/efi/efi-pstore.c 
b/drivers/firmware/efi/efi-pstore.c
index feb7fe6..785f5e6 100644
--- a/drivers/firmware/efi/efi-pstore.c
+++ b/drivers/firmware/efi/efi-pstore.c
@@ -8,6 +8,8 @@
 
 #define DUMP_NAME_LEN 66
 
+#define EFIVARS_DATA_SIZE_MAX 1024
+
 static bool efivars_pstore_disable =
IS_ENABLED(CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE);
 
@@ -18,6 +20,8 @@ module_param_named(pstore_disable, efivars_pstore_disable, 
bool, 0644);
 EFI_VARIABLE_BOOTSERVICE_ACCESS | \
 EFI_VARIABLE_RUNTIME_ACCESS)
 
+static LIST_HEAD(efi_pstore_list);
+
 static int efi_pstore_open(struct pstore_info *psi)
 {
psi->data = NULL;
@@ -126,7 +130,7 @@ static inline int __efi_pstore_scan_sysfs_exit(struct 
efivar_entry *entry,
if (entry->deleting) {
list_del(>list);
efivar_entry_iter_end();
-   efivar_unregister(entry);
+   kfree(entry);
if (efivar_entry_iter_begin())
return -EINTR;
} else if (turn_off_scanning)
@@ -169,7 +173,7 @@ static int efi_pstore_sysfs_entry_iter(struct pstore_record 
*record)
 {
struct efivar_entry **pos = (struct efivar_entry **)>psi->data;
struct efivar_entry *entry, *n;
-   struct list_head *head = _sysfs_list;
+   struct list_head *head = _pstore_list;
int size = 0;
int ret;
 
@@ -314,12 +318,12 @@ static int efi_pstore_erase_name(const char *name)
if (efivar_entry_iter_begin())
return -EINTR;
 
-   found = __efivar_entry_iter(efi_pstore_erase_func, _sysfs_list,
+   found = __efivar_entry_iter(efi_pstore_erase_func, _pstore_list,
efi_name, );
efivar_entry_iter_end();
 
if (found && !entry->scanning)
-   efivar_unregister(entry);
+   kfree(entry);
 
return found ? 0 : -ENOENT;
 }
@@ -354,14 +358,76 @@ static struct pstore_info efi_pstore_info = {
.erase  = efi_pstore_erase,
 };
 
+static int efi_pstore_callback(efi_char16_t *name, efi_guid_t vendor,
+  unsigned long name_size, void *data)
+{
+   struct efivar_entry *entry;
+   int ret;
+
+   entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+   if (!entry)
+   return -ENOMEM;
+
+   memcpy(entry->var.VariableName, name, name_size);
+   entry->var.VendorGuid = vendor;
+
+   ret = efivar_entry_add(entry, _pstore_list);
+   if (ret)
+   kfree(entry);
+
+   return ret;
+}
+
+static int efi_pstore_update_entry(efi_char16_t *name, efi_guid_t vendor,
+  unsigned long name_size, void *data)
+{
+   struct efivar_entry *entry = data;
+
+   if (efivar_entry_find(name, vendor, _pstore_list, false))
+   return 0;
+
+   memcpy(entry->var.VariableName, name, name_size);
+   memcpy(&(entry->var.VendorGuid), , sizeof(efi_guid_t));
+
+   return 1;
+}
+
+static void efi_pstore_update_entries(struct work_struct *work)
+{
+   struct efivar_entry *entry;
+   int err;
+
+   /* Add new sysfs entries */
+ 

[tip: efi/core] efi: gsmi: fix false dependency on CONFIG_EFI_VARS

[tip-bot2 for Ard Biesheuvel]

The following commit has been merged into the efi/core branch of tip:

Commit-ID: 9846d86031eeca2fb2867fe4ac9d92803a97e8e4
Gitweb:
https://git.kernel.org/tip/9846d86031eeca2fb2867fe4ac9d92803a97e8e4
Author:Ard Biesheuvel 
AuthorDate:Wed, 23 Sep 2020 10:18:31 +02:00
Committer: Ard Biesheuvel 
CommitterDate: Tue, 29 Sep 2020 19:40:57 +02:00

efi: gsmi: fix false dependency on CONFIG_EFI_VARS

The gsmi code does not actually rely on CONFIG_EFI_VARS, since it only
uses the efivars abstraction that is included unconditionally when
CONFIG_EFI is defined. CONFIG_EFI_VARS controls the inclusion of the
code that exposes the sysfs entries, and which has been deprecated for
some time.

Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/google/Kconfig | 2 +-
 drivers/firmware/google/gsmi.c  | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/firmware/google/Kconfig b/drivers/firmware/google/Kconfig
index a3a6ca6..97968ae 100644
--- a/drivers/firmware/google/Kconfig
+++ b/drivers/firmware/google/Kconfig
@@ -15,7 +15,7 @@ config GOOGLE_SMI
help
  Say Y here if you want to enable SMI callbacks for Google
  platforms.  This provides an interface for writing to and
- clearing the event log.  If EFI_VARS is also enabled this
+ clearing the event log.  If CONFIG_EFI is also enabled this
  driver provides an interface for reading and writing NVRAM
  variables.
 
diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
index 5b2011e..7d9367b 100644
--- a/drivers/firmware/google/gsmi.c
+++ b/drivers/firmware/google/gsmi.c
@@ -302,7 +302,7 @@ static int gsmi_exec(u8 func, u8 sub)
return rc;
 }
 
-#ifdef CONFIG_EFI_VARS
+#ifdef CONFIG_EFI
 
 static struct efivars efivars;
 
@@ -483,7 +483,7 @@ static const struct efivar_operations efivar_ops = {
.get_next_variable = gsmi_get_next_variable,
 };
 
-#endif /* CONFIG_EFI_VARS */
+#endif /* CONFIG_EFI */
 
 static ssize_t eventlog_write(struct file *filp, struct kobject *kobj,
   struct bin_attribute *bin_attr,
@@ -1007,7 +1007,7 @@ static __init int gsmi_init(void)
goto out_remove_bin_file;
}
 
-#ifdef CONFIG_EFI_VARS
+#ifdef CONFIG_EFI
ret = efivars_register(, _ops, gsmi_kobj);
if (ret) {
printk(KERN_INFO "gsmi: Failed to register efivars\n");
@@ -1047,7 +1047,7 @@ static void __exit gsmi_exit(void)
unregister_die_notifier(_die_notifier);
atomic_notifier_chain_unregister(_notifier_list,
 _panic_notifier);
-#ifdef CONFIG_EFI_VARS
+#ifdef CONFIG_EFI
efivars_unregister();
 #endif
 

[tip: efi/core] cper,edac,efi: Memory Error Record: bank group/address and chip id

[tip-bot2 for Alex Kluver]

The following commit has been merged into the efi/core branch of tip:

Commit-ID: 612b5d506d066cdf0a739963e7cd28642d500ec1
Gitweb:
https://git.kernel.org/tip/612b5d506d066cdf0a739963e7cd28642d500ec1
Author:Alex Kluver 
AuthorDate:Wed, 19 Aug 2020 09:35:44 -05:00
Committer: Ard Biesheuvel 
CommitterDate: Thu, 17 Sep 2020 10:19:52 +03:00

cper,edac,efi: Memory Error Record: bank group/address and chip id

Updates to the UEFI 2.8 Memory Error Record allow splitting the bank field
into bank address and bank group, and using the last 3 bits of the extended
field as a chip identifier.

When needed, print correct version of bank field, bank group, and chip
identification.

Based on UEFI 2.8 Table 299. Memory Error Record.

Signed-off-by: Alex Kluver 
Reviewed-by: Russ Anderson 
Reviewed-by: Kyle Meyer 
Reviewed-by: Steve Wahl 
Acked-by: Borislav Petkov 
Link: https://lore.kernel.org/r/20200819143544.155096-3-alex.klu...@hpe.com
Signed-off-by: Ard Biesheuvel 
---
 drivers/edac/ghes_edac.c|  9 +
 drivers/firmware/efi/cper.c |  9 +
 include/linux/cper.h|  8 
 3 files changed, 26 insertions(+)

diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index 741e760..8a44f32 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -372,6 +372,12 @@ void ghes_edac_report_mem_error(int sev, struct 
cper_sec_mem_err *mem_err)
p += sprintf(p, "rank:%d ", mem_err->rank);
if (mem_err->validation_bits & CPER_MEM_VALID_BANK)
p += sprintf(p, "bank:%d ", mem_err->bank);
+   if (mem_err->validation_bits & CPER_MEM_VALID_BANK_GROUP)
+   p += sprintf(p, "bank_group:%d ",
+mem_err->bank >> CPER_MEM_BANK_GROUP_SHIFT);
+   if (mem_err->validation_bits & CPER_MEM_VALID_BANK_ADDRESS)
+   p += sprintf(p, "bank_address:%d ",
+mem_err->bank & CPER_MEM_BANK_ADDRESS_MASK);
if (mem_err->validation_bits & (CPER_MEM_VALID_ROW | 
CPER_MEM_VALID_ROW_EXT)) {
u32 row = mem_err->row;
 
@@ -399,6 +405,9 @@ void ghes_edac_report_mem_error(int sev, struct 
cper_sec_mem_err *mem_err)
strcpy(e->label, dimm->label);
}
}
+   if (mem_err->validation_bits & CPER_MEM_VALID_CHIP_ID)
+   p += sprintf(p, "chipID: %d ",
+mem_err->extended >> CPER_MEM_CHIP_ID_SHIFT);
if (p > e->location)
*(p - 1) = '\0';
 
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index a60acd1..e15d484 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -232,6 +232,12 @@ static int cper_mem_err_location(struct 
cper_mem_err_compact *mem, char *msg)
n += scnprintf(msg + n, len - n, "rank: %d ", mem->rank);
if (mem->validation_bits & CPER_MEM_VALID_BANK)
n += scnprintf(msg + n, len - n, "bank: %d ", mem->bank);
+   if (mem->validation_bits & CPER_MEM_VALID_BANK_GROUP)
+   n += scnprintf(msg + n, len - n, "bank_group: %d ",
+  mem->bank >> CPER_MEM_BANK_GROUP_SHIFT);
+   if (mem->validation_bits & CPER_MEM_VALID_BANK_ADDRESS)
+   n += scnprintf(msg + n, len - n, "bank_address: %d ",
+  mem->bank & CPER_MEM_BANK_ADDRESS_MASK);
if (mem->validation_bits & CPER_MEM_VALID_DEVICE)
n += scnprintf(msg + n, len - n, "device: %d ", mem->device);
if (mem->validation_bits & (CPER_MEM_VALID_ROW | 
CPER_MEM_VALID_ROW_EXT)) {
@@ -254,6 +260,9 @@ static int cper_mem_err_location(struct 
cper_mem_err_compact *mem, char *msg)
if (mem->validation_bits & CPER_MEM_VALID_TARGET_ID)
scnprintf(msg + n, len - n, "target_id: 0x%016llx ",
  mem->target_id);
+   if (mem->validation_bits & CPER_MEM_VALID_CHIP_ID)
+   scnprintf(msg + n, len - n, "chip_id: %d ",
+ mem->extended >> CPER_MEM_CHIP_ID_SHIFT);
 
msg[n] = '\0';
return n;
diff --git a/include/linux/cper.h b/include/linux/cper.h
index bd2d8a7..6a511a1 100644
--- a/include/linux/cper.h
+++ b/include/linux/cper.h
@@ -231,10 +231,18 @@ enum {
 #define CPER_MEM_VALID_CARD_HANDLE 0x1
 #define CPER_MEM_VALID_MODULE_HANDLE   0x2
 #define CPER_MEM_VALID_ROW_EXT 0x4
+#define CPER_MEM_VALID_BANK_GROUP  0x8
+#define CPER_MEM_VALID_BANK_ADDRESS0x10
+#define CPER_MEM_VALID_CHIP_ID 0x20
 
 #define CPER_MEM_EXT_ROW_MASK  0x3
 #define CPER_MEM_EXT_ROW_SHIFT 16
 
+#define CPER_MEM_BANK_ADDRESS_MASK 0xff
+#define CPER_MEM_BANK_GROUP_SHIFT  8
+
+#define CPER_MEM_CHIP_ID_SHIFT 5
+
 #define CPER_PCIE_VALID_PORT_TYPE  0x0001
 #define 

[tip: efi/core] efi: efivars: limit availability to X86 builds

[tip-bot2 for Ard Biesheuvel]

The following commit has been merged into the efi/core branch of tip:

Commit-ID: 963fabf37f6a94214a823df0a785e653cb8ad6ea
Gitweb:
https://git.kernel.org/tip/963fabf37f6a94214a823df0a785e653cb8ad6ea
Author:Ard Biesheuvel 
AuthorDate:Wed, 23 Sep 2020 10:20:10 +02:00
Committer: Ard Biesheuvel 
CommitterDate: Tue, 29 Sep 2020 19:40:57 +02:00

efi: efivars: limit availability to X86 builds

CONFIG_EFI_VARS controls the code that exposes EFI variables via
sysfs entries, which was deprecated before support for non-Intel
architectures was added to EFI. So let's limit its availability
to Intel architectures for the time being, and hopefully remove
it entirely in the not too distant future.

While at it, let's remove the module alias so that the module is
no longer loaded automatically.

Signed-off-by: Ard Biesheuvel 
---
 Documentation/arm/uefi.rst |  2 +-
 drivers/firmware/efi/Kconfig   | 13 -
 drivers/firmware/efi/efivars.c |  1 -
 3 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/Documentation/arm/uefi.rst b/Documentation/arm/uefi.rst
index f868330..f732f95 100644
--- a/Documentation/arm/uefi.rst
+++ b/Documentation/arm/uefi.rst
@@ -23,7 +23,7 @@ makes it possible for the kernel to support additional 
features:
 For actually enabling [U]EFI support, enable:
 
 - CONFIG_EFI=y
-- CONFIG_EFI_VARS=y or m
+- CONFIG_EFIVAR_FS=y or m
 
 The implementation depends on receiving information about the UEFI environment
 in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF.
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 80f5c67..da1887f 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -4,20 +4,15 @@ menu "EFI (Extensible Firmware Interface) Support"
 
 config EFI_VARS
tristate "EFI Variable Support via sysfs"
-   depends on EFI
+   depends on EFI && (X86 || IA64)
default n
help
  If you say Y here, you are able to get EFI (Extensible Firmware
  Interface) variable information via sysfs.  You may read,
  write, create, and destroy EFI variables through this interface.
-
- Note that using this driver in concert with efibootmgr requires
- at least test release version 0.5.0-test3 or later, which is
- available from:
- 

-
- Subsequent efibootmgr releases may be found at:
- 
+ Note that this driver is only retained for compatibility with
+ legacy users: new users should use the efivarfs filesystem
+ instead.
 
 config EFI_ESRT
bool
diff --git a/drivers/firmware/efi/efivars.c b/drivers/firmware/efi/efivars.c
index a76f50e..e6b16b3 100644
--- a/drivers/firmware/efi/efivars.c
+++ b/drivers/firmware/efi/efivars.c
@@ -22,7 +22,6 @@ MODULE_AUTHOR("Matt Domsch ");
 MODULE_DESCRIPTION("sysfs interface to EFI Variables");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(EFIVARS_VERSION);
-MODULE_ALIAS("platform:efivars");
 
 static LIST_HEAD(efivar_sysfs_list);
 

[tip: efi/core] efi: pstore: move workqueue handling out of efivars

[tip-bot2 for Ard Biesheuvel]

The following commit has been merged into the efi/core branch of tip:

Commit-ID: c9b51a2dbfe7f47643e133bf48e1bf28f1b85d2a
Gitweb:
https://git.kernel.org/tip/c9b51a2dbfe7f47643e133bf48e1bf28f1b85d2a
Author:Ard Biesheuvel 
AuthorDate:Wed, 23 Sep 2020 10:07:49 +02:00
Committer: Ard Biesheuvel 
CommitterDate: Tue, 29 Sep 2020 19:40:57 +02:00

efi: pstore: move workqueue handling out of efivars

The worker thread that gets kicked off to sync the state of the
EFI variable list is only used by the EFI pstore implementation,
and is defined in its source file. So let's move its scheduling
there as well. Since our efivar_init() scan will bail on duplicate
entries, there is no need to disable the workqueue like we did
before, so we can run it unconditionally.

Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/efi-pstore.c |  7 +--
 drivers/firmware/efi/vars.c   | 21 -
 include/linux/efi.h   |  3 ---
 3 files changed, 5 insertions(+), 26 deletions(-)

diff --git a/drivers/firmware/efi/efi-pstore.c 
b/drivers/firmware/efi/efi-pstore.c
index 785f5e6..0ef086e 100644
--- a/drivers/firmware/efi/efi-pstore.c
+++ b/drivers/firmware/efi/efi-pstore.c
@@ -21,6 +21,7 @@ module_param_named(pstore_disable, efivars_pstore_disable, 
bool, 0644);
 EFI_VARIABLE_RUNTIME_ACCESS)
 
 static LIST_HEAD(efi_pstore_list);
+static DECLARE_WORK(efivar_work, NULL);
 
 static int efi_pstore_open(struct pstore_info *psi)
 {
@@ -267,8 +268,9 @@ static int efi_pstore_write(struct pstore_record *record)
ret = efivar_entry_set_safe(efi_name, vendor, PSTORE_EFI_ATTRIBUTES,
  preemptible(), record->size, record->psi->buf);
 
-   if (record->reason == KMSG_DUMP_OOPS)
-   efivar_run_worker();
+   if (record->reason == KMSG_DUMP_OOPS && try_module_get(THIS_MODULE))
+   if (!schedule_work(_work))
+   module_put(THIS_MODULE);
 
return ret;
 };
@@ -412,6 +414,7 @@ static void efi_pstore_update_entries(struct work_struct 
*work)
}
 
kfree(entry);
+   module_put(THIS_MODULE);
 }
 
 static __init int efivars_pstore_init(void)
diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 973eef2..ffb12f6 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -32,10 +32,6 @@ static struct efivars *__efivars;
  */
 static DEFINE_SEMAPHORE(efivars_lock);
 
-static bool efivar_wq_enabled = true;
-DECLARE_WORK(efivar_work, NULL);
-EXPORT_SYMBOL_GPL(efivar_work);
-
 static bool
 validate_device_path(efi_char16_t *var_name, int match, u8 *buffer,
 unsigned long len)
@@ -391,13 +387,6 @@ static void dup_variable_bug(efi_char16_t *str16, 
efi_guid_t *vendor_guid,
size_t i, len8 = len16 / sizeof(efi_char16_t);
char *str8;
 
-   /*
-* Disable the workqueue since the algorithm it uses for
-* detecting new variables won't work with this buggy
-* implementation of GetNextVariableName().
-*/
-   efivar_wq_enabled = false;
-
str8 = kzalloc(len8, GFP_KERNEL);
if (!str8)
return;
@@ -1158,16 +1147,6 @@ struct kobject *efivars_kobject(void)
 EXPORT_SYMBOL_GPL(efivars_kobject);
 
 /**
- * efivar_run_worker - schedule the efivar worker thread
- */
-void efivar_run_worker(void)
-{
-   if (efivar_wq_enabled)
-   schedule_work(_work);
-}
-EXPORT_SYMBOL_GPL(efivar_run_worker);
-
-/**
  * efivars_register - register an efivars
  * @efivars: efivars to register
  * @ops: efivars operations
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 7066c11..ab8c803 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1037,9 +1037,6 @@ bool efivar_validate(efi_guid_t vendor, efi_char16_t 
*var_name, u8 *data,
 bool efivar_variable_is_removable(efi_guid_t vendor, const char *name,
  size_t len);
 
-extern struct work_struct efivar_work;
-void efivar_run_worker(void);
-
 #if defined(CONFIG_EFI_VARS) || defined(CONFIG_EFI_VARS_MODULE)
 int efivars_sysfs_init(void);
 

Re: [PATCH v4 5/7] clk: axi-clkgen: Respect ZYNQMP PFD/VCO frequency limits

[Alexandru Ardelean]

On Tue, Sep 29, 2020 at 6:30 PM Moritz Fischer  wrote:
>
> Hi Alexandru,
>
> On Tue, Sep 29, 2020 at 05:44:15PM +0300, Alexandru Ardelean wrote:
> > From: Mathias Tausen 
> >
> > Since axi-clkgen is now supported on ZYNQMP, make sure the max/min
> > frequencies of the PFD and VCO are respected.
> >
> > Signed-off-by: Mathias Tausen 
> > Signed-off-by: Alexandru Ardelean 
>
> This patch still does not cover the PCIe Zynq plugged into ZynqMP linux
> machine case.
>
> > ---
> >  drivers/clk/clk-axi-clkgen.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/clk/clk-axi-clkgen.c b/drivers/clk/clk-axi-clkgen.c
> > index 4342b7735590..2319bb1c5c08 100644
> > --- a/drivers/clk/clk-axi-clkgen.c
> > +++ b/drivers/clk/clk-axi-clkgen.c
> > @@ -108,12 +108,21 @@ static uint32_t axi_clkgen_lookup_lock(unsigned int m)
> >   return 0x1f1f00fa;
> >  }
> >
> > +#ifdef ARCH_ZYNQMP
> > +static const struct axi_clkgen_limits axi_clkgen_default_limits = {
> > + .fpfd_min = 1,
> > + .fpfd_max = 45,
> > + .fvco_min = 80,
> > + .fvco_max = 160,
> > +};
> > +#else
> >  static const struct axi_clkgen_limits axi_clkgen_default_limits = {
> >   .fpfd_min = 1,
> >   .fpfd_max = 30,
> >   .fvco_min = 60,
> >   .fvco_max = 120,
> >  };
> > +#endif
>
> I still don't understand this. You have a way to determine which fabric
> you are looking at with the FPGA info. Why not:
>
> [..] axi_clkgen_zynqmp_default_limits = {
> };
>
> [..] axi_clkgen_default_limits = {
> };
>
> Set them based on what you read back, i.e. determine which fabric you
> are looking at *per clock gen* and use that info, rather than making a
> compile time decision to support only one of them.
>
> Generally speaking #ifdef $ARCH should be a last resort solution.

The support for reading back the fabric parameters is implemented in
the AXI CLKGEN PCORE version starting with 5.0.a
Links:
https://github.com/analogdevicesinc/hdl/commits/master/library/common/up_clkgen.v
https://github.com/analogdevicesinc/hdl/commit/66823682b63c1037abdc3fc1dd4d4e63d3cfbc1a
https://github.com/analogdevicesinc/hdl/commit/7dcb2050c7946fab5ea5a273eda7c53ea7b969a6

Before that version, these details aren't there, so the best you can
do is assume compile-time ARCH defaults.

Looking at patch 7 [in this series], the axi_clkgen only updates these
defaults if the PCORE version is above version 4.x.x
https://lore.kernel.org/linux-clk/20200929144417.89816-16-alexandru.ardel...@analog.com/T/#u

Now, the question would be: do we still support PCORE versions before 5.0.a?
Depending on the answer to this question, I would be fine with the
proposed change here.

> >
> >  static void axi_clkgen_calc_params(const struct axi_clkgen_limits *limits,
> >   unsigned long fin, unsigned long fout,
> > --
> > 2.17.1
> >
>
> Cheers,
> Moritz

[tip: efi/core] edac,ghes,cper: Add Row Extension to Memory Error Record

[tip-bot2 for Alex Kluver]

The following commit has been merged into the efi/core branch of tip:

Commit-ID: 9baf68cc4544056f33797b78ec09388f54ecc8f0
Gitweb:
https://git.kernel.org/tip/9baf68cc4544056f33797b78ec09388f54ecc8f0
Author:Alex Kluver 
AuthorDate:Wed, 19 Aug 2020 09:35:43 -05:00
Committer: Ard Biesheuvel 
CommitterDate: Thu, 17 Sep 2020 10:19:52 +03:00

edac,ghes,cper: Add Row Extension to Memory Error Record

Memory errors could be printed with incorrect row values since the DIMM
size has outgrown the 16 bit row field in the CPER structure. UEFI
Specification Version 2.8 has increased the size of row by allowing it to
use the first 2 bits from a previously reserved space within the structure.

When needed, add the extension bits to the row value printed.

Based on UEFI 2.8 Table 299. Memory Error Record

Signed-off-by: Alex Kluver 
Tested-by: Russ Anderson 
Reviewed-by: Steve Wahl 
Reviewed-by: Kyle Meyer 
Acked-by: Borislav Petkov 
Link: https://lore.kernel.org/r/20200819143544.155096-2-alex.klu...@hpe.com
Signed-off-by: Ard Biesheuvel 
---
 drivers/edac/ghes_edac.c|  8 ++--
 drivers/firmware/efi/cper.c |  9 +++--
 include/linux/cper.h| 16 ++--
 3 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index da60c29..741e760 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -372,8 +372,12 @@ void ghes_edac_report_mem_error(int sev, struct 
cper_sec_mem_err *mem_err)
p += sprintf(p, "rank:%d ", mem_err->rank);
if (mem_err->validation_bits & CPER_MEM_VALID_BANK)
p += sprintf(p, "bank:%d ", mem_err->bank);
-   if (mem_err->validation_bits & CPER_MEM_VALID_ROW)
-   p += sprintf(p, "row:%d ", mem_err->row);
+   if (mem_err->validation_bits & (CPER_MEM_VALID_ROW | 
CPER_MEM_VALID_ROW_EXT)) {
+   u32 row = mem_err->row;
+
+   row |= cper_get_mem_extension(mem_err->validation_bits, 
mem_err->extended);
+   p += sprintf(p, "row:%d ", row);
+   }
if (mem_err->validation_bits & CPER_MEM_VALID_COLUMN)
p += sprintf(p, "col:%d ", mem_err->column);
if (mem_err->validation_bits & CPER_MEM_VALID_BIT_POSITION)
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index f564e15..a60acd1 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -234,8 +234,12 @@ static int cper_mem_err_location(struct 
cper_mem_err_compact *mem, char *msg)
n += scnprintf(msg + n, len - n, "bank: %d ", mem->bank);
if (mem->validation_bits & CPER_MEM_VALID_DEVICE)
n += scnprintf(msg + n, len - n, "device: %d ", mem->device);
-   if (mem->validation_bits & CPER_MEM_VALID_ROW)
-   n += scnprintf(msg + n, len - n, "row: %d ", mem->row);
+   if (mem->validation_bits & (CPER_MEM_VALID_ROW | 
CPER_MEM_VALID_ROW_EXT)) {
+   u32 row = mem->row;
+
+   row |= cper_get_mem_extension(mem->validation_bits, 
mem->extended);
+   n += scnprintf(msg + n, len - n, "row: %d ", row);
+   }
if (mem->validation_bits & CPER_MEM_VALID_COLUMN)
n += scnprintf(msg + n, len - n, "column: %d ", mem->column);
if (mem->validation_bits & CPER_MEM_VALID_BIT_POSITION)
@@ -292,6 +296,7 @@ void cper_mem_err_pack(const struct cper_sec_mem_err *mem,
cmem->requestor_id = mem->requestor_id;
cmem->responder_id = mem->responder_id;
cmem->target_id = mem->target_id;
+   cmem->extended = mem->extended;
cmem->rank = mem->rank;
cmem->mem_array_handle = mem->mem_array_handle;
cmem->mem_dev_handle = mem->mem_dev_handle;
diff --git a/include/linux/cper.h b/include/linux/cper.h
index 8537e92..bd2d8a7 100644
--- a/include/linux/cper.h
+++ b/include/linux/cper.h
@@ -230,6 +230,10 @@ enum {
 #define CPER_MEM_VALID_RANK_NUMBER 0x8000
 #define CPER_MEM_VALID_CARD_HANDLE 0x1
 #define CPER_MEM_VALID_MODULE_HANDLE   0x2
+#define CPER_MEM_VALID_ROW_EXT 0x4
+
+#define CPER_MEM_EXT_ROW_MASK  0x3
+#define CPER_MEM_EXT_ROW_SHIFT 16
 
 #define CPER_PCIE_VALID_PORT_TYPE  0x0001
 #define CPER_PCIE_VALID_VERSION0x0002
@@ -443,7 +447,7 @@ struct cper_sec_mem_err_old {
u8  error_type;
 };
 
-/* Memory Error Section (UEFI >= v2.3), UEFI v2.7 sec N.2.5 */
+/* Memory Error Section (UEFI >= v2.3), UEFI v2.8 sec N.2.5 */
 struct cper_sec_mem_err {
u64 validation_bits;
u64 error_status;
@@ -461,7 +465,7 @@ struct cper_sec_mem_err {
u64 responder_id;
u64 target_id;
u8  error_type;
-   u8  reserved;
+   u8  extended;
u16 rank;
u16 mem_array_handle;   /* "card handle" in UEFI 2.4 */
u16 

[tip: efi/core] efi: mokvar-table: fix some issues in new code

[tip-bot2 for Ard Biesheuvel]

The following commit has been merged into the efi/core branch of tip:

Commit-ID: b89114cd018cffa5deb7def1844ce1891efd4f96
Gitweb:
https://git.kernel.org/tip/b89114cd018cffa5deb7def1844ce1891efd4f96
Author:Ard Biesheuvel 
AuthorDate:Thu, 24 Sep 2020 17:58:22 +02:00
Committer: Ard Biesheuvel 
CommitterDate: Tue, 29 Sep 2020 19:40:57 +02:00

efi: mokvar-table: fix some issues in new code

Fix a couple of issues in the new mokvar-table handling code, as
pointed out by Arvind and Boris:
- don't bother checking the end of the physical region against the start
  address of the mokvar table,
- ensure that we enter the loop with err = -EINVAL,
- replace size_t with unsigned long to appease pedantic type equality
  checks.

Reviewed-by: Arvind Sankar 
Reviewed-by: Lenny Szubowicz 
Tested-by: Borislav Petkov 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/mokvar-table.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/firmware/efi/mokvar-table.c 
b/drivers/firmware/efi/mokvar-table.c
index b1cd498..72a9e17 100644
--- a/drivers/firmware/efi/mokvar-table.c
+++ b/drivers/firmware/efi/mokvar-table.c
@@ -98,15 +98,14 @@ static struct kobject *mokvar_kobj;
 void __init efi_mokvar_table_init(void)
 {
efi_memory_desc_t md;
-   u64 end_pa;
void *va = NULL;
-   size_t cur_offset = 0;
-   size_t offset_limit;
-   size_t map_size = 0;
-   size_t map_size_needed = 0;
-   size_t size;
+   unsigned long cur_offset = 0;
+   unsigned long offset_limit;
+   unsigned long map_size = 0;
+   unsigned long map_size_needed = 0;
+   unsigned long size;
struct efi_mokvar_table_entry *mokvar_entry;
-   int err = -EINVAL;
+   int err;
 
if (!efi_enabled(EFI_MEMMAP))
return;
@@ -122,18 +121,16 @@ void __init efi_mokvar_table_init(void)
pr_warn("EFI MOKvar config table is not within the EFI memory 
map\n");
return;
}
-   end_pa = efi_mem_desc_end();
-   if (efi.mokvar_table >= end_pa) {
-   pr_err("EFI memory descriptor containing MOKvar config table is 
invalid\n");
-   return;
-   }
-   offset_limit = end_pa - efi.mokvar_table;
+
+   offset_limit = efi_mem_desc_end() - efi.mokvar_table;
+
/*
 * Validate the MOK config table. Since there is no table header
 * from which we could get the total size of the MOK config table,
 * we compute the total size as we validate each variably sized
 * entry, remapping as necessary.
 */
+   err = -EINVAL;
while (cur_offset + sizeof(*mokvar_entry) <= offset_limit) {
mokvar_entry = va + cur_offset;
map_size_needed = cur_offset + sizeof(*mokvar_entry);
@@ -150,7 +147,7 @@ void __init efi_mokvar_table_init(void)
   offset_limit);
va = early_memremap(efi.mokvar_table, map_size);
if (!va) {
-   pr_err("Failed to map EFI MOKvar config table 
pa=0x%lx, size=%zu.\n",
+   pr_err("Failed to map EFI MOKvar config table 
pa=0x%lx, size=%lu.\n",
   efi.mokvar_table, map_size);
return;
}

[tip: efi/core] efi/x86: Add a quirk to support command line arguments on Dell EFI firmware

[tip-bot2 for Arvind Sankar]

The following commit has been merged into the efi/core branch of tip:

Commit-ID: 4a568ce29d3f48df95919f82a80e4b9be7ea0dc1
Gitweb:
https://git.kernel.org/tip/4a568ce29d3f48df95919f82a80e4b9be7ea0dc1
Author:Arvind Sankar 
AuthorDate:Mon, 14 Sep 2020 17:35:35 -04:00
Committer: Ard Biesheuvel 
CommitterDate: Thu, 17 Sep 2020 10:19:53 +03:00

efi/x86: Add a quirk to support command line arguments on Dell EFI firmware

At least some versions of Dell EFI firmware pass the entire
EFI_LOAD_OPTION descriptor, rather than just the OptionalData part, to
the loaded image. This was verified with firmware revision 2.15.0 on a
Dell Precision T3620 by Jacobo Pantoja.

To handle this, add a quirk to check if the options look like a valid
EFI_LOAD_OPTION descriptor, and if so, use the OptionalData part as the
command line.

Signed-off-by: Arvind Sankar 
Reported-by: Jacobo Pantoja 
Link: 
https://lore.kernel.org/linux-efi/20200907170021.ga2284...@rani.riverdale.lan/
Link: https://lore.kernel.org/r/20200914213535.933454-2-nived...@alum.mit.edu
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/libstub/efi-stub-helper.c | 101 +++-
 drivers/firmware/efi/libstub/efistub.h |  31 +-
 drivers/firmware/efi/libstub/file.c|   5 +-
 3 files changed, 135 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index 6bca70b..4dbf04c 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -231,6 +231,102 @@ efi_status_t efi_parse_options(char const *cmdline)
 }
 
 /*
+ * The EFI_LOAD_OPTION descriptor has the following layout:
+ * u32 Attributes;
+ * u16 FilePathListLength;
+ * u16 Description[];
+ * efi_device_path_protocol_t FilePathList[];
+ * u8 OptionalData[];
+ *
+ * This function validates and unpacks the variable-size data fields.
+ */
+static
+bool efi_load_option_unpack(efi_load_option_unpacked_t *dest,
+   const efi_load_option_t *src, size_t size)
+{
+   const void *pos;
+   u16 c;
+   efi_device_path_protocol_t header;
+   const efi_char16_t *description;
+   const efi_device_path_protocol_t *file_path_list;
+
+   if (size < offsetof(efi_load_option_t, variable_data))
+   return false;
+   pos = src->variable_data;
+   size -= offsetof(efi_load_option_t, variable_data);
+
+   if ((src->attributes & ~EFI_LOAD_OPTION_MASK) != 0)
+   return false;
+
+   /* Scan description. */
+   description = pos;
+   do {
+   if (size < sizeof(c))
+   return false;
+   c = *(const u16 *)pos;
+   pos += sizeof(c);
+   size -= sizeof(c);
+   } while (c != L'\0');
+
+   /* Scan file_path_list. */
+   file_path_list = pos;
+   do {
+   if (size < sizeof(header))
+   return false;
+   header = *(const efi_device_path_protocol_t *)pos;
+   if (header.length < sizeof(header))
+   return false;
+   if (size < header.length)
+   return false;
+   pos += header.length;
+   size -= header.length;
+   } while ((header.type != EFI_DEV_END_PATH && header.type != 
EFI_DEV_END_PATH2) ||
+(header.sub_type != EFI_DEV_END_ENTIRE));
+   if (pos != (const void *)file_path_list + src->file_path_list_length)
+   return false;
+
+   dest->attributes = src->attributes;
+   dest->file_path_list_length = src->file_path_list_length;
+   dest->description = description;
+   dest->file_path_list = file_path_list;
+   dest->optional_data_size = size;
+   dest->optional_data = size ? pos : NULL;
+
+   return true;
+}
+
+/*
+ * At least some versions of Dell firmware pass the entire contents of the
+ * Boot variable, i.e. the EFI_LOAD_OPTION descriptor, rather than just the
+ * OptionalData field.
+ *
+ * Detect this case and extract OptionalData.
+ */
+void efi_apply_loadoptions_quirk(const void **load_options, int 
*load_options_size)
+{
+   const efi_load_option_t *load_option = *load_options;
+   efi_load_option_unpacked_t load_option_unpacked;
+
+   if (!IS_ENABLED(CONFIG_X86))
+   return;
+   if (!load_option)
+   return;
+   if (*load_options_size < sizeof(*load_option))
+   return;
+   if ((load_option->attributes & ~EFI_LOAD_OPTION_BOOT_MASK) != 0)
+   return;
+
+   if (!efi_load_option_unpack(_option_unpacked, load_option, 
*load_options_size))
+   return;
+
+   efi_warn_once(FW_BUG "LoadOptions is an EFI_LOAD_OPTION descriptor\n");
+   efi_warn_once(FW_BUG "Using OptionalData as a workaround\n");
+
+   *load_options = load_option_unpacked.optional_data;
+   

[tip: efi/core] efi: efivars: un-export efivars_sysfs_init()

[tip-bot2 for Ard Biesheuvel]

The following commit has been merged into the efi/core branch of tip:

Commit-ID: 5d3c8617ccee6387ba73a5dba77fb9dc21cb85f4
Gitweb:
https://git.kernel.org/tip/5d3c8617ccee6387ba73a5dba77fb9dc21cb85f4
Author:Ard Biesheuvel 
AuthorDate:Wed, 23 Sep 2020 10:13:07 +02:00
Committer: Ard Biesheuvel 
CommitterDate: Tue, 29 Sep 2020 19:40:57 +02:00

efi: efivars: un-export efivars_sysfs_init()

efivars_sysfs_init() is only used locally in the source file that
defines it, so make it static and unexport it.

Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/efivars.c | 3 +--
 include/linux/efi.h| 4 
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/firmware/efi/efivars.c b/drivers/firmware/efi/efivars.c
index f39321d..a76f50e 100644
--- a/drivers/firmware/efi/efivars.c
+++ b/drivers/firmware/efi/efivars.c
@@ -638,7 +638,7 @@ static void efivars_sysfs_exit(void)
kset_unregister(efivars_kset);
 }
 
-int efivars_sysfs_init(void)
+static int efivars_sysfs_init(void)
 {
struct kobject *parent_kobj = efivars_kobject();
int error = 0;
@@ -666,7 +666,6 @@ int efivars_sysfs_init(void)
 
return 0;
 }
-EXPORT_SYMBOL_GPL(efivars_sysfs_init);
 
 module_init(efivars_sysfs_init);
 module_exit(efivars_sysfs_exit);
diff --git a/include/linux/efi.h b/include/linux/efi.h
index ab8c803..4c8dae0 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1037,10 +1037,6 @@ bool efivar_validate(efi_guid_t vendor, efi_char16_t 
*var_name, u8 *data,
 bool efivar_variable_is_removable(efi_guid_t vendor, const char *name,
  size_t len);
 
-#if defined(CONFIG_EFI_VARS) || defined(CONFIG_EFI_VARS_MODULE)
-int efivars_sysfs_init(void);
-
-#endif /* CONFIG_EFI_VARS */
 extern bool efi_capsule_pending(int *reset_type);
 
 extern int efi_capsule_supported(efi_guid_t guid, u32 flags,

[tip: efi/core] efi: remove some false dependencies on CONFIG_EFI_VARS

[tip-bot2 for Ard Biesheuvel]

The following commit has been merged into the efi/core branch of tip:

Commit-ID: 5ee70cd60652e85e4e8ced99f58f2fcbab405110
Gitweb:
https://git.kernel.org/tip/5ee70cd60652e85e4e8ced99f58f2fcbab405110
Author:Ard Biesheuvel 
AuthorDate:Wed, 23 Sep 2020 10:27:36 +02:00
Committer: Ard Biesheuvel 
CommitterDate: Tue, 29 Sep 2020 19:40:57 +02:00

efi: remove some false dependencies on CONFIG_EFI_VARS

Remove some false dependencies on CONFIG_EFI_VARS, which only controls
the creation of the sysfs entries, whereas the underlying functionality
that these modules rely on is enabled unconditionally when CONFIG_EFI
is set.

Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index dd8d108..80f5c67 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -137,7 +137,6 @@ config EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
 
 config EFI_BOOTLOADER_CONTROL
tristate "EFI Bootloader Control"
-   depends on EFI_VARS
default n
help
  This module installs a reboot hook, such that if reboot() is
@@ -281,7 +280,7 @@ config EFI_EARLYCON
 
 config EFI_CUSTOM_SSDT_OVERLAYS
bool "Load custom ACPI SSDT overlay from an EFI variable"
-   depends on EFI_VARS && ACPI
+   depends on EFI && ACPI
default ACPI_TABLE_UPGRADE
help
  Allow loading of an ACPI SSDT overlay from an EFI variable specified

Re: [PATCH v2 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Dmitry Osipenko]

30.09.2020 08:10, Dmitry Osipenko пишет:
> 30.09.2020 03:30, Nicolin Chen пишет:
>>  static void tegra_smmu_release_device(struct device *dev)
> 
> The tegra_get_memory_controller() uses of_find_device_by_node(), hence
> tegra_smmu_release_device() should put_device(mc) in order to balance
> back the refcounting.
> 

Actually, the put_device(mc) should be right after
tegra_get_memory_controller() in tegra_smmu_probe_device() because SMMU
is a part of MC, hence MC can't just go away.

[PATCH] ARM: dts: aspeed-g6: Add sgpiom/sgpios node

[Billy Tsai]

This commit add two sgpiom and two sgpios node into aspeed-g6.dtsi
and change the register range of gpio0 to fix the hardware design.

Signed-off-by: Billy Tsai 
---
 arch/arm/boot/dts/aspeed-g6.dtsi | 51 +++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index 97ca743363d7..00237daec2a1 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -357,7 +357,7 @@
#gpio-cells = <2>;
gpio-controller;
compatible = "aspeed,ast2600-gpio";
-   reg = <0x1e78 0x800>;
+   reg = <0x1e78 0x500>;
interrupts = ;
gpio-ranges = < 0 0 208>;
ngpios = <208>;
@@ -365,6 +365,55 @@
interrupt-controller;
#interrupt-cells = <2>;
};
+   sgpiom0: sgpiom@1e780500 {
+   #gpio-cells = <2>;
+   gpio-controller;
+   compatible = "aspeed,ast2600-sgpiom";
+   reg = <0x1e780500 0x100>;
+   interrupts = ;
+   ngpios = <128>;
+   clocks = < ASPEED_CLK_APB2>;
+   interrupt-controller;
+   bus-frequency = <1200>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_sgpm1_default>;
+   status = "disabled";
+   };
+
+   sgpiom1: sgpiom@1e780600 {
+   #gpio-cells = <2>;
+   gpio-controller;
+   compatible = "aspeed,ast2600-sgpiom";
+   reg = <0x1e780600 0x100>;
+   interrupts = ;
+   ngpios = <80>;
+   clocks = < ASPEED_CLK_APB2>;
+   interrupt-controller;
+   bus-frequency = <1200>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_sgpm2_default>;
+   status = "disabled";
+   };
+
+   sgpios0: sgpios@1e780700 {
+   #gpio-cells = <2>;
+   gpio-controller;
+   compatible = "aspeed,ast2600-sgpios";
+   reg = <0x1e780700 0x40>;
+   interrupts = ;
+   clocks = < ASPEED_CLK_APB2>;
+   };
+
+   sgpios1: sgpios@1e780740 {
+   #gpio-cells = <2>;
+   gpio-controller;
+   compatible = "aspeed,ast2600-sgpios";
+   reg = <0x1e780740 0x40>;
+   interrupts = ;
+   clocks = < ASPEED_CLK_APB2>;
+   };
 
gpio1: gpio@1e780800 {
#gpio-cells = <2>;
-- 
2.17.1

[Linux-kernel-mentees][PATCH 2/2] net: reorder members of receive_queue in virtio_net for optimization

[Anant Thazhemadam]

Analysis of the structure receive_queue using pahole gives the
following stats.
/* size: 1280, cachelines: 20, members: 11 */
/* sum members: 1220, holes: 1, sum holes: 60 */
/* paddings: 2, sum paddings: 44 */
/* forced alignments: 2, forced holes: 1, sum forced holes: 60 */

Reordering the order in which the members of receive_queue are declared
helps in packing byte holes in the middle of receive_queue, and also
allows more members to be fully stored in a cacheline (of size 64bytes)
without overstepping over cachelines unnecessarily.

Analysis using pahole post-reordering of members gives us the following
stats.
/* size: 1280, cachelines: 20, members: 11 */
/* padding: 60 */
/* paddings: 2, sum paddings: 44 */
/* forced alignments: 2 */

Signed-off-by: Anant Thazhemadam 
---
The complete analysis done by pahole can be found below.

Before the change:
struct receive_queue {
struct virtqueue * vq;   /* 0 8 
*/
struct napi_struct napi __attribute__((__aligned__(8))); /* 
8   392 */

/* XXX last struct has 4 bytes of padding */

/* --- cacheline 6 boundary (384 bytes) was 16 bytes ago --- */
struct bpf_prog *  xdp_prog; /*   400 8 
*/
struct virtnet_rq_stats stats;   /*   40864 
*/
/* --- cacheline 7 boundary (448 bytes) was 24 bytes ago --- */
struct page *  pages;/*   472 8 
*/
struct ewma_pkt_len mrg_avg_pkt_len; /*   480 8 
*/
struct page_frag   alloc_frag;   /*   48816 
*/
struct scatterlist sg[19];   /*   504   608 
*/
/* --- cacheline 17 boundary (1088 bytes) was 24 bytes ago --- 
*/
unsigned int   min_buf_len;  /*  1112 4 
*/
char   name[40]; /*  111640 
*/

/* XXX 60 bytes hole, try to pack */

/* --- cacheline 19 boundary (1216 bytes) --- */
struct xdp_rxq_info xdp_rxq __attribute__((__aligned__(64))); 
/*  121664 */

/* XXX last struct has 40 bytes of padding */

/* size: 1280, cachelines: 20, members: 11 */
/* sum members: 1220, holes: 1, sum holes: 60 */
/* paddings: 2, sum paddings: 44 */
/* forced alignments: 2, forced holes: 1, sum forced holes: 60 
*/
} __attribute__((__aligned__(64)));

After the change:
struct receive_queue {
struct virtqueue * vq;   /* 0 8 
*/
struct napi_struct napi __attribute__((__aligned__(8))); /* 
8   392 */

/* XXX last struct has 4 bytes of padding */

/* --- cacheline 6 boundary (384 bytes) was 16 bytes ago --- */
char   name[40]; /*   40040 
*/
struct bpf_prog *  xdp_prog; /*   440 8 
*/
/* --- cacheline 7 boundary (448 bytes) --- */
struct virtnet_rq_stats stats;   /*   44864 
*/
/* --- cacheline 8 boundary (512 bytes) --- */
struct scatterlist sg[19];   /*   512   608 
*/
/* --- cacheline 17 boundary (1088 bytes) was 32 bytes ago --- 
*/
struct page_frag   alloc_frag;   /*  112016 
*/
struct page *  pages;/*  1136 8 
*/
struct ewma_pkt_len mrg_avg_pkt_len; /*  1144 8 
*/
/* --- cacheline 18 boundary (1152 bytes) --- */
struct xdp_rxq_info xdp_rxq __attribute__((__aligned__(64))); 
/*  115264 */

/* XXX last struct has 40 bytes of padding */

/* --- cacheline 19 boundary (1216 bytes) --- */
unsigned int   min_buf_len;  /*  1216 4 
*/

/* size: 1280, cachelines: 20, members: 11 */
/* padding: 60 */
/* paddings: 2, sum paddings: 44 */
/* forced alignments: 2 */
} __attribute__((__aligned__(64)));

It can be observed that the holes have been eliminated. 
Also, more members of virtnet_info are accomodated within a cacheline (instead 
of 
unnecessarily crossing over the cacheline boundary).
There is a padding of 60 performed at the end since the min_buf_len is only of 
size 4, and xdp_rxq is of size 64. If declared anywhere else other than at the 
end, a 60 bytes hole would open up again.

 drivers/net/virtio_net.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git 

[Linux-kernel-mentees][PATCH 0/2] reorder members of structures in virtio_net for optimization

[Anant Thazhemadam]

The structures virtnet_info and receive_queue have byte holes in 
middle, and their members could do with some rearranging 
(order-of-declaration wise) in order to overcome this.

Rearranging the members helps in:
  * elimination the byte holes in the middle of the structures
  * reduce the size of the structure (virtnet_info)
  * have more members stored in one cache line (as opposed to 
unnecessarily crossing the cacheline boundary and spanning
different cachelines)

The analysis was performed using pahole.

These patches may be applied in any order.

Anant Thazhemadam (2):
  net: reorder members of virtnet_info for optimization
  net: reorder members of receive_queue in virtio_net for optimization

 drivers/net/virtio_net.c | 44 +---
 1 file changed, 23 insertions(+), 21 deletions(-)

-- 
2.25.1

[Linux-kernel-mentees][PATCH 1/2] net: reorder members of virtnet_info for optimization

[Anant Thazhemadam]

Analysis of the structure virtnet_info using pahole gives the
following stats.
/* size: 256, cachelines: 4, members: 25 */
/* sum members: 245, holes: 3, sum holes: 11 */
/* paddings: 1, sum paddings: 4 */

Reordering the order in which the members of virtnet_info are declared
helps in packing byte holes in the middle of virtnet_info, reduce the
size required by the structure by 8 bytes, and also allows members to be
stored without overstepping the boundaries of a cacheline (for a
cacheline of size 64bytes) unnecessarily.

Analysis using pahole post-reordering of members gives the following
stats.
/* size: 248, cachelines: 4, members: 25 */
/* padding: 3 */
/* paddings: 1, sum paddings: 4 */
/* last cacheline: 56 bytes */

Signed-off-by: Anant Thazhemadam 
---
The complete analysis done by pahole can be found below.
Before the change:
struct virtnet_info {
struct virtio_device * vdev; /* 0 8 
*/
struct virtqueue * cvq;  /* 8 8 
*/
struct net_device *dev;  /*16 8 
*/
struct send_queue *sq;   /*24 8 
*/
struct receive_queue * rq;   /*32 8 
*/
unsigned int   status;   /*40 4 
*/
u16max_queue_pairs;  /*44 2 
*/
u16curr_queue_pairs; /*46 2 
*/
u16xdp_queue_pairs;  /*48 2 
*/
bool   big_packets;  /*50 1 
*/
bool   mergeable_rx_bufs;/*51 1 
*/
bool   has_cvq;  /*52 1 
*/
bool   any_header_sg;/*53 1 
*/
u8 hdr_len;  /*54 1 
*/

/* XXX 1 byte hole, try to pack */

struct delayed_work refill;  /*5688 
*/

/* XXX last struct has 4 bytes of padding */

/* --- cacheline 2 boundary (128 bytes) was 16 bytes ago --- */
struct work_struct config_work;  /*   14432 
*/
bool   affinity_hint_set;/*   176 1 
*/

/* XXX 7 bytes hole, try to pack */

struct hlist_node  node; /*   18416 
*/
/* --- cacheline 3 boundary (192 bytes) was 8 bytes ago --- */
struct hlist_node  node_dead;/*   20016 
*/
struct control_buf *   ctrl; /*   216 8 
*/
u8 duplex;   /*   224 1 
*/

/* XXX 3 bytes hole, try to pack */

u32speed;/*   228 4 
*/
long unsigned int  guest_offloads;   /*   232 8 
*/
long unsigned int  guest_offloads_capable; /*   240 
8 */
struct failover *  failover; /*   248 8 
*/

/* size: 256, cachelines: 4, members: 25 */
/* sum members: 245, holes: 3, sum holes: 11 */
/* paddings: 1, sum paddings: 4 */
};

After the Change:
struct virtnet_info {
struct virtio_device * vdev; /* 0 8 
*/
struct virtqueue * cvq;  /* 8 8 
*/
struct net_device *dev;  /*16 8 
*/
struct send_queue *sq;   /*24 8 
*/
struct receive_queue * rq;   /*32 8 
*/
unsigned int   status;   /*40 4 
*/
u16max_queue_pairs;  /*44 2 
*/
u16curr_queue_pairs; /*46 2 
*/
u16xdp_queue_pairs;  /*48 2 
*/
bool   big_packets;  /*50 1 
*/
bool   mergeable_rx_bufs;/*51 1 
*/
bool   has_cvq;  /*52 1 
*/
bool   any_header_sg;/*53 1 
*/
bool   affinity_hint_set;/*54 1 
*/
u8 hdr_len;  /*55 1 
*/
struct control_buf *   ctrl; /*56

Re: [PATCH] pinctrl: single: check if #pinctrl-cells exceeds 3

[Tony Lindgren]

* Linus Walleij  [200929 12:51]:
> On Sun, Sep 13, 2020 at 11:17 PM Drew Fustini  wrote:
> 
> > The property #pinctrl-cells can either be 2 or 3.  There is currently
> > only a check to make sure that #pinctrl-cells is 2 or greater.  This
> > patch adds a check to make sure it is not greater than 3.
> >
> > Fixes: a1339541 ("pinctrl: single: parse #pinctrl-cells = 2")
> > Reported-by: Trent Piepho 
> > Link: https://lore.kernel.org/linux-omap/3139716.CMS8C0sQ7x@zen.local/
> > Signed-off-by: Drew Fustini 
> 
> Tony, does this and the other patch look good to you?

Hmm well the description looks a bit confusing, #pinctrl-cells can
also be 1 that's the default. Might be worth clarifying that part.

Regards,

Tony

Re: [PATCH v2 2/4] dt-bindings: PCI: uniphier-ep: Add iATU register description

[Kunihiko Hayashi]

On 2020/09/29 3:09, Rob Herring wrote:

On Mon, 28 Sep 2020 10:05:31 +0900, Kunihiko Hayashi wrote:

In the dt-bindings, "atu" reg-names is required to get the register space
for iATU in Synopsis DWC version 4.80 or later.

Signed-off-by: Kunihiko Hayashi 
---
  Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)




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

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.example.dt.yaml:
 pcie-ep@6600: reg: [[1711276032, 4096], [1711280128, 4096], [1711341568, 
65536], [1728053248, 4194304]] is too short
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.example.dt.yaml:
 pcie-ep@6600: reg-names: ['dbi', 'dbi2', 'link', 'addr_space'] is too short
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml


I found this binding update was wrong.
I'll fix and resend it.




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

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

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

Please check and re-submit.


Thank you,

---
Best Regards
Kunihiko Hayashi

Re: [PATCH] [v2] wireless: Initial driver submission for pureLiFi devices

[Leon Romanovsky]

On Mon, Sep 28, 2020 at 03:49:49PM +0530, Srinivasan Raju wrote:
> This introduces the pureLiFi LiFi driver for LiFi-X, LiFi-XC
> and LiFi-XL USB devices, which provide lightweight, highspeed secure and
> fully networked wireless communications via light.
>
> This driver implementation has been based on the zd1211rw driver
>
> Driver is based on 802.11 softMAC Architecture and uses
> native 802.11 for configuration and management
> The driver is compiled and tested in ARM, x86 architectures and
> compiled in powerpc architecture
>
> Signed-off-by: Srinivasan Raju 
> ---
>  MAINTAINERS   |5 +
>  drivers/net/wireless/Kconfig  |1 +
>  drivers/net/wireless/Makefile |1 +
>  drivers/net/wireless/purelifi/Kconfig |   38 +
>  drivers/net/wireless/purelifi/Makefile|3 +
>  drivers/net/wireless/purelifi/chip.c  |  120 ++
>  drivers/net/wireless/purelifi/chip.h  |   81 +
>  drivers/net/wireless/purelifi/def.h   |   46 +
>  drivers/net/wireless/purelifi/log.h   |   15 +
>  drivers/net/wireless/purelifi/mac.c   |  957 +
>  drivers/net/wireless/purelifi/mac.h   |  178 ++
>  .../net/wireless/purelifi/mac_usb_interface.h |   38 +
>  drivers/net/wireless/purelifi/usb.c   | 1872 +
>  drivers/net/wireless/purelifi/usb.h   |  148 ++
>  14 files changed, 3503 insertions(+)
>  create mode 100644 drivers/net/wireless/purelifi/Kconfig
>  create mode 100644 drivers/net/wireless/purelifi/Makefile
>  create mode 100644 drivers/net/wireless/purelifi/chip.c
>  create mode 100644 drivers/net/wireless/purelifi/chip.h
>  create mode 100644 drivers/net/wireless/purelifi/def.h
>  create mode 100644 drivers/net/wireless/purelifi/log.h
>  create mode 100644 drivers/net/wireless/purelifi/mac.c
>  create mode 100644 drivers/net/wireless/purelifi/mac.h
>  create mode 100644 drivers/net/wireless/purelifi/mac_usb_interface.h
>  create mode 100644 drivers/net/wireless/purelifi/usb.c
>  create mode 100644 drivers/net/wireless/purelifi/usb.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 42c69d2eeece..0e8cd1decafe 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14098,6 +14098,11 @@ T:   git git://linuxtv.org/media_tree.git
>  F:   Documentation/admin-guide/media/pulse8-cec.rst
>  F:   drivers/media/cec/usb/pulse8/
>
> +PUREILIFI USB DRIVER
> +M:   Srinivasan Raju 
> +S:   Maintained
> +F:   drivers/net/wireless/purelifi
> +
>  PVRUSB2 VIDEO4LINUX DRIVER
>  M:   Mike Isely 
>  L:   pvru...@isely.net   (subscribers-only)
> diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
> index 170a64e67709..b87da3139f94 100644
> --- a/drivers/net/wireless/Kconfig
> +++ b/drivers/net/wireless/Kconfig
> @@ -48,6 +48,7 @@ source "drivers/net/wireless/st/Kconfig"
>  source "drivers/net/wireless/ti/Kconfig"
>  source "drivers/net/wireless/zydas/Kconfig"
>  source "drivers/net/wireless/quantenna/Kconfig"
> +source "drivers/net/wireless/purelifi/Kconfig"
>
>  config PCMCIA_RAYCS
>   tristate "Aviator/Raytheon 2.4GHz wireless support"
> diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
> index 80b324499786..c403dda7a14e 100644
> --- a/drivers/net/wireless/Makefile
> +++ b/drivers/net/wireless/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_WLAN_VENDOR_ST) += st/
>  obj-$(CONFIG_WLAN_VENDOR_TI) += ti/
>  obj-$(CONFIG_WLAN_VENDOR_ZYDAS) += zydas/
>  obj-$(CONFIG_WLAN_VENDOR_QUANTENNA) += quantenna/
> +obj-$(WLAN_VENDOR_PURELIFI) += purelifi/

It should be CONFIG_WLAN_VENDOR_PURELIFI

>
>  # 16-bit wireless PCMCIA client drivers
>  obj-$(CONFIG_PCMCIA_RAYCS)   += ray_cs.o
> diff --git a/drivers/net/wireless/purelifi/Kconfig 
> b/drivers/net/wireless/purelifi/Kconfig
> new file mode 100644
> index ..ff05eaf0a8d4
> --- /dev/null
> +++ b/drivers/net/wireless/purelifi/Kconfig
> @@ -0,0 +1,38 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config WLAN_VENDOR_PURELIFI
> + bool "pureLiFi devices"
> + default y

"N" is preferred default.

> + help
> +   If you have a pureLiFi device, say Y.
> +
> +   Note that the answer to this question doesn't directly affect the
> +   kernel: saying N will just cause the configurator to skip all the
> +   questions about these cards. If you say Y, you will be asked for
> +   your specific card in the following questions.

The text above makes no sense. Of course, it makes a lot of sense to
disable this device for whole world.

> +
> +if WLAN_VENDOR_PURELIFI
> +
> +config PURELIFI
> +
> + tristate "pureLiFi device support"
> + depends on CFG80211 && MAC80211 && USB
> + help
> +Say Y if you want to use LiFi.
> +
> +This driver makes the adapter appear as a normal WLAN interface.
> +
> +The pureLiFi device requires external STA firmware to be loaded.
> +
> +To compile this driver as a module, choose M here: the module will
> +

Re: [PATCH] ARM: dts: document pinctrl-single,pins when #pinctrl-cells = 2

[Tony Lindgren]

* Trent Piepho  [200929 20:16]:
> On Thu, Sep 24, 2020 at 12:04 AM Tony Lindgren  wrote:
> > Certainly different compatible strings can be used as needed.
> > But pinctrl-single is not going to be am335x specific though :)
> > We have quite a few SoCs using it:
> 
> So what doesn't make sense to me, is to put something am335x specific
> like two cells for conf and mux, into a generic driver like pinctrl
> single.

Treating conf and mux separately is not am335x specific. Linux treats
them separately because the conf options typically can be described
in a generic way while the mux is just signal routing.

Sure the conf values are currently not generic, but that could be
done if wanted to and added some property to specify that the
controller uses generic conf values.

> This series adds two cells ORed into one.  Ok, that's generic, other
> platforms could use it.  But it also accomplishes nothing, so what's
> the point?  You've hinted there is more to come, which will accomplish
> something, but what is it?  That can be:
> Used by platforms other than am335x
> Can't already be done with the pinctrl single pinconf features
> Needs more than one data cell per pin

For SoCs using #pinctrl-cells = <2> we now have conf and mux values
separated in the dtb. Certainly that's a better place to be compared
to earlier for any further pinconf changes.

> Interrupt controllers have different numbers of cells, but they are
> all platform specific, and the cells have defined platform specific
> meanings.  pci-host-cam-generic is a somewhat generic interrupt
> controller and it uses 1 cell, since it lacks device specific fields
> to put into additional cells.

With interrupts the IRQ_TYPE flags are generic and separate from the
hardware specific cells. If we wanted to, we could have something
similar for pinctrl framework.

> Consider also that any future changes to the pinctrl-single bindings
> would need to be backward compatible with a device tree binary where
> two cells get combined.  So if the bindings being added here aren't
> done, then adding them now creates an unnecessary additional version
> to deal with for backward compatibility.

I don't see issues with backward compabilty. If we specify that the
controller uses #pinctrl-cells = <2>, and some additional property
for specifying generic conf flags, we'd have a similar generic binding
to the interrupt binding.

Regards,

Tony

Re: [PATCH v2 1/3] memory: tegra: Add helper function tegra_get_memory_controller

[Dmitry Osipenko]

30.09.2020 03:30, Nicolin Chen пишет:
...
>  int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long 
> rate);
>  unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc);
> +struct tegra_mc *tegra_get_memory_controller(void);
>  
>  #endif /* __SOC_TEGRA_MC_H__ */
> 

This will conflict with the tegra20-devfreq driver, you should change it
as well.

Re: [PATCH v2 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Dmitry Osipenko]

30.09.2020 03:30, Nicolin Chen пишет:
> + /* An invalid mc pointer means mc and smmu drivers are not ready */
> + if (IS_ERR_OR_NULL(mc))

tegra_get_memory_controller() doesn't return NULL.

> + return ERR_PTR(-EPROBE_DEFER);

Re: [PATCH v2 3/3] iommu/tegra-smmu: Add PCI support

[Dmitry Osipenko]

30.09.2020 03:30, Nicolin Chen пишет:
>  void tegra_smmu_remove(struct tegra_smmu *smmu)
>  {
> + bus_set_iommu(_bus_type, NULL);

Why only platform_bus? Is this really needed at all?

>   iommu_device_unregister(>iommu);
>   iommu_device_sysfs_remove(>iommu);

Re: [PATCH v2 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Dmitry Osipenko]

30.09.2020 03:30, Nicolin Chen пишет:
>  static void tegra_smmu_release_device(struct device *dev)

The tegra_get_memory_controller() uses of_find_device_by_node(), hence
tegra_smmu_release_device() should put_device(mc) in order to balance
back the refcounting.

Re: [PATCH v2 3/3] iommu/tegra-smmu: Add PCI support

[Dmitry Osipenko]

30.09.2020 03:30, Nicolin Chen пишет:
...
> +#ifdef CONFIG_PCI
> + if (!iommu_present(_bus_type)) {

Could you please explain why this check is needed?

Re: [PATCH v2 3/3] iommu/tegra-smmu: Add PCI support

[Dmitry Osipenko]

30.09.2020 03:30, Nicolin Chen пишет:
> - group->group = iommu_group_alloc();
> + group->group = pci ? pci_device_group(dev) : iommu_group_alloc();

This will be nicer to write as:

if (dev_is_pci(dev))
group->group = pci_device_group(dev);
else
group->group = generic_device_group(dev);

Re: [PATCH 02/22] kvm: mmu: Introduce tdp_iter

[Sean Christopherson]

On Fri, Sep 25, 2020 at 02:22:42PM -0700, Ben Gardon wrote:
> diff --git a/arch/x86/kvm/mmu/tdp_iter.h b/arch/x86/kvm/mmu/tdp_iter.h
> new file mode 100644
> index 0..b102109778eac
> --- /dev/null
> +++ b/arch/x86/kvm/mmu/tdp_iter.h
> @@ -0,0 +1,53 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

Kernel style is to use C++ comments for the SPDX headers in .c and .h (and
maybe.S too?).

Re: [PATCH v5] ipvs: adjust the debug info in function set_tcp_state

[Julian Anastasov]

Hello,

On Mon, 28 Sep 2020, longguang.yue wrote:

> Outputting client,virtual,dst addresses info when tcp state changes,
> which makes the connection debug more clear
> 
> Signed-off-by: longguang.yue 

OK, v5 can be used instead of fixing v4.

Acked-by: Julian Anastasov 

> ---

longguang.yue, at this place after --- you can add info
for changes between versions, eg:
v5: fix indentation

Use this for other patches, so that we know what is
changed between versions.

>  net/netfilter/ipvs/ip_vs_proto_tcp.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c 
> b/net/netfilter/ipvs/ip_vs_proto_tcp.c
> index dc2e7da2742a..7da51390cea6 100644
> --- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
> +++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
> @@ -539,8 +539,8 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct 
> ip_vs_conn *cp,
>   if (new_state != cp->state) {
>   struct ip_vs_dest *dest = cp->dest;
>  
> - IP_VS_DBG_BUF(8, "%s %s [%c%c%c%c] %s:%d->"
> -   "%s:%d state: %s->%s conn->refcnt:%d\n",
> + IP_VS_DBG_BUF(8, "%s %s [%c%c%c%c] c:%s:%d v:%s:%d "
> +   "d:%s:%d state: %s->%s conn->refcnt:%d\n",
> pd->pp->name,
> ((state_off == TCP_DIR_OUTPUT) ?
>  "output " : "input "),
> @@ -548,10 +548,12 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct 
> ip_vs_conn *cp,
> th->fin ? 'F' : '.',
> th->ack ? 'A' : '.',
> th->rst ? 'R' : '.',
> -   IP_VS_DBG_ADDR(cp->daf, >daddr),
> -   ntohs(cp->dport),
> IP_VS_DBG_ADDR(cp->af, >caddr),
> ntohs(cp->cport),
> +   IP_VS_DBG_ADDR(cp->af, >vaddr),
> +   ntohs(cp->vport),
> +   IP_VS_DBG_ADDR(cp->daf, >daddr),
> +   ntohs(cp->dport),
> tcp_state_name(cp->state),
> tcp_state_name(new_state),
> refcount_read(>refcnt));
> -- 
> 2.20.1 (Apple Git-117)

Regards

--
Julian Anastasov 

Re: [PATCH 02/22] kvm: mmu: Introduce tdp_iter

[Sean Christopherson]

On Sat, Sep 26, 2020 at 02:04:49AM +0200, Paolo Bonzini wrote:
> On 25/09/20 23:22, Ben Gardon wrote:
> >  EXPORT_SYMBOL_GPL(kvm_mmu_set_mmio_spte_mask);
> >  
> > -static bool is_mmio_spte(u64 spte)
> > +bool is_mmio_spte(u64 spte)
> >  {
> > return (spte & SPTE_SPECIAL_MASK) == SPTE_MMIO_MASK;
> >  }
> > @@ -623,7 +612,7 @@ static int is_nx(struct kvm_vcpu *vcpu)
> > return vcpu->arch.efer & EFER_NX;
> >  }
> >  
> > -static int is_shadow_present_pte(u64 pte)
> > +int is_shadow_present_pte(u64 pte)
> >  {
> > return (pte != 0) && !is_mmio_spte(pte);
> >  }
> > @@ -633,7 +622,7 @@ static int is_large_pte(u64 pte)
> > return pte & PT_PAGE_SIZE_MASK;
> >  }
> >  
> > -static int is_last_spte(u64 pte, int level)
> > +int is_last_spte(u64 pte, int level)
> >  {
> > if (level == PG_LEVEL_4K)
> > return 1;
> > @@ -647,7 +636,7 @@ static bool is_executable_pte(u64 spte)
> > return (spte & (shadow_x_mask | shadow_nx_mask)) == shadow_x_mask;
> >  }
> >  
> > -static kvm_pfn_t spte_to_pfn(u64 pte)
> > +kvm_pfn_t spte_to_pfn(u64 pte)
> >  {
> > return (pte & PT64_BASE_ADDR_MASK) >> PAGE_SHIFT;
> >  }
> 
> Should these be inlines in mmu_internal.h instead?

Ya, that would be my preference as well.

Re: [PATCH] hwmon: fix spelling typo in comments

[Guenter Roeck]

On Sat, Sep 26, 2020 at 10:08:33AM +0800, Wang Qing wrote:
> Modify the comment typo: "compliment" -> "complement".
> 
> Signed-off-by: Wang Qing 
> ---

Applied, but in the future please list the affected driver in the
subject line.

Guenter

>  drivers/hwmon/tmp513.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/tmp513.c b/drivers/hwmon/tmp513.c
> index 23908dc..c37d321
> --- a/drivers/hwmon/tmp513.c
> +++ b/drivers/hwmon/tmp513.c
> @@ -192,7 +192,7 @@ static int tmp51x_get_value(struct tmp51x_data *data, u8 
> reg, u8 pos,
>   /*
>* The valus is read in voltage in the chip but reported as
>* current to the user.
> -  * 2's compliment number shifted by one to four depending
> +  * 2's complement number shifted by one to four depending
>* on the pga gain setting. 1lsb = 10uV
>*/
>   *val = sign_extend32(regval, 17 - tmp51x_get_pga_shift(data));

Re: [PATCH v9 0/2] Renovate memcpy_mcsafe with copy_mc_to_{user, kernel}

[Borislav Petkov]

On Tue, Sep 29, 2020 at 03:32:07PM -0700, Dan Williams wrote:
> Given that Linus was the primary source of review feedback on these
> patches and a version of them have been soaking in -next with only a
> minor conflict report with vfs.git for the entirety of the v5.9-rc
> cycle (left there inadvertently while I was on leave), any concerns
> with me sending this to Linus directly during the merge window?

What's wrong with them going through tip?

But before that pls have a look at this question I have here:

https://lkml.kernel.org/r/20200929102512.gb21...@zn.tnic

Thx.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH 5.8 35/99] tools/libbpf: Avoid counting local symbols in ABI check

[Tony Ambardar]

[adding Michael Ellerman, linux-ppc maintainer]

Hello Justin,

On Tue, 29 Sep 2020 at 14:54, Justin Forbes  wrote:
>
> On Tue, Sep 29, 2020 at 6:53 AM Greg Kroah-Hartman
>  wrote:
> >
> > From: Tony Ambardar 
> >
> > [ Upstream commit 746f534a4809e07f427f7d13d10f3a6a9641e5c3 ]
> >
> > Encountered the following failure building libbpf from kernel 5.8.5 sources
> > with GCC 8.4.0 and binutils 2.34: (long paths shortened)
> >
> >   Warning: Num of global symbols in sharedobjs/libbpf-in.o (234) does NOT
> >   match with num of versioned symbols in libbpf.so (236). Please make sure
> >   all LIBBPF_API symbols are versioned in libbpf.map.
> > #  --- libbpf_global_syms.tmp2020-09-02 07:30:58.920084380 +
> > #  +++ libbpf_versioned_syms.tmp 2020-09-02 07:30:58.924084388 +
> >   @@ -1,3 +1,5 @@
> >   +_fini
> >   +_init
> >bpf_btf_get_fd_by_id
> >bpf_btf_get_next_id
> >bpf_create_map
> >   make[4]: *** [Makefile:210: check_abi] Error 1
> >
> > Investigation shows _fini and _init are actually local symbols counted
> > amongst global ones:
> >
> >   $ readelf --dyn-syms --wide libbpf.so|head -10
> >
> >   Symbol table '.dynsym' contains 343 entries:
> >  Num:Value  Size TypeBind   Vis  Ndx Name
> >0:  0 NOTYPE  LOCAL  DEFAULT  UND
> >1: 4098 0 SECTION LOCAL  DEFAULT   11
> >2: 4098 8 FUNCLOCAL  DEFAULT   11 _init@@LIBBPF_0.0.1
> >3: 00023040 8 FUNCLOCAL  DEFAULT   14 _fini@@LIBBPF_0.0.1
> >4:  0 OBJECT  GLOBAL DEFAULT  ABS LIBBPF_0.0.4
> >5:  0 OBJECT  GLOBAL DEFAULT  ABS LIBBPF_0.0.1
> >6: ffa4 8 FUNCGLOBAL DEFAULT   12 
> > bpf_object__find_map_by_offset@@LIBBPF_0.0.1
> >
> > A previous commit filtered global symbols in sharedobjs/libbpf-in.o. Do the
> > same with the libbpf.so DSO for consistent comparison.
> >
> > Fixes: 306b267cb3c4 ("libbpf: Verify versioned symbols")
> > Signed-off-by: Tony Ambardar 
> > Signed-off-by: Alexei Starovoitov 
> > Acked-by: Andrii Nakryiko 
> > Link: 
> > https://lore.kernel.org/bpf/20200905214831.1565465-1-tony.ambar...@gmail.com
> > Signed-off-by: Sasha Levin 
>
> This seems to work everywhere else, but breaks PPC64LE.
>

I also ran into a PPC build error while working on some bpf problems,
but it seemed
like a pre-existing PPC issue. I did submit an upstream fix, which is
marked for stable
and being reviewed by Michael. See here for discussion and the patch:
https://lkml.org/lkml/2020/9/17/668.

Is that the same problem you encountered? Does that patch address your issue?

Thanks,
Tony

> Justin
>
> > ---
> >  tools/lib/bpf/Makefile |2 ++
> >  1 file changed, 2 insertions(+)
> >
> > --- a/tools/lib/bpf/Makefile
> > +++ b/tools/lib/bpf/Makefile
> > @@ -152,6 +152,7 @@ GLOBAL_SYM_COUNT = $(shell readelf -s --
> >awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print 
> > $$NF}' | \
> >sort -u | wc -l)
> >  VERSIONED_SYM_COUNT = $(shell readelf --dyn-syms --wide $(OUTPUT)libbpf.so 
> > | \
> > + awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print 
> > $$NF}' | \
> >   grep -Eo '[^ ]+@LIBBPF_' | cut -d@ -f1 | sort 
> > -u | wc -l)
> >
> >  CMD_TARGETS = $(LIB_TARGET) $(PC_FILE)
> > @@ -219,6 +220,7 @@ check_abi: $(OUTPUT)libbpf.so
> > awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$NF}'|  \
> > sort -u > $(OUTPUT)libbpf_global_syms.tmp;   \
> > readelf --dyn-syms --wide $(OUTPUT)libbpf.so |   \
> > +   awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$NF}'|  \
> > grep -Eo '[^ ]+@LIBBPF_' | cut -d@ -f1 | \
> > sort -u > $(OUTPUT)libbpf_versioned_syms.tmp;\
> > diff -u $(OUTPUT)libbpf_global_syms.tmp  \
> >
> >

Re: build failure (BTFIDS) with CONFIG_NET && !CONFIG_INET

[Yonghong Song]

On 9/29/20 3:17 AM, Michal Kubecek wrote:

Hello,

our builds of s390x for zfcpdump fail since 5.9-rc1 with

 BTFIDS  vmlinux
   FAILED unresolved symbol tcp_timewait_sock
   make[1]: *** 
[/home/abuild/rpmbuild/BUILD/kernel-zfcpdump-5.9.rc7/linux-5.9-rc7/Makefile:1176:
 vmlinux] Error 255

I believe this is caused by commit fce557bcef11 ("bpf: Make btf_sock_ids
global") and the problem is caused by a specific configuration which has
CONFIG_NET enabled but CONFIG_INET disabled. IIUC there will be no user
of struct tcp_timewait_sock but btf_ids will try to generate BTF info
for it.


Thanks for reporting! Will send a patch to fix the issue soon.



Michal

[rcu:rcu/next] BUILD SUCCESS 250c33dc20de38f275c1150f78f68ec3249e0668

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  rcu/next
branch HEAD: 250c33dc20de38f275c1150f78f68ec3249e0668  locktorture: Invoke 
percpu_free_rwsem() to do percpu-rwsem cleanup

elapsed time: 721m

configs tested: 116
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
powerpc  pcm030_defconfig
armshmobile_defconfig
mips db1xxx_defconfig
sh  sdk7780_defconfig
powerpc mpc8560_ads_defconfig
cskydefconfig
ia64generic_defconfig
mips   rbtx49xx_defconfig
powerpc  pmac32_defconfig
powerpc64alldefconfig
shsh7785lcr_defconfig
arm   efm32_defconfig
arm  tct_hammer_defconfig
powerpcicon_defconfig
arm   omap2plus_defconfig
powerpcsocrates_defconfig
pariscgeneric-64bit_defconfig
xtensa  audio_kc705_defconfig
arcvdk_hs38_defconfig
mips allmodconfig
arm  pxa255-idp_defconfig
powerpcmpc7448_hpc2_defconfig
arm  simpad_defconfig
shedosk7705_defconfig
powerpc mpc837x_rdb_defconfig
s390   zfcpdump_defconfig
m68k alldefconfig
arc haps_hs_defconfig
arcvdk_hs38_smp_defconfig
sh   sh7770_generic_defconfig
arm   h5000_defconfig
arm  ep93xx_defconfig
sh   se7780_defconfig
mips  bmips_stb_defconfig
armmmp2_defconfig
powerpc ksi8560_defconfig
armmulti_v7_defconfig
um   x86_64_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a006-20200929
i386 randconfig-a002-20200929
i386 randconfig-a003-20200929
i386 randconfig-a004-20200929
i386 randconfig-a005-20200929
i386 randconfig-a001-20200929
x86_64   randconfig-a011-20200929
x86_64   randconfig-a013-20200929
x86_64   randconfig-a015-20200929
x86_64   randconfig-a014-20200929
x86_64   randconfig-a016-20200929
x86_64   randconfig-a012-20200929
i386 randconfig-a012-20200929
i386 randconfig-a016-20200929
i386 randconfig-a014-20200929
i386 randconfig-a013-20200929
i386 randconfig-a015-20200929
i386 randconfig-a011-20200929
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig

Re: [PATCH 01/22] kvm: mmu: Separate making SPTEs from set_spte

[Sean Christopherson]

On Fri, Sep 25, 2020 at 02:22:41PM -0700, Ben Gardon wrote:
> +static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
> + unsigned int pte_access, int level,
> + gfn_t gfn, kvm_pfn_t pfn, bool speculative,
> + bool can_unsync, bool host_writable)
> +{
> + u64 spte = 0;
> + struct kvm_mmu_page *sp;
> + int ret = 0;
> +
> + if (set_mmio_spte(vcpu, sptep, gfn, pfn, pte_access))
> + return 0;
> +
> + sp = sptep_to_sp(sptep);
> +
> + spte = make_spte(vcpu, pte_access, level, gfn, pfn, *sptep, speculative,
> +  can_unsync, host_writable, sp_ad_disabled(sp), );
> + if (!spte)
> + return 0;

This is an impossible condition.  Well, maybe it's theoretically possible
if page track is active, with EPT exec-only support (shadow_present_mask is
zero), and pfn==0.  But in that case, returning early is wrong.

Rather than return the spte, what about returning 'ret', passing 'new_spte'
as a u64 *, and dropping the bail early path?  That would also eliminate
the minor wart of make_spte() relying on the caller to initialize 'ret'.

> +
> + if (spte & PT_WRITABLE_MASK)
> + kvm_vcpu_mark_page_dirty(vcpu, gfn);
> +
>   if (mmu_spte_update(sptep, spte))
>   ret |= SET_SPTE_NEED_REMOTE_TLB_FLUSH;
>   return ret;
> -- 
> 2.28.0.709.gb0816b6eb0-goog
> 

Re: [RFC][PATCH 5/6] dma-buf: system_heap: Add pagepool support to system heap

[Chris Goldsworthy]

On 2020-09-25 21:24, John Stultz wrote:

Reuse/abuse the pagepool code from the network code to speed
up allocation performance.

This is similar to the ION pagepool usage, but tries to
utilize generic code instead of a custom implementation.

Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/dma-buf/heaps/Kconfig   |  1 +
 drivers/dma-buf/heaps/system_heap.c | 32 +
 2 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/heaps/Kconfig 
b/drivers/dma-buf/heaps/Kconfig

index a5eef06c4226..f13cde4321b1 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -1,6 +1,7 @@
 config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
+   select PAGE_POOL
help
 	  Choose this option to enable the system dmabuf heap. The system 
heap

  is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 882a632e9bb7..9f57b4c8ae69 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 

 struct dma_heap *sys_heap;

@@ -46,6 +47,7 @@ struct dma_heap_attachment {
 static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP, 
LOW_ORDER_GFP};

 static const unsigned int orders[] = {8, 4, 0};
 #define NUM_ORDERS ARRAY_SIZE(orders)
+struct page_pool *pools[NUM_ORDERS];

 static struct sg_table *dup_sg_table(struct sg_table *table)
 {
@@ -264,13 +266,17 @@ static void system_heap_dma_buf_release(struct
dma_buf *dmabuf)
struct system_heap_buffer *buffer = dmabuf->priv;
struct sg_table *table;
struct scatterlist *sg;
-   int i;
+   int i, j;

table = >sg_table;
for_each_sg(table->sgl, sg, table->nents, i) {
struct page *page = sg_page(sg);

-   __free_pages(page, compound_order(page));
+   for (j = 0; j < NUM_ORDERS; j++) {
+   if (compound_order(page) == orders[j])
+   break;
+   }
+   page_pool_put_full_page(pools[j], page, false);
}
sg_free_table(table);
kfree(buffer);
@@ -300,8 +306,7 @@ static struct page
*alloc_largest_available(unsigned long size,
continue;
if (max_order < orders[i])
continue;
-
-   page = alloc_pages(order_flags[i], orders[i]);
+   page = page_pool_alloc_pages(pools[i], order_flags[i]);
if (!page)
continue;
return page;
@@ -406,6 +411,25 @@ static const struct dma_heap_ops system_heap_ops = 
{

 static int system_heap_create(void)
 {
struct dma_heap_export_info exp_info;
+   int i;
+
+   for (i = 0; i < NUM_ORDERS; i++) {
+   struct page_pool_params pp;
+
+   memset(, 0, sizeof(pp));
+   pp.order = orders[i];
+   pp.dma_dir = DMA_BIDIRECTIONAL;
+   pools[i] = page_pool_create();
+
+   if (IS_ERR(pools[i])) {
+   int j;
+
+   pr_err("%s: page pool creation failed!\n", __func__);
+   for (j = 0; j < i; j++)
+   page_pool_destroy(pools[j]);
+   return PTR_ERR(pools[i]);
+   }
+   }

exp_info.name = "system";
exp_info.ops = _heap_ops;


This is cool, I didn't know about this pooling code under /net/core.  
Nice and compact.


--
The Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project

Re: linux-next: Signed-off-by missing for commit in the rcu tree

[Paul E. McKenney]

On Wed, Sep 30, 2020 at 08:37:17AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Commit
> 
>   5f5f44ca646f ("EXP Revert "KVM: Check the allocation of pv cpu mask"")
> 
> is missing a Signed-off-by from its committer.

Good catch, fixed in current rcu/next, and apologies for the bother!

Thanx, Paul

Re: [PATCH bpf-next v4 0/6] bpf: BTF support for ksyms

[Alexei Starovoitov]

On Tue, Sep 29, 2020 at 4:50 PM Hao Luo  wrote:
>
> v3 -> v4:
>  - Rebasing
>  - Cast bpf_[per|this]_cpu_ptr's parameter to void __percpu * before
>passing into per_cpu_ptr.

Looks good, but doesn't work:
./test_progs -t ksyms_btf
test_ksyms_btf:PASS:kallsyms_fopen 0 nsec
test_ksyms_btf:PASS:ksym_find 0 nsec
test_ksyms_btf:PASS:kallsyms_fopen 0 nsec
test_ksyms_btf:PASS:ksym_find 0 nsec
test_ksyms_btf:PASS:btf_exists 0 nsec
libbpf: extern (ksym) 'bpf_prog_active': incompatible types, expected
[4] int int, but kernel has [18729] var bpf_user_rnd_state
libbpf: failed to load object 'test_ksyms_btf'
libbpf: failed to load BPF skeleton 'test_ksyms_btf': -22
test_ksyms_btf:FAIL:skel_open failed to open and load skeleton
#43 ksyms_btf:FAIL

I have the latest pahole from master. Any ideas?

Re: [RFC 6/7] KVM: X86: Expose PKS to guest and userspace

[Sean Christopherson]

On Thu, Aug 13, 2020 at 12:04:54PM -0700, Jim Mattson wrote:
> On Fri, Aug 7, 2020 at 1:47 AM Chenyi Qiang  wrote:
> >
> > Existence of PKS is enumerated via CPUID.(EAX=7H,ECX=0):ECX[31]. It is
> > enabled by setting CR4.PKS when long mode is active. PKS is only
> > implemented when EPT is enabled and requires the support of VM_{ENTRY,
> > EXIT}_LOAD_IA32_PKRS currently.
> >
> > Signed-off-by: Chenyi Qiang 
> 
> > @@ -967,7 +969,8 @@ int kvm_set_cr4(struct kvm_vcpu *vcpu, unsigned long 
> > cr4)
> >  {
> > unsigned long old_cr4 = kvm_read_cr4(vcpu);
> > unsigned long pdptr_bits = X86_CR4_PGE | X86_CR4_PSE | X86_CR4_PAE |
> > -  X86_CR4_SMEP | X86_CR4_SMAP | 
> > X86_CR4_PKE;
> > +  X86_CR4_SMEP | X86_CR4_SMAP | 
> > X86_CR4_PKE |
> > +  X86_CR4_PKS;
> 
> This list already seems overly long, but I don't think CR4.PKS belongs
> here. In volume 3 of the SDM, section 4.4.1, it says:
> 
> - If PAE paging would be in use following an execution of MOV to CR0
> or MOV to CR4 (see Section 4.1.1) and the instruction is modifying any
> of CR0.CD, CR0.NW, CR0.PG, CR4.PAE, CR4.PGE, CR4.PSE, or CR4.SMEP;
> then the PDPTEs are loaded from the address in CR3.
> 
> CR4.PKS is not in the list of CR4 bits that result in a PDPTE load.
> Since it has no effect on PAE paging, I would be surprised if it did
> result in a PDPTE load.

It does belong in the mmu_role_bits though ;-)

[PATCH 2/5] KVM: x86: Invoke vendor's vcpu_after_set_cpuid() after all common updates

[Sean Christopherson]

Move the call to kvm_x86_ops.vcpu_after_set_cpuid() to the very end of
kvm_vcpu_after_set_cpuid() to allow the vendor implementation to react
to changes made by the common code.  In the near future, this will be
used by VMX to update its CR4 guest/host masks to account for reserved
bits.  In the long term, SGX support will update the allowed XCR0 mask
for enclaves based on the vCPU's allowed XCR0.

vcpu_after_set_cpuid() (nee kvm_update_cpuid()) was originally added by
commit 2acf923e38fb ("KVM: VMX: Enable XSAVE/XRSTOR for guest"), and was
called separately after kvm_x86_ops.vcpu_after_set_cpuid() (nee
kvm_x86_ops->cpuid_update()).  There is no indication that the placement
of the common code updates after the vendor updates was anything more
than a "new function at the end" decision.

Inspection of the current code reveals no dependency on kvm_x86_ops'
vcpu_after_set_cpuid() in kvm_vcpu_after_set_cpuid() or any of its
helpers.  The bulk of the common code depends only on the guest's CPUID
configuration, kvm_mmu_reset_context() does not consume dynamic vendor
state, and there are no collisions between kvm_pmu_refresh() and VMX's
update of PT state.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/cpuid.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 37c3668a774f..963bad7bc0ff 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -121,8 +121,6 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
struct kvm_lapic *apic = vcpu->arch.apic;
struct kvm_cpuid_entry2 *best;
 
-   kvm_x86_ops.vcpu_after_set_cpuid(vcpu);
-
best = kvm_find_cpuid_entry(vcpu, 1, 0);
if (best && apic) {
if (cpuid_entry_has(best, X86_FEATURE_TSC_DEADLINE_TIMER))
@@ -146,6 +144,9 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
kvm_pmu_refresh(vcpu);
vcpu->arch.cr4_guest_rsvd_bits =
__cr4_reserved_bits(guest_cpuid_has, vcpu);
+
+   /* Invoke the vendor callback only after the above state is updated. */
+   kvm_x86_ops.vcpu_after_set_cpuid(vcpu);
kvm_x86_ops.update_exception_bitmap(vcpu);
 }
 
-- 
2.28.0

[PATCH 1/5] KVM: x86: Intercept LA57 to inject #GP fault when it's reserved

[Sean Christopherson]

From: Lai Jiangshan 

Unconditionally intercept changes to CR4.LA57 so that KVM correctly
injects a #GP fault if the guest attempts to set CR4.LA57 when it's
supported in hardware but not exposed to the guest.

Long term, KVM needs to properly handle CR4 bits that can be under guest
control but also may be reserved from the guest's perspective.  But, KVM
currently sets the CR4 guest/host mask only during vCPU creation, and
reworking flows to change that will take a bit of elbow grease.

Even if/when generic support for intercepting reserved bits exists, it's
probably not worth letting the guest set CR4.LA57 directly.  LA57 can't
be toggled while long mode is enabled, thus it's all but guaranteed to
be set once (maybe twice, e.g. by BIOS and kernel) during boot and never
touched again.  On the flip side, letting the guest own CR4.LA57 may
incur extra VMREADs.  In other words, this temporary "hack" is probably
also the right long term fix.

Fixes: fd8cb433734e ("KVM: MMU: Expose the LA57 feature to VM.")
Cc: sta...@vger.kernel.org
Cc: Lai Jiangshan 
Signed-off-by: Lai Jiangshan 
[sean: rewrote changelog]
Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/kvm_cache_regs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/kvm_cache_regs.h b/arch/x86/kvm/kvm_cache_regs.h
index cfe83d4ae625..ca0781b41df9 100644
--- a/arch/x86/kvm/kvm_cache_regs.h
+++ b/arch/x86/kvm/kvm_cache_regs.h
@@ -7,7 +7,7 @@
 #define KVM_POSSIBLE_CR0_GUEST_BITS X86_CR0_TS
 #define KVM_POSSIBLE_CR4_GUEST_BITS  \
(X86_CR4_PVI | X86_CR4_DE | X86_CR4_PCE | X86_CR4_OSFXSR  \
-| X86_CR4_OSXMMEXCPT | X86_CR4_LA57 | X86_CR4_PGE | X86_CR4_TSD)
+| X86_CR4_OSXMMEXCPT | X86_CR4_PGE | X86_CR4_TSD)
 
 #define BUILD_KVM_GPR_ACCESSORS(lname, uname)\
 static __always_inline unsigned long kvm_##lname##_read(struct kvm_vcpu *vcpu)\
-- 
2.28.0

[PATCH 0/5] KVM: x86: Handle reserved CR4 bit interception in VMX

[Sean Christopherson]

This series stems from Lai's RFC patches to intercept LA57 and let the
guest own FSGSBASE[*].  Discussion and inspection revealed that KVM does
not handle the case where LA57 is supported in hardware but not exposed to
the guest.  This is actually true for all CR4 bits, but LA57 is currently
the only bit that can be reserved and also owned by the guest.  I have
a unit test for this that I'll post separately.

Intercepting LA57 was by far the easiest fix for the immedidate bug, and
is likely the right change in the long term as there's no justification
for letting the guest own LA57.

The middle three patches adjust VMX's CR4 guest/host mask to intercept
reserved bits.  This required reworking CPUID updates to also refresh said
mask at the correct time.

The last past is Lai's, which let's the guest own FSGSBASE.  This depends
on the reserved bit handling being in place.

Ran everything through unit tests, and ran the kernel's FSGSBASE selftests
in a VM.

[*] https://lkml.kernel.org/r/20200928083047.3349-1-jiangshan...@gmail.com

Lai Jiangshan (2):
  KVM: x86: Intercept LA57 to inject #GP fault when it's reserved
  KVM: x86: Let the guest own CR4.FSGSBASE

Sean Christopherson (3):
  KVM: x86: Invoke vendor's vcpu_after_set_cpuid() after all common
updates
  KVM: x86: Move call to update_exception_bitmap() into VMX code
  KVM: VMX: Intercept guest reserved CR4 bits to inject #GP fault

 arch/x86/kvm/cpuid.c  |  6 +++---
 arch/x86/kvm/kvm_cache_regs.h |  2 +-
 arch/x86/kvm/vmx/vmx.c| 18 +-
 3 files changed, 17 insertions(+), 9 deletions(-)

-- 
2.28.0

[PATCH 4/5] KVM: VMX: Intercept guest reserved CR4 bits to inject #GP fault

[Sean Christopherson]

Intercept CR4 bits that are guest reserved so that KVM correctly injects
a #GP fault if the guest attempts to set a reserved bit.  If a feature
is supported by the CPU but is not exposed to the guest, and its
associated CR4 bit is not intercepted by KVM by default, then KVM will
fail to inject a #GP if the guest sets the CR4 bit without triggering
an exit, e.g. by toggling only the bit in question.

Note, KVM doesn't give the guest direct access to any CR4 bits that are
also dependent on guest CPUID.  Yet.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/vmx/vmx.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 223e070c48b2..4ff440e7518e 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -4037,13 +4037,16 @@ void vmx_set_constant_host_state(struct vcpu_vmx *vmx)
 
 void set_cr4_guest_host_mask(struct vcpu_vmx *vmx)
 {
-   vmx->vcpu.arch.cr4_guest_owned_bits = KVM_POSSIBLE_CR4_GUEST_BITS;
+   struct kvm_vcpu *vcpu = >vcpu;
+
+   vcpu->arch.cr4_guest_owned_bits = KVM_POSSIBLE_CR4_GUEST_BITS &
+ ~vcpu->arch.cr4_guest_rsvd_bits;
if (!enable_ept)
-   vmx->vcpu.arch.cr4_guest_owned_bits &= ~X86_CR4_PGE;
+   vcpu->arch.cr4_guest_owned_bits &= ~X86_CR4_PGE;
if (is_guest_mode(>vcpu))
-   vmx->vcpu.arch.cr4_guest_owned_bits &=
-   ~get_vmcs12(>vcpu)->cr4_guest_host_mask;
-   vmcs_writel(CR4_GUEST_HOST_MASK, ~vmx->vcpu.arch.cr4_guest_owned_bits);
+   vcpu->arch.cr4_guest_owned_bits &=
+   ~get_vmcs12(vcpu)->cr4_guest_host_mask;
+   vmcs_writel(CR4_GUEST_HOST_MASK, ~vcpu->arch.cr4_guest_owned_bits);
 }
 
 u32 vmx_pin_based_exec_ctrl(struct vcpu_vmx *vmx)
@@ -7233,6 +7236,8 @@ static void vmx_vcpu_after_set_cpuid(struct kvm_vcpu 
*vcpu)
}
}
 
+   set_cr4_guest_host_mask(vmx);
+
/* Refresh #PF interception to account for MAXPHYADDR changes. */
update_exception_bitmap(vcpu);
 }
-- 
2.28.0

[PATCH 3/5] KVM: x86: Move call to update_exception_bitmap() into VMX code

[Sean Christopherson]

Now that vcpu_after_set_cpuid() and update_exception_bitmap() are called
back-to-back, subsume the exception bitmap update into the common CPUID
update.  Drop the SVM invocation entirely as SVM's exception bitmap
doesn't vary with respect to guest CPUID.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/cpuid.c   | 1 -
 arch/x86/kvm/vmx/vmx.c | 3 +++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 963bad7bc0ff..dd62156b8868 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -147,7 +147,6 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
 
/* Invoke the vendor callback only after the above state is updated. */
kvm_x86_ops.vcpu_after_set_cpuid(vcpu);
-   kvm_x86_ops.update_exception_bitmap(vcpu);
 }
 
 static int is_efer_nx(void)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 4551a7e80ebc..223e070c48b2 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -7232,6 +7232,9 @@ static void vmx_vcpu_after_set_cpuid(struct kvm_vcpu 
*vcpu)
vmx_set_guest_uret_msr(vmx, msr, enabled ? 0 : 
TSX_CTRL_RTM_DISABLE);
}
}
+
+   /* Refresh #PF interception to account for MAXPHYADDR changes. */
+   update_exception_bitmap(vcpu);
 }
 
 static __init void vmx_set_cpu_caps(void)
-- 
2.28.0

[PATCH 5/5] KVM: x86: Let the guest own CR4.FSGSBASE

[Sean Christopherson]

From: Lai Jiangshan 

Add FSGSBASE to the set of possible guest-owned CR4 bits, i.e. let the
guest own it on VMX.  KVM never queries the guest's CR4.FSGSBASE value,
thus there is no reason to force VM-Exit on FSGSBASE being toggled.

Note, because FSGSBASE is conditionally available, this is dependent on
recent changes to intercept reserved CR4 bits and to update the CR4
guest/host mask in response to guest CPUID changes.

Cc: Paolo Bonzini 
Signed-off-by: Lai Jiangshan 
[sean: added justification in changelog]
Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/kvm_cache_regs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/kvm_cache_regs.h b/arch/x86/kvm/kvm_cache_regs.h
index ca0781b41df9..a889563ad02d 100644
--- a/arch/x86/kvm/kvm_cache_regs.h
+++ b/arch/x86/kvm/kvm_cache_regs.h
@@ -7,7 +7,7 @@
 #define KVM_POSSIBLE_CR0_GUEST_BITS X86_CR0_TS
 #define KVM_POSSIBLE_CR4_GUEST_BITS  \
(X86_CR4_PVI | X86_CR4_DE | X86_CR4_PCE | X86_CR4_OSFXSR  \
-| X86_CR4_OSXMMEXCPT | X86_CR4_PGE | X86_CR4_TSD)
+| X86_CR4_OSXMMEXCPT | X86_CR4_PGE | X86_CR4_TSD | X86_CR4_FSGSBASE)
 
 #define BUILD_KVM_GPR_ACCESSORS(lname, uname)\
 static __always_inline unsigned long kvm_##lname##_read(struct kvm_vcpu *vcpu)\
-- 
2.28.0

Re: [RFC 12/14] dt-bindings: vendor-prefixes: add Aristainetos

[Heiko Schocher]

Hello Krzysztof,

Am 28.09.2020 um 06:04 schrieb Heiko Schocher:

Hello Krzysztof,

Am 26.09.2020 um 18:28 schrieb Krzysztof Kozlowski:

Document binding for an unknown entity Aristainetos with few boards
mainlined.

Cc: Heiko Schocher 
Signed-off-by: Krzysztof Kozlowski 

---

I tried to Google but except the patches from Heiko Schocher, I could
not find any meaningful data.

Heiko, you posted this. Do you know what is it?


aristainetos is the name of the board, so it is not the vendor name.

I just asked the customer if we can add a valid vendor name...


Ok, it is not easy to get an okay from the customer to publish
his name.

Is there a dummy or unknown entry for vendor?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

[PATCH 2/3] usb: host: add uhci compatible support for ast2600-uhci

[Ryan Chen]

Add support for AST2600 SOC UHCI driver.

Signed-off-by: Ryan Chen 
---
 drivers/usb/host/uhci-platform.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/uhci-platform.c b/drivers/usb/host/uhci-platform.c
index 70dbd95c3f06..fa40fe125c2a 100644
--- a/drivers/usb/host/uhci-platform.c
+++ b/drivers/usb/host/uhci-platform.c
@@ -113,7 +113,8 @@ static int uhci_hcd_platform_probe(struct platform_device 
*pdev)
num_ports);
}
if (of_device_is_compatible(np, "aspeed,ast2400-uhci") ||
-   of_device_is_compatible(np, "aspeed,ast2500-uhci")) {
+   of_device_is_compatible(np, "aspeed,ast2500-uhci") ||
+   of_device_is_compatible(np, "aspeed,ast2600-uhci")) {
uhci->is_aspeed = 1;
dev_info(>dev,
 "Enabled Aspeed implementation workarounds\n");
-- 
2.17.1

[PATCH 0/3] Enable USB host for AST2600

[Ryan Chen]

The patches enable UHCI driver in AST2600 and also enable
USB host in aspeed-ast2600-evb.dts.

Ryan Chen (3):
  configs: aspeed: enable UHCI driver in defconfig
  usb: host: add uhci compatible support for ast2600-uhci
  ARM: dts: add ehci uhci enable in evb dts

 arch/arm/boot/dts/aspeed-ast2600-evb.dts | 8 
 arch/arm/configs/aspeed_g5_defconfig | 1 +
 drivers/usb/host/uhci-platform.c | 3 ++-
 3 files changed, 11 insertions(+), 1 deletion(-)

-- 
2.17.1

[PATCH 1/3] configs: aspeed: enable UHCI driver in defconfig

[Ryan Chen]

Enable UHCI driver in aspeed_g5_defconfig.

Signed-off-by: Ryan Chen 
---
 arch/arm/configs/aspeed_g5_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/aspeed_g5_defconfig 
b/arch/arm/configs/aspeed_g5_defconfig
index 2bacd8c90f4b..a57009d1a3b8 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -212,6 +212,7 @@ CONFIG_USB_DYNAMIC_MINORS=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_ROOT_HUB_TT=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
+CONFIG_USB_UHCI_HCD=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_ASPEED_VHUB=y
 CONFIG_USB_CONFIGFS=y
-- 
2.17.1

[PATCH 3/3] ARM: dts: add ehci uhci enable in evb dts

[Ryan Chen]

Add EHCI UHCI enable build in aspeed-ast2600-evb.dts

Signed-off-by: Ryan Chen 
---
 arch/arm/boot/dts/aspeed-ast2600-evb.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts 
b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
index 89be13197780..2772796e215e 100644
--- a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
+++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
@@ -237,3 +237,11 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.17.1

linux-next: manual merge of the bpf-next tree with the bpf tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the bpf-next tree got a conflict in:

  tools/lib/bpf/btf.c

between commit:

  1245008122d7 ("libbpf: Fix native endian assumption when parsing BTF")

from the bpf tree and commit:

  3289959b97ca ("libbpf: Support BTF loading and raw data output in both 
endianness")

from the bpf-next tree.

I fixed it up (I used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpt_fH_8zuzJ.pgp
Description: OpenPGP digital signature

Re: [Linux-kernel-mentees][PATCH] net: usb: rtl8150: prevent set_ethernet_addr from setting uninit address

[Anant Thazhemadam]

On 29/09/20 2:17 pm, Petko Manolov wrote:
> On 20-09-29 13:50:28, Anant Thazhemadam wrote:
>> When get_registers() fails (which happens when usb_control_msg() fails)
>> in set_ethernet_addr(), the uninitialized value of node_id gets copied
>> as the address.
>>
>> Checking for the return values appropriately, and handling the case
>> wherein set_ethernet_addr() fails like this, helps in avoiding the
>> mac address being incorrectly set in this manner.
>>
>> Reported-by: syzbot+abbc768b560c84d92...@syzkaller.appspotmail.com
>> Tested-by: syzbot+abbc768b560c84d92...@syzkaller.appspotmail.com
>> Signed-off-by: Anant Thazhemadam 
>> ---
>>  drivers/net/usb/rtl8150.c | 24 
>>  1 file changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
>> index 733f120c852b..e542a9ab2ff8 100644
>> --- a/drivers/net/usb/rtl8150.c
>> +++ b/drivers/net/usb/rtl8150.c
>> @@ -150,7 +150,7 @@ static const char driver_name [] = "rtl8150";
>>  **  device related part of the code
>>  **
>>  */
>> -static int get_registers(rtl8150_t * dev, u16 indx, u16 size, void *data)
>> +static int get_registers(rtl8150_t *dev, u16 indx, u16 size, void *data)
>>  {
>>  void *buf;
>>  int ret;
>> @@ -274,12 +274,17 @@ static int write_mii_word(rtl8150_t * dev, u8 phy, 
>> __u8 indx, u16 reg)
>>  return 1;
>>  }
>>  
>> -static inline void set_ethernet_addr(rtl8150_t * dev)
>> +static bool set_ethernet_addr(rtl8150_t *dev)
>>  {
>>  u8 node_id[6];
>> +int ret;
>>  
>> -get_registers(dev, IDR, sizeof(node_id), node_id);
>> -memcpy(dev->netdev->dev_addr, node_id, sizeof(node_id));
>> +ret = get_registers(dev, IDR, sizeof(node_id), node_id);
>> +if (ret > 0 && ret <= sizeof(node_id)) {
> get_registers() was recently modified to use usb_control_msg_recv() which does
> not return partial reads.  IOW you'll either get negative value or
> sizeof(node_id).  Since it is good to be paranoid i'd convert the above check
> to:
>
>   if (ret == sizeof(node_id)) {
>
> and fail in any other case.  Apart from this minor detail the rest of the 
> patch 
> looks good to me.
>
> Acked-by: Petko Manolov
Got it. I'll be sure to include this in a v2, and send that in soon enough.
Thanks for pointing that out. :)

Thanks,
Anant

Re: [PATCH 2/3] exfat: remove useless check in exfat_move_file()

[Tetsuhiro Kohada]

It might check if the cluster numbers are same between source entry
and target directory.


This checks if newdir is the move target itself.
Example:
mv /mnt/dir0 /mnt/dir0/foo

However, this check is not enough.
We need to check newdir and all ancestors.
Example:
mv /mnt/dir0 /mnt/dir0/dir1/foo
mv /mnt/dir0 /mnt/dir0/dir1/dir2/foo
...

This is probably a taboo for all layered filesystems.



Could you let me know what code you mentioned?
Or do you mean the codes on vfs?


You can find in do_renameat2(). --- around 'fs/namei.c:4440'
If the destination ancestors are itself, our driver will not be called.


I think, of course, vfs has been doing that.
So that code is unnecessary in normal situations.

That code comes from the old exfat implementation.


It could be a remnant of another system.
Once upon a time, I moved the dir to a descendant dir without implementing this 
check
and it disappeared forever.
linux-VFS fixed this issue immediately, but some systems still need to be 
checked by
the driver itself. (ex.Windows-IFS)



And as far as I understand, it seems to check once more "the cluster number"
even though it comes through vfs so that it tries detecting abnormal of on-disk.

Anyway, I agonized if it is really needed.
In conclusion, old code could be eliminated and your patch looks reasonable.


It's easy to add, but it's really hard to remove the ancient code.


BTW
I have a question for you.
Now, I'm trying to optimize exfat_get_dentry().
However, exfat_get_dentry() is used a lot, so the patch is also large.
In such a case
-Replace old implementation with new ones with a single patch.
-Devide multiple patches in which old functions and new functions (ex. 
exfat_get_dentry2) coexist temporarily. And finally clean up.

I understand that a small patch is desirable, but the latter has "two similar 
functions".
Which is better for you to review the patch?


BR
---
Tetsuhiro Kohada