[PATCH v5 0/13] Add mt7629 and fix mt7628 pwm

[Sam Shih]

Changes since v5:
- Follow reviewer's comments:
  1. the license stuff is a separate change
  2. split fix mt7628 pwm into a single patch
  3. to ensure to not use mtk_pwm_clk_name[10] 
 (After dynamic allocate clock array patch, 
  this is no need to check)
  4. Use clock-frequency property to replace 
 the use of has_clks

Changes since v4:
- Follow reviewer's comments (v3: pwm: mediatek: add a property "num-pwms")
  Move the changes of droping the check for of_device_get_match_data
  returning non-NULL to next patch
- Follow reviewers's comments 
  (v3: pwm: mediatek: allocate the clks array dynamically)
  1. use pc->soc->has_clks to check clocks exist or not.
  2. Add error message when probe() unable to get clks
- Fixes bug when SoC is old mips which has no complex clock tree.
if clocks not exist, use the new property from DT to apply period 
calculation; otherwise, use clk_get_rate to get clock frequency and 
apply period calculation.

Changes since v3:
- add a new property "clock-frequency" and fix mt7628 pwm
- add mt7629 pwm support

Changes since v2:
- use num-pwms instead of mediatek,num-pwms.
- rename the member from num_pwms to fallback_num_pwms to make it 
  more obvious that it doesn't represent the actually used value.
- add a dev_warn and a expressive comment to help other developers 
  to not start adding num_pwms in the compatible_data.

Changes since v1:
- add some checks for backwards compatibility.


Ryder Lee (5):
  pwm: mediatek: add a property "num-pwms"
  dt-bindings: pwm: add a property "num-pwms"
  arm64: dts: mt7622: add a property "num-pwms" for PWM
  arm: dts: mt7623: add a property "num-pwms" for PWM
  dt-bindings: pwm: update bindings for MT7629 SoC

Sam Shih (8):
  pwm: mediatek: droping the check for of_device_get_match_data
  pwm: mediatek: add a property "clock-frequency"
  pwm: mediatek: allocate the clks array dynamically
  pwm: mediatek: use pwm_mediatek as common prefix
  pwm: mediatek: update license and switch to SPDX tag
  dt-bindings: pwm: update bindings for MT7628 SoC
  pwm: mediatek: remove a property "has-clock"
  arm: dts: mediatek: add mt7629 pwm support

 .../devicetree/bindings/pwm/pwm-mediatek.txt  |  12 +-
 arch/arm/boot/dts/mt7623.dtsi |   1 +
 arch/arm64/boot/dts/mediatek/mt7622.dtsi  |   1 +
 drivers/pwm/pwm-mediatek.c| 257 ++
 arch/arm/boot/dts/mt7629.dtsi | 16 
 5 files changed, 168 insertions(+), 119 deletions(-)

-- 
2.17.1

[PATCH v2] mm: consolidate pgtable_cache_init() and pgd_cache_init()

[Mike Rapoport]

Both pgtable_cache_init() and pgd_cache_init() are used to initialize kmem
cache for page table allocations on several architectures that do not use
PAGE_SIZE tables for one or more levels of the page table hierarchy.

Most architectures do not implement these functions and use __weak default
NOP implementation of pgd_cache_init(). Since there is no such default for
pgtable_cache_init(), its empty stub is duplicated among most
architectures.

Rename the definitions of pgd_cache_init() to pgtable_cache_init() and drop
empty stubs of pgtable_cache_init().

Signed-off-by: Mike Rapoport 
Acked-by: Will Deacon  # arm64
Acked-by: Thomas Gleixner   # x86
---
v2 changes:
* remove stale comments and extra whitespace, per Matthew
* add acks

 arch/alpha/include/asm/pgtable.h  |  5 -
 arch/arc/include/asm/pgtable.h|  5 -
 arch/arm/include/asm/pgtable-nommu.h  |  5 -
 arch/arm/include/asm/pgtable.h|  2 --
 arch/arm64/include/asm/pgtable.h  |  2 --
 arch/arm64/mm/pgd.c   |  2 +-
 arch/c6x/include/asm/pgtable.h|  5 -
 arch/csky/include/asm/pgtable.h   |  5 -
 arch/h8300/include/asm/pgtable.h  |  6 --
 arch/hexagon/include/asm/pgtable.h|  3 ---
 arch/hexagon/mm/Makefile  |  2 +-
 arch/hexagon/mm/pgalloc.c | 10 --
 arch/ia64/include/asm/pgtable.h   |  5 -
 arch/m68k/include/asm/pgtable_mm.h|  5 -
 arch/m68k/include/asm/pgtable_no.h|  5 -
 arch/microblaze/include/asm/pgtable.h |  7 ---
 arch/mips/include/asm/pgtable.h   |  5 -
 arch/nds32/include/asm/pgtable.h  |  2 --
 arch/nios2/include/asm/pgtable.h  |  2 --
 arch/openrisc/include/asm/pgtable.h   |  5 -
 arch/parisc/include/asm/pgtable.h |  2 --
 arch/powerpc/include/asm/pgtable.h|  1 -
 arch/riscv/include/asm/pgtable.h  |  5 -
 arch/s390/include/asm/pgtable.h   |  5 -
 arch/sh/include/asm/pgtable.h |  5 -
 arch/sh/mm/nommu.c|  4 
 arch/sparc/include/asm/pgtable_32.h   |  5 -
 arch/sparc/include/asm/pgtable_64.h   |  1 -
 arch/um/include/asm/pgtable.h |  2 --
 arch/unicore32/include/asm/pgtable.h  |  2 --
 arch/x86/include/asm/pgtable_32.h |  1 -
 arch/x86/include/asm/pgtable_64.h |  2 --
 arch/x86/mm/pgtable.c |  6 +-
 arch/xtensa/include/asm/pgtable.h |  1 -
 include/asm-generic/pgtable.h |  2 +-
 init/main.c   |  3 +--
 36 files changed, 5 insertions(+), 130 deletions(-)
 delete mode 100644 arch/hexagon/mm/pgalloc.c

diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
index 89c2032..065b57f 100644
--- a/arch/alpha/include/asm/pgtable.h
+++ b/arch/alpha/include/asm/pgtable.h
@@ -359,11 +359,6 @@ extern void paging_init(void);
 
 #include 
 
-/*
- * No page table caches to initialise
- */
-#define pgtable_cache_init()   do { } while (0)
-
 /* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT.  */
 #define HAVE_ARCH_UNMAPPED_AREA
 
diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
index 1d87c18..7addd03 100644
--- a/arch/arc/include/asm/pgtable.h
+++ b/arch/arc/include/asm/pgtable.h
@@ -395,11 +395,6 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned 
long address,
 /* to cope with aliasing VIPT cache */
 #define HAVE_ARCH_UNMAPPED_AREA
 
-/*
- * No page table caches to initialise
- */
-#define pgtable_cache_init()   do { } while (0)
-
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/arch/arm/include/asm/pgtable-nommu.h 
b/arch/arm/include/asm/pgtable-nommu.h
index 0b1f679..f277822 100644
--- a/arch/arm/include/asm/pgtable-nommu.h
+++ b/arch/arm/include/asm/pgtable-nommu.h
@@ -72,11 +72,6 @@ typedef pte_t *pte_addr_t;
 extern unsigned int kobjsize(const void *objp);
 
 /*
- * No page table caches to initialise.
- */
-#define pgtable_cache_init()   do { } while (0)
-
-/*
  * All 32bit addresses are effectively valid for vmalloc...
  * Sort of meaningless for non-VM targets.
  */
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index f2e990d..3ae120c 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -368,8 +368,6 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
 #define HAVE_ARCH_UNMAPPED_AREA
 #define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
 
-#define pgtable_cache_init() do { } while (0)
-
 #endif /* !__ASSEMBLY__ */
 
 #endif /* CONFIG_MMU */
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 1535589d..8646f47 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -842,8 +842,6 @@ extern int kern_addr_valid(unsigned long addr);
 
 #include 
 
-static inline void pgtable_cache_init(void) { }
-
 /*
  * On AArch64, the cache coherency is handled via the set_pte_at() function.
  */
diff --git a/arch/arm64/mm/pgd.c b/arch/arm64/mm/pgd.c
index 7548f9c..4a640

Regression in 5.3-rc1 and later

[Chris Clayton]

Hi everyone,

Firstly, apologies to anyone on the long cc list that turns out not to be 
particularly interested in the following, but
you were all marked as cc'd in the commit message below.

I've found a problem that isn't present in 5.2 series or 4.19 series kernels, 
and seems to have arrived in 5.3-rc1. The
problem is that if I suspend (to ram) my laptop, on resume 14 minutes or more 
after suspending, I have no networking
functionality. If I resume the laptop after 13 minutes or less, networking 
works fine. I haven't tried to get finer
grained timings between 13 and 14 minutes, but can do if it would help.

ifconfig shows that wlan0 is still up and still has its assigned ip address 
but, for instance, a ping of any other
device on my network, fails as does pinging, say, kernel.org. I've tried 
"downing" the network with (/sbin/ifdown) and
unloading the iwlmvm module and then reloading the module and "upping" 
(/sbin/ifup) the network, but my network is still
unusable. I should add that the problem also manifests if I hibernate the 
laptop, although my testing of this has been
minimal. I can do more if required.

As I say, the problem first appears in 5.3-rc1, so I've bisected between 5.2.0 
and 5.3-rc1 and that concluded with:

[chris:~/kernel/linux]$ git bisect good
7ac8707479886c75f353bfb6a8273f423cfccb23 is the first bad commit
commit 7ac8707479886c75f353bfb6a8273f423cfccb23
Author: Vincenzo Frascino 
Date:   Fri Jun 21 10:52:49 2019 +0100

x86/vdso: Switch to generic vDSO implementation

The x86 vDSO library requires some adaptations to take advantage of the
newly introduced generic vDSO library.

Introduce the following changes:
 - Modification of vdso.c to be compliant with the common vdso datapage
 - Use of lib/vdso for gettimeofday

[ tglx: Massaged changelog and cleaned up the function signature formatting 
]

Signed-off-by: Vincenzo Frascino 
Signed-off-by: Thomas Gleixner 
Cc: linux-a...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Arnd Bergmann 
Cc: Russell King 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: Daniel Lezcano 
Cc: Mark Salyzyn 
Cc: Peter Collingbourne 
Cc: Shuah Khan 
Cc: Dmitry Safonov <0x7f454...@gmail.com>
Cc: Rasmus Villemoes 
Cc: Huw Davies 
Cc: Shijith Thotton 
Cc: Andre Przywara 
Link: 
https://lkml.kernel.org/r/20190621095252.32307-23-vincenzo.frasc...@arm.com

 arch/x86/Kconfig |   3 +
 arch/x86/entry/vdso/Makefile |   9 ++
 arch/x86/entry/vdso/vclock_gettime.c | 245 ---
 arch/x86/entry/vdso/vdsox32.lds.S|   1 +
 arch/x86/entry/vsyscall/Makefile |   2 -
 arch/x86/entry/vsyscall/vsyscall_gtod.c  |  83 ---
 arch/x86/include/asm/pvclock.h   |   2 +-
 arch/x86/include/asm/vdso/gettimeofday.h | 191 
 arch/x86/include/asm/vdso/vsyscall.h |  44 ++
 arch/x86/include/asm/vgtod.h |  75 +-
 arch/x86/include/asm/vvar.h  |   7 +-
 arch/x86/kernel/pvclock.c|   1 +
 12 files changed, 284 insertions(+), 379 deletions(-)
 delete mode 100644 arch/x86/entry/vsyscall/vsyscall_gtod.c
 create mode 100644 arch/x86/include/asm/vdso/gettimeofday.h
 create mode 100644 arch/x86/include/asm/vdso/vsyscall.h

To confirm my bisection was correct, I did a git checkout of 
7ac8707479886c75f353bfb6a8273f423cfccb2. As expected, the
kernel exhibited the problem I've described. However, a kernel built at the 
immediately preceding (parent?) commit
(bfe801ebe84f42b4666d3f0adde90f504d56e35b) has a working network after a (>= 
14minute) suspend/resume cycle.

As the module name implies, I'm using wireless networking. The hardware is 
detected as "Intel(R) Wireless-AC 9260
160MHz, REV=0x324" by iwlwifi.

I'm more than happy to provide additional diagnostics (but may need a little 
hand-holding) and to apply diagnostic or
fix patches, but please cc me on any reply as I'm not subscribed to any of the 
kernel-related mailing lists.

Chris

Re: [PATCH 3/3] media: imx214: Add new control with V4L2_CID_PIXEL_SIZE

[Jacopo Mondi]

Hi Ricardo,

On Wed, Aug 21, 2019 at 06:31:05PM +0200, Ricardo Ribalda Delgado wrote:
> Hi Jacopo
>
>
> On Wed, Aug 21, 2019 at 6:14 PM Jacopo Mondi  wrote:
> >
> > Hi Ricardo,
> >
> > On Mon, Aug 19, 2019 at 02:17:20PM +0200, Ricardo Ribalda Delgado wrote:
> > > According to the product brief, the unit cell size is 1120 nanometers^2.
> >
> > Should this information come from DT ?
>
> I do not think so. You cannot change this value and it needs to be
> defined also in sensors/cameras that might not have a DT, like a usb
> webcam.

You're probably right. I got this thinking because the camera
location/orientation are two read only parameters that come from DT,
but their value depends on the design of the device where the camera
is installed on, so they're configurable, while this and other
physical properties are not, and it doesn't make much sense to have
them in DT.

Thanks
   j

