Re: [RFC PATCH v2 01/16] mm,hwpoison: cleanup unused PageHuge() check

[Naoya Horiguchi]

On Fri, Oct 18, 2019 at 01:48:32PM +0200, Michal Hocko wrote:
> On Thu 17-10-19 16:21:08, Oscar Salvador wrote:
> > From: Naoya Horiguchi 
> > 
> > Drop the PageHuge check since memory_failure forks into 
> > memory_failure_hugetlb()
> > for hugetlb pages.
> > 
> > Signed-off-by: Oscar Salvador 
> > Signed-off-by: Naoya Horiguchi 
> 
> s-o-b chain is reversed.
> 
> The code is a bit confusing. Doesn't this check aim for THP?

No, PageHuge() is false for thp, so this if branch is just dead code.

> AFAICS
> PageTransHuge(hpage) will split the THP or fail so PageTransHuge
> shouldn't be possible anymore, right?

Yes, that's right.

> But why does hwpoison_user_mappings
> still work with hpage then?

hwpoison_user_mappings() is called both from memory_failure() and
from memory_failure_hugetlb(), so it need handle both cases.

Thanks,
Naoya Horiguchi

> 
> > ---
> >  mm/memory-failure.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index 05c8c6df25e6..2cbadb58c7df 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -1345,10 +1345,7 @@ int memory_failure(unsigned long pfn, int flags)
> >  * page_remove_rmap() in try_to_unmap_one(). So to determine page status
> >  * correctly, we save a copy of the page flags at this time.
> >  */
> > -   if (PageHuge(p))
> > -   page_flags = hpage->flags;
> > -   else
> > -   page_flags = p->flags;
> > +   page_flags = p->flags;
> >  
> > /*
> >  * unpoison always clear PG_hwpoison inside page lock
> > -- 
> > 2.12.3
> 
> -- 
> Michal Hocko
> SUSE Labs
> 

RE:PERSONAL LETTER FROM MRS RASHIA AMIRA

[Mr Barrister Hans Erich]

Greetings

My name is Barrister Hans Erich.

I have a client who is interested to invest in your country, she is a well 
known politician in her country and deserve a lucrative investment partnership 
with you outside her country without any delay   Please can you manage such 
investment please Kindly reply for further details.

Your full names -


Your urgent response will be appreciated

Thank you and God bless you.

Barrister Hans Erich

Yours sincerely,
Barrister Hans Erich

Re: [RFC PATCH v2 02/16] mm,madvise: call soft_offline_page() without MF_COUNT_INCREASED

[Naoya Horiguchi]

On Fri, Oct 18, 2019 at 01:52:27PM +0200, Michal Hocko wrote:
> On Thu 17-10-19 16:21:09, Oscar Salvador wrote:
> > From: Naoya Horiguchi 
> > 
> > The call to get_user_pages_fast is only to get the pointer to a struct
> > page of a given address, pinning it is memory-poisoning handler's job,
> > so drop the refcount grabbed by get_user_pages_fast
> > 
> > Signed-off-by: Naoya Horiguchi 
> > Signed-off-by: Oscar Salvador 
> > ---
> >  mm/madvise.c | 24 
> >  1 file changed, 12 insertions(+), 12 deletions(-)
> > 
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index 2be9f3fdb05e..89ed9a22ff4f 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -878,16 +878,24 @@ static int madvise_inject_error(int behavior,
> >  */
> > order = compound_order(compound_head(page));
> >  
> > -   if (PageHWPoison(page)) {
> > -   put_page(page);
> > +   /*
> > +* The get_user_pages_fast() is just to get the pfn of the
> > +* given address, and the refcount has nothing to do with
> > +* what we try to test, so it should be released immediately.
> > +* This is racy but it's intended because the real hardware
> > +* errors could happen at any moment and memory error handlers
> > +* must properly handle the race.
> > +*/
> > +   put_page(page);
> > +
> > +   if (PageHWPoison(page))
> > continue;
> > -   }
> >  
> > if (behavior == MADV_SOFT_OFFLINE) {
> > pr_info("Soft offlining pfn %#lx at process virtual 
> > address %#lx\n",
> > pfn, start);
> >  
> > -   ret = soft_offline_page(page, MF_COUNT_INCREASED);
> > +   ret = soft_offline_page(page, 0);
> 
> What does prevent this struct page to go away completely?

Nothing does it.  Memory error handler tries to pin by itself and
then determines what state the page is in now.

Thanks,
Naoya Horiguchi

> 
> > if (ret)
> > return ret;
> > continue;
> > @@ -895,14 +903,6 @@ static int madvise_inject_error(int behavior,
> >  
> > pr_info("Injecting memory failure for pfn %#lx at process 
> > virtual address %#lx\n",
> > pfn, start);
> > -
> > -   /*
> > -* Drop the page reference taken by get_user_pages_fast(). In
> > -* the absence of MF_COUNT_INCREASED the memory_failure()
> > -* routine is responsible for pinning the page to prevent it
> > -* from being released back to the page allocator.
> > -*/
> > -   put_page(page);
> > ret = memory_failure(pfn, 0);
> > if (ret)
> > return ret;
> > -- 
> > 2.12.3
> > 
> 
> -- 
> Michal Hocko
> SUSE Labs
> 

[PATCH] m68k: defconfig: Enable ICY I2C and LTC2990 on Amiga

[Geert Uytterhoeven]

Enable support for the ICY I2C board for Amiga, which is typically
equipped with an LTC2990 hwmon chip, in the Amiga and multi-platform
defconfig files.

Signed-off-by: Geert Uytterhoeven 
---
To be queued for v5.5.

 arch/m68k/configs/amiga_defconfig | 6 +-
 arch/m68k/configs/multi_defconfig | 6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/configs/amiga_defconfig 
b/arch/m68k/configs/amiga_defconfig
index 6c9d4e47cf1745dd..619d30d663a2f515 100644
--- a/arch/m68k/configs/amiga_defconfig
+++ b/arch/m68k/configs/amiga_defconfig
@@ -421,11 +421,15 @@ CONFIG_INPUT_M68K_BEEP=m
 # CONFIG_LEGACY_PTYS is not set
 CONFIG_PRINTER=m
 # CONFIG_HW_RANDOM is not set
+CONFIG_I2C=m
+CONFIG_I2C_CHARDEV=m
+CONFIG_I2C_ICY=m
 CONFIG_NTP_PPS=y
 CONFIG_PPS_CLIENT_LDISC=m
 CONFIG_PPS_CLIENT_PARPORT=m
 CONFIG_PTP_1588_CLOCK=m
-# CONFIG_HWMON is not set
+CONFIG_HWMON=m
+CONFIG_SENSORS_LTC2990=m
 CONFIG_FB=y
 CONFIG_FB_CIRRUS=y
 CONFIG_FB_AMIGA=y
diff --git a/arch/m68k/configs/multi_defconfig 
b/arch/m68k/configs/multi_defconfig
index 45654650f50a32fa..b764a0368a568be5 100644
--- a/arch/m68k/configs/multi_defconfig
+++ b/arch/m68k/configs/multi_defconfig
@@ -481,11 +481,15 @@ CONFIG_SERIAL_PMACZILOG_TTYS=y
 CONFIG_SERIAL_PMACZILOG_CONSOLE=y
 CONFIG_PRINTER=m
 # CONFIG_HW_RANDOM is not set
+CONFIG_I2C=m
+CONFIG_I2C_CHARDEV=m
+CONFIG_I2C_ICY=m
 CONFIG_NTP_PPS=y
 CONFIG_PPS_CLIENT_LDISC=m
 CONFIG_PPS_CLIENT_PARPORT=m
 CONFIG_PTP_1588_CLOCK=m
-# CONFIG_HWMON is not set
+CONFIG_HWMON=m
+CONFIG_SENSORS_LTC2990=m
 CONFIG_FB=y
 CONFIG_FB_CIRRUS=y
 CONFIG_FB_AMIGA=y
-- 
2.17.1

Re: [RFC PATCH v2 03/16] mm,madvise: Refactor madvise_inject_error

[Naoya Horiguchi]

On Thu, Oct 17, 2019 at 04:21:10PM +0200, Oscar Salvador wrote:
> Make a proper if-else condition for {hard,soft}-offline.
> 
> Signed-off-by: Oscar Salvador 

Acked-by: Naoya Horiguchi 

Re: [RFC PATCH v2 09/16] mm,hwpoison: Unify THP handling for hard and soft offline

[Naoya Horiguchi]

On Thu, Oct 17, 2019 at 04:21:16PM +0200, Oscar Salvador wrote:
> Place the THP's page handling in a helper and use it
> from both hard and soft-offline machinery, so we get rid
> of some duplicated code.
> 
> Signed-off-by: Oscar Salvador 
> ---
>  mm/memory-failure.c | 48 ++--
>  1 file changed, 22 insertions(+), 26 deletions(-)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 836d671fb74f..37b230b8cfe7 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1066,6 +1066,25 @@ static int identify_page_state(unsigned long pfn, 
> struct page *p,
>   return page_action(ps, p, pfn);
>  }
>  
> +static int try_to_split_thp_page(struct page *page, const char *msg)
> +{
> + lock_page(page);
> + if (!PageAnon(page) || unlikely(split_huge_page(page))) {
> + unsigned long pfn = page_to_pfn(page);
> +
> + unlock_page(page);
> + if (!PageAnon(page))
> + pr_info("%s: %#lx: non anonymous thp\n", msg, pfn);
> + else
> + pr_info("%s: %#lx: thp split failed\n", msg, pfn);
> + put_page(page);
> + return -EBUSY;
> + }
> + unlock_page(page);
> +
> + return 0;
> +}
> +
>  static int memory_failure_hugetlb(unsigned long pfn, int flags)
>  {
>   struct page *p = pfn_to_page(pfn);
> @@ -1288,21 +1307,8 @@ int memory_failure(unsigned long pfn, int flags)
>   }
>  
>   if (PageTransHuge(hpage)) {
> - lock_page(p);
> - if (!PageAnon(p) || unlikely(split_huge_page(p))) {
> - unlock_page(p);
> - if (!PageAnon(p))
> - pr_err("Memory failure: %#lx: non anonymous 
> thp\n",
> - pfn);
> - else
> - pr_err("Memory failure: %#lx: thp split 
> failed\n",
> - pfn);
> - if (TestClearPageHWPoison(p))
> - num_poisoned_pages_dec();
> - put_page(p);
> + if (try_to_split_thp_page(p, "Memory Failure") < 0)
>   return -EBUSY;

Although this is not a cleanup thing, this failure path means that
hwpoison is handled (PG_hwpoison is marked), so action_result() should
be called.  I'll add a patch for this later.

Anyway, this cleanup patch looks fine to me.

Acked-by: Naoya Horiguchi 

> - }
> - unlock_page(p);
>   VM_BUG_ON_PAGE(!page_count(p), p);
>   hpage = compound_head(p);
>   }
> @@ -1801,19 +1807,9 @@ static int soft_offline_in_use_page(struct page *page)
>   int mt;
>   struct page *hpage = compound_head(page);
>  
> - if (!PageHuge(page) && PageTransHuge(hpage)) {
> - lock_page(page);
> - if (!PageAnon(page) || unlikely(split_huge_page(page))) {
> - unlock_page(page);
> - if (!PageAnon(page))
> - pr_info("soft offline: %#lx: non anonymous 
> thp\n", page_to_pfn(page));
> - else
> - pr_info("soft offline: %#lx: thp split 
> failed\n", page_to_pfn(page));
> - put_page(page);
> + if (!PageHuge(page) && PageTransHuge(hpage))
> + if (try_to_split_thp_page(page, "soft offline") < 0)
>   return -EBUSY;
> - }
> - unlock_page(page);
> - }
>  
>   /*
>* Setting MIGRATE_ISOLATE here ensures that the page will be linked
> -- 
> 2.12.3
> 
> 

Re: [RFC PATCH v2 05/16] mm,hwpoison: Un-export get_hwpoison_page and make it static

[Naoya Horiguchi]

On Thu, Oct 17, 2019 at 04:21:12PM +0200, Oscar Salvador wrote:
> Since get_hwpoison_page is only used in memory-failure code now,
> let us un-export it and make it private to that code.
> 
> Signed-off-by: Oscar Salvador 

Acked-by: Naoya Horiguchi 

Re: [RFC PATCH v2 06/16] mm,hwpoison: Kill put_hwpoison_page

[Naoya Horiguchi]

On Thu, Oct 17, 2019 at 04:21:13PM +0200, Oscar Salvador wrote:
> After ("4e41a30c6d50: mm: hwpoison: adjust for new thp refcounting"),
> put_hwpoison_page got reduced to a put_page.
> Let us just use put_page instead.
> 
> Signed-off-by: Oscar Salvador 

Acked-by: Naoya Horiguchi 

Re: [RFC 0/2] Intel IFC VF driver for vdpa

[Zhu, Lingshan]

On 10/16/2019 4:26 PM, Jason Wang wrote:


On 2019/10/16 上午9:36, Zhu Lingshan wrote:

failed to send to kvm list, resend, sorry for the inconvenience.

THanks,
BR
Zhu Lingshan

On 10/16/2019 9:30 AM, Zhu Lingshan wrote:

Hi all:
  This series intends to introduce Intel IFC VF NIC driver for Vhost
Data Plane Acceleration.
  Here comes two main parts, one is ifcvf_base layer, which handles
hardware operations. The other is ifcvf_main layer handles VF
initialization, configuration and removal, which depends on
and complys to vhost_mdev https://lkml.org/lkml/2019/9/26/15
  This is a first RFC try, please help review.



It would be helpful if yon can describe which kinds of test that has 
been done for this series.


Thanks


Hi Jason,

It passed ping and netperf tests（two VMs, each has one ifc vf backed 
mdev nic）, I will mention this in next cover letter Thanks!


BR
Zhu Lingshan

  Thanks!
BR
Zhu Lingshan


Zhu Lingshan (2):
   vhost: IFC VF hardware operation layer
   vhost: IFC VF vdpa layer

  drivers/vhost/ifcvf/ifcvf_base.c | 390 
  drivers/vhost/ifcvf/ifcvf_base.h | 137 ++
  drivers/vhost/ifcvf/ifcvf_main.c | 541 
+++

  3 files changed, 1068 insertions(+)
  create mode 100644 drivers/vhost/ifcvf/ifcvf_base.c
  create mode 100644 drivers/vhost/ifcvf/ifcvf_base.h
  create mode 100644 drivers/vhost/ifcvf/ifcvf_main.c

Re: [RFC PATCH 10/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs

[Vaittinen, Matti]

Hello Bartosz,

Thanks for reading this through! I'll rework this patch during this
week :)

On Thu, 2019-10-17 at 14:45 +0200, Bartosz Golaszewski wrote:
> czw., 17 paź 2019 o 11:53 Matti Vaittinen
>  napisał(a):
> > ROHM BD71828 PMIC contains 4 pins which can be configured by OTP
> > to be used for general purposes. First 3 can be used as outputs
> > and 4.th pin can be used as input. Allow them to be controlled
> > via GPIO framework.
> > 
> > The driver assumes all of the pins are configured as GPIOs and
> > rusts that the reserved pins in other OTP configurations are
> > excluded from control using "gpio-reserved-ranges" device tree
> > property (or left untouched by GPIO users).
> > 
> > Typical use for 4.th pin (input) is to use it as HALL sensor
> > input so that this pin state is toggled when HALL sensor detects
> > LID position change (from close to open or open to close). PMIC
> > HW implements some extra logic which allows PMIC to power-up the
> > system when this pin is toggled. Please see the data sheet for
> > details of GPIO options which can be selcted by OTP settings.
> > 
> > Signed-off-by: Matti Vaittinen 
> > 
> > +++ b/drivers/gpio/gpio-bd71828.c
> > @@ -0,0 +1,161 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 ROHM Semiconductors
> > +// gpio-bd71828.c ROHM BD71828 gpio driver
> 
> I don't think the name of the source file is needed here.

I Agree.

> 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define OUT 0
> > +#define IN 1
> 
> If you really want to define those, please use a common prefix for
> all
> symbols in the driver.

I prefer defining them because I always need to check the meaning of
these values. My brains just refuse from remembering which value is
used for in and which for out. I will add the prefix even though the
scope of these defines is limited to this file :)

> 
> > +#define GPIO_OUT_REG(off) (BD71828_REG_GPIO_CTRL1 + (off))
> > +#define HALL_GPIO_OFFSET 3
> > +
> > +struct bd71828_gpio {
> > +   struct rohm_regmap_dev chip;
> > +   struct gpio_chip gpio;
> > +};
> > +
> > +static void bd71828_gpio_set(struct gpio_chip *chip, unsigned int
> > offset,
> > +int value)
> > +{
> > +   int ret;
> > +   struct bd71828_gpio *bdgpio = gpiochip_get_data(chip);
> > +   u8 val = (value) ? BD71828_GPIO_OUT_HI :
> > BD71828_GPIO_OUT_LO;
> > +
> > +   if (offset == HALL_GPIO_OFFSET)
> > +   return;
> 
> Can you add a comment here saying that this pin can only be used as
> input? Otherwise this information is only available in the commit
> message.

Sure thing. I thought the comment in get_direction was sufficient but
you are correct - it's nice to see this limitation also here.

> > +
> > +   ret = regmap_update_bits(bdgpio->chip.regmap,
> > GPIO_OUT_REG(offset),
> > +BD71828_GPIO_OUT_MASK, val);
> > +   if (ret)
> > +   dev_err(bdgpio->chip.dev, "Could not set gpio to
> > %d\n", value);
> > +}
> > +
> > +static int bd71828_gpio_get(struct gpio_chip *chip, unsigned int
> > offset)
> > +{
> > +   int ret;
> > +   unsigned int val;
> > +   struct bd71828_gpio *bdgpio = gpiochip_get_data(chip);
> > +
> > +   if (offset == HALL_GPIO_OFFSET)
> > +   ret = regmap_read(bdgpio->chip.regmap,
> > BD71828_REG_IO_STAT,
> > + &val);
> > +   else
> > +   ret = regmap_read(bdgpio->chip.regmap,
> > GPIO_OUT_REG(offset),
> > + &val);
> > +   if (!ret)
> > +   ret = (val & BD71828_GPIO_OUT_MASK);
> > +
> > +   return ret;
> > +}
> > +
> > +static int bd71828_gpio_set_config(struct gpio_chip *chip,
> > unsigned int offset,
> > +  unsigned long config)
> > +{
> > +   struct bd71828_gpio *bdgpio = gpiochip_get_data(chip);
> > +
> > +   if (offset == HALL_GPIO_OFFSET)
> > +   return -ENOTSUPP;
> > +
> > +   switch (pinconf_to_config_param(config)) {
> > +   case PIN_CONFIG_DRIVE_OPEN_DRAIN:
> > +   return regmap_update_bits(bdgpio->chip.regmap,
> > + GPIO_OUT_REG(offset),
> > + BD71828_GPIO_DRIVE_MASK,
> > + BD71828_GPIO_OPEN_DRAIN);
> > +   case PIN_CONFIG_DRIVE_PUSH_PULL:
> > +   return regmap_update_bits(bdgpio->chip.regmap,
> > + GPIO_OUT_REG(offset),
> > + BD71828_GPIO_DRIVE_MASK,
> > + BD71828_GPIO_PUSH_PULL);
> > +   default:
> > +   break;
> > +   }
> > +   return -ENOTSUPP;
> +}+static int bd71828_get_direction(struct gpio_chip *chip, unsigned
> int offset)
> > +{
> > +   /*
> > +* Pin usage is selected by OTP data. We ca

Re: [PATCH net-next v7 06/17] ethtool: netlink bitset handling

[Michal Kubecek]

On Mon, Oct 14, 2019 at 03:02:05PM +0200, Jiri Pirko wrote:
> Mon, Oct 14, 2019 at 01:18:47PM CEST, mkube...@suse.cz wrote:
> >On Fri, Oct 11, 2019 at 03:34:29PM +0200, Jiri Pirko wrote:
> >> Wed, Oct 09, 2019 at 10:59:18PM CEST, mkube...@suse.cz wrote:
> >> >+Bit sets
> >> >+
> >> >+
> >> >+For short bitmaps of (reasonably) fixed length, standard 
> >> >``NLA_BITFIELD32``
> >> >+type is used. For arbitrary length bitmaps, ethtool netlink uses a nested
> >> >+attribute with contents of one of two forms: compact (two binary bitmaps
> >> >+representing bit values and mask of affected bits) and bit-by-bit (list 
> >> >of
> >> >+bits identified by either index or name).
> >> >+
> >> >+Compact form: nested (bitset) atrribute contents:
> >> >+
> >> >+    ==  
> >> >+  ``ETHTOOL_A_BITSET_LIST`` flagno mask, only a list
> >> 
> >> I find "list" a bit confusing name of a flag. Perhaps better to stick
> >> with the "compact" terminology and make this "ETHTOOL_A_BITSET_COMPACT"?
> >> Then in the code you can have var "is_compact", which makes the code a
> >> bit easier to read I believe.
> >
> >This is not the same as "compact", "list" flag means that the bit set
> >does not represent a value/mask pair but only a single bitmap (which can
> >be understood as a list or subset of possible values).
> 
> Okay, this is confusing. So you say that the "LIST" may be on and
> ETHTOOL_A_BITSET_VALUE present, but ETHTOOL_A_BITSET_MASK not?
> I thought that whtn "LIST" is on, no "VALUE" nor "MASK" should be here.
> 
> >This saves some space in kernel replies where there is no natural mask
> >so that we would have to invent one (usually all possible bits) but it
> 
> Do you have an example?

E.g. peer advertised link modes or the four bitmaps returned in reply to
query for netdev features (replacement for ETHTOOL_GFEATURES).

> >is more important in request where some request want to modify a subset
> >of bits (set some, unset some) while some requests pass a list of bits
> >to be set after the operation (i.e. "I want exactly these to be
> >enabled").
> 
> Hmm, it's a different type of bitset then. Wouldn't it be better to have
> ETHTOOL_A_BITSET_TYPE
> and enum:
> ETHTOOL_A_BITSET_TYPE_LIST
> ETHTOOL_A_BITSET_TYPE_MASKED
> or something like that?
> Or maybe just NLA_FLAG called "MASKED". I don't know, "list" has a
> specific meaning and this isn't that...

"MASKED" sounds fine to me. After all, there is a good chance there will
be more cases when bitset without mask will be returned so that it would
be natural to see unmasked bitmaps as default and value/mask pairs as
something special.

> >> B) Why don't you do bitmap_to_arr32 conversion in this function just
> >>before val/mask put. Then you can use normal test_bit() here.
> >
> >This relates to the question (below) why we need two versions of the
> >functions, one for unsigned long based bitmaps, one for u32 based ones.
> >The reason is that both are used internally by existing code. So if we
> >had only one set of bitset functions, callers using the other format
> >would have to do the wrapping themselves.
> >
> >There are two reasons why u32 versions are implemented directly and
> >usingned long ones as wrappers. First, u32 based bitmaps are more
> >frequent in existing code. Second, when we can get away with a cast
> >(i.e. anywhere exect 64-bit big endian), unsigned long based bitmap can
> >be always interpreted as u32 based bitmap but if we tried it the other
> >way, we would need a special handling of the last word when the number
> >of 32-bit words is odd.
> 
> Okay. Perhaps you can add it as a comment so it is clear what is going
> on?

OK

Michal

Re: [PATCH] driver:st1633: fixed multitouch incorrect coordinates

[Martin Kepplinger]

On 20.10.19 10:29, Dixit Parmar wrote:
> Any review comments for this?
> Or it should be merged?
> 
> Thanks.

My comment and tag is there. This fixes multitouch and should be merged.

  martin


> 
> 
> On Thu, Aug 22, 2019 at 02:08:14PM +0200, Martin Kepplinger wrote:
>> Am 19.08.2019 12:08 schrieb Dixit Parmar:
>>> From: Dixit Parmar 
>>>
>>> For Sitronix st1633 multi-touch controller driver the co-ordinates
>>> reported
>>> for multiple fingers were wrong.
>>>
>>> So the below mentioned bug was filed,
>>> Bugzilla Bug ID: 204561
>>>
>>> While reading co-ordinates from specified I2C registers, the X & Y
>>> co-ordinates should be read from proper I2C address for particular
>>> finger as
>>> specified in chip specific datasheet.
>>>
>>> for single touch this logic is working fine. However, for multi-touch
>>> scenario the logic of reading data from data buffer has issues.
>>>
>>> This patch fixes the reading logic from data buffer.
>>>
>>> Previous logic:
>>> * Offset of X & Y Lower byte coordinate is increased by i no. only(by 1
>>> Byte)
>>>   for each finger.
>>>
>>> New logic:
>>> * The logic of reading X & Y Lower Byte coordinate needs to be increased
>>>   by i+y for each time/finger.
>>>
>>> Signed-off-by: Dixit Parmar 
>>> ---
>>>  drivers/input/touchscreen/st1232.c | 6 --
>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/input/touchscreen/st1232.c
>>> b/drivers/input/touchscreen/st1232.c
>>> index 3492339..1139714 100644
>>> --- a/drivers/input/touchscreen/st1232.c
>>> +++ b/drivers/input/touchscreen/st1232.c
>>> @@ -81,8 +81,10 @@ static int st1232_ts_read_data(struct st1232_ts_data
>>> *ts)
>>> for (i = 0, y = 0; i < ts->chip_info->max_fingers; i++, y += 3) {
>>> finger[i].is_valid = buf[i + y] >> 7;
>>> if (finger[i].is_valid) {
>>> -   finger[i].x = ((buf[i + y] & 0x0070) << 4) | buf[i + 1];
>>> -   finger[i].y = ((buf[i + y] & 0x0007) << 8) | buf[i + 2];
>>> +   finger[i].x = ((buf[i + y] & 0x0070) << 4) |
>>> +   buf[i + y + 1];
>>> +   finger[i].y = ((buf[i + y] & 0x0007) << 8) |
>>> +   buf[i + y + 2];
>>
>> Seems like you're right. It's simply +1 (for x) and +2 (for y) from the
>> high-byte locations.
>> Not sure how that went wrong.
>>
>> Thank you,
>>
>> Reviewed-by: Martin Kepplinger 
>>
>>
>>>
>>> /* st1232 includes a z-axis / touch strength */
>>> if (ts->chip_info->have_z)
>>

Re: [RFC] lib: optimize cpumask_local_spread()

[Shaokun Zhang]

Hi Michal,

On 2019/10/17 20:37, Michal Hocko wrote:
> On Thu 17-10-19 18:23:08, Shaokun Zhang wrote:
>> From: yuqi jin 
>>
>> In the multi-processor and NUMA system, A device may have many numa
>> nodes belonging to multiple cpus. When we get a local numa, it is better
>> to find the node closest to the local numa node to return instead of
>> going to the online cpu immediately.
>>
>> For example, In Huawei Kunpeng 920 system, there are 4 NUMA node(0 -3)
>> in the 2-socket system(0 - 1). If the I/O device is in socket1
>> and the local NUMA node is 2, we shall choose the non-local node3 in
>> the same socket when cpu core in NUMA node2 is less that I/O requirements.
>> If we directly pick one cpu core from all online ones, it may be in
>> the another socket and it is not friendly for performance.
> 
> Could you be more specific on the effect of this patch please? Do you
> have any performance numbers?

The NIC driver calls this function to determine the core which irq will be 
binded to,
and the initialization of XPS depends on the binding of irqs. The NIC driver 
will get
the local NUMA node where it is located.

On Huawei Kunpeng 920 SoC, there are 4-NUMA nodes and there is 24-cores per 
node.
If the function paratmer @i = 0-23 and @node = 2, then the core which is 
located on
node 2 and irq will be binded to node2.
If the parameter @i = 24-47 and @node = 2, without this patch, it will return 
the
core which is on NUMA node0; Applied the patch, it will return NUMA node3 cpu 
cores
which are in the same sokcet.

without the patch, the performance is 22W QPS and added this patch, the 
performance
become better and it is 26W QPS.

I'm not sure whether anyone also hits this problem and send it as a RFC.

> Also is it safe and reasonable to perform GFP_KERNEL (aka sleepable)
> allocations from this function?
> 

Good catch, I missed it and it should be GFP_ATOMIC.

Thanks,
Shaokun.

>> Cc: Andrew Morton 
>> Cc: Mike Rapoport 
>> Cc: Paul Burton 
>> Cc: Michal Hocko 
>> Cc: Michael Ellerman 
>> Cc: Anshuman Khandual 
>> Signed-off-by: yuqi jin 
>> Signed-off-by: Shaokun Zhang 
>> ---
>>  lib/cpumask.c | 78 
>> ++-
>>  1 file changed, 67 insertions(+), 11 deletions(-)
>>
>> diff --git a/lib/cpumask.c b/lib/cpumask.c
>> index 0cb672eb107c..8f89c7cebfb0 100644
>> --- a/lib/cpumask.c
>> +++ b/lib/cpumask.c
>> @@ -192,6 +192,33 @@ void __init free_bootmem_cpumask_var(cpumask_var_t mask)
>>  }
>>  #endif
>>  
>> +static void calc_node_distance(int *node_dist, int node)
>> +{
>> +int i;
>> +
>> +for (i = 0; i < nr_node_ids; i++)
>> +node_dist[i] = node_distance(node, i);
>> +}
>> +
>> +static int find_nearest_node(int *node_dist, bool *used_flag)
>> +{
>> +int i, min_dist = node_dist[0], node_id = -1;
>> +
>> +for (i = 0; i < nr_node_ids; i++)
>> +if (used_flag[i] == 0) {
>> +min_dist = node_dist[i];
>> +node_id = i;
>> +break;
>> +}
>> +for (i = 0; i < nr_node_ids; i++)
>> +if (node_dist[i] < min_dist && used_flag[i] == 0) {
>> +min_dist = node_dist[i];
>> +node_id = i;
>> +}
>> +
>> +return node_id;
>> +}
>> +
>>  /**
>>   * cpumask_local_spread - select the i'th cpu with local numa cpu's first
>>   * @i: index number
>> @@ -205,7 +232,8 @@ void __init free_bootmem_cpumask_var(cpumask_var_t mask)
>>   */
>>  unsigned int cpumask_local_spread(unsigned int i, int node)
>>  {
>> -int cpu;
>> +int cpu, j, id, *node_dist;
>> +bool *used_flag;
>>  
>>  /* Wrap: we always want a cpu. */
>>  i %= num_online_cpus();
>> @@ -215,19 +243,47 @@ unsigned int cpumask_local_spread(unsigned int i, int 
>> node)
>>  if (i-- == 0)
>>  return cpu;
>>  } else {
>> -/* NUMA first. */
>> -for_each_cpu_and(cpu, cpumask_of_node(node), cpu_online_mask)
>> -if (i-- == 0)
>> -return cpu;
>> +node_dist = kmalloc_array(nr_node_ids,
>> +sizeof(int), GFP_KERNEL);
>> +if (!node_dist)
>> +for_each_cpu(cpu, cpu_online_mask)
>> +if (i-- == 0)
>> +return cpu;
>>  
>> -for_each_cpu(cpu, cpu_online_mask) {
>> -/* Skip NUMA nodes, done above. */
>> -if (cpumask_test_cpu(cpu, cpumask_of_node(node)))
>> -continue;
>> +used_flag = kmalloc_array(nr_node_ids,
>> +sizeof(bool), GFP_KERNEL);
>> +if (!used_flag)
>> +for_each_cpu(cpu, cpu_online_mask)
>> +if (i-- == 0) {
>> +kfree(node_dist);
>> +return cpu;
>> +

Re: [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function

[masonccyang]

Hi Miquel,


> > > > Then fill-in these two hooks from the manufacturer code, without 
the
> > > > postponed init.
> > > > 
> > > 
> > > But in the final of nand_scan_tail(), mtd->_lock/_unlock will be
> > > filled by NULL, right ?
> > 
> > The NAND core should set mtd->_lock/_unlock() to NAND specific hooks 
so
> > that the MTD layer is abstracted and and drivers do not see it. Then,
> > in the NAND helper, either there is no specific hook defined by a
> > manufacturer driver and you return -ENOTSUPP, or you execute the
> > defined hook.
> 
> okay, patch specific manufacturer _lock/_unlock driver
> in nand_manufacturer_init();
> 
> and in the final of nand_scan_tail()
> if (!mtd->_lock)
>  mtd->_lock = NULL;
> if (!mtd->_unlock)
>  mtd->_unlock = NULL;
 

I'm still considering of post_init() in nand_scan_tail() for
MTD layer default call-back function replacement because
there would be more call-back functions need it.
i.e., 
MTD->_lock/_unlokc
MTD->_suspend/_resume
NTD->_point/_unpoint
...


actually, my patch series are including MTD->_locl/_unlock and 
MTD->_suspend/_resume. how do you think ?


thanks for your time & comments.
Mason


CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information 
and/or personal data, which is protected by applicable laws. Please be 
reminded that duplication, disclosure, distribution, or use of this e-mail 
(and/or its attachments) or any part thereof is prohibited. If you receive 
this e-mail in error, please notify us immediately and delete this mail as 
well as its attachment(s) from your system. In addition, please be 
informed that collection, processing, and/or use of personal data is 
prohibited unless expressly permitted by personal data protection laws. 
Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=





CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information and/or 
personal data, which is protected by applicable laws. Please be reminded that 
duplication, disclosure, distribution, or use of this e-mail (and/or its 
attachments) or any part thereof is prohibited. If you receive this e-mail in 
error, please notify us immediately and delete this mail as well as its 
attachment(s) from your system. In addition, please be informed that 
collection, processing, and/or use of personal data is prohibited unless 
expressly permitted by personal data protection laws. Thank you for your 
attention and cooperation.

Macronix International Co., Ltd.

=

Re: [BUGFIX PATCH 0/5] selftests: Fixes for 32bit arch

[Masami Hiramatsu]

Hi Shuah,

On Fri, 18 Oct 2019 15:45:56 -0600
shuah  wrote:

> On 10/7/19 9:10 AM, Masami Hiramatsu wrote:
> > Hi,
> > 
> > Here are some patches to fix some warnings/issues on 32bit arch
> > (e.g. arm).
> > 
> > When I built the ksefltest on arm, I hit some 32bit related warnings.
> > Here are the patches to fix those issues.
> > 
> > 
> >   - [1/5] va_max was set 2^32 even on 32bit arch. This can make
> >  va_max == 0 and always fail. Make it 3GB on 32bit.
> >   - [2/5] Some VM tests requires 64bit user space, which should
> >  not run on 32bit arch.
> >   - [3/5] For counting the size of large file, we should use
> >  size_t instead of unsinged long.
> >   - [4/5] Gcc warns printf format for size_t and int64_t on
> >  32bit arch. Use %llu and cast it.
> >   - [5/5] Gcc warns __u64 and pointer type castings. It should
> >  once translated to unsigned long.
> > 
> > Thank you,
> > 
> > ---
> > 
> > Masami Hiramatsu (5):
> >selftests: proc: Make va_max 3GB on 32bit arch
> >selftests: vm: Build/Run 64bit tests only on 64bit arch
> >selftests: net: Use size_t and ssize_t for counting file size
> >selftests: net: Fix printf format warnings on arm
> >selftests: sync: Fix cast warnings on arm
> > 
> > 
> >   tools/testing/selftests/net/so_txtime.c|4 ++--
> >   tools/testing/selftests/net/tcp_mmap.c |8 
> >   tools/testing/selftests/net/udpgso.c   |3 ++-
> >   tools/testing/selftests/net/udpgso_bench_tx.c  |3 ++-
> >   .../selftests/proc/proc-self-map-files-002.c   |   11 ++-
> >   tools/testing/selftests/sync/sync.c|6 +++---
> >   tools/testing/selftests/vm/Makefile|5 +
> >   tools/testing/selftests/vm/run_vmtests |   10 ++
> >   8 files changed, 38 insertions(+), 12 deletions(-)
> > 
> > --
> > Masami Hiramatsu (Linaro) 
> > 
> 
> Hi Masami,
> 
> I would love to pull these in. But looks like these are spread out
> across several sub-systems.

Right.

> 
> There are some comments on vm patch. Do you mind sending them again
> cc'ing everybody on the cover-letter. Looks like these are getting
> lost in the noise.
> 

OK, I'll update it and resend.

Thank you,


> thanks,
> -- Shuah


-- 
Masami Hiramatsu 

Re: [PATCH] m68k: defconfig: Enable ICY I2C and LTC2990 on Amiga

[Max Staudt]

Looks good, thanks Geert!

Acked-by: Max Staudt 

Re: [PATCH] iommu/vt-d: Fix panic after kexec -p for kdump

[Lu Baolu]

Hi John,

On 10/18/19 10:17 PM, John Donnelly wrote:

This cures a panic on restart after a kexec -p  operation on 5.3 and 5.4 
kernels.

The underlying state of the iommu registers (iommu->flags &
VTD_FLAG_TRANS_PRE_ENABLED) on a restart results in a domain being marked as
"DEFER_DEVICE_DOMAIN_INFO" that produces an Oops in identity_mapping().

[   43.654737] BUG: kernel NULL pointer dereference, address:
0056
[   43.655720] #PF: supervisor read access in kernel mode
[   43.655720] #PF: error_code(0x) - not-present page
[   43.655720] PGD 0 P4D 0
[   43.655720] Oops:  [#1] SMP PTI
[   43.655720] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.3.2-1940.el8uek.x86_64 #1
[   43.655720] Hardware name: Oracle Corporation ORACLE SERVER
X5-2/ASM,MOTHERBOARD,1U, BIOS 30140300 09/20/2018
[   43.655720] RIP: 0010:iommu_need_mapping+0x29/0xd0
[   43.655720] Code: 00 0f 1f 44 00 00 48 8b 97 70 02 00 00 48 83 fa ff
74 53 48 8d 4a ff b8 01 00 00 00 48 83 f9 fd 76 01 c3 48 8b 35 7f 58 e0
01 <48> 39 72 58 75 f2 55 48 89 e5 41 54 53 48 8b 87 28 02 00 00 4c 8b
[   43.655720] RSP: 0018:c901b9b0 EFLAGS: 00010246
[   43.655720] RAX: 0001 RBX: 1000 RCX:
fffd
[   43.655720] RDX: fffe RSI: 8880719b8000 RDI:
8880477460b0
[   43.655720] RBP: c901b9e8 R08:  R09:
888047c01700
[   43.655720] R10: 2194036fc692 R11:  R12:

[   43.655720] R13: 8880477460b0 R14: 0cc0 R15:
888072d2b558
[   43.655720] FS:  () GS:888071c0()
knlGS:
[   43.655720] CS:  0010 DS:  ES:  CR0: 80050033
[   43.655720] CR2: 0056 CR3: 7440a002 CR4:
001606b0
[   43.655720] Call Trace:
[   43.655720]  ? intel_alloc_coherent+0x2a/0x180
[   43.655720]  ? __schedule+0x2c2/0x650
[   43.655720]  dma_alloc_attrs+0x8c/0xd0
[   43.655720]  dma_pool_alloc+0xdf/0x200
[   43.655720]  ehci_qh_alloc+0x58/0x130
[   43.655720]  ehci_setup+0x287/0x7ba
[   43.655720]  ? _dev_info+0x6c/0x83
[   43.655720]  ehci_pci_setup+0x91/0x436
[   43.655720]  usb_add_hcd.cold.48+0x1d4/0x754
[   43.655720]  usb_hcd_pci_probe+0x2bc/0x3f0
[   43.655720]  ehci_pci_probe+0x39/0x40
[   43.655720]  local_pci_probe+0x47/0x80
[   43.655720]  pci_device_probe+0xff/0x1b0
[   43.655720]  really_probe+0xf5/0x3a0
[   43.655720]  driver_probe_device+0xbb/0x100
[   43.655720]  device_driver_attach+0x58/0x60
[   43.655720]  __driver_attach+0x8f/0x150
[   43.655720]  ? device_driver_attach+0x60/0x60
[   43.655720]  bus_for_each_dev+0x74/0xb0
[   43.655720]  driver_attach+0x1e/0x20
[   43.655720]  bus_add_driver+0x151/0x1f0
[   43.655720]  ? ehci_hcd_init+0xb2/0xb2
[   43.655720]  ? do_early_param+0x95/0x95
[   43.655720]  driver_register+0x70/0xc0
[   43.655720]  ? ehci_hcd_init+0xb2/0xb2
[   43.655720]  __pci_register_driver+0x57/0x60
[   43.655720]  ehci_pci_init+0x6a/0x6c
[   43.655720]  do_one_initcall+0x4a/0x1fa
[   43.655720]  ? do_early_param+0x95/0x95
[   43.655720]  kernel_init_freeable+0x1bd/0x262
[   43.655720]  ? rest_init+0xb0/0xb0
[   43.655720]  kernel_init+0xe/0x110
[   43.655720]  ret_from_fork+0x24/0x50



Good catch. Can you please add:

Fixes: 8af46c784ecfe ("iommu/vt-d: Implement is_attach_deferred iommu 
ops entry")

Cc: sta...@vger.kernel.org # v5.3+

With above:

Reviewed-by: Lu Baolu 

Best regards,
Baolu


Signed-off-by: John Donnelly 
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c4e0e4a9ee9e..f83a9a302f8e 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2783,7 +2783,7 @@ static int identity_mapping(struct device *dev)
struct device_domain_info *info;

info = dev->archdata.iommu;
-   if (info && info != DUMMY_DEVICE_DOMAIN_INFO)
+   if (info && info != DUMMY_DEVICE_DOMAIN_INFO && info != 
DEFER_DEVICE_DOMAIN_INFO)
return (info->domain == si_domain);

return 0;

Re: WARNING: ODEBUG bug in del_timer

[Dmitry Vyukov]

On Sat, Oct 19, 2019 at 1:36 AM zzoru  wrote:
>
> Hi
>
> The customizations are related to driver fuzzing.
> We added some more descriptions of USB driver & narrowed the
> constraints (targeted fuzzing).

Please consider upstreaming these improvements to syzkaller.

> And sorry about I have not much time to make patches of these bugs.
>
> On Fri, Oct 18, 2019 at 2:33 AM Dmitry Vyukov  wrote:
> >
> > On Wed, Oct 16, 2019 at 11:59 AM zzoru  wrote:
> > >
> > > We found the following crash on Linux 5.4-rc1 (Not patched in currnet
> > > HEAD commit 3b1f00aceb7a67bf079a5a64aa5c6baf78a8f442)
> > > with our customized syzkaller.
> >
> > Hi zzoru,
> >
> > Do you mind sharing what customizations you did to syzkaller? Are
> > these related to USB? I've noticed several reports were related to USB
> > subsystem.
> >
> > > ODEBUG: assert_init not available (active state 0) object type:
> > > timer_list hint: 0x0
> > > WARNING: CPU: 0 PID: 141 at linux/lib/debugobjects.c:484
> > > debug_print_object+0x15e/0x220 linux/lib/debugobjects.c:481
> > > Kernel panic - not syncing: panic_on_warn set ...
> > > CPU: 0 PID: 141 Comm: kworker/0:3 Not tainted 5.4.0-rc1 #5
> > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > > rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
> > > Workqueue: usb_hub_wq hub_event
> > > Call Trace:
> > >  __dump_stack linux/lib/dump_stack.c:77 [inline]
> > >  dump_stack+0x7c/0xbb linux/lib/dump_stack.c:113
> > >  panic+0x205/0x48e linux/kernel/panic.c:220
> > >  __warn+0x19c/0x1c0 linux/kernel/panic.c:581
> > >  report_bug+0x1a9/0x2b0 linux/lib/bug.c:195
> > >  fixup_bug.part.11+0x32/0x80 linux/arch/x86/kernel/traps.c:179
> > >  fixup_bug linux/arch/x86/include/asm/irqflags.h:54 [inline]
> > >  do_error_trap+0xf5/0x160 linux/arch/x86/kernel/traps.c:272
> > >  do_invalid_op+0x31/0x40 linux/arch/x86/kernel/traps.c:291
> > >  invalid_op+0x23/0x30 linux/arch/x86/entry/entry_64.S:1028
> > > RIP: 0010:debug_print_object+0x15e/0x220 linux/lib/debugobjects.c:481
> > > Code: 3c dd 80 05 9a 85 48 89 fa 48 c1 ea 03 80 3c 02 00 75 7f 48 8b
> > > 14 dd 80 05 9a 85 4c 89 ee 48 c7 c7 00 fb 99 85 e8 d2 a7 43 ff <0f> 0b
> > > 83 05 cd bd 70 05 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
> > > RSP: 0018:888017017668 EFLAGS: 00010282
> > > RAX:  RBX: 0005 RCX: 814153b0
> > > RDX:  RSI: 0008 RDI: 88801a41f730
> > > RBP: 0001 R08: ed1003483ee7 R09: ed1003483ee7
> > > R10: 0001 R11: ed1003483ee6 R12: 86908460
> > > R13: 859a01a0 R14: 812b6bc0 R15: 888017fb0420
> > >  debug_object_assert_init+0x290/0x430 linux/lib/debugobjects.c:866
> > >  debug_timer_assert_init linux/kernel/time/timer.c:729 [inline]
> > >  debug_assert_init linux/kernel/time/timer.c:774 [inline]
> > >  del_timer+0x67/0xf0 linux/kernel/time/timer.c:1196
> > >  realtek_cr_destructor+0x5a/0x90 
> > > linux/drivers/usb/storage/realtek_cr.c:937
> > >  usb_stor_release_resources linux/drivers/usb/storage/usb.c:817 [inline]
> > >  release_everything+0xc0/0x2c0 linux/drivers/usb/storage/usb.c:879
> > >  usb_unbind_interface+0x19f/0x810 linux/drivers/usb/core/driver.c:423
> > >  __device_release_driver linux/drivers/base/dd.c:1134 [inline]
> > >  device_release_driver_internal+0x429/0x4f0 linux/drivers/base/dd.c:1165
> > >  bus_remove_device+0x2d1/0x490 linux/drivers/base/bus.c:532
> > >  device_del+0x403/0xaa0 linux/drivers/base/core.c:2375
> > >  usb_disable_device+0x1d7/0x5f0 linux/drivers/usb/core/message.c:1237
> > >  usb_disconnect+0x25a/0x840 linux/drivers/usb/core/hub.c:2199
> > >  hub_port_connect linux/drivers/usb/core/hub.c:4949 [inline]
> > >  hub_port_connect_change linux/drivers/usb/core/hub.c:5213 [inline]
> > >  port_event linux/drivers/usb/core/hub.c:5359 [inline]
> > >  hub_event+0x11f5/0x3610 linux/drivers/usb/core/hub.c:5441
> > >  process_one_work+0x8b5/0x17c0 linux/kernel/workqueue.c:2269
> > >  worker_thread+0x82/0xb80 linux/kernel/workqueue.c:2415
> > >  kthread+0x325/0x3e0 linux/kernel/kthread.c:255
> > >  ret_from_fork+0x24/0x30 linux/arch/x86/entry/entry_64.S:352
> > > Dumping ftrace buffer:
> > >(ftrace buffer empty)
> > > Kernel Offset: disabled
> > >
> > > Following is my analysis of this bug (Just add some comments in source 
> > > code):
> > > https://github.com/torvalds/linux/blob/e0703556644a531e50b5dc61b9f6ea83af5f6604/drivers/usb/storage/realtek_cr.c#L887-L891
> > > static int realtek_cr_autosuspend_setup(struct us_data *us)
> > > {
> > > ...
> > > if (retval != STATUS_SUCCESS) {
> > > usb_stor_dbg(us, "Read status fail\n");
> > > return -EIO; // Error!
> > > }
> > > ...
> > > timer_setup(&chip->rts51x_suspend_timer, rts51x_suspend_timer_fn,
> > > 0); // rts51x_suspend_timer wasn't be initialized. When
> > > realtek_cr_autosuspend_setup just returns an error.
> > > }
> > >
> > >
> > > https://github.com/torvalds/linux/blob/e0703556644a53

[PATCH v3] HID: core: check whether usage page item is after usage id item

[Candle Sun]

From: Candle Sun 

Upstream commit 58e75155009c ("HID: core: move Usage Page concatenation
to Main item") adds support for Usage Page item after Usage ID items
(such as keyboards manufactured by Primax).

Usage Page concatenation in Main item works well for following report
descriptor patterns:

USAGE_PAGE (Keyboard)   05 07
USAGE_MINIMUM (Keyboard LeftControl)19 E0
USAGE_MAXIMUM (Keyboard Right GUI)  29 E7
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (8)95 08
INPUT (Data,Var,Abs)81 02

-

USAGE_MINIMUM (Keyboard LeftControl)19 E0
USAGE_MAXIMUM (Keyboard Right GUI)  29 E7
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (8)95 08
USAGE_PAGE (Keyboard)   05 07
INPUT (Data,Var,Abs)81 02

But it makes the parser act wrong for the following report
descriptor pattern(such as some Gamepads):

USAGE_PAGE (Button) 05 09
USAGE (Button 1)09 01
USAGE (Button 2)09 02
USAGE (Button 4)09 04
USAGE (Button 5)09 05
USAGE (Button 7)09 07
USAGE (Button 8)09 08
USAGE (Button 14)   09 0E
USAGE (Button 15)   09 0F
USAGE (Button 13)   09 0D
USAGE_PAGE (Consumer Devices)   05 0C
USAGE (Back)0a 24 02
USAGE (HomePage)0a 23 02
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (11)   95 0B
INPUT (Data,Var,Abs)81 02

With Usage Page concatenation in Main item, parser recognizes all the
11 Usages as consumer keys, it is not the HID device's real intention.

This patch adds usage_page_last to flag whether Usage Page is after
Usage ID items. usage_page_last is false default, it is set as true
once Usage Page item is encountered and is reverted by next Usage ID
item.

Usage Page concatenation on the currently defined Usage Page will do
firstly in Local parsing when Usage ID items encountered.

When Main item is parsing, concatenation will do again with last
defined Usage Page if usage_page_last flag is true.

Signed-off-by: Candle Sun 
Signed-off-by: Nianfu Bai 
---
Changes in v3:
- Rework the GET_COMPLETE_USAGE macro as static complete_usage()
  function
- Add some code comments for usage_page_last

Changes in v2:
- Update patch title
- Add GET_COMPLETE_USAGE macro
- Change the logic of checking whether to concatenate usage page again
  in main parsing
---
 drivers/hid/hid-core.c | 42 +-
 include/linux/hid.h|  1 +
 2 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 3eaee2c37931..779b7798dae8 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -211,6 +211,18 @@ static unsigned hid_lookup_collection(struct hid_parser 
*parser, unsigned type)
return 0; /* we know nothing about this usage type */
 }
 
+/*
+ * Concatenate usage which defines 16 bits or less with the
+ * currently defined usage page to form a 32 bit usage
+ */
+
+static void complete_usage(struct hid_parser *parser, unsigned int index)
+{
+   parser->local.usage[index] &= 0x;
+   parser->local.usage[index] |=
+   (parser->global.usage_page & 0x) << 16;
+}
+
 /*
  * Add a usage to the temporary parser table.
  */
@@ -221,7 +233,18 @@ static int hid_add_usage(struct hid_parser *parser, 
unsigned usage, u8 size)
hid_err(parser->device, "usage index exceeded\n");
return -1;
}
-   parser->local.usage[parser->local.usage_index] = usage;
+
+   /*
+* If Usage item only includes usage id, concatenate it with
+* currently defined usage page and clear usage_page_last flag
+*/
+   if (size <= 2) {
+   parser->local.usage_page_last = false;
+   complete_usage(parser, parser->local.usage_index);
+   } else {
+   parser->local.usage[parser->local.usage_index] = usage;
+   }
+
parser->local.usage_size[parser->local.usage_index] = size;
parser->local.collection_index[parser->local.usage_index] =
parser->collection_stack_ptr ?
@@ -366,6 +389,8 @@ static int hid_parser_global(struct hid_parser *parser, 
struct hid_item *item)
 
case HID_GLOBAL_ITEM_TAG_USAGE_PAGE:

Re: [PATCH] iommu/vt-d: Fix panic after kexec -p for kdump

[Lu Baolu]

By the way, Joerg Roedel  is the IOMMU subsystem
maintainer. If you have a v2, please add his email in the "To" list.

You can always use scripts/get_maintainer.pl to check who should the
patch be sent to. :-)

Best regards,
Baolu

On 10/21/19 3:27 PM, Lu Baolu wrote:

Hi John,

On 10/18/19 10:17 PM, John Donnelly wrote:
This cures a panic on restart after a kexec -p  operation on 5.3 and 
5.4 kernels.


The underlying state of the iommu registers (iommu->flags &
VTD_FLAG_TRANS_PRE_ENABLED) on a restart results in a domain being 
marked as

"DEFER_DEVICE_DOMAIN_INFO" that produces an Oops in identity_mapping().

[   43.654737] BUG: kernel NULL pointer dereference, address:
0056
[   43.655720] #PF: supervisor read access in kernel mode
[   43.655720] #PF: error_code(0x) - not-present page
[   43.655720] PGD 0 P4D 0
[   43.655720] Oops:  [#1] SMP PTI
[   43.655720] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.3.2-1940.el8uek.x86_64 #1
[   43.655720] Hardware name: Oracle Corporation ORACLE SERVER
X5-2/ASM,MOTHERBOARD,1U, BIOS 30140300 09/20/2018
[   43.655720] RIP: 0010:iommu_need_mapping+0x29/0xd0
[   43.655720] Code: 00 0f 1f 44 00 00 48 8b 97 70 02 00 00 48 83 fa ff
74 53 48 8d 4a ff b8 01 00 00 00 48 83 f9 fd 76 01 c3 48 8b 35 7f 58 e0
01 <48> 39 72 58 75 f2 55 48 89 e5 41 54 53 48 8b 87 28 02 00 00 4c 8b
[   43.655720] RSP: 0018:c901b9b0 EFLAGS: 00010246
[   43.655720] RAX: 0001 RBX: 1000 RCX:
fffd
[   43.655720] RDX: fffe RSI: 8880719b8000 RDI:
8880477460b0
[   43.655720] RBP: c901b9e8 R08:  R09:
888047c01700
[   43.655720] R10: 2194036fc692 R11:  R12:

[   43.655720] R13: 8880477460b0 R14: 0cc0 R15:
888072d2b558
[   43.655720] FS:  () GS:888071c0()
knlGS:
[   43.655720] CS:  0010 DS:  ES:  CR0: 80050033
[   43.655720] CR2: 0056 CR3: 7440a002 CR4:
001606b0
[   43.655720] Call Trace:
[   43.655720]  ? intel_alloc_coherent+0x2a/0x180
[   43.655720]  ? __schedule+0x2c2/0x650
[   43.655720]  dma_alloc_attrs+0x8c/0xd0
[   43.655720]  dma_pool_alloc+0xdf/0x200
[   43.655720]  ehci_qh_alloc+0x58/0x130
[   43.655720]  ehci_setup+0x287/0x7ba
[   43.655720]  ? _dev_info+0x6c/0x83
[   43.655720]  ehci_pci_setup+0x91/0x436
[   43.655720]  usb_add_hcd.cold.48+0x1d4/0x754
[   43.655720]  usb_hcd_pci_probe+0x2bc/0x3f0
[   43.655720]  ehci_pci_probe+0x39/0x40
[   43.655720]  local_pci_probe+0x47/0x80
[   43.655720]  pci_device_probe+0xff/0x1b0
[   43.655720]  really_probe+0xf5/0x3a0
[   43.655720]  driver_probe_device+0xbb/0x100
[   43.655720]  device_driver_attach+0x58/0x60
[   43.655720]  __driver_attach+0x8f/0x150
[   43.655720]  ? device_driver_attach+0x60/0x60
[   43.655720]  bus_for_each_dev+0x74/0xb0
[   43.655720]  driver_attach+0x1e/0x20
[   43.655720]  bus_add_driver+0x151/0x1f0
[   43.655720]  ? ehci_hcd_init+0xb2/0xb2
[   43.655720]  ? do_early_param+0x95/0x95
[   43.655720]  driver_register+0x70/0xc0
[   43.655720]  ? ehci_hcd_init+0xb2/0xb2
[   43.655720]  __pci_register_driver+0x57/0x60
[   43.655720]  ehci_pci_init+0x6a/0x6c
[   43.655720]  do_one_initcall+0x4a/0x1fa
[   43.655720]  ? do_early_param+0x95/0x95
[   43.655720]  kernel_init_freeable+0x1bd/0x262
[   43.655720]  ? rest_init+0xb0/0xb0
[   43.655720]  kernel_init+0xe/0x110
[   43.655720]  ret_from_fork+0x24/0x50



Good catch. Can you please add:

Fixes: 8af46c784ecfe ("iommu/vt-d: Implement is_attach_deferred iommu 
ops entry")

Cc: sta...@vger.kernel.org # v5.3+

With above:

Reviewed-by: Lu Baolu 

Best regards,
Baolu


Signed-off-by: John Donnelly 
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c4e0e4a9ee9e..f83a9a302f8e 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2783,7 +2783,7 @@ static int identity_mapping(struct device *dev)
struct device_domain_info *info;

info = dev->archdata.iommu;
-    if (info && info != DUMMY_DEVICE_DOMAIN_INFO)
+    if (info && info != DUMMY_DEVICE_DOMAIN_INFO && info != 
DEFER_DEVICE_DOMAIN_INFO)

    return (info->domain == si_domain);

return 0;

RE: [EXT] Re: [v3,2/2] i2c: mux: pca954x: support property idle-state

[Biwen Li]

> On 2019-10-16 06:09, Biwen Li wrote:
> > This supports property idle-state
> >
> > Signed-off-by: Biwen Li 
> > ---
> > Change in v3:
> >   - update subject and description
> >   - add a helper function pca954x_calculate_chan()
> >
> > Change in v2:
> >   - update subject and description
> >   - add property idle-state
> >
> >  drivers/i2c/muxes/i2c-mux-pca954x.c | 64
> > ++---
> >  1 file changed, 39 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
> > b/drivers/i2c/muxes/i2c-mux-pca954x.c
> > index 923aa3a5a3dc..8777d429269c 100644
> > --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> > +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> > @@ -86,7 +86,7 @@ struct pca954x {
> >
> >   u8 last_chan;   /* last register value */
> >   /* MUX_IDLE_AS_IS, MUX_IDLE_DISCONNECT or >= 0 for channel */
> > - s8 idle_state;
> > + s32 idle_state;
> >
> >   struct i2c_client *client;
> >
> > @@ -229,22 +229,25 @@ static int pca954x_reg_write(struct i2c_adapter
> *adap,
> >   I2C_SMBUS_BYTE, &dummy);  }
> >
> > +static int pca954x_calculate_chan(struct pca954x *data, u32 chan)
> 
> Should return u8, and "chan" is not what is calculated. Perhaps name the
> function pca954x_regval?
Okay, got it, I will change it in v4.
> 
> (Yes, last_chan is also clearly a bad name, and I suspect you may have
> based this name on it, but changing that is a separate patch.)
> 
> > +{
> > + /* we make switches look like muxes, not sure how to be smarter */
> > + if (data->chip->muxtype == pca954x_ismux)
> > + return chan | data->chip->enable;
> > + else
> > + return 1 << chan;
> > +}
> > +
> >  static int pca954x_select_chan(struct i2c_mux_core *muxc, u32 chan)
> > {
> >   struct pca954x *data = i2c_mux_priv(muxc);
> >   struct i2c_client *client = data->client;
> > - const struct chip_desc *chip = data->chip;
> >   u8 regval;
> >   int ret = 0;
> >
> > - /* we make switches look like muxes, not sure how to be smarter */
> > - if (chip->muxtype == pca954x_ismux)
> > - regval = chan | chip->enable;
> > - else
> > - regval = 1 << chan;
> > -
> > + regval = pca954x_calculate_chan(data, chan);
> 
> I think I would have kept the empty line here. Not important...
> 
> >   /* Only select the channel if its different from the last channel */
> > - if (data->last_chan != regval) {
> > + if ((data->last_chan & 0xff) != regval) {
> 
> The changes on this line are not needed (last_chan and regval are both u8)
> and just clutters up the code.
Okay, got it, I will not change it in v4.
> 
> >   ret = pca954x_reg_write(muxc->parent, client, regval);
> >   data->last_chan = ret < 0 ? 0 : regval;
> >   }
> > @@ -256,7 +259,7 @@ static int pca954x_deselect_mux(struct
> > i2c_mux_core *muxc, u32 chan)  {
> >   struct pca954x *data = i2c_mux_priv(muxc);
> >   struct i2c_client *client = data->client;
> > - s8 idle_state;
> > + s32 idle_state;
> >
> >   idle_state = READ_ONCE(data->idle_state);
> >   if (idle_state >= 0)
> > @@ -402,6 +405,23 @@ static void pca954x_cleanup(struct
> i2c_mux_core *muxc)
> >   i2c_mux_del_adapters(muxc);
> >  }
> >
> > +static int pca954x_init(struct i2c_client *client, struct pca954x
> > +*data) {
> > + /*
> > +  * Write the mux register at addr to verify
> > +  * that the mux is in fact present. This also
> > +  * initializes the mux to a channel
> > +  * or disconnected state.
> > +  */
> 
> Again, this comment belongs in pca954x_probe before the call to this
> function.
> It does not apply (at least not the first sentence) when pca954x_init is 
> called
> from pca954x_resume.
Okay, got it, thanks, I will move it in v4.
> 
> Hmmm, it could be argued that specifying MUX_IDLE_AS_IS should not
> trigger a disconnect on init (since the mux is always idle at init) and that
> some other method should be used to determine if the chip is present. The
> difference is that with the idle-state property you can explicitly request
> MUX_IDLE_AS_IS, while the old code only had some default behavior if
> i2c-mux-idle-disconnect was not present.
> 
> The easy way out of this is to, in the binding, document the situation and say
> that "idle-state = ;" is not supported but that similar
> functionality can be obtained by leaving out both the
> i2c-mux-idle-disconnect and idle-state properties.
I will support MUX_IDLE_AS_IS in v4.

> 
> > + if (data->idle_state >= 0) {
> > + data->last_chan = pca954x_calculate_chan(data,
> data->idle_state);
> > + } else {
> > + /* Disconnect multiplexer */
> > + data->last_chan = 0;
> > + }
> > + return i2c_smbus_write_byte(client, data->last_chan); }
> > +
> >  /*
> >   * I2C init/probing/exit functions
> >   */
> > @@ -411,7 +431,6 @@ static int pca954x

linux-next: Fixes tag needs some work in the rdma-fixes tree

[Stephen Rothwell]

Hi all,

In commit

  612e0486ad08 ("iw_cxgb4: fix ECN check on the passive accept")

Fixes tag

  Fixes: 92e7ae7172 ("iw_cxgb4: Choose appropriate hw mtu index and ISS for 
iWARP connections")

has these problem(s):

  - SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").

-- 
Cheers,
Stephen Rothwell


pgp3xN3HXn9eC.pgp
Description: OpenPGP digital signature

[PATCH] posix-cpu-timers: fix two trivial comments

[Yi Wang]

Commit b7be4ef1365d ("posix-cpu-timers: Switch thread group sampling to
array") and commit 001f7971433a ("posix-cpu-timers: Make expiry checks
array based") made some modification on parameters of function
thread_group_sample_cputime() and task_cputimers_expired(), but forgot
to modify the comment.

This patch can fix this.

Signed-off-by: Yi Wang 
---
 kernel/time/posix-cpu-timers.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 92a4319..617b919 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -266,7 +266,7 @@ static void update_gt_cputime(struct task_cputime_atomic 
*cputime_atomic,
 /**
  * thread_group_sample_cputime - Sample cputime for a given task
  * @tsk:   Task for which cputime needs to be started
- * @iimes: Storage for time samples
+ * @samples:   Storage for time samples
  *
  * Called from sys_getitimer() to calculate the expiry time of an active
  * timer. That means group cputime accounting is already active. Called
@@ -1031,7 +1031,7 @@ static void posix_cpu_timer_rearm(struct k_itimer *timer)
 /**
  * task_cputimers_expired - Check whether posix CPU timers are expired
  *
- * @samples:   Array of current samples for the CPUCLOCK clocks
+ * @sample:Array of current samples for the CPUCLOCK clocks
  * @pct:   Pointer to a posix_cputimers container
  *
  * Returns true if any member of @samples is greater than the corresponding
-- 
1.8.3.1

Re: [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function

[Boris Brezillon]

On Mon, 21 Oct 2019 15:23:57 +0800
masonccy...@mxic.com.tw wrote:

> Hi Miquel,
> 
> 
> > > > > Then fill-in these two hooks from the manufacturer code, without   
> the
> > > > > postponed init.
> > > > >   
> > > > 
> > > > But in the final of nand_scan_tail(), mtd->_lock/_unlock will be
> > > > filled by NULL, right ?  
> > > 
> > > The NAND core should set mtd->_lock/_unlock() to NAND specific hooks   
> so
> > > that the MTD layer is abstracted and and drivers do not see it. Then,
> > > in the NAND helper, either there is no specific hook defined by a
> > > manufacturer driver and you return -ENOTSUPP, or you execute the
> > > defined hook.  
> > 
> > okay, patch specific manufacturer _lock/_unlock driver
> > in nand_manufacturer_init();
> > 
> > and in the final of nand_scan_tail()
> > if (!mtd->_lock)
> >  mtd->_lock = NULL;
> > if (!mtd->_unlock)
> >  mtd->_unlock = NULL;  
>  
> 
> I'm still considering of post_init() in nand_scan_tail() for
> MTD layer default call-back function replacement because
> there would be more call-back functions need it.
> i.e., 
> MTD->_lock/_unlokc
> MTD->_suspend/_resume

Again, that's something that needs to be abstracted so that both the
NAND manufacturer driver and the NAND controller driver can take
appropriate actions on suspend/resume operations.

> NTD->_point/_unpoint

->_point/_unpoint() are irrelevant for a NAND chip.

> ...
> 
> 
> actually, my patch series are including MTD->_locl/_unlock and 
> MTD->_suspend/_resume. how do you think ?

Miquel was suggesting to add nand_chip->{lock,unlock,is_locked}()
methods that would be implemented by the NAND manufacturer drivers, and
have generic wrappers implemented in nand_base.c:

static int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
struct nand_chip *chip = mtd_to_nand(mtd);

if (!chip->lock)
return -ENOTSUPP;

return chip->lock(chip, ofs, len);
}

...

If you do that, you won't need this post_init() hook.

Re: [PATCH v4] arm64: psci: Reduce the waiting time for cpu_psci_cpu_kill()

[Yunfeng Ye]

On 2019/10/18 23:20, Sudeep Holla wrote:
> On Fri, Oct 18, 2019 at 08:46:37PM +0800, Yunfeng Ye wrote:
>> In case like suspend-to-disk and uspend-to-ram, a large number of CPU
> 
> s/case/cases/
> s/uspend-to-ram/suspend-to-ram/
> 
ok, thanks.

>> cores need to be shut down. At present, the CPU hotplug operation is
>> serialised, and the CPU cores can only be shut down one by one. In this
>> process, if PSCI affinity_info() does not return LEVEL_OFF quickly,
>> cpu_psci_cpu_kill() needs to wait for 10ms. If hundreds of CPU cores
>> need to be shut down, it will take a long time.
>>
>> Normally, there is no need to wait 10ms in cpu_psci_cpu_kill(). So
>> change the wait interval from 10 ms to max 1 ms and use usleep_range()
>> instead of msleep() for more accurate timer.
>>
>> In addition, reducing the time interval will increase the messages
>> output, so remove the "Retry ..." message, instead, put the number of
>> waiting times to the sucessful message.
>>
>> Signed-off-by: Yunfeng Ye 
>> ---
>> v3 -> v4:
>>  - using time_before(jiffies, timeout) to check
>>  - update the comment as review suggest
>>
>> v2 -> v3:
>>  - update the comment
>>  - remove the busy-wait logic, modify the loop logic and output message
>>
>> v1 -> v2:
>>  - use usleep_range() instead of udelay() after waiting for a while
>>  arch/arm64/kernel/psci.c | 14 --
>>  1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
>> index c9f72b2665f1..77965c3ba477 100644
>> --- a/arch/arm64/kernel/psci.c
>> +++ b/arch/arm64/kernel/psci.c
>> @@ -81,7 +81,8 @@ static void cpu_psci_cpu_die(unsigned int cpu)
>>
>>  static int cpu_psci_cpu_kill(unsigned int cpu)
>>  {
>> -int err, i;
>> +int err, i = 0;
>> +unsigned long timeout;
>>
>>  if (!psci_ops.affinity_info)
>>  return 0;
>> @@ -91,16 +92,17 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
>>   * while it is dying. So, try again a few times.
>>   */
>>
>> -for (i = 0; i < 10; i++) {
>> +timeout = jiffies + msecs_to_jiffies(100);
>> +do {
>> +i++;
>>  err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
>>  if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
>> -pr_info("CPU%d killed.\n", cpu);
>> +pr_info("CPU%d killed (polled %d times)\n", cpu, i);
> 
> We can even drop loop counter completely, track time and log that
> instead of loop counter that doesn't give any indication without looking
> into the code.
> 
ok, I will modify as your suggest. thanks.

>   start = jiffies, end = start + msecs_to_jiffies(100);
>   do {
>   
>   pr_info("CPU%d killed (polled %u ms)\n", cpu,
>   jiffies_to_msecs(jiffies - start));
>   
>   } while (time_before(jiffies, end));
> 
> Just my preference. Looks good otherwise.
> 
> --
> Regards,
> Sudeep
> 
> 
> .
> 

Re: [PATCH] media: rcar_drif: fix a memory disclosure

[Geert Uytterhoeven]

Hi Kangjie,

On Sat, Oct 19, 2019 at 12:29 AM Kangjie Lu  wrote:
> "f->fmt.sdr.reserved" is uninitialized. As other peer drivers
> like msi2500 and airspy do, the fix initializes it to avoid
> memory disclosures.
>
> Signed-off-by: Kangjie Lu 

Reviewed-by: Geert Uytterhoeven 

> --- a/drivers/media/platform/rcar_drif.c
> +++ b/drivers/media/platform/rcar_drif.c
> @@ -912,6 +912,7 @@ static int rcar_drif_g_fmt_sdr_cap(struct file *file, 
> void *priv,
>  {
> struct rcar_drif_sdr *sdr = video_drvdata(file);
>
> +   memset(f->fmt.sdr.reserved, 0, sizeof(f->fmt.sdr.reserved));
> f->fmt.sdr.pixelformat = sdr->fmt->pixelformat;
> f->fmt.sdr.buffersize = sdr->fmt->buffersize;

I would do the memset() at the end, though, to follow declaration order of the
struct members.

Gr{oetje,eeting}s,

Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] perf cs-etm: Fix definition of macro TO_CS_QUEUE_NR

[Leo Yan]

Macro TO_CS_QUEUE_NR definition has a typo, which uses 'trace_id_chan'
as its parameter, this doesn't match with its definition body which uses
'trace_chan_id'.  So renames the parameter to 'trace_chan_id'.

It's luck to have a local variable 'trace_chan_id' in the function
cs_etm__setup_queue(), even we wrongly define the macro TO_CS_QUEUE_NR,
the local variable 'trace_chan_id' is used rather than the macro's
parameter 'trace_id_chan'; so the compiler doesn't complain for this
before.

After renaming the parameter, it leads to a compiling error due
cs_etm__setup_queue() has no variable 'trace_id_chan'.  This patch uses
the variable 'trace_chan_id' for the macro so that fixes the compiling
error.

Signed-off-by: Leo Yan 
---
 tools/perf/util/cs-etm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 4ba0f871f086..f5f855fff412 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -110,7 +110,7 @@ static int cs_etm__decode_data_block(struct cs_etm_queue 
*etmq);
  * encode the etm queue number as the upper 16 bit and the channel as
  * the lower 16 bit.
  */
-#define TO_CS_QUEUE_NR(queue_nr, trace_id_chan)\
+#define TO_CS_QUEUE_NR(queue_nr, trace_chan_id)\
  (queue_nr << 16 | trace_chan_id)
 #define TO_QUEUE_NR(cs_queue_nr) (cs_queue_nr >> 16)
 #define TO_TRACE_CHAN_ID(cs_queue_nr) (cs_queue_nr & 0x)
@@ -819,7 +819,7 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
 * Note that packets decoded above are still in the traceID's packet
 * queue and will be processed in cs_etm__process_queues().
 */
-   cs_queue_nr = TO_CS_QUEUE_NR(queue_nr, trace_id_chan);
+   cs_queue_nr = TO_CS_QUEUE_NR(queue_nr, trace_chan_id);
ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, timestamp);
 out:
return ret;
-- 
2.17.1

Re: [PATCH v4 00/10] sched/fair: rework the CFS load balance

[Ingo Molnar]

* Vincent Guittot  wrote:

> Several wrong task placement have been raised with the current load
> balance algorithm but their fixes are not always straight forward and
> end up with using biased values to force migrations. A cleanup and rework
> of the load balance will help to handle such UCs and enable to fine grain
> the behavior of the scheduler for other cases.
> 
> Patch 1 has already been sent separately and only consolidate asym policy
> in one place and help the review of the changes in load_balance.
> 
> Patch 2 renames the sum of h_nr_running in stats.
> 
> Patch 3 removes meaningless imbalance computation to make review of
> patch 4 easier.
> 
> Patch 4 reworks load_balance algorithm and fixes some wrong task placement
> but try to stay conservative.
> 
> Patch 5 add the sum of nr_running to monitor non cfs tasks and take that
> into account when pulling tasks.
> 
> Patch 6 replaces runnable_load by load now that the signal is only used
> when overloaded.
> 
> Patch 7 improves the spread of tasks at the 1st scheduling level.
> 
> Patch 8 uses utilization instead of load in all steps of misfit task
> path.
> 
> Patch 9 replaces runnable_load_avg by load_avg in the wake up path.
> 
> Patch 10 optimizes find_idlest_group() that was using both runnable_load
> and load. This has not been squashed with previous patch to ease the
> review.
> 
> Patch 11 reworks find_idlest_group() to follow the same steps as
> find_busiest_group()
> 
> Some benchmarks results based on 8 iterations of each tests:
> - small arm64 dual quad cores system
> 
>tip/sched/corew/ this patchsetimprovement
> schedpipe  53125 +/-0.18%53443 +/-0.52%   (+0.60%)
> 
> hackbench -l (2560/#grp) -g #grp
>  1 groups  1.579 +/-29.16%   1.410 +/-13.46% (+10.70%)
>  4 groups  1.269 +/-9.69%1.205 +/-3.27%   (+5.00%)
>  8 groups  1.117 +/-1.51%1.123 +/-1.27%   (+4.57%)
> 16 groups  1.176 +/-1.76%1.164 +/-2.42%   (+1.07%)
> 
> Unixbench shell8
>   1 test 1963.48 +/-0.36%   1902.88 +/-0.73%(-3.09%)
> 224 tests2427.60 +/-0.20%   2469.80 +/-0.42%  (1.74%)
> 
> - large arm64 2 nodes / 224 cores system
> 
>tip/sched/corew/ this patchsetimprovement
> schedpipe 124084 +/-1.36%   124445 +/-0.67%   (+0.29%)
> 
> hackbench -l (256000/#grp) -g #grp
>   1 groups15.305 +/-1.50%   14.001 +/-1.99%   (+8.52%)
>   4 groups 5.959 +/-0.70%5.542 +/-3.76%   (+6.99%)
>  16 groups 3.120 +/-1.72%3.253 +/-0.61%   (-4.92%)
>  32 groups 2.911 +/-0.88%2.837 +/-1.16%   (+2.54%)
>  64 groups 2.805 +/-1.90%2.716 +/-1.18%   (+3.17%)
> 128 groups 3.166 +/-7.71%3.891 +/-6.77%   (+5.82%)
> 256 groups 3.655 +/-10.09%   3.185 +/-6.65%  (+12.87%)
> 
> dbench
>   1 groups   328.176 +/-0.29%  330.217 +/-0.32%   (+0.62%)
>   4 groups   930.739 +/-0.50%  957.173 +/-0.66%   (+2.84%)
>  16 groups  1928.292 +/-0.36% 1978.234 +/-0.88%   (+0.92%)
>  32 groups  2369.348 +/-1.72% 2454.020 +/-0.90%   (+3.57%)
>  64 groups  2583.880 +/-3.39% 2618.860 +/-0.84%   (+1.35%)
> 128 groups  2256.406 +/-10.67%2392.498 +/-2.13%   (+6.03%)
> 256 groups  1257.546 +/-3.81% 1674.684 +/-4.97%  (+33.17%)
> 
> Unixbench shell8
>   1 test 6944.16 +/-0.02 6605.82 +/-0.11  (-4.87%)
> 224 tests   13499.02 +/-0.1413637.94 +/-0.47% (+1.03%)
> lkp reported a -10% regression on shell8 (1 test) for v3 that 
> seems that is partially recovered on my platform with v4.
> 
> tip/sched/core sha1:
>   commit 563c4f85f9f0 ("Merge branch 'sched/rt' into sched/core, to pick up 
> -rt changes")
>   
> Changes since v3:
> - small typo and variable ordering fixes
> - add some acked/reviewed tag
> - set 1 instead of load for migrate_misfit
> - use nr_h_running instead of load for asym_packing
> - update the optimization of find_idlest_group() and put back somes
>  conditions when comparing load
> - rework find_idlest_group() to match find_busiest_group() behavior
> 
> Changes since v2:
> - fix typo and reorder code
> - some minor code fixes
> - optimize the find_idles_group()
> 
> Not covered in this patchset:
> - Better detection of overloaded and fully busy state, especially for cases
>   when nr_running > nr CPUs.
> 
> Vincent Guittot (11):
>   sched/fair: clean up asym packing
>   sched/fair: rename sum_nr_running to sum_h_nr_running
>   sched/fair: remove meaningless imbalance calculation
>   sched/fair: rework load_balance
>   sched/fair: use rq->nr_running when balancing load
>   sched/fair: use load instead of runnable load in load_balance
>   sched/fair: evenly spread tasks when not overloaded
>   sched/fair: use utilization to select misfit task
>   sched/fair: use load instead of runnable load in wakeup path
>   sched/fair: optimize find_idlest_group
>   sched/fair: rework find_idlest_group
> 
>  kernel/sched/fair.c | 1181 
> +---

Re: [PATCH v5 3/3] PM / AVS: SVS: Introduce SVS engine

[Pi-Hsun Shih]

Hi Roger,

On Fri, Sep 6, 2019 at 6:06 PM Roger Lu  wrote:
> ...
> +static int svs_resource_setup(struct mtk_svs *svs)
> ...
> +   for (i = 0, freq = (u32)-1; i < svsb->opp_count; i++, freq--) 
> {
> +   opp = dev_pm_opp_find_freq_floor(svsb->dev, &freq);
> +   if (IS_ERR(opp)) {
> +   pr_err("%s: error opp entry!!, err = %ld\n",
> +  svsb->name, PTR_ERR(opp));
> +   return PTR_ERR(opp);
> +   }
> +
> +   svsb->opp_freqs[i] = freq;
> +   svsb->opp_volts[i] = dev_pm_opp_get_voltage(opp);
> +   svsb->freqs_pct[i] = percent(svsb->opp_freqs[i],
> +svsb->freq_base) & 0xff;

Should have dev_pm_opp_put(opp); here.

> +   }
> +   }
> +
> +   return 0;
> +}
> ...
> +static int svs_status_proc_show(struct seq_file *m, void *v)
> ...
> +   for (i = 0, freq = (u32)-1; i < svsb->opp_count; i++, freq--) {
> +   opp = dev_pm_opp_find_freq_floor(svsb->dev, &freq);
> +   if (IS_ERR(opp)) {
> +   seq_printf(m, "%s: error opp entry!!, err = %ld\n",
> +  svsb->name, PTR_ERR(opp));
> +   return PTR_ERR(opp);
> +   }
> +
> +   seq_printf(m, "opp_freqs[%02u]: %lu, volts[%02u]: %lu, ",
> +  i, freq, i, dev_pm_opp_get_voltage(opp));
> +   seq_printf(m, "svsb_volts[%02u]: 0x%x, freqs_pct[%02u]: %u\n",
> +  i, svsb->volts[i], i, svsb->freqs_pct[i]);

Same here.

> +   }
> +
> +   return 0;
> +}
> ...

Re: [PATCH v1 3/3] perf tests: Disable bp_signal testing for arm64

[Leo Yan]

On Fri, Oct 18, 2019 at 02:59:19PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Oct 18, 2019 at 04:55:31PM +0800, Leo Yan escreveu:
> > As there have several discussions for enabling Perf breakpoint signal
> > testing on arm64 platform; arm64 needs to rely on single-step to execute
> > the breakpointed instruction and then reinstall the breakpoint exception
> > handler.  But if hook the breakpoint with a signal, the signal handler
> > will do the stepping rather than the breakpointed instruction, this
> > causes infinite loops as below:
> > 
> >  Kernel space  |Userspace
> > ---|
> >|  __test_function() -> hit
> >|   breakpoint
> >   breakpoint_handler() |
> > `-> user_enable_single_step()  |
> >   do_signal()  |
> >|  sig_handler() -> Step one
> >|instruction and
> >|trap to kernel
> >   single_step_handler()|
> > `-> reinstall_suspended_bps()  |
> >|  __test_function() -> hit
> >| breakpoint again and
> >| repeat up flow infinitely
> > 
> > As Will Deacon mentioned [1]: "that we require the overflow handler to
> > do the stepping on arm/arm64, which is relied upon by GDB/ptrace. The
> > hw_breakpoint code is a complete disaster so my preference would be to
> > rip out the perf part and just implement something directly in ptrace,
> > but it's a pretty horrible job".  Though Will commented this on arm
> > architecture, but the comment also can apply on arm64 architecture.
> > 
> > For complete information, I searched online and found a few years back,
> > Wang Nan sent one patch 'arm64: Store breakpoint single step state into
> > pstate' [2]; the patch tried to resolve this issue by avoiding single
> > stepping in signal handler and defer to enable the signal stepping when
> > return to __test_function().  The fixing was not merged due to the
> > concern for missing to handle different usage cases.
> > 
> > Based on the info, the most feasible way is to skip Perf breakpoint
> > signal testing for arm64 and this could avoid the duplicate
> > investigation efforts when people see the failure.  This patch skips
> > this case on arm64 platform, which is same with arm architecture.
> 
> Ok, applying,

Thanks a lot, Arnaldo.

@Will, @Mark Rultland, very appreciate if you have time to review this
patch and welcome any comments or suggestions!  It's good you could
confirm this patch so have more confidence for it.

Thanks,
Leo Yan

> - Arnaldo
>  
> > [1] https://lkml.org/lkml/2018/11/15/205
> > [2] https://lkml.org/lkml/2015/12/23/477
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  tools/perf/tests/bp_signal.c | 15 ++-
> >  1 file changed, 6 insertions(+), 9 deletions(-)
> > 
> > diff --git a/tools/perf/tests/bp_signal.c b/tools/perf/tests/bp_signal.c
> > index c1c2c13de254..166f411568a5 100644
> > --- a/tools/perf/tests/bp_signal.c
> > +++ b/tools/perf/tests/bp_signal.c
> > @@ -49,14 +49,6 @@ asm (
> > "__test_function:\n"
> > "incq (%rdi)\n"
> > "ret\n");
> > -#elif defined (__aarch64__)
> > -extern void __test_function(volatile long *ptr);
> > -asm (
> > -   ".globl __test_function\n"
> > -   "__test_function:\n"
> > -   "str x30, [x0]\n"
> > -   "ret\n");
> > -
> >  #else
> >  static void __test_function(volatile long *ptr)
> >  {
> > @@ -302,10 +294,15 @@ bool test__bp_signal_is_supported(void)
> >  * stepping into the SIGIO handler and getting stuck on the
> >  * breakpointed instruction.
> >  *
> > +* Since arm64 has the same issue with arm for the single-step
> > +* handling, this case also gets suck on the breakpointed
> > +* instruction.
> > +*
> >  * Just disable the test for these architectures until these
> >  * issues are resolved.
> >  */
> > -#if defined(__powerpc__) || defined(__s390x__) || defined(__arm__)
> > +#if defined(__powerpc__) || defined(__s390x__) || defined(__arm__) || \
> > +defined(__aarch64__)
> > return false;
> >  #else
> > return true;
> > -- 
> > 2.17.1
> 
> -- 
> 
> - Arnaldo

Re: [PATCH v3] HID: core: check whether usage page item is after usage id item

[Candle Sun]

Hi,


On Mon, Oct 21, 2019 at 3:38 PM Candle Sun  wrote:
>
> From: Candle Sun 
>
> Upstream commit 58e75155009c ("HID: core: move Usage Page concatenation
> to Main item") adds support for Usage Page item after Usage ID items
> (such as keyboards manufactured by Primax).
>
> Usage Page concatenation in Main item works well for following report
> descriptor patterns:
>
> USAGE_PAGE (Keyboard)   05 07
> USAGE_MINIMUM (Keyboard LeftControl)19 E0
> USAGE_MAXIMUM (Keyboard Right GUI)  29 E7
> LOGICAL_MINIMUM (0) 15 00
> LOGICAL_MAXIMUM (1) 25 01
> REPORT_SIZE (1) 75 01
> REPORT_COUNT (8)95 08
> INPUT (Data,Var,Abs)81 02
>
> -
>
> USAGE_MINIMUM (Keyboard LeftControl)19 E0
> USAGE_MAXIMUM (Keyboard Right GUI)  29 E7
> LOGICAL_MINIMUM (0) 15 00
> LOGICAL_MAXIMUM (1) 25 01
> REPORT_SIZE (1) 75 01
> REPORT_COUNT (8)95 08
> USAGE_PAGE (Keyboard)   05 07
> INPUT (Data,Var,Abs)81 02
>
> But it makes the parser act wrong for the following report
> descriptor pattern(such as some Gamepads):
>
> USAGE_PAGE (Button) 05 09
> USAGE (Button 1)09 01
> USAGE (Button 2)09 02
> USAGE (Button 4)09 04
> USAGE (Button 5)09 05
> USAGE (Button 7)09 07
> USAGE (Button 8)09 08
> USAGE (Button 14)   09 0E
> USAGE (Button 15)   09 0F
> USAGE (Button 13)   09 0D
> USAGE_PAGE (Consumer Devices)   05 0C
> USAGE (Back)0a 24 02
> USAGE (HomePage)0a 23 02
> LOGICAL_MINIMUM (0) 15 00
> LOGICAL_MAXIMUM (1) 25 01
> REPORT_SIZE (1) 75 01
> REPORT_COUNT (11)   95 0B
> INPUT (Data,Var,Abs)81 02
>
> With Usage Page concatenation in Main item, parser recognizes all the
> 11 Usages as consumer keys, it is not the HID device's real intention.
>
> This patch adds usage_page_last to flag whether Usage Page is after
> Usage ID items. usage_page_last is false default, it is set as true
> once Usage Page item is encountered and is reverted by next Usage ID
> item.
>
> Usage Page concatenation on the currently defined Usage Page will do
> firstly in Local parsing when Usage ID items encountered.
>
> When Main item is parsing, concatenation will do again with last
> defined Usage Page if usage_page_last flag is true.
>
> Signed-off-by: Candle Sun 
> Signed-off-by: Nianfu Bai 
> ---
> Changes in v3:
> - Rework the GET_COMPLETE_USAGE macro as static complete_usage()
>   function
> - Add some code comments for usage_page_last
>
> Changes in v2:
> - Update patch title
> - Add GET_COMPLETE_USAGE macro
> - Change the logic of checking whether to concatenate usage page again
>   in main parsing
> ---
>  drivers/hid/hid-core.c | 42 +-
>  include/linux/hid.h|  1 +
>  2 files changed, 38 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 3eaee2c37931..779b7798dae8 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -211,6 +211,18 @@ static unsigned hid_lookup_collection(struct hid_parser 
> *parser, unsigned type)
> return 0; /* we know nothing about this usage type */
>  }
>
> +/*
> + * Concatenate usage which defines 16 bits or less with the
> + * currently defined usage page to form a 32 bit usage
> + */
> +
> +static void complete_usage(struct hid_parser *parser, unsigned int index)
> +{
> +   parser->local.usage[index] &= 0x;
> +   parser->local.usage[index] |=
> +   (parser->global.usage_page & 0x) << 16;
> +}
> +
>  /*
>   * Add a usage to the temporary parser table.
>   */
> @@ -221,7 +233,18 @@ static int hid_add_usage(struct hid_parser *parser, 
> unsigned usage, u8 size)
> hid_err(parser->device, "usage index exceeded\n");
> return -1;
> }
> -   parser->local.usage[parser->local.usage_index] = usage;
> +
> +   /*
> +* If Usage item only includes usage id, concatenate it with
> +* currently defined usage page and clear usage_page_last flag
> +*/
> +   if (size <= 2) {
> +   parser->local.usage_page_last = false;
> +   complete_usage(parser, parser->local.usage_index);
> +   } else {
> +   parser->local.usage[parser->local.usage_index] = usage;
> +   }
> +
> parser->local.usage_size[parser->local.usag

Re: [PATCH] soc: amlogic: meson-gx-socinfo: Fix S905D3 ID for VIM3L

[Neil Armstrong]

Hi,

On 21/10/2019 07:04, Christian Hewitt wrote:
> Chip on the board is S905D3 not S905X3.
> 
> Fixes: 1d7c541b8a5b ("soc: amlogic: meson-gx-socinfo: Add S905X3 ID for 
> VIM3L")
> 
> Signed-off-by: Christian Hewitt 
> ---
>  drivers/soc/amlogic/meson-gx-socinfo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c 
> b/drivers/soc/amlogic/meson-gx-socinfo.c
> index 87ed558..e612dae 100644
> --- a/drivers/soc/amlogic/meson-gx-socinfo.c
> +++ b/drivers/soc/amlogic/meson-gx-socinfo.c
> @@ -69,7 +69,7 @@ static const struct meson_gx_package_id {
>   { "S922X", 0x29, 0x40, 0xf0 },
>   { "A311D", 0x29, 0x10, 0xf0 },
>   { "S905X3", 0x2b, 0x5, 0xf },
> - { "S905X3", 0x2b, 0xb0, 0xf2 },
> + { "S905D3", 0x2b, 0xb0, 0xf2 },

Why is the mask 0xf2 ? What is reported in dmesg ?

>   { "A113L", 0x2c, 0x0, 0xf8 },
>  };
>  
> 

Neil

Re: [PATCH] mmc: fix mmc dma operation

[Neil Armstrong]

Hi,

Thanks for the fix.

First, you should add "mmc: meson-gx:" in the subject.

On 21/10/2019 07:59, Jianxin Pan wrote:
> From: Nan Li 
> 
> In MMC dma transfer, the region requested by dma_map_sg() may be released
> by dma_unmap_sg() before the transfer is completed.
> 
> Put the unmap operation in front of mmc_request_done() to avoid this.


You should add a "Fixes:" tag so it can be backported on stable kernels.

> 
> Signed-off-by: Nan Li 
> Signed-off-by: Jianxin Pan 
> ---
>  drivers/mmc/host/meson-gx-mmc.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index e712315..7667e8a 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -173,6 +173,7 @@ struct meson_host {
>   int irq;
>  
>   bool vqmmc_enabled;
> + bool needs_pre_post_req;
>  };
>  
>  #define CMD_CFG_LENGTH_MASK GENMASK(8, 0)
> @@ -654,6 +655,8 @@ static void meson_mmc_request_done(struct mmc_host *mmc,
>   struct meson_host *host = mmc_priv(mmc);
>  
>   host->cmd = NULL;
> + if (host->needs_pre_post_req)
> + meson_mmc_post_req(mmc, mrq, 0);
>   mmc_request_done(host->mmc, mrq);
>  }
>  
> @@ -803,25 +806,23 @@ static void meson_mmc_start_cmd(struct mmc_host *mmc, 
> struct mmc_command *cmd)
>  static void meson_mmc_request(struct mmc_host *mmc, struct mmc_request *mrq)
>  {
>   struct meson_host *host = mmc_priv(mmc);
> - bool needs_pre_post_req = mrq->data &&
> +
> + host->needs_pre_post_req = mrq->data &&
>   !(mrq->data->host_cookie & SD_EMMC_PRE_REQ_DONE);
>  
> - if (needs_pre_post_req) {
> + if (host->needs_pre_post_req) {
>   meson_mmc_get_transfer_mode(mmc, mrq);
>   if (!meson_mmc_desc_chain_mode(mrq->data))
> - needs_pre_post_req = false;
> + host->needs_pre_post_req = false;
>   }
>  
> - if (needs_pre_post_req)
> + if (host->needs_pre_post_req)
>   meson_mmc_pre_req(mmc, mrq);
>  
>   /* Stop execution */
>   writel(0, host->regs + SD_EMMC_START);
>  
>   meson_mmc_start_cmd(mmc, mrq->sbc ?: mrq->cmd);
> -
> - if (needs_pre_post_req)
> - meson_mmc_post_req(mmc, mrq, 0);
>  }
>  
>  static void meson_mmc_read_resp(struct mmc_host *mmc, struct mmc_command 
> *cmd)
>
Neil

Re: [PATCH v3 4/4] perf/core,x86: synchronize PMU task contexts on optimized context switches

[Ingo Molnar]

* Alexey Budankov  wrote:

> + /*
> +  * PMU specific parts of task perf context may require
> +  * additional synchronization, at least for proper Intel
> +  * LBR callstack data profiling;
> +  */
> + pmu->sync_task_ctx(ctx->task_ctx_data,
> +next_ctx->task_ctx_data);

Firstly, I'm pretty sure you never run this on a CPU where 
pmu->sync_task_ctx is NULL, right? ;-)

Secondly, even on Intel CPUs in many cases we'll just call into a ~2 deep 
function pointer based call hierarchy, just to find that nothing needs to 
be done, because there's no LBR call stack maintained:

+   if (!one || !another)
+   return;

So while it's technically a layering violation, it might make sense to 
elevate this check to the generic layer and say that synchronization 
calls by the core layer will always provide two valid pointers?

Thanks,

Ingo

Re: [RFC PATCH 11/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC

[Vaittinen, Matti]

Hello Dan,

Thanks for taking the time to check my driver :) I truly appreciate all
the help!

A "fundamental question" regarding these review comments is whether I
should add DT entries for these LEDs or not. I thought I shouldn't but
I would like to get a comment from Rob regarding it.

On Thu, 2019-10-17 at 09:04 -0500, Dan Murphy wrote:
> Matt
> 
> On 10/17/19 4:53 AM, Matti Vaittinen wrote:
> > ROHM BD71828 power management IC has two LED outputs for charge
> > status
> > and button pressing indications. The LED outputs can also be forced
> > bs SW so add driver allowing to use these LEDs for other
> > indications
> s/bs/by
> > as well.
> > 
> > Leds are controlled by SW using 'Force ON' bits. Please note the
> > constrains mentioned in data-sheet:
> > 1. If one LED is forced ON - then also the other LED is forced.
> > => You can't use SW control to force ON one LED and allow HW
> >to control the other.
> > 2. You can't force both LEDs OFF. If the FORCE bit for both LED's
> > is
> > zero, then LEDs are controlled by HW and indicate
> > button/charger
> > states as explained in data-sheet.
> > 
> > Signed-off-by: Matti Vaittinen 
> > ---
> >   drivers/leds/Kconfig| 10 
> >   drivers/leds/Makefile   |  1 +
> >   drivers/leds/leds-bd71828.c | 97
> > +
> >   3 files changed, 108 insertions(+)
> >   create mode 100644 drivers/leds/leds-bd71828.c
> > 
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > index b0fdeef10bd9..ec59f28bcb39 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -529,6 +529,16 @@ config LEDS_BD2802
> >   This option enables support for BD2802GU RGB LED driver chips
> >   accessed via the I2C bus.
> >   
> > +config LEDS_BD71828
> > +   tristate "LED driver for LED pins on ROHM BD71828 PMIC"
> > +   depends on LEDS_CLASS
> doesn't this have a dependency on MFD_ROHM_BD71828
> > +   depends on I2C
> > +   help
> > + This option enables support for LED outputs located on ROHM
> > +  BD71828 power management IC. ROHM BD71828 has two led output
> > pins
> > +  which can be left to indicate HW states or controlled by SW.
> > Say
> > +  yes here if you want to enable SW control for these LEDs.
> > +
> 
> Add module statement

What is the module statement? Do you mean the 'if you compile this as a
module it will be called blahblah' or 'choose M to blahblah'?

I've never understood why some entries have those statements. 'Choose
M' stuff is help for config system - why should each module explain how
to use configs? This information should be in more generic
documentation. Furthermore, the 'tristate' there already says you can
compile this as a module. Module name on the other hand really is
module's property but it may well change if one changes the name of the
file. That should not require change in KConfig. Furthermore, where do
you need the module name? And if you really need the module name you
should check the config name from Makefile to be sure - module/file
names in comments or docs tend to get outdated.

After all this being said - I can add any boilerplate text in KConfig
if necessary - I just see zero benefit from this. And if you didn't
mean this - can you then please tell me what is the module statement?

> >   config LEDS_INTEL_SS4200
> > tristate "LED driver for Intel NAS SS4200 series"
> > depends on LEDS_CLASS
> > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> > index 41fb073a39c1..2a8f6a8e4c7c 100644
> > --- a/drivers/leds/Makefile
> > +++ b/drivers/leds/Makefile
> > @@ -15,6 +15,7 @@ obj-$(CONFIG_LEDS_AN30259A)   +=
> > leds-an30259a.o
> >   obj-$(CONFIG_LEDS_BCM6328)+= leds-bcm6328.o
> >   obj-$(CONFIG_LEDS_BCM6358)+= leds-bcm6358.o
> >   obj-$(CONFIG_LEDS_BD2802) += leds-bd2802.o
> > +obj-$(CONFIG_LEDS_BD71828) += leds-bd71828.o
> >   obj-$(CONFIG_LEDS_CPCAP)  += leds-cpcap.o
> >   obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
> >   obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
> > diff --git a/drivers/leds/leds-bd71828.c b/drivers/leds/leds-
> > bd71828.c
> > new file mode 100644
> > index ..2427619444f5
> > --- /dev/null
> > +++ b/drivers/leds/leds-bd71828.c
> > @@ -0,0 +1,97 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2019 ROHM Semiconductors
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define BD71828_LED_TO_DATA(l) ((l)->id == ID_GREEN_LED ? \
> > +   container_of((l), struct bd71828_leds, green) : \
> > +   container_of((l), struct bd71828_leds, amber))
> 
> I don't think we should be defining the color as the variable. The 
> outputs can drive any color LED.

I used the colors mentioned in BD71828 data-sheet. It is true someone
might use different LEDs on their board but at least this naming allows

Re: [PATCH v2 3/4] watchdog: add meson secure watchdog driver

[Xingyu Chen]

Hi, Guenter

On 2019/10/21 0:56, Guenter Roeck wrote:

On 10/18/19 1:33 AM, Xingyu Chen wrote:

The watchdog controller on the Meson-A/C series SoCs is moved to secure
world, watchdog operation needs to be done in secure EL3 mode via ATF,
Non-secure world can call SMC instruction to trap to AFT for watchdog
operation.

Signed-off-by: Xingyu Chen 
---
  drivers/watchdog/Kconfig |  17 
  drivers/watchdog/Makefile    |   1 +
  drivers/watchdog/meson_sec_wdt.c | 187 
+++

  3 files changed, 205 insertions(+)
  create mode 100644 drivers/watchdog/meson_sec_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 58e7c10..e84be42 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -826,6 +826,23 @@ config MESON_GXBB_WATCHDOG
    To compile this driver as a module, choose M here: the
    module will be called meson_gxbb_wdt.
+config MESON_SEC_WATCHDOG
+    tristate "Amlogic Meson Secure watchdog support"
+    depends on MESON_SM
+    depends on ARCH_MESON || COMPILE_TEST


This dependency is pointless. MESON_SM already depends on ARCH_MESON,
thus specifying "COMPILE_TEST" here adds no value but only
creates confusion.

Thanks for your analysis, perhaps i should remove the line below.
- depends on ARCH_MESON || COMPILE_TEST

Is it ok to modify code above like this ?



+    select WATCHDOG_CORE
+    help
+  The watchdog controller on the Meson-A/C series SoCs is moved to
+  secure world, watchdog operation needs to be done in secure EL3
+  mode via ATF, non-secure world can call SMC instruction to trap
+  to ATF for the watchdog operation.
+
+  Say Y here if watchdog controller on Meson SoCs is located in
+  secure world.
+
+  To compile this driver as a module, choose M here: the
+  module will be called meson_sec_wdt.
+
  config MESON_WATCHDOG
  tristate "Amlogic Meson SoCs watchdog support"
  depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 2ee352b..5e6b73d 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -78,6 +78,7 @@ obj-$(CONFIG_QCOM_WDT) += qcom-wdt.o
  obj-$(CONFIG_BCM_KONA_WDT) += bcm_kona_wdt.o
  obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
  obj-$(CONFIG_MESON_GXBB_WATCHDOG) += meson_gxbb_wdt.o
+obj-$(CONFIG_MESON_SEC_WATCHDOG) += meson_sec_wdt.o
  obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
  obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
  obj-$(CONFIG_DIGICOLOR_WATCHDOG) += digicolor_wdt.o
diff --git a/drivers/watchdog/meson_sec_wdt.c 
b/drivers/watchdog/meson_sec_wdt.c

new file mode 100644
index ..86bd87c
--- /dev/null
+++ b/drivers/watchdog/meson_sec_wdt.c
@@ -0,0 +1,187 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
+ * Author: Xingyu Chen 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MESON_SIP_WDT_DISABLE    0x1
+#define MESON_SIP_WDT_ENABLE    0x2
+#define MESON_SIP_WDT_PING    0x3
+#define MESON_SIP_WDT_INIT    0x4
+#define MESON_SIP_WDT_RESETNOW    0x5
+#define MESON_SIP_WDT_SETTIMEOUT    0x6
+#define MESON_SIP_WDT_GETTIMELEFT    0x7
+
+#define DEFAULT_TIMEOUT    30 /* seconds */
+
+/*
+ * Watchdog timer tick is set to 1ms in secfw side, and tick count is
+ * stored in the bit[16-31] of WATCHDOG_CNT register, so the maximum
+ * timeout value is 0x ms.
+ */
+#define MAX_TIMEOUT_MS    0x
+
+struct meson_sec_wdt {
+    struct watchdog_device wdt_dev;
+    struct meson_sm_firmware *fw;
+};
+
+static int meson_sec_wdt_start(struct watchdog_device *wdt_dev)
+{
+    struct meson_sec_wdt *data = watchdog_get_drvdata(wdt_dev);
+
+    return meson_sm_call(data->fw, SM_WATCHDOG_OPS, NULL,
+ MESON_SIP_WDT_ENABLE, 0, 0, 0, 0);
+}
+
+static int meson_sec_wdt_stop(struct watchdog_device *wdt_dev)
+{
+    struct meson_sec_wdt *data = watchdog_get_drvdata(wdt_dev);
+
+    return meson_sm_call(data->fw, SM_WATCHDOG_OPS, NULL,
+ MESON_SIP_WDT_DISABLE, 0, 0, 0, 0);
+}
+
+static int meson_sec_wdt_ping(struct watchdog_device *wdt_dev)
+{
+    struct meson_sec_wdt *data = watchdog_get_drvdata(wdt_dev);
+
+    return meson_sm_call(data->fw, SM_WATCHDOG_OPS, NULL,
+ MESON_SIP_WDT_PING, 0, 0, 0, 0);
+}
+
+static int meson_sec_wdt_set_timeout(struct watchdog_device *wdt_dev,
+ unsigned int timeout)
+{
+    struct meson_sec_wdt *data = watchdog_get_drvdata(wdt_dev);
+
+    wdt_dev->timeout = timeout;
+
+    return meson_sm_call(data->fw, SM_WATCHDOG_OPS, NULL,
+ MESON_SIP_WDT_SETTIMEOUT,
+ wdt_dev->timeout, 0, 0, 0);
+}
+
+static unsigned int meson_sec_wdt_get_timeleft(struct watchdog_device 
*wdt_dev)

+{
+    int ret;
+    unsigned int timeleft;
+    struct meson_sec_wdt *data = watchdog_get_drvdata(wdt_dev);
+
+    ret = meson_sm_

Re: [PATCH 00/22] Stop using input_polled_dev in polling drivers

[Marco Felsch]

On 19-10-18 11:44, Andy Shevchenko wrote:
> On Thu, Oct 17, 2019 at 01:41:54PM -0700, Dmitry Torokhov wrote:
> > Input devices now support polling mode natively (via input_setup_polling
> > API), and input_polled_dev implementation is going away. This series
> > switches drivers found in drivers/input to the new scheme.
> > 
> 
> For all I have been Cc'ed
> Acked-by: Andy Shevchenko 

Same for me
Acked-by: Marco Felsch  

> > 
> > Dmitry Torokhov (21):
> >   Input: raspberrypi-ts - switch to using polled mode of input devices
> >   Input: sur40 - switch to using polled mode of input devices
> >   Input: ts4800-ts - switch to using polled mode of input devices
> >   Input: tsc6507x-ts - switch to using polled mode of input devices
> >   Input: adc-keys - switch to using polled mode of input devices
> >   Input: clps711x-keypad - switch to using polled mode of input devices
> >   Input: jornada680_kbd - switch to using polled mode of input devices
> >   Input: gpio_keys_polled - switch to using polled mode of input devices
> >   Input: apanel - switch to using polled mode of input devices
> >   Input: wistron_btns - switch to using polled mode of input devices
> >   Input: cobalt_btns - convert to use managed resources
> >   Input: cobalt_btns - switch to using polled mode of input devices
> >   Input: sgi_btns - switch to using managed resources
> >   Input: sgi_btns - switch to using polled mode of input devices
> >   Input: rb532_button - switch to using managed resources
> >   Input: rb532_button - switch to using polled mode of input devices
> >   Input: gpio_decoder - switch to using polled mode of input devices
> >   Input: mma8450 - switch to using polled mode of input devices
> >   Input: bma150 - switch to using polled mode of input devices
> >   Input: kxtj9 - switch to using managed resources
> >   Input: kxtj9 - switch to using polled mode of input devices
> > 
> > Jonathan Bakker (1):
> >   Input: bma150 - use managed resources helpers
> > 
> >  drivers/input/keyboard/Kconfig |   4 -
> >  drivers/input/keyboard/adc-keys.c  |  36 ++--
> >  drivers/input/keyboard/clps711x-keypad.c   |  70 +++
> >  drivers/input/keyboard/gpio_keys_polled.c  |  65 +++---
> >  drivers/input/keyboard/jornada680_kbd.c|  37 ++--
> >  drivers/input/misc/Kconfig |  15 --
> >  drivers/input/misc/apanel.c| 153 ++
> >  drivers/input/misc/bma150.c| 190 +
> >  drivers/input/misc/cobalt_btns.c   |  73 +++
> >  drivers/input/misc/gpio_decoder.c  |  42 ++--
> >  drivers/input/misc/kxtj9.c | 224 ++---
> >  drivers/input/misc/mma8450.c   | 101 +-
> >  drivers/input/misc/rb532_button.c  |  48 ++---
> >  drivers/input/misc/sgi_btns.c  |  54 ++---
> >  drivers/input/misc/wistron_btns.c  |  51 ++---
> >  drivers/input/touchscreen/Kconfig  |   4 -
> >  drivers/input/touchscreen/raspberrypi-ts.c |  38 ++--
> >  drivers/input/touchscreen/sur40.c  |  92 +
> >  drivers/input/touchscreen/tps6507x-ts.c|  36 ++--
> >  drivers/input/touchscreen/ts4800-ts.c  |  68 ---
> >  20 files changed, 557 insertions(+), 844 deletions(-)
> > 
> > -- 
> > 2.23.0.866.gb869b98d4c-goog
> > 
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH] misc: rtsx: Add support for RTS5261

[rui_feng]

From: Rui Feng 

Add support for new chip rts5261.
In order to support rts5261, the definitions of some internal registers
and workflow have to be modified and are different from its predecessors.
So we need this patch to ensure RTS5261 can work.

Signed-off-by: Rui Feng 
---
 drivers/misc/cardreader/Makefile   |   2 +-
 drivers/misc/cardreader/rts5261.c  | 792 +
 drivers/misc/cardreader/rts5261.h  | 233 +++
 drivers/misc/cardreader/rtsx_pcr.c |  43 +-
 drivers/misc/cardreader/rtsx_pcr.h |   1 +
 include/linux/rtsx_pci.h   |   1 +
 6 files changed, 1064 insertions(+), 8 deletions(-)
 create mode 100644 drivers/misc/cardreader/rts5261.c
 create mode 100644 drivers/misc/cardreader/rts5261.h

diff --git a/drivers/misc/cardreader/Makefile b/drivers/misc/cardreader/Makefile
index d9bff5a..1f56267 100644
--- a/drivers/misc/cardreader/Makefile
+++ b/drivers/misc/cardreader/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_MISC_ALCOR_PCI)   += alcor_pci.o
 obj-$(CONFIG_MISC_RTSX_PCI)+= rtsx_pci.o
-rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o rts5227.o rts5249.o 
rts5260.o
+rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o rts5227.o rts5249.o 
rts5260.o rts5261.o
 obj-$(CONFIG_MISC_RTSX_USB)+= rtsx_usb.o
diff --git a/drivers/misc/cardreader/rts5261.c 
b/drivers/misc/cardreader/rts5261.c
new file mode 100644
index ..32dcec2
--- /dev/null
+++ b/drivers/misc/cardreader/rts5261.c
@@ -0,0 +1,792 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Driver for Realtek PCI-Express card reader
+ *
+ * Copyright(c) 2018-2019 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * Author:
+ *   Rui FENG 
+ *   Wei WANG 
+ */
+
+#include 
+#include 
+#include 
+
+#include "rts5261.h"
+#include "rtsx_pcr.h"
+
+static u8 rts5261_get_ic_version(struct rtsx_pcr *pcr)
+{
+   u8 val;
+
+   rtsx_pci_read_register(pcr, DUMMY_REG_RESET_0, &val);
+   return val & IC_VERSION_MASK;
+}
+
+static void rts5261_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
+{
+   u8 driving_3v3[4][3] = {
+   {0x13, 0x13, 0x13},
+   {0x96, 0x96, 0x96},
+   {0x7F, 0x7F, 0x7F},
+   {0x96, 0x96, 0x96},
+   };
+   u8 driving_1v8[4][3] = {
+   {0x99, 0x99, 0x99},
+   {0x3A, 0x3A, 0x3A},
+   {0xE6, 0xE6, 0xE6},
+   {0xB3, 0xB3, 0xB3},
+   };
+   u8 (*driving)[3], drive_sel;
+
+   if (voltage == OUTPUT_3V3) {
+   driving = driving_3v3;
+   drive_sel = pcr->sd30_drive_sel_3v3;
+   } else {
+   driving = driving_1v8;
+   drive_sel = pcr->sd30_drive_sel_1v8;
+   }
+
+   rtsx_pci_write_register(pcr, SD30_CLK_DRIVE_SEL,
+0xFF, driving[drive_sel][0]);
+
+   rtsx_pci_write_register(pcr, SD30_CMD_DRIVE_SEL,
+0xFF, driving[drive_sel][1]);
+
+   rtsx_pci_write_register(pcr, SD30_DAT_DRIVE_SEL,
+0xFF, driving[drive_sel][2]);
+}
+
+static void rtsx5261_fetch_vendor_settings(struct rtsx_pcr *pcr)
+{
+   u32 reg;
+   /* 0x814~0x817 */
+   rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG2, ®);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG2, reg);
+
+   if (!rts5261_vendor_setting_valid(reg)) {
+   pcr_dbg(pcr, "skip fetch vendor setting\n");
+   return;
+   }
+
+   pcr->card_drive_sel &= 0x3F;
+   pcr->card_drive_sel |= rts5261_reg_to_card_drive_sel(reg);
+
+   if (rts5261_reg_check_reverse_socket(reg))
+   pcr->flags |= PCR_REVERSE_SOCKET;
+
+   /* 0x724~0x727 */
+   rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, ®);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
+
+   pcr->aspm_en = rts5261_reg_to_aspm(reg);
+   pcr->sd30_drive_sel_1v8 = rts5261_reg_to_sd30_drive_sel_1v8(reg);
+   pcr->sd30_drive_sel_3v3 = rts5261_reg_to_sd30_drive_sel_3v3(reg);
+}
+
+static void rts5261_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
+{
+   /* Set relink_time to 0 */
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, MASK_8_BIT_DEF, 0);
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 2, MASK_8_BIT_DEF, 0);
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3,
+   RELINK_TIME_MASK, 0);
+
+   if (pm_state == HOST_ENTER_S3)
+   rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3,
+   D3_DELINK_MODE_EN, D3_DELINK_MODE_EN);
+
+   rtsx_pci_write_register(pcr, RTS5261_REG_FPDCTL,
+   SSC_POWER_DOWN, SSC_POWER_DOWN);
+}
+
+static int rts5261_enable_auto_blink(struct rtsx_pcr *pcr)
+{
+   return rtsx_pci_write_register(pcr, OLT_LED_CTL,
+   LED_SHINE_MASK, LED_SHINE_EN);
+}
+
+static int rts5261_disable_auto_blink(struct rtsx_pcr *pcr)
+{
+   return rtsx_pci_wri

Re: [PATCH v4 4/6] cpufreq: Initialize cpufreq-dt driver earlier

[Ingo Molnar]

* Amit Kucheria  wrote:

> This allows HW drivers that depend on cpufreq-dt to initialise earlier.

My obsessive-compulsive in-brain spellchecker noticed that the title says 
'initialize' (US spelling), while the comment uses 'initialise' (UK 
spelling). Just in case this is not some post-Brexit expression of 
cross-Atlantic friendliness you might want to fix it. :)

Thanks,

Ingo

RE: [PATCH v4 0/3] PCI: Add Intel PCIe Driver and respective dt-binding yaml file

[Gustavo Pimentel]

Hi,


On Mon, Oct 21, 2019 at 7:39:17, Dilip Kota  
wrote:

> Intel PCIe is synopsys based controller utilizes the Designware

Please do this general replacement in all your patches.

s/synopsys/Synopsys

and

s/Designware/DesignWare

> framework for host initialization and intel application
> specific register configurations.
> 
> Changes on v4:
>   Add lane resizing API in PCIe DesignWare driver.
>   Intel PCIe driver uses it for lane resizing which
>is being exposed through sysfs attributes.
>   Add Intel PCIe sysfs attributes is in separate patch.
>   Address review comments given on v3.
> 
> Changes on v3:
>   Compared to v2, map_irq() patch is removed as it is no longer
> required for Intel PCIe driver. Intel PCIe driver does platform
> specific interrupt configuration during core initialization. So
> changed the subject line too.
>   Address v2 review comments for DT binding and PCIe driver
> 
> Dilip Kota (3):
>   dt-bindings: PCI: intel: Add YAML schemas for the PCIe RC controller
>   dwc: PCI: intel: PCIe RC controller driver
>   pci: intel: Add sysfs attributes to configure pcie link
> 
>  .../devicetree/bindings/pci/intel-gw-pcie.yaml | 135 
>  drivers/pci/controller/dwc/Kconfig |  10 +
>  drivers/pci/controller/dwc/Makefile|   1 +
>  drivers/pci/controller/dwc/pcie-designware.c   |  43 ++
>  drivers/pci/controller/dwc/pcie-designware.h   |  15 +
>  drivers/pci/controller/dwc/pcie-intel-gw.c | 700 +++
>  include/uapi/linux/pci_regs.h  |   1 +
>  7 files changed, 905 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
>  create mode 100644 drivers/pci/controller/dwc/pcie-intel-gw.c
> 
> -- 
> 2.11.0

Re: [PATCH v2 11/13] drivers: irqchip: qcom-pdc: Add irqchip for sc7180

[Marc Zyngier]

On 2019-10-21 07:55, Rajendra Nayak wrote:

From: Maulik Shah 

Add sc7180 pdc irqchip

Signed-off-by: Maulik Shah 
Signed-off-by: Rajendra Nayak 
Cc: Lina Iyer 
Cc: Marc Zyngier 
---
v2: No change

 drivers/irqchip/qcom-pdc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index faa7d61b9d6c..954fb599fa9c 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -310,3 +310,4 @@ static int qcom_pdc_init(struct device_node
*node, struct device_node *parent)
 }

 IRQCHIP_DECLARE(pdc_sdm845, "qcom,sdm845-pdc", qcom_pdc_init);
+IRQCHIP_DECLARE(pdc_sc7180, "qcom,sc7180-pdc", qcom_pdc_init);


What I gather from these 3 irq-related patches is that as far as
the PDC is concerned, SDM845/850 and SC7180 are strictly identical.

Why the churn?

M.
--
Jazz is not dead. It just smells funny...

[v4,1/2] dt-bindings: i2c: support property idle-state

[Biwen Li]

This supports property idle-state

Signed-off-by: Biwen Li 
---
Change in v4:
- none

Change in v3:
- update subject and description
- add some information for property idle-state

Change in v2:
- update subject and description
- add property idle-state

 Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
index 30ac6a60f041..7abda506b828 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
@@ -25,6 +25,8 @@ Required Properties:
 Optional Properties:
 
   - reset-gpios: Reference to the GPIO connected to the reset input.
+  - idle-state: if present, overrides i2c-mux-idle-disconnect,
+Please refer to Documentation/devicetree/bindings/mux/mux-controller.txt
   - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
 children in idle state. This is necessary for example, if there are several
 multiplexers on the bus and the devices behind them use same I2C addresses.
-- 
2.17.1

[v4,2/2] i2c: mux: pca954x: support property idle-state

[Biwen Li]

This supports property idle-state

Signed-off-by: Biwen Li 
---
Change in v4:
- rename function
  pca954x_calculate_chan -> pca954x_regval

Change in v3:
- update subject and description
- add a helper function pca954x_calculate_chan()

Change in v2:
- update subject and description
- add property idle-state

 drivers/i2c/muxes/i2c-mux-pca954x.c | 59 ++---
 1 file changed, 36 insertions(+), 23 deletions(-)

diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c 
b/drivers/i2c/muxes/i2c-mux-pca954x.c
index 923aa3a5a3dc..e566c4cd8ba5 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -86,7 +86,7 @@ struct pca954x {
 
u8 last_chan;   /* last register value */
/* MUX_IDLE_AS_IS, MUX_IDLE_DISCONNECT or >= 0 for channel */
-   s8 idle_state;
+   s32 idle_state;
 
struct i2c_client *client;
 
@@ -229,20 +229,23 @@ static int pca954x_reg_write(struct i2c_adapter *adap,
I2C_SMBUS_BYTE, &dummy);
 }
 
+static u8 pca954x_regval(struct pca954x *data, u8 chan)
+{
+   /* we make switches look like muxes, not sure how to be smarter */
+   if (data->chip->muxtype == pca954x_ismux)
+   return chan | data->chip->enable;
+   else
+   return 1 << chan;
+}
+
 static int pca954x_select_chan(struct i2c_mux_core *muxc, u32 chan)
 {
struct pca954x *data = i2c_mux_priv(muxc);
struct i2c_client *client = data->client;
-   const struct chip_desc *chip = data->chip;
u8 regval;
int ret = 0;
 
-   /* we make switches look like muxes, not sure how to be smarter */
-   if (chip->muxtype == pca954x_ismux)
-   regval = chan | chip->enable;
-   else
-   regval = 1 << chan;
-
+   regval = pca954x_regval(data, (u8)(chan & 0xff));
/* Only select the channel if its different from the last channel */
if (data->last_chan != regval) {
ret = pca954x_reg_write(muxc->parent, client, regval);
@@ -256,7 +259,7 @@ static int pca954x_deselect_mux(struct i2c_mux_core *muxc, 
u32 chan)
 {
struct pca954x *data = i2c_mux_priv(muxc);
struct i2c_client *client = data->client;
-   s8 idle_state;
+   s32 idle_state;
 
idle_state = READ_ONCE(data->idle_state);
if (idle_state >= 0)
@@ -402,6 +405,17 @@ static void pca954x_cleanup(struct i2c_mux_core *muxc)
i2c_mux_del_adapters(muxc);
 }
 
+static int pca954x_init(struct i2c_client *client, struct pca954x *data)
+{
+   if (data->idle_state >= 0) {
+   data->last_chan = pca954x_regval(data, (u8)(data->idle_state & 
0xff));
+   } else {
+   /* Disconnect multiplexer */
+   data->last_chan = 0;
+   }
+   return i2c_smbus_write_byte(client, data->last_chan);
+}
+
 /*
  * I2C init/probing/exit functions
  */
@@ -411,7 +425,6 @@ static int pca954x_probe(struct i2c_client *client,
struct i2c_adapter *adap = client->adapter;
struct device *dev = &client->dev;
struct device_node *np = dev->of_node;
-   bool idle_disconnect_dt;
struct gpio_desc *gpio;
struct i2c_mux_core *muxc;
struct pca954x *data;
@@ -462,23 +475,24 @@ static int pca954x_probe(struct i2c_client *client,
}
}
 
-   /* Write the mux register at addr to verify
+   data->idle_state = MUX_IDLE_AS_IS;
+   if (of_property_read_u32(np, "idle-state", &data->idle_state)) {
+   if (np && of_property_read_bool(np, "i2c-mux-idle-disconnect"))
+   data->idle_state = MUX_IDLE_DISCONNECT;
+   }
+
+   /*
+* Write the mux register at addr to verify
 * that the mux is in fact present. This also
-* initializes the mux to disconnected state.
+* initializes the mux to a channel
+* or disconnected state.
 */
-   if (i2c_smbus_write_byte(client, 0) < 0) {
+   ret = pca954x_init(client, data);
+   if (ret < 0) {
dev_warn(dev, "probe failed\n");
return -ENODEV;
}
 
-   data->last_chan = 0;   /* force the first selection */
-   data->idle_state = MUX_IDLE_AS_IS;
-
-   idle_disconnect_dt = np &&
-   of_property_read_bool(np, "i2c-mux-idle-disconnect");
-   if (idle_disconnect_dt)
-   data->idle_state = MUX_IDLE_DISCONNECT;
-
ret = pca954x_irq_setup(muxc);
if (ret)
goto fail_cleanup;
@@ -531,8 +545,7 @@ static int pca954x_resume(struct device *dev)
struct i2c_mux_core *muxc = i2c_get_clientdata(client);
struct pca954x *data = i2c_mux_priv(muxc);
 
-   data->last_chan = 0;
-   return i2c_smbus_write_byte(client, 0);
+   return pca954x_init(client, data);
 }
 #endif
 
-- 
2.17.1

Re: [PATCH v2 3/4] KVM: x86/vPMU: Reuse perf_event to avoid unnecessary pmc_reprogram_counter

[Paolo Bonzini]

Just a naming tweak:

On 13/10/19 11:15, Like Xu wrote:
> + /* the exact requested config to create perf_event */
> + u64 programed_config;

/*
 * eventsel value for general purpose counters, ctrl value for
 * fixed counters.
 */
u64 current_config;

Re: [PATCH] ARM: dt: add fxos8700 on gateworks boards

[Marco Felsch]

Hi Robert,

please don't use 'ARM: dt: ..' instead you should name it 'ARM: dts:
imx6qdl-gw5x:'.

On 19-10-18 16:20, Robert Jones wrote:
> Add fxos8700 iio imu entries for Gateworks SBCs.
> 
> Signed-off-by: Robert Jones 
> ---
>  arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 5 +
>  arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 5 +
>  arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 5 +
>  3 files changed, 15 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi 
> b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
> index 1a9a9d9..ffc4449 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
> @@ -306,6 +306,11 @@
>   VDDIO-supply = <®_3p3v>;
>   };
>  
> + fxos8700@1e {
> + compatible = "nxp,fxos8700";

I grep'd the whole tree and found no such compatible. I don't know the
rule but IMHO if there isn't a driver we shouldn't add the compatible
here.

Regards,
  Marco

> + reg = <0x1e>;
> + };
> +
>   touchscreen: egalax_ts@4 {
>   compatible = "eeti,egalax_ts";
>   reg = <0x04>;
> diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi 
> b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
> index 54b2bea..ebbd1c8 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
> @@ -297,6 +297,11 @@
>   VDDIO-supply = <®_3p3v>;
>   };
>  
> + fxos8700@1e {
> + compatible = "nxp,fxos8700";
> + reg = <0x1e>;
> + };
> +
>   touchscreen: egalax_ts@4 {
>   compatible = "eeti,egalax_ts";
>   reg = <0x04>;
> diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi 
> b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
> index 1b6c133..67d4725 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
> @@ -354,6 +354,11 @@
>   VDDIO-supply = <®_3p3v>;
>   };
>  
> + fxos8700@1e {
> + compatible = "nxp,fxos8700";
> + reg = <0x1e>;
> + };
> +
>   touchscreen: egalax_ts@4 {
>   compatible = "eeti,egalax_ts";
>   reg = <0x04>;
> -- 
> 2.9.2
> 
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v2 3/4] KVM: x86/vPMU: Reuse perf_event to avoid unnecessary pmc_reprogram_counter

[Like Xu]

Hi Paolo,

On 2019/10/21 16:12, Paolo Bonzini wrote:

Just a naming tweak:

On 13/10/19 11:15, Like Xu wrote:

+   /* the exact requested config to create perf_event */
+   u64 programed_config;


/*
 * eventsel value for general purpose counters, ctrl value for
 * fixed counters.
 */
u64 current_config;




It looks good to me and I'll apply this.
Is there more need for improvement？

Re: [RFC PATCH v2 10/16] mm,hwpoison: Rework soft offline for free pages

[Naoya Horiguchi]

On Thu, Oct 17, 2019 at 04:21:17PM +0200, Oscar Salvador wrote:
> When trying to soft-offline a free page, we need to first take it off
> the buddy allocator.
> Once we know is out of reach, we can safely flag it as poisoned.
> 
> take_page_off_buddy will be used to take a page meant to be poisoned
> off the buddy allocator.
> take_page_off_buddy calls break_down_buddy_pages, which splits a
> higher-order page in case our page belongs to one.
> 
> Once the page is under our control, we call page_set_poison to set it

I guess you mean page_handle_poison here.

> as poisoned and grab a refcount on it.
> 
> Signed-off-by: Oscar Salvador 
> ---
>  mm/memory-failure.c | 20 +++-
>  mm/page_alloc.c | 68 
> +
>  2 files changed, 82 insertions(+), 6 deletions(-)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 37b230b8cfe7..1d986580522d 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -78,6 +78,15 @@ EXPORT_SYMBOL_GPL(hwpoison_filter_dev_minor);
>  EXPORT_SYMBOL_GPL(hwpoison_filter_flags_mask);
>  EXPORT_SYMBOL_GPL(hwpoison_filter_flags_value);
>  
> +extern bool take_page_off_buddy(struct page *page);
> +
> +static void page_handle_poison(struct page *page)

hwpoison is a separate idea from page poisoning, so maybe I think
it's better to be named like page_handle_hwpoison().

> +{
> + SetPageHWPoison(page);
> + page_ref_inc(page);
> + num_poisoned_pages_inc();
> +}
> +
>  static int hwpoison_filter_dev(struct page *p)
>  {
>   struct address_space *mapping;
> @@ -1830,14 +1839,13 @@ static int soft_offline_in_use_page(struct page *page)
>  
>  static int soft_offline_free_page(struct page *page)
>  {
> - int rc = dissolve_free_huge_page(page);
> + int rc = -EBUSY;
>  
> - if (!rc) {
> - if (set_hwpoison_free_buddy_page(page))
> - num_poisoned_pages_inc();
> - else
> - rc = -EBUSY;
> + if (!dissolve_free_huge_page(page) && take_page_off_buddy(page)) {
> + page_handle_poison(page);
> + rc = 0;
>   }
> +
>   return rc;
>  }
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index cd1dd0712624..255df0c76a40 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -8632,6 +8632,74 @@ bool is_free_buddy_page(struct page *page)
>  
>  #ifdef CONFIG_MEMORY_FAILURE
>  /*
> + * Break down a higher-order page in sub-pages, and keep our target out of
> + * buddy allocator.
> + */
> +static void break_down_buddy_pages(struct zone *zone, struct page *page,
> +struct page *target, int low, int high,
> +struct free_area *area, int migratetype)
> +{
> + unsigned long size = 1 << high;
> + struct page *current_buddy, *next_page;
> +
> + while (high > low) {
> + area--;
> + high--;
> + size >>= 1;
> +
> + if (target >= &page[size]) {
> + next_page = page + size;
> + current_buddy = page;
> + } else {
> + next_page = page;
> + current_buddy = page + size;
> + }
> +
> + if (set_page_guard(zone, current_buddy, high, migratetype))
> + continue;
> +
> + if (current_buddy != target) {
> + add_to_free_area(current_buddy, area, migratetype);
> + set_page_order(current_buddy, high);
> + page = next_page;
> + }
> + }
> +}
> +
> +/*
> + * Take a page that will be marked as poisoned off the buddy allocator.
> + */
> +bool take_page_off_buddy(struct page *page)
> + {
> + struct zone *zone = page_zone(page);
> + unsigned long pfn = page_to_pfn(page);
> + unsigned long flags;
> + unsigned int order;
> + bool ret = false;
> +
> + spin_lock_irqsave(&zone->lock, flags);
> + for (order = 0; order < MAX_ORDER; order++) {
> + struct page *page_head = page - (pfn & ((1 << order) - 1));
> + int buddy_order = page_order(page_head);
> + struct free_area *area = &(zone->free_area[buddy_order]);
> +
> + if (PageBuddy(page_head) && buddy_order >= order) {
> + unsigned long pfn_head = page_to_pfn(page_head);
> + int migratetype = get_pfnblock_migratetype(page_head,
> +pfn_head);
> +
> + del_page_from_free_area(page_head, area);
> + break_down_buddy_pages(zone, page_head, page, 0,
> +buddy_order, area, migratetype);
> + ret = true;
> + break;

indent with whitespace?
And you can find a few more coding style warning with checkpatch.pl.

BTW, if we consider to make unpoison mechanism to k

Re: [PATCH] KVM: remove redundant code in kvm_arch_vm_ioctl

[Thomas Gleixner]

On Mon, 21 Oct 2019, Miaohe Lin wrote:
> If we reach here with r = 0, we will reassign r = 0
> unnecesarry, then do the label set_irqchip_out work.
> If we reach here with r != 0, then we will do the label
> work directly. So this if statement and r = 0 assignment
> is redundant.
> 
> Signed-off-by: Miaohe Lin 
> ---
>  arch/x86/kvm/x86.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 661e2bf38526..0b3ebc2afb3d 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -4916,9 +4916,6 @@ long kvm_arch_vm_ioctl(struct file *filp,
>   if (!irqchip_kernel(kvm))
>   goto set_irqchip_out;
>   r = kvm_vm_ioctl_set_irqchip(kvm, chip);
> - if (r)
> - goto set_irqchip_out;
> - r = 0;
>   set_irqchip_out:
>   kfree(chip);
>   break;

Can you please get rid of that odd jump label completely?

if (irqchip_kernel(kvm))
r = kvm_vm_ioctl_set_irqchip(kvm, chip);

Hmm?


Thanks,

tglx

Re: [RFC PATCH 12/13] dt-bindings: mfd: Document ROHM BD71282 bindings

[Vaittinen, Matti]

Thanks Dan,

On Thu, 2019-10-17 at 09:18 -0500, Dan Murphy wrote:
> Matt

By the way, its Matti ;)

> On 10/17/19 4:55 AM, Matti Vaittinen wrote:
> > ROHM BD71828 Power management IC integrates 7 buck converters, 7
> > LDOs,
> > a real-time clock (RTC), 3 GPO/regulator control pins, HALL input
> > pin
> > and a 32.768 kHz clock gate.
> > 
> > Document the dt bindings drivers are using.
> 
> This should be patch 1 of X

I will rebase :)

Br,
Matti Vaittinen

Re: [PATCH] ARM: dt: add lsm9ds1 iio imu/magn support to gw553x

[Marco Felsch]

Hi Robert,

same here, don't name it 'ARM: dt: ...' instead name it 'ARM: dts: imx:
ventana: ..' or 'ARM: dts: imx: imx6qdl-gw553x: ..'.

On 19-10-18 16:21, Robert Jones wrote:
> Add one node for the accel/gyro i2c device and another for the separate
> magnetometer device in the lsm9ds1.
> 
> Signed-off-by: Robert Jones 
> ---
>  arch/arm/boot/dts/imx6qdl-gw553x.dtsi | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-gw553x.dtsi 
> b/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
> index a106689..55e6922 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
> @@ -173,6 +173,25 @@
>   pinctrl-0 = <&pinctrl_i2c2>;
>   status = "okay";
>  
> + lsm9ds1_ag@6a {
> + compatible = "st,lsm9ds1-imu";

Didn't found this compatible string.

> + reg = <0x6a>;
> + st,drdy-int-pin = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_acc_gyro>;
> + interrupt-parent = <&gpio7>;
> + interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + lsm9ds1_m@1c {
> + compatible = "st,lsm9ds1-magn";
> + reg = <0x1c>;

Nodes are sorted according their i2c-addresses.

Regards,
  Marco

> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mag>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <2 IRQ_TYPE_EDGE_RISING>;
> + };
> +
>   ltc3676: pmic@3c {
>   compatible = "lltc,ltc3676";
>   reg = <0x3c>;
> @@ -462,6 +481,18 @@
>   >;
>   };
>  
> + pinctrl_acc_gyro: acc_gyrogrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_18__GPIO7_IO13  0x1b0b0
> + >;
> + };
> +
> + pinctrl_mag: maggrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_2__GPIO1_IO02   0x1b0b0
> + >;
> + };
> +
>   pinctrl_pps: ppsgrp {
>   fsl,pins = <
>   MX6QDL_PAD_ENET_RXD1__GPIO1_IO260x1b0b1
> -- 
> 2.9.2
> 
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] cpufreq: flush any pending policy update work scheduled before freeing

[Rafael J. Wysocki]

On Mon, Oct 21, 2019 at 4:15 AM Viresh Kumar  wrote:
>
> On 18-10-19, 12:06, Sudeep Holla wrote:
> > Callstack is:
> >
> > (cpufreq_notifier_max)
> > (notifier_call_chain)
> > (blocking_notifier_call_chain)
> > (pm_qos_update_target)
> > (freq_qos_apply)
> > (freq_qos_remove_request)
> > (cpufreq_policy_free)
> > (subsys_interface_unregister)
> > (cpufreq_unregister_driver)
>
> @sudeep: I see that the patch is merged now, but as I said earlier the
> reasoning isn't clear yet. Please don't stop working on this and lets
> clean this once and for all.
>
> What patches were you testing this with? My buggy patches or Rafael's
> patches as well ? At least with my patches, this can happen due to the
> other bug where the notifier doesn't get removed (as I said earlier),
> but once that bug isn't there then this shouldn't happen, else we have
> another bug in pipeline somewhere and should find it.

Right.

I have found one already which should be fixed in my current
linux-next branch, so testing that in particular would be appreciated.

[PATCH v2] soc: amlogic: meson-gx-socinfo: Fix S905D3 ID for VIM3L

[Christian Hewitt]

Chip on the board is S905D3 not S905X3:

[0.098998] soc soc0: Amlogic Meson SM1 (S905D3) Revision 2b:c (b0:2) 
Detected

Change from v1: use 0xf0 mask instead of 0xf2 as advised by Neil Armstrong.

Fixes: 1d7c541b8a5b ("soc: amlogic: meson-gx-socinfo: Add S905X3 ID for VIM3L")

Signed-off-by: Christian Hewitt 
---
 drivers/soc/amlogic/meson-gx-socinfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c 
b/drivers/soc/amlogic/meson-gx-socinfo.c
index 87ed558..01fc0d2 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -69,7 +69,7 @@ static const struct meson_gx_package_id {
{ "S922X", 0x29, 0x40, 0xf0 },
{ "A311D", 0x29, 0x10, 0xf0 },
{ "S905X3", 0x2b, 0x5, 0xf },
-   { "S905X3", 0x2b, 0xb0, 0xf2 },
+   { "S905D3", 0x2b, 0xb0, 0xf0 },
{ "A113L", 0x2c, 0x0, 0xf8 },
 };
 
-- 
2.7.4

Re: [PATCH v2] soc: amlogic: meson-gx-socinfo: Fix S905D3 ID for VIM3L

[Neil Armstrong]

On 21/10/2019 10:20, Christian Hewitt wrote:
> Chip on the board is S905D3 not S905X3:
> 
> [0.098998] soc soc0: Amlogic Meson SM1 (S905D3) Revision 2b:c (b0:2) 
> Detected
> 
> Change from v1: use 0xf0 mask instead of 0xf2 as advised by Neil Armstrong.
> 
> Fixes: 1d7c541b8a5b ("soc: amlogic: meson-gx-socinfo: Add S905X3 ID for 
> VIM3L")
> 
> Signed-off-by: Christian Hewitt 
> ---
>  drivers/soc/amlogic/meson-gx-socinfo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c 
> b/drivers/soc/amlogic/meson-gx-socinfo.c
> index 87ed558..01fc0d2 100644
> --- a/drivers/soc/amlogic/meson-gx-socinfo.c
> +++ b/drivers/soc/amlogic/meson-gx-socinfo.c
> @@ -69,7 +69,7 @@ static const struct meson_gx_package_id {
>   { "S922X", 0x29, 0x40, 0xf0 },
>   { "A311D", 0x29, 0x10, 0xf0 },
>   { "S905X3", 0x2b, 0x5, 0xf },
> - { "S905X3", 0x2b, 0xb0, 0xf2 },
> + { "S905D3", 0x2b, 0xb0, 0xf0 },
>   { "A113L", 0x2c, 0x0, 0xf8 },
>  };
>  
> 

Acked-by: Neil Armstrong 

Re: [PATCH] mmc: fix mmc dma operation

[Jianxin Pan]

Hi Neil,

Thanks for the review, I will update the subject and commit message in the next 
version.

On 2019/10/21 15:57, Neil Armstrong wrote:
> Hi,
> 
> Thanks for the fix.
> 
> First, you should add "mmc: meson-gx:" in the subject.
> 
> On 21/10/2019 07:59, Jianxin Pan wrote:
>> From: Nan Li 
>>
>> In MMC dma transfer, the region requested by dma_map_sg() may be released
>> by dma_unmap_sg() before the transfer is completed.
>>
>> Put the unmap operation in front of mmc_request_done() to avoid this.
> 
> 
> You should add a "Fixes:" tag so it can be backported on stable kernels.
> 
>>
>> Signed-off-by: Nan Li 
>> Signed-off-by: Jianxin Pan 
>> ---
>>  drivers/mmc/host/meson-gx-mmc.c | 15 ---
>>  1 file changed, 8 insertions(+), 7 deletions(-)
>>
[...]
>>  }
>>  
>>  static void meson_mmc_read_resp(struct mmc_host *mmc, struct mmc_command 
>> *cmd)
>>
> Neil
> 
> .
> 

Re: [patch 07/26] mm/memunmap: don't access uninitialized memmap in memunmap_pages()

[Michal Hocko]

Has this been properly reviewed? I do not see any Acks nor Reviewed-bys.

On Fri 18-10-19 20:19:39, Andrew Morton wrote:
> From: "Aneesh Kumar K.V" 
> Subject: mm/memunmap: don't access uninitialized memmap in memunmap_pages()
> 
> Patch series "mm/memory_hotplug: Shrink zones before removing memory", v6.
> 
> This series fixes the access of uninitialized memmaps when shrinking
> zones/nodes and when removing memory.  Also, it contains all fixes for
> crashes that can be triggered when removing certain namespace using
> memunmap_pages() - ZONE_DEVICE, reported by Aneesh.
> 
> We stop trying to shrink ZONE_DEVICE, as it's buggy, fixing it would be
> more involved (we don't have SECTION_IS_ONLINE as an indicator), and
> shrinking is only of limited use (set_zone_contiguous() cannot detect the
> ZONE_DEVICE as contiguous).
> 
> We continue shrinking !ZONE_DEVICE zones, however, I reduced the amount of
> code to a minimum.  Shrinking is especially necessary to keep
> zone->contiguous set where possible, especially, on memory unplug of DIMMs
> at zone boundaries.
> 
> --
> 
> Zones are now properly shrunk when offlining memory blocks or when
> onlining failed.  This allows to properly shrink zones on memory unplug
> even if the separate memory blocks of a DIMM were onlined to different
> zones or re-onlined to a different zone after offlining.
> 
> Example:
> 
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
> spanned  0
> present  0
> managed  0
> :/# echo "online_movable" > /sys/devices/system/memory/memory41/state
> :/# echo "online_movable" > /sys/devices/system/memory/memory43/state
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
> spanned  98304
> present  65536
> managed  65536
> :/# echo 0 > /sys/devices/system/memory/memory43/online
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
> spanned  32768
> present  32768
> managed  32768
> :/# echo 0 > /sys/devices/system/memory/memory41/online
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
> spanned  0
> present  0
> managed  0
> 
> 
> This patch (of 10):
> 
> With an altmap, the memmap falling into the reserved altmap space are not
> initialized and, therefore, contain a garbage NID and a garbage zone. 
> Make sure to read the NID/zone from a memmap that was initialized.
> 
> This fixes a kernel crash that is observed when destroying a namespace:
> 
> [   81.356173] kernel BUG at include/linux/mm.h:1107!
> cpu 0x1: Vector: 700 (Program Check) at [c00274087890]
> pc: c04b9728: memunmap_pages+0x238/0x340
> lr: c04b9724: memunmap_pages+0x234/0x340
> ...
> pid   = 3669, comm = ndctl
> kernel BUG at include/linux/mm.h:1107!
> [c00274087ba0] c09e3500 devm_action_release+0x30/0x50
> [c00274087bc0] c09e4758 release_nodes+0x268/0x2d0
> [c00274087c30] c09dd144 device_release_driver_internal+0x174/0x240
> [c00274087c70] c09d9dfc unbind_store+0x13c/0x190
> [c00274087cb0] c09d8a24 drv_attr_store+0x44/0x60
> [c00274087cd0] c05a7470 sysfs_kf_write+0x70/0xa0
> [c00274087d10] c05a5cac kernfs_fop_write+0x1ac/0x290
> [c00274087d60] c04be45c __vfs_write+0x3c/0x70
> [c00274087d80] c04c26e4 vfs_write+0xe4/0x200
> [c00274087dd0] c04c2a6c ksys_write+0x7c/0x140
> [c00274087e20] c000bbd0 system_call+0x5c/0x68
> 
> The "page_zone(pfn_to_page(pfn)" was introduced by 69324b8f4833 ("mm,
> devm_memremap_pages: add MEMORY_DEVICE_PRIVATE support"), however, I
> think we will never have driver reserved memory with
> MEMORY_DEVICE_PRIVATE (no altmap AFAIKS).
> 
> [da...@redhat.com: minimze code changes, rephrase description]
> Link: http://lkml.kernel.org/r/20191006085646.5768-2-da...@redhat.com
> Fixes: 2c2a5af6fed2 ("mm, memory_hotplug: add nid parameter to 
> arch_remove_memory")
> Signed-off-by: Aneesh Kumar K.V 
> Signed-off-by: David Hildenbrand 
> Cc: Dan Williams 
> Cc: Jason Gunthorpe 
> Cc: Logan Gunthorpe 
> Cc: Ira Weiny 
> Cc: Damian Tometzki 
> Cc: Alexander Duyck 
> Cc: Alexander Potapenko 
> Cc: Andy Lutomirski 
> Cc: Anshuman Khandual 
> Cc: Benjamin Herrenschmidt 
> Cc: Borislav Petkov 
> Cc: Catalin Marinas 
> Cc: Christian Borntraeger 
> Cc: Christophe Leroy 
> Cc: Dave Hansen 
> Cc: Fenghua Yu 
> Cc: Gerald Schaefer 
> Cc: Greg Kroah-Hartman 
> Cc: Halil Pasic 
> Cc: Heiko Carstens 
> Cc: "H. Peter Anvin" 
> Cc: Ingo Molnar 
> Cc: Jun Yao 
> Cc: Mark Rutland 
> Cc: Masahiro Yamada 
> Cc: "Matthew Wilcox (Oracle)" 
> Cc: Mel Gorman 
> Cc: Michael Ellerman 
> Cc: Michal Hocko 
> Cc: Mike Rapoport 
> Cc: Oscar Salvador 
> Cc: Pankaj Gupta 
> Cc: Paul Mackerras 
> Cc: Pavel Tatashin 
> Cc: Pavel Tatashin 
> Cc: Peter Zijlstra 
> Cc: Qian Cai 
> Cc: Rich Felker 
> Cc: Robin Murphy 
> Cc: Steve Capper 
> Cc: Thomas Gleixner 
> Cc: Tom Lendacky 
> C

[BUGFIX PATCH v2 1/5] selftests: proc: Make va_max 1GB on 32bit arch

[Masami Hiramatsu]

Currently proc-self-map-files-002.c sets va_max (max test address
of user virtual address) to 4GB, but it is too big for 32bit
arch and 1UL << 32 is overflow on 32bit long.

Make va_max 1GB on 32bit arch like i386 and arm.

Signed-off-by: Masami Hiramatsu 
Cc: Alexey Dobriyan 
---
 Changes in v2:
  - Make the va_max 1GB according to Alexey's comment.
---
 .../selftests/proc/proc-self-map-files-002.c   |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/proc/proc-self-map-files-002.c 
b/tools/testing/selftests/proc/proc-self-map-files-002.c
index 47b7473dedef..5d372d66d6ad 100644
--- a/tools/testing/selftests/proc/proc-self-map-files-002.c
+++ b/tools/testing/selftests/proc/proc-self-map-files-002.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void pass(const char *fmt, unsigned long a, unsigned long b)
 {
@@ -44,10 +45,18 @@ static void fail(const char *fmt, unsigned long a, unsigned 
long b)
exit(1);
 }
 
+#if __BITS_PER_LONG == 32
+# define VA_MAX (1UL << 30)
+#elif __BITS_PER_LONG == 64
+# define VA_MAX (1UL << 32)
+#else
+# define VA_MAX 0
+#endif
+
 int main(void)
 {
const int PAGE_SIZE = sysconf(_SC_PAGESIZE);
-   const unsigned long va_max = 1UL << 32;
+   const unsigned long va_max = VA_MAX;
unsigned long va;
void *p;
int fd;

Re: [patch 06/26] mm/memory_hotplug: don't access uninitialized memmaps in shrink_pgdat_span()

[Michal Hocko]

Has this been reviewed properly? I do not see any Acks nor Reviewed-bys.
Did Aneesh gave it some testing?

On Fri 18-10-19 20:19:33, Andrew Morton wrote:
> From: David Hildenbrand 
> Subject: mm/memory_hotplug: don't access uninitialized memmaps in 
> shrink_pgdat_span()
> 
> We might use the nid of memmaps that were never initialized.  For example,
> if the memmap was poisoned, we will crash the kernel in pfn_to_nid() right
> now.  Let's use the calculated boundaries of the separate zones instead. 
> This now also avoids having to iterate over a whole bunch of subsections
> again, after shrinking one zone.
> 
> Before commit d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug"),
> the memmap was initialized to 0 and the node was set to the right value. 
> After that commit, the node might be garbage.
> 
> We'll have to fix shrink_zone_span() next.
> 
> Link: http://lkml.kernel.org/r/20191006085646.5768-4-da...@redhat.com
> Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to 
> zones until online")[d0dc12e86b319]
> Signed-off-by: David Hildenbrand 
> Reported-by: Aneesh Kumar K.V 
> Cc: Oscar Salvador 
> Cc: David Hildenbrand 
> Cc: Michal Hocko 
> Cc: Pavel Tatashin 
> Cc: Dan Williams 
> Cc: Wei Yang 
> Cc: Alexander Duyck 
> Cc: Alexander Potapenko 
> Cc: Andy Lutomirski 
> Cc: Anshuman Khandual 
> Cc: Benjamin Herrenschmidt 
> Cc: Borislav Petkov 
> Cc: Catalin Marinas 
> Cc: Christian Borntraeger 
> Cc: Christophe Leroy 
> Cc: Damian Tometzki 
> Cc: Dave Hansen 
> Cc: Fenghua Yu 
> Cc: Gerald Schaefer 
> Cc: Greg Kroah-Hartman 
> Cc: Halil Pasic 
> Cc: Heiko Carstens 
> Cc: "H. Peter Anvin" 
> Cc: Ingo Molnar 
> Cc: Ira Weiny 
> Cc: Jason Gunthorpe 
> Cc: Jun Yao 
> Cc: Logan Gunthorpe 
> Cc: Mark Rutland 
> Cc: Masahiro Yamada 
> Cc: "Matthew Wilcox (Oracle)" 
> Cc: Mel Gorman 
> Cc: Michael Ellerman 
> Cc: Mike Rapoport 
> Cc: Pankaj Gupta 
> Cc: Paul Mackerras 
> Cc: Pavel Tatashin 
> Cc: Peter Zijlstra 
> Cc: Qian Cai 
> Cc: Rich Felker 
> Cc: Robin Murphy 
> Cc: Steve Capper 
> Cc: Thomas Gleixner 
> Cc: Tom Lendacky 
> Cc: Tony Luck 
> Cc: Vasily Gorbik 
> Cc: Vlastimil Babka 
> Cc: Wei Yang 
> Cc: Will Deacon 
> Cc: Yoshinori Sato 
> Cc: Yu Zhao 
> Cc:   [4.13+]
> Signed-off-by: Andrew Morton 
> ---
> 
>  mm/memory_hotplug.c |   74 +-
>  1 file changed, 16 insertions(+), 58 deletions(-)
> 
> --- 
> a/mm/memory_hotplug.c~mm-memory_hotplug-dont-access-uninitialized-memmaps-in-shrink_pgdat_span
> +++ a/mm/memory_hotplug.c
> @@ -436,67 +436,25 @@ static void shrink_zone_span(struct zone
>   zone_span_writeunlock(zone);
>  }
>  
> -static void shrink_pgdat_span(struct pglist_data *pgdat,
> -   unsigned long start_pfn, unsigned long end_pfn)
> +static void update_pgdat_span(struct pglist_data *pgdat)
>  {
> - unsigned long pgdat_start_pfn = pgdat->node_start_pfn;
> - unsigned long p = pgdat_end_pfn(pgdat); /* pgdat_end_pfn namespace 
> clash */
> - unsigned long pgdat_end_pfn = p;
> - unsigned long pfn;
> - int nid = pgdat->node_id;
> -
> - if (pgdat_start_pfn == start_pfn) {
> - /*
> -  * If the section is smallest section in the pgdat, it need
> -  * shrink pgdat->node_start_pfn and pgdat->node_spanned_pages.
> -  * In this case, we find second smallest valid mem_section
> -  * for shrinking zone.
> -  */
> - pfn = find_smallest_section_pfn(nid, NULL, end_pfn,
> - pgdat_end_pfn);
> - if (pfn) {
> - pgdat->node_start_pfn = pfn;
> - pgdat->node_spanned_pages = pgdat_end_pfn - pfn;
> - }
> - } else if (pgdat_end_pfn == end_pfn) {
> - /*
> -  * If the section is biggest section in the pgdat, it need
> -  * shrink pgdat->node_spanned_pages.
> -  * In this case, we find second biggest valid mem_section for
> -  * shrinking zone.
> -  */
> - pfn = find_biggest_section_pfn(nid, NULL, pgdat_start_pfn,
> -start_pfn);
> - if (pfn)
> - pgdat->node_spanned_pages = pfn - pgdat_start_pfn + 1;
> - }
> -
> - /*
> -  * If the section is not biggest or smallest mem_section in the pgdat,
> -  * it only creates a hole in the pgdat. So in this case, we need not
> -  * change the pgdat.
> -  * But perhaps, the pgdat has only hole data. Thus it check the pgdat
> -  * has only hole or not.
> -  */
> - pfn = pgdat_start_pfn;
> - for (; pfn < pgdat_end_pfn; pfn += PAGES_PER_SUBSECTION) {
> - if (unlikely(!pfn_valid(pfn)))
> - continue;
> -
> - if (pfn_to_nid(pfn) != nid)
> - continue;
> -
> - /* Skip range to be removed */
> -  

[BUGFIX PATCH v2 3/5] selftests: net: Use size_t and ssize_t for counting file size

[Masami Hiramatsu]

Use size_t and ssize_t correctly for counting send file size
instead of unsigned long and long, because long is 32bit on
32bit arch, which is not enough for counting long file size (>4GB).

Signed-off-by: Masami Hiramatsu 
Cc: Eric Dumazet 
Cc: David S. Miller 
---
 tools/testing/selftests/net/tcp_mmap.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/net/tcp_mmap.c 
b/tools/testing/selftests/net/tcp_mmap.c
index 31ced79f4f25..33035d1b3f6d 100644
--- a/tools/testing/selftests/net/tcp_mmap.c
+++ b/tools/testing/selftests/net/tcp_mmap.c
@@ -71,7 +71,7 @@
 #define MSG_ZEROCOPY0x400
 #endif
 
-#define FILE_SZ (1UL << 35)
+#define FILE_SZ (1ULL << 35)
 static int cfg_family = AF_INET6;
 static socklen_t cfg_alen = sizeof(struct sockaddr_in6);
 static int cfg_port = 8787;
@@ -155,7 +155,7 @@ void *child_thread(void *arg)
socklen_t zc_len = sizeof(zc);
int res;
 
-   zc.address = (__u64)addr;
+   zc.address = (__u64)((unsigned long)addr);
zc.length = chunk_size;
zc.recv_skip_hint = 0;
res = getsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE,
@@ -302,7 +302,7 @@ int main(int argc, char *argv[])
 {
struct sockaddr_storage listenaddr, addr;
unsigned int max_pacing_rate = 0;
-   unsigned long total = 0;
+   size_t total = 0;
char *host = NULL;
int fd, c, on = 1;
char *buffer;
@@ -417,7 +417,7 @@ int main(int argc, char *argv[])
zflg = 0;
}
while (total < FILE_SZ) {
-   long wr = FILE_SZ - total;
+   ssize_t wr = FILE_SZ - total;
 
if (wr > chunk_size)
wr = chunk_size;

[BUGFIX PATCH v2 4/5] selftests: net: Fix printf format warnings on arm

[Masami Hiramatsu]

Fix printf format warnings on arm (and other 32bit arch).

 - udpgso.c and udpgso_bench_tx use %lu for size_t but it
   should be unsigned long long on 32bit arch.

 - so_txtime.c uses %ld for int64_t, but it should be
   unsigned long long on 32bit arch.

Signed-off-by: Masami Hiramatsu 
Cc: Willem de Bruijn 
Cc: David S. Miller 
---
 tools/testing/selftests/net/so_txtime.c   |4 ++--
 tools/testing/selftests/net/udpgso.c  |3 ++-
 tools/testing/selftests/net/udpgso_bench_tx.c |3 ++-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/net/so_txtime.c 
b/tools/testing/selftests/net/so_txtime.c
index 53f598f06647..34df4c8882af 100644
--- a/tools/testing/selftests/net/so_txtime.c
+++ b/tools/testing/selftests/net/so_txtime.c
@@ -105,8 +105,8 @@ static void do_recv_one(int fdr, struct timed_send *ts)
tstop = (gettime_ns() - glob_tstart) / 1000;
texpect = ts->delay_us >= 0 ? ts->delay_us : 0;
 
-   fprintf(stderr, "payload:%c delay:%ld expected:%ld (us)\n",
-   rbuf[0], tstop, texpect);
+   fprintf(stderr, "payload:%c delay:%lld expected:%lld (us)\n",
+   rbuf[0], (long long)tstop, (long long)texpect);
 
if (rbuf[0] != ts->data)
error(1, 0, "payload mismatch. expected %c", ts->data);
diff --git a/tools/testing/selftests/net/udpgso.c 
b/tools/testing/selftests/net/udpgso.c
index b8265ee9923f..cab334e51ac1 100644
--- a/tools/testing/selftests/net/udpgso.c
+++ b/tools/testing/selftests/net/udpgso.c
@@ -448,7 +448,8 @@ static bool __send_one(int fd, struct msghdr *msg, int 
flags)
if (ret == -1)
error(1, errno, "sendmsg");
if (ret != msg->msg_iov->iov_len)
-   error(1, 0, "sendto: %d != %lu", ret, msg->msg_iov->iov_len);
+   error(1, 0, "sendto: %d != %llu", ret,
+   (unsigned long long)msg->msg_iov->iov_len);
if (msg->msg_flags)
error(1, 0, "sendmsg: return flags 0x%x\n", msg->msg_flags);
 
diff --git a/tools/testing/selftests/net/udpgso_bench_tx.c 
b/tools/testing/selftests/net/udpgso_bench_tx.c
index ada99496634a..17512a43885e 100644
--- a/tools/testing/selftests/net/udpgso_bench_tx.c
+++ b/tools/testing/selftests/net/udpgso_bench_tx.c
@@ -405,7 +405,8 @@ static int send_udp_segment(int fd, char *data)
if (ret == -1)
error(1, errno, "sendmsg");
if (ret != iov.iov_len)
-   error(1, 0, "sendmsg: %u != %lu\n", ret, iov.iov_len);
+   error(1, 0, "sendmsg: %u != %llu\n", ret,
+   (unsigned long long)iov.iov_len);
 
return 1;
 }

[BUGFIX PATCH v2 5/5] selftests: sync: Fix cast warnings on arm

[Masami Hiramatsu]

Fix warnings on __u64 and pointer translation on arm and
other 32bit architectures. Since the pointer is 32bits on
those archs, we should not directly cast those types.

Signed-off-by: Masami Hiramatsu 
Cc: Emilio López 
---
 tools/testing/selftests/sync/sync.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/sync/sync.c 
b/tools/testing/selftests/sync/sync.c
index f3d599f249b9..7741c0518d18 100644
--- a/tools/testing/selftests/sync/sync.c
+++ b/tools/testing/selftests/sync/sync.c
@@ -109,7 +109,7 @@ static struct sync_file_info *sync_file_info(int fd)
return NULL;
}
 
-   info->sync_fence_info = (uint64_t)fence_info;
+   info->sync_fence_info = (uint64_t)(unsigned long)fence_info;
 
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
if (err < 0) {
@@ -124,7 +124,7 @@ static struct sync_file_info *sync_file_info(int fd)
 
 static void sync_file_info_free(struct sync_file_info *info)
 {
-   free((void *)info->sync_fence_info);
+   free((void *)(unsigned long)info->sync_fence_info);
free(info);
 }
 
@@ -152,7 +152,7 @@ int sync_fence_count_with_status(int fd, int status)
if (!info)
return -1;
 
-   fence_info = (struct sync_fence_info *)info->sync_fence_info;
+   fence_info = (struct sync_fence_info *)(unsigned 
long)info->sync_fence_info;
for (i = 0 ; i < info->num_fences ; i++) {
if (fence_info[i].status == status)
count++;

Re: [patch 07/26] mm/memunmap: don't access uninitialized memmap in memunmap_pages()

[David Hildenbrand]

On 21.10.19 10:26, Michal Hocko wrote:

Has this been properly reviewed? I do not see any Acks nor Reviewed-bys.



As I modified this patch while carrying it along, it at least has my 
implicit Ack/RB.


--

Thanks,

David / dhildenb

[BUGFIX PATCH v2 2/5] selftests: vm: Build/Run 64bit tests only on 64bit arch

[Masami Hiramatsu]

Some virtual address range tests requires 64bit address space,
and we can not build and run those tests on the 32bit machine.

Filter the 64bit architectures in Makefile and run_vmtests,
so that those tests are built/run only on 64bit archs.

Signed-off-by: Masami Hiramatsu 
Cc: Anshuman Khandual 
Cc: Aneesh Kumar K.V 
---
 tools/testing/selftests/vm/Makefile|5 +
 tools/testing/selftests/vm/run_vmtests |   10 ++
 2 files changed, 15 insertions(+)

diff --git a/tools/testing/selftests/vm/Makefile 
b/tools/testing/selftests/vm/Makefile
index 9534dc2bc929..7f9a8a8c31da 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 # Makefile for vm selftests
+uname_M := $(shell uname -m 2>/dev/null || echo not)
+ARCH ?= $(shell echo $(uname_M) | sed -e 's/aarch64.*/arm64/')
 
 CFLAGS = -Wall -I ../../../../usr/include $(EXTRA_CFLAGS)
 LDLIBS = -lrt
@@ -16,8 +18,11 @@ TEST_GEN_FILES += on-fault-limit
 TEST_GEN_FILES += thuge-gen
 TEST_GEN_FILES += transhuge-stress
 TEST_GEN_FILES += userfaultfd
+
+ifneq (,$(filter $(ARCH),arm64 ia64 mips64 parisc64 ppc64 riscv64 s390x sh64 
sparc64 x86_64))
 TEST_GEN_FILES += va_128TBswitch
 TEST_GEN_FILES += virtual_address_range
+endif
 
 TEST_PROGS := run_vmtests
 
diff --git a/tools/testing/selftests/vm/run_vmtests 
b/tools/testing/selftests/vm/run_vmtests
index 951c507a27f7..a692ea828317 100755
--- a/tools/testing/selftests/vm/run_vmtests
+++ b/tools/testing/selftests/vm/run_vmtests
@@ -58,6 +58,14 @@ else
exit 1
 fi
 
+#filter 64bit architectures
+ARCH64STR="arm64 ia64 mips64 parisc64 ppc64 riscv64 s390x sh64 sparc64 x86_64"
+if [ -z $ARCH ]; then
+  ARCH=`uname -m 2>/dev/null | sed -e 's/aarch64.*/arm64/'`
+fi
+VADDR64=0
+echo "$ARCH64STR" | grep $ARCH && VADDR64=1
+
 mkdir $mnt
 mount -t hugetlbfs none $mnt
 
@@ -189,6 +197,7 @@ else
echo "[PASS]"
 fi
 
+if [ $VADDR64 -ne 0 ]; then
 echo "-"
 echo "running virtual_address_range"
 echo "-"
@@ -210,6 +219,7 @@ if [ $? -ne 0 ]; then
 else
 echo "[PASS]"
 fi
+fi # VADDR64
 
 echo ""
 echo "running vmalloc stability smoke test"

[BUGFIX PATCH v2 0/5] selftests: Fixes for 32bit arch

[Masami Hiramatsu]

Hi,

Here are the 2nd version of kselftest fixes some on 32bit arch
(e.g. arm). In this version, I updated [1/5] to make va_max 1GB
instead of 3GB, according to Alexey's comment.

When I built the ksefltest on arm, I hit some 32bit related warnings.
Here are the patches to fix those issues.


 - [1/5] va_max was set 2^32 even on 32bit arch. This can make
va_max == 0 and always fail. Make it 3GB on 32bit.
 - [2/5] Some VM tests requires 64bit user space, which should
not run on 32bit arch.
 - [3/5] For counting the size of large file, we should use
size_t instead of unsinged long.
 - [4/5] Gcc warns printf format for size_t and int64_t on
32bit arch. Use %llu and cast it.
 - [5/5] Gcc warns __u64 and pointer type castings. It should
once translated to unsigned long.

Thank you,

---

Masami Hiramatsu (5):
  selftests: proc: Make va_max 1GB on 32bit arch
  selftests: vm: Build/Run 64bit tests only on 64bit arch
  selftests: net: Use size_t and ssize_t for counting file size
  selftests: net: Fix printf format warnings on arm
  selftests: sync: Fix cast warnings on arm


 tools/testing/selftests/net/so_txtime.c|4 ++--
 tools/testing/selftests/net/tcp_mmap.c |8 
 tools/testing/selftests/net/udpgso.c   |3 ++-
 tools/testing/selftests/net/udpgso_bench_tx.c  |3 ++-
 .../selftests/proc/proc-self-map-files-002.c   |   11 ++-
 tools/testing/selftests/sync/sync.c|6 +++---
 tools/testing/selftests/vm/Makefile|5 +
 tools/testing/selftests/vm/run_vmtests |   10 ++
 8 files changed, 38 insertions(+), 12 deletions(-)

--
Masami Hiramatsu (Linaro) 

Re: [PATCH v2] rtl8xxxu: fix RTL8723BU connection failure issue after warm reboot

[Kalle Valo]

Chris Chiu  writes:

> On Thu, Oct 17, 2019 at 10:26 AM Chris Chiu  wrote:
>>
>> On Wed, Oct 16, 2019 at 9:54 AM Chris Chiu  wrote:
>> >
>> > The RTL8723BU has problems connecting to AP after each warm reboot.
>> > Sometimes it returns no scan result, and in most cases, it fails
>> > the authentication for unknown reason. However, it works totally
>> > fine after cold reboot.
>> >
>> > Compare the value of register SYS_CR and SYS_CLK_MAC_CLK_ENABLE
>> > for cold reboot and warm reboot, the registers imply that the MAC
>> > is already powered and thus some procedures are skipped during
>> > driver initialization. Double checked the vendor driver, it reads
>> > the SYS_CR and SYS_CLK_MAC_CLK_ENABLE also but doesn't skip any
>> > during initialization based on them. This commit only tells the
>> > RTL8723BU to do full initialization without checking MAC status.
>> >
>> > Signed-off-by: Chris Chiu 
>> Signed-off-by: Jes Sorensen 
>>
>> Sorry, I forgot to add Jes.
>>
>> Chris
>> > ---
>> >
>> > Note:
>> >   v2: fix typo of commit message
>> >
>> >
>
> Gentle ping. Cheers.

To reduce email please avoid pinging like this, it has been only five
days since you submitted this version and this is not a 24/7 service. I
have documented how you can follow the status from patchwork:

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

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

Re: [PATCH] arm64: dts: meson: khadas-vim3: move audio nodes to common dtsi

[Neil Armstrong]

On 18/10/2019 18:29, Christian Hewitt wrote:
> Move VIM3 audio nodes to meson-khadas-vim3.dtsi to enable audio for all
> boards in the VIM3 family including VIM3L.
> 
> This change depends on [1] being merged/applied first.
> 
> [1] https://patchwork.kernel.org/patch/11198535/
> 
> Signed-off-by: Christian Hewitt 
> ---
>  .../boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi   | 89 
> --
>  arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi | 88 +
>  2 files changed, 88 insertions(+), 89 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi 
> b/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi
> index 69019d0..190e934 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi
> @@ -5,8 +5,6 @@
>   * Copyright (c) 2019 Christian Hewitt 
>   */
>  
> -#include 
> -
>  / {
>   vddcpu_a: regulator-vddcpu-a {
>   /*
> @@ -45,69 +43,6 @@
>   regulator-boot-on;
>   regulator-always-on;
>   };
> -
> - sound {
> - compatible = "amlogic,axg-sound-card";
> - model = "G12A-KHADAS-VIM3";
> - audio-aux-devs = <&tdmout_b>;
> - audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
> - "TDMOUT_B IN 1", "FRDDR_B OUT 1",
> - "TDMOUT_B IN 2", "FRDDR_C OUT 1",
> - "TDM_B Playback", "TDMOUT_B OUT";
> -
> - assigned-clocks = <&clkc CLKID_MPLL2>,
> -   <&clkc CLKID_MPLL0>,
> -   <&clkc CLKID_MPLL1>;
> - assigned-clock-parents = <0>, <0>, <0>;
> - assigned-clock-rates = <294912000>,
> -<270950400>,
> -<393216000>;
> - status = "okay";
> -
> - dai-link-0 {
> - sound-dai = <&frddr_a>;
> - };
> -
> - dai-link-1 {
> - sound-dai = <&frddr_b>;
> - };
> -
> - dai-link-2 {
> - sound-dai = <&frddr_c>;
> - };
> -
> - /* 8ch hdmi interface */
> - dai-link-3 {
> - sound-dai = <&tdmif_b>;
> - dai-format = "i2s";
> - dai-tdm-slot-tx-mask-0 = <1 1>;
> - dai-tdm-slot-tx-mask-1 = <1 1>;
> - dai-tdm-slot-tx-mask-2 = <1 1>;
> - dai-tdm-slot-tx-mask-3 = <1 1>;
> - mclk-fs = <256>;
> -
> - codec {
> - sound-dai = <&tohdmitx TOHDMITX_I2S_IN_B>;
> - };
> - };
> -
> - /* hdmi glue */
> - dai-link-4 {
> - sound-dai = <&tohdmitx TOHDMITX_I2S_OUT>;
> -
> - codec {
> - sound-dai = <&hdmi_tx>;
> - };
> - };
> - };
> -};
> -
> -&arb {
> - status = "okay";
> -};
> -
> -&clkc_audio {
> - status = "okay";
>  };
>  
>  &cpu0 {
> @@ -152,18 +87,6 @@
>   clock-latency = <5>;
>  };
>  
> -&frddr_a {
> -status = "okay";
> -};
> -
> -&frddr_b {
> - status = "okay";
> -};
> -
> -&frddr_c {
> - status = "okay";
> -};
> -
>  &pwm_ab {
>   pinctrl-0 = <&pwm_a_e_pins>;
>   pinctrl-names = "default";
> @@ -179,15 +102,3 @@
>   clock-names = "clkin1";
>   status = "okay";
>  };
> -
> -&tdmif_b {
> - status = "okay";
> -};
> -
> -&tdmout_b {
> - status = "okay";
> -};
> -
> -&tohdmitx {
> - status = "okay";
> -};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi 
> b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> index 90815fa..3f5c373 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> @@ -7,6 +7,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  / {
>   model = "Khadas VIM3";
> @@ -76,6 +77,61 @@
>   clock-names = "ext_clock";
>   };
>  
> + sound {
> + compatible = "amlogic,axg-sound-card";
> + model = "G12A-KHADAS-VIM3";
> + audio-aux-devs = <&tdmout_b>;
> + audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
> + "TDMOUT_B IN 1", "FRDDR_B OUT 1",
> + "TDMOUT_B IN 2", "FRDDR_C OUT 1",
> + "TDM_B Playback", "TDMOUT_B OUT";
> +
> + assigned-clocks = <&clkc CLKID_MPLL2>,
> +   <&clkc CLKID_MPLL0>,
> +   <&clkc CLKID_MPLL1>;
> + assigned-clock-parents = <0>, <0>, <0>;
> + assigned-clock-rates = <294912000>,
> +<270950400>,
> + 

RE: [PATCH v4 2/3] dwc: PCI: intel: PCIe RC controller driver

[Gustavo Pimentel]

Hi

On Mon, Oct 21, 2019 at 7:39:19, Dilip Kota  
wrote:

> Add support to PCIe RC controller on Intel Gateway SoCs.
> PCIe controller is based of Synopsys DesignWare pci core.
> 
> Intel PCIe driver requires Upconfig support, fast training
> sequence configuration and link speed change. So adding the
> respective helper functions in the pcie DesignWare framework.
> It also programs hardware autonomous speed during speed
> configuration so defining it in pci_regs.h.

Please do the replacement in all of your patches

s/pcie/PCIe
s/pci/PCI

Also I think the correct term is Upconfigure and not Upconfig

> 
> Changes on v4:
>   Rename the driver naming and description to
>"PCIe RC controller on Intel Gateway SoCs".
>   Use PCIe core register macros defined in pci_regs.h
>and remove respective local definitions.
>   Remove pcie core interrupt handling.
>   Move pcie link control speed change, upconfig and FTS.
>   configuration functions to DesignWare framework.
>   Use of_pci_get_max_link_speed().
>   Mark dependency on X86 and COMPILE_TEST in Kconfig.
>   Remove lanes and add n_fts variables in intel_pcie_port structure.
>   Rename rst_interval variable to rst_intrvl in intel_pcie_port structure.
>   Remove intel_pcie_mem_iatu() as it is already perfomed in dw_setup_rc()
>   Move sysfs attributes specific code to separate patch.
>   Remove redundant error handling.
>   Reduce LoCs by doing variable initializations while declaration itself.
>   Add extra line after closing parenthesis.
>   Move intel_pcie_ep_rst_init() out of get_resources()
> 
> changes on v3:
>   Rename PCIe app logic registers with PCIE_APP prefix.
>   PCIE_IOP_CTRL configuration is not required. Remove respective code.
>   Remove wrapper functions for clk enable/disable APIs.
>   Use platform_get_resource_byname() instead of
> devm_platform_ioremap_resource() to be similar with DWC framework.
>   Rename phy name to "pciephy".
>   Modify debug message in msi_init() callback to be more specific.
>   Remove map_irq() callback.
>   Enable the INTx interrupts at the time of PCIe initialization.
>   Reduce memory fragmentation by using variable "struct dw_pcie pci"
> instead of allocating memory.
>   Reduce the delay to 100us during enpoint initialization
> intel_pcie_ep_rst_init().
>   Call  dw_pcie_host_deinit() during remove() instead of directly
> calling PCIe core APIs.
>   Rename "intel,rst-interval" to "reset-assert-ms".
>   Remove unused APP logic Interrupt bit macro definitions.
>   Use dwc framework's dw_pcie_setup_rc() for PCIe host specific
>configuration instead of redefining the same functionality in
>the driver.
>   Move the whole DT parsing specific code to intel_pcie_get_resources()
> 
> Signed-off-by: Dilip Kota 
> ---
>  drivers/pci/controller/dwc/Kconfig   |  10 +
>  drivers/pci/controller/dwc/Makefile  |   1 +
>  drivers/pci/controller/dwc/pcie-designware.c |  34 ++
>  drivers/pci/controller/dwc/pcie-designware.h |  12 +
>  drivers/pci/controller/dwc/pcie-intel-gw.c   | 590 
> +++
>  include/uapi/linux/pci_regs.h|   1 +
>  6 files changed, 648 insertions(+)
>  create mode 100644 drivers/pci/controller/dwc/pcie-intel-gw.c
> 
> diff --git a/drivers/pci/controller/dwc/Kconfig 
> b/drivers/pci/controller/dwc/Kconfig
> index 0ba988b5b5bc..b33ed1cc873d 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -82,6 +82,16 @@ config PCIE_DW_PLAT_EP
> order to enable device-specific features PCI_DW_PLAT_EP must be
> selected.
>  
> +config PCIE_INTEL_GW
> +bool "Intel Gateway PCIe host controller support"
> + depends on OF && (X86 || COMPILE_TEST)
> + select PCIE_DW_HOST
> + help
> +  Say 'Y' here to enable support for PCIe Host controller driver.
> +   The PCIe controller on Intel Gateway SoCs is based on the Synopsys
> +   DesignWare pcie core and therefore uses the DesignWare core
> +   functions for the driver implementation.
> +
>  config PCI_EXYNOS
>   bool "Samsung Exynos PCIe controller"
>   depends on SOC_EXYNOS5440 || COMPILE_TEST
> diff --git a/drivers/pci/controller/dwc/Makefile 
> b/drivers/pci/controller/dwc/Makefile
> index b30336181d46..99db83cd2f35 100644
> --- a/drivers/pci/controller/dwc/Makefile
> +++ b/drivers/pci/controller/dwc/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_PCIE_DW) += pcie-designware.o
>  obj-$(CONFIG_PCIE_DW_HOST) += pcie-designware-host.o
>  obj-$(CONFIG_PCIE_DW_EP) += pcie-designware-ep.o
>  obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
> +obj-$(CONFIG_PCIE_INTEL_GW) += pcie-intel-gw.o
>  obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
>  obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
>  obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
> diff --git a/drivers/pci/controller/dwc/

Re: [PATCH v4 0/3] PCI: Add Intel PCIe Driver and respective dt-binding yaml file

[Dilip Kota]

Hi Gustavo Pimentel,

On 10/21/2019 4:08 PM, Gustavo Pimentel wrote:

Hi,


On Mon, Oct 21, 2019 at 7:39:17, Dilip Kota 
wrote:


Intel PCIe is synopsys based controller utilizes the Designware

Please do this general replacement in all your patches.

s/synopsys/Synopsys

and

s/Designware/DesignWare

Sure, i will update it in the next patch version.
(In the all other patches naming is proper, i got missed it here.)
I will ensure and take care of it.

Regards,
Dilip




framework for host initialization and intel application
specific register configurations.

Changes on v4:
Add lane resizing API in PCIe DesignWare driver.
Intel PCIe driver uses it for lane resizing which
 is being exposed through sysfs attributes.
Add Intel PCIe sysfs attributes is in separate patch.
Address review comments given on v3.

Changes on v3:
Compared to v2, map_irq() patch is removed as it is no longer
  required for Intel PCIe driver. Intel PCIe driver does platform
  specific interrupt configuration during core initialization. So
  changed the subject line too.
Address v2 review comments for DT binding and PCIe driver

Dilip Kota (3):
   dt-bindings: PCI: intel: Add YAML schemas for the PCIe RC controller
   dwc: PCI: intel: PCIe RC controller driver
   pci: intel: Add sysfs attributes to configure pcie link

  .../devicetree/bindings/pci/intel-gw-pcie.yaml | 135 
  drivers/pci/controller/dwc/Kconfig |  10 +
  drivers/pci/controller/dwc/Makefile|   1 +
  drivers/pci/controller/dwc/pcie-designware.c   |  43 ++
  drivers/pci/controller/dwc/pcie-designware.h   |  15 +
  drivers/pci/controller/dwc/pcie-intel-gw.c | 700 +++
  include/uapi/linux/pci_regs.h  |   1 +
  7 files changed, 905 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
  create mode 100644 drivers/pci/controller/dwc/pcie-intel-gw.c

--
2.11.0

Re: [patch 07/26] mm/memunmap: don't access uninitialized memmap in memunmap_pages()

[Michal Hocko]

On Mon 21-10-19 10:28:16, David Hildenbrand wrote:
> On 21.10.19 10:26, Michal Hocko wrote:
> > Has this been properly reviewed? I do not see any Acks nor Reviewed-bys.
> > 
> 
> As I modified this patch while carrying it along, it at least has my
> implicit Ack/RB.

OK, thanks!
-- 
Michal Hocko
SUSE Labs

[PATCH] perf/core: Fix tracking of auxiliary trace buffer allocation

[Thomas Richter]

commit d44248a41337 ("perf/core: Rework memory accounting in perf_mmap()")
breaks auxiliary trace buffer tracking.

I run command 'perf record -e rbd000' to record samples and saving
them in the **auxiliary** trace buffer. The value of 'locked_vm' becomes
negative after all trace buffers have been allocated and released:

During allocation the values increase
[52.250027] perf_mmap user->locked_vm:0x87 pinned_vm:0x0 ret:0
[52.250115] perf_mmap user->locked_vm:0x107 pinned_vm:0x0 ret:0
[52.250251] perf_mmap user->locked_vm:0x188 pinned_vm:0x0 ret:0
[52.250326] perf_mmap user->locked_vm:0x208 pinned_vm:0x0 ret:0
[52.250441] perf_mmap user->locked_vm:0x289 pinned_vm:0x0 ret:0
[52.250498] perf_mmap user->locked_vm:0x309 pinned_vm:0x0 ret:0
[52.250613] perf_mmap user->locked_vm:0x38a pinned_vm:0x0 ret:0
[52.250715] perf_mmap user->locked_vm:0x408 pinned_vm:0x2 ret:0
[52.250834] perf_mmap user->locked_vm:0x408 pinned_vm:0x83 ret:0
[52.250915] perf_mmap user->locked_vm:0x408 pinned_vm:0x103 ret:0
[52.251061] perf_mmap user->locked_vm:0x408 pinned_vm:0x184 ret:0
[52.251146] perf_mmap user->locked_vm:0x408 pinned_vm:0x204 ret:0
[52.251299] perf_mmap user->locked_vm:0x408 pinned_vm:0x285 ret:0
[52.251383] perf_mmap user->locked_vm:0x408 pinned_vm:0x305 ret:0
[52.251544] perf_mmap user->locked_vm:0x408 pinned_vm:0x386 ret:0
[52.251634] perf_mmap user->locked_vm:0x408 pinned_vm:0x406 ret:0
[52.253018] perf_mmap user->locked_vm:0x408 pinned_vm:0x487 ret:0
[52.253197] perf_mmap user->locked_vm:0x408 pinned_vm:0x508 ret:0
[52.253374] perf_mmap user->locked_vm:0x408 pinned_vm:0x589 ret:0
[52.253550] perf_mmap user->locked_vm:0x408 pinned_vm:0x60a ret:0
[52.253726] perf_mmap user->locked_vm:0x408 pinned_vm:0x68b ret:0
[52.253903] perf_mmap user->locked_vm:0x408 pinned_vm:0x70c ret:0
[52.254084] perf_mmap user->locked_vm:0x408 pinned_vm:0x78d ret:0
[52.254263] perf_mmap user->locked_vm:0x408 pinned_vm:0x80e ret:0

The value of user->locked_vm increases to a limit then the memory
is tracked by pinned_vm.

During deallocation the size is subtracted from pinned_vm until
it hits a limit. Then a larger value is subtracted from locked_vm
leading to a large number (because of type unsigned):
[64.267797] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x78d
[64.267826] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x70c
[64.267848] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x68b
[64.267869] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x60a
[64.267891] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x589
[64.267911] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x508
[64.267933] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x487
[64.267952] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x406
[64.268883] perf_mmap_close mmap_user->locked_vm:0x307 pinned_vm:0x406
[64.269117] perf_mmap_close mmap_user->locked_vm:0x206 pinned_vm:0x406
[64.269433] perf_mmap_close mmap_user->locked_vm:0x105 pinned_vm:0x406
[64.269536] perf_mmap_close mmap_user->locked_vm:0x4 pinned_vm:0x404
[64.269797] perf_mmap_close mmap_user->locked_vm:0xff84 
pinned_vm:0x303
[64.270105] perf_mmap_close mmap_user->locked_vm:0xff04 
pinned_vm:0x202
[64.270374] perf_mmap_close mmap_user->locked_vm:0xfe84 
pinned_vm:0x101
[64.270628] perf_mmap_close mmap_user->locked_vm:0xfe04 
pinned_vm:0x0

This value sticks for the user until system is rebooted, causing
follow-on system calls using locked_vm resource limit to fail.

Note: There is no issue using the normal trace buffer.

In fact the issue is in perf_mmap_close(). During allocation auxiliary
trace buffer memory is either traced as 'extra' and added to 'pinned_vm'
or trace as 'user_extra' and added to 'locked_vm'. This applies for
normal trace buffers and auxiliary trace buffer.

However in function perf_mmap_close() all auxiliary trace buffer is
subtraced from 'locked_vm' and never from 'pinned_vm'. This breaks the
ballance.

Fixes: d44248a41337 ("perf/core: Rework memory accounting in perf_mmap()")

Signed-off-by: Thomas Richter 
---
 kernel/events/core.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 9ec0b0bfddbd..90ba23043af0 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5607,8 +5607,12 @@ static void perf_mmap_close(struct vm_area_struct *vma)
perf_pmu_output_stop(event);
 
/* now it's safe to free the pages */
-   atomic_long_sub(rb->aux_nr_pages, &mmap_user->locked_vm);
-   atomic64_sub(rb->aux_mmap_locked, &vma->vm_mm->pinned_vm);
+   if (!rb->aux_mmap_locked)
+   atomic_long_sub(rb->aux_nr_pages,
+   &mmap_user->locked_vm);
+   else
+   atomic64_sub(rb->aux_mmap_locked,
+&vma->vm_mm->pinned_vm);
 
/* this h

Re: [patch 06/26] mm/memory_hotplug: don't access uninitialized memmaps in shrink_pgdat_span()

[David Hildenbrand]

On 21.10.19 10:28, Michal Hocko wrote:

Has this been reviewed properly? I do not see any Acks nor Reviewed-bys.
Did Aneesh gave it some testing?


No explicit ACK/RB. I know that Aneesh at leasted reviewed parts of the 
v4/v5 series and gave it a test (which resulted in "[patch 07/26] 
mm/memunmap: don't access uninitialized memmap in memunmap_pages()").


--

Thanks,

David / dhildenb

Re: [PATCH] xfrm : lock input tasklet skb queue

[Steffen Klassert]

On Sun, Oct 20, 2019 at 08:46:10AM -0700, Tom Rix wrote:
> On PREEMPT_RT_FULL while running netperf, a corruption
> of the skb queue causes an oops.
> 
> This appears to be caused by a race condition here
> __skb_queue_tail(&trans->queue, skb);
> tasklet_schedule(&trans->tasklet);
> Where the queue is changed before the tasklet is locked by
> tasklet_schedule.
> 
> The fix is to use the skb queue lock.
> 
> Signed-off-by: Tom Rix 
> ---
>  net/xfrm/xfrm_input.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> index 9b599ed66d97..226dead86828 100644
> --- a/net/xfrm/xfrm_input.c
> +++ b/net/xfrm/xfrm_input.c
> @@ -758,12 +758,16 @@ static void xfrm_trans_reinject(unsigned long data)
>  struct xfrm_trans_tasklet *trans = (void *)data;
>  struct sk_buff_head queue;
>  struct sk_buff *skb;
> +unsigned long flags;
> 
>  __skb_queue_head_init(&queue);
> +spin_lock_irqsave(&trans->queue.lock, flags);
>  skb_queue_splice_init(&trans->queue, &queue);
> 
>  while ((skb = __skb_dequeue(&queue)))
>  XFRM_TRANS_SKB_CB(skb)->finish(dev_net(skb->dev), NULL, skb);
> +
> +spin_unlock_irqrestore(&trans->queue.lock, flags);
>  }
> 
>  int xfrm_trans_queue(struct sk_buff *skb,
> @@ -771,15 +775,20 @@ int xfrm_trans_queue(struct sk_buff *skb,
> struct sk_buff *))
>  {
>  struct xfrm_trans_tasklet *trans;
> +unsigned long flags;
> 
>  trans = this_cpu_ptr(&xfrm_trans_tasklet);
> +spin_lock_irqsave(&trans->queue.lock, flags);

As you can see above 'trans' is per cpu, so a spinlock
is not needed here. Also this does not run in hard
interrupt context, so irqsave is also not needed.
I don't see how this can fix anything.

Can you please explain that race a bit more detailed?

Re: [PATCH v7 1/3] PM: wakeup: Add routine to help fetch wakeup source object.

[Rafael J. Wysocki]

On Mon, Oct 21, 2019 at 5:49 AM Ran Wang  wrote:
>
> Some user might want to go through all registered wakeup sources
> and doing things accordingly. For example, SoC PM driver might need to
> do HW programming to prevent powering down specific IP which wakeup
> source depending on. So add this API to help walk through all registered
> wakeup source objects on that list and return them one by one.
>
> Signed-off-by: Ran Wang 
> Tested-by: Leonard Crestez 
> ---
> Change in v7:
> - Remove define of member *dev in wake_irq to fix conflict with commit
> c8377adfa781 ("PM / wakeup: Show wakeup sources stats in sysfs"), user
> will use ws->dev->parent instead.
> - Remove '#include ' because it is not used.
>
> Change in v6:
> - Add wakeup_source_get_star() and wakeup_source_get_stop() to aligned
> with wakeup_sources_stats_seq_start/nex/stop.
>
> Change in v5:
> - Update commit message, add decription of walk through all wakeup
> source objects.
> - Add SCU protection in function wakeup_source_get_next().
> - Rename wakeup_source member 'attached_dev' to 'dev' and move it up
> (before wakeirq).
>
> Change in v4:
> - None.
>
> Change in v3:
> - Adjust indentation of *attached_dev;.
>
> Change in v2:
> - None.
>
>  drivers/base/power/wakeup.c | 37 +
>  include/linux/pm_wakeup.h   |  3 +++
>  2 files changed, 40 insertions(+)
>
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index 5817b51..dee1b09 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -248,6 +248,43 @@ void wakeup_source_unregister(struct wakeup_source *ws)
>  EXPORT_SYMBOL_GPL(wakeup_source_unregister);
>
>  /**
> + * wakeup_source_get_star - Begin a walk on wakeup source list

The "get" in the name suggests acquiring a reference of some kind
which doesn't happen here.

What about renaming it to wakeup_sources_walk_start()?

> + * @srcuidx: Lock index allocated for this caller.
> + */
> +struct wakeup_source *wakeup_source_get_start(int *srcuidx)

I don't quite like the calling convention here with passing an int
pointer to get the SRCU index back.

What about splitting this into, say, wakeup_sources_read_lock() (that
will return the SRCU index) and wakeup_sources_walk_start() (that will
return the first list entry)?

Then, you could do something like

idx = wakeup_sources_read_lock();

ws = wakeup_sources_walk_start();
while (ws) {

stuff

ws = wakeup_sources_walk_next();
}

wakeup_sources_read_unlock(idx);

Or even define for_each_wakeup_source(ws) as

for (ws = wakeup_sources_walk_start(); ws; ws = wakeup_sources_walk_next())

and use that under a _read_lock()/_read_unlock() pair?

Re: [PATCH] KVM: remove redundant code in kvm_arch_vm_ioctl

[linmiaohe]

On Mon, 21 Oct 2019, tglx wrote:
>On Mon, 21 Oct 2019, Miaohe Lin wrote:
>> If we reach here with r = 0, we will reassign r = 0 unnecesarry, then 
>> do the label set_irqchip_out work.
>> If we reach here with r != 0, then we will do the label work directly. 
>> So this if statement and r = 0 assignment is redundant.
>
>Can you please get rid of that odd jump label completely?
>
>   if (irqchip_kernel(kvm))
>   r = kvm_vm_ioctl_set_irqchip(kvm, chip);
>
>Hmm?

Sure, thanks for your reply. I will send patch v2 to complete it.
Thanks again.

RE: [PATCH v4 3/3] pci: intel: Add sysfs attributes to configure pcie link

[Gustavo Pimentel]

On Mon, Oct 21, 2019 at 7:39:20, Dilip Kota  
wrote:

> PCIe RC driver on Intel Gateway SoCs have a requirement
> of changing link width and speed on the fly.
> So add the sysfs attributes to show and store the link
> properties.
> Add the respective link resize function in pcie DesignWare
> framework so that Intel PCIe driver can use during link
> width configuration on the fly.
> 
> Signed-off-by: Dilip Kota 
> ---
>  drivers/pci/controller/dwc/pcie-designware.c |   9 +++
>  drivers/pci/controller/dwc/pcie-designware.h |   3 +
>  drivers/pci/controller/dwc/pcie-intel-gw.c   | 112 
> ++-
>  3 files changed, 123 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
> b/drivers/pci/controller/dwc/pcie-designware.c
> index 4c391bfd681a..662fdcb4f2d6 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -474,6 +474,15 @@ int dw_pcie_link_up(struct dw_pcie *pci)
>   (!(val & PCIE_PORT_DEBUG1_LINK_IN_TRAINING)));
>  }
>  
> +void dw_pcie_link_width_resize(struct dw_pcie *pci, u32 lane_width)
> +{
> + u32 val;
> +
> + val =  dw_pcie_readl_dbi(pci, PCIE_PORT_MULTI_LANE_CTRL);
> + val &= ~(PORT_MLTI_LNK_WDTH_CHNG | PORT_MLTI_LNK_WDTH);
> + val |= PORT_MLTI_LNK_WDTH_CHNG | lane_width;
> + dw_pcie_writel_dbi(pci, PCIE_PORT_MULTI_LANE_CTRL, val);
> +}
>  
>  void dw_pcie_upconfig_setup(struct dw_pcie *pci)
>  {
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
> b/drivers/pci/controller/dwc/pcie-designware.h
> index 3beac10e4a4c..fcf0442341fd 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -67,6 +67,8 @@
>  #define PCIE_MSI_INTR0_STATUS0x830
>  
>  #define PCIE_PORT_MULTI_LANE_CTRL0x8C0
> +#define PORT_MLTI_LNK_WDTH   GENMASK(5, 0)
> +#define PORT_MLTI_LNK_WDTH_CHNG  BIT(6)
>  #define PORT_MLTI_UPCFG_SUPPORT  BIT(7)
>  
>  #define PCIE_ATU_VIEWPORT0x900
> @@ -282,6 +284,7 @@ void dw_pcie_write_dbi2(struct dw_pcie *pci, u32 reg, 
> size_t size, u32 val);
>  u32 dw_pcie_read_atu(struct dw_pcie *pci, u32 reg, size_t size);
>  void dw_pcie_write_atu(struct dw_pcie *pci, u32 reg, size_t size, u32 val);
>  int dw_pcie_link_up(struct dw_pcie *pci);
> +void dw_pcie_link_width_resize(struct dw_pcie *pci, u32 lane_width);
>  void dw_pcie_upconfig_setup(struct dw_pcie *pci);
>  void dw_pcie_link_speed_change(struct dw_pcie *pci, bool enable);
>  void dw_pcie_link_set_n_fts(struct dw_pcie *pci, u32 n_fts);
> diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c 
> b/drivers/pci/controller/dwc/pcie-intel-gw.c
> index 9142c70db808..b9be0921671d 100644
> --- a/drivers/pci/controller/dwc/pcie-intel-gw.c
> +++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
> @@ -146,6 +146,22 @@ static void intel_pcie_ltssm_disable(struct 
> intel_pcie_port *lpp)
>   pcie_app_wr_mask(lpp, PCIE_APP_CCR_LTSSM_ENABLE, 0, PCIE_APP_CCR);
>  }
>  
> +static const char *pcie_link_gen_to_str(int gen)
> +{
> + switch (gen) {
> + case PCIE_LINK_SPEED_GEN1:
> + return "2.5";
> + case PCIE_LINK_SPEED_GEN2:
> + return "5.0";
> + case PCIE_LINK_SPEED_GEN3:
> + return "8.0";
> + case PCIE_LINK_SPEED_GEN4:
> + return "16.0";
> + default:
> + return "???";
> + }
> +}
> +
>  static void intel_pcie_link_setup(struct intel_pcie_port *lpp)
>  {
>   u32 val;
> @@ -444,6 +460,91 @@ static int intel_pcie_host_setup(struct intel_pcie_port 
> *lpp)
>   return ret;
>  }
>  
> +static ssize_t pcie_link_status_show(struct device *dev,
> +  struct device_attribute *attr, char *buf)
> +{
> + struct intel_pcie_port *lpp = dev_get_drvdata(dev);
> + u32 reg, width, gen;
> +
> + reg = pcie_rc_cfg_rd(lpp, PCIE_CAP_OFST + PCI_EXP_LNKCTL);
> + width = FIELD_GET(PCI_EXP_LNKSTA_NLW, reg >> 16);
> + gen = FIELD_GET(PCI_EXP_LNKSTA_CLS, reg >> 16);
> +
> + if (gen > lpp->max_speed)
> + return -EINVAL;
> +
> + return sprintf(buf, "Port %2u Width x%u Speed %s GT/s\n", lpp->id,
> +width, pcie_link_gen_to_str(gen));
> +}
> +static DEVICE_ATTR_RO(pcie_link_status);

Dilip please check pci.h there are there already enums and strings 
relatively to PCIe speed and width, that you can use.

> +
> +static ssize_t pcie_speed_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct intel_pcie_port *lpp = dev_get_drvdata(dev);
> + unsigned long val;
> + int ret;
> +
> + ret = kstrtoul(buf, 10, &val);
> + if (ret)
> + return ret;
> +
> + if (val > lpp->max_speed)
> + return -EINVAL;
> +
> + lpp->link_gen = val;
> + intel_pcie_max_speed_setup(lpp);
> + dw

Re: [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function

[masonccyang]

Hi Boris,

 
> > > > > > Then fill-in these two hooks from the manufacturer code, 
without 
> > the
> > > > > > postponed init.
> > > > > > 
> > > > > 
> > > > > But in the final of nand_scan_tail(), mtd->_lock/_unlock will be
> > > > > filled by NULL, right ? 
> > > > 
> > > > The NAND core should set mtd->_lock/_unlock() to NAND specific 
hooks 
> > so
> > > > that the MTD layer is abstracted and and drivers do not see it. 
Then,
> > > > in the NAND helper, either there is no specific hook defined by a
> > > > manufacturer driver and you return -ENOTSUPP, or you execute the
> > > > defined hook. 
> > > 
> > > okay, patch specific manufacturer _lock/_unlock driver
> > > in nand_manufacturer_init();
> > > 
> > > and in the final of nand_scan_tail()
> > > if (!mtd->_lock)
> > >  mtd->_lock = NULL;
> > > if (!mtd->_unlock)
> > >  mtd->_unlock = NULL; 
> > 
> > 
> > I'm still considering of post_init() in nand_scan_tail() for
> > MTD layer default call-back function replacement because
> > there would be more call-back functions need it.
> > i.e., 
> > MTD->_lock/_unlokc
> > MTD->_suspend/_resume
> 
> Again, that's something that needs to be abstracted so that both the
> NAND manufacturer driver and the NAND controller driver can take
> appropriate actions on suspend/resume operations.
> 
> > NTD->_point/_unpoint
> 
> ->_point/_unpoint() are irrelevant for a NAND chip.
> 
> > ...
> > 
> > 
> > actually, my patch series are including MTD->_locl/_unlock and 
> > MTD->_suspend/_resume. how do you think ?
> 
> Miquel was suggesting to add nand_chip->{lock,unlock,is_locked}()
> methods that would be implemented by the NAND manufacturer drivers, and
> have generic wrappers implemented in nand_base.c:
> 
> static int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> {
>struct nand_chip *chip = mtd_to_nand(mtd);
> 
>if (!chip->lock)
>   return -ENOTSUPP;
> 
>return chip->lock(chip, ofs, len);
> }
> 
> ...
> 
> If you do that, you won't need this post_init() hook.

got it, but ... 
user space program flash_lock/flash_unlock are calling 
mtd_lock() & mtd_unlock().
i.e.,
int mtd_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
 if (!mtd->_lock)
 return -EOPNOTSUPP;
 if (ofs < 0 || ofs >= mtd->size || len > mtd->size - ofs)
 return -EINVAL;
 if (!len)
 return 0;
 return mtd->_lock(mtd, ofs, len);
}


thanks for your time & comments.
Mason


CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information 
and/or personal data, which is protected by applicable laws. Please be 
reminded that duplication, disclosure, distribution, or use of this e-mail 
(and/or its attachments) or any part thereof is prohibited. If you receive 
this e-mail in error, please notify us immediately and delete this mail as 
well as its attachment(s) from your system. In addition, please be 
informed that collection, processing, and/or use of personal data is 
prohibited unless expressly permitted by personal data protection laws. 
Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=





CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information and/or 
personal data, which is protected by applicable laws. Please be reminded that 
duplication, disclosure, distribution, or use of this e-mail (and/or its 
attachments) or any part thereof is prohibited. If you receive this e-mail in 
error, please notify us immediately and delete this mail as well as its 
attachment(s) from your system. In addition, please be informed that 
collection, processing, and/or use of personal data is prohibited unless 
expressly permitted by personal data protection laws. Thank you for your 
attention and cooperation.

Macronix International Co., Ltd.

=

Re: [PATCH] fbdev/omap: fix max fclk divider for omap36xx

[Tomi Valkeinen]

On 18/10/2019 15:49, Adam Ford wrote:

The OMAP36xx and AM/DM37x TRMs say that the maximum divider for DSS fclk
(in CM_CLKSEL_DSS) is 32. Experimentation shows that this is not
correct, and using divider of 32 breaks DSS with a flood or underflows
and sync losts. Dividers up to 31 seem to work fine.

There is another patch to the DT files to limit the divider correctly,
but as the DSS driver also needs to know the maximum divider to be able
to iteratively find good rates, we also need to do the fix in the DSS
driver.

Signed-off-by: Adam Ford 
Cc: Tomi Valkeinen 
Cc: sta...@vger.kernel.org #linux-4.9.y+

diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
index 48c6500c24e1..4429ad37b64c 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
@@ -843,7 +843,7 @@ static const struct dss_features omap34xx_dss_feats = {
  };
  
  static const struct dss_features omap3630_dss_feats = {

-   .fck_div_max=   32,
+   .fck_div_max=   31,
.dss_fck_multiplier =   1,
.parent_clk_name=   "dpll4_ck",
.dpi_select_source  =   &dss_dpi_select_source_omap2_omap3,



Reviewed-by: Tomi Valkeinen 

 Tomi

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

Re: [PATCH 2/6] EDAC/amd64: Gather hardware information early

[Borislav Petkov]

On Fri, Oct 18, 2019 at 03:31:26PM +, Ghannam, Yazen wrote:
> From: Yazen Ghannam 
> 
> Split out gathering hardware information from init_one_instance() into a
> separate function get_hardware_info().
> 
> This is necessary so that the information can be cached earlier and used
> to check if memory is populated and if ECC is enabled on a node.
> 
> Signed-off-by: Yazen Ghannam 
> ---
> Link:
> https://lkml.kernel.org/r/20190821235938.118710-9-yazen.ghan...@amd.com
> 
> rfc -> v1:
> * Fixup after making struct amd64_family_type fam_type global.
> 
>  drivers/edac/amd64_edac.c | 72 +++
>  1 file changed, 42 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index b9a712819c68..4410da7c3a25 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -3416,33 +3416,16 @@ static void compute_num_umcs(void)
>   edac_dbg(1, "Number of UMCs: %x", num_umcs);
>  }
>  
> -static int init_one_instance(unsigned int nid)
> +static int get_hardware_info(struct amd64_pvt *pvt)
>  {
> - struct pci_dev *F3 = node_to_amd_nb(nid)->misc;
> - struct mem_ctl_info *mci = NULL;
> - struct edac_mc_layer layers[2];
> - struct amd64_pvt *pvt = NULL;
>   u16 pci_id1, pci_id2;
> - int err = 0, ret;
> -
> - ret = -ENOMEM;
> - pvt = kzalloc(sizeof(struct amd64_pvt), GFP_KERNEL);
> - if (!pvt)
> - goto err_ret;
> -
> - pvt->mc_node_id = nid;
> - pvt->F3 = F3;
> -
> - ret = -EINVAL;
> - fam_type = per_family_init(pvt);
> - if (!fam_type)
> - goto err_free;
> + int ret = -EINVAL;
>  
>   if (pvt->fam >= 0x17) {
>   pvt->umc = kcalloc(num_umcs, sizeof(struct amd64_umc), 
> GFP_KERNEL);
>   if (!pvt->umc) {
>   ret = -ENOMEM;
> - goto err_free;
> + goto err_ret;
>   }
>  
>   pci_id1 = fam_type->f0_id;
> @@ -3452,18 +3435,33 @@ static int init_one_instance(unsigned int nid)
>   pci_id2 = fam_type->f2_id;
>   }
>  
> - err = reserve_mc_sibling_devs(pvt, pci_id1, pci_id2);
> - if (err)
> + ret = reserve_mc_sibling_devs(pvt, pci_id1, pci_id2);
> + if (ret)
>   goto err_post_init;
>  
>   read_mc_regs(pvt);
>  
> + return 0;
> +
> +err_post_init:
> + if (pvt->fam >= 0x17)
> + kfree(pvt->umc);

So you're freeing pvt->umc here but nothing in that function allocated
it. get_hardware_info() in probe_one_instance() did but if you do it
this way, it is kinda hard to follow and the layering is a bit iffy.

So what I'd suggest is:

* Rename get_hardware_info() to something like hw_info_get() so that
you can have a counterpart hw_info_put() which does any cleanup after
hw_info_get(), including the freeing of the ->umc.

* In probe_one_instance(), if init_one_instance() fails, call
hw_info_put() on the error path so that all your flow in the probe/init
functions is nicely ballanced and easily followed.

Makes sense?

Thx.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] include/linux/byteorder/generic.h: fix signed/unsigned warnings

[Anatol Belski]

Hi,

On Mon, 2019-10-21 at 09:52 +0300, Andy Shevchenko wrote:
> On Sun, Oct 20, 2019 at 05:22:30PM +, Anatol Belski wrote:
> > From: Anatol Belski 
> 
> Better to add commit message even for small patches like this.
> Do you have compiler / sparse / etc warning? Cite it here as well!
> 

yes, it's -Wsign-compare. I'll send a follow up with a better commit
message.

Thanks

Anatol

Re: [PATCH] fbdev/omap: fix max fclk divider for omap36xx

[Tomi Valkeinen]

On 18/10/2019 16:05, Adam Ford wrote:

The OMAP36xx and AM/DM37x TRMs say that the maximum divider for DSS fclk
(in CM_CLKSEL_DSS) is 32. Experimentation shows that this is not
correct, and using divider of 32 breaks DSS with a flood or underflows
and sync losts. Dividers up to 31 seem to work fine.

There is another patch to the DT files to limit the divider correctly,
but as the DSS driver also needs to know the maximum divider to be able
to iteratively find good rates, we also need to do the fix in the DSS
driver.

Signed-off-by: Adam Ford 
Cc: Tomi Valkeinen 
Cc: sta...@vger.kernel.org # linux-4.4.y only

diff --git a/drivers/video/fbdev/omap2/dss/dss.c 
b/drivers/video/fbdev/omap2/dss/dss.c
index 9200a8668b49..a57c3a5f4bf8 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -843,7 +843,7 @@ static const struct dss_features omap34xx_dss_feats = {
  };
  
  static const struct dss_features omap3630_dss_feats = {

-   .fck_div_max=   32,
+   .fck_div_max=   31,
.dss_fck_multiplier =   1,
.parent_clk_name=   "dpll4_ck",
.dpi_select_source  =   &dss_dpi_select_source_omap2_omap3,



To clarify, this patch is only for the v4.4 stable, whereas the previous 
patch was for next merge window and v4.9+ stable. Right?


Reviewed-by: Tomi Valkeinen 

 Tomi

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

Re: [PATCH v4 00/10] sched/fair: rework the CFS load balance

[Vincent Guittot]

On Mon, 21 Oct 2019 at 09:50, Ingo Molnar  wrote:
>
>
> * Vincent Guittot  wrote:
>
> > Several wrong task placement have been raised with the current load
> > balance algorithm but their fixes are not always straight forward and
> > end up with using biased values to force migrations. A cleanup and rework
> > of the load balance will help to handle such UCs and enable to fine grain
> > the behavior of the scheduler for other cases.
> >
> > Patch 1 has already been sent separately and only consolidate asym policy
> > in one place and help the review of the changes in load_balance.
> >
> > Patch 2 renames the sum of h_nr_running in stats.
> >
> > Patch 3 removes meaningless imbalance computation to make review of
> > patch 4 easier.
> >
> > Patch 4 reworks load_balance algorithm and fixes some wrong task placement
> > but try to stay conservative.
> >
> > Patch 5 add the sum of nr_running to monitor non cfs tasks and take that
> > into account when pulling tasks.
> >
> > Patch 6 replaces runnable_load by load now that the signal is only used
> > when overloaded.
> >
> > Patch 7 improves the spread of tasks at the 1st scheduling level.
> >
> > Patch 8 uses utilization instead of load in all steps of misfit task
> > path.
> >
> > Patch 9 replaces runnable_load_avg by load_avg in the wake up path.
> >
> > Patch 10 optimizes find_idlest_group() that was using both runnable_load
> > and load. This has not been squashed with previous patch to ease the
> > review.
> >
> > Patch 11 reworks find_idlest_group() to follow the same steps as
> > find_busiest_group()
> >
> > Some benchmarks results based on 8 iterations of each tests:
> > - small arm64 dual quad cores system
> >
> >tip/sched/corew/ this patchsetimprovement
> > schedpipe  53125 +/-0.18%53443 +/-0.52%   (+0.60%)
> >
> > hackbench -l (2560/#grp) -g #grp
> >  1 groups  1.579 +/-29.16%   1.410 +/-13.46% (+10.70%)
> >  4 groups  1.269 +/-9.69%1.205 +/-3.27%   (+5.00%)
> >  8 groups  1.117 +/-1.51%1.123 +/-1.27%   (+4.57%)
> > 16 groups  1.176 +/-1.76%1.164 +/-2.42%   (+1.07%)
> >
> > Unixbench shell8
> >   1 test 1963.48 +/-0.36%   1902.88 +/-0.73%(-3.09%)
> > 224 tests2427.60 +/-0.20%   2469.80 +/-0.42%  (1.74%)
> >
> > - large arm64 2 nodes / 224 cores system
> >
> >tip/sched/corew/ this patchsetimprovement
> > schedpipe 124084 +/-1.36%   124445 +/-0.67%   (+0.29%)
> >
> > hackbench -l (256000/#grp) -g #grp
> >   1 groups15.305 +/-1.50%   14.001 +/-1.99%   (+8.52%)
> >   4 groups 5.959 +/-0.70%5.542 +/-3.76%   (+6.99%)
> >  16 groups 3.120 +/-1.72%3.253 +/-0.61%   (-4.92%)
> >  32 groups 2.911 +/-0.88%2.837 +/-1.16%   (+2.54%)
> >  64 groups 2.805 +/-1.90%2.716 +/-1.18%   (+3.17%)
> > 128 groups 3.166 +/-7.71%3.891 +/-6.77%   (+5.82%)
> > 256 groups 3.655 +/-10.09%   3.185 +/-6.65%  (+12.87%)
> >
> > dbench
> >   1 groups   328.176 +/-0.29%  330.217 +/-0.32%   (+0.62%)
> >   4 groups   930.739 +/-0.50%  957.173 +/-0.66%   (+2.84%)
> >  16 groups  1928.292 +/-0.36% 1978.234 +/-0.88%   (+0.92%)
> >  32 groups  2369.348 +/-1.72% 2454.020 +/-0.90%   (+3.57%)
> >  64 groups  2583.880 +/-3.39% 2618.860 +/-0.84%   (+1.35%)
> > 128 groups  2256.406 +/-10.67%2392.498 +/-2.13%   (+6.03%)
> > 256 groups  1257.546 +/-3.81% 1674.684 +/-4.97%  (+33.17%)
> >
> > Unixbench shell8
> >   1 test 6944.16 +/-0.02 6605.82 +/-0.11  (-4.87%)
> > 224 tests   13499.02 +/-0.1413637.94 +/-0.47% (+1.03%)
> > lkp reported a -10% regression on shell8 (1 test) for v3 that
> > seems that is partially recovered on my platform with v4.
> >
> > tip/sched/core sha1:
> >   commit 563c4f85f9f0 ("Merge branch 'sched/rt' into sched/core, to pick up 
> > -rt changes")
> >
> > Changes since v3:
> > - small typo and variable ordering fixes
> > - add some acked/reviewed tag
> > - set 1 instead of load for migrate_misfit
> > - use nr_h_running instead of load for asym_packing
> > - update the optimization of find_idlest_group() and put back somes
> >  conditions when comparing load
> > - rework find_idlest_group() to match find_busiest_group() behavior
> >
> > Changes since v2:
> > - fix typo and reorder code
> > - some minor code fixes
> > - optimize the find_idles_group()
> >
> > Not covered in this patchset:
> > - Better detection of overloaded and fully busy state, especially for cases
> >   when nr_running > nr CPUs.
> >
> > Vincent Guittot (11):
> >   sched/fair: clean up asym packing
> >   sched/fair: rename sum_nr_running to sum_h_nr_running
> >   sched/fair: remove meaningless imbalance calculation
> >   sched/fair: rework load_balance
> >   sched/fair: use rq->nr_running when balancing load
> >   sched/fair: use load instead of runnable load in load_balance
> >   sched/fair: evenly spread tasks when not overloaded
> >   sched/fair: use utiliz

Re: [PATCH 0/7] towards QE support on ARM

[Rasmus Villemoes]

On 18/10/2019 23.52, Li Yang wrote:
> On Fri, Oct 18, 2019 at 3:54 PM Rasmus Villemoes
>  wrote:
>>
>> On 18/10/2019 22.16, Leo Li wrote:
>>>

 There have been several attempts in the past few years to allow building 
 the
 QUICC engine drivers for platforms other than PPC. This is (the beginning 
 of)
 yet another attempt. I hope I can get someone to pick up these relatively
 trivial patches (I _think_ they shouldn't change functionality at all), 
 and then
 I'll continue slowly working towards removing the PPC32 dependency for
 CONFIG_QUICC_ENGINE.
>>>
>>> Hi Rasmus,
>>>
>>> I don't fully understand the motivation of this work.  As far as I know the 
>>> QUICC ENGINE is only used on PowerPC based SoCs.
>>
>> Hm, you're not the Leo Li that participated in this thread
>> ?
> 
> Oops, I totally forgot about this discussion which is just three years
> ago.  :)  The QE-HDLC on LS1021a is kind of a special case.
> 
>>
>>
>>  Can you give an example on how is it used on ARM system?
>>
>> LS1021A, for example, which is the one I'm aiming for getting fully
>> supported in mainline.
>> 
>>
>> The forks at https://github.com/qoriq-open-source/linux.git have various
>> degrees of support (grep for commits saying stuff like "remove PPCisms"
>> - some versions can be found on
>> ). Our current kernel is
>> based on commits from the now-vanished 4.1 branch, and unfortunately at
>> least the 4.14 branch (LSDK-18.06-V4.14) trivially doesn't build on ARM,
>> despite the PPC32 dependency having been removed from CONFIG_QUICC_ENGINE.
> 
> Can you try the 4.14 branch from a newer LSDK release?  LS1021a should
> be supported platform on LSDK.  If it is broken, something is wrong.

What newer release? LSDK-18.06-V4.14 is the latest -V4.14 tag at
https://github.com/qoriq-open-source/linux.git, and identical to the
linux-4.14 branch. And despite commit 4c33e2d0576b removing the PPC32
dependency from QUICC_ENGINE, it clearly hasn't been built on arm, since
back around v4.12, mainline's qe.c grew a call to pvr_version_is which
is ppc-only. So from that I sort of assumed that NXP had dropped trying
to support the LS1021A even in their own kernels.

In any case, we have zero interest in running an NXP kernel. Maybe I
should clarify what I meant by "based on commits from" above: We're
currently running a mainline 4.14 kernel on LS1021A, with a few patches
inspired from the NXP 4.1 branch applied on top - but also with some
manual fixes for e.g. the pvr_version_is() issue. Now we want to move
that to a 4.19-based kernel (so that it aligns with our MPC8309 platform).

>> This is just some first few steps, and I'm not claiming
>> that this is sufficient to make the QE drivers build on ARM yet. But I
>> have a customer with both mpc8309-based and ls1021a-based platforms, and
>> they want to run the same, as-close-to-mainline-as-possible, kernel on
>> both. So I will take a piecemeal approach, and try to make sure I don't
>> break the ppc boards in the process (just building and booting one board
>> is of course not sufficient, but better than nothing). Once I get to
>> actually build some of the QE drivers for ARM, I'll of course also test
>> them.
> 
> Understood.  Zhao Qiang also maintains some patches similar to your
> patchset and I think they are tested on ARM.  But the review of these
> patches from last submission didn't finish.  It looks like your
> patches are better divided but not really verified on ARM.  Zhao
> Qiang's patches are tested but maybe need some final touch for
> cleaning up.  I will let you guys decide what is the best approach to
> make this upstreamed.

Yes, as I said, I wanted to try a fresh approach since Zhao
Qiang's patches seemed to be getting nowhere. Splitting the patches into
smaller pieces is definitely part of that - for example, the completely
trivial whitespace fix in patch 1 is to make sure the later coccinelle
generated patch is precisely that (i.e., a later respin can just rerun
the coccinelle script, with zero manual fixups). I also want to avoid
mixing the ppcism cleanups with other things (e.g. replacing some
of_get_property() by of_property_read_u32()). And the "testing on ARM"
part comes once I get to actually building on ARM. But there's not much
point doing all that unless there's some indication that this can be
applied to some tree that actually feeds into Linus', which is why I
started with a few trivial patches and precisely to start this discussion.

Rasmus

Re: [PATCH v2 4/4] KVM: x86/vPMU: Add lazy mechanism to release perf_event per vPMC

[Paolo Bonzini]

On 13/10/19 11:15, Like Xu wrote:
> Currently, a host perf_event is created for a vPMC functionality emulation.
> It’s unpredictable to determine if a disabled perf_event will be reused.
> If they are disabled and are not reused for a considerable period of time,
> those obsolete perf_events would increase host context switch overhead that
> could have been avoided.
> 
> If the guest doesn't access (set_msr/get_msr/rdpmc) any of the vPMC's MSRs
> during an entire vcpu sched time slice, and its independent enable bit of
> the vPMC isn't set, we can predict that the guest has finished the use of
> this vPMC, and then it's time to release non-reused perf_events in the
> first call of vcpu_enter_guest() after the vcpu gets next scheduled in.
> 
> This lazy mechanism delays the event release time to the beginning of the
> next scheduled time slice if vPMC's MSRs aren't accessed during this time
> slice. If guest comes back to use this vPMC in next time slice, a new perf
> event would be re-created via perf_event_create_kernel_counter() as usual.
> 
> Suggested-by: Wei W Wang 
> Signed-off-by: Like Xu 
> ---
>  arch/x86/include/asm/kvm_host.h | 15 
>  arch/x86/kvm/pmu.c  | 43 +
>  arch/x86/kvm/pmu.h  |  3 +++
>  arch/x86/kvm/pmu_amd.c  | 13 ++
>  arch/x86/kvm/vmx/pmu_intel.c| 25 +++
>  arch/x86/kvm/x86.c  | 12 +
>  6 files changed, 111 insertions(+)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 1aae4953..45f9cdae150b 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -472,6 +472,21 @@ struct kvm_pmu {
>   struct kvm_pmc fixed_counters[INTEL_PMC_MAX_FIXED];
>   struct irq_work irq_work;
>   u64 reprogram_pmi;
> +
> + /* for vPMC being set, do not released its perf_event (if any) */
> + u64 lazy_release_ctrl;

Please use DECLARE_BITMAP(lazy_release_ctrl, X86_PMC_IDX_MAX).  I would
also rename the bitmap to pmc_in_use.

I know you're just copying what reprogram_pmi does, but that has to be
fixed too. :)  I'll send a patch now.

> + /*
> +  * The gate to release perf_events not marked in
> +  * lazy_release_ctrl only once in a vcpu time slice.
> +  */
> + bool need_cleanup;
> +
> + /*
> +  * The total number of programmed perf_events and it helps to avoid
> +  * redundant check before cleanup if guest don't use vPMU at all.
> +  */
> + u8 event_count;
>  };
>  
>  struct kvm_pmu_ops;
> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
> index 09d1a03c057c..7ab262f009f6 100644
> --- a/arch/x86/kvm/pmu.c
> +++ b/arch/x86/kvm/pmu.c
> @@ -137,6 +137,7 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, 
> u32 type,
>   }
>  
>   pmc->perf_event = event;
> + pmc_to_pmu(pmc)->event_count++;
>   clear_bit(pmc->idx, (unsigned long*)&pmc_to_pmu(pmc)->reprogram_pmi);
>  }
>  
> @@ -368,6 +369,7 @@ int kvm_pmu_rdpmc(struct kvm_vcpu *vcpu, unsigned idx, 
> u64 *data)
>   if (!pmc)
>   return 1;
>  
> + __set_bit(pmc->idx, (unsigned long *)&pmu->lazy_release_ctrl);
>   *data = pmc_read_counter(pmc) & mask;
>   return 0;
>  }
> @@ -385,11 +387,13 @@ bool kvm_pmu_is_valid_msr(struct kvm_vcpu *vcpu, u32 
> msr)
>  
>  int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *data)
>  {
> + kvm_x86_ops->pmu_ops->update_lazy_release_ctrl(vcpu, msr);

Instead of this new pmu_ops entry, please introduce two separate patches
to do the following:

1) rename the existing msr_idx_to_pmc to rdpmc_idx_to_pmc, and
is_valid_msr_idx to is_valid_rdpmc_idx (likewise for
kvm_pmu_is_valid_msr_idx).

2) introduce a new callback msr_idx_to_pmc that returns a struct
kvm_pmc*, and change kvm_pmu_is_valid_msr to do

bool kvm_pmu_is_valid_msr(struct kvm_vcpu *vcpu, u32 msr)
{
return (kvm_x86_ops->pmu_ops->msr_idx_to_pmc(vcpu, msr) ||
kvm_x86_ops->pmu_ops->is_valid_msr(vcpu, msr));
}

and AMD can just return false from .is_valid_msr.

Once this change is done, this patch can use simply:

static int kvm_pmu_mark_pmc_in_use(struct kvm_vcpu *vcpu, u32 msr)
{
struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
struct kvm_pmc *pmc = kvm_x86_ops->pmu_ops->msr_idx_to_pmc(vcpu, msr);
__set_bit(pmc->idx, pmu->pmc_in_use);
}

>   return kvm_x86_ops->pmu_ops->get_msr(vcpu, msr, data);
>  }
>  
>  int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>  {
> + kvm_x86_ops->pmu_ops->update_lazy_release_ctrl(vcpu, msr_info->index);
>   return kvm_x86_ops->pmu_ops->set_msr(vcpu, msr_info);
>  }
>  
> @@ -417,9 +421,48 @@ void kvm_pmu_init(struct kvm_vcpu *vcpu)
>   memset(pmu, 0, sizeof(*pmu));
>   kvm_x86_ops->pmu_ops->init(vcpu);
>   init_irq_work(&pmu->irq_work, kvm_pmi_trigger_fn);
> + pmu->lazy_release_ctrl = 0;
> + pmu->event_count = 0;
> + pmu->need_cl

[PATCH v2 1/4] dt-bindings: Add doc about rk3308 General Register Files

[Andy Yan]

RK3308 GRF is divided into four sections: GRF, SGRF,
DETECTGRF, COREGRF. This patch add documentation for
it.

Signed-off-by: Andy Yan 

---

Changes in v2: None

 .../devicetree/bindings/soc/rockchip/grf.txt  | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt 
b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
index d7debec26ba4..61d89749918a 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
@@ -10,6 +10,12 @@ From RK3368 SoCs, the GRF is divided into two sections,
 
 On RK3328 SoCs, the GRF adds a section for USB2PHYGRF,
 
+ON RK3308 SoC, the GRF is divided into four sections:
+- GRF, used for general non-secure system,
+- SGRF, used for general secure system,
+- DETECTGRF, used for audio codec system,
+- COREGRF, used for pvtm,
+
 Required Properties:
 
 - compatible: GRF should be one of the following:
@@ -19,10 +25,15 @@ Required Properties:
- "rockchip,rk3188-grf", "syscon": for rk3188
- "rockchip,rk3228-grf", "syscon": for rk3228
- "rockchip,rk3288-grf", "syscon": for rk3288
+   - "rockchip,rk3308-grf", "syscon": for rk3308
- "rockchip,rk3328-grf", "syscon": for rk3328
- "rockchip,rk3368-grf", "syscon": for rk3368
- "rockchip,rk3399-grf", "syscon": for rk3399
- "rockchip,rv1108-grf", "syscon": for rv1108
+- compatible: DETECTGRF should be one of the following:
+   - "rockchip,rk3308-detect-grf", "syscon": for rk3308
+- compatilbe: COREGRF should be one of the following:
+   - "rockchip,rk3308-core-grf", "syscon": for rk3308
 - compatible: PMUGRF should be one of the following:
- "rockchip,px30-pmugrf", "syscon": for px30
- "rockchip,rk3368-pmugrf", "syscon": for rk3368
-- 
2.17.1

Re: WARNING in check_corruption

[Dmitry Vyukov]

On Fri, Oct 18, 2019 at 4:13 PM syzbot
 wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:8ada228a Add linux-next specific files for 20191011
> git tree:   linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=144265ab60
> kernel config:  https://syzkaller.appspot.com/x/.config?x=7cf4eed5fe42c31a
> dashboard link: https://syzkaller.appspot.com/bug?extid=2e88d23c0143e90d8303
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1249ad80e0
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13ca6de760

syzkaller managed to write to /dev/mem.
https://github.com/google/syzkaller/commit/ef4a2149feeadf5833638d9b6ec3e53cb8dfd39d
disables CONFIG_DEVMEM and CONFIG_DEVKMEM is syzbot config.

#syz invalid


> Bisection is inconclusive: the bug happens on the oldest tested release.
>
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=158d26d760
> final crash:https://syzkaller.appspot.com/x/report.txt?x=178d26d760
> console output: https://syzkaller.appspot.com/x/log.txt?x=138d26d760
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+2e88d23c0143e90d8...@syzkaller.appspotmail.com
>
> check: Corrupted low memory at b9a95c9f (2900 phys) = 00e8
> [ cut here ]
> Memory corruption detected in low memory
> WARNING: CPU: 0 PID: 3473 at arch/x86/kernel/check.c:161
> check_for_bios_corruption arch/x86/kernel/check.c:161 [inline]
> WARNING: CPU: 0 PID: 3473 at arch/x86/kernel/check.c:161
> check_corruption+0x159/0x1fc arch/x86/kernel/check.c:169
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 0 PID: 3473 Comm: kworker/0:2 Not tainted 5.4.0-rc2-next-20191011 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events check_corruption
> Call Trace:
>   __dump_stack lib/dump_stack.c:77 [inline]
>   dump_stack+0x172/0x1f0 lib/dump_stack.c:113
>   panic+0x2e3/0x75c kernel/panic.c:221
>   __warn.cold+0x2f/0x35 kernel/panic.c:582
>   report_bug+0x289/0x300 lib/bug.c:195
>   fixup_bug arch/x86/kernel/traps.c:174 [inline]
>   fixup_bug arch/x86/kernel/traps.c:169 [inline]
>   do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
>   do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
>   invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028
> RIP: 0010:check_for_bios_corruption arch/x86/kernel/check.c:161 [inline]
> RIP: 0010:check_corruption+0x159/0x1fc arch/x86/kernel/check.c:169
> Code: 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 80 3d 8b 00 90 08 00 75 a2
> 48 c7 c7 e0 6b a8 87 c6 05 7b 00 90 08 01 e8 af 0b 12 00 <0f> 0b eb 8b 48
> 89 df 89 55 d0 e8 88 45 7c 00 8b 55 d0 e9 4e ff ff
> RSP: 0018:88809c8d7cf8 EFLAGS: 00010286
> RAX:  RBX: 8881 RCX: 
> RDX:  RSI: 815cb3a6 RDI: ed101391af91
> RBP: 88809c8d7d30 R08: 88809c8e2080 R09: ed1015d06161
> R10: ed1015d06160 R11: 8880ae830b07 R12: 8881
> R13: 0001 R14: dc00 R15: 8880
>   process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
>   worker_thread+0x98/0xe40 kernel/workqueue.c:2415
>   kthread+0x361/0x430 kernel/kthread.c:255
>   ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/syzkaller-bugs/eed19705952fee5a%40google.com.

[PATCH v2 3/4] dt-bindings: Add doc for rk3308-evb

[Andy Yan]

Add compatible for RK3308 Evaluation board

Signed-off-by: Andy Yan 

---

Changes in v2:
- Split with the dts file

 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index c82c5e57d44c..b680c4b8b2c9 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -447,6 +447,11 @@ properties:
   - const: rockchip,r88
   - const: rockchip,rk3368
 
+  - description: Rockchip RK3308 Evaluation board
+items:
+  - const: rockchip,rk3308-evb
+  - const: rockchip,rk3308
+
   - description: Rockchip RK3228 Evaluation board
 items:
   - const: rockchip,rk3228-evb
-- 
2.17.1

[PATCH v2 4/4] arm64: dts: rockchip: Add basic dts for RK3308 EVB

[Andy Yan]

This board use uart4 as debug port and arm core voltage
is modulated by pwm, logic voltage is fixed to 1.05V.

Signed-off-by: Andy Yan 

---

Changes in v2:
- Split binding to a separate patch
- Power tree update.

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3308-evb.dts | 230 
 2 files changed, 231 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3308-evb.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index 1f18a9392d15..a959434ad46e 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3308-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3308-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3308-evb.dts
new file mode 100644
index ..124a24086684
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3308-evb.dts
@@ -0,0 +1,230 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ */
+
+/dts-v1/;
+#include 
+#include "rk3308.dtsi"
+
+/ {
+   model = "Rockchip RK3308 EVB";
+   compatible = "rockchip,rk3308-evb", "rockchip,rk3308";
+
+   chosen {
+   stdout-path = "serial4:150n8";
+   };
+
+   adc-keys0 {
+   compatible = "adc-keys";
+   io-channels = <&saradc 0>;
+   io-channel-names = "buttons";
+   poll-interval = <100>;
+   keyup-threshold-microvolt = <180>;
+
+   func-key {
+   linux,code = ;
+   label = "function";
+   press-threshold-microvolt = <18000>;
+   };
+   };
+
+   adc-keys1 {
+   compatible = "adc-keys";
+   io-channels = <&saradc 1>;
+   io-channel-names = "buttons";
+   poll-interval = <100>;
+   keyup-threshold-microvolt = <180>;
+
+   esc-key {
+   linux,code = ;
+   label = "micmute";
+   press-threshold-microvolt = <113>;
+   };
+
+   home-key {
+   linux,code = ;
+   label = "mode";
+   press-threshold-microvolt = <901000>;
+   };
+
+   menu-key {
+   linux,code = ;
+   label = "play";
+   press-threshold-microvolt = <624000>;
+   };
+
+   vol-down-key {
+   linux,code = ;
+   label = "volume down";
+   press-threshold-microvolt = <30>;
+   };
+
+   vol-up-key {
+   linux,code = ;
+   label = "volume up";
+   press-threshold-microvolt = <18000>;
+   };
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   autorepeat;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&pwr_key>;
+
+   power {
+   gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "GPIO Key Power";
+   wakeup-source;
+   debounce-interval = <100>;
+   };
+   };
+
+   vcc12v_dcin: vcc12v-dcin {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc12v_dcin";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   vcc5v0_sys: vcc5v0-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <&vcc12v_dcin>;
+   };
+
+   vdd_core: vdd-core {
+   compatible = "pwm-regulator";
+   pwms = <&pwm0 0 5000 1>;
+   regulator-name = "vdd_core";
+   regulator-min-microvolt = <827000>;
+   regulator-max-microvolt = <134>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-settling-time-up-us = <250>;
+   pwm-supply = <&vcc5v0_sys>;
+   };
+
+   vdd_log: vdd-log {
+   compatible = "regulator-fixed";
+   regulator-name = "vdd_log";
+   regulator-always-on;
+

Re: [PATCH] fs/dax: Fix pmd vs pte conflict detection

[Jan Kara]

On Sat 19-10-19 09:26:19, Dan Williams wrote:
> Check for NULL entries before checking the entry order, otherwise NULL
> is misinterpreted as a present pte conflict. The 'order' check needs to
> happen before the locked check as an unlocked entry at the wrong order
> must fallback to lookup the correct order.
> 
> Reported-by: Jeff Smits 
> Reported-by: Doug Nelson 
> Cc: 
> Fixes: 23c84eb78375 ("dax: Fix missed wakeup with PMD faults")
> Cc: Jan Kara 
> Cc: Matthew Wilcox (Oracle) 
> Signed-off-by: Dan Williams 

Good catch! The patch looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  fs/dax.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index a71881e77204..08160011d94c 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -221,10 +221,11 @@ static void *get_unlocked_entry(struct xa_state *xas, 
> unsigned int order)
>  
>   for (;;) {
>   entry = xas_find_conflict(xas);
> + if (!entry || WARN_ON_ONCE(!xa_is_value(entry)))
> + return entry;
>   if (dax_entry_order(entry) < order)
>   return XA_RETRY_ENTRY;
> - if (!entry || WARN_ON_ONCE(!xa_is_value(entry)) ||
> - !dax_is_locked(entry))
> + if (!dax_is_locked(entry))
>   return entry;
>  
>   wq = dax_entry_waitqueue(xas, entry, &ewait.key);
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH v4 03/16] x86/alternatives,jump_label: Provide better text_poke() batching interface

[Ingo Molnar]

* Peter Zijlstra  wrote:

> --- a/arch/x86/kernel/jump_label.c
> +++ b/arch/x86/kernel/jump_label.c
> @@ -35,18 +35,19 @@ static void bug_at(unsigned char *ip, in
>   BUG();
>  }
>  
> -static void __jump_label_set_jump_code(struct jump_entry *entry,
> -enum jump_label_type type,
> -union jump_code_union *code,
> -int init)
> +static const void *
> +__jump_label_set_jump_code(struct jump_entry *entry, enum jump_label_type 
> type, int init)
>  {
> + static union jump_code_union code; /* relies on text_mutex */
>   const unsigned char default_nop[] = { STATIC_KEY_INIT_NOP };
>   const unsigned char *ideal_nop = ideal_nops[NOP_ATOMIC5];
>   const void *expect;
>   int line;
>  
> - code->jump = 0xe9;
> - code->offset = jump_entry_target(entry) -
> + lockdep_assert_held(&text_mutex);
> +
> + code.jump = JMP32_INSN_OPCODE;
> + code.offset = jump_entry_target(entry) -
>  (jump_entry_code(entry) + JUMP_LABEL_NOP_SIZE);
>  
>   if (init) {
> @@ -54,23 +55,23 @@ static void __jump_label_set_jump_code(s
>   } else if (type == JUMP_LABEL_JMP) {
>   expect = ideal_nop; line = __LINE__;
>   } else {
> - expect = code->code; line = __LINE__;
> + expect = code.code; line = __LINE__;

Side note: the whole 'line' logic looked weird to me and it obsfuscates 
the logic a bit, and I had to look it up to see what it's about: 
improving the debug output of text-patching crashes.

How about something like the below on top of your queue? We have %phD 
that can nicely print instructions in hex.

Totally untested though.

Thanks,

Ingo

---
 arch/x86/kernel/jump_label.c |   21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

Index: tip/arch/x86/kernel/jump_label.c
===
--- tip.orig/arch/x86/kernel/jump_label.c
+++ tip/arch/x86/kernel/jump_label.c
@@ -16,14 +16,15 @@
 #include 
 #include 
 
-static void bug_at(const void *ip, int line)
+static void bug_at(const void *ip, const void *op_expected, const void 
*op_unexpected)
 {
/*
 * The location is not an op that we were expecting.
 * Something went wrong. Crash the box, as something could be
 * corrupting the kernel.
 */
-   pr_crit("jump_label: Fatal kernel bug, unexpected op at %pS [%p] (%5ph) 
%d\n", ip, ip, ip, line);
+   pr_crit("jump_label: Fatal kernel bug, expected op (%*phD), unexpected 
op (%*phD) at %pS [%p] (%5ph\n",
+   JUMP_LABEL_NOP_SIZE, op_expected, JUMP_LABEL_NOP_SIZE, 
op_unexpected, ip, ip, ip);
BUG();
 }
 
@@ -34,23 +35,21 @@ __jump_label_set_jump_code(struct jump_e
const unsigned char *ideal_nop = ideal_nops[NOP_ATOMIC5];
const void *expect, *code;
const void *addr, *dest;
-   int line;
 
addr = (void *)jump_entry_code(entry);
dest = (void *)jump_entry_target(entry);
 
code = text_gen_insn(JMP32_INSN_OPCODE, addr, dest);
 
-   if (init) {
-   expect = default_nop; line = __LINE__;
-   } else if (type == JUMP_LABEL_JMP) {
-   expect = ideal_nop; line = __LINE__;
-   } else {
-   expect = code; line = __LINE__;
-   }
+   if (init)
+   expect = default_nop;
+   else if (type == JUMP_LABEL_JMP)
+   expect = ideal_nop;
+   else
+   expect = code;
 
if (memcmp(addr, expect, JUMP_LABEL_NOP_SIZE))
-   bug_at(addr, line);
+   bug_at(addr, expect, addr);
 
if (type == JUMP_LABEL_NOP)
code = ideal_nop;

[PATCH v2 0/4] Add basic dts support for RK3308

[Andy Yan]

RK3308 is a quad Cortex A35 based SOC with rich audio
interfaces(I2S/PCM/TDM/PDM/SPDIF/VAD/HDMI ARC), which
designed for intelligent voice interaction and audio
input/output processing.

As the clk and pinctrl drivers are landed, we post
the basic dts support, make it convenient for other
module development.

Changes in v2:
- Address Heiko's comments in V1
- Split with the dts file
- Split binding to a separate patch
- Power tree update.

Andy Yan (4):
  dt-bindings: Add doc about rk3308 General Register Files
  arm64: dts: rockchip: Add core dts for RK3308 SOC
  dt-bindings: Add doc for rk3308-evb
  arm64: dts: rockchip: Add basic dts for RK3308 EVB

 .../devicetree/bindings/arm/rockchip.yaml |5 +
 .../devicetree/bindings/soc/rockchip/grf.txt  |   11 +
 arch/arm64/boot/dts/rockchip/Makefile |1 +
 arch/arm64/boot/dts/rockchip/rk3308-evb.dts   |  230 +++
 arch/arm64/boot/dts/rockchip/rk3308.dtsi  | 1838 +
 5 files changed, 2085 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3308-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3308.dtsi

-- 
2.17.1

Re: [RFC 2/2] vhost: IFC VF vdpa layer

[Zhu, Lingshan]

On 10/16/2019 5:53 PM, Simon Horman wrote:

Hi Zhu,

thanks for your patch.

On Wed, Oct 16, 2019 at 09:03:18AM +0800, Zhu Lingshan wrote:

This commit introduced IFC VF operations for vdpa, which complys to
vhost_mdev interfaces, handles IFC VF initialization,
configuration and removal.

Signed-off-by: Zhu Lingshan 
---
  drivers/vhost/ifcvf/ifcvf_main.c | 541 +++
  1 file changed, 541 insertions(+)
  create mode 100644 drivers/vhost/ifcvf/ifcvf_main.c

diff --git a/drivers/vhost/ifcvf/ifcvf_main.c b/drivers/vhost/ifcvf/ifcvf_main.c
new file mode 100644
index ..c48a29969a85
--- /dev/null
+++ b/drivers/vhost/ifcvf/ifcvf_main.c
@@ -0,0 +1,541 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ifcvf_base.h"
+
+#define VERSION_STRING "0.1"
+#define DRIVER_AUTHOR  "Intel Corporation"
+#define IFCVF_DRIVER_NAME  "ifcvf"
+
+static irqreturn_t ifcvf_intr_handler(int irq, void *arg)
+{
+   struct vring_info *vring = arg;
+
+   if (vring->cb.callback)
+   return vring->cb.callback(vring->cb.private);
+
+   return IRQ_HANDLED;
+}
+
+static u64 ifcvf_mdev_get_features(struct mdev_device *mdev)
+{
+   return IFC_SUPPORTED_FEATURES;
+}
+
+static int ifcvf_mdev_set_features(struct mdev_device *mdev, u64 features)
+{
+   struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+   struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);

Perhaps a helper that takes a struct mdev_device would be useful.
The pattern above seems to be repeated many times.


Hi Simon, thanks a lot for your comments.

sure, can do




+
+   vf->req_features = features;
+
+   return 0;
+}
+
+static u64 ifcvf_mdev_get_vq_state(struct mdev_device *mdev, u16 qid)
+{
+   struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+   struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+   return vf->vring[qid].last_avail_idx;
+}
+
+static int ifcvf_mdev_set_vq_state(struct mdev_device *mdev, u16 qid, u64 num)
+{
+   struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+   struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+   vf->vring[qid].last_used_idx = num;
+   vf->vring[qid].last_avail_idx = num;
+
+   return 0;
+}
+
+static int ifcvf_mdev_set_vq_address(struct mdev_device *mdev, u16 idx,
+u64 desc_area, u64 driver_area,
+u64 device_area)
+{
+   struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+   struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+   vf->vring[idx].desc = desc_area;
+   vf->vring[idx].avail = driver_area;
+   vf->vring[idx].used = device_area;
+
+   return 0;
+}
+
+static void ifcvf_mdev_set_vq_num(struct mdev_device *mdev, u16 qid, u32 num)
+{
+   struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+   struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+   vf->vring[qid].size = num;
+}
+
+static void ifcvf_mdev_set_vq_ready(struct mdev_device *mdev,
+   u16 qid, bool ready)

u16 should be vertically whitespace aligned with struct mdev_device.


+{
+
+   struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+   struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+   vf->vring[qid].ready = ready;
+}
+
+static bool ifcvf_mdev_get_vq_ready(struct mdev_device *mdev, u16 qid)
+{
+
+   struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+   struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+   return vf->vring[qid].ready;
+}
+
+static void ifcvf_mdev_set_vq_cb(struct mdev_device *mdev, u16 idx,
+struct virtio_mdev_callback *cb)
+{
+   struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+   struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+   vf->vring[idx].cb = *cb;
+}
+
+static void ifcvf_mdev_kick_vq(struct mdev_device *mdev, u16 idx)
+{
+   struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+   struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+   ifcvf_notify_queue(vf, idx);
+}
+
+static u8 ifcvf_mdev_get_status(struct mdev_device *mdev)
+{
+   struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+   struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+   return vf->status;
+}
+
+static u32 ifcvf_mdev_get_generation(struct mdev_device *mdev)
+{
+   struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+   struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+   return vf->generation;
+}
+
+static int ifcvf_mdev_get_version(struct mdev_device *mdev)
+{
+   return VIRTIO_MDEV_VERSION;
+}
+
+static u32 ifcvf_mdev_get_device_id(struct mdev_device *mdev)
+{
+   return IFCVF_DEVICE_ID;
+}
+
+static u32 ifcvf_mdev_get_vendor_id(struct mdev_device *mdev)
+{
+   return IFCVF_VENDOR_ID;
+}
+
+static u16 ifcvf_mdev_get

Re: [PATCH] arm64: kprobes: Drop open-coded exception fixup

[Masami Hiramatsu]

Hi Robin,

On Thu, 17 Oct 2019 16:31:42 +0100
Robin Murphy  wrote:

> The short-circuit call to fixup_exception() from kprobe_fault_handler()
> poses a problem now that the former wants to consume the fault address
> too, since the common kprobes API offers us no way to pass it through.
> Fortunately, however, it works out to be unnecessary:

Thank you for pointing it out!

> 
> - uaccess instructions themselves are not probeable, so at most we
>   should only ever expect to take a fixable fault from the pre or post
>   handlers.

Right. If it is not fixable, we should handle it as a kernel bug.
(to avoid it we can use probe_kernel_read() in kprobe handler)

> - the pre and post handler run with preemption disabled, thus for any
>   fault they may cause, an unhandled return from kprobe_page_fault()
>   will proceed directly to __do_kernel_fault() thanks to the
>   faulthandler_disabled() check.

OK, this is reasonable.

> - __do_kernel_fault() will immediately call fixup_exception() unless
>   we're in an EL1 instruction abort, and if we've somehow taken one of
>   those on what we think is the middle of a uaccess routine, then the
>   world is already very on fire.

OK, this looks good to me.

Reviewed-by: Masami Hiramatsu 

Thank you!

> 
> Thus we can reasonably drop the call from kprobe_fault_handler() and
> leave uaccess fixups to the regular flow.
> 
> Signed-off-by: Robin Murphy 
> ---
>  arch/arm64/kernel/probes/kprobes.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/arch/arm64/kernel/probes/kprobes.c 
> b/arch/arm64/kernel/probes/kprobes.c
> index c4452827419b..422fbd5c6c55 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -334,13 +334,6 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, 
> unsigned int fsr)
>*/
>   if (cur->fault_handler && cur->fault_handler(cur, regs, fsr))
>   return 1;
> -
> - /*
> -  * In case the user-specified fault handler returned
> -  * zero, try to fix up.
> -  */
> - if (fixup_exception(regs))
> - return 1;
>   }
>   return 0;
>  }
> -- 
> 2.21.0.dirty
> 


-- 
Masami Hiramatsu 

[PATCH v2 2/4] arm64: dts: rockchip: Add core dts for RK3308 SOC

[Andy Yan]

RK3308 is a quad Cortex A35 based SOC with rich audio
interfaces(I2S/PCM/TDM/PDM/SPDIF/VAD/HDMI ARC), which
designed for intelligent voice interaction and audio
input/output processing.

This patch add basic core dtsi file for it.

Signed-off-by: Andy Yan 

---

Changes in v2:
- Address Heiko's comments in V1

 arch/arm64/boot/dts/rockchip/rk3308.dtsi | 1838 ++
 1 file changed, 1838 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3308.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
new file mode 100644
index ..c38acc7dd275
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
@@ -0,0 +1,1838 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "rockchip,rk3308";
+
+   interrupt-parent = <&gic>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   i2c0 = &i2c0;
+   i2c1 = &i2c1;
+   i2c2 = &i2c2;
+   i2c3 = &i2c3;
+   serial0 = &uart0;
+   serial1 = &uart1;
+   serial2 = &uart2;
+   serial3 = &uart3;
+   serial4 = &uart4;
+   spi0 = &spi0;
+   spi1 = &spi1;
+   spi2 = &spi2;
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a35", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   clocks = <&cru ARMCLK>;
+   #cooling-cells = <2>;
+   dynamic-power-coefficient = <90>;
+   operating-points-v2 = <&cpu0_opp_table>;
+   cpu-idle-states = <&CPU_SLEEP>;
+   next-level-cache = <&l2>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a35", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   operating-points-v2 = <&cpu0_opp_table>;
+   cpu-idle-states = <&CPU_SLEEP>;
+   next-level-cache = <&l2>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a35", "arm,armv8";
+   reg = <0x0 0x2>;
+   enable-method = "psci";
+   operating-points-v2 = <&cpu0_opp_table>;
+   cpu-idle-states = <&CPU_SLEEP>;
+   next-level-cache = <&l2>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a35", "arm,armv8";
+   reg = <0x0 0x3>;
+   enable-method = "psci";
+   operating-points-v2 = <&cpu0_opp_table>;
+   cpu-idle-states = <&CPU_SLEEP>;
+   next-level-cache = <&l2>;
+   };
+
+   idle-states {
+   entry-method = "psci";
+
+   CPU_SLEEP: cpu-sleep {
+   compatible = "arm,idle-state";
+   local-timer-stop;
+   arm,psci-suspend-param = <0x001>;
+   entry-latency-us = <120>;
+   exit-latency-us = <250>;
+   min-residency-us = <900>;
+   };
+   };
+
+   l2: l2-cache {
+   compatible = "cache";
+   };
+   };
+
+   cpu0_opp_table: cpu0-opp-table {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-40800 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <95 95 134>;
+   clock-latency-ns = <4>;
+   opp-suspend;
+   };
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <95 95 134>;
+   clock-latency-ns = <4>;
+   };
+   opp-81600 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <1025000 1025000 134>;
+   clock-latency-ns = <4>;
+   };
+   opp-100800 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-mic

[PATCH v2] KVM: remove redundant code in kvm_arch_vm_ioctl

[Miaohe Lin]

If we reach here with r = 0, we will reassign r = 0
unnecesarry, then do the label set_irqchip_out work.
If we reach here with r != 0, then we will do the label
work directly. So this if statement and r = 0 assignment
is redundant. We remove them and therefore we can get rid
of odd set_irqchip_out lable further pointed out by tglx.

Signed-off-by: Miaohe Lin 
---
 arch/x86/kvm/x86.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 661e2bf38526..cd4ca8c2f7de 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4913,13 +4913,8 @@ long kvm_arch_vm_ioctl(struct file *filp,
}
 
r = -ENXIO;
-   if (!irqchip_kernel(kvm))
-   goto set_irqchip_out;
-   r = kvm_vm_ioctl_set_irqchip(kvm, chip);
-   if (r)
-   goto set_irqchip_out;
-   r = 0;
-   set_irqchip_out:
+   if (irqchip_kernel(kvm))
+   r = kvm_vm_ioctl_set_irqchip(kvm, chip);
kfree(chip);
break;
}
-- 
2.19.1

linux-kernel@vger.kernel.org

[zhuguangqing83]

From: zhuguangqing 

After commit 00ee22c28915 (PM / wakeup: Use seq_open()
to show wakeup stats), print_wakeup_source_stats(m, &deleted_ws)
is deleted in function wakeup_sources_stats_seq_show().

Because deleted_ws is one of wakeup sources, so it should
also be showed. This patch add it to the end of all other
wakeup sources.

Signed-off-by: zhuguangqing 
---
 drivers/base/power/wakeup.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index 5817b51d2b15..29e9434ccaaa 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -1071,6 +1071,9 @@ static void *wakeup_sources_stats_seq_next(struct 
seq_file *m,
break;
}
 
+   if (&ws->entry == &wakeup_sources)
+   print_wakeup_source_stats(m, &deleted_ws);
+
return next_ws;
 }
 
-- 
2.17.1

Re: [PATCH v1 1/5] staging: wfx: fix warnings of no space is necessary

[Joe Perches]

On Mon, 2019-10-21 at 08:52 +0200, Julia Lawall wrote:
> > btw2:
> > 
> > I really dislike all the code inconsistencies and
> > unnecessary code duplication with miscellaneous changes
> > in the rtl staging drivers
> > 
> > Horrid stuff.
> 
> I'm not sure what you mean by "miscellaneous changes".  Do you mean that
> all issues should be fixed for one file before moving on to another one?
> 
> Or that there are code clones, and all of the clones should be updated at
> the same time?

Neither really.

But realtek drivers are basically code clones where
realtek should prefer to have a single library used
for multiple drivers.

And staging is basically a dumping ground for realtek
wireless drivers.

https://lkml.org/lkml/2019/5/15/1405

Re: [PATCH RFC v2 2/2] USB: ldusb: fix ring-buffer locking

[Johan Hovold]

On Fri, Oct 18, 2019 at 11:54:58AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Oct 18, 2019 at 05:19:55PM +0200, Johan Hovold wrote:
> > The custom ring-buffer implementation was merged without any locking
> > whatsoever, but a spinlock was later added by commit 9d33efd9a791
> > ("USB: ldusb bugfix").
> > 
> > The lock did not cover the loads from the ring-buffer entry after
> > determining the buffer was non-empty, nor the update of the tail index
> > once the entry had been processed. The former could lead to stale data
> > being returned, while the latter could lead to memory corruption on
> > sufficiently weakly ordered architectures.
> 
> Ugh.
> 
> This almost looks sane, but what's the odds there is some other issue in
> here as well?  Would it make sense to just convert the code to use the
> "standard" ring buffer code instead?

Yeah, long term that may be the right thing to do, but I wanted a
minimal fix addressing the issue at hand without having to reimplement
the driver and fix all other (less-critical) issues in there...

For the ring-buffer corruption / info-leak issue, these two patches
should be sufficient though.

Copying the ring-buffer entry to a temporary buffer while holding the
lock might still be preferred to avoid having to deal with barrier
subtleties. But unless someone speaks out against 2/2, I'd just go ahead
and apply it.

Johan

Re: [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function

[Boris Brezillon]

On Mon, 21 Oct 2019 16:40:57 +0800
masonccy...@mxic.com.tw wrote:

> Hi Boris,
> 
>  
> > > > > > > Then fill-in these two hooks from the manufacturer code,   
> without 
> > > the  
> > > > > > > postponed init.
> > > > > > >   
> > > > > > 
> > > > > > But in the final of nand_scan_tail(), mtd->_lock/_unlock will be
> > > > > > filled by NULL, right ?   
> > > > > 
> > > > > The NAND core should set mtd->_lock/_unlock() to NAND specific   
> hooks 
> > > so  
> > > > > that the MTD layer is abstracted and and drivers do not see it.   
> Then,
> > > > > in the NAND helper, either there is no specific hook defined by a
> > > > > manufacturer driver and you return -ENOTSUPP, or you execute the
> > > > > defined hook.   
> > > > 
> > > > okay, patch specific manufacturer _lock/_unlock driver
> > > > in nand_manufacturer_init();
> > > > 
> > > > and in the final of nand_scan_tail()
> > > > if (!mtd->_lock)
> > > >  mtd->_lock = NULL;
> > > > if (!mtd->_unlock)
> > > >  mtd->_unlock = NULL;   
> > > 
> > > 
> > > I'm still considering of post_init() in nand_scan_tail() for
> > > MTD layer default call-back function replacement because
> > > there would be more call-back functions need it.
> > > i.e., 
> > > MTD->_lock/_unlokc
> > > MTD->_suspend/_resume  
> > 
> > Again, that's something that needs to be abstracted so that both the
> > NAND manufacturer driver and the NAND controller driver can take
> > appropriate actions on suspend/resume operations.
> >   
> > > NTD->_point/_unpoint  
> >   
> > ->_point/_unpoint() are irrelevant for a NAND chip.  
> >   
> > > ...
> > > 
> > > 
> > > actually, my patch series are including MTD->_locl/_unlock and 
> > > MTD->_suspend/_resume. how do you think ?  
> > 
> > Miquel was suggesting to add nand_chip->{lock,unlock,is_locked}()
> > methods that would be implemented by the NAND manufacturer drivers, and
> > have generic wrappers implemented in nand_base.c:
> > 
> > static int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> > {
> >struct nand_chip *chip = mtd_to_nand(mtd);
> > 
> >if (!chip->lock)
> >   return -ENOTSUPP;
> > 
> >return chip->lock(chip, ofs, len);
> > }
> > 
> > ...
> > 
> > If you do that, you won't need this post_init() hook.  
> 
> got it, but ... 
> user space program flash_lock/flash_unlock are calling 
> mtd_lock() & mtd_unlock().
> i.e.,
> int mtd_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> {
>  if (!mtd->_lock)
>  return -EOPNOTSUPP;
>  if (ofs < 0 || ofs >= mtd->size || len > mtd->size - ofs)
>  return -EINVAL;
>  if (!len)
>  return 0;
>  return mtd->_lock(mtd, ofs, len);
> }
> 

Assign mtd lock/unlock/is_locked hooks to the generic wrappers in
nand_scan_tail():

mtd->_lock = nand_lock;
mtd->_unlock = nand_unlock;
mtd->_is_locked = nand_is_locked;

Seriously, we've almost implemented the thing for you with all the
details we've given. At some point you have to look more closely at how
things are done/designed in the NAND framework if you want to
contribute core changes. I'm fine giving hints but we're far beyond
that point here.

Re: [PATCH] KVM: remove redundant code in kvm_arch_vm_ioctl

[Paolo Bonzini]

On 21/10/19 10:16, Thomas Gleixner wrote:
> Can you please get rid of that odd jump label completely?
> 
>   if (irqchip_kernel(kvm))
>   r = kvm_vm_ioctl_set_irqchip(kvm, chip);

Keeping the label has the advantage of making the get and set cases a
bit more similar (the get case has to do a copy_to_user after
kvm_vm_ioctl_get_irqchip returns).  Unfortunately struct kvm_irqchip is
quite big (520 bytes) so we don't allocate it on the stack.

So I queued Miaohe's patch.

Paolo

Re: [PATCH 0/7] add support for clocksource/clockevent DT selection

[Claudiu.Beznea]

Hi Daniel,

On 18.10.2019 23:24, Daniel Lezcano wrote:
> Hi Claudiu,
> 
> On 15/10/2019 11:23, claudiu.bez...@microchip.com wrote:
> 
> [ ... ]
> 
>> The timer clock source could be divided by MR.PRES + 1.
>>
>> So, I used the clock-frequency DT binding to let user choose the timer's
>> frequency. Based on the value provided via this DT binding the best clock
>> source and prescaler is chosen via mchp_pit64b_pres_prepare() function.
> 
> I'm willing to take the driver but I doubt the purpose of the
> clock-frequency is to let the user choose the frequency.
> 

I found this approach in the following already integrated drivers:
drivers/clocksource/armv7m_systick.c
drivers/clocksource/bcm2835_timer.c
drivers/clocksource/bcm_kona_timer.c
drivers/clocksource/mips-gic-timer.c
drivers/clocksource/mps2-timer.c
drivers/clocksource/timer-qcom.c
drivers/clocksource/arm_arch_timer.c

Looking through the documentation of these, most of them document this DT
property as the frequency of the clock that drivers the timer, but none of
them seems to have some IP internal dividers so that the timer to tick at
different frequency than the clock that feeds the IP. From the
documentation of the above drivers;
drivers/clocksource/armv7m_systick.c
- clock-frequency : The rate in HZ in input of the ARM SysTick

drivers/clocksource/bcm2835_timer.c
- clock-frequency : The frequency of the clock that drives the counter, 
in
Hz.
drivers/clocksource/bcm_kona_timer.c
- clock-frequency: frequency that the clock operates

drivers/clocksource/mips-gic-timer.c
clock-frequency : Clock frequency at which the GIC timers operate.
drivers/clocksource/mps2-timer.c
- clock-frequency : The rate in HZ in input of the ARM MPS2 timer

drivers/clocksource/timer-qcom.c
- clock-frequency : The frequency of the debug timer and the general
purpose
timer(s) in Hz in that order.


This is why I also chose this DT bindings.

If you want I can stick to a fixed frequency hard coded in the driver.
Please let me know if this would be OK for you.

Thank you,
Claudiu Beznea

> 
> [ ... ]
> 
> 

Re: [PATCH v4 09/16] x86/alternative: Remove text_poke_loc::len

[Ingo Molnar]

* Peter Zijlstra  wrote:

>* Second step: update all but the first byte of the patched range.
>*/
>   for (do_sync = 0, i = 0; i < nr_entries; i++) {
> - if (tp[i].len - sizeof(int3) > 0) {
> + int len = text_opcode_size(tp[i].opcode);
> +
> + if (len - sizeof(int3) > 0) {
>   text_poke((char *)tp[i].addr + sizeof(int3),
> (const char *)tp[i].text + sizeof(int3),
> -   tp[i].len - sizeof(int3));
> +   len - sizeof(int3));
>   do_sync++;
>   }

Readability side note: 'sizeof(int3)' is a really weird way to write '1' 
and I had to double check it's not measuring the size of some larger 
entity.

I think it might make sense to just break out INT3_SIZE from 
arch/x86/kernel/kprobes/opt.c into a header, rename it to INS_INT3_SIZE 
and define it to 1, because the opt.c use is pretty obfuscated as well:

  #define INT3_SIZE sizeof(kprobe_opcode_t)

Where kprobe_opcode_t is u8 on x86 (and won't ever be anything else).

?

Thanks,

Ingo