>
> It would be like adding to the DT the min/max exposure time...
>
> But of course we can discuss it ;)
>
> Best regards
>
> >
> > I'm asking as I've a series in review that adds an helper that
> > collectes dt properties and register controls for them. It currently
> > only supports the newly proposed camera location control, but there
> > might be others like the rotation, for which we already have a DT
> > property.
> >
> > https://patchwork.kernel.org/project/linux-media/list/?series=160901
> >
> > This new one is indeed an HW property of the sensor, I wonder if
> > having it in the firmware interface would make any sense or not...
> >
> > Thanks
> >   j
> >
> > >
> > > https://www.sony-semicon.co.jp/products_en/IS/sensor1/img/products/ProductBrief_IMX214_20150428.pdf
> > >
> > > Signed-off-by: Ricardo Ribalda Delgado 
> > > ---
> > >  drivers/media/i2c/imx214.c | 23 +++
> > >  1 file changed, 23 insertions(+)
> > >
> > > diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
> > > index 159a3a604f0e..b2f6bd2d8d7d 100644
> > > --- a/drivers/media/i2c/imx214.c
> > > +++ b/drivers/media/i2c/imx214.c
> > > @@ -47,6 +47,7 @@ struct imx214 {
> > >   struct v4l2_ctrl *pixel_rate;
> > >   struct v4l2_ctrl *link_freq;
> > >   struct v4l2_ctrl *exposure;
> > > + struct v4l2_ctrl *pixel_size;
> > >
> > >   struct regulator_bulk_data  supplies[IMX214_NUM_SUPPLIES];
> > >
> > > @@ -941,6 +942,26 @@ static int __maybe_unused imx214_resume(struct 
> > > device *dev)
> > >   return ret;
> > >  }
> > >
> > > +static void pixel_size_init(const struct v4l2_ctrl *ctrl, u32 idx,
> > > +  union v4l2_ctrl_ptr ptr)
> > > +{
> > > + ptr.p_pixel_size->width = 1120;
> > > + ptr.p_pixel_size->height = 1120;
> > > +}
> > > +
> > > +static const struct v4l2_ctrl_type_ops pixel_size_ops = {
> > > + .init = pixel_size_init,
> > > +};
> > > +
> > > +static struct v4l2_ctrl *new_pixel_size_ctrl(struct v4l2_ctrl_handler 
> > > *handler)
> > > +{
> > > + static struct v4l2_ctrl_config ctrl = {
> > > + .id = V4L2_CID_PIXEL_SIZE,
> > > + .type_ops = &pixel_size_ops,
> > > + };
> > > +
> > > + return v4l2_ctrl_new_custom(handler, &ctrl, NULL);
> > > +}
> > >  static int imx214_probe(struct i2c_client *client)
> > >  {
> > >   struct device *dev = &client->dev;
> > > @@ -1029,6 +1050,8 @@ static int imx214_probe(struct i2c_client *client)
> > >V4L2_CID_EXPOSURE,
> > >0, 3184, 1, 0x0c70);
> > >
> > > + imx214->pixel_size = new_pixel_size_ctrl(&imx214->ctrls);
> > > +
> > >   ret = imx214->ctrls.error;
> > >   if (ret) {
> > >   dev_err(&client->dev, "%s control init failed (%d)\n",
> > > --
> > > 2.23.0.rc1
> > >


signature.asc
Description: PGP signature

Re: [PATCH v2] tomoyo: Don't check open/getattr permission on sockets.

[Tetsuo Handa]

Eric Biggers wrote:
> What happened to this patch?

I have to learn how to manage a git tree for sending
pull requests, but I can't find time to try.

> 
> Also, isn't the same bug in other places too?:
> 
>   - tomoyo_path_chmod()
>   - tomoyo_path_chown()
>   - smack_inode_getsecurity()
>   - smack_inode_setsecurity()

What's the bug? The file descriptor returned by open(O_PATH) cannot be
passed to read(2), write(2), fchmod(2), fchown(2), fgetxattr(2), mmap(2) etc.

Adding depends-on DT binding to break cyclic dependencies

[Saravana Kannan]

Hi Rob,

Frank, Greg and I got together during ELC and had an extensive and
very productive discussion about my "postboot supplier state cleanup"
patch series [1]. The three of us are on the same page now -- the
series as it stands is the direction we want to go in, with some minor
refactoring, documentation and naming changes.

However, one of the things Frank is concerned about (and Greg and I
agree) in the current patch series is that the "cyclic dependency
breaking" logic has been pushed off to individual drivers using the
edit_links() callback.

The concern being, there are going to be multiple device specific ad
hoc implementations to break a cyclic dependency. Also, if a device
can be part of a cyclic dependency, the driver for that device has to
check for specific system/products in which the device is part of a
cyclic dependency (because it might not always be part of a cycle),
and then potentially have cycle/product specific code to break the
cycle (since the cycle can be different on each system/product).

One way to avoid all of the device/driver specific code and simplify
my patch series by a non-trivial amount would be by adding a
"depends-on" DT binding that can ONLY be used to break cycles. We can
document it as such and reject any attempts to use it for other
purposes. When a depends-on property is present in a device node, that
specific device's supplier list will be parsed ONLY from the
depends-on property and the other properties won't be parsed for
deriving dependency information for that device.

Frank, Greg and I like this usage model for a new depends-on DT
binding. Is this something you'd be willing to accept?

Thanks,
Saravana

[1] - https://lore.kernel.org/lkml/20190731221721.187713-1-sarava...@google.com/

Re: [PATCH v3 2/2] phy: intel-lgm-emmc: Add support for eMMC PHY

[Ramuthevar, Vadivel MuruganX]

Hi Andy,
On 21/8/2019 8:01 PM, Andy Shevchenko wrote:

On Wed, Aug 21, 2019 at 06:11:18PM +0800, Ramuthevar,Vadivel MuruganX wrote:

From: Ramuthevar Vadivel Murugan 

Add support for eMMC PHY on Intel's Lightning Mountain SoC.
--- /dev/null
+++ b/drivers/phy/intel/Kconfig
@@ -0,0 +1,8 @@

Missed licence tag

Thank you so much for the review comments, will update.

+#
+# Phy drivers for Intel X86 LGM platform
+#
+#define EMMC_PHYCTRL2_REG  0xb0
+#define FRQSEL_25M 0

I would still leave 1 and 2 with corresponding names for sake of documentation.

Ok, will add for the sake of documentation.

+#define FRQSEL_150M3
+#define FRQSEL_MASKGENMASK(24, 22)
+#define FRQSEL_SHIFT(x)(((x) << 22) & FRQSEL_MASK)
+   unsigned int freqsel = 0;

Redundant assignment.

Noted, will update.

+   udelay(5);

+ blank line

Noted, will update



+   regmap_update_bits(priv->syscfg, EMMC_PHYCTRL1_REG, PDB_MASK, 1);

And here missed to address one of my comments.

Yes, will update.

+   /*
+* We purposely get the clock here and not in probe to avoid the
+* circular dependency problem.  We expect:

We don't use double space

Noted, will update.

+* - PHY driver to probe
+* - SDHCI driver to start probe
+* - SDHCI driver to register it's clock
+* - SDHCI driver to get the PHY
+* - SDHCI driver to init the PHY
+*
+* The clock is optional, so upon any error just return it like
+* any other error to user.
+*
+*/
+   struct device *dev = &pdev->dev;
+   struct intel_emmc_phy *priv;
+   struct phy *generic_phy;
+   struct phy_provider *phy_provider;
+   struct device_node *np = dev->of_node;

Group it with other assignment(s), i.e. dev = ... above.

struct device *dev = ...;
struct device_node *np = ...;


agree, will update.

---
With Best Regards
Vadivel Murugan

[RT PATCH] kernel/irq: make irq_set_affinity_notifier() work on old_notify consistently

[Juri Lelli]

The second half of irq_set_affinity_notifier() flushes an old notifier,
but (for RT) it is currently working on 'notify', which is the new one
(or can be NULL - in fact a NULL pointer dereference has been observed).

Fix this by making the second half of irq_set_affinity_notifier() use
old_notify consistently.

Fixes: d4200ab75cdd ("genirq: Handle missing work_struct in 
irq_set_affinity_notifier()")
Signed-off-by: Juri Lelli 
---
Hi,

This applies to v4.19.59-rt24 (and to all the other branches that have
the patch that introduced the issue). v5.2-rtx doesn't have this problem
(thanks to the workqueue rework).

Best,

Juri
---
 kernel/irq/manage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index b2736d7d863b..4586967a1b32 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -386,7 +386,7 @@ irq_set_affinity_notifier(unsigned int irq, struct 
irq_affinity_notify *notify)
 
if (old_notify) {
 #ifdef CONFIG_PREEMPT_RT_BASE
-   kthread_cancel_work_sync(¬ify->work);
+   kthread_cancel_work_sync(&old_notify->work);
 #else
cancel_work_sync(&old_notify->work);
 #endif
-- 
2.17.2

[PATCH -next] ASoC: sun4i-i2s: Use PTR_ERR_OR_ZERO in sun4i_i2s_init_regmap_fields()

[YueHaibing]

Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

Signed-off-by: YueHaibing 
---
 sound/soc/sunxi/sun4i-i2s.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 9e691baee1e8..2071c54265f3 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1095,10 +1095,7 @@ static int sun4i_i2s_init_regmap_fields(struct device 
*dev,
i2s->field_fmt_sr =
devm_regmap_field_alloc(dev, i2s->regmap,
i2s->variant->field_fmt_sr);
-   if (IS_ERR(i2s->field_fmt_sr))
-   return PTR_ERR(i2s->field_fmt_sr);
-
-   return 0;
+   return PTR_ERR_OR_ZERO(i2s->field_fmt_sr);
 }
 
 static int sun4i_i2s_probe(struct platform_device *pdev)

[PATCH net-next] net/mlx5e: Use PTR_ERR_OR_ZERO in mlx5e_tc_add_nic_flow()

[YueHaibing]

Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

Signed-off-by: YueHaibing 
---
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 3917834b48ff..9d38c9e88f76 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -985,10 +985,7 @@ mlx5e_tc_add_nic_flow(struct mlx5e_priv *priv,
&flow_act, dest, dest_ix);
mutex_unlock(&priv->fs.tc.t_lock);
 
-   if (IS_ERR(flow->rule[0]))
-   return PTR_ERR(flow->rule[0]);
-
-   return 0;
+   return PTR_ERR_OR_ZERO(flow->rule[0]);
 }
 
 static void mlx5e_tc_del_nic_flow(struct mlx5e_priv *priv,

[PATCH 1/2] mmc: mediatek: fix controller busy when plug out SD

[Chaotian Jing]

when plug out SD card, may get data CRC error, the MMC core will issue
CMD13 to get card status, then CMD13 timeout(due to card plug out) will
trigger CMD19 tuning, first CMD19 timeout has not call msdc_reset_hw()
and cause the next CMD19 gets controller busy.

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 33f4b6387ef7..5cc422e5db69 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1071,11 +1071,13 @@ static bool msdc_cmd_done(struct msdc_host *host, int 
events,
}
 
if (!sbc_error && !(events & MSDC_INT_CMDRDY)) {
-   if (cmd->opcode != MMC_SEND_TUNING_BLOCK &&
-   cmd->opcode != MMC_SEND_TUNING_BLOCK_HS200)
+   if (events & MSDC_INT_CMDTMO ||
+   (cmd->opcode != MMC_SEND_TUNING_BLOCK &&
+cmd->opcode != MMC_SEND_TUNING_BLOCK_HS200))
/*
 * should not clear fifo/interrupt as the tune data
-* may have alreay come.
+* may have alreay come when cmd19/cmd21 gets response
+* CRC error.
 */
msdc_reset_hw(host);
if (events & MSDC_INT_RSPCRCERR) {
-- 
2.18.0

fix controller busy issue and add 24bits segment support

[Chaotian Jing]

the below 2 patches fix controller busy issue when plug out SD card
and add 24bits segment size support.

Chaotian Jing (2):
  mmc: mediatek: fix controller busy when plug out SD
  mmc: mediatek: support 24bits segment size

 drivers/mmc/host/mtk-sd.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

-- 
2.18.0

[PATCH 2/2] mmc: mediatek: support 24bits segment size

[Chaotian Jing]

MSDC IP which support 64G DRAM will support 24bits BDMA buffer length,
so add support it.

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 5cc422e5db69..4c72c5b73e87 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -328,6 +328,7 @@ struct mt_bdma_desc {
u32 ptr;
u32 bd_data_len;
 #define BDMA_DESC_BUFLEN   (0x) /* bit0 ~ bit15 */
+#define BDMA_DESC_BUFLEN_EXT   (0xff) /* bit0 ~ bit23 */
 };
 
 struct msdc_dma {
@@ -641,8 +642,14 @@ static inline void msdc_dma_setup(struct msdc_host *host, 
struct msdc_dma *dma,
bd[j].bd_info |= (upper_32_bits(dma_address) & 0xf)
 << 28;
}
-   bd[j].bd_data_len &= ~BDMA_DESC_BUFLEN;
-   bd[j].bd_data_len |= (dma_len & BDMA_DESC_BUFLEN);
+
+   if (host->dev_comp->support_64g) {
+   bd[j].bd_data_len &= ~BDMA_DESC_BUFLEN_EXT;
+   bd[j].bd_data_len |= (dma_len & BDMA_DESC_BUFLEN_EXT);
+   } else {
+   bd[j].bd_data_len &= ~BDMA_DESC_BUFLEN;
+   bd[j].bd_data_len |= (dma_len & BDMA_DESC_BUFLEN);
+   }
 
if (j == data->sg_count - 1) /* the last bd */
bd[j].bd_info |= BDMA_DESC_EOL;
@@ -2277,7 +2284,10 @@ static int msdc_drv_probe(struct platform_device *pdev)
mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23;
/* MMC core transfer sizes tunable parameters */
mmc->max_segs = MAX_BD_NUM;
-   mmc->max_seg_size = BDMA_DESC_BUFLEN;
+   if (host->dev_comp->support_64g)
+   mmc->max_seg_size = BDMA_DESC_BUFLEN_EXT;
+   else
+   mmc->max_seg_size = BDMA_DESC_BUFLEN;
mmc->max_blk_size = 2048;
mmc->max_req_size = 512 * 1024;
mmc->max_blk_count = mmc->max_req_size / 512;
-- 
2.18.0

Re: [PATCH] arm: skip nomap memblocks while finding the lowmem/highmem boundary

[Ard Biesheuvel]

On Thu, 22 Aug 2019 at 09:44, Mike Rapoport  wrote:
>
> On Thu, Aug 22, 2019 at 03:59:42AM +, Chester Lin wrote:
> > On Thu, Aug 22, 2019 at 11:45:34AM +0800, Chester Lin wrote:
> > > adjust_lowmem_bounds() checks every memblocks in order to find the 
> > > boundary
> > > between lowmem and highmem. However some memblocks could be marked as 
> > > NOMAP
> > > so they are not used by kernel, which should be skipped while calculating
> > > the boundary.
> > >
> > > Signed-off-by: Chester Lin 
> > > ---
> > >  arch/arm/mm/mmu.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > index 426d9085396b..b86dba44d828 100644
> > > --- a/arch/arm/mm/mmu.c
> > > +++ b/arch/arm/mm/mmu.c
> > > @@ -1181,6 +1181,9 @@ void __init adjust_lowmem_bounds(void)
> > > phys_addr_t block_start = reg->base;
> > > phys_addr_t block_end = reg->base + reg->size;
> > >
> > > +   if (memblock_is_nomap(reg))
> > > +   continue;
> > > +
> > > if (reg->base < vmalloc_limit) {
> > > if (block_end > lowmem_limit)
> > > /*
> > > --
> > > 2.22.0
> > >
> >
> > Hi Russell, Mike and Ard,
> >
> > Per the discussion in the thread "[PATH] efi/arm: fix allocation failure 
> > ...",
> > (https://lkml.org/lkml/2019/8/21/163), I presume that the change to 
> > disregard
> > NOMAP memblocks in adjust_lowmem_bounds() should be separated as a single 
> > patch.
> >
> > Please let me know if any suggestion, thank you.
>
> Let's add this one to the series:
>
> From 06a986e79d60c310c804b3e550bd50316597aec5 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport 
> Date: Thu, 22 Aug 2019 09:27:40 +0300
> Subject: [PATCH] arm: ensure that usable memory in bank 0 starts from a
>  PMD-aligned address
>
> The calculation of memblock_limit in adjust_lowmem_bounds() assumes that
> bank 0 starts from a PMD-aligned address. However, the beginning of the
> first bank may be NOMAP memory and the start of usable memory
> will be not aligned to PMD boundary. In such case the memblock_limit will
> be set to the end of the NOMAP region, which will prevent any memblock
> allocations.
>
> Mark the region between the end of the NOMAP area and the next PMD-aligned
> address as NOMAP as well, so that the usable memory will start at
> PMD-aligned address.
>
> Signed-off-by: Mike Rapoport 

Acked-by: Ard Biesheuvel 

> ---
>  arch/arm/mm/mmu.c | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 4495a26..25da9b2 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1177,6 +1177,22 @@ void __init adjust_lowmem_bounds(void)
>  */
> vmalloc_limit = (u64)(uintptr_t)vmalloc_min - PAGE_OFFSET + 
> PHYS_OFFSET;
>
> +   /*
> +* The first usable region must be PMD aligned. Mark its start
> +* as MEMBLOCK_NOMAP if it isn't
> +*/
> +   for_each_memblock(memory, reg) {
> +   if (!memblock_is_nomap(reg)) {
> +   if (!IS_ALIGNED(reg->base, PMD_SIZE)) {
> +   phys_addr_t len;
> +
> +   len = round_up(reg->base, PMD_SIZE) - 
> reg->base;
> +   memblock_mark_nomap(reg->base, len);
> +   }
> +   break;
> +   }
> +   }
> +
> for_each_memblock(memory, reg) {
> phys_addr_t block_start = reg->base;
> phys_addr_t block_end = reg->base + reg->size;
> --
> 2.7.4
>
>
> --
> Sincerely yours,
> Mike.
>

Re: [PATCH] arm: skip nomap memblocks while finding the lowmem/highmem boundary

[Mike Rapoport]

On Thu, Aug 22, 2019 at 03:59:42AM +, Chester Lin wrote:
> On Thu, Aug 22, 2019 at 11:45:34AM +0800, Chester Lin wrote:
> > adjust_lowmem_bounds() checks every memblocks in order to find the boundary
> > between lowmem and highmem. However some memblocks could be marked as NOMAP
> > so they are not used by kernel, which should be skipped while calculating
> > the boundary.
> > 
> > Signed-off-by: Chester Lin 
> > ---
> >  arch/arm/mm/mmu.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > index 426d9085396b..b86dba44d828 100644
> > --- a/arch/arm/mm/mmu.c
> > +++ b/arch/arm/mm/mmu.c
> > @@ -1181,6 +1181,9 @@ void __init adjust_lowmem_bounds(void)
> > phys_addr_t block_start = reg->base;
> > phys_addr_t block_end = reg->base + reg->size;
> >  
> > +   if (memblock_is_nomap(reg))
> > +   continue;
> > +
> > if (reg->base < vmalloc_limit) {
> > if (block_end > lowmem_limit)
> > /*
> > -- 
> > 2.22.0
> >
> 
> Hi Russell, Mike and Ard,
> 
> Per the discussion in the thread "[PATH] efi/arm: fix allocation failure ...",
> (https://lkml.org/lkml/2019/8/21/163), I presume that the change to disregard
> NOMAP memblocks in adjust_lowmem_bounds() should be separated as a single 
> patch.
> 
> Please let me know if any suggestion, thank you.

Let's add this one to the series: 

>From 06a986e79d60c310c804b3e550bd50316597aec5 Mon Sep 17 00:00:00 2001
From: Mike Rapoport 
Date: Thu, 22 Aug 2019 09:27:40 +0300
Subject: [PATCH] arm: ensure that usable memory in bank 0 starts from a
 PMD-aligned address

The calculation of memblock_limit in adjust_lowmem_bounds() assumes that
bank 0 starts from a PMD-aligned address. However, the beginning of the
first bank may be NOMAP memory and the start of usable memory
will be not aligned to PMD boundary. In such case the memblock_limit will
be set to the end of the NOMAP region, which will prevent any memblock
allocations.

Mark the region between the end of the NOMAP area and the next PMD-aligned
address as NOMAP as well, so that the usable memory will start at
PMD-aligned address.

Signed-off-by: Mike Rapoport 
---
 arch/arm/mm/mmu.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4495a26..25da9b2 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1177,6 +1177,22 @@ void __init adjust_lowmem_bounds(void)
 */
vmalloc_limit = (u64)(uintptr_t)vmalloc_min - PAGE_OFFSET + PHYS_OFFSET;
 
+   /*
+* The first usable region must be PMD aligned. Mark its start
+* as MEMBLOCK_NOMAP if it isn't
+*/
+   for_each_memblock(memory, reg) {
+   if (!memblock_is_nomap(reg)) {
+   if (!IS_ALIGNED(reg->base, PMD_SIZE)) {
+   phys_addr_t len;
+
+   len = round_up(reg->base, PMD_SIZE) - reg->base;
+   memblock_mark_nomap(reg->base, len);
+   }
+   break;
+   }
+   }
+
for_each_memblock(memory, reg) {
phys_addr_t block_start = reg->base;
phys_addr_t block_end = reg->base + reg->size;
-- 
2.7.4


-- 
Sincerely yours,
Mike.

Re: [PATCH] arm: skip nomap memblocks while finding the lowmem/highmem boundary

[Mike Rapoport]

On Thu, Aug 22, 2019 at 03:45:34AM +, Chester Lin wrote:
> adjust_lowmem_bounds() checks every memblocks in order to find the boundary
> between lowmem and highmem. However some memblocks could be marked as NOMAP
> so they are not used by kernel, which should be skipped while calculating
> the boundary.
> 
> Signed-off-by: Chester Lin 

Reviewed-by: Mike Rapoport 

> ---
>  arch/arm/mm/mmu.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 426d9085396b..b86dba44d828 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1181,6 +1181,9 @@ void __init adjust_lowmem_bounds(void)
>   phys_addr_t block_start = reg->base;
>   phys_addr_t block_end = reg->base + reg->size;
>  
> + if (memblock_is_nomap(reg))
> + continue;
> +
>   if (reg->base < vmalloc_limit) {
>   if (block_end > lowmem_limit)
>   /*
> -- 
> 2.22.0
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 1/4] dt-bindings: reset: aoss: Add AOSS reset binding for SC7180 SoCs

[Sibi Sankar]

Hey Philipp,
Thanks for the review!

On 2019-08-21 16:02, Philipp Zabel wrote:

On Wed, 2019-08-21 at 15:24 +0530, Sibi Sankar wrote:

Add SC7180 AOSS reset to the list of possible bindings.

Signed-off-by: Sibi Sankar 
---
 Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt 
b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt

index 510c748656ec5..8f0bbdc6afd91 100644
--- a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
+++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
@@ -8,7 +8,8 @@ Required properties:
 - compatible:
Usage: required
Value type: 
-   Definition: must be:
+   Definition: must be one of:
+   "qcom,sc7180-aoss-cc"
"qcom,sdm845-aoss-cc"

 - reg:


Does sc7180 have exactly the same resets (mss, camss, venus, gpu,
dispss, wcss, and lpass) as sdm845? If so, it could be considered
compatible, and the driver changes wouldn't be needed at all:


Yes they are identical both
AOSS and PDC resets.



-   Definition: must be:
+   Definition: must be one of:
+   "qcom,sc7180-aoss-cc", "qcom,sdm845-aoss-cc"

"qcom,sdm845-aoss-cc"

Is there a reason not to do this?


I am fine with ^^, will change
them in v2.



regards
Philipp


--
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

RE: [EXT] Re: [Patch v4 1/3] dt-bindings: spi: spi-fsl-qspi: Add ls2080a compatibility string to bindings

[Ashish Kumar]

> -Original Message-
> From: devicetree-ow...@vger.kernel.org  ow...@vger.kernel.org> On Behalf Of Ashish Kumar
> Sent: Wednesday, August 21, 2019 7:49 PM
> To: Mark Brown ; shawn...@kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; robh...@kernel.org; mark.rutl...@arm.com;
> linux-n...@vger.kernel.org; Kuldeep Singh 
> Subject: RE: [EXT] Re: [Patch v4 1/3] dt-bindings: spi: spi-fsl-qspi: Add 
> ls2080a
> compatibility string to bindings
> 
> Caution: EXT Email
> 
> > -Original Message-
> > From: Mark Brown 
> > Sent: Wednesday, August 21, 2019 4:37 PM
> > To: Ashish Kumar 
> > Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> > devicet...@vger.kernel.org; robh...@kernel.org;
> mark.rutl...@arm.com;
> > linux-n...@vger.kernel.org; Kuldeep Singh 
> > Subject: [EXT] Re: [Patch v4 1/3] dt-bindings: spi: spi-fsl-qspi: Add
> > ls2080a compatibility string to bindings
> >
> > On Tue, Aug 13, 2019 at 03:53:09PM +0530, Ashish Kumar wrote:
> >
> > > There are 2 version of QSPI-IP, according to which controller
> > > registers sets can be big endian or little endian.There are some
> > > other minor changes like RX fifo depth etc.
> > >
> > > The big endian version uses driver compatible "fsl,ls1021a-qspi" and
> > > little endian version uses driver compatible "fsl,ls2080a-qspi"
> >
> > I'm not seeing the corresponding code changes anywhere?  I'd at least
> > expect to see the compatibles added, and it sounds like some actual
> > code updates are needed.
> Hi Mark,
> 
> Snippet from driver spi-fsl-qspi.c
> static const struct of_device_id fsl_qspi_dt_ids[] = {
> { .compatible = "fsl,vf610-qspi", .data = &vybrid_data, },
> { .compatible = "fsl,imx6sx-qspi", .data = &imx6sx_data, },
> { .compatible = "fsl,imx7d-qspi", .data = &imx7d_data, },
> { .compatible = "fsl,imx6ul-qspi", .data = &imx6ul_data, },
> { .compatible = "fsl,ls1021a-qspi", .data = &ls1021a_data, },
> { .compatible = "fsl,ls2080a-qspi", .data = &ls2080a_data, },
> { /* sentinel */ }
> };
> I had previously sent dts patch based out of Shawn's tree with dependency
> on these dt binding patch. To which Shawn had replied to get dependency
> patch accepted first before sending this dts change.
> Reference conversion can be viewed here [1],[2].
> 
> This compatible can be seen here: file arch/arm64/boot/dts/freescale/fsl-
> ls208xa.dtsi
> 
> Snippet from previous dts patch based on Shawn tree, I will send next
> version on this patch after dt-bindings are updated
> arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-) diff --git
> a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> index d7e78dcd153d..8e5ba513b24f 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> @@ -606,7 +606,7 @@
> 
> qspi: spi@20c {
> status = "disabled";
> -   compatible = "fsl,ls2080a-qspi", "fsl,ls1021a-qspi";
> +   compatible = "fsl,ls2080a-qspi";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x0 0x20c 0x0 0x1>,
> >
> > Please use subject lines matching the style for the subsystem.  This
> > makes it easier for people to identify relevant patches.
Hi Mark,

After looking at some patch in Documentation/devicetree/bindings/spi/
I think I should update subject line to
dt-bindings: spi: Add ls2080-qspi compatible string for FSL QSPI driver
or 
doc: qspi: Add ls2080-qspi compatible to DT bindings for FSL QSPI driver

Please suggest, if you think these are good or still need change.
Regards
Ashish 

> Could you please guide more, or point to documentation to follow sub-
> system style.
> dt-bindings: spi: spi-fsl-qspi: Add ls2080a-qspi compatibility string to 
> bindings
> Is this a better now? if yes, I will send next version
> 
> [1]:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .spinics.net%2Flists%2Farm-
> kernel%2Fmsg727403.html&data=02%7C01%7Cashish.kumar%40nxp.co
> m%7C5922d2067b004c8f8f2c08d72642800c%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C63701993936903&sdata=HsumTqK0SiaBjzmbK
> 9r5dfpNtWHiZ%2FcB9e%2Bwy7SW160%3D&reserved=0
> [2]:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fpatch%2F10192103%2F&data=02%7C01%7Cashish.k
> umar%40nxp.com%7C5922d2067b004c8f8f2c08d72642800c%7C686ea1d3bc2b
> 4c6fa92cd99c5c301635%7C0%7C0%7C63701993936903&sdata=2xRb
> YdJHTibb1BM0iNSJ00P69s2RKj9SLNFNUsneT8I%3D&reserved=0
> 
> Regards
> Ashish

[PATCH] ext4: remove unreachable statement inside __es_insert_extent()

[Austin Kim]

__es_insert_extent() never returns -EINVAL after BUG is executed.
So remove unreachable code.
---
 fs/ext4/extents_status.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c
index a959adc..7f97360 100644
--- a/fs/ext4/extents_status.c
+++ b/fs/ext4/extents_status.c
@@ -781,7 +781,6 @@ static int __es_insert_extent(struct inode *inode, struct 
extent_status *newes)
p = &(*p)->rb_right;
} else {
BUG();
-   return -EINVAL;
}
}
 
-- 
2.6.2

Re: [PATCH] VMCI: Release resource if the work is already queued

[Vishnu Dasa]

On 8/20/19, 8:48 PM, "Nadav Amit"  wrote:
> Francois reported that VMware balloon gets stuck after a balloon reset,
> when the VMCI doorbell is removed. A similar error can occur when the
> balloon driver is removed with the following splat:
> 
> [ 1088.622000] INFO: task modprobe:3565 blocked for more than 120 seconds.
> [ 1088.622035]   Tainted: GW 5.2.0 #4
> [ 1088.622087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 1088.622205] modprobeD0  3565   1450 0x
> [ 1088.622210] Call Trace:
> [ 1088.622246]  __schedule+0x2a8/0x690
> [ 1088.622248]  schedule+0x2d/0x90
> [ 1088.622250]  schedule_timeout+0x1d3/0x2f0
> [ 1088.622252]  wait_for_completion+0xba/0x140
> [ 1088.622320]  ? wake_up_q+0x80/0x80
> [ 1088.622370]  vmci_resource_remove+0xb9/0xc0 [vmw_vmci]
> [ 1088.622373]  vmci_doorbell_destroy+0x9e/0xd0 [vmw_vmci]
> [ 1088.622379]  vmballoon_vmci_cleanup+0x6e/0xf0 [vmw_balloon]
> [ 1088.622381]  vmballoon_exit+0x18/0xcc8 [vmw_balloon]
> [ 1088.622394]  __x64_sys_delete_module+0x146/0x280
> [ 1088.622408]  do_syscall_64+0x5a/0x130
> [ 1088.622410]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 1088.622415] RIP: 0033:0x7f54f62791b7
> [ 1088.622421] Code: Bad RIP value.
> [ 1088.622421] RSP: 002b:7fff2a949008 EFLAGS: 0206 ORIG_RAX: 
> 00b0
> [ 1088.622426] RAX: ffda RBX: 55dff8b55d00 RCX: 
> 7f54f62791b7
> [ 1088.622426] RDX:  RSI: 0800 RDI: 
> 55dff8b55d68
> [ 1088.622427] RBP: 55dff8b55d00 R08: 7fff2a947fb1 R09: 
> 
> [ 1088.622427] R10: 7f54f62f5cc0 R11: 0206 R12: 
> 55dff8b55d68
> [ 1088.622428] R13: 0001 R14: 55dff8b55d68 R15: 
> 7fff2a94a3f0
> 
> The cause for the bug is that when the "delayed" doorbell is invoked, it
> takes a reference on the doorbell entry and schedules work that is
> supposed to run the appropriate code and drop the doorbell entry
> reference. The code ignores the fact that if the work is already queued,
> it will not be scheduled to run one more time. As a result one of the
> references would not be dropped. When the code waits for the reference
> to get to zero, during balloon reset or module removal, it gets stuck.
>
> Fix it. Drop the reference if schedule_work() indicates that the work is
> already queued.
>
> Note that this bug got more apparent (or apparent at all) due to
> commit ce664331b248 ("vmw_balloon: VMCI_DOORBELL_SET does not check status").
>
> Fixes: 83e2ec765be03 ("VMCI: doorbell implementation.")
> Reported-by: Francois Rigault 
> Cc: Jorgen Hansen 
> Cc: Adit Ranadive 
> Cc: Alexios Zavras 
> Cc: Vishnu DASA 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Nadav Amit 
> ---
> drivers/misc/vmw_vmci/vmci_doorbell.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)

Thanks for the fix, looks good to me.
Reviewed-by: Vishnu Dasa 

--
vishnu

[PATCH -next] phy: tegra: Use PTR_ERR_OR_ZERO in tegra_p2u_probe()

[YueHaibing]

Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

Signed-off-by: YueHaibing 
---
 drivers/phy/tegra/phy-tegra194-p2u.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/phy/tegra/phy-tegra194-p2u.c 
b/drivers/phy/tegra/phy-tegra194-p2u.c
index 7042bed9feaa..42394d27f4cb 100644
--- a/drivers/phy/tegra/phy-tegra194-p2u.c
+++ b/drivers/phy/tegra/phy-tegra194-p2u.c
@@ -92,10 +92,7 @@ static int tegra_p2u_probe(struct platform_device *pdev)
phy_set_drvdata(generic_phy, phy);
 
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
-   if (IS_ERR(phy_provider))
-   return PTR_ERR(phy_provider);
-
-   return 0;
+   return PTR_ERR_OR_ZERO(phy_provider);
 }
 
 static const struct of_device_id tegra_p2u_id_table[] = {

Re: [PATCH v2] tomoyo: Don't check open/getattr permission on sockets.

[Eric Biggers]

Hi Tetsuo,

On Sat, Jun 22, 2019 at 01:45:30PM +0900, Tetsuo Handa wrote:
> On 2019/06/19 5:49, Al Viro wrote:
> > On Sun, Jun 16, 2019 at 03:49:00PM +0900, Tetsuo Handa wrote:
> >> Hello, Al.
> >>
> >> Q1: Do you agree that we should fix TOMOYO side rather than SOCKET_I()->sk
> >> management.
> > 
> > You do realize that sockets are not unique in that respect, right?
> > All kinds of interesting stuff can be accessed via /proc/*/fd/*, and
> > it _can_ be closed under you.  So I'd suggest checking how your code
> > copes with similar for pipes, FIFOs, epoll, etc., accessed that way...
> 
> I know all kinds of interesting stuff can be accessed via /proc/*/fd/*,
> and it _can_ be closed under me.
> 
> Regarding sockets, I was accessing "struct socket" memory and
> "struct sock" memory which are outside of "struct inode" memory.
> 
> But regarding other objects, I am accessing "struct dentry" memory,
> "struct super_block" memory and "struct inode" memory. I'm expecting
> that these memory can't be kfree()d as long as "struct path" holds
> a reference. Is my expectation correct?
> 
> > 
> > We are _not_ going to be checking that in fs/open.c - the stuff found
> > via /proc/*/fd/* can have the associated file closed by the time
> > we get to calling ->open() and we won't know that until said call.
> 
> OK. Then, fixing TOMOYO side is the correct way.
> 
> > 
> >> Q2: Do you see any problem with using f->f_path.dentry->d_inode ?
> >> Do we need to use d_backing_inode() or d_inode() ?
> > 
> > Huh?  What's wrong with file_inode(f), in the first place?  And
> > just when can that be NULL, while we are at it?
> 
> Oh, I was not aware of file_inode(). Thanks.
> 
> > 
> >>>  static int tomoyo_inode_getattr(const struct path *path)
> >>>  {
> >>> + /* It is not safe to call tomoyo_get_socket_name(). */
> >>> + if (path->dentry->d_inode && S_ISSOCK(path->dentry->d_inode->i_mode))
> >>> + return 0;
> > 
> > Can that be called for a negative?
> > 
> 
> I check for NULL when I'm not sure it is guaranteed to hold a valid pointer.
> You meant "we are sure that path->dentry->d_inode is valid", don't you?
> 
> By the way, "negative" associates with IS_ERR() range. I guess that
> "NULL" is the better name...
> 
> Anyway, here is V2 patch.
> 
> From c63c4074300921d6d1c33c3b8dc9c84ebfededf5 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa 
> Date: Sat, 22 Jun 2019 13:14:26 +0900
> Subject: [PATCH v2] tomoyo: Don't check open/getattr permission on sockets.
> 
> syzbot is reporting that use of SOCKET_I()->sk from open() can result in
> use after free problem [1], for socket's inode is still reachable via
> /proc/pid/fd/n despite destruction of SOCKET_I()->sk already completed.
> 
> But there is no point with calling security_file_open() on sockets
> because open("/proc/pid/fd/n", !O_PATH) on sockets fails with -ENXIO.
> 
> There is some point with calling security_inode_getattr() on sockets
> because stat("/proc/pid/fd/n") and fstat(open("/proc/pid/fd/n", O_PATH))
> are valid. If we want to access "struct sock"->sk_{family,type,protocol}
> fields, we will need to use security_socket_post_create() hook and
> security_inode_free() hook in order to remember these fields because
> security_sk_free() hook is called before the inode is destructed. But
> since information which can be protected by checking
> security_inode_getattr() on sockets is trivial, let's not be bothered by
> "struct inode"->i_security management.
> 
> There is point with calling security_file_ioctl() on sockets. Since
> ioctl(open("/proc/pid/fd/n", O_PATH)) is invalid, security_file_ioctl()
> on sockets should remain safe.
> 
> [1] 
> https://syzkaller.appspot.com/bug?id=73d590010454403d55164cca23bd0565b1eb3b74
> 
> Signed-off-by: Tetsuo Handa 
> Reported-by: syzbot 
> ---
>  security/tomoyo/tomoyo.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
> index 716c92e..8ea3f5d 100644
> --- a/security/tomoyo/tomoyo.c
> +++ b/security/tomoyo/tomoyo.c
> @@ -126,6 +126,9 @@ static int tomoyo_bprm_check_security(struct linux_binprm 
> *bprm)
>   */
>  static int tomoyo_inode_getattr(const struct path *path)
>  {
> + /* It is not safe to call tomoyo_get_socket_name(). */
> + if (S_ISSOCK(d_inode(path->dentry)->i_mode))
> + return 0;
>   return tomoyo_path_perm(TOMOYO_TYPE_GETATTR, path, NULL);
>  }
>  
> @@ -316,6 +319,9 @@ static int tomoyo_file_open(struct file *f)
>   /* Don't check read permission here if called from do_execve(). */
>   if (current->in_execve)
>   return 0;
> + /* Sockets can't be opened by open(). */
> + if (S_ISSOCK(file_inode(f)->i_mode))
> + return 0;
>   return tomoyo_check_open_permission(tomoyo_domain(), &f->f_path,
>   f->f_flags);
>  }
> -- 

What happened to this patch?

Also, isn't the same bug in other places too?:

- tomoyo_path_chmod()
- 

[PATCH -next] net: mediatek: remove set but not used variable 'status'

[Mao Wenan]

Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/mediatek/mtk_eth_soc.c: In function mtk_handle_irq:
drivers/net/ethernet/mediatek/mtk_eth_soc.c:1951:6: warning: variable status 
set but not used [-Wunused-but-set-variable]

It is not used since commit 296c9120752b ("net: ethernet: mediatek: Add 
MT7628/88 SoC support")
Signed-off-by: Mao Wenan 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8ddbb8d..bb7d623 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1948,9 +1948,7 @@ static irqreturn_t mtk_handle_irq_tx(int irq, void *_eth)
 static irqreturn_t mtk_handle_irq(int irq, void *_eth)
 {
struct mtk_eth *eth = _eth;
-   u32 status;
 
-   status = mtk_r32(eth, MTK_PDMA_INT_STATUS);
if (mtk_r32(eth, MTK_PDMA_INT_MASK) & MTK_RX_DONE_INT) {
if (mtk_r32(eth, MTK_PDMA_INT_STATUS) & MTK_RX_DONE_INT)
mtk_handle_irq_rx(irq, _eth);
-- 
2.7.4

Re: linux-next: build warning after merge of the soundwire tree

[Vinod Koul]

On 22-08-19, 16:04, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the soundwire tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> drivers/soundwire/intel.c: In function 'sdw_master_read_intel_prop':
> drivers/soundwire/intel.c:829:12: warning: unused variable 'i' 
> [-Wunused-variable]
>   int nval, i;
> ^
> drivers/soundwire/intel.c:829:6: warning: unused variable 'nval' 
> [-Wunused-variable]
>   int nval, i;
>   ^~~~
> 
> Introduced by commit
> 
>   085f4ace103d ("soundwire: intel: read mclk_freq property from firmware")

Thanks Stephen for the report. I have fixed it up by removing these.
Posting the patch now

Thanks
-- 
~Vinod

Re: [PATCH v1 41/63] Input: touchscreen: Atmel: Enable IRQ_DISABLE_UNLAZY flag for interrupt

[Jiada Wang]

Hi Dmitry

On 2019/08/17 2:26, Dmitry Torokhov wrote:

On Fri, Aug 16, 2019 at 05:35:36PM +0900, Jiada Wang wrote:

From: Bhuvanesh Surachari 

The de-/serializer driver has defined only irq_mask "ds90ub927_irq_mask" and
irq_unmask "ds90ub927_irq_unmask" callback functions. And de-/serializer
driver doesn't implement the irq_disable and irq_enable callback functions.
Hence inorder to invoke irq_mask callback function when disable_irq_nosync is
called the IRQ_DISABLE_UNLAZY interrupt flag should be set. If not the
disable_irq_nosync will just increment the depth field in the irq
descriptor only once as shown below.

disable_irq_nosync
  __disable_irq_nosync
   __disable_irq (desc->depth++)
irq_disable
 if irq_disable present ---> if IRQ_DISABLE_UNLAZYflag set
  |  no  |
  yes |  yes |
  |  |
  desc->irq_data.chip->irq_disable   desc->irq_data.chip->irq_unmask
  (ds90ub927_irq_mask)
   disable_irq
__disable_irq_nosync
 __disable_irq
(desc->depth++)
But the enable_irq will try to decrement the depth field twice which generates
the backtrace stating "Unbalanced enable for irq 293". This is because there is
no IRQ_DISABLE_UNLAZY flag check while calling irq_unmask callback function
of the "ds90ub927_irq_unmask" de-/serializer via enable_irq.

enable_irq
  __enable_irq (desc->depth--)
   irq_enable
if irq_enable present -> desc->irq_data.chip->irq_unmask
   |no(ds90ub927_irq_unmask)
   yes |enable_irq
   | __enable_irq (desc->depth--)
 (desc->irq_data.chip->irq_enable)


I'd prefer if we instead did not use the disable_irq_nosync() in the
driver.


sorry for the mistake, during forward port,
I have already eliminated disable_irq_nosync(),
so this patch is no longer needed,
will drop it in v2 patch-set

Thanks，
Jiada


Thanks.

[PATCH] xfs: Use BUG_ON rather than BUG() to remove unreachable code

[Austin Kim]

Code after BUG is unreachable since system would be crashed
after the call to BUG is made.
So change BUG_ON instead of BUG() to remove unreachable code.
---
 fs/xfs/xfs_mount.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 322da69..a681808 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -213,13 +213,7 @@ xfs_initialize_perag(
goto out_hash_destroy;
 
spin_lock(&mp->m_perag_lock);
-   if (radix_tree_insert(&mp->m_perag_tree, index, pag)) {
-   BUG();
-   spin_unlock(&mp->m_perag_lock);
-   radix_tree_preload_end();
-   error = -EEXIST;
-   goto out_hash_destroy;
-   }
+   BUG_ON(radix_tree_insert(&mp->m_perag_tree, index, pag));
spin_unlock(&mp->m_perag_lock);
radix_tree_preload_end();
/* first new pag is fully initialized */
-- 
2.6.2

[PATCH] mm/memcg: return value of the function mem_cgroup_from_css() is not checked

[Yizhuo]

Inside function mem_cgroup_wb_domain(), the pointer memcg
could be NULL via mem_cgroup_from_css(). However, this pointer is
not checked and directly dereferenced in the if statement,
which is potentially unsafe.

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

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 661f046ad318..bd84bdaed3b0 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3665,7 +3665,7 @@ struct wb_domain *mem_cgroup_wb_domain(struct 
bdi_writeback *wb)
 {
struct mem_cgroup *memcg = mem_cgroup_from_css(wb->memcg_css);
 
-   if (!memcg->css.parent)
+   if (!memcg || !memcg->css.parent)
return NULL;
 
return &memcg->cgwb_domain;
-- 
2.17.1

Re: [PATCH] ASoC: sun4i-i2s: incorrect regmap for A83t

[Maxime Ripard]

Hi Markus,

On Wed, Aug 21, 2019 at 06:23:20PM +0200, codekip...@gmail.com wrote:
> From: Marcus Cooper 
>
> Fixes: 21faaea1343f ("ASoC: sun4i-i2s: Add support for A83T")
> Signed-off-by: Marcus Cooper 

The patch is ok, but you should have a commit log here.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 1/2] clocksource/drivers/timer-of: Do not warn on deferred probe

[Daniel Lezcano]

On 21/08/2019 17:02, Jon Hunter wrote:
> Deferred probe is an expected return value for clk_get() on many
> platforms. The driver deals with it properly, so there's no need
> to output a warning that may potentially confuse users.
> 
> Signed-off-by: Jon Hunter 
> ---

Applied, thanks!

>  drivers/clocksource/timer-of.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clocksource/timer-of.c b/drivers/clocksource/timer-of.c
> index 80542289fae7..d8c2bd4391d0 100644
> --- a/drivers/clocksource/timer-of.c
> +++ b/drivers/clocksource/timer-of.c
> @@ -113,8 +113,10 @@ static __init int timer_of_clk_init(struct device_node 
> *np,
>   of_clk->clk = of_clk->name ? of_clk_get_by_name(np, of_clk->name) :
>   of_clk_get(np, of_clk->index);
>   if (IS_ERR(of_clk->clk)) {
> - pr_err("Failed to get clock for %pOF\n", np);
> - return PTR_ERR(of_clk->clk);
> + ret = PTR_ERR(of_clk->clk);
> + if (ret != -EPROBE_DEFER)
> + pr_err("Failed to get clock for %pOF\n", np);
> + goto out;
>   }
>  
>   ret = clk_prepare_enable(of_clk->clk);
> 


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH v2 1/1] iio: core: Fix fractional format generation

[Alexander Stein]

In case the result is -0.3252 tmp0 is 0 after the div_s64_rem, so tmp0 is
non-negative which results in an output of 0.3252.
Fix this by explicitly handling the negative sign ourselves.

Signed-off-by: Alexander Stein 
---
Changes in v2:
* Support vals[0] >= and vals[1] < 0 in IIO_VAL_FRACTIONAL
* Note: IIO_VAL_FRACTIONAL is untested, as I lack hardware
* Note2: Currently IIO_VAL_FRACTIONAL is only called with vals[1] from
 in-kernel drivers AFAICS

 drivers/iio/industrialio-core.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 245b5844028d..247338142c87 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -568,6 +568,7 @@ static ssize_t __iio_format_value(char *buf, size_t len, 
unsigned int type,
 {
unsigned long long tmp;
int tmp0, tmp1;
+   char *sign;
bool scale_db = false;
 
switch (type) {
@@ -593,11 +594,17 @@ static ssize_t __iio_format_value(char *buf, size_t len, 
unsigned int type,
tmp = div_s64((s64)vals[0] * 10LL, vals[1]);
tmp1 = vals[1];
tmp0 = (int)div_s64_rem(tmp, 10, &tmp1);
-   return snprintf(buf, len, "%d.%09u", tmp0, abs(tmp1));
+   if (vals[1] < 0) {
+   sign = vals[0] >= 0 ? "-" : "";
+   } else {
+   sign = vals[0] < 0 ? "-" : "";
+   }
+   return snprintf(buf, len, "%s%u.%09u", sign, abs(tmp0), 
abs(tmp1));
case IIO_VAL_FRACTIONAL_LOG2:
+   sign = vals[0] < 0 ? "-" : "";
tmp = shift_right((s64)vals[0] * 10LL, vals[1]);
tmp0 = (int)div_s64_rem(tmp, 10LL, &tmp1);
-   return snprintf(buf, len, "%d.%09u", tmp0, abs(tmp1));
+   return snprintf(buf, len, "%s%u.%09u", sign, abs(tmp0), 
abs(tmp1));
case IIO_VAL_INT_MULTIPLE:
{
int i;
-- 
2.23.0

[PATCH] arm64: defconfig: Enable SM8150 GCC and pinctrl driver

[Vinod Koul]

Enable GCC config CONFIG_SM_GCC_8150 and pinctrl config
CONFIG_PINCTRL_SM8150 to make it possible to boot the SM8150 MTP.

Signed-off-by: Vinod Koul 
---
 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..09be33cb4d76 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -403,6 +403,7 @@ CONFIG_PINCTRL_QCS404=y
 CONFIG_PINCTRL_QDF2XXX=y
 CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
 CONFIG_PINCTRL_SDM845=y
+CONFIG_PINCTRL_SM8150=y
 CONFIG_GPIO_DWAPB=y
 CONFIG_GPIO_MB86S7X=y
 CONFIG_GPIO_PL061=y
@@ -690,6 +691,7 @@ CONFIG_MSM_MMCC_8996=y
 CONFIG_MSM_GCC_8998=y
 CONFIG_QCS_GCC_404=y
 CONFIG_SDM_GCC_845=y
+CONFIG_SM_GCC_8150=y
 CONFIG_HWSPINLOCK=y
 CONFIG_HWSPINLOCK_QCOM=y
 CONFIG_ARM_MHU=y
-- 
2.20.1

linux-next: build warning after merge of the soundwire tree

[Stephen Rothwell]

Hi all,

After merging the soundwire tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

drivers/soundwire/intel.c: In function 'sdw_master_read_intel_prop':
drivers/soundwire/intel.c:829:12: warning: unused variable 'i' 
[-Wunused-variable]
  int nval, i;
^
drivers/soundwire/intel.c:829:6: warning: unused variable 'nval' 
[-Wunused-variable]
  int nval, i;
  ^~~~

Introduced by commit

  085f4ace103d ("soundwire: intel: read mclk_freq property from firmware")

-- 
Cheers,
Stephen Rothwell


pgpy4buyBRNCl.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 0/7] renesas, cmt: DT Binding Documentation and Minor Driver Updates V2

[Daniel Lezcano]

On 20/08/2019 14:34, Magnus Damm wrote:
> renesas, cmt: DT Binding Documentation and Minor Driver Updates V2
> 
> [PATCH v2 1/7] dt-bindings: timer: renesas, cmt: Add CMT0234 to sh73a0 and 
> r8a7740
> [PATCH v2 2/7] dt-bindings: timer: renesas, cmt: Update CMT1 on sh73a0 and 
> r8a7740
> [PATCH v2 3/7] dt-bindings: timer: renesas, cmt: Add CMT0 and CMT1 to r8a7792
> [PATCH v2 4/7] dt-bindings: timer: renesas, cmt: Add CMT0 and CMT1 to r8a77995
> [PATCH v2 5/7] dt-bindings: timer: renesas, cmt: Update R-Car Gen3 CMT1 usage
> [PATCH v2 6/7] clocksource/drivers/sh_cmt: r8a7740 and sh73a0 SoC-specific 
> match
> [PATCH v2 7/7] clocksource/drivers/sh_cmt: Document "cmt-48" as deprecated 
> 
> This series collect the following rather trivial changes for the CMT driver:
> - Add 32-bit CMT0234 and convert CMT1 DT binding docs on sh73a0 and r8a7740.
> - Add documentation for the CMT on the R-Car Gen2 V2H (r8a7792) SoC.
> - Add missing R-Car Gen3 DT binding documentation for D3 (r8a77995).
> - Update the R-Car Gen3 DT documentation to reflect current usage.
> - Introduce SoC-specific matching in the driver for CMT1 on sh73a0 and sh73a0.
> - Document old "cmt-48" binding as deprecated in the driver.
> 
> Since V1 the only update is the addition of reviewed-by from Simon - thanks!
> 
> Please see each individual patch for more detailed information.
> 
> Signed-off-by: Magnus Damm 
> Reviewed-by: Geert Uytterhoeven  [Patch 3-5]
> Reviewed-by: Rob Herring  [Patch 1-5]
> Reviewed-by: Simon Horman 
> ---

Applied, thanks!


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH v7 4/4] ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards

[Krzysztof Kozlowski]

Add support for i.MX6UL modules from Kontron Electronics GmbH (before
acquisition: Exceet Electronics) and evalkit boards based on it:

1. N6310 SOM: i.MX6 UL System-on-Module, a 25x25 mm solderable module
   (LGA pads and pin castellations) with 256 MB RAM, 1 MB NOR-Flash,
   256 MB NAND and other interfaces,
2. N6310 S: evalkit, w/wo eMMC, without display,
3. N6310 S 43: evalkit with 4.3" display,

The work is based on Exceet/Kontron source code (GPLv2) with numerous
changes:
1. Reorganize files,
2. Rename Exceet -> Kontron,
3. Rename models/compatibles to match newest Kontron product naming,
4. Fix coding style errors and adjust to device tree coding guidelines,
5. Fix DTC warnings,
6. Extend compatibles so eval boards inherit the SoM compatible,
7. Use defines instead of GPIO and interrupt flag values,
8. Use proper vendor compatible for Macronix SPI NOR,
9. Replace deprecated bindings with proper ones,
10. Sort nodes alphabetically,
11. Remove Admatec display nodes (not yet supported).

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Rob Herring 
Reviewed-by: Frieder Schrempf 
Reviewed-by: Fabio Estevam 

---

Changes since v6:
1. None

Changes since v5:
1. Split Documentation/devicetree/bindings/arm/fsl.yaml update to
   separate patch.

Changes since v4:
1. Split Documentation/devicetree/bindings/eeprom/at25.txt update to
   separate patch.

Changes since v3, after Shawn's review:
1. Split bindings update to patch 2/3,
2. Remove unsupported displays from (Admatec),
3. Remove N6310 S 50 board (same as N6310 S 43 since there is no Admatec
   display),
4. Order iomux nodes by name, minor cleanup,
5. Use wakeup-source instead of enable-sdio-wakeup,
6. Add review tags.

Changes since v2, after Fabio's review:
1. Add "imx6ul" compatible to board name (that's what I understood from
   review),
2. Add vendor/device prefix to eeprom and document the compatible,
3. Use "admatecde" as vendor compatible to avoid confusion with Admatec
   AG in Switzerland (also making LCD panels),
4. Use generic names for nodes,
5. Use IRQ_TYPE_LEVEL_LOW,
6. Move iomux to the end of files,
7. Remove regulators node (include regulators in top level),
8. Remove cpu clock-frequency,
9. Other minor fixes pointed by Fabio.

Changes since v1, after Frieder's review:
1. Remove unneeded license notes,
2. Add Kontron copyright (2018),
3. Rename the files/models/compatibles to new naming - N6310,
4. Remove unneeded CPU operating points override,
5. Switch regulator nodes into simple children nodes without addresses
   (so not simple bus),
6. Use proper vendor compatible for Macronix SPI NOR.
---
 arch/arm/boot/dts/Makefile|   2 +
 .../boot/dts/imx6ul-kontron-n6310-s-43.dts| 102 +
 arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts  | 420 ++
 .../boot/dts/imx6ul-kontron-n6310-som.dtsi| 134 ++
 4 files changed, 658 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
 create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
 create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9159fa2cea90..747eef501f95 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -569,6 +569,8 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-geam.dtb \
imx6ul-isiot-emmc.dtb \
imx6ul-isiot-nand.dtb \
+   imx6ul-kontron-n6310-s.dtb \
+   imx6ul-kontron-n6310-s-43.dtb \
imx6ul-liteboard.dtb \
imx6ul-opos6uldev.dtb \
imx6ul-pico-hobbit.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts 
b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
new file mode 100644
index ..5bad29683cc3
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 exceet electronics GmbH
+ * Copyright (C) 2018 Kontron Electronics GmbH
+ * Copyright (c) 2019 Krzysztof Kozlowski 
+ */
+
+#include "imx6ul-kontron-n6310-s.dts"
+
+/ {
+   model = "Kontron N6310 S 43";
+   compatible = "kontron,imx6ul-n6310-s-43", "kontron,imx6ul-n6310-s",
+"kontron,imx6ul-n6310-som", "fsl,imx6ul";
+
+   backlight {
+   compatible = "pwm-backlight";
+   pwms = <&pwm7 0 500>;
+   brightness-levels = <0 4 8 16 32 64 128 255>;
+   default-brightness-level = <6>;
+   status = "okay";
+   };
+};
+
+&i2c4 {
+   touchscreen@5d {
+   compatible = "goodix,gt928";
+   reg = <0x5d>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_cap_touch>;
+   interrupt-parent = <&gpio5>;
+   interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+   reset-gpios = <&gpio5 8 GPIO_ACTIVE_HIGH>;
+   irq-gpios = <&gpio5 6 GPIO_ACTIVE_HIGH>;
+   };
+};
+
+&lcdif {
+   pinctrl-names = "default";
+

[PATCH v7 2/4] dt-bindings: eeprom: at25: Add Anvo ANV32E61W

[Krzysztof Kozlowski]

Document the compatible for ANV32E61W 64kb Serial SPI non-volatile SRAM.
Although it is a SRAM device, it can be accessed through EEPROM
interface. At least until there is no proper SRAM driver support for
it.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Fabio Estevam 

---

Changes since v5:
1. None

Changes since v4:
1. Update commit msg.
---
 Documentation/devicetree/bindings/eeprom/at25.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/eeprom/at25.txt 
b/Documentation/devicetree/bindings/eeprom/at25.txt
index b3bde97dc199..42577dd113dd 100644
--- a/Documentation/devicetree/bindings/eeprom/at25.txt
+++ b/Documentation/devicetree/bindings/eeprom/at25.txt
@@ -3,6 +3,7 @@ EEPROMs (SPI) compatible with Atmel at25.
 Required properties:
 - compatible : Should be ",", and generic value "atmel,at25".
   Example "," values:
+"anvo,anv32e61w"
 "microchip,25lc040"
 "st,m95m02"
 "st,m95256"
-- 
2.17.1

[PATCH v7 1/4] dt-bindings: vendor-prefixes: Add Anvo-Systems

[Krzysztof Kozlowski]

Add vendor prefix for Anvo-Systems Dresden GmbH.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Rob Herring 

---

Changes since v4:
None

Changes since v3:
1. Add Rob's tag,
2. Remove Admatec (not needed anymore).

Changes since v2:
1. Use admatecde vendor prefix.
2. Add Anvo-Systems Dresden GmbH.

Changes since v1:
New patch
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6992ffab..519889f5aec8 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -81,6 +81,8 @@ patternProperties:
 description: Analogix Semiconductor, Inc.
   "^andestech,.*":
 description: Andes Technology Corporation
+  "^anvo,.*":
+description: Anvo-Systems Dresden GmbH
   "^apm,.*":
 description: Applied Micro Circuits Corporation (APM)
   "^aptina,.*":
-- 
2.17.1

[PATCH v7 3/4] dt-bindings: arm: fsl: Add Kontron i.MX6UL N6310 compatibles

[Krzysztof Kozlowski]

Add the compatibles for Kontron i.MX6UL N6310 SoM and boards.

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v6:
1. Split entries to pass the dtbs_check.

Changes since v5:
New patch
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7294ac36f4c0..1f440817fc03 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -161,6 +161,20 @@ properties:
 items:
   - enum:
   - fsl,imx6ul-14x14-evk  # i.MX6 UltraLite 14x14 EVK Board
+  - kontron,imx6ul-n6310-som  # Kontron N6310 SOM
+  - const: fsl,imx6ul
+
+  - description: Kontron N6310 S Board
+items:
+  - const: kontron,imx6ul-n6310-s
+  - const: kontron,imx6ul-n6310-som
+  - const: fsl,imx6ul
+
+  - description: Kontron N6310 S 43 Board
+items:
+  - const: kontron,imx6ul-n6310-s-43
+  - const: kontron,imx6ul-n6310-s
+  - const: kontron,imx6ul-n6310-som
   - const: fsl,imx6ul
 
   - description: i.MX6ULL based Boards
-- 
2.17.1

Re: [PATCH -next] cpufreq: qcom-hw: remove set but not used variable 'prev_cc'

[Viresh Kumar]

On 22-08-19, 10:25, Sibi Sankar wrote:
> @YueHaibing thanks for the patch.
> 
> On 2019-08-22 08:10, Viresh Kumar wrote:
> > On 21-08-19, 20:14, YueHaibing wrote:
> > > drivers/cpufreq/qcom-cpufreq-hw.c: In function
> > > qcom_cpufreq_hw_read_lut:
> > > drivers/cpufreq/qcom-cpufreq-hw.c:89:38: warning:
> > >  variable prev_cc set but not used [-Wunused-but-set-variable]
> > > 
> > > It is not used since commit 3003e75a5045 ("cpufreq:
> > > qcom-hw: Update logic to detect turbo frequency")
> > > 
> > > Reported-by: Hulk Robot 
> > > Signed-off-by: YueHaibing 
> > > ---
> > >  drivers/cpufreq/qcom-cpufreq-hw.c | 3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
> > > b/drivers/cpufreq/qcom-cpufreq-hw.c
> > > index 3eea197..a9ae2f8 100644
> > > --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> > > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> > > @@ -86,7 +86,7 @@ static int qcom_cpufreq_hw_read_lut(struct device
> > > *cpu_dev,
> > >   struct cpufreq_policy *policy,
> > >   void __iomem *base)
> > >  {
> > > - u32 data, src, lval, i, core_count, prev_cc = 0, prev_freq = 0,
> > > freq;
> > > + u32 data, src, lval, i, core_count, prev_freq = 0, freq;
> > >   u32 volt;
> > >   struct cpufreq_frequency_table  *table;
> > > 
> > > @@ -139,7 +139,6 @@ static int qcom_cpufreq_hw_read_lut(struct
> > > device *cpu_dev,
> > >   break;
> > >   }
> > > 
> > > - prev_cc = core_count;
> > >   prev_freq = freq;
> > >   }
> > 
> > @Sibi, you fine with this change ? I will merge it with the original
> > patch then.
> 
> yes the changes seem fine, I missed
> removing prev_cc.

Thanks. Merged into the original patch itself.

-- 
viresh

Re: [linux-next][PPC][bisected c7d8b7][gcc 6.4.1] build error at drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:1471

[Stephen Rothwell]

Hi Abdul,

On Thu, 22 Aug 2019 11:16:51 +0530 Abdul Haleem  
wrote:
>
> Today's linux-next kernel 5.3.0-rc5-next-20190820 failed to build on my
> powerpc machine
> 
> Build errors:
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c: In function amdgpu_exit:
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:1471:2: error: implicit
> declaration of function mmu_notifier_synchronize
> [-Werror=implicit-function-declaration]
>   mmu_notifier_synchronize();
>   ^~~~ 
> cc1: some warnings being treated as errors
> make[4]: *** [drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o] Error 1
> make[3]: *** [drivers/gpu/drm/amd/amdgpu] Error 2
> 
> It was introduced with commit c7d8b7 (hmm: use mmu_notifier_get/put for
> 'struct hmm')

This should have been fixed in next-20190821.

-- 
Cheers,
Stephen Rothwell


pgpdSfWDHzSJc.pgp
Description: OpenPGP digital signature

[PATCH RESEND] i2c: mediatek: disable zero-length transfers for mt8183

[Hsin-Yi Wang]

When doing i2cdetect quick write mode, we would get transfer
error ENOMEM, and i2cdetect shows there's no device at the address.
Quoting from mt8183 datasheet, the number of transfers to be
transferred in one transaction should be set to bigger than 1,
so we should forbid zero-length transfer and update functionality.

Incorrect return:
localhost ~ # i2cdetect -q -y 0
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

After this patch:
localhost ~ #  i2cdetect -q -y 0
Error: Can't use SMBus Quick Write command on this bus

localhost ~ #  i2cdetect -y 0
Warning: Can't use SMBus Quick Write command, will skip some addresses
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:
10:
20:
30: -- -- -- -- -- -- -- --
40:
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60:
70:

Reported-by: Alexandru M Stan 
Signed-off-by: Hsin-Yi Wang 
---
Previous patch and discussion:
http://patchwork.ozlabs.org/patch/1042684/
---
 drivers/i2c/busses/i2c-mt65xx.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 252edb433fdf..2842ca4b8c3b 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -234,6 +234,10 @@ static const struct i2c_adapter_quirks mt7622_i2c_quirks = 
{
.max_num_msgs = 255,
 };
 
+static const struct i2c_adapter_quirks mt8183_i2c_quirks = {
+   .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
 static const struct mtk_i2c_compatible mt2712_compat = {
.regs = mt_i2c_regs_v1,
.pmic_i2c = 0,
@@ -298,6 +302,7 @@ static const struct mtk_i2c_compatible mt8173_compat = {
 };
 
 static const struct mtk_i2c_compatible mt8183_compat = {
+   .quirks = &mt8183_i2c_quirks,
.regs = mt_i2c_regs_v2,
.pmic_i2c = 0,
.dcm = 0,
@@ -870,7 +875,11 @@ static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id)
 
 static u32 mtk_i2c_functionality(struct i2c_adapter *adap)
 {
-   return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+   if (adap->quirks->flags & I2C_AQ_NO_ZERO_LEN)
+   return I2C_FUNC_I2C |
+   (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
+   else
+   return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
 }
 
 static const struct i2c_algorithm mtk_i2c_algorithm = {
@@ -933,8 +942,8 @@ static int mtk_i2c_probe(struct platform_device *pdev)
i2c->dev = &pdev->dev;
i2c->adap.dev.parent = &pdev->dev;
i2c->adap.owner = THIS_MODULE;
-   i2c->adap.algo = &mtk_i2c_algorithm;
i2c->adap.quirks = i2c->dev_comp->quirks;
+   i2c->adap.algo = &mtk_i2c_algorithm;
i2c->adap.timeout = 2 * HZ;
i2c->adap.retries = 1;
 
-- 
2.20.1

Re: [PATCH] mm: consolidate pgtable_cache_init() and pgd_cache_init()

[Mike Rapoport]

On Wed, Aug 21, 2019 at 06:17:12PM +0200, Marc Gonzalez wrote:
> On 21/08/2019 17:06, Mike Rapoport wrote:
> 
> > Both pgtable_cache_init() and pgd_cache_init() are used to initialize kmem
> > cache for page table allocations on several architectures that do not use
> > PAGE_SIZE tables for one or more levels of the page table hierarchy.
> > 
> > Most architectures do not implement these functions and use __week default
> 
> s/week/weak  ?

Sure, thanks!

-- 
Sincerely yours,
Mike.

[linux-next][PPC][bisected c7d8b7][gcc 6.4.1] build error at drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:1471

[Abdul Haleem]

Greeting's

Today's linux-next kernel 5.3.0-rc5-next-20190820 failed to build on my
powerpc machine

Build errors:
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c: In function amdgpu_exit:
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:1471:2: error: implicit
declaration of function mmu_notifier_synchronize
[-Werror=implicit-function-declaration]
  mmu_notifier_synchronize();
  ^~~~ 
cc1: some warnings being treated as errors
make[4]: *** [drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o] Error 1
make[3]: *** [drivers/gpu/drm/amd/amdgpu] Error 2

It was introduced with commit c7d8b7 (hmm: use mmu_notifier_get/put for
'struct hmm')

error disappears when commit is reverted.

-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre

Re: [PATCH v1 06/63] Input: atmel_mxt_ts - output status from T42 Touch Suppression

[Jiada Wang]

Hi

On 2019/08/17 2:34, Dmitry Torokhov wrote:

On Fri, Aug 16, 2019 at 05:30:33PM +0900, Jiada Wang wrote:

From: Nick Dyer 

Signed-off-by: Nick Dyer 
Acked-by: Benson Leung 
Acked-by: Yufeng Shen 
(cherry picked from ndyer/linux/for-upstream commit 
ab95b5a30d2c098daaa9f88d9fcfae7eb516)
Signed-off-by: George G. Davis 
Signed-off-by: Jiada Wang 
---
  drivers/input/touchscreen/atmel_mxt_ts.c | 25 
  1 file changed, 25 insertions(+)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index a75c35c6f9f9..9226ec528adf 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -155,6 +155,9 @@ struct t37_debug {
  #define MXT_RESET_VALUE   0x01
  #define MXT_BACKUP_VALUE  0x55
  
+/* Define for MXT_PROCI_TOUCHSUPPRESSION_T42 */

+#define MXT_T42_MSG_TCHSUP BIT(0)
+
  /* T100 Multiple Touch Touchscreen */
  #define MXT_T100_CTRL 0
  #define MXT_T100_CFG1 1
@@ -323,6 +326,8 @@ struct mxt_data {
u8 T9_reportid_max;
u16 T18_address;
u8 T19_reportid;
+   u8 T42_reportid_min;
+   u8 T42_reportid_max;
u16 T44_address;
u8 T48_reportid;
u8 T100_reportid_min;
@@ -978,6 +983,17 @@ static void mxt_proc_t100_message(struct mxt_data *data, 
u8 *message)
data->update_input = true;
  }
  
+static void mxt_proc_t42_messages(struct mxt_data *data, u8 *msg)

+{
+   struct device *dev = &data->client->dev;
+   u8 status = msg[1];
+
+   if (status & MXT_T42_MSG_TCHSUP)
+   dev_info(dev, "T42 suppress\n");
+   else
+   dev_info(dev, "T42 normal\n");


dev_dbg(). There is no need to flood the logs with this. I'd assume this
is for assisting in bringup. Should there be some more generic way of
monitoring the status?


will replace with dev_dbg() in v2 patchset

thanks,
Jiada

RE: [RFC PATCH] powerpc: Convert ____flush_dcache_icache_phys() to C

[Alastair D'Silva]

On Thu, 2019-08-22 at 07:06 +0200, Christophe Leroy wrote:
> 
> Le 22/08/2019 à 02:27, Alastair D'Silva a écrit :
> > On Wed, 2019-08-21 at 22:27 +0200, Christophe Leroy wrote:
> > > Le 20/08/2019 à 06:36, Alastair D'Silva a écrit :
> > > > On Fri, 2019-08-16 at 15:52 +, Christophe Leroy wrote:
> > > 
> > > [...]
> > > 
> > > > Thanks Christophe,
> > > > 
> > > > I'm trying a somewhat different approach that requires less
> > > > knowledge
> > > > of assembler. Handling of CPU_FTR_COHERENT_ICACHE is outside
> > > > this
> > > > function. The code below is not a patch as my tree is a bit
> > > > messy,
> > > > sorry:
> > > 
> > > Can we be 100% sure that GCC won't add any code accessing some
> > > global
> > > data or stack while the Data MMU is OFF ?
> > > 
> > > Christophe
> > > 
> > 
> > +mpe
> > 
> > I'm not sure how we would go about making such a guarantee, but
> > I've
> > tied every variable used to a register and addr is passed in a
> > register, so there is no stack usage, and every call in there only
> > operates on it's operands.
> > 
> > The calls to the inline cache helpers (for the PPC32 case) are all
> > constants, so I can't see a reasonable scenario where there would
> > be a
> > function call and reordered to after the DR bit is turned off, but
> > I
> > guess if we want to be paranoid, we could always add an mb() call
> > before the DR bit is manipulated to prevent the compiler from
> > reordering across the section where the data MMU is disabled.
> > 
> > 
> 
> Anyway, I think the benefit of converting that function to C is
> pretty 
> small. flush_dcache_range() and friends were converted to C mainly
> in 
> order to inline them. But this __flush_dcache_icache_phys() is too
> big 
> to be worth inlining, yet small and stable enough to remain in
> assembly 
> for the time being.
> 
I disagree on this point, after converting it to C, using
44x/currituck.defconfig, the compiler definitely will inline it (noting
that there is only 1 caller of it):

0134 :
 134:   94 21 ff f0 stwur1,-16(r1)
 138:   3d 20 00 00 lis r9,0
 13c:   81 29 00 00 lwz r9,0(r9)
 140:   7c 08 02 a6 mflrr0
 144:   38 81 00 0c addir4,r1,12
 148:   90 01 00 14 stw r0,20(r1)
 14c:   91 21 00 0c stw r9,12(r1)
 150:   48 00 00 01 bl  150 
 154:   39 00 00 20 li  r8,32
 158:   39 43 10 00 addir10,r3,4096
 15c:   7c 69 1b 78 mr  r9,r3
 160:   7d 09 03 a6 mtctr   r8
 164:   7c 00 48 6c dcbst   0,r9
 168:   39 29 00 80 addir9,r9,128
 16c:   42 00 ff f8 bdnz164 
 170:   7c 00 04 ac hwsync
 174:   7c 69 1b 78 mr  r9,r3
 178:   7c 00 4f ac icbi0,r9
 17c:   39 29 00 80 addir9,r9,128
 180:   7f 8a 48 40 cmplw   cr7,r10,r9
 184:   40 9e ff f4 bne cr7,178 
 188:   7c 00 04 ac hwsync
 18c:   4c 00 01 2c isync
 190:   80 01 00 14 lwz r0,20(r1)
 194:   38 21 00 10 addir1,r1,16
 198:   7c 08 03 a6 mtlrr0
 19c:   48 00 00 00 b   19c 


> So I suggest you keep it aside your series for now, just move 
> PURGE_PREFETCHED_INS inside it directly as it will be the only
> remaining 
> user of it.
> 
> Christophe

-- 
Alastair D'Silva
Open Source Developer
Linux Technology Centre, IBM Australia
mob: 0423 762 819

[linux-next][PPC][bisected c7d8b7][gcc 6.4.1] build error at drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:1471

[Abdul Haleem]

Greeting's

Today's linux-next kernel 5.3.0-rc5-next-20190820 failed to build on my
powerpc machine

Build errors:
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c: In function amdgpu_exit:
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:1471:2: error: implicit
declaration of function mmu_notifier_synchronize
[-Werror=implicit-function-declaration]
  mmu_notifier_synchronize();
  ^~~~ 
cc1: some warnings being treated as errors
make[4]: *** [drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o] Error 1
make[3]: *** [drivers/gpu/drm/amd/amdgpu] Error 2

It was introduced with commit c7d8b7 (hmm: use mmu_notifier_get/put for
'struct hmm')

Reverting the commit fixes the issue.

-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre

Re: [PATCH v3 1/2] dt-bindings: phy: intel-emmc-phy: Add YAML schema for LGM eMMC PHY

[Ramuthevar, Vadivel MuruganX]

Hi Rob,

On 21/8/2019 9:35 PM, Rob Herring wrote:

On Wed, Aug 21, 2019 at 5:11 AM Ramuthevar,Vadivel MuruganX
 wrote:

From: Ramuthevar Vadivel Murugan 

Add a YAML schema to use the host controller driver with the
eMMC PHY on Intel's Lightning Mountain SoC.

Signed-off-by: Ramuthevar Vadivel Murugan 

---
changes in v3:
   - resolve 'make dt_binding_check' warnings

changes in v2:
   As per Rob Herring review comments, the following updates
  - change GPL-2.0 -> (GPL-2.0-only OR BSD-2-Clause)
  - filename is the compatible string plus .yaml
  - LGM: Lightning Mountain
  - update maintainer
  - add intel,syscon under property list
  - keep one example instead of two
---
  .../bindings/phy/intel,lgm-emmc-phy.yaml   | 59 ++
  1 file changed, 59 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml 
b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
new file mode 100644
index ..9342e33d8b02
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,lgm-emmc-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Lightning Mountain(LGM) eMMC PHY Device Tree Bindings
+
+maintainers:
+  - Ramuthevar Vadivel Murugan 
+
+properties:
+  "#phy-cells":
+const: 0
+
+  compatible:
+const: intel,lgm-emmc-phy
+
+  reg:
+maxItems: 1
+
+  syscon:

intel,syscon like the example. You must have used 5.2 as on 5.3-rc the
example will fail validation.
Thanks for the review comments,  used 5.3 for validation, after 
addressing the below comments

once again validate on both 5.2 and 5.3 as well.

+items:

Drop items as there is only 1.

agreed

+  $ref: "/schemas/types.yaml#definitions/phandle"
+
+  clocks:
+items:
+  - description: e-MMC phy module clock
+
+  clock-names:
+items:
+  - const: emmcclk
+
+  resets:
+maxItems: 1
+
+required:
+  - "#phy-cells"
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - resets
+  - ref

Not documented.


Agreed, will update

With Best Regards
Vadivel

+
+additionalProperties: false
+
+examples:
+  - |
+emmc_phy: emmc_phy {
+compatible = "intel,lgm-emmc-phy";
+reg = <0xe002 0x100>;
+intel,syscon = <&sysconf>;
+clocks = <&emmc>;
+clock-names = "emmcclk";
+#phy-cells = <0>;
+};
+
+...
--
2.11.0

Re: [PATCH v3 1/3] RISC-V: Issue a local tlbflush if possible.

[Atish Patra]

On Thu, 2019-08-22 at 06:27 +0200, h...@lst.de wrote:
> On Thu, Aug 22, 2019 at 04:01:24AM +, Atish Patra wrote:
> > The downside of this is that for every !cmask case in true SMP
> > (more
> > common probably) it will execute 2 extra cpumask instructions. As
> > tlbflush path is in performance critical path, I think we should
> > favor
> > more common case (SMP with more than 1 core).
> 
> Actually, looking at both the current mainline code, and the code
> from my
> cleanups tree I don't think remote_sfence_vma / __sbi_tlb_flush_range
> can ever be called with  NULL cpumask, as we always have a valid mm.
> 

Yes. You are correct.

As both cpumask functions here will crash if cpumask is null, we should
probably leave a harmless comment to warn the consequeunce of cpumask
being null.

> So this is a bit of a moot point, and we can drop andling that case
> entirely.  With that we can also use a simple if / else for the local
> cpu only vs remote case. 

Done.

>  Btw, what was the reason you didn't like
> using cpumask_any_but like x86, which should be more efficient than
> cpumask_test_cpu + hweigt?

I had it in v2 patch but removed as it can potentially return garbage
value if cpumask is empty. 

However, we are already checking empty cpumask before the local cpu
check. I will replace cpumask_test_cpu + hweight with
cpumask_any_but().

-- 
Regards,
Atish

[PATCH] x86/Hyper-V: Fix build error with CONFIG_HYPERV_TSCPAGE=N

[lantianyu1986]

From: Tianyu Lan 

Both Hyper-V tsc page and Hyper-V tsc MSR code use variable
hv_sched_clock_offset for their sched clock callback and so
define the variable regardless of CONFIG_HYPERV_TSCPAGE setting.

Signed-off-by: Tianyu Lan 
---
This patch is based on the top of 
"git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers/core".

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

diff --git a/drivers/clocksource/hyperv_timer.c 
b/drivers/clocksource/hyperv_timer.c
index dad8af198e20..c322ab4d3689 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -22,6 +22,7 @@
 #include 
 
 static struct clock_event_device __percpu *hv_clock_event;
+static u64 hv_sched_clock_offset __ro_after_init;
 
 /*
  * If false, we're using the old mechanism for stimer0 interrupts
@@ -215,7 +216,6 @@ EXPORT_SYMBOL_GPL(hyperv_cs);
 #ifdef CONFIG_HYPERV_TSCPAGE
 
 static struct ms_hyperv_tsc_page tsc_pg __aligned(PAGE_SIZE);
-static u64 hv_sched_clock_offset __ro_after_init;
 
 struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
 {
-- 
2.14.5

Re: [PATCH v2] fs: fs_parser: avoid NULL param->string to kstrtouint

[Al Viro]

On Wed, Aug 21, 2019 at 09:22:49PM -0700, Eric Biggers wrote:
> > > diff --git a/fs/fs_parser.c b/fs/fs_parser.c
> > > index 83b66c9e9a24..7498a44f18c0 100644
> > > --- a/fs/fs_parser.c
> > > +++ b/fs/fs_parser.c
> > > @@ -206,6 +206,9 @@ int fs_parse(struct fs_context *fc,
> > >   case fs_param_is_fd: {
> > >   switch (param->type) {
> > >   case fs_value_is_string:
> > > + if (!result->has_value)
> > > + goto bad_value;
> > > +
> > >   ret = kstrtouint(param->string, 0, &result->uint_32);
> > >   break;
> > >   case fs_value_is_file:
> > > -- 
> > > 2.17.1
> > 
> > Reviewed-by: Eric Biggers 
> > 
> > Al, can you please apply this patch?
> > 
> > - Eric
> 
> Ping.  Al, when are you going to apply this?

Sits in the local queue.  Sorry, got seriously sidetracked into
configfs mess lately, will update for-next tomorrow and push
it out.

Re: [PATCH v1 04/63] Input: atmel_mxt_ts - split large i2c transfers into blocks

[Jiada Wang]

Hi Dmitry

On 2019/08/17 2:18, Dmitry Torokhov wrote:

On Fri, Aug 16, 2019 at 05:28:53PM +0900, Jiada Wang wrote:

From: Nick Dyer 

On some firmware variants, the size of the info block exceeds what can
be read in a single transfer.

Signed-off-by: Nick Dyer 
(cherry picked from ndyer/linux/for-upstream commit 
74c4f5277cfa403d43fafc404119dc57a08677db)
[gdavis: Forward port and fix conflicts due to v4.14.51 commit
 960fe000b1d3 ("Input: atmel_mxt_ts - fix the firmware
 update").]
Signed-off-by: George G. Davis 
Signed-off-by: Jiada Wang 
---
  drivers/input/touchscreen/atmel_mxt_ts.c | 27 +---
  1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 9b165d23e092..2d70ddf71cd9 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -40,7 +40,7 @@
  #define MXT_OBJECT_START  0x07
  #define MXT_OBJECT_SIZE   6
  #define MXT_INFO_CHECKSUM_SIZE3
-#define MXT_MAX_BLOCK_WRITE256
+#define MXT_MAX_BLOCK_WRITE255
  
  /* Object types */

  #define MXT_DEBUG_DIAGNOSTIC_T37  37
@@ -659,6 +659,27 @@ static int __mxt_read_reg(struct i2c_client *client,
return ret;
  }
  
+static int mxt_read_blks(struct mxt_data *data, u16 start, u16 count, u8 *buf)


Can we call this __mxt_read_reg() and the original read reg call
__mxt_read_chunk()?


yes, I will update in v2 patch-set,
so that every call to __mxt_read_reg() in atmel driver,
can have the feature to split large size transfer.

Thanks,
Jiada


+{
+   u16 offset = 0;
+   int error;
+   u16 size;
+
+   while (offset < count) {
+   size = min(MXT_MAX_BLOCK_WRITE, count - offset);
+
+   error = __mxt_read_reg(data->client,
+  start + offset,
+  size, buf + offset);
+   if (error)
+   return error;
+
+   offset += size;
+   }
+
+   return 0;
+}


Thanks.

[PATCH net-next,v4, 4/6] net/mlx5: Add HV VHCA infrastructure

[Haiyang Zhang]

From: Eran Ben Elisha 

HV VHCA is a layer which provides PF to VF communication channel based on
HyperV PCI config channel. It implements Mellanox's Inter VHCA control
communication protocol. The protocol contains control block in order to
pass messages between the PF and VF drivers, and data blocks in order to
pass actual data.

The infrastructure is agent based. Each agent will be responsible of
contiguous buffer blocks in the VHCA config space. This infrastructure will
bind agents to their blocks, and those agents can only access read/write
the buffer blocks assigned to them. Each agent will provide three
callbacks (control, invalidate, cleanup). Control will be invoked when
block-0 is invalidated with a command that concerns this agent. Invalidate
callback will be invoked if one of the blocks assigned to this agent was
invalidated. Cleanup will be invoked before the agent is being freed in
order to clean all of its open resources or deferred works.

Block-0 serves as the control block. All execution commands from the PF
will be written by the PF over this block. VF will ack on those by
writing on block-0 as well. Its format is described by struct
mlx5_hv_vhca_control_block layout.

Signed-off-by: Eran Ben Elisha 
Signed-off-by: Saeed Mahameed 
Signed-off-by: Haiyang Zhang 
---
 drivers/net/ethernet/mellanox/mlx5/core/Makefile   |   2 +-
 .../net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c  | 253 +
 .../net/ethernet/mellanox/mlx5/core/lib/hv_vhca.h  | 102 +
 drivers/net/ethernet/mellanox/mlx5/core/main.c |   7 +
 include/linux/mlx5/driver.h|   2 +
 5 files changed, 365 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/hv_vhca.h

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Makefile 
b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
index fd32a5b..8d443fc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
@@ -45,7 +45,7 @@ mlx5_core-$(CONFIG_MLX5_ESWITCH)   += eswitch.o 
eswitch_offloads.o eswitch_offlo
 mlx5_core-$(CONFIG_MLX5_MPFS)  += lib/mpfs.o
 mlx5_core-$(CONFIG_VXLAN)  += lib/vxlan.o
 mlx5_core-$(CONFIG_PTP_1588_CLOCK) += lib/clock.o
-mlx5_core-$(CONFIG_PCI_HYPERV_INTERFACE) += lib/hv.o
+mlx5_core-$(CONFIG_PCI_HYPERV_INTERFACE) += lib/hv.o lib/hv_vhca.o
 
 #
 # Ipoib netdev
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c 
b/drivers/net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c
new file mode 100644
index 000..84d1d75
--- /dev/null
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c
@@ -0,0 +1,253 @@
+// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
+// Copyright (c) 2018 Mellanox Technologies
+
+#include 
+#include "mlx5_core.h"
+#include "lib/hv.h"
+#include "lib/hv_vhca.h"
+
+struct mlx5_hv_vhca {
+   struct mlx5_core_dev   *dev;
+   struct workqueue_struct*work_queue;
+   struct mlx5_hv_vhca_agent  *agents[MLX5_HV_VHCA_AGENT_MAX];
+   struct mutexagents_lock; /* Protect agents array */
+};
+
+struct mlx5_hv_vhca_work {
+   struct work_struct invalidate_work;
+   struct mlx5_hv_vhca   *hv_vhca;
+   u64block_mask;
+};
+
+struct mlx5_hv_vhca_data_block {
+   u16 sequence;
+   u16 offset;
+   u8  reserved[4];
+   u64 data[15];
+};
+
+struct mlx5_hv_vhca_agent {
+   enum mlx5_hv_vhca_agent_type type;
+   struct mlx5_hv_vhca *hv_vhca;
+   void*priv;
+   u16  seq;
+   void (*control)(struct mlx5_hv_vhca_agent *agent,
+   struct mlx5_hv_vhca_control_block *block);
+   void (*invalidate)(struct mlx5_hv_vhca_agent *agent,
+  u64 block_mask);
+   void (*cleanup)(struct mlx5_hv_vhca_agent *agent);
+};
+
+struct mlx5_hv_vhca *mlx5_hv_vhca_create(struct mlx5_core_dev *dev)
+{
+   struct mlx5_hv_vhca *hv_vhca = NULL;
+
+   hv_vhca = kzalloc(sizeof(*hv_vhca), GFP_KERNEL);
+   if (!hv_vhca)
+   return ERR_PTR(-ENOMEM);
+
+   hv_vhca->work_queue = create_singlethread_workqueue("mlx5_hv_vhca");
+   if (!hv_vhca->work_queue) {
+   kfree(hv_vhca);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   hv_vhca->dev = dev;
+   mutex_init(&hv_vhca->agents_lock);
+
+   return hv_vhca;
+}
+
+void mlx5_hv_vhca_destroy(struct mlx5_hv_vhca *hv_vhca)
+{
+   if (IS_ERR_OR_NULL(hv_vhca))
+   return;
+
+   destroy_workqueue(hv_vhca->work_queue);
+   kfree(hv_vhca);
+}
+
+static void mlx5_hv_vhca_invalidate_work(struct work_struct *work)
+{
+   struct mlx5_hv_vhca_work *hwork;
+   struct mlx5_hv_vhca *hv_vhca;
+   int i;
+
+   hwork = container_of(work, struct mlx5_hv_vhca_work, invalidate_work);
+

[PATCH net-next,v4, 5/6] net/mlx5: Add HV VHCA control agent

[Haiyang Zhang]

From: Eran Ben Elisha 

Control agent is responsible over of the control block (ID 0). It should
update the PF via this block about every capability change. In addition,
upon block 0 invalidate, it should activate all other supported agents
with data requests from the PF.

Upon agent create/destroy, the invalidate callback of the control agent
is being called in order to update the PF driver about this change.

The control agent is an integral part of HV VHCA and will be created
and destroy as part of the HV VHCA init/cleanup flow.

Signed-off-by: Eran Ben Elisha 
Signed-off-by: Saeed Mahameed 
Signed-off-by: Haiyang Zhang 
---
 .../net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c  | 122 -
 .../net/ethernet/mellanox/mlx5/core/lib/hv_vhca.h  |   1 +
 2 files changed, 121 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c 
b/drivers/net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c
index 84d1d75..4047629 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c
@@ -109,22 +109,131 @@ void mlx5_hv_vhca_invalidate(void *context, u64 
block_mask)
queue_work(hv_vhca->work_queue, &work->invalidate_work);
 }
 
+#define AGENT_MASK(type) (type ? BIT(type - 1) : 0 /* control */)
+
+static void mlx5_hv_vhca_agents_control(struct mlx5_hv_vhca *hv_vhca,
+   struct mlx5_hv_vhca_control_block 
*block)
+{
+   int i;
+
+   for (i = 0; i < MLX5_HV_VHCA_AGENT_MAX; i++) {
+   struct mlx5_hv_vhca_agent *agent = hv_vhca->agents[i];
+
+   if (!agent || !agent->control)
+   continue;
+
+   if (!(AGENT_MASK(agent->type) & block->control))
+   continue;
+
+   agent->control(agent, block);
+   }
+}
+
+static void mlx5_hv_vhca_capabilities(struct mlx5_hv_vhca *hv_vhca,
+ u32 *capabilities)
+{
+   int i;
+
+   for (i = 0; i < MLX5_HV_VHCA_AGENT_MAX; i++) {
+   struct mlx5_hv_vhca_agent *agent = hv_vhca->agents[i];
+
+   if (agent)
+   *capabilities |= AGENT_MASK(agent->type);
+   }
+}
+
+static void
+mlx5_hv_vhca_control_agent_invalidate(struct mlx5_hv_vhca_agent *agent,
+ u64 block_mask)
+{
+   struct mlx5_hv_vhca *hv_vhca = agent->hv_vhca;
+   struct mlx5_core_dev *dev = hv_vhca->dev;
+   struct mlx5_hv_vhca_control_block *block;
+   u32 capabilities = 0;
+   int err;
+
+   block = kzalloc(sizeof(*block), GFP_KERNEL);
+   if (!block)
+   return;
+
+   err = mlx5_hv_read_config(dev, block, sizeof(*block), 0);
+   if (err)
+   goto free_block;
+
+   mlx5_hv_vhca_capabilities(hv_vhca, &capabilities);
+
+   /* In case no capabilities, send empty block in return */
+   if (!capabilities) {
+   memset(block, 0, sizeof(*block));
+   goto write;
+   }
+
+   if (block->capabilities != capabilities)
+   block->capabilities = capabilities;
+
+   if (block->control & ~capabilities)
+   goto free_block;
+
+   mlx5_hv_vhca_agents_control(hv_vhca, block);
+   block->command_ack = block->command;
+
+write:
+   mlx5_hv_write_config(dev, block, sizeof(*block), 0);
+
+free_block:
+   kfree(block);
+}
+
+static struct mlx5_hv_vhca_agent *
+mlx5_hv_vhca_control_agent_create(struct mlx5_hv_vhca *hv_vhca)
+{
+   return mlx5_hv_vhca_agent_create(hv_vhca, MLX5_HV_VHCA_AGENT_CONTROL,
+NULL,
+mlx5_hv_vhca_control_agent_invalidate,
+NULL, NULL);
+}
+
+static void mlx5_hv_vhca_control_agent_destroy(struct mlx5_hv_vhca_agent 
*agent)
+{
+   mlx5_hv_vhca_agent_destroy(agent);
+}
+
 int mlx5_hv_vhca_init(struct mlx5_hv_vhca *hv_vhca)
 {
+   struct mlx5_hv_vhca_agent *agent;
+   int err;
+
if (IS_ERR_OR_NULL(hv_vhca))
return IS_ERR_OR_NULL(hv_vhca);
 
-   return mlx5_hv_register_invalidate(hv_vhca->dev, hv_vhca,
-  mlx5_hv_vhca_invalidate);
+   err = mlx5_hv_register_invalidate(hv_vhca->dev, hv_vhca,
+ mlx5_hv_vhca_invalidate);
+   if (err)
+   return err;
+
+   agent = mlx5_hv_vhca_control_agent_create(hv_vhca);
+   if (IS_ERR_OR_NULL(agent)) {
+   mlx5_hv_unregister_invalidate(hv_vhca->dev);
+   return IS_ERR_OR_NULL(agent);
+   }
+
+   hv_vhca->agents[MLX5_HV_VHCA_AGENT_CONTROL] = agent;
+
+   return 0;
 }
 
 void mlx5_hv_vhca_cleanup(struct mlx5_hv_vhca *hv_vhca)
 {
+   struct mlx5_hv_vhca_agent *agent;
int i;
 
if (IS_ERR_OR_NULL(hv_vhca))
return;
 
+   agent = hv_vhca->agents[MLX5

[PATCH net-next,v4, 2/6] PCI: hv: Add a Hyper-V PCI interface driver for software backchannel interface

[Haiyang Zhang]

This interface driver is a helper driver allows other drivers to
have a common interface with the Hyper-V PCI frontend driver.

Signed-off-by: Haiyang Zhang 
Signed-off-by: Saeed Mahameed 
---
 MAINTAINERS  |  1 +
 drivers/pci/Kconfig  |  1 +
 drivers/pci/controller/Kconfig   |  7 
 drivers/pci/controller/Makefile  |  1 +
 drivers/pci/controller/pci-hyperv-intf.c | 67 
 drivers/pci/controller/pci-hyperv.c  | 12 --
 include/linux/hyperv.h   | 30 ++
 7 files changed, 108 insertions(+), 11 deletions(-)
 create mode 100644 drivers/pci/controller/pci-hyperv-intf.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a406947..9860853 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7469,6 +7469,7 @@ F:drivers/hid/hid-hyperv.c
 F: drivers/hv/
 F: drivers/input/serio/hyperv-keyboard.c
 F: drivers/pci/controller/pci-hyperv.c
+F: drivers/pci/controller/pci-hyperv-intf.c
 F: drivers/net/hyperv/
 F: drivers/scsi/storvsc_drv.c
 F: drivers/uio/uio_hv_generic.c
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 2ab9240..c313de9 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -182,6 +182,7 @@ config PCI_LABEL
 config PCI_HYPERV
 tristate "Hyper-V PCI Frontend"
 depends on X86 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && X86_64
+   select PCI_HYPERV_INTERFACE
 help
   The PCI device frontend driver allows the kernel to import arbitrary
   PCI devices from a PCI backend to support PCI driver domains.
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index fe9f9f1..70e0782 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -281,5 +281,12 @@ config VMD
  To compile this driver as a module, choose M here: the
  module will be called vmd.
 
+config PCI_HYPERV_INTERFACE
+   tristate "Hyper-V PCI Interface"
+   depends on X86 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && X86_64
+   help
+ The Hyper-V PCI Interface is a helper driver allows other drivers to
+ have a common interface with the Hyper-V PCI frontend driver.
+
 source "drivers/pci/controller/dwc/Kconfig"
 endmenu
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index d56a507..a2a22c9 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_PCIE_CADENCE_HOST) += pcie-cadence-host.o
 obj-$(CONFIG_PCIE_CADENCE_EP) += pcie-cadence-ep.o
 obj-$(CONFIG_PCI_FTPCI100) += pci-ftpci100.o
 obj-$(CONFIG_PCI_HYPERV) += pci-hyperv.o
+obj-$(CONFIG_PCI_HYPERV_INTERFACE) += pci-hyperv-intf.o
 obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
 obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
 obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
diff --git a/drivers/pci/controller/pci-hyperv-intf.c 
b/drivers/pci/controller/pci-hyperv-intf.c
new file mode 100644
index 000..cc96be4
--- /dev/null
+++ b/drivers/pci/controller/pci-hyperv-intf.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Microsoft Corporation.
+ *
+ * Author:
+ *   Haiyang Zhang 
+ *
+ * This small module is a helper driver allows other drivers to
+ * have a common interface with the Hyper-V PCI frontend driver.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+
+struct hyperv_pci_block_ops hvpci_block_ops;
+EXPORT_SYMBOL_GPL(hvpci_block_ops);
+
+int hyperv_read_cfg_blk(struct pci_dev *dev, void *buf, unsigned int buf_len,
+   unsigned int block_id, unsigned int *bytes_returned)
+{
+   if (!hvpci_block_ops.read_block)
+   return -EOPNOTSUPP;
+
+   return hvpci_block_ops.read_block(dev, buf, buf_len, block_id,
+ bytes_returned);
+}
+EXPORT_SYMBOL_GPL(hyperv_read_cfg_blk);
+
+int hyperv_write_cfg_blk(struct pci_dev *dev, void *buf, unsigned int len,
+unsigned int block_id)
+{
+   if (!hvpci_block_ops.write_block)
+   return -EOPNOTSUPP;
+
+   return hvpci_block_ops.write_block(dev, buf, len, block_id);
+}
+EXPORT_SYMBOL_GPL(hyperv_write_cfg_blk);
+
+int hyperv_reg_block_invalidate(struct pci_dev *dev, void *context,
+   void (*block_invalidate)(void *context,
+u64 block_mask))
+{
+   if (!hvpci_block_ops.reg_blk_invalidate)
+   return -EOPNOTSUPP;
+
+   return hvpci_block_ops.reg_blk_invalidate(dev, context,
+ block_invalidate);
+}
+EXPORT_SYMBOL_GPL(hyperv_reg_block_invalidate);
+
+static void __exit exit_hv_pci_intf(void)
+{
+}
+
+static int __init init_hv_pci_intf(void)
+{
+   return 0;
+}
+
+module_init(init_hv_pci_intf);
+module_exit(exit_hv_pci_intf);
+
+MODULE_DESCRIPTION("Hyper-V PCI Inte

[PATCH net-next,v4, 6/6] net/mlx5e: Add mlx5e HV VHCA stats agent

[Haiyang Zhang]

From: Eran Ben Elisha 

HV VHCA stats agent is responsible on running a preiodic rx/tx
packets/bytes stats update. Currently the supported format is version
MLX5_HV_VHCA_STATS_VERSION. Block ID 1 is dedicated for statistics data
transfer from the VF to the PF.

The reporter fetch the statistics data from all opened channels, fill it
in a buffer and send it to mlx5_hv_vhca_write_agent.

As the stats layer should include some metadata per block (sequence and
offset), the HV VHCA layer shall modify the buffer before actually send it
over block 1.

Signed-off-by: Eran Ben Elisha 
Signed-off-by: Saeed Mahameed 
Signed-off-by: Haiyang Zhang 
---
 drivers/net/ethernet/mellanox/mlx5/core/Makefile   |   1 +
 drivers/net/ethernet/mellanox/mlx5/core/en.h   |  13 ++
 .../ethernet/mellanox/mlx5/core/en/hv_vhca_stats.c | 162 +
 .../ethernet/mellanox/mlx5/core/en/hv_vhca_stats.h |  25 
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c  |   3 +
 .../net/ethernet/mellanox/mlx5/core/lib/hv_vhca.h  |   1 +
 6 files changed, 205 insertions(+)
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/hv_vhca_stats.c
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/hv_vhca_stats.h

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Makefile 
b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
index 8d443fc..f4de9cc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
@@ -36,6 +36,7 @@ mlx5_core-$(CONFIG_MLX5_CORE_EN_DCB) += en_dcbnl.o 
en/port_buffer.o
 mlx5_core-$(CONFIG_MLX5_ESWITCH) += en_rep.o en_tc.o en/tc_tun.o 
lib/port_tun.o lag_mp.o \
lib/geneve.o en/tc_tun_vxlan.o 
en/tc_tun_gre.o \
en/tc_tun_geneve.o 
diag/en_tc_tracepoint.o
+mlx5_core-$(CONFIG_PCI_HYPERV_INTERFACE) += en/hv_vhca_stats.o
 
 #
 # Core extra
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h 
b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index 7316571..4467927 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -54,6 +54,7 @@
 #include "mlx5_core.h"
 #include "en_stats.h"
 #include "en/fs.h"
+#include "lib/hv_vhca.h"
 
 extern const struct net_device_ops mlx5e_netdev_ops;
 struct page_pool;
@@ -782,6 +783,15 @@ struct mlx5e_modify_sq_param {
int rl_index;
 };
 
+#if IS_ENABLED(CONFIG_PCI_HYPERV_INTERFACE)
+struct mlx5e_hv_vhca_stats_agent {
+   struct mlx5_hv_vhca_agent *agent;
+   struct delayed_workwork;
+   u16delay;
+   void  *buf;
+};
+#endif
+
 struct mlx5e_xsk {
/* UMEMs are stored separately from channels, because we don't want to
 * lose them when channels are recreated. The kernel also stores UMEMs,
@@ -853,6 +863,9 @@ struct mlx5e_priv {
struct devlink_health_reporter *tx_reporter;
struct devlink_health_reporter *rx_reporter;
struct mlx5e_xsk   xsk;
+#if IS_ENABLED(CONFIG_PCI_HYPERV_INTERFACE)
+   struct mlx5e_hv_vhca_stats_agent stats_agent;
+#endif
 };
 
 struct mlx5e_profile {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/hv_vhca_stats.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en/hv_vhca_stats.c
new file mode 100644
index 000..c37b4ac
--- /dev/null
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/hv_vhca_stats.c
@@ -0,0 +1,162 @@
+// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
+// Copyright (c) 2018 Mellanox Technologies
+
+#include "en.h"
+#include "en/hv_vhca_stats.h"
+#include "lib/hv_vhca.h"
+#include "lib/hv.h"
+
+struct mlx5e_hv_vhca_per_ring_stats {
+   u64 rx_packets;
+   u64 rx_bytes;
+   u64 tx_packets;
+   u64 tx_bytes;
+};
+
+static void
+mlx5e_hv_vhca_fill_ring_stats(struct mlx5e_priv *priv, int ch,
+ struct mlx5e_hv_vhca_per_ring_stats *data)
+{
+   struct mlx5e_channel_stats *stats;
+   int tc;
+
+   stats = &priv->channel_stats[ch];
+   data->rx_packets = stats->rq.packets;
+   data->rx_bytes   = stats->rq.bytes;
+
+   for (tc = 0; tc < priv->max_opened_tc; tc++) {
+   data->tx_packets += stats->sq[tc].packets;
+   data->tx_bytes   += stats->sq[tc].bytes;
+   }
+}
+
+static void mlx5e_hv_vhca_fill_stats(struct mlx5e_priv *priv, u64 *data,
+int buf_len)
+{
+   int ch, i = 0;
+
+   for (ch = 0; ch < priv->max_nch; ch++) {
+   u64 *buf = data + i;
+
+   if (WARN_ON_ONCE(buf +
+sizeof(struct mlx5e_hv_vhca_per_ring_stats) >
+data + buf_len))
+   return;
+
+   mlx5e_hv_vhca_fill_ring_stats(priv, ch,
+ (struct 
mlx5e_hv_vhca_per_ring_stats *)buf);
+   i += sizeof(struct mlx5e_hv_vhca_per_ring_stat

Re: [RFC PATCH] powerpc: Convert ____flush_dcache_icache_phys() to C

[Christophe Leroy]

Le 22/08/2019 à 02:27, Alastair D'Silva a écrit :

On Wed, 2019-08-21 at 22:27 +0200, Christophe Leroy wrote:


Le 20/08/2019 à 06:36, Alastair D'Silva a écrit :

On Fri, 2019-08-16 at 15:52 +, Christophe Leroy wrote:


[...]



Thanks Christophe,

I'm trying a somewhat different approach that requires less
knowledge
of assembler. Handling of CPU_FTR_COHERENT_ICACHE is outside this
function. The code below is not a patch as my tree is a bit messy,
sorry:


Can we be 100% sure that GCC won't add any code accessing some
global
data or stack while the Data MMU is OFF ?

Christophe



+mpe

I'm not sure how we would go about making such a guarantee, but I've
tied every variable used to a register and addr is passed in a
register, so there is no stack usage, and every call in there only
operates on it's operands.

The calls to the inline cache helpers (for the PPC32 case) are all
constants, so I can't see a reasonable scenario where there would be a
function call and reordered to after the DR bit is turned off, but I
guess if we want to be paranoid, we could always add an mb() call
before the DR bit is manipulated to prevent the compiler from
reordering across the section where the data MMU is disabled.




Anyway, I think the benefit of converting that function to C is pretty 
small. flush_dcache_range() and friends were converted to C mainly in 
order to inline them. But this __flush_dcache_icache_phys() is too big 
to be worth inlining, yet small and stable enough to remain in assembly 
for the time being.


So I suggest you keep it aside your series for now, just move 
PURGE_PREFETCHED_INS inside it directly as it will be the only remaining 
user of it.


Christophe

[PATCH net-next,v4, 1/6] PCI: hv: Add a paravirtual backchannel in software

[Haiyang Zhang]

From: Dexuan Cui 

Windows SR-IOV provides a backchannel mechanism in software for communication
between a VF driver and a PF driver.  These "configuration blocks" are
similar in concept to PCI configuration space, but instead of doing reads and
writes in 32-bit chunks through a very slow path, packets of up to 128 bytes
can be sent or received asynchronously.

Nearly every SR-IOV device contains just such a communications channel in
hardware, so using this one in software is usually optional.  Using the
software channel, however, allows driver implementers to leverage software
tools that fuzz the communications channel looking for vulnerabilities.

The usage model for these packets puts the responsibility for reading or
writing on the VF driver.  The VF driver sends a read or a write packet,
indicating which "block" is being referred to by number.

If the PF driver wishes to initiate communication, it can "invalidate" one or
more of the first 64 blocks.  This invalidation is delivered via a callback
supplied by the VF driver by this driver.

No protocol is implied, except that supplied by the PF and VF drivers.

Signed-off-by: Jake Oshins 
Signed-off-by: Dexuan Cui 
Cc: Haiyang Zhang 
Cc: K. Y. Srinivasan 
Cc: Stephen Hemminger 
Signed-off-by: Saeed Mahameed 
Signed-off-by: Haiyang Zhang 
---
 drivers/pci/controller/pci-hyperv.c | 302 
 include/linux/hyperv.h  |  15 ++
 2 files changed, 317 insertions(+)

diff --git a/drivers/pci/controller/pci-hyperv.c 
b/drivers/pci/controller/pci-hyperv.c
index 40b6254..57adeca 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -365,6 +365,39 @@ struct pci_delete_interrupt {
struct tran_int_desc int_desc;
 } __packed;
 
+/*
+ * Note: the VM must pass a valid block id, wslot and bytes_requested.
+ */
+struct pci_read_block {
+   struct pci_message message_type;
+   u32 block_id;
+   union win_slot_encoding wslot;
+   u32 bytes_requested;
+} __packed;
+
+struct pci_read_block_response {
+   struct vmpacket_descriptor hdr;
+   u32 status;
+   u8 bytes[HV_CONFIG_BLOCK_SIZE_MAX];
+} __packed;
+
+/*
+ * Note: the VM must pass a valid block id, wslot and byte_count.
+ */
+struct pci_write_block {
+   struct pci_message message_type;
+   u32 block_id;
+   union win_slot_encoding wslot;
+   u32 byte_count;
+   u8 bytes[HV_CONFIG_BLOCK_SIZE_MAX];
+} __packed;
+
+struct pci_dev_inval_block {
+   struct pci_incoming_message incoming;
+   union win_slot_encoding wslot;
+   u64 block_mask;
+} __packed;
+
 struct pci_dev_incoming {
struct pci_incoming_message incoming;
union win_slot_encoding wslot;
@@ -499,6 +532,9 @@ struct hv_pci_dev {
struct hv_pcibus_device *hbus;
struct work_struct wrk;
 
+   void (*block_invalidate)(void *context, u64 block_mask);
+   void *invalidate_context;
+
/*
 * What would be observed if one wrote 0x to a BAR and then
 * read it back, for each of the BAR offsets within config space.
@@ -817,6 +853,256 @@ static int hv_pcifront_write_config(struct pci_bus *bus, 
unsigned int devfn,
.write = hv_pcifront_write_config,
 };
 
+/*
+ * Paravirtual backchannel
+ *
+ * Hyper-V SR-IOV provides a backchannel mechanism in software for
+ * communication between a VF driver and a PF driver.  These
+ * "configuration blocks" are similar in concept to PCI configuration space,
+ * but instead of doing reads and writes in 32-bit chunks through a very slow
+ * path, packets of up to 128 bytes can be sent or received asynchronously.
+ *
+ * Nearly every SR-IOV device contains just such a communications channel in
+ * hardware, so using this one in software is usually optional.  Using the
+ * software channel, however, allows driver implementers to leverage software
+ * tools that fuzz the communications channel looking for vulnerabilities.
+ *
+ * The usage model for these packets puts the responsibility for reading or
+ * writing on the VF driver.  The VF driver sends a read or a write packet,
+ * indicating which "block" is being referred to by number.
+ *
+ * If the PF driver wishes to initiate communication, it can "invalidate" one 
or
+ * more of the first 64 blocks.  This invalidation is delivered via a callback
+ * supplied by the VF driver by this driver.
+ *
+ * No protocol is implied, except that supplied by the PF and VF drivers.
+ */
+
+struct hv_read_config_compl {
+   struct hv_pci_compl comp_pkt;
+   void *buf;
+   unsigned int len;
+   unsigned int bytes_returned;
+};
+
+/**
+ * hv_pci_read_config_compl() - Invoked when a response packet
+ * for a read config block operation arrives.
+ * @context:   Identifies the read config operation
+ * @resp:  The response packet itself
+ * @resp_packet_size:  Size in bytes of the response packet
+ */
+static void hv_pci_read_config_compl(void *contex

[PATCH net-next,v4, 3/6] net/mlx5: Add wrappers for HyperV PCIe operations

[Haiyang Zhang]

From: Eran Ben Elisha 

Add wrapper functions for HyperV PCIe read / write /
block_invalidate_register operations.  This will be used as an
infrastructure in the downstream patch for software communication.

This will be enabled by default if CONFIG_PCI_HYPERV_INTERFACE is set.

Signed-off-by: Eran Ben Elisha 
Signed-off-by: Saeed Mahameed 
Signed-off-by: Haiyang Zhang 
---
 drivers/net/ethernet/mellanox/mlx5/core/Makefile |  1 +
 drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c | 64 
 drivers/net/ethernet/mellanox/mlx5/core/lib/hv.h | 22 
 3 files changed, 87 insertions(+)
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/hv.h

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Makefile 
b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
index bcf3655..fd32a5b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
@@ -45,6 +45,7 @@ mlx5_core-$(CONFIG_MLX5_ESWITCH)   += eswitch.o 
eswitch_offloads.o eswitch_offlo
 mlx5_core-$(CONFIG_MLX5_MPFS)  += lib/mpfs.o
 mlx5_core-$(CONFIG_VXLAN)  += lib/vxlan.o
 mlx5_core-$(CONFIG_PTP_1588_CLOCK) += lib/clock.o
+mlx5_core-$(CONFIG_PCI_HYPERV_INTERFACE) += lib/hv.o
 
 #
 # Ipoib netdev
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c 
b/drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c
new file mode 100644
index 000..cf08d02
--- /dev/null
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
+// Copyright (c) 2018 Mellanox Technologies
+
+#include 
+#include "mlx5_core.h"
+#include "lib/hv.h"
+
+static int mlx5_hv_config_common(struct mlx5_core_dev *dev, void *buf, int len,
+int offset, bool read)
+{
+   int rc = -EOPNOTSUPP;
+   int bytes_returned;
+   int block_id;
+
+   if (offset % HV_CONFIG_BLOCK_SIZE_MAX || len % HV_CONFIG_BLOCK_SIZE_MAX)
+   return -EINVAL;
+
+   block_id = offset / HV_CONFIG_BLOCK_SIZE_MAX;
+
+   rc = read ?
+hyperv_read_cfg_blk(dev->pdev, buf,
+HV_CONFIG_BLOCK_SIZE_MAX, block_id,
+&bytes_returned) :
+hyperv_write_cfg_blk(dev->pdev, buf,
+ HV_CONFIG_BLOCK_SIZE_MAX, block_id);
+
+   /* Make sure len bytes were read successfully  */
+   if (read)
+   rc |= !(len == bytes_returned);
+
+   if (rc) {
+   mlx5_core_err(dev, "Failed to %s hv config, err = %d, len = %d, 
offset = %d\n",
+ read ? "read" : "write", rc, len,
+ offset);
+   return rc;
+   }
+
+   return 0;
+}
+
+int mlx5_hv_read_config(struct mlx5_core_dev *dev, void *buf, int len,
+   int offset)
+{
+   return mlx5_hv_config_common(dev, buf, len, offset, true);
+}
+
+int mlx5_hv_write_config(struct mlx5_core_dev *dev, void *buf, int len,
+int offset)
+{
+   return mlx5_hv_config_common(dev, buf, len, offset, false);
+}
+
+int mlx5_hv_register_invalidate(struct mlx5_core_dev *dev, void *context,
+   void (*block_invalidate)(void *context,
+u64 block_mask))
+{
+   return hyperv_reg_block_invalidate(dev->pdev, context,
+  block_invalidate);
+}
+
+void mlx5_hv_unregister_invalidate(struct mlx5_core_dev *dev)
+{
+   hyperv_reg_block_invalidate(dev->pdev, NULL, NULL);
+}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/hv.h 
b/drivers/net/ethernet/mellanox/mlx5/core/lib/hv.h
new file mode 100644
index 000..f9a4557
--- /dev/null
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/hv.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB */
+/* Copyright (c) 2019 Mellanox Technologies. */
+
+#ifndef __LIB_HV_H__
+#define __LIB_HV_H__
+
+#if IS_ENABLED(CONFIG_PCI_HYPERV_INTERFACE)
+
+#include 
+#include 
+
+int mlx5_hv_read_config(struct mlx5_core_dev *dev, void *buf, int len,
+   int offset);
+int mlx5_hv_write_config(struct mlx5_core_dev *dev, void *buf, int len,
+int offset);
+int mlx5_hv_register_invalidate(struct mlx5_core_dev *dev, void *context,
+   void (*block_invalidate)(void *context,
+u64 block_mask));
+void mlx5_hv_unregister_invalidate(struct mlx5_core_dev *dev);
+#endif
+
+#endif /* __LIB_HV_H__ */
-- 
1.8.3.1

[PATCH net-next,v4, 0/6] Add software backchannel and mlx5e HV VHCA stats

[Haiyang Zhang]

This patch set adds paravirtual backchannel in software in pci_hyperv,
which is required by the mlx5e driver HV VHCA stats agent.

The stats agent is responsible on running a periodic rx/tx packets/bytes
stats update.

Dexuan Cui (1):
  PCI: hv: Add a paravirtual backchannel in software

Eran Ben Elisha (4):
  net/mlx5: Add wrappers for HyperV PCIe operations
  net/mlx5: Add HV VHCA infrastructure
  net/mlx5: Add HV VHCA control agent
  net/mlx5e: Add mlx5e HV VHCA stats agent

Haiyang Zhang (1):
  PCI: hv: Add a Hyper-V PCI interface driver for software backchannel
interface

 MAINTAINERS|   1 +
 drivers/net/ethernet/mellanox/mlx5/core/Makefile   |   2 +
 drivers/net/ethernet/mellanox/mlx5/core/en.h   |  13 +
 .../ethernet/mellanox/mlx5/core/en/hv_vhca_stats.c | 162 +
 .../ethernet/mellanox/mlx5/core/en/hv_vhca_stats.h |  25 ++
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c  |   3 +
 drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c   |  64 
 drivers/net/ethernet/mellanox/mlx5/core/lib/hv.h   |  22 ++
 .../net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c  | 371 +
 .../net/ethernet/mellanox/mlx5/core/lib/hv_vhca.h  | 104 ++
 drivers/net/ethernet/mellanox/mlx5/core/main.c |   7 +
 drivers/pci/Kconfig|   1 +
 drivers/pci/controller/Kconfig |   7 +
 drivers/pci/controller/Makefile|   1 +
 drivers/pci/controller/pci-hyperv-intf.c   |  67 
 drivers/pci/controller/pci-hyperv.c| 308 +
 include/linux/hyperv.h |  29 ++
 include/linux/mlx5/driver.h|   2 +
 18 files changed, 1189 insertions(+)
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/hv_vhca_stats.c
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/hv_vhca_stats.h
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/hv.h
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/hv_vhca.c
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/hv_vhca.h
 create mode 100644 drivers/pci/controller/pci-hyperv-intf.c

-- 
1.8.3.1

Re: [PATCH -next] cpufreq: qcom-hw: remove set but not used variable 'prev_cc'

[Sibi Sankar]

@YueHaibing thanks for the patch.

On 2019-08-22 08:10, Viresh Kumar wrote:

On 21-08-19, 20:14, YueHaibing wrote:
drivers/cpufreq/qcom-cpufreq-hw.c: In function 
qcom_cpufreq_hw_read_lut:

drivers/cpufreq/qcom-cpufreq-hw.c:89:38: warning:
 variable prev_cc set but not used [-Wunused-but-set-variable]

It is not used since commit 3003e75a5045 ("cpufreq:
qcom-hw: Update logic to detect turbo frequency")

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
---
 drivers/cpufreq/qcom-cpufreq-hw.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
b/drivers/cpufreq/qcom-cpufreq-hw.c

index 3eea197..a9ae2f8 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -86,7 +86,7 @@ static int qcom_cpufreq_hw_read_lut(struct device 
*cpu_dev,

struct cpufreq_policy *policy,
void __iomem *base)
 {
-	u32 data, src, lval, i, core_count, prev_cc = 0, prev_freq = 0, 
freq;

+   u32 data, src, lval, i, core_count, prev_freq = 0, freq;
u32 volt;
struct cpufreq_frequency_table  *table;

@@ -139,7 +139,6 @@ static int qcom_cpufreq_hw_read_lut(struct device 
*cpu_dev,

break;
}

-   prev_cc = core_count;
prev_freq = freq;
}


@Sibi, you fine with this change ? I will merge it with the original 
patch then.


yes the changes seem fine, I missed
removing prev_cc.

--
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees

[Davidlohr Bueso]

On Wed, 21 Aug 2019, Michel Lespinasse wrote:


On Tue, Aug 13, 2019 at 03:46:18PM -0700, Davidlohr Bueso wrote:

o The border cases for overlapping differ -- interval trees are closed,
while memtype intervals are open. We need to maintain semantics such
that conflict detection and getting the lowest match does not change.


Agree on the need to maintain semantics.

As I had commented some time ago, I wish the interval trees used [start,end)
intervals instead of [start,last] - it would be a better fit for basically
all of the current interval tree users.


Yes, after going through all the users of interval-tree,  I agree that
they all want to use [start,end intervals.



I'm not sure where to go with this - would it make sense to add a new
interval tree header file that uses [start,end) intervals (with the
thought of eventually converting all current interval tree users to it)
instead of adding one more use of the less-natural [start,last]
interval trees ?


It might be the safest way, although I really hate having another
header file for interval_tree... The following is a diffstat of a
tentative conversion (I'll send the patch separately); I'm not sure
if a single shot conversion would be acceptable, albeit with relevant
maintainer acks.

drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c  |  8 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  5 +++--
drivers/gpu/drm/drm_mm.c|  2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 13 +
drivers/gpu/drm/radeon/radeon_mn.c  | 10 +++---
drivers/gpu/drm/radeon/radeon_vm.c  |  2 +-
drivers/infiniband/hw/hfi1/mmu_rb.c | 12 ++--
drivers/iommu/virtio-iommu.c|  4 ++--
drivers/vhost/vhost.c   |  6 +++---
include/drm/drm_mm.h|  2 +-
include/linux/interval_tree_generic.h   | 28 ++--
mm/interval_tree.c  |  2 +-
mm/rmap.c   |  2 +-
13 files changed, 42 insertions(+), 54 deletions(-)

This gets rid of 'end - 1' trick from the users and converts
cond1 and cond2 checks in interval_tree_generic.h

Note that I think amdgpu_vm.c actually uses fully open intervals.




diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
index fa16036fa592..1be4d1856a9b 100644
--- a/arch/x86/mm/pat_rbtree.c
+++ b/arch/x86/mm/pat_rbtree.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 

@@ -34,68 +34,41 @@
  * memtype_lock protects the rbtree.
  */

-static struct rb_root memtype_rbroot = RB_ROOT;
+static struct rb_root_cached memtype_rbroot = RB_ROOT_CACHED;
+
+#define START(node) ((node)->start)
+#define END(node)  ((node)->end)
+INTERVAL_TREE_DEFINE(struct memtype, rb, u64, subtree_max_end,
+START, END, static, memtype_interval)

 static int is_node_overlap(struct memtype *node, u64 start, u64 end)
 {
-   if (node->start >= end || node->end <= start)
+   /*
+* Unlike generic interval trees, the memtype nodes are ]a, b[


I think the memtype nodes are [a, b)  (which one could also write as [a, b[
depending on their local customs - but either way, closed on the start side
and open on the end side) ?


+* therefore we need to adjust the ranges accordingly. Missing
+* an overlap can lead to incorrectly detecting conflicts,
+* for example.
+*/
+   if (node->start + 1 >= end || node->end - 1 <= start)
return 0;

return 1;
 }


All right, now I am *really* confused.

My understanding is as follows:
* the PAT code wants to use [start, end( intervals
* interval trees are defined to use [start, last] intervals with last == end-1


Yes, we're talking about the same thing, but I overcomplicated things by
considering memtype lookups to be different than the nodes in the tree;
which obviously doesn't make sense... it is actually [a,b[ as you mention.



At first, I thought that you were handling that by removing 1 from the
end of the interval, to adjust between the PAT and interval tree
definitions. But, I don't see you doing that anywhere.


This should have been my first approach.



Then, I thought that you were using [start, end( intervals everywhere,
and the interval tree functions memtype_interval_iter_first and
memtype_interval_iter_next would just return too many candidate
matches as as you are passing "end" instead of "last" == end-1 as the
interval endpoint, but then you would filter out the extra intervals
using is_node_overlap(). But, if that is the case, then I don't
understand why you need to redefine is_node_overlap() here.


My original expectation was to actually remove a lot more of pat_rbtree,
including the is_node_overlap() and the filtering. Yes, I think this can
be done if the interval-tree is converted to [a,b[ and we can thus
just iterate the tree seamlessly.



Could you help me out by defining if the intervals are open or 

[PATCH 1/6] kbuild: remove 'Using ... as source for kernel' message

[Masahiro Yamada]

You already know the location of the source tree without this message.

Signed-off-by: Masahiro Yamada 
---

 Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Makefile b/Makefile
index 7e54a821b4b0..a77102e4ee90 100644
--- a/Makefile
+++ b/Makefile
@@ -1118,7 +1118,6 @@ PHONY += prepare archprepare prepare3
 # 1) Check that make has not been executed in the kernel src $(srctree)
 prepare3: include/config/kernel.release
 ifdef building_out_of_srctree
-   @$(kecho) '  Using $(srctree) as source for kernel'
$(Q)if [ -f $(srctree)/.config -o \
 -d $(srctree)/include/config -o \
 -d $(srctree)/arch/$(SRCARCH)/include/generated ]; then \
-- 
2.17.1

[PATCH 3/6] kbuild: clarify where to run make mrproper when out-of-tree fails

[Masahiro Yamada]

If you try out-of-tree build with an unclean source tree, Kbuild
suggests to run make mrproper. The path to the source tree may be
shown with a relative path, for example, "make O=foo" emits the
following:

  .. is not clean, please run 'make mrproper'
  in the '..' directory.

This is somewhat confusing if you ran "make O=foo" in the source tree.
Using the absolute path will be clearer.

This commit changes the error message like follows:

***
*** The source tree is not clean, please run 'make mrproper'
*** in /absolute/path/to/linux
***

Signed-off-by: Masahiro Yamada 
---

 Makefile | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index d9cbbc27d4ba..901fcb8fffbe 100644
--- a/Makefile
+++ b/Makefile
@@ -1121,8 +1121,10 @@ ifdef building_out_of_srctree
$(Q)if [ -f $(srctree)/.config -o \
 -d $(srctree)/include/config -o \
 -d $(srctree)/arch/$(SRCARCH)/include/generated ]; then \
-   echo >&2 "  $(srctree) is not clean, please run 'make$(if 
$(findstring command line, $(origin ARCH)), ARCH=$(ARCH)) mrproper'"; \
-   echo >&2 "  in the '$(srctree)' directory.";\
+   echo >&2 "***"; \
+   echo >&2 "*** The source tree is not clean, please run 
'make$(if $(findstring command line, $(origin ARCH)), ARCH=$(ARCH)) mrproper'"; 
\
+   echo >&2 "*** in $(abs_srctree)";\
+   echo >&2 "***"; \
/bin/false; \
fi;
 endif
-- 
2.17.1

[PATCH 5/6] kbuild: remove prepare3 target

[Masahiro Yamada]

Now prepare3 does nothing but depends on include/config/kernel.release

Signed-off-by: Masahiro Yamada 
---

 Makefile | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index ca6851f5ebc9..960df4d35b15 100644
--- a/Makefile
+++ b/Makefile
@@ -1121,11 +1121,9 @@ scripts: scripts_basic scripts_dtc
 # archprepare is used in arch Makefiles and when processed asm symlink,
 # version.h and scripts_basic is processed / created.
 
-PHONY += prepare archprepare prepare3
+PHONY += prepare archprepare
 
-prepare3: include/config/kernel.release
-
-archprepare: archheaders archscripts scripts prepare3 outputmakefile \
+archprepare: archheaders archscripts scripts include/config/kernel.release 
outputmakefile \
asm-generic $(version_h) $(autoksyms_h) include/generated/utsrelease.h
 
 prepare0: archprepare
@@ -1261,11 +1259,11 @@ endif
 
 ifneq ($(dtstree),)
 
-%.dtb: prepare3 scripts_dtc
+%.dtb: include/config/kernel.release scripts_dtc
$(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
 
 PHONY += dtbs dtbs_install dt_binding_check
-dtbs dtbs_check: prepare3 scripts_dtc
+dtbs dtbs_check: include/config/kernel.release scripts_dtc
$(Q)$(MAKE) $(build)=$(dtstree)
 
 dtbs_check: export CHECK_DTBS=1
-- 
2.17.1

[PATCH 4/6] kbuild: move the clean srctree check to the outputmakefile target

[Masahiro Yamada]

With this commit, the error report is shown earlier, even before
running kconfig.

Signed-off-by: Masahiro Yamada 
---

 Makefile | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/Makefile b/Makefile
index 901fcb8fffbe..ca6851f5ebc9 100644
--- a/Makefile
+++ b/Makefile
@@ -522,6 +522,7 @@ scripts_basic:
$(Q)rm -f .tmp_quiet_recordmcount
 
 PHONY += outputmakefile
+# Before starting out-of-tree build, make sure the source tree is clean.
 # outputmakefile generates a Makefile in the output directory, if using a
 # separate output directory. This allows convenient use of make in the
 # output directory.
@@ -529,6 +530,15 @@ PHONY += outputmakefile
 # ignore whole output directory
 outputmakefile:
 ifdef building_out_of_srctree
+   $(Q)if [ -f $(srctree)/.config -o \
+-d $(srctree)/include/config -o \
+-d $(srctree)/arch/$(SRCARCH)/include/generated ]; then \
+   echo >&2 "***"; \
+   echo >&2 "*** The source tree is not clean, please run 
'make$(if $(findstring command line, $(origin ARCH)), ARCH=$(ARCH)) mrproper'"; 
\
+   echo >&2 "*** in $(abs_srctree)";\
+   echo >&2 "***"; \
+   false; \
+   fi
$(Q)ln -fsn $(srctree) source
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkmakefile $(srctree)
$(Q)test -e .gitignore || \
@@ -1113,21 +1123,7 @@ scripts: scripts_basic scripts_dtc
 
 PHONY += prepare archprepare prepare3
 
-# prepare3 is used to check if we are building in a separate output directory,
-# and if so do:
-# 1) Check that make has not been executed in the kernel src $(srctree)
 prepare3: include/config/kernel.release
-ifdef building_out_of_srctree
-   $(Q)if [ -f $(srctree)/.config -o \
--d $(srctree)/include/config -o \
--d $(srctree)/arch/$(SRCARCH)/include/generated ]; then \
-   echo >&2 "***"; \
-   echo >&2 "*** The source tree is not clean, please run 
'make$(if $(findstring command line, $(origin ARCH)), ARCH=$(ARCH)) mrproper'"; 
\
-   echo >&2 "*** in $(abs_srctree)";\
-   echo >&2 "***"; \
-   /bin/false; \
-   fi;
-endif
 
 archprepare: archheaders archscripts scripts prepare3 outputmakefile \
asm-generic $(version_h) $(autoksyms_h) include/generated/utsrelease.h
-- 
2.17.1

[PATCH 6/6] kbuild: check clean srctree even earlier

[Masahiro Yamada]

Move the outputmakefile target to the leftmost in the prerequisite list
so that this is checked first. There is no guarantee that Make runs the
prerequisites from left to right, but at least the released versions of
GNU Make work like that when the parallel build option is not given.

Of course, when the parallel option -j given, other targets will be run
simultaneously but it is nice to show the error as early as possible.

Signed-off-by: Masahiro Yamada 
---

 Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 960df4d35b15..089983a8a028 100644
--- a/Makefile
+++ b/Makefile
@@ -581,10 +581,10 @@ ifdef config-build
 include arch/$(SRCARCH)/Makefile
 export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT
 
-config: scripts_basic outputmakefile FORCE
+config: outputmakefile scripts_basic FORCE
$(Q)$(MAKE) $(build)=scripts/kconfig $@
 
-%config: scripts_basic outputmakefile FORCE
+%config: outputmakefile scripts_basic FORCE
$(Q)$(MAKE) $(build)=scripts/kconfig $@
 
 else #!config-build
@@ -1123,7 +1123,7 @@ scripts: scripts_basic scripts_dtc
 
 PHONY += prepare archprepare
 
-archprepare: archheaders archscripts scripts include/config/kernel.release 
outputmakefile \
+archprepare: outputmakefile archheaders archscripts scripts 
include/config/kernel.release \
asm-generic $(version_h) $(autoksyms_h) include/generated/utsrelease.h
 
 prepare0: archprepare
-- 
2.17.1

[PATCH 2/6] kbuild: Inform user to pass ARCH= for make mrproper only when necessary

[Masahiro Yamada]

Since commit 3a475b2166fd ("kbuild: Inform user to pass ARCH= for make
mrproper"), if you try out-of-tree build with an unclean source tree,
it suggests to run 'make ARCH= mrproper'.

This looks odd when you are not cross-compiling the kernel. Show the
'ARCH=' part only when ARCH= was given from the command line.
If ARCH is the default (native build) or came from the environment,
it should simply suggest 'make mrproper' as before.

Signed-off-by: Masahiro Yamada 
---

 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index a77102e4ee90..d9cbbc27d4ba 100644
--- a/Makefile
+++ b/Makefile
@@ -1121,7 +1121,7 @@ ifdef building_out_of_srctree
$(Q)if [ -f $(srctree)/.config -o \
 -d $(srctree)/include/config -o \
 -d $(srctree)/arch/$(SRCARCH)/include/generated ]; then \
-   echo >&2 "  $(srctree) is not clean, please run 'make 
ARCH=$(ARCH) mrproper'"; \
+   echo >&2 "  $(srctree) is not clean, please run 'make$(if 
$(findstring command line, $(origin ARCH)), ARCH=$(ARCH)) mrproper'"; \
echo >&2 "  in the '$(srctree)' directory.";\
/bin/false; \
fi;
-- 
2.17.1

Re: [PATCH v3 1/3] RISC-V: Issue a local tlbflush if possible.

[h...@lst.de]

On Thu, Aug 22, 2019 at 04:01:24AM +, Atish Patra wrote:
> The downside of this is that for every !cmask case in true SMP (more
> common probably) it will execute 2 extra cpumask instructions. As
> tlbflush path is in performance critical path, I think we should favor
> more common case (SMP with more than 1 core).

Actually, looking at both the current mainline code, and the code from my
cleanups tree I don't think remote_sfence_vma / __sbi_tlb_flush_range
can ever be called with  NULL cpumask, as we always have a valid mm.

So this is a bit of a moot point, and we can drop andling that case
entirely.  With that we can also use a simple if / else for the local
cpu only vs remote case.  Btw, what was the reason you didn't like
using cpumask_any_but like x86, which should be more efficient than
cpumask_test_cpu + hweigt?

Re: [PATCH v3 3/3] RISC-V: Do not invoke SBI call if cpumask is empty

[Atish Patra]

On Thu, 2019-08-22 at 03:51 +0200, Christoph Hellwig wrote:
> On Wed, Aug 21, 2019 at 05:46:44PM -0700, Atish Patra wrote:
> > SBI calls are expensive. If cpumask is empty, there is no need to
> > trap via SBI as no remote tlb flushing is required.
> > 
> > Signed-off-by: Atish Patra 
> > ---
> >  arch/riscv/mm/tlbflush.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c
> > index 9f58b3790baa..2bd3c418d769 100644
> > --- a/arch/riscv/mm/tlbflush.c
> > +++ b/arch/riscv/mm/tlbflush.c
> > @@ -21,6 +21,9 @@ static void __sbi_tlb_flush_range(struct cpumask
> > *cmask, unsigned long start,
> > goto issue_sfence;
> > }
> >  
> > +   if (cpumask_empty(cmask))
> > +   goto done;
> 
> I think this can even be done before the get_cpu to optimize it a
> little
> further.

Yeah. I can just return directly in this case and call get_cpu after
this. Thanks for the suggestion.


-- 
Regards,
Atish

Re: [PATCH v2] fs: fs_parser: avoid NULL param->string to kstrtouint

[Eric Biggers]

[trimmed Cc list a bit]

On Thu, Aug 15, 2019 at 07:46:56PM -0700, Eric Biggers wrote:
> On Sat, Jul 20, 2019 at 07:29:49AM +0800, Yin Fengwei wrote:
> > syzbot reported general protection fault in kstrtouint:
> > https://lkml.org/lkml/2019/7/18/328
> > 
> > From the log, if the mount option is something like:
> >fd,
> > 
> > The default parameter (which has NULL param->string) will be
> > passed to vfs_parse_fs_param. Finally, this NULL param->string
> > is passed to kstrtouint and trigger NULL pointer access.
> > 
> > Reported-by: syzbot+398343b7c1b1b9892...@syzkaller.appspotmail.com
> > Fixes: 71cbb7570a9a ("vfs: Move the subtype parameter into fuse")
> > 
> > Signed-off-by: Yin Fengwei 
> > ---
> > ChangeLog:
> >  v1 -> v2:
> >- Fix typo in v1
> >- Remove braces {} from single statement blocks
> > 
> >  fs/fs_parser.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/fs/fs_parser.c b/fs/fs_parser.c
> > index 83b66c9e9a24..7498a44f18c0 100644
> > --- a/fs/fs_parser.c
> > +++ b/fs/fs_parser.c
> > @@ -206,6 +206,9 @@ int fs_parse(struct fs_context *fc,
> > case fs_param_is_fd: {
> > switch (param->type) {
> > case fs_value_is_string:
> > +   if (!result->has_value)
> > +   goto bad_value;
> > +
> > ret = kstrtouint(param->string, 0, &result->uint_32);
> > break;
> > case fs_value_is_file:
> > -- 
> > 2.17.1
> 
> Reviewed-by: Eric Biggers 
> 
> Al, can you please apply this patch?
> 
> - Eric

Ping.  Al, when are you going to apply this?

- Eric

RE: [PATCH net-next,v3, 0/6] Add software backchannel and mlx5e HV VHCA stats

[Haiyang Zhang]

> -Original Message-
> From: linux-hyperv-ow...@vger.kernel.org  ow...@vger.kernel.org> On Behalf Of David Miller
> Sent: Wednesday, August 21, 2019 9:09 PM
> To: Haiyang Zhang 
> Cc: sas...@kernel.org; sae...@mellanox.com; l...@kernel.org;
> era...@mellanox.com; lorenzo.pieral...@arm.com; bhelg...@google.com;
> linux-...@vger.kernel.org; linux-hyp...@vger.kernel.org;
> net...@vger.kernel.org; KY Srinivasan ; Stephen
> Hemminger ; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next,v3, 0/6] Add software backchannel and mlx5e
> HV VHCA stats
> 
> From: Haiyang Zhang 
> Date: Wed, 21 Aug 2019 00:23:19 +
> 
> > This patch set adds paravirtual backchannel in software in pci_hyperv,
> > which is required by the mlx5e driver HV VHCA stats agent.
> >
> > The stats agent is responsible on running a periodic rx/tx
> > packets/bytes stats update.
> 
> These patches don't apply cleanly to net-next, probably due to some recent
> mlx5 driver changes.
> 
> Please respin.

I will do.
Thanks,

- Haiyang

Re: [PATCH net-next,v3, 0/6] Add software backchannel and mlx5e HV VHCA stats

[David Miller]

From: Haiyang Zhang 
Date: Wed, 21 Aug 2019 00:23:19 +

> This patch set adds paravirtual backchannel in software in pci_hyperv,
> which is required by the mlx5e driver HV VHCA stats agent.
> 
> The stats agent is responsible on running a periodic rx/tx packets/bytes
> stats update.

These patches don't apply cleanly to net-next, probably due to some recent
mlx5 driver changes.

Please respin.

Re: [PATCH] arm: skip nomap memblocks while finding the lowmem/highmem boundary

[Chester Lin]

On Thu, Aug 22, 2019 at 11:45:34AM +0800, Chester Lin wrote:
> adjust_lowmem_bounds() checks every memblocks in order to find the boundary
> between lowmem and highmem. However some memblocks could be marked as NOMAP
> so they are not used by kernel, which should be skipped while calculating
> the boundary.
> 
> Signed-off-by: Chester Lin 
> ---
>  arch/arm/mm/mmu.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 426d9085396b..b86dba44d828 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1181,6 +1181,9 @@ void __init adjust_lowmem_bounds(void)
>   phys_addr_t block_start = reg->base;
>   phys_addr_t block_end = reg->base + reg->size;
>  
> + if (memblock_is_nomap(reg))
> + continue;
> +
>   if (reg->base < vmalloc_limit) {
>   if (block_end > lowmem_limit)
>   /*
> -- 
> 2.22.0
>

Hi Russell, Mike and Ard,

Per the discussion in the thread "[PATH] efi/arm: fix allocation failure ...",
(https://lkml.org/lkml/2019/8/21/163), I presume that the change to disregard
NOMAP memblocks in adjust_lowmem_bounds() should be separated as a single patch.

Please let me know if any suggestion, thank you.

Re: [PATCH] selftests: net: add missing NFT_FWD_NETDEV to config

[David Miller]

From: Anders Roxell 
Date: Tue, 20 Aug 2019 15:41:02 +0200

> When running xfrm_policy.sh we see the following
> 
>  # sysctl cannot stat /proc/sys/net/ipv4/conf/eth1/forwarding No such file or 
> directory
>  cannot: stat_/proc/sys/net/ipv4/conf/eth1/forwarding #

I don't understand how a netfilter config options is going to make that
generic ipv4 protocol per-device sysctl appear.

If it's unrelated to your change, don't include it in the commit message
as it is confusing.

Thank you.

Re: [PATCH v3 2/3] RISC-V: Issue a tlb page flush if possible

[Atish Patra]

On Thu, 2019-08-22 at 03:50 +0200, Christoph Hellwig wrote:
> On Wed, Aug 21, 2019 at 05:46:43PM -0700, Atish Patra wrote:
> > +   if (size <= PAGE_SIZE && size != -1)
> > +   local_flush_tlb_page(start);
> > +   else
> > +   local_flush_tlb_all();
> 
> As Andreas pointed out (unsigned long)-1 is actually larger than
> PAGE_SIZE, so we don't need the extra check.

Ahh yes. Sorry I missed his comment in the earlier email. Fixed it.

-- 
Regards,
Atish

Re: [PATCH v3 1/3] RISC-V: Issue a local tlbflush if possible.

[Atish Patra]

On Thu, 2019-08-22 at 03:46 +0200, Christoph Hellwig wrote:
> On Wed, Aug 21, 2019 at 05:46:42PM -0700, Atish Patra wrote:
> > In RISC-V, tlb flush happens via SBI which is expensive. If the
> > local
> > cpu is the only cpu in cpumask, there is no need to invoke a SBI
> > call.
> > 
> > Just do a local flush and return.
> > 
> > Signed-off-by: Atish Patra 
> > ---
> >  arch/riscv/mm/tlbflush.c | 15 +++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c
> > index df93b26f1b9d..36430ee3bed9 100644
> > --- a/arch/riscv/mm/tlbflush.c
> > +++ b/arch/riscv/mm/tlbflush.c
> > @@ -2,6 +2,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  void flush_tlb_all(void)
> > @@ -13,9 +14,23 @@ static void __sbi_tlb_flush_range(struct cpumask
> > *cmask, unsigned long start,
> > unsigned long size)
> >  {
> > struct cpumask hmask;
> > +   unsigned int cpuid = get_cpu();
> >  
> > +   if (!cmask) {
> > +   riscv_cpuid_to_hartid_mask(cpu_online_mask, &hmask);
> > +   goto issue_sfence;
> > +   }
> > +
> > +   if (cpumask_test_cpu(cpuid, cmask) && cpumask_weight(cmask) ==
> > 1) {
> > +   local_flush_tlb_all();
> > +   goto done;
> > +   }
> 
> I think a single core on a SMP kernel is a valid enough use case
> given
> how litte distros still have UP kernels.  So Maybe this shiuld rather
> be:
> 
>   if (!cmask)
>   cmask = cpu_online_mask;
> 
>   if (cpumask_test_cpu(cpuid, cmask) && cpumask_weight(cmask) ==
> 1) {
>   local_flush_tlb_all();
>   } else {
>   riscv_cpuid_to_hartid_mask(cmask, &hmask);
>   sbi_remote_sfence_vma(hmask.bits, start, size);
>   }

The downside of this is that for every !cmask case in true SMP (more
common probably) it will execute 2 extra cpumask instructions. As
tlbflush path is in performance critical path, I think we should favor
more common case (SMP with more than 1 core).

Thoughts ?

-- 
Regards,
Atish

[PATCH] kbuild: get rid of $(realpath ...) from scripts/mkmakefile

[Masahiro Yamada]

Both relative path and absolute path have pros and cons. For example,
we can move the source and objtree around together by using the
relative path to the source tree.

Do not force the absolute path to the source tree. If you prefer the
absolute path, you can specify KBUILD_ABS_SRCTREE=1.

Signed-off-by: Masahiro Yamada 
---

 scripts/mkmakefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/mkmakefile b/scripts/mkmakefile
index 4d0faebb1719..1cb174751429 100755
--- a/scripts/mkmakefile
+++ b/scripts/mkmakefile
@@ -12,6 +12,6 @@ if [ "${quiet}" != "silent_" ]; then
 fi
 
 cat << EOF > Makefile
-# Automatically generated by $(realpath $0): don't edit
-include $(realpath $1/Makefile)
+# Automatically generated by $0: don't edit
+include $1/Makefile
 EOF
-- 
2.17.1

Re: [PATCH net-next v3 0/4] Improve phc2sys precision for mv88e6xxx switch in combination with imx6-fec

[David Miller]

From: Hubert Feurstein 
Date: Tue, 20 Aug 2019 10:48:29 +0200

> From: Hubert Feurstein 
> 
> Changelog:
>  v3: mv88e6xxx_smi_indirect_write: forward ptp_sts only on the last write
>  Copied Miroslav Lichvar because of PTP offset compensation patch
>  v2: Added patch for PTP offset compensation
>  Removed mdiobus_write_sts as there was no user
>  Removed ptp_sts_supported-boolean and introduced flags instead
> 
> With this patchset the phc2sys synchronisation precision improved to +/-555ns 
> on
> an IMX6DL with an MV88E6220 switch attached.
> 
> This patchset takes into account the comments from the following discussions:
> - https://lkml.org/lkml/2019/8/2/1364
> - https://lkml.org/lkml/2019/8/5/169
> 
> Patch 01 adds the required infrastructure in the MDIO layer.
> Patch 02 adds additional PTP offset compensation.
> Patch 03 adds support for the PTP_SYS_OFFSET_EXTENDED ioctl in the mv88e6xxx 
> driver.
> Patch 04 adds support for the PTP system timestamping in the imx-fec driver.

It looks like there is still some active discussion about these changes and
there will likely be another spin.

Re: [PATCH] rcu: don't include in rcutiny.h

[Christoph Hellwig]

On Wed, Aug 21, 2019 at 08:02:00PM -0700, Paul E. McKenney wrote:
> On Thu, Aug 22, 2019 at 10:53:43AM +0900, Christoph Hellwig wrote:
> > The kbuild reported a built failure due to a header loop when RCUTINY is
> > enabled with my pending riscv-nommu port.  Switch rcutiny.h to only
> > include the minimal required header to get HZ instead.
> > 
> > Signed-off-by: Christoph Hellwig 
> 
> Queued for review and testing, thank you!
> 
> Do you need this in v5.4?  My normal workflow would put it into v5.5.

I hope the riscv-nommu coe gets merges for 5.4, so if we could queue
it up for that I'd appreciate it.

[PATCH] arm: skip nomap memblocks while finding the lowmem/highmem boundary

[Chester Lin]

adjust_lowmem_bounds() checks every memblocks in order to find the boundary
between lowmem and highmem. However some memblocks could be marked as NOMAP
so they are not used by kernel, which should be skipped while calculating
the boundary.

Signed-off-by: Chester Lin 
---
 arch/arm/mm/mmu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 426d9085396b..b86dba44d828 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1181,6 +1181,9 @@ void __init adjust_lowmem_bounds(void)
phys_addr_t block_start = reg->base;
phys_addr_t block_end = reg->base + reg->size;
 
+   if (memblock_is_nomap(reg))
+   continue;
+
if (reg->base < vmalloc_limit) {
if (block_end > lowmem_limit)
/*
-- 
2.22.0

Re: [PATCH] x86/apic: Update virtual irq base for DT/OF based system as well

[Tanwar, Rahul]

Hi Thomas,

On 22/8/2019 12:47 AM, Andy Shevchenko wrote:

For DT we can actually avoid that completely. See below.

For ACPI not unfortunately as the stupid GSI mapping is hard coded.

The below works better for my case, so, if you are going with that
Tested-by: Andy Shevchenko 


8<-
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2438,7 +2438,13 @@ unsigned int arch_dynirq_lower_bound(uns
 * dmar_alloc_hwirq() may be called before setup_IO_APIC(), so use
 * gsi_top if ioapic_dynirq_base hasn't been initialized yet.
 */
-   return ioapic_initialized ? ioapic_dynirq_base : gsi_top;
+   if (!ioapic_initialized)
+   return gsi_top;
+   /*
+* For DT enabled machines ioapic_dynirq_base is irrelevant and not
+* updated. So simply return @from if ioapic_dynirq_base == 0.
+*/
+   return ioapic_dynirq_base ? : from;
  }
  
  #ifdef CONFIG_X86_32



I have also tested above and it works fine. In fact, my first patch to

resolve it during internal review was exactly on similar lines. So if

you are going to add above then i will stop following up on this

topic further. Thanks.


Regards,

Rahul

Re: [PATCH 2/4] memremap: remove the dev field in struct dev_pagemap

[Dan Williams]

On Wed, Aug 21, 2019 at 4:51 PM Jason Gunthorpe  wrote:
>
> On Wed, Aug 21, 2019 at 01:24:20PM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 20, 2019 at 07:58:22PM -0700, Dan Williams wrote:
> > > On Tue, Aug 20, 2019 at 6:27 AM Jason Gunthorpe  wrote:
> > > >
> > > > On Mon, Aug 19, 2019 at 06:44:02PM -0700, Dan Williams wrote:
> > > > > On Sun, Aug 18, 2019 at 2:12 AM Christoph Hellwig  wrote:
> > > > > >
> > > > > > The dev field in struct dev_pagemap is only used to print dev_name 
> > > > > > in
> > > > > > two places, which are at best nice to have.  Just remove the field
> > > > > > and thus the name in those two messages.
> > > > > >
> > > > > > Signed-off-by: Christoph Hellwig 
> > > > > > Reviewed-by: Ira Weiny 
> > > > >
> > > > > Needs the below as well.
> > > > >
> > > > > /me goes to check if he ever merged the fix to make the unit test
> > > > > stuff get built by default with COMPILE_TEST [1]. Argh! Nope, didn't
> > > > > submit it for 5.3-rc1, sorry for the thrash.
> > > > >
> > > > > You can otherwise add:
> > > > >
> > > > > Reviewed-by: Dan Williams 
> > > > >
> > > > > [1]: 
> > > > > https://lore.kernel.org/lkml/156097224232.1086847.9463861924683372741.st...@dwillia2-desk3.amr.corp.intel.com/
> > > >
> > > > Can you get this merged? Do you want it to go with this series?
> > >
> > > Yeah, makes some sense to let you merge it so that you can get
> > > kbuild-robot reports about any follow-on memremap_pages() work that
> > > may trip up the build. Otherwise let me know and I'll get it queued
> > > with the other v5.4 libnvdimm pending bits.
> >
> > Done, I used it already to test build the last series from CH..
>
> It failed 0-day, I'm guessing some missing kconfig stuff
>
> For now I dropped it, but, if you send a v2 I can forward it toward
> 0-day again!

The system works!

Sorry for that thrash, I'll track it down.

Re: [PATCH v1 03/63] Input: atmel_mxt_ts - only read messages in mxt_acquire_irq() when necessary

[Jiada Wang]

Hi

On 2019/08/22 2:54, Dmitry Torokhov wrote:

On Wed, Aug 21, 2019 at 10:26:31PM +0900, Jiada Wang wrote:

Hi Dmitry

On 2019/08/17 2:16, Dmitry Torokhov wrote:

On Fri, Aug 16, 2019 at 05:28:52PM +0900, Jiada Wang wrote:

From: Nick Dyer 

The workaround of reading all messages until an invalid is received is a
way of forcing the CHG line high, which means that when using
edge-triggered interrupts the interrupt can be acquired.

With level-triggered interrupts the workaround is unnecessary.

Also, most recent maXTouch chips have a feature called RETRIGEN which, when
enabled, reasserts the interrupt line every cycle if there are messages
waiting. This also makes the workaround unnecessary.

Note: the RETRIGEN feature is only in some firmware versions/chips, it's
not valid simply to enable the bit.


Instead of trying to work around of misconfiguration for IRQ/firmware,
can we simply error out of probe if we see a level interrupt with
!RETRIGEN firmware?


I think for old firmwares, which doesn't support RETRIGEN feature, this
workaround is needed, otherwise we will break all old firmwares, which
configured with edge-triggered IRQ


Do you know if there are any? I know Chrome OS firmware have RETRIGEN
activated and they are pretty old (original Pixel is from 2013). But if
we indeed have devices with edge interrupt and old not firmware that
does not retrigger, I guess we'll have to keep it...



Honestly I don't know firmwares/chips which don't support RETRIGEN feature.

BUT Dyer originally authored this patch in 2012, I assume here "old" 
firmware/chips means, those before 2012.



Thanks,
Jiada


Thanks.

Re: [PATCH v3 2/3] drivers: hv: vmbus: add test attributes to debugfs

[Branden Bonaby]

> > +What:   /sys/kernel/debug/hyperv//fuzz_test_state
> > +Date:   August 2019
> > +KernelVersion:  5.3
> > +Contact:Branden Bonaby 
> > +Description:Fuzz testing status of a vmbus device, whether its in an ON
> > +state or a OFF state
> 
> Document what values are actually returned?  
> 
> > +Users:  Debugging tools
> > +
> > +What:   
> > /sys/kernel/debug/hyperv//delay/fuzz_test_buffer_interrupt_delay
> > +Date:   August 2019
> > +KernelVersion:  5.3
> > +Contact:Branden Bonaby 
> > +Description:Fuzz testing buffer delay value between 0 - 1000
> 
> It would be helpful to document the units -- I think this is 0 to 1000
> microseconds.

you're right, that makes sense I'll add that information in. Also 
to confirm, it is microseconds like you said.

> > +static int hv_debugfs_delay_set(void *data, u64 val)
> > +{
> > +   if (val >= 1 && val <= 1000)
> > +   *(u32 *)data = val;
> > +   /*Best to not use else statement here since we want
> > +* the delay to remain the same if val > 1000
> > +*/
> 
> The standard multi-line comment style would be:
> 
>   /*
>* Best to not use else statement here since we want
>* the delay to remain the same if val > 1000
>*/
>

will change

> > +   else if (val <= 0)
> > +   *(u32 *)data = 0;
> 
> You could consider returning an error for an invalid
> value (< 0, or > 1000).
> 

its subtle but it does make sense and shows anyone
reading that the only acceptable values in the 
function are 0 <= 1000 at a glance. I'll add
that in.

Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch modules

[Masahiro Yamada]

Hi Joe,

On Tue, Aug 20, 2019 at 1:02 AM Joe Lawrence  wrote:
>
> On 8/19/19 3:31 AM, Miroslav Benes wrote:
> > On Mon, 19 Aug 2019, Masahiro Yamada wrote:
> >
> >>
> >> I can review this series from the build system point of view,
> >> but I am not familiar enough with live-patching itself.
> >>
> >> Some possibilities:
> >>
> >> [1] Merge this series thru the live-patch tree after the
> >>  kbuild base patches land.
> >>  This requires one extra development cycle (targeting for 5.5-rc1)
> >>  but I think this is the official way if you do not rush into it.
> >
> > I'd prefer this option. There is no real rush and I think we can wait one
> > extra development cycle.
>
> Agreed.  I'm in no hurry and was only curious about the kbuild changes
> that this patchset is now dependent on -- how to note them for other
> reviewers or anyone wishing to test.
>
> > Joe, could you submit one more revision with all the recent changes (once
> > kbuild improvements settle down), please? We should take a look at the
> > whole thing one more time? What do you think?
> >
>
> Definitely, yes.  I occasionally force a push to:
> https://github.com/joe-lawrence/linux/tree/klp-convert-v5-expanded
>
> as I've been updating and collecting feedback from v4.  Once updates
> settle, I'll send out a new v5 set.
>
> -- Joe

When you send v5, please squash the following clean-up too:



diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
index 89eaef0d3efc..9e77246d84e3 100644
--- a/scripts/Makefile.modfinal
+++ b/scripts/Makefile.modfinal
@@ -47,7 +47,7 @@ targets += $(modules) $(modules:.ko=.mod.o)
 # Live Patch
 # ---

-$(modules-klp:.ko=.tmp.ko): %.tmp.ko: %.o %.mod.o Symbols.list FORCE
+%.tmp.ko: %.o %.mod.o Symbols.list FORCE
+$(call if_changed,ld_ko_o)

 quiet_cmd_klp_convert = KLP $@




Thanks.


-- 
Best Regards
Masahiro Yamada

[PATCH v3] vfio_pci: Restore original state on release

[hexin]

vfio_pci_enable() saves the device's initial configuration information
with the intent that it is restored in vfio_pci_disable().  However,
the commit referenced in Fixes: below replaced the call to
__pci_reset_function_locked(), which is not wrapped in a state save
and restore, with pci_try_reset_function(), which overwrites the
restored device state with the current state before applying it to the
device.  Reinstate use of __pci_reset_function_locked() to return to
the desired behavior.

Fixes: 890ed578df82 ("vfio-pci: Use pci "try" reset interface")
Signed-off-by: hexin 
Signed-off-by: Liu Qi 
Signed-off-by: Zhang Yu 
---
v2->v3:
- change commit log 
v1->v2:
- add fixes tag
- add comment to warn 

[1] 
https://lore.kernel.org/linux-pci/1565926427-21675-1-git-send-email-hexi...@baidu.com
[2] 
https://lore.kernel.org/linux-pci/1566042663-16694-1-git-send-email-hexi...@baidu.com

 drivers/vfio/pci/vfio_pci.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 703948c..0220616 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -438,11 +438,20 @@ static void vfio_pci_disable(struct vfio_pci_device *vdev)
pci_write_config_word(pdev, PCI_COMMAND, PCI_COMMAND_INTX_DISABLE);
 
/*
-* Try to reset the device.  The success of this is dependent on
-* being able to lock the device, which is not always possible.
+* Try to get the locks ourselves to prevent a deadlock. The
+* success of this is dependent on being able to lock the device,
+* which is not always possible.
+* We can not use the "try" reset interface here, which will
+* overwrite the previously restored configuration information.
 */
-   if (vdev->reset_works && !pci_try_reset_function(pdev))
-   vdev->needs_reset = false;
+   if (vdev->reset_works && pci_cfg_access_trylock(pdev)) {
+   if (device_trylock(&pdev->dev)) {
+   if (!__pci_reset_function_locked(pdev))
+   vdev->needs_reset = false;
+   device_unlock(&pdev->dev);
+   }
+   pci_cfg_access_unlock(pdev);
+   }
 
pci_restore_state(pdev);
 out:
-- 
1.8.3.1

Re: [PATCH net] net: dsa: bcm_sf2: Do not configure PHYLINK on CPU port

[David Miller]

From: Florian Fainelli 
Date: Wed, 21 Aug 2019 17:07:46 -0700

> The SF2 binding does not specify that the CPU port should have
> properties mandatory for successfully instantiating a PHYLINK object. As
> such, there will be missing properties (including fixed-link) and when
> attempting to validate and later configure link modes, we will have an
> incorrect set of parameters (interface, speed, duplex).
> 
> Simply prevent the CPU port from being configured through PHYLINK since
> bcm_sf2_imp_setup() takes care of that already.
> 
> Fixes: 0e27921816ad ("net: dsa: Use PHYLINK for the CPU/DSA ports")
> Signed-off-by: Florian Fainelli 

Applied, thanks Florian.

Re: KMSAN: uninit-value in rtm_new_nexthop

[David Ahern]

On 8/21/19 6:38 PM, syzbot wrote:
> ==
> BUG: KMSAN: uninit-value in rtm_to_nh_config net/ipv4/nexthop.c:1317
> [inline]
> BUG: KMSAN: uninit-value in rtm_new_nexthop+0x447/0x98e0
> net/ipv4/nexthop.c:1474

I believed this is fixed in net by commit:

Author: David Ahern 
Date:   Mon Aug 12 13:07:07 2019 -0700

netlink: Fix nlmsg_parse as a wrapper for strict message parsing

Re: [PATCH v2] ARM: UNWINDER_FRAME_POINTER implementation for Clang

[Nick Desaulniers]

On Wed, Aug 21, 2019 at 10:46 AM Nathan Huckleberry  wrote:
>
> The stackframe setup when compiled with clang is different.
> Since the stack unwinder expects the gcc stackframe setup it
> fails to print backtraces. This patch adds support for the
> clang stackframe setup.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/35
> Cc: clang-built-li...@googlegroups.com
> Suggested-by: Tri Vo 
> Signed-off-by: Nathan Huckleberry 
> ---
> Changes from v1->v2
> * Fix indentation in various files
> * Swap spaces for tabs
> * Rename Ldsi to Lopcode
> * Remove unused Ldsi entry
>
>  arch/arm/Kconfig.debug |   2 +-
>  arch/arm/Makefile  |   5 +-
>  arch/arm/lib/Makefile  |   8 +-
>  arch/arm/lib/backtrace-clang.S | 229 +
>  4 files changed, 241 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/lib/backtrace-clang.S
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 85710e078afb..b9c674ec19e0 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -56,7 +56,7 @@ choice
>
>  config UNWINDER_FRAME_POINTER
> bool "Frame pointer unwinder"
> -   depends on !THUMB2_KERNEL && !CC_IS_CLANG
> +   depends on !THUMB2_KERNEL
> select ARCH_WANT_FRAME_POINTERS
> select FRAME_POINTER
> help
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c3624ca6c0bc..6f251c201db0 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -36,7 +36,10 @@ KBUILD_CFLAGS+= $(call 
> cc-option,-mno-unaligned-access)
>  endif
>
>  ifeq ($(CONFIG_FRAME_POINTER),y)
> -KBUILD_CFLAGS  +=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
> +KBUILD_CFLAGS  +=-fno-omit-frame-pointer
> +ifeq ($(CONFIG_CC_IS_GCC),y)
> +KBUILD_CFLAGS += -mapcs -mno-sched-prolog
> +endif
>  endif
>
>  ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index b25c54585048..6d2ba454f25b 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -5,7 +5,7 @@
>  # Copyright (C) 1995-2000 Russell King
>  #
>
> -lib-y  := backtrace.o changebit.o csumipv6.o csumpartial.o   \
> +lib-y  := changebit.o csumipv6.o csumpartial.o   \
>csumpartialcopy.o csumpartialcopyuser.o clearbit.o \
>delay.o delay-loop.o findbit.o memchr.o memcpy.o   \
>memmove.o memset.o setbit.o\
> @@ -19,6 +19,12 @@ lib-y:= backtrace.o changebit.o csumipv6.o 
> csumpartial.o   \
>  mmu-y  := clear_user.o copy_page.o getuser.o putuser.o   \
>copy_from_user.o copy_to_user.o
>
> +ifdef CONFIG_CC_IS_CLANG
> +  lib-y+= backtrace-clang.o
> +else
> +  lib-y+= backtrace.o
> +endif
> +
>  # using lib_ here won't override already available weak symbols
>  obj-$(CONFIG_UACCESS_WITH_MEMCPY) += uaccess_with_memcpy.o
>
> diff --git a/arch/arm/lib/backtrace-clang.S b/arch/arm/lib/backtrace-clang.S
> new file mode 100644
> index ..6f2a8a57d0fb
> --- /dev/null
> +++ b/arch/arm/lib/backtrace-clang.S
> @@ -0,0 +1,229 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + *  linux/arch/arm/lib/backtrace-clang.S
> + *
> + *  Copyright (C) 2019 Nathan Huckleberry
> + *
> + */
> +#include 
> +#include 
> +#include 
> +   .text
> +
> +/* fp is 0 or stack frame */
> +
> +#define frame  r4
> +#define sv_fp  r5
> +#define sv_pc  r6
> +#define mask   r7
> +#define sv_lr  r8
> +
> +ENTRY(c_backtrace)
> +
> +#if !defined(CONFIG_FRAME_POINTER) || !defined(CONFIG_PRINTK)
> +   ret lr
> +ENDPROC(c_backtrace)
> +#else
> +
> +
> +/*
> + * Clang does not store pc or sp in function prologues
> + * so we don't know exactly where the function
> + * starts.

To quickly re-wrap text (if you're using vim) such as with comments like these:
shift+v (VISUAL LINE MODE)
j or k to highlight lines
gq (to rewrap)
You may need `set cc=80` (not sure).

> + *
> + * We can treat the current frame's lr as the saved pc and the
> + * preceding frame's lr as the current frame's lr,
> + * but we can't trace the most recent call.
> + * Inserting a false stack frame allows us to reference the
> + * function called last in the stacktrace.
> + *
> + * If the call instruction was a bl we can look at the callers
> + * branch instruction to calculate the saved pc.
> + * We can recover the pc in most cases, but in cases such as
> + * calling function pointers we cannot. In this
> + * case, default to using the lr. This will be
> + * some address in the function, but will not
> + * be the function start.
> + *
> + * Unfortunately due to the stack frame layout we can't dump
> + *  r0 - r3, but these are less frequently saved.

I guess if they were spilled, but I'm ok with this; I'd rather have a
working unwinder than disabled config.  The printing is a debug
feature that's nice to have, but the main focus should be unwindin

[PATCH] gpio: Move gpiochip_lock/unlock_as_irq to gpio/driver.h

[YueHaibing]

If CONFIG_GPIOLIB is not, gpiochip_lock/unlock_as_irq will
conflict as this:

In file included from sound/soc/codecs/wm5100.c:18:0:
./include/linux/gpio.h:224:19: error: static declaration of 
gpiochip_lock_as_irq follows non-static declaration
 static inline int gpiochip_lock_as_irq(struct gpio_chip *chip,
   ^~~~
In file included from sound/soc/codecs/wm5100.c:17:0:
./include/linux/gpio/driver.h:494:5: note: previous declaration of 
gpiochip_lock_as_irq was here
 int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
 ^~~~
In file included from sound/soc/codecs/wm5100.c:18:0:
./include/linux/gpio.h:231:20: error: static declaration of 
gpiochip_unlock_as_irq follows non-static declaration
 static inline void gpiochip_unlock_as_irq(struct gpio_chip *chip,
^~
In file included from sound/soc/codecs/wm5100.c:17:0:
./include/linux/gpio/driver.h:495:6: note: previous declaration of 
gpiochip_unlock_as_irq was here
 void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
 ^~

Move them to gpio/driver.h and use CONFIG_GPIOLIB guard this.

Reported-by: Hulk Robot 
Fixes: d74be6dfea1b ("gpio: remove gpiod_lock/unlock_as_irq()")
Signed-off-by: YueHaibing 
---
 include/linux/gpio.h| 13 -
 include/linux/gpio/driver.h | 19 ---
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index f757a58..2157717 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -221,19 +221,6 @@ static inline int gpio_to_irq(unsigned gpio)
return -EINVAL;
 }
 
-static inline int gpiochip_lock_as_irq(struct gpio_chip *chip,
-  unsigned int offset)
-{
-   WARN_ON(1);
-   return -EINVAL;
-}
-
-static inline void gpiochip_unlock_as_irq(struct gpio_chip *chip,
- unsigned int offset)
-{
-   WARN_ON(1);
-}
-
 static inline int irq_to_gpio(unsigned irq)
 {
/* irq can never have been returned from gpio_to_irq() */
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 4d2d7b7..1778106 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -490,9 +490,6 @@ extern int devm_gpiochip_add_data(struct device *dev, 
struct gpio_chip *chip,
 extern struct gpio_chip *gpiochip_find(void *data,
  int (*match)(struct gpio_chip *chip, void *data));
 
-/* lock/unlock as IRQ */
-int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
-void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
 bool gpiochip_line_is_irq(struct gpio_chip *chip, unsigned int offset);
 int gpiochip_reqres_irq(struct gpio_chip *chip, unsigned int offset);
 void gpiochip_relres_irq(struct gpio_chip *chip, unsigned int offset);
@@ -710,6 +707,10 @@ void devprop_gpiochip_set_names(struct gpio_chip *chip,
 
 struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc);
 
+/* lock/unlock as IRQ */
+int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
+void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
+
 #else /* CONFIG_GPIOLIB */
 
 static inline struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc)
@@ -719,6 +720,18 @@ static inline struct gpio_chip *gpiod_to_chip(const struct 
gpio_desc *desc)
return ERR_PTR(-ENODEV);
 }
 
+static inline int gpiochip_lock_as_irq(struct gpio_chip *chip,
+  unsigned int offset)
+{
+   WARN_ON(1);
+   return -EINVAL;
+}
+
+static inline void gpiochip_unlock_as_irq(struct gpio_chip *chip,
+ unsigned int offset)
+{
+   WARN_ON(1);
+}
 #endif /* CONFIG_GPIOLIB */
 
 #endif /* __LINUX_GPIO_DRIVER_H */
-- 
2.7.4

Re: [PATCH v3 3/3] tools: hv: add vmbus testing tool

[Branden Bonaby]

On Thu, Aug 22, 2019 at 01:36:09AM +, Harry Zhang wrote:
> Tool function issues:  Please validate args errors for  '-p' and '--path',  
> in or following validate_args_path().  
> 
> Comments of functionality:
> - it's confusing when fuzz_testing are all OFF, then user run ' python3 
> /home/lisa/vmbus_testing -p 
> /sys/kernel/debug/hyperv/000d3a6e-4548-000d-3a6e-4548000d3a6e delay -d 0 0 -D 
> ' which will enable all delay testing state ('Y' in state files).  even I 
> used "-D", "--dis_all" param. 
> - if we have subparsers of "disable-all" for the testing tool, then 
> probably we don't need the mutually_exclusive_group under subparsers of 
> "delay"
> - the path argument (-p) could be an argument for subparsers of "delay" 
> and "view" only.
> 
> Regards,
> Harry
>

So I made the choice to keep disabling the state and disabling delay
testing seperate, because once we start adding other testing options
you wouldn't want to inadvertently disable all testing especially
if you were doing more than one type of test at a time.
So with your configuration

'python3 /home/lisa/vmbus_testing -p 
/sys/kernel/debug/hyperv/000d3a6e-4548-000d-3a6e-4548000d3a6e delay -d 0 0 -D '

this would stop all delay testing on all the devices but wouldn't change
their test state to OFF 'N'.So thats why I have the option -s --state to
change the state to Off with a -s 0. Then to disable all types of testing
and change the state to OFF thats where the 'disable-all' subparser  comes in.
with:

'python3 /home/lisa/vmbus_testing disable-all

For that last point I don't understand what you mean, are you saying it would be
better to have something like this using  delay as an example?

'python3 /home/lisa/vmbus_testing delay -p 
/sys/kernel/debug/hyperv/000d3a6e-4548-000d-3a6e-4548000d3a6e'

If thats what you mean I figured it was better to make the -p accessible
to all test type so I made it apart of the main parser. This would allow
us to just have it there once instead of having to make a -p for every
subparser.

Also maybe I need to change the examples and the help text
because with the -D option for delay you wouldnt actually need to put in 
the path. As

'python3 /home/lisa/vmbus_testing delay -d 0 0 -D '

would suffice to stop delay testing on all devices; -E would enable
it for all devices and change the state to On 'Y' if it wasn't already.

let me know your thoughts

branden bonaby

RE: [tip:timers/core 34/34] drivers//clocksource/hyperv_timer.c:264:35: error: 'hv_sched_clock_offset' undeclared; did you mean 'sched_clock_register'?

[Tianyu Lan]

Thanks for reporting. I will send out fix patch.

-Original Message-
From: kbuild test robot  
Sent: Thursday, August 22, 2019 10:25 AM
To: Tianyu Lan 
Cc: kbuild-...@01.org; linux-kernel@vger.kernel.org; tipbu...@zytor.com; Thomas 
Gleixner ; Michael Kelley 
Subject: [tip:timers/core 34/34] drivers//clocksource/hyperv_timer.c:264:35: 
error: 'hv_sched_clock_offset' undeclared; did you mean 'sched_clock_register'?

tree:   
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkernel.googlesource.com%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftip%2Ftip.git&data=02%7C01%7CTianyu.Lan%40microsoft.com%7Cfa01680d45d1424cbbc308d726a82122%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637020378361213701&sdata=56fY4vgmkc4Nk3ZqCZhRyaA%2BmfKSd%2Fp9eYXZUahw5uo%3D&reserved=0
 timers/core
head:   b74e1d61dbc614ff35ef3ad9267c61ed06b09051
commit: b74e1d61dbc614ff35ef3ad9267c61ed06b09051 [34/34] clocksource/hyperv: 
Add Hyper-V specific sched clock function
config: i386-randconfig-g002-201933 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
git checkout b74e1d61dbc614ff35ef3ad9267c61ed06b09051
# save the attached .config to linux build tree
make ARCH=i386 

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

All error/warnings (new ones prefixed by >>):

   drivers//clocksource/hyperv_timer.c: In function 'read_hv_sched_clock_msr':
>> drivers//clocksource/hyperv_timer.c:264:35: error: 'hv_sched_clock_offset' 
>> undeclared (first use in this function); did you mean 'sched_clock_register'?
 return read_hv_clock_msr(NULL) - hv_sched_clock_offset;
  ^
  sched_clock_register
   drivers//clocksource/hyperv_timer.c:264:35: note: each undeclared identifier 
is reported only once for each function it appears in
   drivers//clocksource/hyperv_timer.c: In function 'hv_init_clocksource':
   drivers//clocksource/hyperv_timer.c:334:2: error: 'hv_sched_clock_offset' 
undeclared (first use in this function); did you mean 'sched_clock_register'?
 hv_sched_clock_offset = hyperv_cs->read(hyperv_cs);
 ^
 sched_clock_register
   drivers//clocksource/hyperv_timer.c: In function 'read_hv_sched_clock_msr':
>> drivers//clocksource/hyperv_timer.c:265:1: warning: control reaches end of 
>> non-void function [-Wreturn-type]
}
^

vim +264 drivers//clocksource/hyperv_timer.c

   261  
   262  static u64 read_hv_sched_clock_msr(void)
   263  {
 > 264  return read_hv_clock_msr(NULL) - hv_sched_clock_offset;
 > 265  }
   266  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org%2Fpipermail%2Fkbuild-all&data=02%7C01%7CTianyu.Lan%40microsoft.com%7Cfa01680d45d1424cbbc308d726a82122%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637020378361213701&sdata=bmZV%2B2uKHUlwngubxhE2bZlfOqCRNYVDCXOs%2FWcy3f8%3D&reserved=0
   Intel Corporation

Re: [PATCH V6 2/2] genirq/affinity: Spread vectors on node according to nr_cpu ratio

[Ming Lei]

On Mon, Aug 19, 2019 at 04:02:21PM +0200, Thomas Gleixner wrote:
> On Mon, 19 Aug 2019, Ming Lei wrote:
> > On Mon, Aug 19, 2019 at 03:13:58PM +0200, Thomas Gleixner wrote:
> > > On Mon, 19 Aug 2019, Ming Lei wrote:
> > > 
> > > > Cc: Jon Derrick 
> > > > Cc: Jens Axboe 
> > > > Reported-by: Jon Derrick 
> > > > Reviewed-by: Jon Derrick 
> > > > Reviewed-by: Keith Busch 
> > > 
> > > This version is sufficiently different from the previous one, so I do not
> > > consider the reviewed-by tags still being valid and meaningful. Don't
> > > include them unless you just do cosmetic changes.
> > 
> > Fine.
> > 
> > However, the V6 only change isn't big, just for addressing the 
> > un-initialized
> > warning, and the change is only done on function of 
> > irq_build_affinity_masks().
> 
> They are not trivial either:
> 
>  affinity.c |   28 +---
>  1 file changed, 13 insertions(+), 15 deletions(-)
> 
> --- a/kernel/irq/affinity.c
> +++ b/kernel/irq/affinity.c
> @@ -339,7 +339,7 @@ static int irq_build_affinity_masks(unsi
>   unsigned int firstvec,
>   struct irq_affinity_desc *masks)
>  {
> - unsigned int curvec = startvec, nr_present, nr_others;
> + unsigned int curvec = startvec, nr_present = 0, nr_others = 0;
>   cpumask_var_t *node_to_cpumask;
>   cpumask_var_t nmsk, npresmsk;
>   int ret = -ENOMEM;
> @@ -354,19 +354,17 @@ static int irq_build_affinity_masks(unsi
>   if (!node_to_cpumask)
>   goto fail_npresmsk;
>  
> - ret = 0;
>   /* Stabilize the cpumasks */
>   get_online_cpus();
>   build_node_to_cpumask(node_to_cpumask);
>  
>   /* Spread on present CPUs starting from affd->pre_vectors */
> - nr_present = __irq_build_affinity_masks(curvec, numvecs,
> - firstvec, node_to_cpumask,
> - cpu_present_mask, nmsk, masks);
> - if (nr_present < 0) {
> - ret = nr_present;
> + ret = __irq_build_affinity_masks(curvec, numvecs, firstvec,
> +  node_to_cpumask, cpu_present_mask,
> +  nmsk, masks);
> + if (ret < 0)
>   goto fail_build_affinity;
> - }
> + nr_present = ret;
>  
>   /*
>* Spread on non present CPUs starting from the next vector to be
> @@ -379,16 +377,16 @@ static int irq_build_affinity_masks(unsi
>   else
>   curvec = firstvec + nr_present;
>   cpumask_andnot(npresmsk, cpu_possible_mask, cpu_present_mask);
> - nr_others = __irq_build_affinity_masks(curvec, numvecs,
> -firstvec, node_to_cpumask,
> -npresmsk, nmsk, masks);
> - if (nr_others < 0)
> - ret = nr_others;
> + ret = __irq_build_affinity_masks(curvec, numvecs, firstvec,
> +  node_to_cpumask, npresmsk, nmsk,
> +  masks);
> + if (ret >= 0)
> + nr_others = ret;
>  
>   fail_build_affinity:
>   put_online_cpus();
>  
> - if (min(nr_present, nr_others) >= 0)
> + if (ret >= 0)
>   WARN_ON(nr_present + nr_others < numvecs);
>  
>   free_node_to_cpumask(node_to_cpumask);
> @@ -398,7 +396,7 @@ static int irq_build_affinity_masks(unsi
>  
>   fail_nmsk:
>   free_cpumask_var(nmsk);
> - return ret;
> + return ret < 0 ? ret : 0;
>  }
>  
>  static void default_calc_sets(struct irq_affinity *affd, unsigned int 
> affvecs)

Hi Keith & Jon,

Could you review the above V6 extra change so that we can move on?

BTW, in-balanced numa nodes can be made easily via passing 'possible_cpus=N'.


Thanks, 
Ming

Re: BUG: MAX_STACK_TRACE_ENTRIES too low in tipc_topsrv_exit_net

[Eric Biggers]

On Mon, Aug 19, 2019 at 05:22:07AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:5181b473 net: phy: realtek: add NBase-T PHY auto-detection
> git tree:   net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=156b731c60
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d4cf1ffb87d590d7
> dashboard link: https://syzkaller.appspot.com/bug?extid=5f97459a05652f579f6c
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> 
> Unfortunately, I don't have any reproducer for this crash yet.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+5f97459a05652f579...@syzkaller.appspotmail.com
> 
> BUG: MAX_STACK_TRACE_ENTRIES too low!
> turning off the locking correctness validator.
> CPU: 0 PID: 2581 Comm: kworker/u4:4 Not tainted 5.3.0-rc3+ #132
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: netns cleanup_net
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x172/0x1f0 lib/dump_stack.c:113
>  save_trace kernel/locking/lockdep.c:473 [inline]
>  save_trace.isra.0.cold+0x14/0x19 kernel/locking/lockdep.c:458
>  mark_lock+0x3db/0x11e0 kernel/locking/lockdep.c:3583
>  mark_usage kernel/locking/lockdep.c:3517 [inline]
>  __lock_acquire+0x538/0x4c30 kernel/locking/lockdep.c:3834
>  lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4412
>  flush_workqueue+0x126/0x14b0 kernel/workqueue.c:2774
>  drain_workqueue+0x1b4/0x470 kernel/workqueue.c:2939
>  destroy_workqueue+0x21/0x6c0 kernel/workqueue.c:4320
>  tipc_topsrv_work_stop net/tipc/topsrv.c:636 [inline]
>  tipc_topsrv_stop net/tipc/topsrv.c:694 [inline]
>  tipc_topsrv_exit_net+0x3fe/0x5d8 net/tipc/topsrv.c:706
>  ops_exit_list.isra.0+0xaa/0x150 net/core/net_namespace.c:172
>  cleanup_net+0x4e2/0xa70 net/core/net_namespace.c:594
>  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
> kobject: 'rx-0' (0e2c91cd): kobject_cleanup, parent 2003fefb
> kobject: 'rx-0' (0e2c91cd): auto cleanup 'remove' event
> kobject: 'rx-0' (0e2c91cd): kobject_uevent_env
> kobject: 'rx-0' (0e2c91cd): kobject_uevent_env: uevent_suppress
> caused the event to drop!
> kobject: 'rx-0' (0e2c91cd): auto cleanup kobject_del
> kobject: 'rx-0' (0e2c91cd): calling ktype release
> kobject: 'rx-0': free name
> kobject: 'tx-0' (58b6f726): kobject_cleanup, parent 2003fefb
> kobject: 'tx-0' (58b6f726): auto cleanup 'remove' event
> kobject: 'tx-0' (58b6f726): kobject_uevent_env
> kobject: 'tx-0' (58b6f726): kobject_uevent_env: uevent_suppress
> caused the event to drop!
> kobject: 'tx-0' (58b6f726): auto cleanup kobject_del
> kobject: 'tx-0' (58b6f726): calling ktype release
> kobject: 'tx-0': free name
> kobject: 'queues' (2003fefb): kobject_cleanup, parent
> 9c061a32
> kobject: 'queues' (2003fefb): calling ktype release
> kobject: 'queues' (2003fefb): kset_release
> kobject: 'queues': free name
> kobject: 'ip6gre0' (18a24d65): kobject_uevent_env
> kobject: 'ip6gre0' (18a24d65): kobject_uevent_env: uevent_suppress
> caused the event to drop!
> kobject: 'rx-0' (940b22b0): kobject_cleanup, parent 05a1fc3a
> kobject: 'rx-0' (940b22b0): auto cleanup 'remove' event
> kobject: 'rx-0' (940b22b0): kobject_uevent_env
> kobject: 'rx-0' (940b22b0): kobject_uevent_env: uevent_suppress
> caused the event to drop!
> kobject: 'rx-0' (940b22b0): auto cleanup kobject_del
> kobject: 'rx-0' (940b22b0): calling ktype release
> kobject: 'rx-0': free name
> kobject: 'tx-0' (278e85e2): kobject_cleanup, parent 05a1fc3a
> kobject: 'tx-0' (278e85e2): auto cleanup 'remove' event
> kobject: 'tx-0' (278e85e2): kobject_uevent_env
> kobject: 'tx-0' (278e85e2): kobject_uevent_env: uevent_suppress
> caused the event to drop!
> kobject: 'tx-0' (278e85e2): auto cleanup kobject_del
> kobject: 'tx-0' (278e85e2): calling ktype release
> kobject: 'tx-0': free name
> kobject: 'queues' (05a1fc3a): kobject_cleanup, parent
> 9c061a32
> kobject: 'queues' (05a1fc3a): calling ktype release
> kobject: 'queues' (05a1fc3a): kset_release
> kobject: 'queues': free name
> kobject: 'ip6gre0' (c78b955b): kobject_uevent_env
> kobject: 'ip6gre0' (c78b955b): kobject_uevent_env: uevent_suppress
> caused the event to drop!
> kobject: 'rx-0' (0fa7c1d1): kobject_cleanup, parent d264d5b4
> kobject: 'rx-0' (0fa7c1d1): auto cleanup 'remove' event
> kobject: 'rx-0' (0fa7c1d1): kobject_uevent_env
> kobject: 'rx-0' (0fa7c1d1): kobject_uevent_env: uevent_supp

[PATCH V2] csky: Fixup 610 vipt cache flush mechanism

[guoren]

From: Guo Ren 

610 has vipt aliasing issue, so we need to finish the cache flush
apis mentioned in cachetlb.rst to avoid data corruption.

Here is the list of modified apis in the patch:

 - flush_kernel_dcache_page  (new add)
 - flush_dcache_mmap_lock(new add)
 - flush_dcache_mmap_unlock  (new add)
 - flush_kernel_vmap_range   (new add)
 - invalidate_kernel_vmap_range  (new add)
 - flush_anon_page   (new add)
 - flush_cache_range (new add)
 - flush_cache_vmap  (flush all)
 - flush_cache_vunmap(flush all)
 - flush_cache_mm(only dcache flush)
 - flush_icache_page (just nop)
 - copy_from_user_page   (remove no need flush)
 - copy_to_user_page (remove no need flush)

Change to V2:
 - Fixup compile error with xa_lock*(&mapping->i_pages)

Signed-off-by: Guo Ren 
Cc: Arnd Bergmann 
Cc: Christoph Hellwig 
---
 arch/csky/abiv1/cacheflush.c | 20 ++
 arch/csky/abiv1/inc/abi/cacheflush.h | 41 +---
 2 files changed, 49 insertions(+), 12 deletions(-)

diff --git a/arch/csky/abiv1/cacheflush.c b/arch/csky/abiv1/cacheflush.c
index fee99fc..9f1fe80 100644
--- a/arch/csky/abiv1/cacheflush.c
+++ b/arch/csky/abiv1/cacheflush.c
@@ -54,3 +54,23 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned 
long addr,
icache_inv_all();
}
 }
+
+void flush_kernel_dcache_page(struct page *page)
+{
+   struct address_space *mapping;
+
+   mapping = page_mapping_file(page);
+
+   if (!mapping || mapping_mapped(mapping))
+   dcache_wbinv_all();
+}
+EXPORT_SYMBOL(flush_kernel_dcache_page);
+
+void flush_cache_range(struct vm_area_struct *vma, unsigned long start,
+   unsigned long end)
+{
+   dcache_wbinv_all();
+
+   if (vma->vm_flags & VM_EXEC)
+   icache_inv_all();
+}
diff --git a/arch/csky/abiv1/inc/abi/cacheflush.h 
b/arch/csky/abiv1/inc/abi/cacheflush.h
index fce5604..79ef9e8 100644
--- a/arch/csky/abiv1/inc/abi/cacheflush.h
+++ b/arch/csky/abiv1/inc/abi/cacheflush.h
@@ -4,26 +4,49 @@
 #ifndef __ABI_CSKY_CACHEFLUSH_H
 #define __ABI_CSKY_CACHEFLUSH_H
 
-#include 
+#include 
 #include 
 #include 
 
 #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
 extern void flush_dcache_page(struct page *);
 
-#define flush_cache_mm(mm) cache_wbinv_all()
+#define flush_cache_mm(mm) dcache_wbinv_all()
 #define flush_cache_page(vma, page, pfn)   cache_wbinv_all()
 #define flush_cache_dup_mm(mm) cache_wbinv_all()
 
+#define ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE
+extern void flush_kernel_dcache_page(struct page *);
+
+#define flush_dcache_mmap_lock(mapping)
xa_lock_irq(&mapping->i_pages)
+#define flush_dcache_mmap_unlock(mapping)  xa_unlock_irq(&mapping->i_pages)
+
+static inline void flush_kernel_vmap_range(void *addr, int size)
+{
+   dcache_wbinv_all();
+}
+static inline void invalidate_kernel_vmap_range(void *addr, int size)
+{
+   dcache_wbinv_all();
+}
+
+#define ARCH_HAS_FLUSH_ANON_PAGE
+static inline void flush_anon_page(struct vm_area_struct *vma,
+struct page *page, unsigned long vmaddr)
+{
+   if (PageAnon(page))
+   cache_wbinv_all();
+}
+
 /*
  * if (current_mm != vma->mm) cache_wbinv_range(start, end) will be broken.
  * Use cache_wbinv_all() here and need to be improved in future.
  */
-#define flush_cache_range(vma, start, end) cache_wbinv_all()
-#define flush_cache_vmap(start, end)   cache_wbinv_range(start, end)
-#define flush_cache_vunmap(start, end) cache_wbinv_range(start, end)
+extern void flush_cache_range(struct vm_area_struct *vma, unsigned long start, 
unsigned long end);
+#define flush_cache_vmap(start, end)   cache_wbinv_all()
+#define flush_cache_vunmap(start, end) cache_wbinv_all()
 
-#define flush_icache_page(vma, page)   cache_wbinv_all()
+#define flush_icache_page(vma, page)   do {} while (0);
 #define flush_icache_range(start, end) cache_wbinv_range(start, end)
 
 #define flush_icache_user_range(vma,page,addr,len) \
@@ -31,19 +54,13 @@ extern void flush_dcache_page(struct page *);
 
 #define copy_from_user_page(vma, page, vaddr, dst, src, len) \
 do { \
-   cache_wbinv_all(); \
memcpy(dst, src, len); \
-   cache_wbinv_all(); \
 } while (0)
 
 #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
 do { \
-   cache_wbinv_all(); \
memcpy(dst, src, len); \
cache_wbinv_all(); \
 } while (0)
 
-#define flush_dcache_mmap_lock(mapping)do {} while (0)
-#define flush_dcache_mmap_unlock(mapping)  do {} while (0)
-
 #endif /* __ABI_CSKY_CACHEFLUSH_H */
-- 
2.7.4

Re: [PATCH] rcu: don't include in rcutiny.h

[Paul E. McKenney]

On Thu, Aug 22, 2019 at 10:53:43AM +0900, Christoph Hellwig wrote:
> The kbuild reported a built failure due to a header loop when RCUTINY is
> enabled with my pending riscv-nommu port.  Switch rcutiny.h to only
> include the minimal required header to get HZ instead.
> 
> Signed-off-by: Christoph Hellwig 

Queued for review and testing, thank you!

Do you need this in v5.4?  My normal workflow would put it into v5.5.

Thanx, Paul

> ---
>  include/linux/rcutiny.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> index 8e727f57d814..9bf1dfe7781f 100644
> --- a/include/linux/rcutiny.h
> +++ b/include/linux/rcutiny.h
> @@ -12,7 +12,7 @@
>  #ifndef __LINUX_TINY_H
>  #define __LINUX_TINY_H
>  
> -#include 
> +#include  /* for HZ */
>  
>  /* Never flag non-existent other CPUs! */
>  static inline bool rcu_eqs_special_set(int cpu) { return false; }
> -- 
> 2.20.1
> 

[PATCH V4 1/4] dt-bindings: watchdog: Add i.MX7ULP bindings

[Anson Huang]

Add the watchdog bindings for Freescale i.MX7ULP.

Signed-off-by: Anson Huang 
---
No changes.
---
 .../bindings/watchdog/fsl-imx7ulp-wdt.txt  | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
new file mode 100644
index 000..d83fc5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
@@ -0,0 +1,22 @@
+* Freescale i.MX7ULP Watchdog Timer (WDT) Controller
+
+Required properties:
+- compatible : Should be "fsl,imx7ulp-wdt"
+- reg : Should contain WDT registers location and length
+- interrupts : Should contain WDT interrupt
+- clocks: Should contain a phandle pointing to the gated peripheral clock.
+
+Optional properties:
+- timeout-sec : Contains the watchdog timeout in seconds
+
+Examples:
+
+wdog1: wdog@403d {
+   compatible = "fsl,imx7ulp-wdt";
+   reg = <0x403d 0x1>;
+   interrupts = ;
+   clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+   assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+   assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
+   timeout-sec = <40>;
+};
-- 
2.7.4

[PATCH V4 2/4] watchdog: Add i.MX7ULP watchdog support

[Anson Huang]

The i.MX7ULP Watchdog Timer (WDOG) module is an independent timer
that is available for system use.
It provides a safety feature to ensure that software is executing
as planned and that the CPU is not stuck in an infinite loop or
executing unintended code. If the WDOG module is not serviced
(refreshed) within a certain period, it resets the MCU.

Add driver support for i.MX7ULP watchdog.

Signed-off-by: Anson Huang 
---
Changes since V3:
- pass clk directly for reset action to avoid dereference from 
structure;
- use constant instead of variable for wdog clock rate, as it is fixed 
as 1KHz.
---
 drivers/watchdog/Kconfig   |  13 +++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/imx7ulp_wdt.c | 243 +
 3 files changed, 257 insertions(+)
 create mode 100644 drivers/watchdog/imx7ulp_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index a8f5c81..d68e5b5 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -724,6 +724,19 @@ config IMX_SC_WDT
  To compile this driver as a module, choose M here: the
  module will be called imx_sc_wdt.
 
+config IMX7ULP_WDT
+   tristate "IMX7ULP Watchdog"
+   depends on ARCH_MXC || COMPILE_TEST
+   select WATCHDOG_CORE
+   help
+ This is the driver for the hardware watchdog on the Freescale
+ IMX7ULP and later processors. If you have one of these
+ processors and wish to have watchdog support enabled,
+ say Y, otherwise say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx7ulp_wdt.
+
 config UX500_WATCHDOG
tristate "ST-Ericsson Ux500 watchdog"
depends on MFD_DB8500_PRCMU
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index b5a0aed..2ee352b 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
 obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
 obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
 obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o
+obj-$(CONFIG_IMX7ULP_WDT) += imx7ulp_wdt.o
 obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
 obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
 obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
diff --git a/drivers/watchdog/imx7ulp_wdt.c b/drivers/watchdog/imx7ulp_wdt.c
new file mode 100644
index 000..5ce5102
--- /dev/null
+++ b/drivers/watchdog/imx7ulp_wdt.c
@@ -0,0 +1,243 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WDOG_CS0x0
+#define WDOG_CS_CMD32ENBIT(13)
+#define WDOG_CS_ULKBIT(11)
+#define WDOG_CS_RCSBIT(10)
+#define WDOG_CS_EN BIT(7)
+#define WDOG_CS_UPDATE BIT(5)
+
+#define WDOG_CNT   0x4
+#define WDOG_TOVAL 0x8
+
+#define REFRESH_SEQ0   0xA602
+#define REFRESH_SEQ1   0xB480
+#define REFRESH((REFRESH_SEQ1 << 16) | REFRESH_SEQ0)
+
+#define UNLOCK_SEQ00xC520
+#define UNLOCK_SEQ10xD928
+#define UNLOCK ((UNLOCK_SEQ1 << 16) | UNLOCK_SEQ0)
+
+#define DEFAULT_TIMEOUT60
+#define MAX_TIMEOUT128
+#define WDOG_CLOCK_RATE1000
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, );
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct imx7ulp_wdt_device {
+   struct notifier_block restart_handler;
+   struct watchdog_device wdd;
+   void __iomem *base;
+   struct clk *clk;
+};
+
+static inline void imx7ulp_wdt_enable(void __iomem *base, bool enable)
+{
+   u32 val = readl(base + WDOG_CS);
+
+   writel(UNLOCK, base + WDOG_CNT);
+   if (enable)
+   writel(val | WDOG_CS_EN, base + WDOG_CS);
+   else
+   writel(val & ~WDOG_CS_EN, base + WDOG_CS);
+}
+
+static inline bool imx7ulp_wdt_is_enabled(void __iomem *base)
+{
+   u32 val = readl(base + WDOG_CS);
+
+   return val & WDOG_CS_EN;
+}
+
+static int imx7ulp_wdt_ping(struct watchdog_device *wdog)
+{
+   struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+
+   writel(REFRESH, wdt->base + WDOG_CNT);
+
+   return 0;
+}
+
+static int imx7ulp_wdt_start(struct watchdog_device *wdog)
+{
+   struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+
+   imx7ulp_wdt_enable(wdt->base, true);
+
+   return 0;
+}
+
+static int imx7ulp_wdt_stop(struct watchdog_device *wdog)
+{
+   struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+
+   imx7ulp_wdt_enable(wdt->base, false);
+
+   return 0;
+}
+
+static int imx7ulp_wdt_set_timeout(struct watchdog_device *wdog,
+  unsigned int timeout)
+{
+   struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+  

[PATCH V4 4/4] ARM: dts: imx7ulp: Add wdog1 node

[Anson Huang]

Add wdog1 node to support watchdog driver.

Signed-off-by: Anson Huang 
---
No changes.
---
 arch/arm/boot/dts/imx7ulp.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index 6859a3a..1fdb5a35 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -264,6 +264,16 @@
#clock-cells = <1>;
};
 
+   wdog1: wdog@403d {
+   compatible = "fsl,imx7ulp-wdt";
+   reg = <0x403d 0x1>;
+   interrupts = ;
+   clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+   assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+   assigned-clocks-parents = <&scg1 
IMX7ULP_CLK_FIRC_BUS_CLK>;
+   timeout-sec = <40>;
+   };
+
pcc2: clock-controller@403f {
compatible = "fsl,imx7ulp-pcc2";
reg = <0x403f 0x1>;
-- 
2.7.4

[PATCH V4 3/4] ARM: imx_v6_v7_defconfig: Enable CONFIG_IMX7ULP_WDT by default

[Anson Huang]

Select CONFIG_IMX7ULP_WDT by default to support i.MX7ULP watchdog.

Signed-off-by: Anson Huang 
---
No changes.
---
 arch/arm/configs/imx_v6_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index 9bfffbe..be2a694 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -236,6 +236,7 @@ CONFIG_DA9062_WATCHDOG=y
 CONFIG_DA9063_WATCHDOG=m
 CONFIG_RN5T618_WATCHDOG=y
 CONFIG_IMX2_WDT=y
+CONFIG_IMX7ULP_WDT=y
 CONFIG_MFD_DA9052_I2C=y
 CONFIG_MFD_DA9062=y
 CONFIG_MFD_DA9063=y
-- 
2.7.4

RE: [PATCH V3 2/4] watchdog: Add i.MX7ULP watchdog support

[Anson Huang]

Hi, Guenter

> On Tue, Aug 20, 2019 at 10:07:56PM -0400, Anson Huang wrote:
> > The i.MX7ULP Watchdog Timer (WDOG) module is an independent timer
> that
> > is available for system use.
> > It provides a safety feature to ensure that software is executing as
> > planned and that the CPU is not stuck in an infinite loop or executing
> > unintended code. If the WDOG module is not serviced
> > (refreshed) within a certain period, it resets the MCU.
> >
> > Add driver support for i.MX7ULP watchdog.
> >
> > Signed-off-by: Anson Huang 
> > ---
> > Changes since V2:
> > - add devm_add_action_or_reset to disable clk for remove action.
> > ---
> >  drivers/watchdog/Kconfig   |  13 +++
> >  drivers/watchdog/Makefile  |   1 +
> >  drivers/watchdog/imx7ulp_wdt.c | 246
> > +
> >  3 files changed, 260 insertions(+)
> >  create mode 100644 drivers/watchdog/imx7ulp_wdt.c
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index
> > a8f5c81..d68e5b5 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -724,6 +724,19 @@ config IMX_SC_WDT
> >   To compile this driver as a module, choose M here: the
> >   module will be called imx_sc_wdt.
> >
> > +config IMX7ULP_WDT
> > +   tristate "IMX7ULP Watchdog"
> > +   depends on ARCH_MXC || COMPILE_TEST
> > +   select WATCHDOG_CORE
> > +   help
> > + This is the driver for the hardware watchdog on the Freescale
> > + IMX7ULP and later processors. If you have one of these
> > + processors and wish to have watchdog support enabled,
> > + say Y, otherwise say N.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called imx7ulp_wdt.
> > +
> >  config UX500_WATCHDOG
> > tristate "ST-Ericsson Ux500 watchdog"
> > depends on MFD_DB8500_PRCMU
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index b5a0aed..2ee352b 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -67,6 +67,7 @@ obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
> >  obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
> >  obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
> >  obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o
> > +obj-$(CONFIG_IMX7ULP_WDT) += imx7ulp_wdt.o
> >  obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
> >  obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
> >  obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o diff --git
> > a/drivers/watchdog/imx7ulp_wdt.c b/drivers/watchdog/imx7ulp_wdt.c
> new
> > file mode 100644 index 000..5d37957
> > --- /dev/null
> > +++ b/drivers/watchdog/imx7ulp_wdt.c
> > @@ -0,0 +1,246 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright 2019 NXP.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define WDOG_CS0x0
> > +#define WDOG_CS_CMD32ENBIT(13)
> > +#define WDOG_CS_ULKBIT(11)
> > +#define WDOG_CS_RCSBIT(10)
> > +#define WDOG_CS_EN BIT(7)
> > +#define WDOG_CS_UPDATE BIT(5)
> > +
> > +#define WDOG_CNT   0x4
> > +#define WDOG_TOVAL 0x8
> > +
> > +#define REFRESH_SEQ0   0xA602
> > +#define REFRESH_SEQ1   0xB480
> > +#define REFRESH((REFRESH_SEQ1 << 16) | REFRESH_SEQ0)
> > +
> > +#define UNLOCK_SEQ00xC520
> > +#define UNLOCK_SEQ10xD928
> > +#define UNLOCK ((UNLOCK_SEQ1 << 16) | UNLOCK_SEQ0)
> > +
> > +#define DEFAULT_TIMEOUT60
> > +#define MAX_TIMEOUT128
> > +
> > +static bool nowayout = WATCHDOG_NOWAYOUT;
> module_param(nowayout,
> > +bool, ); MODULE_PARM_DESC(nowayout, "Watchdog cannot be
> stopped
> > +once started (default="
> > +__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> > +
> > +struct imx7ulp_wdt_device {
> > +   struct notifier_block restart_handler;
> > +   struct watchdog_device wdd;
> > +   void __iomem *base;
> > +   struct clk *clk;
> > +   int rate;
> > +};
> > +
> > +static inline void imx7ulp_wdt_enable(void __iomem *base, bool
> > +enable) {
> > +   u32 val = readl(base + WDOG_CS);
> > +
> > +   writel(UNLOCK, base + WDOG_CNT);
> > +   if (enable)
> > +   writel(val | WDOG_CS_EN, base + WDOG_CS);
> > +   else
> > +   writel(val & ~WDOG_CS_EN, base + WDOG_CS); }
> > +
> > +static inline bool imx7ulp_wdt_is_enabled(void __iomem *base) {
> > +   u32 val = readl(base + WDOG_CS);
> > +
> > +   return val & WDOG_CS_EN;
> > +}
> > +
> > +static int imx7ulp_wdt_ping(struct watchdog_device *wdog) {
> > +   struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
> > +
> > +   writel(REFRESH, wdt->base + WDOG_CNT);
> > +
> > +   return 0;
> > +}
> > +
> > +static int imx7ulp_wdt_start(struct watchdog_device *wdog) {
> > +   struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
> > +
> > +   imx7ulp_wdt_enable(wdt->base, true);
> > +
> > +   return 0;
> > +}
> > +
> > +stat