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

[David Howells]

Stephen Rothwell  wrote:

> After merging the fscache tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> fs/afs/file.c: In function 'afs_req_issue_op':
> fs/afs/file.c:291:6: warning: unused variable 'ret' [-Wunused-variable]
>   291 |  int ret;
>   |  ^~~
> 
> Introduced by commit
> 
>   799fbdf96cd5 ("afs: Use new fscache read helper API")

I've updated my branch to remove the variable.

David

Re: linux-next: build failure after merge of the powerpc-fixes tree

[Michael Ellerman]

Uwe Kleine-König  writes:
> Hello,
>
> On 3/2/21 3:09 AM, Michael Ellerman wrote:
>> Stephen Rothwell  writes:
>>> Hi all,
>>>
>>> After merging the powerpc-fixes tree, today's linux-next build (powerpc
>>> allyesconfig) failed like this:
>>>
>>> drivers/net/ethernet/ibm/ibmvnic.c:5399:13: error: conflicting types for 
>>> 'ibmvnic_remove'
>>>   5399 | static void ibmvnic_remove(struct vio_dev *dev)
>>>| ^~
>>> drivers/net/ethernet/ibm/ibmvnic.c:81:12: note: previous declaration of 
>>> 'ibmvnic_remove' was here
>>> 81 | static int ibmvnic_remove(struct vio_dev *);
>>>|^~
>>>
>>> Caused by commit
>>>
>>>1bdd1e6f9320 ("vio: make remove callback return void")
>> 
>> Gah, is IBMVNIC in any of our defconfigs?! ... no it's not.
>
> Would you accept a patch to add the driver to one of the defconfigs as 
> an excuse for the build breakage I created?

Thanks, but I already sent a patch adding it.

We should really have these drivers enabled in our defconfig, so that's
on us.

cheers

Re: linux-kernel janitorial RFP: Mark static arrays as const

[Bernd Petrovitsch]

Hi all!

On 02/03/2021 18:42, Joe Perches wrote:
[...]
> - For instance: (head -10 of the git grep for file statics)
> 
> drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 16, 
> 8, 4, 2, 1 };
> drivers/accessibility/speakup/keyhelp.c:26:static u_char funcvals[] = {
> drivers/accessibility/speakup/main.c:2059:static spkup_hand spkup_handler[] = 
> {
> drivers/accessibility/speakup/speakup_acntpc.c:35:static unsigned int 
> synth_portlist[] = { 0x2a8, 0 };
> drivers/accessibility/speakup/speakup_decpc.c:133:static int synth_portlist[] 
> = { 0x340, 0x350, 0x240, 0x250, 0 };
> drivers/accessibility/speakup/speakup_dectlk.c:110:static int ap_defaults[] = 
> {122, 89, 155, 110, 208, 240, 200, 106, 306};
> drivers/accessibility/speakup/speakup_dectlk.c:111:static int g5_defaults[] = 
> {86, 81, 86, 84, 81, 80, 83, 83, 73};
> drivers/accessibility/speakup/speakup_dtlk.c:34:static unsigned int 
> synth_portlist[] = {
> drivers/accessibility/speakup/speakup_keypc.c:34:static unsigned int 
> synth_portlist[] = { 0x2a8, 0 };
> drivers/acpi/ac.c:137:static enum power_supply_property ac_props[] = {
> 
> For drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 
> 16, 8, 4, 2, 1 };

Looking at the examples: Just s/^static /static const / in the lines
reported by the grep's above and see if it compiles (and save space)?

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 There is NO CLOUD, just other people's computers. - FSFE
 LUGA : http://www.luga.at

Re: [PATCH v1 0/3] driver core: Set fw_devlink=on take II

[Saravana Kannan]

On Tue, Mar 2, 2021 at 2:42 PM Saravana Kannan  wrote:
>
> On Tue, Mar 2, 2021 at 2:24 PM Michael Walle  wrote:
> >
> > Am 2021-03-02 22:11, schrieb Saravana Kannan:
> > > I think Patch 1 should fix [4] without [5]. Can you test the series
> > > please?
> >
> > Mh, I'm on latest linux-next (next-20210302) and I've applied patch 3/3
> > and
> > reverted commit 7007b745a508 ("PCI: layerscape: Convert to
> > builtin_platform_driver()"). I'd assumed that PCIe shouldn't be working,
> > right? But it is. Did I miss something?
>
> You need to revert [5].

My bad. You did revert it. Ah... I wonder if it was due to
fw_devlink.strict that I added. To break PCI again, also set
fw_devlink.strict=1 in the kernel command line.

-Saravana

[PATCH] v4l2-ctrls: Fix h264 hierarchical coding type menu ctrl

[Stanimir Varbanov]

Add a name of the menu and fill control type.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 016cf6204cbb..5d99e2294335 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -421,6 +421,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Annex B Start Code",
NULL,
};
+   static const char * const h264_hierarchical_coding_type[] = {
+   "Hier Coding B",
+   "Hier Coding P",
+   NULL,
+   };
static const char * const mpeg_mpeg2_level[] = {
"Low",
"Main",
@@ -697,6 +702,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return h264_decode_mode;
case V4L2_CID_STATELESS_H264_START_CODE:
return h264_start_code;
+   case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_TYPE:
+   return h264_hierarchical_coding_type;
case V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL:
return mpeg_mpeg2_level;
case V4L2_CID_MPEG_VIDEO_MPEG2_PROFILE:
@@ -1326,6 +1333,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC:
case V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE:
case V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE:
+   case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_TYPE:
case V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL:
case V4L2_CID_MPEG_VIDEO_MPEG2_PROFILE:
case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
-- 
2.25.1

[PATCH] bus: mhi: core: Remove pre_init flag used for power purposes

[Bhaumik Bhatt]

Some controllers can choose to skip preparation for power up.
In that case, device context is initialized based on the pre_init
flag not being set during mhi_prepare_for_power_up(). There is no
reason MHI host driver should maintain and provide controllers
with two separate paths for preparing MHI.

Going forward, all controllers will be required to call the
mhi_prepare_for_power_up() API followed by their choice of sync
or async power up. This allows MHI host driver to get rid of the
pre_init flag and sets up a common way for all controllers to use
MHI. This also helps controllers fail early on during preparation
phase in some failure cases.

Signed-off-by: Bhaumik Bhatt 
---
 drivers/bus/mhi/core/init.c |  3 ---
 drivers/bus/mhi/core/pm.c   | 20 
 include/linux/mhi.h |  2 --
 3 files changed, 25 deletions(-)

diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 33323ad..59ff832 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -1080,8 +1080,6 @@ int mhi_prepare_for_power_up(struct mhi_controller 
*mhi_cntrl)
mhi_rddm_prepare(mhi_cntrl, mhi_cntrl->rddm_image);
}
 
-   mhi_cntrl->pre_init = true;
-
mutex_unlock(_cntrl->pm_mutex);
 
return 0;
@@ -1112,7 +1110,6 @@ void mhi_unprepare_after_power_down(struct mhi_controller 
*mhi_cntrl)
}
 
mhi_deinit_dev_ctxt(mhi_cntrl);
-   mhi_cntrl->pre_init = false;
 }
 EXPORT_SYMBOL_GPL(mhi_unprepare_after_power_down);
 
diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
index 681960c..fa5454d 100644
--- a/drivers/bus/mhi/core/pm.c
+++ b/drivers/bus/mhi/core/pm.c
@@ -1033,13 +1033,6 @@ int mhi_async_power_up(struct mhi_controller *mhi_cntrl)
mutex_lock(_cntrl->pm_mutex);
mhi_cntrl->pm_state = MHI_PM_DISABLE;
 
-   if (!mhi_cntrl->pre_init) {
-   /* Setup device context */
-   ret = mhi_init_dev_ctxt(mhi_cntrl);
-   if (ret)
-   goto error_dev_ctxt;
-   }
-
ret = mhi_init_irq_setup(mhi_cntrl);
if (ret)
goto error_setup_irq;
@@ -1121,10 +1114,6 @@ int mhi_async_power_up(struct mhi_controller *mhi_cntrl)
mhi_deinit_free_irq(mhi_cntrl);
 
 error_setup_irq:
-   if (!mhi_cntrl->pre_init)
-   mhi_deinit_dev_ctxt(mhi_cntrl);
-
-error_dev_ctxt:
mutex_unlock(_cntrl->pm_mutex);
 
return ret;
@@ -1166,15 +1155,6 @@ void mhi_power_down(struct mhi_controller *mhi_cntrl, 
bool graceful)
flush_work(_cntrl->st_worker);
 
free_irq(mhi_cntrl->irq[0], mhi_cntrl);
-
-   if (!mhi_cntrl->pre_init) {
-   /* Free all allocated resources */
-   if (mhi_cntrl->fbc_image) {
-   mhi_free_bhie_table(mhi_cntrl, mhi_cntrl->fbc_image);
-   mhi_cntrl->fbc_image = NULL;
-   }
-   mhi_deinit_dev_ctxt(mhi_cntrl);
-   }
 }
 EXPORT_SYMBOL_GPL(mhi_power_down);
 
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index d26acc8..a401271 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -352,7 +352,6 @@ struct mhi_controller_config {
  * @index: Index of the MHI controller instance
  * @bounce_buf: Use of bounce buffer
  * @fbc_download: MHI host needs to do complete image transfer (optional)
- * @pre_init: MHI host needs to do pre-initialization before power up
  * @wake_set: Device wakeup set flag
  * @irq_flags: irq flags passed to request_irq (optional)
  *
@@ -445,7 +444,6 @@ struct mhi_controller {
int index;
bool bounce_buf;
bool fbc_download;
-   bool pre_init;
bool wake_set;
unsigned long irq_flags;
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v1 0/3] driver core: Set fw_devlink=on take II

[Saravana Kannan]

On Tue, Mar 2, 2021 at 2:24 PM Michael Walle  wrote:
>
> Am 2021-03-02 22:11, schrieb Saravana Kannan:
> > I think Patch 1 should fix [4] without [5]. Can you test the series
> > please?
>
> Mh, I'm on latest linux-next (next-20210302) and I've applied patch 3/3
> and
> reverted commit 7007b745a508 ("PCI: layerscape: Convert to
> builtin_platform_driver()"). I'd assumed that PCIe shouldn't be working,
> right? But it is. Did I miss something?

You need to revert [5].

-Saravana

>
> Anyway, I've also applied Patch 1/3 and 2/3 and it still works. But I
> guess that doesn't say much.
>
> -michael

Re: [PATCH 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as

[Nick Desaulniers]

On Tue, Mar 2, 2021 at 2:09 PM Nick Desaulniers  wrote:
>
> On Tue, Mar 2, 2021 at 2:02 PM Fangrui Song  wrote:
> >
> > On 2021-03-02, Nathan Chancellor wrote:
> > >When building with LLVM_IAS=1, there is no point to specifying
> > >'--prefix=' because that flag is only used to find the cross assembler,
> > >which is clang itself when building with LLVM_IAS=1. All of the other
> > >tools are invoked directly from PATH or a full path specified via the
> > >command line, which does not depend on the value of '--prefix='.
> > >
> > >Sharing commands to reproduce issues becomes a little bit easier without
> > >a '--prefix=' value because that '--prefix=' value is specific to a
> > >user's machine due to it being an absolute path.
> > >
> > >Signed-off-by: Nathan Chancellor 
> >
> > Reviewed-by: Fangrui Song 
> >
> > clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU
> > objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]).
>
> But -g get's set via CONFIG_DEBUG_INFO and -gsplit-dwarf by
> DEBUG_INFO_SPLIT.  So if we say:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang LLVM_IAS=1
>
> So cross compile, use clang, use the integrated assembler (ie. with
> this change, don't set --prefix), with either of the two above
> configs, which objcopy get's exec'd?

Ok, I spoke to Fangrui more offline, and probably misread his
response. From our chat:
```
Fangrui:
objcopy is only used for GNU as assembled object files
With integrated assembler, the object file streamer creates .o and
.dwo simultaneously
With GNU as, two objcopy commands are needed to extract .debug*.dwo to
.dwo files &&& another command to remove .debug*.dwo sections
```

Reviewed-by: Nick Desaulniers 
Tested-by: Nick Desaulniers 

I ran this series through a mix of LLVM=1 vs CC=clang, LLVM_IAS=1 vs
unset, CROSS_COMPILE vs not, without issue.

>
> >
> > With LLVM_IAS=1, these cases are ruled out.
>
>
>
> --
> Thanks,
> ~Nick Desaulniers



-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] gpio: regmap: move struct gpio_regmap definition

[Linus Walleij]

On Tue, Mar 2, 2021 at 7:14 PM Álvaro Fernández Rojas  wrote:

> I'm trying to add support for bcm63xx pin controllers, and Linus
> suggested that I could use gpio regmap instead of adding duplicated code.
> However, I need to access gpio_chip inside gpio_regmap to call
> pinctrl_add_gpio_range() with gpio_chip.base.

Can't you just put the ranges in the device tree using the standard
property gpio-ranges?

These will be added automatically after the chip is added.

It is documented in
Documentation/devicetree/bindings/gpio/gpio.txt
a bit down the file.

The code is in of_gpiochip_add_pin_range() in gpiolib-of.c
called from of_gpiochip_add() which is always called
when gpiochip_add_data_with_key(), the main gpiochip
registering function is called.

This would just do the work for you with no effort in the driver.

It is a bit counterintuitive that this can be done in the device
tree but the hierarchical IRQs cannot do the same clever
manouver to map IRQs, sorry.

Yours,
Linus Walleij

[PATCH] bus: mhi: core: Add missing checks for MMIO register entries

[Bhaumik Bhatt]

As per documentation, fields marked as (required) in an MHI
controller structure need to be populated by the controller driver
before calling mhi_register_controller(). Ensure all required
fields are present in the controller before proceeding with the
registration.

Signed-off-by: Bhaumik Bhatt 
---
 drivers/bus/mhi/core/init.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index aa575d3..33323ad 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -860,10 +860,10 @@ int mhi_register_controller(struct mhi_controller 
*mhi_cntrl,
u32 soc_info;
int ret, i;
 
-   if (!mhi_cntrl)
-   return -EINVAL;
-
-   if (!mhi_cntrl->runtime_get || !mhi_cntrl->runtime_put ||
+   if (!mhi_cntrl || !mhi_cntrl->cntrl_dev || !mhi_cntrl->regs ||
+   !mhi_cntrl->iova_start || !mhi_cntrl->iova_stop ||
+   !mhi_cntrl->fw_image || !mhi_cntrl->irq ||
+   !mhi_cntrl->runtime_get || !mhi_cntrl->runtime_put ||
!mhi_cntrl->status_cb || !mhi_cntrl->read_reg ||
!mhi_cntrl->write_reg || !mhi_cntrl->nr_irqs)
return -EINVAL;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/8] input: Documentation: corrections for event-codes.rst

[Randy Dunlap]

Fix hyphenation, typos, capitalization, and a referenced file name
(.txt -> .rst).

Signed-off-by: Randy Dunlap 
Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/input/event-codes.rst |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- linux-next-20210202.orig/Documentation/input/event-codes.rst
+++ linux-next-20210202/Documentation/input/event-codes.rst
@@ -246,9 +246,9 @@ A few EV_ABS codes have special meanings
 
  A device should set the resolution of the axis to indicate whether the
  pressure is in measurable units. If the resolution is zero, the
- pressure data is in arbitrary units. If the resolution is nonzero, the
+ pressure data is in arbitrary units. If the resolution is non-zero, the
  pressure data is in units/gram. For example, a value of 10 with a
- resolution of 1 represents 10 gram, a value of 10 with a resolution on
+ resolution of 1 represents 10 gram, a value of 10 with a resolution of
  1000 represents 10 microgram.
 
 EV_SW
@@ -344,7 +344,7 @@ INPUT_PROP_BUTTONPAD
 
 For touchpads where the button is placed beneath the surface, such that
 pressing down on the pad causes a button click, this property should be
-set. Common in clickpad notebooks and macbooks from 2009 and onwards.
+set. Common in Clickpad notebooks and Macbooks from 2009 and onwards.
 
 Originally, the buttonpad property was coded into the bcm5974 driver
 version field under the name integrated button. For backwards
@@ -356,7 +356,7 @@ INPUT_PROP_SEMI_MT
 Some touchpads, most common between 2008 and 2011, can detect the presence
 of multiple contacts without resolving the individual positions; only the
 number of contacts and a rectangular shape is known. For such
-touchpads, the semi-mt property should be set.
+touchpads, the SEMI_MT property should be set.
 
 Depending on the device, the rectangle may enclose all touches, like a
 bounding box, or just some of them, for instance the two most recent
@@ -394,7 +394,7 @@ Guidelines
 ==
 
 The guidelines below ensure proper single-touch and multi-finger functionality.
-For multi-touch functionality, see the multi-touch-protocol.txt document for
+For multi-touch functionality, see the multi-touch-protocol.rst document for
 more information.
 
 Mice

[PATCH 1/8] input: Documentation: corrections for input.rst

[Randy Dunlap]

Fix grammar, punctuation, and spelling.

Signed-off-by: Randy Dunlap 
Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/input/input.rst |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- linux-next-20210202.orig/Documentation/input/input.rst
+++ linux-next-20210202/Documentation/input/input.rst
@@ -9,7 +9,7 @@ Introduction
 Architecture
 
 
-Input subsystem  a collection of drivers that is designed to support
+Input subsystem is a collection of drivers that is designed to support
 all input devices under Linux. Most of the drivers reside in
 drivers/input, although quite a few live in drivers/hid and
 drivers/platform.
@@ -50,7 +50,7 @@ will be available as a character device
 
crw-r--r--   1 root root  13,  63 Mar 28 22:45 mice
 
-This device usually created automatically by the system. The commands
+This device is usually created automatically by the system. The commands
 to create it by hand are::
 
cd /dev
@@ -180,7 +180,7 @@ whole suite. It handles all HID devices,
 wide variety of them, and because the USB HID specification isn't
 simple, it needs to be this big.
 
-Currently, it handles USB mice, joysticks, gamepads, steering wheels
+Currently, it handles USB mice, joysticks, gamepads, steering wheels,
 keyboards, trackballs and digitizers.
 
 However, USB uses HID also for monitor controls, speaker controls, UPSs,
@@ -268,7 +268,7 @@ events on a read. Their layout is::
 };
 
 ``time`` is the timestamp, it returns the time at which the event happened.
-Type is for example EV_REL for relative moment, EV_KEY for a keypress or
+Type is for example EV_REL for relative movement, EV_KEY for a keypress or
 release. More types are defined in include/uapi/linux/input-event-codes.h.
 
 ``code`` is event code, for example REL_X or KEY_BACKSPACE, again a complete

[PATCH 3/8 RESEND] input: Documentation: update related file names in ff.rst

[Randy Dunlap]

Change other related documentation file names from .txt to .rst
and be more explicit about their paths/locations.

Signed-off-by: Randy Dunlap 
Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Cc: Johann Deneux 
Cc: Anssi Hannula 
---
where is fftest mentioned here found? I only found one place:
  https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c

 Documentation/input/ff.rst |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- linux-next-20210202.orig/Documentation/input/ff.rst
+++ linux-next-20210202/Documentation/input/ff.rst
@@ -16,8 +16,8 @@ goal is not to support these devices as
 (as it is already the case), but to really enable the rendering of force
 effects.
 This document only describes the force feedback part of the Linux input
-interface. Please read joystick.txt and input.txt before reading further this
-document.
+interface. Please read joydev/joystick.rst and input.rst before reading further
+this document.
 
 Instructions to the user
 
@@ -36,7 +36,7 @@ should keep a hand on your device, in or
 something goes wrong.
 
 If you have a serial iforce device, you need to start inputattach. See
-joystick.txt for details.
+joydev/joystick.rst for details.
 
 Does it work ?
 --

[PATCH 8/8] input: Documentation: corrections for uinput.rst

[Randy Dunlap]

Fix a typo (supportinf -> supporting).

Signed-off-by: Randy Dunlap 
Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/input/uinput.rst |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20210202.orig/Documentation/input/uinput.rst
+++ linux-next-20210202/Documentation/input/uinput.rst
@@ -179,7 +179,7 @@ uinput old interface
 
 
 Before uinput version 5, there wasn't a dedicated ioctl to set up a virtual
-device. Programs supportinf older versions of uinput interface need to fill
+device. Programs supporting older versions of uinput interface need to fill
 a uinput_user_dev structure and write it to the uinput file descriptor to
 configure the new uinput device. New code should not use the old interface
 but interact with uinput via ioctl calls, or use libevdev.

[PATCH 0/8] input: Documentation: corrections to Doc/input/ files

[Randy Dunlap]

Update several Documentation/input/ files for wording, punctutation,
struct info, and file names.

Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org

 [PATCH 1/8] input: Documentation: corrections for input.rst
 [PATCH 2/8] input: Documentation: corrections for event-codes.rst
 [PATCH 3/8 RESEND] input: Documentation: update related file names in ff.rst
 [PATCH 4/8] input: Documentation: corrections for gameport-programming.rst
 [PATCH 5/8] input: Documentation: corrections for multi-touch-protocol.rst
 [PATCH 6/8] input: Documentation: corrections for notifier.rst
 [PATCH 7/8] input: Documentation: corrections for input-programming.rst
 [PATCH 8/8] input: Documentation: corrections for uinput.rst

 Documentation/input/event-codes.rst  |   10 ++--
 Documentation/input/ff.rst   |6 +-
 Documentation/input/gameport-programming.rst |   35 +++--
 Documentation/input/input-programming.rst|   20 -
 Documentation/input/input.rst|8 +--
 Documentation/input/multi-touch-protocol.rst |8 +--
 Documentation/input/notifier.rst |3 -
 Documentation/input/uinput.rst   |2 
 8 files changed, 52 insertions(+), 40 deletions(-)

Re: [PATCH 4.9 000/134] 4.9.259-rc3 review

[Florian Fainelli]

On 3/2/21 11:27 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.259 release.
> There are 134 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.259-rc3.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernel:

Tested-by: Florian Fainelli 
-- 
Florian

[PATCH 7/8] input: Documentation: corrections for input-programming.rst

[Randy Dunlap]

Drop a repeated word.
Fix punctuation of "eg." to "e.g."
Fix punctuation of "ie" to "i.e."
Add hyphentation to non-zero.
Capitalize PM (for Power Management).
Capitalize ID (for Identifier).
Change "," in a run-on sentence to ";".

Signed-off-by: Randy Dunlap 
Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/input/input-programming.rst |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

--- linux-next-20210202.orig/Documentation/input/input-programming.rst
+++ linux-next-20210202/Documentation/input/input-programming.rst
@@ -120,7 +120,7 @@ Then there is the::
 
 call to tell those who receive the events that we've sent a complete report.
 This doesn't seem important in the one button case, but is quite important
-for for example mouse movement, where you don't want the X and Y values
+for example for mouse movement, where you don't want the X and Y values
 to be interpreted separately, because that'd result in a different movement.
 
 dev->open() and dev->close()
@@ -128,7 +128,7 @@ dev->open() and dev->close()
 
 In case the driver has to repeatedly poll the device, because it doesn't
 have an interrupt coming from it and the polling is too expensive to be done
-all the time, or if the device uses a valuable resource (eg. interrupt), it
+all the time, or if the device uses a valuable resource (e.g. interrupt), it
 can use the open and close callback to know when it can stop polling or
 release the interrupt and when it must resume polling or grab the interrupt
 again. To do that, we would add this to our example driver::
@@ -161,7 +161,7 @@ makes sure that dev->open() is called on
 to the device and that dev->close() is called when the very last user
 disconnects. Calls to both callbacks are serialized.
 
-The open() callback should return a 0 in case of success or any nonzero value
+The open() callback should return a 0 in case of success or any non-zero value
 in case of failure. The close() callback (which is void) must always succeed.
 
 Inhibiting input devices
@@ -182,8 +182,8 @@ providing events to the input core.
 
 Calling the device's close() method on inhibit (if there are users) allows the
 driver to save power. Either by directly powering down the device or by
-releasing the runtime-pm reference it got in open() when the driver is using
-runtime-pm.
+releasing the runtime-PM reference it got in open() when the driver is using
+runtime-PM.
 
 Inhibiting and uninhibiting are orthogonal to opening and closing the device by
 input handlers. Userspace might want to inhibit a device in anticipation before
@@ -219,8 +219,8 @@ It's reported to the input system via::
input_report_key(struct input_dev *dev, int code, int value)
 
 See uapi/linux/input-event-codes.h for the allowable values of code (from 0 to
-KEY_MAX). Value is interpreted as a truth value, ie any nonzero value means key
-pressed, zero value means key released. The input code generates events only
+KEY_MAX). Value is interpreted as a truth value, i.e. any non-zero value means
+key pressed, zero value means key released. The input code generates events 
only
 in case the value is different from before.
 
 In addition to EV_KEY, there are two more basic event types: EV_REL and
@@ -231,12 +231,12 @@ because it doesn't have any absolute coo
 events are namely for joysticks and digitizers - devices that do work in an
 absolute coordinate systems.
 
-Having the device report EV_REL buttons is as simple as with EV_KEY, simply
+Having the device report EV_REL buttons is as simple as with EV_KEY; simply
 set the corresponding bits and call the::
 
input_report_rel(struct input_dev *dev, int code, int value)
 
-function. Events are generated only for nonzero value.
+function. Events are generated only for non-zero values.
 
 However EV_ABS requires a little special care. Before calling
 input_register_device, you have to fill additional fields in the input_dev
@@ -280,7 +280,7 @@ device driver. It's a string like 'Gener
 user friendly name of the device.
 
 The id* fields contain the bus ID (PCI, USB, ...), vendor ID and device ID
-of the device. The bus IDs are defined in input.h. The vendor and device ids
+of the device. The bus IDs are defined in input.h. The vendor and device IDs
 are defined in pci_ids.h, usb_ids.h and similar include files. These fields
 should be set by the input device driver before registering it.
 

[PATCH 6/8] input: Documentation: corrections for notifier.rst

[Randy Dunlap]

Add 'ledstate' to the keyboard_notifier_param struct info and tell
which header file contains that struct.

Signed-off-by: Randy Dunlap 
Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/input/notifier.rst |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-next-20210202.orig/Documentation/input/notifier.rst
+++ linux-next-20210202/Documentation/input/notifier.rst
@@ -4,11 +4,12 @@ Keyboard notifier
 
 One can use register_keyboard_notifier to get called back on keyboard
 events (see kbd_keycode() function for details).  The passed structure is
-keyboard_notifier_param:
+keyboard_notifier_param (see ):
 
 - 'vc' always provide the VC for which the keyboard event applies;
 - 'down' is 1 for a key press event, 0 for a key release;
 - 'shift' is the current modifier state, mask bit indexes are KG_*;
+- 'ledstate' is the current LED state;
 - 'value' depends on the type of event.
 
 - KBD_KEYCODE events are always sent before other events, value is the keycode.

[PATCH 4/8] input: Documentation: corrections for gameport-programming.rst

[Randy Dunlap]

Use "E.g." instead of "Eg.".
Use correct index for buttons[] array.
Update all of struct gameport's descriptions.

Signed-off-by: Randy Dunlap 
Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/input/gameport-programming.rst |   35 +++--
 1 file changed, 23 insertions(+), 12 deletions(-)

--- linux-next-20210202.orig/Documentation/input/gameport-programming.rst
+++ linux-next-20210202/Documentation/input/gameport-programming.rst
@@ -21,7 +21,7 @@ choose which one to program the hardware
 addresses is preferred, because the likelihood of clashing with the standard
 0x201 address is smaller.
 
-Eg. if your driver supports addresses 0x200, 0x208, 0x210 and 0x218, then
+E.g. if your driver supports addresses 0x200, 0x208, 0x210 and 0x218, then
 0x218 would be the address of first choice.
 
 If your hardware supports a gameport address that is not mapped to ISA io
@@ -78,7 +78,7 @@ the gameport. To register a cooked gamep
 
for (i = 0; i < 4; i++)
axes[i] = my_mmio[i];
-   buttons[i] = my_mmio[4];
+   buttons[0] = my_mmio[4];
}
 
int my_open(struct gameport *gameport, int mode)
@@ -117,25 +117,28 @@ Simple::
 The gameport structure
 ~~
 
-.. note::
-
-This section is outdated. There are several fields here that don't
-match what's there at include/linux/gameport.h.
-
 ::
 
 struct gameport {
 
-   void *private;
+   void *port_data;
 
 A private pointer for free use in the gameport driver. (Not the joystick
 driver!)
 
 ::
 
-   int number;
+   char name[32];
+
+Driver's name as set by driver calling gameport_set_name(). Informational
+purpose only.
+
+::
+
+   char phys[32];
 
-Number assigned to the gameport when registered. Informational purpose only.
+gameport's physical name/description as set by driver calling 
gameport_set_phys().
+Informational purpose only.
 
 ::
 
@@ -210,8 +213,16 @@ gameport.
 
 ::
 
-   struct gameport_dev *dev;
-   struct gameport *next;
+   struct timer_list poll_timer;
+   unsigned int poll_interval; /* in msecs */
+   spinlock_t timer_lock;
+   unsigned int poll_cnt;
+   void (*poll_handler)(struct gameport *);
+   struct gameport *parent, *child;
+   struct gameport_driver *drv;
+   struct mutex drv_mutex; /* protects serio->drv so attributes 
can pin driver */
+   struct device dev;
+   struct list_head node;
 
 For internal use by the gameport layer.
 

[PATCH 5/8] input: Documentation: corrections for multi-touch-protocol.rst

[Randy Dunlap]

Correct hyphenation, spelling, and capitalization.

Signed-off-by: Randy Dunlap 
Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Cc: Henrik Rydberg 
---
 Documentation/input/multi-touch-protocol.rst |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- linux-next-20210202.orig/Documentation/input/multi-touch-protocol.rst
+++ linux-next-20210202/Documentation/input/multi-touch-protocol.rst
@@ -261,7 +261,7 @@ ABS_MT_PRESSURE
 signal intensity distribution.
 
 If the resolution is zero, the pressure data is in arbitrary units.
-If the resolution is nonzero, the pressure data is in units/gram. See
+If the resolution is non-zero, the pressure data is in units/gram. See
 :ref:`input-event-codes` for details.
 
 ABS_MT_DISTANCE
@@ -279,14 +279,14 @@ ABS_MT_ORIENTATION
 max should be returned; when aligned with the X axis in the negative
 direction, the range -max should be returned.
 
-Touch ellipsis are symmetrical by default. For devices capable of true 360
+Touch ellipses are symmetrical by default. For devices capable of true 360
 degree orientation, the reported orientation must exceed the range max to
 indicate more than a quarter of a revolution. For an upside-down finger,
 range max * 2 should be returned.
 
 Orientation can be omitted if the touch area is circular, or if the
 information is not available in the kernel driver. Partial orientation
-support is possible if the device can distinguish between the two axis, but
+support is possible if the device can distinguish between the two axes, but
 not (uniquely) any values in between. In such cases, the range of
 ABS_MT_ORIENTATION should be [0, 1] [#f4]_.
 
@@ -356,7 +356,7 @@ The range of ABS_MT_ORIENTATION should b
 the device can distinguish between a finger along the Y axis (0) and a
 finger along the X axis (1).
 
-For win8 devices with both T and C coordinates, the position mapping is::
+For Win8 devices with both T and C coordinates, the position mapping is::
 
ABS_MT_POSITION_X := T_X
ABS_MT_POSITION_Y := T_Y

Re: [PATCH 1/2] Makefile: Remove '--gcc-toolchain' flag

[Nick Desaulniers]

On Tue, Mar 2, 2021 at 1:07 PM Nathan Chancellor  wrote:
>
> This is not necessary anymore now that we specify '--prefix=', which
> tells clang exactly where to find the GNU cross tools. This has been
> verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as well as a
> distribution version of LLVM 11.1.0 without binutils in the LLVM
> toolchain locations.
>
> Signed-off-by: Nathan Chancellor 

Thanks for the patch!
Reviewed-by: Nick Desaulniers 
Tested-by: Nick Desaulniers 

I see this pattern still being used in
arch/arm64/kernel/vdso32/Makefile, but that can be separate cleanups.

> ---
>  Makefile | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index f9b54da2fca0..c20f0ad8be73 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -568,10 +568,6 @@ ifneq ($(CROSS_COMPILE),)
>  CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%))
>  GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
>  CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
> -GCC_TOOLCHAIN  := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
> -endif
> -ifneq ($(GCC_TOOLCHAIN),)
> -CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN)
>  endif
>  ifneq ($(LLVM_IAS),1)
>  CLANG_FLAGS+= -no-integrated-as
>
> base-commit: 7a7fd0de4a9804299793e564a555a49c1fc924cb
> --
> 2.31.0.rc0.75.gec125d1bc1
>


-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] recordmcount: Fix the wrong use of w* in arm64_is_fake_mcount()

[Steven Rostedt]

On Tue, 2 Mar 2021 17:30:58 -0500
Steven Rostedt  wrote:

> I just realized that I received this patch twice, and thought it was the
> same patch! Chen was three days ahead of you, so he get's the credit ;-)
> 
>  https://lore.kernel.org/r/20210222135840.56250-1-chenjun...@huawei.com

I'm applying this patch (same one here but came earlier).

Will, you still OK with your acked-by on it?

-- Steve

>From 999340d51174ce4141dd723105d4cef872b13ee9 Mon Sep 17 00:00:00 2001
From: Chen Jun 
Date: Mon, 22 Feb 2021 13:58:40 +
Subject: [PATCH] ftrace: Have recordmcount use w8 to read relp->r_info in
 arm64_is_fake_mcount

On little endian system, Use aarch64_be(gcc v7.3) downloaded from
linaro.org to build image with CONFIG_CPU_BIG_ENDIAN = y,
CONFIG_FTRACE = y, CONFIG_DYNAMIC_FTRACE = y.

gcc will create symbols of _mcount but recordmcount can not create
mcount_loc for *.o.
aarch64_be-linux-gnu-objdump -r fs/namei.o | grep mcount
00d0 R_AARCH64_CALL26  _mcount
...
7190 R_AARCH64_CALL26  _mcount

The reason is than funciton arm64_is_fake_mcount can not work correctly.
A symbol of _mcount in *.o compiled with big endian compiler likes:
00 00 00 2d 00 00 01 1b
w(rp->r_info) will return 0x2d instead of 0x011b. Because w() takes
uint32_t as parameter, which truncates rp->r_info.

Use w8() instead w() to read relp->r_info

Link: https://lkml.kernel.org/r/20210222135840.56250-1-chenjun...@huawei.com

Fixes: ea0eada45632 ("recordmcount: only record relocation of type 
R_AARCH64_CALL26 on arm64.")
Acked-by: Will Deacon 
Signed-off-by: Chen Jun 
Signed-off-by: Steven Rostedt (VMware) 
---
 scripts/recordmcount.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index b9c2ee7ab43f..cce12e1971d8 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -438,7 +438,7 @@ static int arm_is_fake_mcount(Elf32_Rel const *rp)
 
 static int arm64_is_fake_mcount(Elf64_Rel const *rp)
 {
-   return ELF64_R_TYPE(w(rp->r_info)) != R_AARCH64_CALL26;
+   return ELF64_R_TYPE(w8(rp->r_info)) != R_AARCH64_CALL26;
 }
 
 /* 64-bit EM_MIPS has weird ELF64_Rela.r_info.
-- 
2.25.4

Re: 5.11 regression: "ia64: add support for TIF_NOTIFY_SIGNAL" breaks ia64 boot

[John Paul Adrian Glaubitz]

Hi Sergei!

On 3/2/21 11:26 PM, Sergei Trofimovich wrote:
> Gave v5.12-rc1 a try today and got a similar boot failure around
> hpsa queue initialization, but my failure is later:
> https://dev.gentoo.org/~slyfox/configs/guppy-dmesg-5.12-rc1
> Maybe I get different error because I flipped on most debugging
> kernel options :)
> 
> Looks like 'ERROR: Invalid distance value range' while being
> very scary are harmless. It's just a new spammy way for kernel
> to report lack of NUMA config on the machine (no SRAT and SLIT
> ACPI tables).
> 
> At least I get hpsa detected on PCI bus. But I guess it's discovered
> configuration is very wrong as I get unaligned accesses:
> [   19.811570] kernel unaligned access to 0xe00105dd8295, 
> ip=0xa00100b874d1
> 
> Bisecting now.

Sounds good. I guess we should get Jens' fix for the signal regression
merged as well as your two fixes for strace.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: 5.12-rc1 regression: freezing iou-mgr/wrk failed

[Jens Axboe]

On 3/2/21 3:13 PM, Alex Xu (Hello71) wrote:
> I tried 29be7fc03d ("io_uring: ensure that threads freeze on suspend") 
> and it seems to work OK. The system suspends fine and no errors are 
> printed to the kernel log.
> 
> I am using Gentoo on the machine in question.
> 
> I didn't test the other patches you supplied. Let me know if there's 
> anything you would like me to test.

OK great, thanks. I'll add your reported/tested-by to the patch.

-- 
Jens Axboe

Re: 5.11 regression: "ia64: add support for TIF_NOTIFY_SIGNAL" breaks ia64 boot

[Jens Axboe]

On 3/2/21 3:07 PM, Sergei Trofimovich wrote:
> On Tue, 23 Feb 2021 08:08:30 +
> Sergei Trofimovich  wrote:
> 
>> On Mon, 22 Feb 2021 17:43:58 -0700
>> Jens Axboe  wrote:
>>
>>> On 2/22/21 5:41 PM, Jens Axboe wrote:  
 On 2/22/21 5:34 PM, Jens Axboe wrote:
> On 2/22/21 4:53 PM, Sergei Trofimovich wrote:
>> On Mon, 22 Feb 2021 16:34:50 -0700
>> Jens Axboe  wrote:
>>
>>> On 2/22/21 4:05 PM, Sergei Trofimovich wrote:
 Hia Jens!

 Tried 5.11 on rx3600 box and noticed it has
 a problem handling init (5.10 booted fine):

 INIT: version 2.98 booting

OpenRC 0.42.1 is starting up Gentoo Linux (ia64)

 mkdir `/run/openrc': Read-only file system
 mkdir `/run/openrc/starting': No such file or directory
 mkdir `/run/openrc/started': No such file or directory
 mkdir `/run/openrc/stopping': No such file or directory
 mkdir `/run/openrc/inactive': No such file or directory
 mkdir `/run/openrc/wasinactive': No such file or directory
 mkdir `/run/openrc/failed': No such file or directory
 mkdir `/run/openrc/hotplugged': No such file or directory
 mkdir `/run/openrc/daemons': No such file or directory
 mkdir `/run[   14.595059] Kernel panic - not syncing: Attempted to 
 kill init! exitcode=0x000b
 [   14.599059] ---[ end Kernel panic - not syncing: Attempted to kill 
 init! exitcode=0x000b ]---

 I suspect we build bad signal stack frame for userspace.

 With a bit of #define DEBUG_SIG 1 enabled the signals are SIGCHLD:

 [   34.969771] SIG deliver (gendepends.sh:69): sig=17 
 sp=6f6aeaa0 ip=a0040740 handler=4b4c59b6
 [   34.969948] SIG deliver (init:1): sig=17 sp=6f1ccc50 
 ip=a0040740 handler=4638b9e5
 [   34.969948] SIG deliver (gendepends.sh:69): sig=17 
 sp=6f6adf90 ip=a0040740 handler=4b4c59b6
 [   34.973948] SIG deliver (init:1): sig=17 sp=6f1cc140 
 ip=a0040740 handler=4638b9e5
 [   34.973948] Kernel panic - not syncing: Attempted to kill init! 
 exitcode=0x000b
 [   34.973948] SIG deliver (gendepends.sh:69): sig=17 
 sp=6f6ad480 ip=a0040740 handler=4b4c59b6
 [   34.973948] ---[ end Kernel panic - not syncing: Attempted to kill 
 init! exitcode=0x000b ]---

 Bisect points at:

 commit b269c229b0e89aedb7943c06673b56b6052cf5e5
 Author: Jens Axboe 
 Date:   Fri Oct 9 14:49:43 2020 -0600

 ia64: add support for TIF_NOTIFY_SIGNAL

 Wire up TIF_NOTIFY_SIGNAL handling for ia64.

 Cc: linux-i...@vger.kernel.org
 [axboe: added fixes from Mike Rapoport ]
 Signed-off-by: Jens Axboe 

 diff --git a/arch/ia64/include/asm/thread_info.h 
 b/arch/ia64/include/asm/thread_info.h
 index 64a1011f6812..51d20cb37706 100644
 --- a/arch/ia64/include/asm/thread_info.h
 +++ b/arch/ia64/include/asm/thread_info.h
 @@ -103,6 +103,7 @@ struct thread_info {
  #define TIF_SYSCALL_TRACE  2   /* syscall trace active */
  #define TIF_SYSCALL_AUDIT  3   /* syscall auditing active */
  #define TIF_SINGLESTEP 4   /* restore singlestep on 
 return to user mode */
 +#define TIF_NOTIFY_SIGNAL  5   /* signal notification exist */
  #define TIF_NOTIFY_RESUME  6   /* resumption notification 
 requested */
  #define TIF_MEMDIE 17  /* is terminating due to OOM 
 killer */
  #define TIF_MCA_INIT   18  /* this task is processing MCA 
 or INIT */
 @@ -115,6 +116,7 @@ struct thread_info {
  #define _TIF_SINGLESTEP(1 << TIF_SINGLESTEP)
  #define _TIF_SYSCALL_TRACEAUDIT
 (_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SINGLESTEP)
  #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
 +#define _TIF_NOTIFY_SIGNAL (1 << TIF_NOTIFY_SIGNAL)
  #define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
  #define _TIF_NEED_RESCHED  (1 << TIF_NEED_RESCHED)
  #define _TIF_MCA_INIT  (1 << TIF_MCA_INIT)
 @@ -124,7 +126,7 @@ struct thread_info {

  /* "work to do on user-return" bits */
  #define TIF_ALLWORK_MASK   
 (_TIF_SIGPENDING|_TIF_NOTIFY_RESUME|_TIF_SYSCALL_AUDIT|\
 -_TIF_NEED_RESCHED|_TIF_SYSCALL_TRACE)
 +
 _TIF_NEED_RESCHED|_TIF_SYSCALL_TRACE|_TIF_NOTIFY_SIGNAL)
  /* like 

[PATCH] bus: mhi: core: Add missing checks for MMIO register entries

[Bhaumik Bhatt]

As per documentation, fields marked as (required) in an MHI
controller structure need to be populated by the controller driver
before calling mhi_register_controller(). Ensure all required
fields are present in the controller before proceeding with the
registration.

Signed-off-by: Bhaumik Bhatt 
---
 drivers/bus/mhi/core/init.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index aa575d3..33323ad 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -860,10 +860,10 @@ int mhi_register_controller(struct mhi_controller 
*mhi_cntrl,
u32 soc_info;
int ret, i;
 
-   if (!mhi_cntrl)
-   return -EINVAL;
-
-   if (!mhi_cntrl->runtime_get || !mhi_cntrl->runtime_put ||
+   if (!mhi_cntrl || !mhi_cntrl->cntrl_dev || !mhi_cntrl->regs ||
+   !mhi_cntrl->iova_start || !mhi_cntrl->iova_stop ||
+   !mhi_cntrl->fw_image || !mhi_cntrl->irq ||
+   !mhi_cntrl->runtime_get || !mhi_cntrl->runtime_put ||
!mhi_cntrl->status_cb || !mhi_cntrl->read_reg ||
!mhi_cntrl->write_reg || !mhi_cntrl->nr_irqs)
return -EINVAL;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] recordmcount: Fix the wrong use of w* in arm64_is_fake_mcount()

[Steven Rostedt]

On Thu, 25 Feb 2021 16:01:17 +
Will Deacon  wrote:

> On Thu, Feb 25, 2021 at 09:44:26AM -0500, Steven Rostedt wrote:
> > This requires an acked-by from one of the ARM64 maintainers.
> > 
> > -- Steve
> > 
> > 
> > On Thu, 25 Feb 2021 22:07:47 +0800
> > Li Huafei  wrote:
> >   
> > > When cross-compiling the kernel, the endian of the target machine and
> > > the local machine may not match, at this time the recordmcount tool
> > > needs byte reversal when processing elf's variables to get the correct
> > > value. w* callback function is used to solve this problem, w is used for
> > > 4-byte variable processing, while w8 is used for 8-byte.
> > > 
> > > arm64_is_fake_mcount() is used to filter '_mcount' relocations that are
> > > not used by ftrace. In arm64_is_fake_mcount(), rp->info is 8 bytes in
> > > size, but w is used. This causes arm64_is_fake_mcount() to get the wrong
> > > type of relocation when we cross-compile the arm64_be kernel image on an
> > > x86_le machine, and all valid '_mcount' is filtered out. The
> > > recordmcount tool does not collect any mcount function call locations.
> > > At kernel startup, the following ftrace log is seen:
> > > 
> > >   ftrace: No functions to be traced?
> > > 
> > > and thus ftrace cannot be used.
> > > 
> > > Using w8 to get the value of rp->r_info will fix the problem.
> > > 
> > > Fixes: ea0eada45632 ("recordmcount: only record relocation of type
> > > R_AARCH64_CALL26 on arm64")
> > > Signed-off-by: Li Huafei 
> > > ---
> > >  scripts/recordmcount.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
> > > index b9c2ee7ab43f..cce12e1971d8 100644
> > > --- a/scripts/recordmcount.c
> > > +++ b/scripts/recordmcount.c
> > > @@ -438,7 +438,7 @@ static int arm_is_fake_mcount(Elf32_Rel const *rp)
> > >  
> > >  static int arm64_is_fake_mcount(Elf64_Rel const *rp)
> > >  {
> > > - return ELF64_R_TYPE(w(rp->r_info)) != R_AARCH64_CALL26;
> > > + return ELF64_R_TYPE(w8(rp->r_info)) != R_AARCH64_CALL26;  
> 
> Acked-by: Will Deacon 
> 
> But you know you could avoid these sorts of problems by moving to little
> endian along with everybody else? ;)
> 

I just realized that I received this patch twice, and thought it was the
same patch! Chen was three days ahead of you, so he get's the credit ;-)

 https://lore.kernel.org/r/20210222135840.56250-1-chenjun...@huawei.com

-- Steve

[tip:x86/mm] BUILD SUCCESS a78eda76b92b81ae3515bcda43a36d671e287c1c

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/mm
branch HEAD: a78eda76b92b81ae3515bcda43a36d671e287c1c  Merge branch 
'locking/core' into x86/mm, to fix conflicts

elapsed time: 722m

configs tested: 119
configs skipped: 2

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
mips tb0287_defconfig
sh  rsk7269_defconfig
armxcep_defconfig
mips   capcella_defconfig
mips tb0226_defconfig
arcnsim_700_defconfig
armkeystone_defconfig
ia64 alldefconfig
armmps2_defconfig
armvt8500_v6_v7_defconfig
m68kmvme16x_defconfig
powerpcklondike_defconfig
powerpc  pmac32_defconfig
mipsbcm63xx_defconfig
xtensaxip_kc705_defconfig
powerpc mpc8272_ads_defconfig
sh  r7780mp_defconfig
sh   se7751_defconfig
ia64defconfig
mips cu1000-neo_defconfig
s390   zfcpdump_defconfig
sh  rts7751r2d1_defconfig
sparc   defconfig
c6x  alldefconfig
powerpc  mgcoge_defconfig
mips   jazz_defconfig
arm   omap1_defconfig
arm mv78xx0_defconfig
riscv nommu_k210_sdcard_defconfig
powerpc mpc837x_mds_defconfig
nios2 10m50_defconfig
armrealview_defconfig
sh   sh7770_generic_defconfig
arm s5pv210_defconfig
openrisc simple_smp_defconfig
m68kstmark2_defconfig
mips   ip27_defconfig
m68km5307c3_defconfig
m68k allmodconfig
ia64 bigsur_defconfig
arm  colibri_pxa270_defconfig
shsh7757lcr_defconfig
armpleb_defconfig
powerpc mpc512x_defconfig
m68k  multi_defconfig
arm  imote2_defconfig
ia64 allmodconfig
ia64 allyesconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210302
x86_64   randconfig-a001-20210302
x86_64   randconfig-a004-20210302
x86_64   randconfig-a002-20210302
x86_64   randconfig-a005-20210302
x86_64   randconfig-a003-20210302
i386 randconfig-a005-20210302
i386 randconfig-a003-20210302
i386 randconfig-a002-20210302
i386 randconfig-a004-20210302
i386 randconfig-a006-20210302
i386 randconfig-a001-20210302
i386 randconfig-a016-20210302
i386 randconfig-a012-20210302
i386 randconfig-a014-20210302
i386 randconfig-a013-20210302
i386 randconfig-a011-20210302
i386 randconfig-a015-20210302
riscv

Re: [PATCH 5.4 000/337] 5.4.102-rc5 review

[Florian Fainelli]

On 3/2/21 11:28 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.102 release.
> There are 337 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.102-rc5.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernel:

Tested-by: Florian Fainelli 
-- 
Florian

Re: [RFC PATCH v5 19/19] virtio/vsock: update trace event for SEQPACKET

[Steven Rostedt]

On Thu, 18 Feb 2021 08:42:15 +0300
Arseny Krasnov  wrote:

Not sure if this was pulled in yet, but I do have a small issue with this
patch.

> @@ -69,14 +82,19 @@ TRACE_EVENT(virtio_transport_alloc_pkt,
>   __entry->type = type;
>   __entry->op = op;
>   __entry->flags = flags;
> + __entry->msg_len = msg_len;
> + __entry->msg_cnt = msg_cnt;
>   ),
> - TP_printk("%u:%u -> %u:%u len=%u type=%s op=%s flags=%#x",
> + TP_printk("%u:%u -> %u:%u len=%u type=%s op=%s flags=%#x "
> +   "msg_len=%u msg_cnt=%u",

It's considered poor formatting to split strings like the above. This is
one of the exceptions for the 80 character limit. Do not break strings just
to keep it within 80 characters.

-- Steve


> __entry->src_cid, __entry->src_port,
> __entry->dst_cid, __entry->dst_port,
> __entry->len,
> show_type(__entry->type),
> show_op(__entry->op),
> -   __entry->flags)
> +   __entry->flags,
> +   __entry->msg_len,
> +   __entry->msg_cnt)
>  );

Re: [PATCH v1 0/3] driver core: Set fw_devlink=on take II

[Michael Walle]

Am 2021-03-02 22:11, schrieb Saravana Kannan:
I think Patch 1 should fix [4] without [5]. Can you test the series 
please?


Mh, I'm on latest linux-next (next-20210302) and I've applied patch 3/3 
and

reverted commit 7007b745a508 ("PCI: layerscape: Convert to
builtin_platform_driver()"). I'd assumed that PCIe shouldn't be working,
right? But it is. Did I miss something?

Anyway, I've also applied Patch 1/3 and 2/3 and it still works. But I
guess that doesn't say much.

-michael

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

[Stephen Rothwell]

Hi all,

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

fs/f2fs/sysfs.c:576:25: warning: 'f2fs_attr_ovp_segments' defined but not used 
[-Wunused-variable]
  576 | static struct f2fs_attr f2fs_attr_##name = __ATTR(name, 0444, 
name##_show, NULL)
  | ^~
fs/f2fs/sysfs.c:639:1: note: in expansion of macro 'F2FS_GENERAL_RO_ATTR'
  639 | F2FS_GENERAL_RO_ATTR(ovp_segments);
  | ^~~~

Introduced by commit

  10e0b8ef8715 ("f2fs: expose # of overprivision segments")

-- 
Cheers,
Stephen Rothwell


pgp0I6WVOUAAo.pgp
Description: OpenPGP digital signature

Re: [PATCH] mm/hugetlb: use some helper functions to cleanup code

[Mike Kravetz]

On 2/9/21 10:53 PM, Miaohe Lin wrote:
> We could use pages_per_huge_page to get the number of pages per hugepage,
> use get_hstate_idx to calculate hstate index, and use hstate_is_gigantic
> to check if a hstate is gigantic to make code more succinct.
> 
> Signed-off-by: Miaohe Lin 

These are all straight forward substitutions of open coded calculations
with the appropriate helper routine.

Reviewed-by: Mike Kravetz 

> ---
>  fs/hugetlbfs/inode.c | 2 +-
>  mm/hugetlb.c | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 701c82c36138..c262566f7c5d 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -1435,7 +1435,7 @@ static int get_hstate_idx(int page_size_log)
>  
>   if (!h)
>   return -1;
> - return h - hstates;
> + return hstate_index(h);
>  }
>  
>  /*
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 8f6c98096476..da347047ea10 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1271,7 +1271,7 @@ static void free_gigantic_page(struct page *page, 
> unsigned int order)
>  static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
>   int nid, nodemask_t *nodemask)
>  {
> - unsigned long nr_pages = 1UL << huge_page_order(h);
> + unsigned long nr_pages = pages_per_huge_page(h);
>   if (nid == NUMA_NO_NODE)
>   nid = numa_mem_id();
>  
> @@ -3262,10 +3262,10 @@ static int __init hugepages_setup(char *s)
>  
>   /*
>* Global state is always initialized later in hugetlb_init.
> -  * But we need to allocate >= MAX_ORDER hstates here early to still
> +  * But we need to allocate gigantic hstates here early to still
>* use the bootmem allocator.
>*/
> - if (hugetlb_max_hstate && parsed_hstate->order >= MAX_ORDER)
> + if (hugetlb_max_hstate && hstate_is_gigantic(parsed_hstate))
>   hugetlb_hstate_alloc_pages(parsed_hstate);
>  
>   last_mhp = mhp;
> 

[PATCH] Fix ld-version.sh script if LLD was built with LLD_VENDOR

[Bernhard Rosenkränzer]

If LLD was built with -DLLD_VENDOR="xyz", ld.lld --version output
will prefix LLD_VENDOR. Since LLD_VENDOR can contain spaces, the
LLD identifier isn't guaranteed to be $2 either.

Adjust the version checker to handle such versions of lld.

Signed-off-by: Bernhard Rosenkränzer 
---
 scripts/ld-version.sh | 12 
 1 file changed, 12 insertions(+)

diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
index a463273509b5..4c042a306e22 100755
--- a/scripts/ld-version.sh
+++ b/scripts/ld-version.sh
@@ -49,6 +49,18 @@ elif [ "$1" = LLD ]; then
min_version=$lld_min_version
name=LLD
disp_name=LLD
+elif echo "$@" |grep -q ' LLD '; then
+   # if LLD was built with -DLLD_VENDOR="xyz", it ld.lld --version
+   # says "xyz LLD [...]". Since LLD_VENDOR may contain spaces, we
+   # don't know the exact position of "LLD" and the version info
+   # at this point
+   while [ "$1" != "LLD" ]; do
+   shift
+   done
+   version=$2
+   min_version=$lld_min_version
+   name=LLD
+   disp_name=LLD
 else
echo "$orig_args: unknown linker" >&2
exit 1
-- 
2.30.1

Re: [PATCH v3 10/10] clocksource/drivers/hyper-v: Move handling of STIMER0 interrupts

[Daniel Lezcano]

On 02/03/2021 22:38, Michael Kelley wrote:
> STIMER0 interrupts are most naturally modeled as per-cpu IRQs. But
> because x86/x64 doesn't have per-cpu IRQs, the core STIMER0 interrupt
> handling machinery is done in code under arch/x86 and Linux IRQs are
> not used. Adding support for ARM64 means adding equivalent code
> using per-cpu IRQs under arch/arm64.
> 
> A better model is to treat per-cpu IRQs as the normal path (which it is
> for modern architectures), and the x86/x64 path as the exception. Do this
> by incorporating standard Linux per-cpu IRQ allocation into the main
> SITMER0 driver code, and bypass it in the x86/x64 exception case. For
> x86/x64, special case code is retained under arch/x86, but no STIMER0
> interrupt handling code is needed under arch/arm64.
> 
> No functional change.
> 
> Signed-off-by: Michael Kelley 

Acked-by: Daniel Lezcano 

[ ... ]

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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

[Stephen Rothwell]

Hi all,

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

fs/afs/file.c: In function 'afs_req_issue_op':
fs/afs/file.c:291:6: warning: unused variable 'ret' [-Wunused-variable]
  291 |  int ret;
  |  ^~~

Introduced by commit

  799fbdf96cd5 ("afs: Use new fscache read helper API")

-- 
Cheers,
Stephen Rothwell


pgpEyqwaybGRc.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 07/10] clocksource/drivers/hyper-v: Handle vDSO differences inline

[Daniel Lezcano]

On 02/03/2021 22:38, Michael Kelley wrote:
> While the driver for the Hyper-V Reference TSC and STIMERs is architecture
> neutral, vDSO is implemented for x86/x64, but not for ARM64.  Current code
> calls into utility functions under arch/x86 (and coming, under arch/arm64)
> to handle the difference.
> 
> Change this approach to handle the difference inline based on whether
> VDSO_CLOCK_MODE_HVCLOCK is present.  The new approach removes code under
> arch/* since the difference is tied more to the specifics of the Linux
> implementation than to the architecture.
> 
> No functional change.
> 
> Signed-off-by: Michael Kelley 
> Reviewed-by: Boqun Feng 
> ---
>  arch/x86/include/asm/mshyperv.h|  4 
>  drivers/clocksource/hyperv_timer.c | 10 --
>  2 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index c10dd1c..4f566db 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -27,10 +27,6 @@ static inline u64 hv_get_register(unsigned int reg)
>   return value;
>  }
>  
> -#define hv_set_clocksource_vdso(val) \
> - ((val).vdso_clock_mode = VDSO_CLOCKMODE_HVCLOCK)
> -#define hv_enable_vdso_clocksource() \
> - vclocks_set_used(VDSO_CLOCKMODE_HVCLOCK);
>  #define hv_get_raw_timer() rdtsc_ordered()
>  
>  /*
> diff --git a/drivers/clocksource/hyperv_timer.c 
> b/drivers/clocksource/hyperv_timer.c
> index c73c127..06984fa 100644
> --- a/drivers/clocksource/hyperv_timer.c
> +++ b/drivers/clocksource/hyperv_timer.c
> @@ -370,11 +370,13 @@ static void resume_hv_clock_tsc(struct clocksource *arg)
>   hv_set_register(HV_REGISTER_REFERENCE_TSC, tsc_msr);
>  }
>  
> +#ifdef VDSO_CLOCKMODE_HVCLOCK
>  static int hv_cs_enable(struct clocksource *cs)
>  {
> - hv_enable_vdso_clocksource();
> + vclocks_set_used(VDSO_CLOCKMODE_HVCLOCK);
>   return 0;
>  }
> +#endif

We had a confusion here. The suggestion was to remove the #ifdef here
and add the __maybe_unused annotation to the function.

>  static struct clocksource hyperv_cs_tsc = {
>   .name   = "hyperv_clocksource_tsc_page",
> @@ -384,7 +386,12 @@ static int hv_cs_enable(struct clocksource *cs)
>   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
>   .suspend= suspend_hv_clock_tsc,
>   .resume = resume_hv_clock_tsc,
> +#ifdef VDSO_CLOCKMODE_HVCLOCK
>   .enable = hv_cs_enable,
> + .vdso_clock_mode = VDSO_CLOCKMODE_HVCLOCK,
> +#else
> + .vdso_clock_mode = VDSO_CLOCKMODE_NONE,
> +#endif
>  };
>  
>  static u64 notrace read_hv_clock_msr(void)
> @@ -442,7 +449,6 @@ static bool __init hv_init_tsc_clocksource(void)
>   tsc_msr = tsc_msr | 0x1 | (u64)phys_addr;
>   hv_set_register(HV_REGISTER_REFERENCE_TSC, tsc_msr);
>  
> - hv_set_clocksource_vdso(hyperv_cs_tsc);
>   clocksource_register_hz(_cs_tsc, NSEC_PER_SEC/100);
>  
>   hv_sched_clock_offset = hv_read_reference_counter();
> 


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v3 08/10] clocksource/drivers/hyper-v: Handle sched_clock differences inline

[Daniel Lezcano]

On 02/03/2021 22:38, Michael Kelley wrote:
> While the Hyper-V Reference TSC code is architecture neutral, the
> pv_ops.time.sched_clock() function is implemented for x86/x64, but not
> for ARM64. Current code calls a utility function under arch/x86 (and
> coming, under arch/arm64) to handle the difference.
> 
> Change this approach to handle the difference inline based on whether
> GENERIC_SCHED_CLOCK is present.  The new approach removes code under
> arch/* since the difference is tied more to the specifics of the Linux
> implementation than to the architecture.
> 
> No functional change.
> 
> Signed-off-by: Michael Kelley 
> Reviewed-by: Boqun Feng 

Acked-by: Daniel Lezcano 

> ---
>  arch/x86/include/asm/mshyperv.h| 11 ---
>  drivers/clocksource/hyperv_timer.c | 24 
>  2 files changed, 24 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index 4f566db..5433312 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -29,17 +29,6 @@ static inline u64 hv_get_register(unsigned int reg)
>  
>  #define hv_get_raw_timer() rdtsc_ordered()
>  
> -/*
> - * Reference to pv_ops must be inline so objtool
> - * detection of noinstr violations can work correctly.
> - */
> -static __always_inline void hv_setup_sched_clock(void *sched_clock)
> -{
> -#ifdef CONFIG_PARAVIRT
> - pv_ops.time.sched_clock = sched_clock;
> -#endif
> -}
> -
>  void hyperv_vector_handler(struct pt_regs *regs);
>  
>  static inline void hv_enable_stimer0_percpu_irq(int irq) {}
> diff --git a/drivers/clocksource/hyperv_timer.c 
> b/drivers/clocksource/hyperv_timer.c
> index 06984fa..10eb5c6 100644
> --- a/drivers/clocksource/hyperv_timer.c
> +++ b/drivers/clocksource/hyperv_timer.c
> @@ -423,6 +423,30 @@ static u64 notrace read_hv_sched_clock_msr(void)
>   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
>  };
>  
> +/*
> + * Reference to pv_ops must be inline so objtool
> + * detection of noinstr violations can work correctly.
> + */
> +#ifdef CONFIG_GENERIC_SCHED_CLOCK
> +static __always_inline void hv_setup_sched_clock(void *sched_clock)
> +{
> + /*
> +  * We're on an architecture with generic sched clock (not x86/x64).
> +  * The Hyper-V sched clock read function returns nanoseconds, not
> +  * the normal 100ns units of the Hyper-V synthetic clock.
> +  */
> + sched_clock_register(sched_clock, 64, NSEC_PER_SEC);
> +}
> +#elif defined CONFIG_PARAVIRT
> +static __always_inline void hv_setup_sched_clock(void *sched_clock)
> +{
> + /* We're on x86/x64 *and* using PV ops */
> + pv_ops.time.sched_clock = sched_clock;
> +}
> +#else /* !CONFIG_GENERIC_SCHED_CLOCK && !CONFIG_PARAVIRT */
> +static __always_inline void hv_setup_sched_clock(void *sched_clock) {}
> +#endif /* CONFIG_GENERIC_SCHED_CLOCK */
> +
>  static bool __init hv_init_tsc_clocksource(void)
>  {
>   u64 tsc_msr;
> 


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: 5.12-rc1 regression: freezing iou-mgr/wrk failed

[Alex Xu (Hello71)]

I tried 29be7fc03d ("io_uring: ensure that threads freeze on suspend") 
and it seems to work OK. The system suspends fine and no errors are 
printed to the kernel log.

I am using Gentoo on the machine in question.

I didn't test the other patches you supplied. Let me know if there's 
anything you would like me to test.

Thanks,
Alex.

Re: [RFC PATCH v2 0/2] mm: fix races due to deferred TLB flushes

[Peter Xu]

On Fri, Dec 25, 2020 at 01:25:27AM -0800, Nadav Amit wrote:
> From: Nadav Amit 
> 
> This patch-set went from v1 to RFCv2, as there is still an ongoing
> discussion regarding the way of solving the recently found races due to
> deferred TLB flushes. These patches are only sent for reference for now,
> and can be applied later if no better solution is taken.
> 
> In a nutshell, write-protecting PTEs with deferred TLB flushes was mostly
> performed while holding mmap_lock for write. This prevented concurrent
> page-fault handler invocations from mistakenly assuming that a page is
> write-protected when in fact, due to the deferred TLB flush, other CPU
> could still write to the page. Such a write can cause a memory
> corruption if it takes place after the page was copied (in
> cow_user_page()), and before the PTE was flushed (by wp_page_copy()).
> 
> However, the userfaultfd and soft-dirty mechanisms did not take
> mmap_lock for write, but only for read, which made such races possible.
> Since commit 09854ba94c6a ("mm: do_wp_page() simplification") these
> races became more likely to take place as non-COW'd pages are more
> likely to be COW'd instead of being reused. Both of the races that
> these patches are intended to resolve were produced on v5.10.
> 
> To avoid the performance overhead some alternative solutions that do not
> require to acquire mmap_lock for write were proposed, specifically for
> userfaultfd. So far no better solution that can be backported was
> proposed for the soft-dirty case.
> 
> v1->RFCv2:
> - Better (i.e., correct) description of the userfaultfd buggy case [Yu]
> - Patch for the soft-dirty case

Nadav,

Do you plan to post a new version to fix the tlb corrupt issue that this series
wanted to solve?

Thanks,

-- 
Peter Xu

Re: [RFC PATCH v2 0/2] mm: fix races due to deferred TLB flushes

[Nadav Amit]

> On Mar 2, 2021, at 2:13 PM, Peter Xu  wrote:
> 
> On Fri, Dec 25, 2020 at 01:25:27AM -0800, Nadav Amit wrote:
>> From: Nadav Amit 
>> 
>> This patch-set went from v1 to RFCv2, as there is still an ongoing
>> discussion regarding the way of solving the recently found races due to
>> deferred TLB flushes. These patches are only sent for reference for now,
>> and can be applied later if no better solution is taken.
>> 
>> In a nutshell, write-protecting PTEs with deferred TLB flushes was mostly
>> performed while holding mmap_lock for write. This prevented concurrent
>> page-fault handler invocations from mistakenly assuming that a page is
>> write-protected when in fact, due to the deferred TLB flush, other CPU
>> could still write to the page. Such a write can cause a memory
>> corruption if it takes place after the page was copied (in
>> cow_user_page()), and before the PTE was flushed (by wp_page_copy()).
>> 
>> However, the userfaultfd and soft-dirty mechanisms did not take
>> mmap_lock for write, but only for read, which made such races possible.
>> Since commit 09854ba94c6a ("mm: do_wp_page() simplification") these
>> races became more likely to take place as non-COW'd pages are more
>> likely to be COW'd instead of being reused. Both of the races that
>> these patches are intended to resolve were produced on v5.10.
>> 
>> To avoid the performance overhead some alternative solutions that do not
>> require to acquire mmap_lock for write were proposed, specifically for
>> userfaultfd. So far no better solution that can be backported was
>> proposed for the soft-dirty case.
>> 
>> v1->RFCv2:
>> - Better (i.e., correct) description of the userfaultfd buggy case [Yu]
>> - Patch for the soft-dirty case
> 
> Nadav,
> 
> Do you plan to post a new version to fix the tlb corrupt issue that this 
> series
> wanted to solve?

Yes, yes. Sorry for that. Will do so later today.

Regards,
Nadav


signature.asc
Description: Message signed with OpenPGP

Re: [PATCH v3 4/8] mm/rmap: Split migration into its own function

[Zi Yan]

On 26 Feb 2021, at 2:18, Alistair Popple wrote:

> Migration is currently implemented as a mode of operation for
> try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag
> or in the case of splitting a huge anonymous page TTU_SPLIT_FREEZE.
>
> However it does not have much in common with the rest of the unmap
> functionality of try_to_unmap_one() and thus splitting it into a
> separate function reduces the complexity of try_to_unmap_one() making it
> more readable.
>
> Several simplifications can also be made in try_to_migrate_one() based
> on the following observations:
>
>  - All users of TTU_MIGRATION also set TTU_IGNORE_MLOCK.
>  - No users of TTU_MIGRATION ever set TTU_IGNORE_HWPOISON.
>  - No users of TTU_MIGRATION ever set TTU_BATCH_FLUSH.
>
> TTU_SPLIT_FREEZE is a special case of migration used when splitting an
> anonymous page. This is most easily dealt with by calling the correct
> function from unmap_page() in mm/huge_memory.c  - either
> try_to_migrate() for PageAnon or try_to_unmap().
>
> Signed-off-by: Alistair Popple 
> ---
>  include/linux/rmap.h |   4 +-
>  mm/huge_memory.c |  10 +-
>  mm/migrate.c |   9 +-
>  mm/rmap.c| 352 +++
>  4 files changed, 269 insertions(+), 106 deletions(-)
>
> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> index 7f1ee411bd7b..77fa17de51d7 100644
> --- a/include/linux/rmap.h
> +++ b/include/linux/rmap.h
> @@ -86,8 +86,6 @@ struct anon_vma_chain {
>  };
>
>  enum ttu_flags {
> - TTU_MIGRATION   = 0x1,  /* migration mode */
> -
>   TTU_SPLIT_HUGE_PMD  = 0x4,  /* split huge PMD if any */

It implies freeze in try_to_migrate() and no freeze in try_to_unmap(). I think
we need some comments here, above try_to_migrate(), and above try_to_unmap()
to clarify the implication.

>   TTU_IGNORE_MLOCK= 0x8,  /* ignore mlock */
>   TTU_IGNORE_HWPOISON = 0x20, /* corrupted page is recoverable */
> @@ -96,7 +94,6 @@ enum ttu_flags {
>* do a final flush if necessary */
>   TTU_RMAP_LOCKED = 0x80, /* do not grab rmap lock:
>* caller holds it */
> - TTU_SPLIT_FREEZE= 0x100,/* freeze pte under 
> splitting thp */
>  };
>
>  #ifdef CONFIG_MMU
> @@ -193,6 +190,7 @@ static inline void page_dup_rmap(struct page *page, bool 
> compound)
>  int page_referenced(struct page *, int is_locked,
>   struct mem_cgroup *memcg, unsigned long *vm_flags);
>
> +bool try_to_migrate(struct page *page, enum ttu_flags flags);
>  bool try_to_unmap(struct page *, enum ttu_flags flags);
>
>  /* Avoid racy checks */
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index d00b93dc2d9e..357052a4567b 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2351,16 +2351,16 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma,
>
>  static void unmap_page(struct page *page)
>  {
> - enum ttu_flags ttu_flags = TTU_IGNORE_MLOCK |
> - TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
> + enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
>   bool unmap_success;
>
>   VM_BUG_ON_PAGE(!PageHead(page), page);
>
>   if (PageAnon(page))
> - ttu_flags |= TTU_SPLIT_FREEZE;
> -
> - unmap_success = try_to_unmap(page, ttu_flags);
> + unmap_success = try_to_migrate(page, ttu_flags);
> + else
> + unmap_success = try_to_unmap(page, ttu_flags |
> + TTU_IGNORE_MLOCK);

I think we need a comment here about why anonymous pages need try_to_migrate()
and others need try_to_unmap().

Thanks.

—
Best Regards,
Yan Zi


signature.asc
Description: OpenPGP digital signature

Re: [PATCH 5.10 000/657] 5.10.20-rc4 review

[Florian Fainelli]

On 3/2/21 11:28 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.20 release.
> There are 657 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.20-rc4.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.10.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernel:

Tested-by: Florian Fainelli 
-- 
Florian

Re: [PATCH 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as

[Nick Desaulniers]

On Tue, Mar 2, 2021 at 2:02 PM Fangrui Song  wrote:
>
> On 2021-03-02, Nathan Chancellor wrote:
> >When building with LLVM_IAS=1, there is no point to specifying
> >'--prefix=' because that flag is only used to find the cross assembler,
> >which is clang itself when building with LLVM_IAS=1. All of the other
> >tools are invoked directly from PATH or a full path specified via the
> >command line, which does not depend on the value of '--prefix='.
> >
> >Sharing commands to reproduce issues becomes a little bit easier without
> >a '--prefix=' value because that '--prefix=' value is specific to a
> >user's machine due to it being an absolute path.
> >
> >Signed-off-by: Nathan Chancellor 
>
> Reviewed-by: Fangrui Song 
>
> clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU
> objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]).

But -g get's set via CONFIG_DEBUG_INFO and -gsplit-dwarf by
DEBUG_INFO_SPLIT.  So if we say:
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang LLVM_IAS=1

So cross compile, use clang, use the integrated assembler (ie. with
this change, don't set --prefix), with either of the two above
configs, which objcopy get's exec'd?

>
> With LLVM_IAS=1, these cases are ruled out.



-- 
Thanks,
~Nick Desaulniers

Re: 5.11 regression: "ia64: add support for TIF_NOTIFY_SIGNAL" breaks ia64 boot

[Sergei Trofimovich]

On Tue, 23 Feb 2021 08:08:30 +
Sergei Trofimovich  wrote:

> On Mon, 22 Feb 2021 17:43:58 -0700
> Jens Axboe  wrote:
> 
> > On 2/22/21 5:41 PM, Jens Axboe wrote:  
> > > On 2/22/21 5:34 PM, Jens Axboe wrote:
> > >> On 2/22/21 4:53 PM, Sergei Trofimovich wrote:
> > >>> On Mon, 22 Feb 2021 16:34:50 -0700
> > >>> Jens Axboe  wrote:
> > >>>
> >  On 2/22/21 4:05 PM, Sergei Trofimovich wrote:
> > > Hia Jens!
> > >
> > > Tried 5.11 on rx3600 box and noticed it has
> > > a problem handling init (5.10 booted fine):
> > >
> > > INIT: version 2.98 booting
> > >
> > >OpenRC 0.42.1 is starting up Gentoo Linux (ia64)
> > >
> > > mkdir `/run/openrc': Read-only file system
> > > mkdir `/run/openrc/starting': No such file or directory
> > > mkdir `/run/openrc/started': No such file or directory
> > > mkdir `/run/openrc/stopping': No such file or directory
> > > mkdir `/run/openrc/inactive': No such file or directory
> > > mkdir `/run/openrc/wasinactive': No such file or directory
> > > mkdir `/run/openrc/failed': No such file or directory
> > > mkdir `/run/openrc/hotplugged': No such file or directory
> > > mkdir `/run/openrc/daemons': No such file or directory
> > > mkdir `/run[   14.595059] Kernel panic - not syncing: Attempted to 
> > > kill init! exitcode=0x000b
> > > [   14.599059] ---[ end Kernel panic - not syncing: Attempted to kill 
> > > init! exitcode=0x000b ]---
> > >
> > > I suspect we build bad signal stack frame for userspace.
> > >
> > > With a bit of #define DEBUG_SIG 1 enabled the signals are SIGCHLD:
> > >
> > > [   34.969771] SIG deliver (gendepends.sh:69): sig=17 
> > > sp=6f6aeaa0 ip=a0040740 handler=4b4c59b6
> > > [   34.969948] SIG deliver (init:1): sig=17 sp=6f1ccc50 
> > > ip=a0040740 handler=4638b9e5
> > > [   34.969948] SIG deliver (gendepends.sh:69): sig=17 
> > > sp=6f6adf90 ip=a0040740 handler=4b4c59b6
> > > [   34.973948] SIG deliver (init:1): sig=17 sp=6f1cc140 
> > > ip=a0040740 handler=4638b9e5
> > > [   34.973948] Kernel panic - not syncing: Attempted to kill init! 
> > > exitcode=0x000b
> > > [   34.973948] SIG deliver (gendepends.sh:69): sig=17 
> > > sp=6f6ad480 ip=a0040740 handler=4b4c59b6
> > > [   34.973948] ---[ end Kernel panic - not syncing: Attempted to kill 
> > > init! exitcode=0x000b ]---
> > >
> > > Bisect points at:
> > >
> > > commit b269c229b0e89aedb7943c06673b56b6052cf5e5
> > > Author: Jens Axboe 
> > > Date:   Fri Oct 9 14:49:43 2020 -0600
> > >
> > > ia64: add support for TIF_NOTIFY_SIGNAL
> > >
> > > Wire up TIF_NOTIFY_SIGNAL handling for ia64.
> > >
> > > Cc: linux-i...@vger.kernel.org
> > > [axboe: added fixes from Mike Rapoport ]
> > > Signed-off-by: Jens Axboe 
> > >
> > > diff --git a/arch/ia64/include/asm/thread_info.h 
> > > b/arch/ia64/include/asm/thread_info.h
> > > index 64a1011f6812..51d20cb37706 100644
> > > --- a/arch/ia64/include/asm/thread_info.h
> > > +++ b/arch/ia64/include/asm/thread_info.h
> > > @@ -103,6 +103,7 @@ struct thread_info {
> > >  #define TIF_SYSCALL_TRACE  2   /* syscall trace active */
> > >  #define TIF_SYSCALL_AUDIT  3   /* syscall auditing active */
> > >  #define TIF_SINGLESTEP 4   /* restore singlestep on 
> > > return to user mode */
> > > +#define TIF_NOTIFY_SIGNAL  5   /* signal notification exist 
> > > */
> > >  #define TIF_NOTIFY_RESUME  6   /* resumption notification 
> > > requested */
> > >  #define TIF_MEMDIE 17  /* is terminating due to OOM 
> > > killer */
> > >  #define TIF_MCA_INIT   18  /* this task is processing 
> > > MCA or INIT */
> > > @@ -115,6 +116,7 @@ struct thread_info {
> > >  #define _TIF_SINGLESTEP(1 << TIF_SINGLESTEP)
> > >  #define _TIF_SYSCALL_TRACEAUDIT
> > > (_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SINGLESTEP)
> > >  #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
> > > +#define _TIF_NOTIFY_SIGNAL (1 << TIF_NOTIFY_SIGNAL)
> > >  #define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
> > >  #define _TIF_NEED_RESCHED  (1 << TIF_NEED_RESCHED)
> > >  #define _TIF_MCA_INIT  (1 << TIF_MCA_INIT)
> > > @@ -124,7 +126,7 @@ struct thread_info {
> > >
> > >  /* "work to do on user-return" bits */
> > >  #define TIF_ALLWORK_MASK   
> > > (_TIF_SIGPENDING|_TIF_NOTIFY_RESUME|_TIF_SYSCALL_AUDIT|\
> > > -_TIF_NEED_RESCHED|_TIF_SYSCALL_TRACE)
> > > +
> > > 

[PATCH v4 5/6] can: c_can: prepare to up the message objects number

[Dario Binacchi]

As pointed by commit c0a9f4d396c9 ("can: c_can: Reduce register access")
the "driver casts the 16 message objects in stone, which is completely
braindead as contemporary hardware has up to 128 message objects".

The patch prepares the module to extend the number of message objects
beyond the 32 currently managed. This was achieved by transforming the
constants used to manage RX/TX messages into variables without changing
the driver policy.

Signed-off-by: Dario Binacchi 
Reported-by: kernel test robot 

---

Changes in v4:
- Use GENMASK() for setting msg_obj_rx_mask.

Changes in v3:
- Use unsigned int instead of int as type of the msg_obj_* fields
  in the c_can_priv structure.
- Replace (u64)1 with 1UL in msg_obj_rx_mask setting.

Changes in v2:
- Fix compiling error reported by kernel test robot.
- Add Reported-by tag.
- Pass larger size to alloc_candev() routine to avoid an additional
  memory allocation/deallocation.

 drivers/net/can/c_can/c_can.c  | 50 --
 drivers/net/can/c_can/c_can.h  | 23 ++--
 drivers/net/can/c_can/c_can_pci.c  |  2 +-
 drivers/net/can/c_can/c_can_platform.c |  2 +-
 4 files changed, 43 insertions(+), 34 deletions(-)

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 77b9aee56154..0052ba5197e0 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -173,9 +173,6 @@
 /* Wait for ~1 sec for INIT bit */
 #define INIT_WAIT_MS   1000
 
-/* napi related */
-#define C_CAN_NAPI_WEIGHT  C_CAN_MSG_OBJ_RX_NUM
-
 /* c_can lec values */
 enum c_can_lec_type {
LEC_NO_ERROR = 0,
@@ -325,7 +322,7 @@ static void c_can_setup_tx_object(struct net_device *dev, 
int iface,
 * first, i.e. clear the MSGVAL flag in the arbiter.
 */
if (rtr != (bool)test_bit(idx, >tx_dir)) {
-   u32 obj = idx + C_CAN_MSG_OBJ_TX_FIRST;
+   u32 obj = idx + priv->msg_obj_tx_first;
 
c_can_inval_msg_object(dev, iface, obj);
change_bit(idx, >tx_dir);
@@ -463,10 +460,10 @@ static netdev_tx_t c_can_start_xmit(struct sk_buff *skb,
 * prioritized. The lowest buffer number wins.
 */
idx = fls(atomic_read(>tx_active));
-   obj = idx + C_CAN_MSG_OBJ_TX_FIRST;
+   obj = idx + priv->msg_obj_tx_first;
 
/* If this is the last buffer, stop the xmit queue */
-   if (idx == C_CAN_MSG_OBJ_TX_NUM - 1)
+   if (idx == priv->msg_obj_tx_num - 1)
netif_stop_queue(dev);
/*
 * Store the message in the interface so we can call
@@ -549,17 +546,18 @@ static int c_can_set_bittiming(struct net_device *dev)
  */
 static void c_can_configure_msg_objects(struct net_device *dev)
 {
+   struct c_can_priv *priv = netdev_priv(dev);
int i;
 
/* first invalidate all message objects */
-   for (i = C_CAN_MSG_OBJ_RX_FIRST; i <= C_CAN_NO_OF_OBJECTS; i++)
+   for (i = priv->msg_obj_rx_first; i <= priv->msg_obj_num; i++)
c_can_inval_msg_object(dev, IF_RX, i);
 
/* setup receive message objects */
-   for (i = C_CAN_MSG_OBJ_RX_FIRST; i < C_CAN_MSG_OBJ_RX_LAST; i++)
+   for (i = priv->msg_obj_rx_first; i < priv->msg_obj_rx_last; i++)
c_can_setup_receive_object(dev, IF_RX, i, 0, 0, IF_MCONT_RCV);
 
-   c_can_setup_receive_object(dev, IF_RX, C_CAN_MSG_OBJ_RX_LAST, 0, 0,
+   c_can_setup_receive_object(dev, IF_RX, priv->msg_obj_rx_last, 0, 0,
   IF_MCONT_RCV_EOB);
 }
 
@@ -730,7 +728,7 @@ static void c_can_do_tx(struct net_device *dev)
while ((idx = ffs(pend))) {
idx--;
pend &= ~(1 << idx);
-   obj = idx + C_CAN_MSG_OBJ_TX_FIRST;
+   obj = idx + priv->msg_obj_tx_first;
 
/*
 * We use IF_RX interface instead of IF_TX because we are
@@ -746,7 +744,7 @@ static void c_can_do_tx(struct net_device *dev)
/* Clear the bits in the tx_active mask */
atomic_sub(clr, >tx_active);
 
-   if (clr & (1 << (C_CAN_MSG_OBJ_TX_NUM - 1)))
+   if (clr & (1 << (priv->msg_obj_tx_num - 1)))
netif_wake_queue(dev);
 
if (pkts) {
@@ -761,11 +759,11 @@ static void c_can_do_tx(struct net_device *dev)
  * raced with the hardware or failed to readout all upper
  * objects in the last run due to quota limit.
  */
-static u32 c_can_adjust_pending(u32 pend)
+static u32 c_can_adjust_pending(u32 pend, u32 rx_mask)
 {
u32 weight, lasts;
 
-   if (pend == RECEIVE_OBJECT_BITS)
+   if (pend == rx_mask)
return pend;
 
/*
@@ -868,8 +866,7 @@ static int c_can_do_rx_poll(struct net_device *dev, int 
quota)
 * It is faster to read only one 16bit register. This is only possible
 * for a maximum number of 16 objects.
 */
-   BUILD_BUG_ON_MSG(C_CAN_MSG_OBJ_RX_LAST > 16,
-   "Implementation does 

[PATCH v4 3/6] can: c_can: add a comment about IF_RX interface's use

[Dario Binacchi]

After reading the commit 640916db2bf7 ("can: c_can: Make it SMP safe")
it may sound strange to see the IF_RX interface used by the
can_inval_tx_object function. A comment was added to avoid any
misunderstanding.

Signed-off-by: Dario Binacchi 

---

Changes in v4:
- Restore IF_RX interface.
- Add a comment to clarify why IF_RX interface is used instead of IF_TX.

 drivers/net/can/c_can/c_can.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index dbcc1c1c92d6..6c6d0d0ff7b8 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -732,6 +732,12 @@ static void c_can_do_tx(struct net_device *dev)
idx--;
pend &= ~(1 << idx);
obj = idx + C_CAN_MSG_OBJ_TX_FIRST;
+
+   /*
+* We use IF_RX interface instead of IF_TX because we are
+* called from c_can_poll(), which runs inside NAPI. We are
+* not trasmitting.
+*/
c_can_inval_tx_object(dev, IF_RX, obj);
can_get_echo_skb(dev, idx, NULL);
bytes += priv->dlc[idx];
-- 
2.17.1

[PATCH v4 4/6] can: c_can: use 32-bit write to set arbitration register

[Dario Binacchi]

The arbitration register is already set up with 32-bit writes in the
other parts of the code except for this point.

Signed-off-by: Dario Binacchi 
---

(no changes since v1)

 drivers/net/can/c_can/c_can.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 6c6d0d0ff7b8..77b9aee56154 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -297,8 +297,7 @@ static void c_can_inval_msg_object(struct net_device *dev, 
int iface, int obj)
 {
struct c_can_priv *priv = netdev_priv(dev);
 
-   priv->write_reg(priv, C_CAN_IFACE(ARB1_REG, iface), 0);
-   priv->write_reg(priv, C_CAN_IFACE(ARB2_REG, iface), 0);
+   priv->write_reg32(priv, C_CAN_IFACE(ARB1_REG, iface), 0);
c_can_inval_tx_object(dev, iface, obj);
 }
 
-- 
2.17.1

Re: [PATCH 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as

[Fangrui Song]

On 2021-03-02, Nathan Chancellor wrote:

When building with LLVM_IAS=1, there is no point to specifying
'--prefix=' because that flag is only used to find the cross assembler,
which is clang itself when building with LLVM_IAS=1. All of the other
tools are invoked directly from PATH or a full path specified via the
command line, which does not depend on the value of '--prefix='.

Sharing commands to reproduce issues becomes a little bit easier without
a '--prefix=' value because that '--prefix=' value is specific to a
user's machine due to it being an absolute path.

Signed-off-by: Nathan Chancellor 


Reviewed-by: Fangrui Song 

clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU
objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]).

With LLVM_IAS=1, these cases are ruled out.

[PATCH v4 1/6] can: c_can: remove unused code

[Dario Binacchi]

Commit 9d23a9818cb1 ("can: c_can: Remove unused inline function") left
behind C_CAN_MSG_OBJ_TX_LAST constant.

Commit fa39b54ccf28 ("can: c_can: Get rid of pointless interrupts") left
behind C_CAN_MSG_RX_LOW_LAST and C_CAN_MSG_OBJ_RX_SPLIT constants.

The removed code also made a comment useless and misleading.

Signed-off-by: Dario Binacchi 
---

(no changes since v1)

 drivers/net/can/c_can/c_can.c | 3 +--
 drivers/net/can/c_can/c_can.h | 4 
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index ef474bae47a1..a962ceefd44a 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -848,8 +848,7 @@ static inline u32 c_can_get_pending(struct c_can_priv *priv)
  * c_can core saves a received CAN message into the first free message
  * object it finds free (starting with the lowest). Bits NEWDAT and
  * INTPND are set for this message object indicating that a new message
- * has arrived. To work-around this issue, we keep two groups of message
- * objects whose partitioning is defined by C_CAN_MSG_OBJ_RX_SPLIT.
+ * has arrived.
  *
  * We clear the newdat bit right away.
  *
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 92213d3d96eb..90d3d2e7a086 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -32,11 +32,7 @@
C_CAN_MSG_OBJ_RX_NUM - 1)
 
 #define C_CAN_MSG_OBJ_TX_FIRST (C_CAN_MSG_OBJ_RX_LAST + 1)
-#define C_CAN_MSG_OBJ_TX_LAST  (C_CAN_MSG_OBJ_TX_FIRST + \
-   C_CAN_MSG_OBJ_TX_NUM - 1)
 
-#define C_CAN_MSG_OBJ_RX_SPLIT 9
-#define C_CAN_MSG_RX_LOW_LAST  (C_CAN_MSG_OBJ_RX_SPLIT - 1)
 #define RECEIVE_OBJECT_BITS0x
 
 enum reg {
-- 
2.17.1

[PATCH v4 2/6] can: c_can: fix indentation

[Dario Binacchi]

Commit 524369e2391f ("can: c_can: remove obsolete STRICT_FRAME_ORDERING Kconfig 
option")
left behind wrong indentation, fix it.

Signed-off-by: Dario Binacchi 
---

(no changes since v1)

 drivers/net/can/c_can/c_can.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index a962ceefd44a..dbcc1c1c92d6 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -786,7 +786,7 @@ static u32 c_can_adjust_pending(u32 pend)
 static inline void c_can_rx_object_get(struct net_device *dev,
   struct c_can_priv *priv, u32 obj)
 {
-   c_can_object_get(dev, IF_RX, obj, priv->comm_rcv_high);
+   c_can_object_get(dev, IF_RX, obj, priv->comm_rcv_high);
 }
 
 static inline void c_can_rx_finalize(struct net_device *dev,
-- 
2.17.1

[PATCH v4 0/6] can: c_can: add support to 64 message objects

[Dario Binacchi]

The D_CAN controller supports up to 128 messages. Until now the driver
only managed 32 messages although Sitara processors and DRA7 SOC can
handle 64.

The series was tested on a beaglebone board.

Note:
I have not changed the type of tx_field (belonging to the c_can_priv
structure) to atomic64_t because I think the atomic_t type has size
of at least 32 bits on x86 and arm, which is enough to handle 64
messages.
http://marc.info/?l=linux-can=139746476821294=2 reports the results
of tests performed just on x86 and arm architectures.

Changes in v4:
- Restore IF_RX interface.
- Add a comment to clarify why IF_RX interface is used instead of IF_TX.
- Use GENMASK() for setting msg_obj_rx_mask.
- Use BIT() for setting single bits and GENMASK() for setting masks.

Changes in v3:
- Use unsigned int instead of int as type of the msg_obj_* fields
  in the c_can_priv structure.
- Replace (u64)1 with 1UL in msg_obj_rx_mask setting.
- Use unsigned int instead of int as type of the msg_obj_num field
  in c_can_driver_data and c_can_pci_data structures.

Changes in v2:
- Fix compiling error reported by kernel test robot.
- Add Reported-by tag.
- Pass larger size to alloc_candev() routine to avoid an additional
  memory allocation/deallocation.
- Add message objects number to PCI driver data.

Dario Binacchi (6):
  can: c_can: remove unused code
  can: c_can: fix indentation
  can: c_can: add a comment about IF_RX interface's use
  can: c_can: use 32-bit write to set arbitration register
  can: c_can: prepare to up the message objects number
  can: c_can: add support to 64 message objects

 drivers/net/can/c_can/c_can.c  | 90 --
 drivers/net/can/c_can/c_can.h  | 32 -
 drivers/net/can/c_can/c_can_pci.c  |  6 +-
 drivers/net/can/c_can/c_can_platform.c |  6 +-
 4 files changed, 78 insertions(+), 56 deletions(-)

-- 
2.17.1

[PATCH v4 6/6] can: c_can: add support to 64 message objects

[Dario Binacchi]

D_CAN controller supports 16, 32, 64 or 128 message objects, comparing
to 32 on C_CAN.
AM335x/AM437x Sitara processors and DRA7 SOC all instantiate a D_CAN
controller with 64 message objects, as described in the "DCAN features"
subsection of the CAN chapter of their technical reference manuals.

The driver policy has been kept unchanged, and as in the previous
version, the first half of the message objects is used for reception and
the second for transmission.

The I/O load is increased only in the case of 64 message objects,
keeping it unchanged in the case of 32. Two 32-bit read accesses are in
fact required, which however remained at 16-bit for configurations with
32 message objects.

Signed-off-by: Dario Binacchi 

---

Changes in v4:
- Use BIT() for setting single bits and GENMASK() for setting masks.

Changes in v3:
- Use unsigned int instead of int as type of the msg_obj_num field
  in c_can_driver_data and c_can_pci_data structures.

Changes in v2:
- Add message objects number to PCI driver data.

 drivers/net/can/c_can/c_can.c  | 30 +++---
 drivers/net/can/c_can/c_can.h  |  5 +++--
 drivers/net/can/c_can/c_can_pci.c  |  6 +-
 drivers/net/can/c_can/c_can_platform.c |  6 +-
 4 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 0052ba5197e0..41e4ec6ab0aa 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -475,7 +475,7 @@ static netdev_tx_t c_can_start_xmit(struct sk_buff *skb,
can_put_echo_skb(skb, dev, idx, 0);
 
/* Update the active bits */
-   atomic_add((1 << idx), >tx_active);
+   atomic_add(BIT(idx), >tx_active);
/* Start transmission */
c_can_object_put(dev, IF_TX, obj, IF_COMM_TX);
 
@@ -723,11 +723,15 @@ static void c_can_do_tx(struct net_device *dev)
struct net_device_stats *stats = >stats;
u32 idx, obj, pkts = 0, bytes = 0, pend, clr;
 
-   clr = pend = priv->read_reg(priv, C_CAN_INTPND2_REG);
+   if (priv->msg_obj_tx_last > 32)
+   pend = priv->read_reg32(priv, C_CAN_INTPND3_REG);
+   else
+   pend = priv->read_reg(priv, C_CAN_INTPND2_REG);
 
+   clr = pend;
while ((idx = ffs(pend))) {
idx--;
-   pend &= ~(1 << idx);
+   pend &= ~BIT(idx);
obj = idx + priv->msg_obj_tx_first;
 
/*
@@ -744,7 +748,7 @@ static void c_can_do_tx(struct net_device *dev)
/* Clear the bits in the tx_active mask */
atomic_sub(clr, >tx_active);
 
-   if (clr & (1 << (priv->msg_obj_tx_num - 1)))
+   if (clr & BIT(priv->msg_obj_tx_num - 1))
netif_wake_queue(dev);
 
if (pkts) {
@@ -781,9 +785,10 @@ static u32 c_can_adjust_pending(u32 pend, u32 rx_mask)
 * Find the first set bit after the gap. We walk backwards
 * from the last set bit.
 */
-   for (lasts--; pend & (1 << (lasts - 1)); lasts--);
+   for (lasts--; pend & BIT(lasts - 1); lasts--)
+   ;
 
-   return pend & ~((1 << lasts) - 1);
+   return pend & ~GENMASK(lasts - 1, 0);
 }
 
 static inline void c_can_rx_object_get(struct net_device *dev,
@@ -840,7 +845,12 @@ static int c_can_read_objects(struct net_device *dev, 
struct c_can_priv *priv,
 
 static inline u32 c_can_get_pending(struct c_can_priv *priv)
 {
-   u32 pend = priv->read_reg(priv, C_CAN_NEWDAT1_REG);
+   u32 pend;
+
+   if (priv->msg_obj_rx_last > 16)
+   pend = priv->read_reg32(priv, C_CAN_NEWDAT1_REG);
+   else
+   pend = priv->read_reg(priv, C_CAN_NEWDAT1_REG);
 
return pend;
 }
@@ -862,12 +872,6 @@ static int c_can_do_rx_poll(struct net_device *dev, int 
quota)
struct c_can_priv *priv = netdev_priv(dev);
u32 pkts = 0, pend = 0, toread, n;
 
-   /*
-* It is faster to read only one 16bit register. This is only possible
-* for a maximum number of 16 objects.
-*/
-   WARN_ON(priv->msg_obj_rx_last > 16);
-
while (quota > 0) {
if (!pend) {
pend = c_can_get_pending(priv);
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 68295fab83d9..bd291e998a51 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -22,8 +22,6 @@
 #ifndef C_CAN_H
 #define C_CAN_H
 
-#define C_CAN_NO_OF_OBJECTS32
-
 enum reg {
C_CAN_CTRL_REG = 0,
C_CAN_CTRL_EX_REG,
@@ -61,6 +59,7 @@ enum reg {
C_CAN_NEWDAT2_REG,
C_CAN_INTPND1_REG,
C_CAN_INTPND2_REG,
+   C_CAN_INTPND3_REG,
C_CAN_MSGVAL1_REG,
C_CAN_MSGVAL2_REG,
C_CAN_FUNCTION_REG,
@@ -122,6 +121,7 @@ static const u16 __maybe_unused reg_map_d_can[] = {
[C_CAN_NEWDAT2_REG] = 0x9E,
[C_CAN_INTPND1_REG] = 0xB0,
[C_CAN_INTPND2_REG] = 0xB2,
+   

Re: [PATCH v2] mm/hugetlb: remove redundant reservation check condition in alloc_huge_page()

[Mike Kravetz]

On 3/1/21 2:47 AM, Miaohe Lin wrote:
> vma_resv_map(vma) checks if a reserve map is associated with the vma.  The
> routine vma_needs_reservation() will check vma_resv_map(vma) and return 1
> if no reserv map is present.  map_chg is set to the return value of
> vma_needs_reservation().  Therefore, !vma_resv_map(vma) is redundant in the
> expression:
>   map_chg || avoid_reserve || !vma_resv_map(vma);
> Remove the redundant check.
> 
> [Thanks Mike Kravetz for reshaping this commit message!]
> 
> Signed-off-by: Miaohe Lin 

Thanks,

Reviewed-by: Mike Kravetz 

> ---
>  mm/hugetlb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 60c67eb016f7..060005b868cf 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2314,7 +2314,7 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
>  
>   /* If this allocation is not consuming a reservation, charge it now.
>*/
> - deferred_reserve = map_chg || avoid_reserve || !vma_resv_map(vma);
> + deferred_reserve = map_chg || avoid_reserve;
>   if (deferred_reserve) {
>   ret = hugetlb_cgroup_charge_cgroup_rsvd(
>   idx, pages_per_huge_page(h), _cg);
> 

[PATCH 3/3] clk: socfpga: Convert to s10/agilex/n5x to use clk_hw

[Dinh Nguyen]

As recommended by Stephen Boyd, convert the Agilex/Stratix10/n5x clock
driver to use the clk_hw registration method.

Suggested-by: Stephen Boyd 
Signed-off-by: Dinh Nguyen 
---
 drivers/clk/socfpga/clk-agilex.c | 114 ++-
 drivers/clk/socfpga/clk-gate-s10.c   |  15 ++--
 drivers/clk/socfpga/clk-periph-s10.c |  42 +-
 drivers/clk/socfpga/clk-pll-s10.c|  43 +-
 drivers/clk/socfpga/clk-s10.c|  68 +++-
 drivers/clk/socfpga/stratix10-clk.h  |  24 +++---
 6 files changed, 159 insertions(+), 147 deletions(-)

diff --git a/drivers/clk/socfpga/clk-agilex.c b/drivers/clk/socfpga/clk-agilex.c
index 7689bdd0a914..319c69112bcf 100644
--- a/drivers/clk/socfpga/clk-agilex.c
+++ b/drivers/clk/socfpga/clk-agilex.c
@@ -303,18 +303,18 @@ static const struct stratix10_gate_clock 
agilex_gate_clks[] = {
 static int n5x_clk_register_c_perip(const struct n5x_perip_c_clock *clks,
   int nums, struct stratix10_clock_data 
*data)
 {
-   struct clk *clk;
+   struct clk_hw *hw_clk;
void __iomem *base = data->base;
int i;
 
for (i = 0; i < nums; i++) {
-   clk = n5x_register_periph([i], base);
-   if (IS_ERR(clk)) {
+   hw_clk = n5x_register_periph([i], base);
+   if (IS_ERR(hw_clk)) {
pr_err("%s: failed to register clock %s\n",
   __func__, clks[i].name);
continue;
}
-   data->clk_data.clks[clks[i].id] = clk;
+   data->clk_data.hws[clks[i].id] = hw_clk;
}
return 0;
 }
@@ -322,18 +322,18 @@ static int n5x_clk_register_c_perip(const struct 
n5x_perip_c_clock *clks,
 static int agilex_clk_register_c_perip(const struct stratix10_perip_c_clock 
*clks,
   int nums, struct stratix10_clock_data 
*data)
 {
-   struct clk *clk;
+   struct clk_hw *hw_clk;
void __iomem *base = data->base;
int i;
 
for (i = 0; i < nums; i++) {
-   clk = s10_register_periph([i], base);
-   if (IS_ERR(clk)) {
+   hw_clk = s10_register_periph([i], base);
+   if (IS_ERR(hw_clk)) {
pr_err("%s: failed to register clock %s\n",
   __func__, clks[i].name);
continue;
}
-   data->clk_data.clks[clks[i].id] = clk;
+   data->clk_data.hws[clks[i].id] = hw_clk;
}
return 0;
 }
@@ -341,18 +341,18 @@ static int agilex_clk_register_c_perip(const struct 
stratix10_perip_c_clock *clk
 static int agilex_clk_register_cnt_perip(const struct 
stratix10_perip_cnt_clock *clks,
 int nums, struct stratix10_clock_data 
*data)
 {
-   struct clk *clk;
+   struct clk_hw *hw_clk;
void __iomem *base = data->base;
int i;
 
for (i = 0; i < nums; i++) {
-   clk = s10_register_cnt_periph([i], base);
-   if (IS_ERR(clk)) {
+   hw_clk = s10_register_cnt_periph([i], base);
+   if (IS_ERR(hw_clk)) {
pr_err("%s: failed to register clock %s\n",
   __func__, clks[i].name);
continue;
}
-   data->clk_data.clks[clks[i].id] = clk;
+   data->clk_data.hws[clks[i].id] = hw_clk;
}
 
return 0;
@@ -360,18 +360,18 @@ static int agilex_clk_register_cnt_perip(const struct 
stratix10_perip_cnt_clock
 
 static int agilex_clk_register_gate(const struct stratix10_gate_clock *clks,   
int nums, struct stratix10_clock_data *data)
 {
-   struct clk *clk;
+   struct clk_hw *hw_clk;
void __iomem *base = data->base;
int i;
 
for (i = 0; i < nums; i++) {
-   clk = s10_register_gate([i], base);
-   if (IS_ERR(clk)) {
+   hw_clk = s10_register_gate([i], base);
+   if (IS_ERR(hw_clk)) {
pr_err("%s: failed to register clock %s\n",
   __func__, clks[i].name);
continue;
}
-   data->clk_data.clks[clks[i].id] = clk;
+   data->clk_data.hws[clks[i].id] = hw_clk;
}
 
return 0;
@@ -380,18 +380,18 @@ static int agilex_clk_register_gate(const struct 
stratix10_gate_clock *clks,
 static int agilex_clk_register_pll(const struct stratix10_pll_clock *clks,
 int nums, struct stratix10_clock_data *data)
 {
-   struct clk *clk;
+   struct clk_hw *hw_clk;
void __iomem *base = data->base;
int i;
 
for (i = 0; i < nums; i++) {
-   clk = agilex_register_pll([i], base);
-   if (IS_ERR(clk)) {
+   hw_clk = 

Re: [PATCH 1/2] Makefile: Remove '--gcc-toolchain' flag

[Fangrui Song]

Reviewed-by: Fangrui Song 

Thanks for the clean-up!
--gcc-toolchain= is an obsscure way searching for GCC installation prefixes 
(--prefix).
The logic is complex and different for different distributions/architectures.

If we specify --prefix= (-B) explicitly, --gcc-toolchain is not needed.

On 2021-03-02, Nathan Chancellor wrote:

This is not necessary anymore now that we specify '--prefix=', which
tells clang exactly where to find the GNU cross tools. This has been
verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as well as a
distribution version of LLVM 11.1.0 without binutils in the LLVM
toolchain locations.

Signed-off-by: Nathan Chancellor 
---
Makefile | 4 
1 file changed, 4 deletions(-)

diff --git a/Makefile b/Makefile
index f9b54da2fca0..c20f0ad8be73 100644
--- a/Makefile
+++ b/Makefile
@@ -568,10 +568,6 @@ ifneq ($(CROSS_COMPILE),)
CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
-GCC_TOOLCHAIN  := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
-endif
-ifneq ($(GCC_TOOLCHAIN),)
-CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN)
endif
ifneq ($(LLVM_IAS),1)
CLANG_FLAGS += -no-integrated-as

base-commit: 7a7fd0de4a9804299793e564a555a49c1fc924cb
--
2.31.0.rc0.75.gec125d1bc1

--
You received this message because you are subscribed to the Google Groups "Clang 
Built Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clang-built-linux+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clang-built-linux/20210302210646.3044738-1-nathan%40kernel.org.

[PATCH v3 02/10] x86/hyper-v: Move hv_message_type to architecture neutral module

[Michael Kelley]

The definition of enum hv_message_type includes arch neutral and
x86/x64-specific values. Ideally there would be a way to put the
arch neutral values in an arch neutral module, and the arch
specific values in an arch specific module. But C doesn't provide
a way to extend enum types. As a compromise, move the entire
definition into an arch neutral module, to avoid duplicating the
arch neutral values for x86/x64 and for ARM64.

No functional change.

Signed-off-by: Michael Kelley 
Reviewed-by: Boqun Feng 
---
 arch/x86/include/asm/hyperv-tlfs.h | 29 -
 include/asm-generic/hyperv-tlfs.h  | 35 +++
 2 files changed, 35 insertions(+), 29 deletions(-)

diff --git a/arch/x86/include/asm/hyperv-tlfs.h 
b/arch/x86/include/asm/hyperv-tlfs.h
index e6cd3fe..68b38a2 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -288,35 +288,6 @@ struct hv_tsc_emulation_status {
 #define HV_X64_MSR_TSC_REFERENCE_ENABLE0x0001
 #define HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT 12
 
-
-/* Define hypervisor message types. */
-enum hv_message_type {
-   HVMSG_NONE  = 0x,
-
-   /* Memory access messages. */
-   HVMSG_UNMAPPED_GPA  = 0x8000,
-   HVMSG_GPA_INTERCEPT = 0x8001,
-
-   /* Timer notification messages. */
-   HVMSG_TIMER_EXPIRED = 0x8010,
-
-   /* Error messages. */
-   HVMSG_INVALID_VP_REGISTER_VALUE = 0x8020,
-   HVMSG_UNRECOVERABLE_EXCEPTION   = 0x8021,
-   HVMSG_UNSUPPORTED_FEATURE   = 0x8022,
-
-   /* Trace buffer complete messages. */
-   HVMSG_EVENTLOG_BUFFERCOMPLETE   = 0x8040,
-
-   /* Platform-specific processor intercept messages. */
-   HVMSG_X64_IOPORT_INTERCEPT  = 0x8001,
-   HVMSG_X64_MSR_INTERCEPT = 0x80010001,
-   HVMSG_X64_CPUID_INTERCEPT   = 0x80010002,
-   HVMSG_X64_EXCEPTION_INTERCEPT   = 0x80010003,
-   HVMSG_X64_APIC_EOI  = 0x80010004,
-   HVMSG_X64_LEGACY_FP_ERROR   = 0x80010005
-};
-
 struct hv_nested_enlightenments_control {
struct {
__u32 directhypercall:1;
diff --git a/include/asm-generic/hyperv-tlfs.h 
b/include/asm-generic/hyperv-tlfs.h
index 83448e8..9cf10837 100644
--- a/include/asm-generic/hyperv-tlfs.h
+++ b/include/asm-generic/hyperv-tlfs.h
@@ -220,6 +220,41 @@ enum HV_GENERIC_SET_FORMAT {
 #define HV_MESSAGE_PAYLOAD_BYTE_COUNT  (240)
 #define HV_MESSAGE_PAYLOAD_QWORD_COUNT (30)
 
+/*
+ * Define hypervisor message types. Some of the message types
+ * are x86/x64 specific, but there's no good way to separate
+ * them out into the arch-specific version of hyperv-tlfs.h
+ * because C doesn't provide a way to extend enum types.
+ * Keeping them all in the arch neutral hyperv-tlfs.h seems
+ * the least messy compromise.
+ */
+enum hv_message_type {
+   HVMSG_NONE  = 0x,
+
+   /* Memory access messages. */
+   HVMSG_UNMAPPED_GPA  = 0x8000,
+   HVMSG_GPA_INTERCEPT = 0x8001,
+
+   /* Timer notification messages. */
+   HVMSG_TIMER_EXPIRED = 0x8010,
+
+   /* Error messages. */
+   HVMSG_INVALID_VP_REGISTER_VALUE = 0x8020,
+   HVMSG_UNRECOVERABLE_EXCEPTION   = 0x8021,
+   HVMSG_UNSUPPORTED_FEATURE   = 0x8022,
+
+   /* Trace buffer complete messages. */
+   HVMSG_EVENTLOG_BUFFERCOMPLETE   = 0x8040,
+
+   /* Platform-specific processor intercept messages. */
+   HVMSG_X64_IOPORT_INTERCEPT  = 0x8001,
+   HVMSG_X64_MSR_INTERCEPT = 0x80010001,
+   HVMSG_X64_CPUID_INTERCEPT   = 0x80010002,
+   HVMSG_X64_EXCEPTION_INTERCEPT   = 0x80010003,
+   HVMSG_X64_APIC_EOI  = 0x80010004,
+   HVMSG_X64_LEGACY_FP_ERROR   = 0x80010005
+};
+
 /* Define synthetic interrupt controller message flags. */
 union hv_message_flags {
__u8 asu8;
-- 
1.8.3.1

[PATCH v3 03/10] Drivers: hv: Redo Hyper-V synthetic MSR get/set functions

[Michael Kelley]

Current code defines a separate get and set macro for each Hyper-V
synthetic MSR used by the VMbus driver. Furthermore, the get macro
can't be converted to a standard function because the second argument
is modified in place, which is somewhat bad form.

Redo this by providing a single get and a single set function that
take a parameter specifying the MSR to be operated on. Fixup usage
of the get function. Calling locations are no more complex than before,
but the code under arch/x86 and the upcoming code under arch/arm64
is significantly simplified.

Also standardize the names of Hyper-V synthetic MSRs that are
architecture neutral. But keep the old x86-specific names as aliases
that can be removed later when all references (particularly in KVM
code) have been cleaned up in a separate patch series.

No functional change.

Signed-off-by: Michael Kelley 
Reviewed-by: Boqun Feng 
---
 arch/x86/hyperv/hv_init.c  |   2 +-
 arch/x86/include/asm/hyperv-tlfs.h | 102 +++--
 arch/x86/include/asm/mshyperv.h|  39 --
 drivers/clocksource/hyperv_timer.c |  26 +-
 drivers/hv/hv.c|  37 --
 drivers/hv/vmbus_drv.c |   2 +-
 include/asm-generic/mshyperv.h |   2 +-
 7 files changed, 110 insertions(+), 100 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 4bdb344..94d52c5 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -75,7 +75,7 @@ static int hv_cpu_init(unsigned int cpu)
*output_arg = page_address(pg + 1);
}
 
-   hv_get_vp_index(msr_vp_index);
+   msr_vp_index = hv_get_register(HV_REGISTER_VP_INDEX);
 
hv_vp_index[smp_processor_id()] = msr_vp_index;
 
diff --git a/arch/x86/include/asm/hyperv-tlfs.h 
b/arch/x86/include/asm/hyperv-tlfs.h
index 68b38a2..606f5cc 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -156,7 +156,7 @@ enum hv_isolation_type {
 #define HV_X64_MSR_HYPERCALL   0x4001
 
 /* MSR used to provide vcpu index */
-#define HV_X64_MSR_VP_INDEX0x4002
+#define HV_REGISTER_VP_INDEX   0x4002
 
 /* MSR used to reset the guest OS. */
 #define HV_X64_MSR_RESET   0x4003
@@ -165,10 +165,10 @@ enum hv_isolation_type {
 #define HV_X64_MSR_VP_RUNTIME  0x4010
 
 /* MSR used to read the per-partition time reference counter */
-#define HV_X64_MSR_TIME_REF_COUNT  0x4020
+#define HV_REGISTER_TIME_REF_COUNT 0x4020
 
 /* A partition's reference time stamp counter (TSC) page */
-#define HV_X64_MSR_REFERENCE_TSC   0x4021
+#define HV_REGISTER_REFERENCE_TSC  0x4021
 
 /* MSR used to retrieve the TSC frequency */
 #define HV_X64_MSR_TSC_FREQUENCY   0x4022
@@ -183,50 +183,50 @@ enum hv_isolation_type {
 #define HV_X64_MSR_VP_ASSIST_PAGE  0x4073
 
 /* Define synthetic interrupt controller model specific registers. */
-#define HV_X64_MSR_SCONTROL0x4080
-#define HV_X64_MSR_SVERSION0x4081
-#define HV_X64_MSR_SIEFP   0x4082
-#define HV_X64_MSR_SIMP0x4083
-#define HV_X64_MSR_EOM 0x4084
-#define HV_X64_MSR_SINT0   0x4090
-#define HV_X64_MSR_SINT1   0x4091
-#define HV_X64_MSR_SINT2   0x4092
-#define HV_X64_MSR_SINT3   0x4093
-#define HV_X64_MSR_SINT4   0x4094
-#define HV_X64_MSR_SINT5   0x4095
-#define HV_X64_MSR_SINT6   0x4096
-#define HV_X64_MSR_SINT7   0x4097
-#define HV_X64_MSR_SINT8   0x4098
-#define HV_X64_MSR_SINT9   0x4099
-#define HV_X64_MSR_SINT10  0x409A
-#define HV_X64_MSR_SINT11  0x409B
-#define HV_X64_MSR_SINT12  0x409C
-#define HV_X64_MSR_SINT13  0x409D
-#define HV_X64_MSR_SINT14  0x409E
-#define HV_X64_MSR_SINT15  0x409F
+#define HV_REGISTER_SCONTROL   0x4080
+#define HV_REGISTER_SVERSION   0x4081
+#define HV_REGISTER_SIEFP  0x4082
+#define HV_REGISTER_SIMP   0x4083
+#define HV_REGISTER_EOM0x4084
+#define HV_REGISTER_SINT0  0x4090
+#define HV_REGISTER_SINT1  0x4091
+#define HV_REGISTER_SINT2  0x4092
+#define HV_REGISTER_SINT3  0x4093
+#define HV_REGISTER_SINT4  0x4094
+#define HV_REGISTER_SINT5  0x4095

[PATCH v3 08/10] clocksource/drivers/hyper-v: Handle sched_clock differences inline

[Michael Kelley]

While the Hyper-V Reference TSC code is architecture neutral, the
pv_ops.time.sched_clock() function is implemented for x86/x64, but not
for ARM64. Current code calls a utility function under arch/x86 (and
coming, under arch/arm64) to handle the difference.

Change this approach to handle the difference inline based on whether
GENERIC_SCHED_CLOCK is present.  The new approach removes code under
arch/* since the difference is tied more to the specifics of the Linux
implementation than to the architecture.

No functional change.

Signed-off-by: Michael Kelley 
Reviewed-by: Boqun Feng 
---
 arch/x86/include/asm/mshyperv.h| 11 ---
 drivers/clocksource/hyperv_timer.c | 24 
 2 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 4f566db..5433312 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -29,17 +29,6 @@ static inline u64 hv_get_register(unsigned int reg)
 
 #define hv_get_raw_timer() rdtsc_ordered()
 
-/*
- * Reference to pv_ops must be inline so objtool
- * detection of noinstr violations can work correctly.
- */
-static __always_inline void hv_setup_sched_clock(void *sched_clock)
-{
-#ifdef CONFIG_PARAVIRT
-   pv_ops.time.sched_clock = sched_clock;
-#endif
-}
-
 void hyperv_vector_handler(struct pt_regs *regs);
 
 static inline void hv_enable_stimer0_percpu_irq(int irq) {}
diff --git a/drivers/clocksource/hyperv_timer.c 
b/drivers/clocksource/hyperv_timer.c
index 06984fa..10eb5c6 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -423,6 +423,30 @@ static u64 notrace read_hv_sched_clock_msr(void)
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
+/*
+ * Reference to pv_ops must be inline so objtool
+ * detection of noinstr violations can work correctly.
+ */
+#ifdef CONFIG_GENERIC_SCHED_CLOCK
+static __always_inline void hv_setup_sched_clock(void *sched_clock)
+{
+   /*
+* We're on an architecture with generic sched clock (not x86/x64).
+* The Hyper-V sched clock read function returns nanoseconds, not
+* the normal 100ns units of the Hyper-V synthetic clock.
+*/
+   sched_clock_register(sched_clock, 64, NSEC_PER_SEC);
+}
+#elif defined CONFIG_PARAVIRT
+static __always_inline void hv_setup_sched_clock(void *sched_clock)
+{
+   /* We're on x86/x64 *and* using PV ops */
+   pv_ops.time.sched_clock = sched_clock;
+}
+#else /* !CONFIG_GENERIC_SCHED_CLOCK && !CONFIG_PARAVIRT */
+static __always_inline void hv_setup_sched_clock(void *sched_clock) {}
+#endif /* CONFIG_GENERIC_SCHED_CLOCK */
+
 static bool __init hv_init_tsc_clocksource(void)
 {
u64 tsc_msr;
-- 
1.8.3.1

Re: [Cocci] linux-kernel janitorial RFP: Mark static arrays as const

[Julia Lawall]

On Tue, 2 Mar 2021, Joe Perches wrote:

> Here is a possible opportunity to reduce data usage in the kernel.

Does it actually reduce data usage?

julia

>
> $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' 
> drivers/ | \
>   grep -v __initdata | \
>   wc -l
> 3250
>
> Meaning there are ~3000 declarations of arrays with what appears to be
> file static const content that are not marked const.
>
> So there are many static arrays that could be marked const to move the
> compiled object code from data to text minimizing the total amount of
> exposed r/w data.
>
> However, I do not know of a mechanism using coccinelle to determine
> whether or not any of these static declarations are ever modified.
>
> So it appears that each instance of these declarations might need
> manual inspection.
>
> But for arrays declared inside functions, it's much more likely that
> the static declaration without const is done with the intent to modify
> the array:
>
> (note the difference in the git grep with a leading '^\s+')
>
> $ git grep -Pn '^\s+static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' 
> drivers/ | \
>   grep -v __initdata | \
>   wc -l
> 323
>
> - For instance: (head -10 of the git grep for file statics)
>
> drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 16, 
> 8, 4, 2, 1 };
> drivers/accessibility/speakup/keyhelp.c:26:static u_char funcvals[] = {
> drivers/accessibility/speakup/main.c:2059:static spkup_hand spkup_handler[] = 
> {
> drivers/accessibility/speakup/speakup_acntpc.c:35:static unsigned int 
> synth_portlist[] = { 0x2a8, 0 };
> drivers/accessibility/speakup/speakup_decpc.c:133:static int synth_portlist[] 
> = { 0x340, 0x350, 0x240, 0x250, 0 };
> drivers/accessibility/speakup/speakup_dectlk.c:110:static int ap_defaults[] = 
> {122, 89, 155, 110, 208, 240, 200, 106, 306};
> drivers/accessibility/speakup/speakup_dectlk.c:111:static int g5_defaults[] = 
> {86, 81, 86, 84, 81, 80, 83, 83, 73};
> drivers/accessibility/speakup/speakup_dtlk.c:34:static unsigned int 
> synth_portlist[] = {
> drivers/accessibility/speakup/speakup_keypc.c:34:static unsigned int 
> synth_portlist[] = { 0x2a8, 0 };
> drivers/acpi/ac.c:137:static enum power_supply_property ac_props[] = {
>
> For drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 
> 16, 8, 4, 2, 1 };
>
> masks is only used in static function say_key and should be const and
> perhaps the declaration might be better moved into that function.
>
> For drivers/accessibility/speakup/keyhelp.c:26:static u_char funcvals[] = {
>
> funcvals is only used in static function spk_handle_help and should be const
> and perhaps the declaration might be better moved into that function.
>
> For drivers/accessibility/speakup/main.c:2059:static spkup_hand 
> spkup_handler[] = {
>
> spkup_handler is only used in static function do_spkup and should be const
> and perhaps the declaration might be better moved into that function.
>
> etc... for speakup
>
> For drivers/acpi/ac.c:137:static enum power_supply_property ac_props[] = {
>
> array ac_props is assigned as a reference in acpi_ac_add as a
> "const enum power_supply_property *" member of a struct power_supply_desc.
>
> - For instance: (head -10 of the git grep for function statics)
>
> drivers/acpi/apei/apei-base.c:781:static u8 whea_uuid_str[] = 
> "ed855e0c-6c90-47bf-a62a-26de0fc5ad5c";
> drivers/block/amiflop.c:1051: static unsigned char CRCTable1[] = {
> drivers/block/amiflop.c:1070: static unsigned char CRCTable2[] = {
> drivers/block/drbd/drbd_nl.c:872: static char units[] = { 'K', 'M', 'G', 
> 'T', 'P', 'E' };
> drivers/block/drbd/drbd_proc.c:224:   static char write_ordering_chars[] = {
> drivers/block/drbd/drbd_receiver.c:4363:  static enum drbd_conns c_tab[] 
> = {
> drivers/char/pcmcia/synclink_cs.c:3717:   static unsigned char patterns[] 
> =
> drivers/cpufreq/intel_pstate.c:1515:  static int silvermont_freq_table[] = {
> drivers/cpufreq/intel_pstate.c:1530:  static int airmont_freq_table[] = {
> drivers/dma/xgene-dma.c:360:  static u8 flyby_type[] = {
>
> Some of these could be const, but some could not.  For instance:
>
> For drivers/acpi/apei/apei-base.c:781:static u8 whea_uuid_str[] = 
> "ed855e0c-6c90-47bf-a62a-26de0fc5ad5c";
>
> whea_uuid_str is assigned as a reference in "int apei_osc_setup(void)"
> a struct acpi_osc_context where .uuid_str is not declared as const char *.
>
>
>
>
> ___
> Cocci mailing list
> co...@systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
>

[PATCH 1/3] clk: socfpga: use clk_hw_register for a5/c5

[Dinh Nguyen]

As recommended by Stephen Boyd, convert the cyclone5/arria5 clock driver
to use the clk_hw registration method.

Suggested-by: Stephen Boyd 
Signed-off-by: Dinh Nguyen 
---
 drivers/clk/socfpga/clk-gate.c   | 11 +++
 drivers/clk/socfpga/clk-periph.c |  8 
 drivers/clk/socfpga/clk-pll.c| 18 +++---
 3 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c
index 43ecd507bf83..b17aba5799d2 100644
--- a/drivers/clk/socfpga/clk-gate.c
+++ b/drivers/clk/socfpga/clk-gate.c
@@ -174,13 +174,14 @@ void __init socfpga_gate_init(struct device_node *node)
u32 div_reg[3];
u32 clk_phase[2];
u32 fixed_div;
-   struct clk *clk;
+   struct clk_hw *hw_clk;
struct socfpga_gate_clk *socfpga_clk;
const char *clk_name = node->name;
const char *parent_name[SOCFPGA_MAX_PARENTS];
struct clk_init_data init;
struct clk_ops *ops;
int rc;
+   int err;
 
socfpga_clk = kzalloc(sizeof(*socfpga_clk), GFP_KERNEL);
if (WARN_ON(!socfpga_clk))
@@ -238,12 +239,14 @@ void __init socfpga_gate_init(struct device_node *node)
init.parent_names = parent_name;
socfpga_clk->hw.hw.init = 
 
-   clk = clk_register(NULL, _clk->hw.hw);
-   if (WARN_ON(IS_ERR(clk))) {
+   hw_clk = _clk->hw.hw;
+
+   err = clk_hw_register(NULL, hw_clk);
+   if (err) {
kfree(socfpga_clk);
return;
}
-   rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   rc = of_clk_add_provider(node, of_clk_src_simple_get, hw_clk);
if (WARN_ON(rc))
return;
 }
diff --git a/drivers/clk/socfpga/clk-periph.c b/drivers/clk/socfpga/clk-periph.c
index 5e0c4b45f77f..43707e2d7248 100644
--- a/drivers/clk/socfpga/clk-periph.c
+++ b/drivers/clk/socfpga/clk-periph.c
@@ -51,7 +51,7 @@ static __init void __socfpga_periph_init(struct device_node 
*node,
const struct clk_ops *ops)
 {
u32 reg;
-   struct clk *clk;
+   struct clk_hw *hw_clk;
struct socfpga_periph_clk *periph_clk;
const char *clk_name = node->name;
const char *parent_name[SOCFPGA_MAX_PARENTS];
@@ -94,13 +94,13 @@ static __init void __socfpga_periph_init(struct device_node 
*node,
init.parent_names = parent_name;
 
periph_clk->hw.hw.init = 
+   hw_clk = _clk->hw.hw;
 
-   clk = clk_register(NULL, _clk->hw.hw);
-   if (WARN_ON(IS_ERR(clk))) {
+   if (clk_hw_register(NULL, hw_clk)) {
kfree(periph_clk);
return;
}
-   rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   rc = of_clk_add_provider(node, of_clk_src_simple_get, hw_clk);
 }
 
 void __init socfpga_periph_init(struct device_node *node)
diff --git a/drivers/clk/socfpga/clk-pll.c b/drivers/clk/socfpga/clk-pll.c
index 3cf99df7d005..dcb573d44034 100644
--- a/drivers/clk/socfpga/clk-pll.c
+++ b/drivers/clk/socfpga/clk-pll.c
@@ -70,16 +70,18 @@ static const struct clk_ops clk_pll_ops = {
.get_parent = clk_pll_get_parent,
 };
 
-static __init struct clk *__socfpga_pll_init(struct device_node *node,
+static __init struct clk_hw *__socfpga_pll_init(struct device_node *node,
const struct clk_ops *ops)
 {
u32 reg;
-   struct clk *clk;
+   struct clk_hw *hw_clk;
struct socfpga_pll *pll_clk;
const char *clk_name = node->name;
const char *parent_name[SOCFPGA_MAX_PARENTS];
struct clk_init_data init;
struct device_node *clkmgr_np;
+   int rc;
+   int err;
 
of_property_read_u32(node, "reg", );
 
@@ -105,13 +107,15 @@ static __init struct clk *__socfpga_pll_init(struct 
device_node *node,
 
pll_clk->hw.bit_idx = SOCFPGA_PLL_EXT_ENA;
 
-   clk = clk_register(NULL, _clk->hw.hw);
-   if (WARN_ON(IS_ERR(clk))) {
+   hw_clk = _clk->hw.hw;
+
+   err = clk_hw_register(NULL, hw_clk);
+   if (err) {
kfree(pll_clk);
-   return NULL;
+   return ERR_PTR(err);
}
-   of_clk_add_provider(node, of_clk_src_simple_get, clk);
-   return clk;
+   rc = of_clk_add_provider(node, of_clk_src_simple_get, hw_clk);
+   return hw_clk;
 }
 
 void __init socfpga_pll_init(struct device_node *node)
-- 
2.30.0

[PATCH 2/3] clk: socfpga: arria10: convert to use clk_hw

[Dinh Nguyen]

As recommended by Stephen Boyd, convert the Arria10 clock driver to use
the clk_hw registration method.

Suggested-by: Stephen Boyd 
Signed-off-by: Dinh Nguyen 
---
 drivers/clk/socfpga/clk-gate-a10.c   |  8 
 drivers/clk/socfpga/clk-periph-a10.c | 11 ++-
 drivers/clk/socfpga/clk-pll-a10.c| 12 ++--
 3 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/clk/socfpga/clk-gate-a10.c 
b/drivers/clk/socfpga/clk-gate-a10.c
index cd5df9103614..f5cba8298712 100644
--- a/drivers/clk/socfpga/clk-gate-a10.c
+++ b/drivers/clk/socfpga/clk-gate-a10.c
@@ -98,7 +98,7 @@ static void __init __socfpga_gate_init(struct device_node 
*node,
u32 div_reg[3];
u32 clk_phase[2];
u32 fixed_div;
-   struct clk *clk;
+   struct clk_hw *hw_clk;
struct socfpga_gate_clk *socfpga_clk;
const char *clk_name = node->name;
const char *parent_name[SOCFPGA_MAX_PARENTS];
@@ -159,13 +159,13 @@ static void __init __socfpga_gate_init(struct device_node 
*node,
init.num_parents = of_clk_parent_fill(node, parent_name, 
SOCFPGA_MAX_PARENTS);
init.parent_names = parent_name;
socfpga_clk->hw.hw.init = 
+   hw_clk = _clk->hw.hw;
 
-   clk = clk_register(NULL, _clk->hw.hw);
-   if (WARN_ON(IS_ERR(clk))) {
+   if (clk_hw_register(NULL, hw_clk)) {
kfree(socfpga_clk);
return;
}
-   rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   rc = of_clk_add_provider(node, of_clk_src_simple_get, hw_clk);
if (WARN_ON(rc))
return;
 }
diff --git a/drivers/clk/socfpga/clk-periph-a10.c 
b/drivers/clk/socfpga/clk-periph-a10.c
index 3e0c55727b89..b9cdde4b8441 100644
--- a/drivers/clk/socfpga/clk-periph-a10.c
+++ b/drivers/clk/socfpga/clk-periph-a10.c
@@ -61,7 +61,7 @@ static __init void __socfpga_periph_init(struct device_node 
*node,
const struct clk_ops *ops)
 {
u32 reg;
-   struct clk *clk;
+   struct clk_hw *hw_clk;
struct socfpga_periph_clk *periph_clk;
const char *clk_name = node->name;
const char *parent_name[SOCFPGA_MAX_PARENTS];
@@ -104,12 +104,13 @@ static __init void __socfpga_periph_init(struct 
device_node *node,
 
periph_clk->hw.hw.init = 
 
-   clk = clk_register(NULL, _clk->hw.hw);
-   if (WARN_ON(IS_ERR(clk))) {
+   hw_clk = _clk->hw.hw;
+
+   if (clk_hw_register(NULL, hw_clk)) {
kfree(periph_clk);
return;
}
-   rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   rc = of_clk_add_provider(node, of_clk_src_simple_get, hw_clk);
if (rc < 0) {
pr_err("Could not register clock provider for node:%s\n",
   clk_name);
@@ -119,7 +120,7 @@ static __init void __socfpga_periph_init(struct device_node 
*node,
return;
 
 err_clk:
-   clk_unregister(clk);
+   clk_hw_unregister(hw_clk);
 }
 
 void __init socfpga_a10_periph_init(struct device_node *node)
diff --git a/drivers/clk/socfpga/clk-pll-a10.c 
b/drivers/clk/socfpga/clk-pll-a10.c
index 3338f054fe98..bee0f7da5b6e 100644
--- a/drivers/clk/socfpga/clk-pll-a10.c
+++ b/drivers/clk/socfpga/clk-pll-a10.c
@@ -63,11 +63,11 @@ static const struct clk_ops clk_pll_ops = {
.get_parent = clk_pll_get_parent,
 };
 
-static struct clk * __init __socfpga_pll_init(struct device_node *node,
+static struct clk_hw * __init __socfpga_pll_init(struct device_node *node,
const struct clk_ops *ops)
 {
u32 reg;
-   struct clk *clk;
+   struct clk_hw *hw_clk;
struct socfpga_pll *pll_clk;
const char *clk_name = node->name;
const char *parent_name[SOCFGPA_MAX_PARENTS];
@@ -101,14 +101,14 @@ static struct clk * __init __socfpga_pll_init(struct 
device_node *node,
pll_clk->hw.hw.init = 
 
pll_clk->hw.bit_idx = SOCFPGA_PLL_EXT_ENA;
+   hw_clk = _clk->hw.hw;
 
-   clk = clk_register(NULL, _clk->hw.hw);
-   if (WARN_ON(IS_ERR(clk))) {
+   if (clk_hw_register(NULL, hw_clk)) {
kfree(pll_clk);
return NULL;
}
-   of_clk_add_provider(node, of_clk_src_simple_get, clk);
-   return clk;
+   of_clk_add_provider(node, of_clk_src_simple_get, hw_clk);
+   return hw_clk;
 }
 
 void __init socfpga_a10_pll_init(struct device_node *node)
-- 
2.30.0

[PATCH v3 09/10] clocksource/drivers/hyper-v: Set clocksource rating based on Hyper-V feature

[Michael Kelley]

On x86/x64, the TSC clocksource is available in a Hyper-V VM only if
Hyper-V provides the TSC_INVARIANT flag. The rating on the Hyper-V
Reference TSC page clocksource is currently set so that it will not
override the TSC clocksource in this case.  Alternatively, if the TSC
clocksource is not available, then the Hyper-V clocksource is used.

But on ARM64, the Hyper-V Reference TSC page clocksource should
override the ARM arch counter, since the Hyper-V clocksource provides
scaling and offsetting during live migrations that is not provided
for the ARM arch counter.

To get the needed behavior for both x86/x64 and ARM64, tweak the
logic by defaulting the Hyper-V Reference TSC page clocksource
rating to a large value that will always override.  If the Hyper-V
TSC_INVARIANT flag is set, then reduce the rating so that it will not
override the TSC.

While the logic for getting there is slightly different, the net
result in the normal cases is no functional change.

Signed-off-by: Michael Kelley 
Acked-by: Daniel Lezcano 
---
 drivers/clocksource/hyperv_timer.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/clocksource/hyperv_timer.c 
b/drivers/clocksource/hyperv_timer.c
index 10eb5c6..7a9030c 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -302,14 +302,6 @@ void hv_stimer_global_cleanup(void)
  * the other that uses the TSC reference page feature as defined in the
  * TLFS.  The MSR version is for compatibility with old versions of
  * Hyper-V and 32-bit x86.  The TSC reference page version is preferred.
- *
- * The Hyper-V clocksource ratings of 250 are chosen to be below the
- * TSC clocksource rating of 300.  In configurations where Hyper-V offers
- * an InvariantTSC, the TSC is not marked "unstable", so the TSC clocksource
- * is available and preferred.  With the higher rating, it will be the
- * default.  On older hardware and Hyper-V versions, the TSC is marked
- * "unstable", so no TSC clocksource is created and the selected Hyper-V
- * clocksource will be the default.
  */
 
 u64 (*hv_read_reference_counter)(void);
@@ -380,7 +372,7 @@ static int hv_cs_enable(struct clocksource *cs)
 
 static struct clocksource hyperv_cs_tsc = {
.name   = "hyperv_clocksource_tsc_page",
-   .rating = 250,
+   .rating = 500,
.read   = read_hv_clock_tsc_cs,
.mask   = CLOCKSOURCE_MASK(64),
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
@@ -417,7 +409,7 @@ static u64 notrace read_hv_sched_clock_msr(void)
 
 static struct clocksource hyperv_cs_msr = {
.name   = "hyperv_clocksource_msr",
-   .rating = 250,
+   .rating = 500,
.read   = read_hv_clock_msr_cs,
.mask   = CLOCKSOURCE_MASK(64),
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
@@ -458,6 +450,17 @@ static bool __init hv_init_tsc_clocksource(void)
if (hv_root_partition)
return false;
 
+   /*
+* If Hyper-V offers TSC_INVARIANT, then the virtualized TSC correctly
+* handles frequency and offset changes due to live migration,
+* pause/resume, and other VM management operations.  So lower the
+* Hyper-V Reference TSC rating, causing the generic TSC to be used.
+* TSC_INVARIANT is not offered on ARM64, so the Hyper-V Reference
+* TSC will be preferred over the virtualized ARM64 arch counter.
+*/
+   if (ms_hyperv.features & HV_ACCESS_TSC_INVARIANT)
+   hyperv_cs_tsc.rating = 250;
+
hv_read_reference_counter = read_hv_clock_tsc;
phys_addr = virt_to_phys(hv_get_tsc_page());
 
-- 
1.8.3.1

[PATCH v3 10/10] clocksource/drivers/hyper-v: Move handling of STIMER0 interrupts

[Michael Kelley]

STIMER0 interrupts are most naturally modeled as per-cpu IRQs. But
because x86/x64 doesn't have per-cpu IRQs, the core STIMER0 interrupt
handling machinery is done in code under arch/x86 and Linux IRQs are
not used. Adding support for ARM64 means adding equivalent code
using per-cpu IRQs under arch/arm64.

A better model is to treat per-cpu IRQs as the normal path (which it is
for modern architectures), and the x86/x64 path as the exception. Do this
by incorporating standard Linux per-cpu IRQ allocation into the main
SITMER0 driver code, and bypass it in the x86/x64 exception case. For
x86/x64, special case code is retained under arch/x86, but no STIMER0
interrupt handling code is needed under arch/arm64.

No functional change.

Signed-off-by: Michael Kelley 
---
 arch/x86/hyperv/hv_init.c  |   2 +-
 arch/x86/include/asm/mshyperv.h|   4 -
 arch/x86/kernel/cpu/mshyperv.c |  10 +--
 drivers/clocksource/hyperv_timer.c | 168 +
 include/asm-generic/mshyperv.h |   5 --
 include/clocksource/hyperv_timer.h |   3 +-
 6 files changed, 120 insertions(+), 72 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 9af4f8a..9d10025 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -327,7 +327,7 @@ static void __init hv_stimer_setup_percpu_clockev(void)
 * Ignore any errors in setting up stimer clockevents
 * as we can run with the LAPIC timer as a fallback.
 */
-   (void)hv_stimer_alloc();
+   (void)hv_stimer_alloc(false);
 
/*
 * Still register the LAPIC timer, because the direct-mode STIMER is
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 5433312..6d4891b 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -31,10 +31,6 @@ static inline u64 hv_get_register(unsigned int reg)
 
 void hyperv_vector_handler(struct pt_regs *regs);
 
-static inline void hv_enable_stimer0_percpu_irq(int irq) {}
-static inline void hv_disable_stimer0_percpu_irq(int irq) {}
-
-
 #if IS_ENABLED(CONFIG_HYPERV)
 extern int hyperv_init_cpuhp;
 
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 41fd84a..cebed53 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -90,21 +90,17 @@ void hv_remove_vmbus_handler(void)
set_irq_regs(old_regs);
 }
 
-int hv_setup_stimer0_irq(int *irq, int *vector, void (*handler)(void))
+/* For x86/x64, override weak placeholders in hyperv_timer.c */
+void hv_setup_stimer0_handler(void (*handler)(void))
 {
-   *vector = HYPERV_STIMER0_VECTOR;
-   *irq = -1;   /* Unused on x86/x64 */
hv_stimer0_handler = handler;
-   return 0;
 }
-EXPORT_SYMBOL_GPL(hv_setup_stimer0_irq);
 
-void hv_remove_stimer0_irq(int irq)
+void hv_remove_stimer0_handler(void)
 {
/* We have no way to deallocate the interrupt gate */
hv_stimer0_handler = NULL;
 }
-EXPORT_SYMBOL_GPL(hv_remove_stimer0_irq);
 
 void hv_setup_kexec_handler(void (*handler)(void))
 {
diff --git a/drivers/clocksource/hyperv_timer.c 
b/drivers/clocksource/hyperv_timer.c
index 7a9030c..ce94f78 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -18,6 +18,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -43,14 +46,13 @@
  */
 static bool direct_mode_enabled;
 
-static int stimer0_irq;
-static int stimer0_vector;
+static int stimer0_irq = -1;
 static int stimer0_message_sint;
+static DEFINE_PER_CPU(long, stimer0_evt);
 
 /*
- * ISR for when stimer0 is operating in Direct Mode.  Direct Mode
- * does not use VMbus or any VMbus messages, so process here and not
- * in the VMbus driver code.
+ * Common code for stimer0 interrupts coming via Direct Mode or
+ * as a VMbus message.
  */
 void hv_stimer0_isr(void)
 {
@@ -61,6 +63,16 @@ void hv_stimer0_isr(void)
 }
 EXPORT_SYMBOL_GPL(hv_stimer0_isr);
 
+/*
+ * stimer0 interrupt handler for architectures that support
+ * per-cpu interrupts, which also implies Direct Mode.
+ */
+static irqreturn_t hv_stimer0_percpu_isr(int irq, void *dev_id)
+{
+   hv_stimer0_isr();
+   return IRQ_HANDLED;
+}
+
 static int hv_ce_set_next_event(unsigned long delta,
struct clock_event_device *evt)
 {
@@ -76,8 +88,8 @@ static int hv_ce_shutdown(struct clock_event_device *evt)
 {
hv_set_register(HV_REGISTER_STIMER0_COUNT, 0);
hv_set_register(HV_REGISTER_STIMER0_CONFIG, 0);
-   if (direct_mode_enabled)
-   hv_disable_stimer0_percpu_irq(stimer0_irq);
+   if (direct_mode_enabled && stimer0_irq >= 0)
+   disable_percpu_irq(stimer0_irq);
 
return 0;
 }
@@ -95,8 +107,9 @@ static int hv_ce_set_oneshot(struct clock_event_device *evt)
 * on the specified hardware vector/IRQ.
 */
timer_cfg.direct_mode 

[PATCH v3 04/10] Drivers: hv: vmbus: Move hyperv_report_panic_msg to arch neutral code

[Michael Kelley]

With the new Hyper-V MSR set function, hyperv_report_panic_msg() can be
architecture neutral, so move it out from under arch/x86 and merge into
hv_kmsg_dump(). This move also avoids needing a separate implementation
under arch/arm64.

No functional change.

Signed-off-by: Michael Kelley 
Reviewed-by: Boqun Feng 
---
 arch/x86/hyperv/hv_init.c  | 27 ---
 drivers/hv/vmbus_drv.c | 24 +++-
 include/asm-generic/mshyperv.h |  1 -
 3 files changed, 19 insertions(+), 33 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 94d52c5..9af4f8a 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -571,33 +571,6 @@ void hyperv_report_panic(struct pt_regs *regs, long err, 
bool in_die)
 }
 EXPORT_SYMBOL_GPL(hyperv_report_panic);
 
-/**
- * hyperv_report_panic_msg - report panic message to Hyper-V
- * @pa: physical address of the panic page containing the message
- * @size: size of the message in the page
- */
-void hyperv_report_panic_msg(phys_addr_t pa, size_t size)
-{
-   /*
-* P3 to contain the physical address of the panic page & P4 to
-* contain the size of the panic data in that page. Rest of the
-* registers are no-op when the NOTIFY_MSG flag is set.
-*/
-   wrmsrl(HV_X64_MSR_CRASH_P0, 0);
-   wrmsrl(HV_X64_MSR_CRASH_P1, 0);
-   wrmsrl(HV_X64_MSR_CRASH_P2, 0);
-   wrmsrl(HV_X64_MSR_CRASH_P3, pa);
-   wrmsrl(HV_X64_MSR_CRASH_P4, size);
-
-   /*
-* Let Hyper-V know there is crash data available along with
-* the panic message.
-*/
-   wrmsrl(HV_X64_MSR_CRASH_CTL,
-  (HV_CRASH_CTL_CRASH_NOTIFY | HV_CRASH_CTL_CRASH_NOTIFY_MSG));
-}
-EXPORT_SYMBOL_GPL(hyperv_report_panic_msg);
-
 bool hv_is_hyperv_initialized(void)
 {
union hv_x64_msr_hypercall_contents hypercall_msr;
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 9e63170..7524d71 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1392,22 +1392,36 @@ static void hv_kmsg_dump(struct kmsg_dumper *dumper,
 enum kmsg_dump_reason reason)
 {
size_t bytes_written;
-   phys_addr_t panic_pa;
 
/* We are only interested in panics. */
if ((reason != KMSG_DUMP_PANIC) || (!sysctl_record_panic_msg))
return;
 
-   panic_pa = virt_to_phys(hv_panic_page);
-
/*
 * Write dump contents to the page. No need to synchronize; panic should
 * be single-threaded.
 */
kmsg_dump_get_buffer(dumper, false, hv_panic_page, HV_HYP_PAGE_SIZE,
 _written);
-   if (bytes_written)
-   hyperv_report_panic_msg(panic_pa, bytes_written);
+   if (!bytes_written)
+   return;
+   /*
+* P3 to contain the physical address of the panic page & P4 to
+* contain the size of the panic data in that page. Rest of the
+* registers are no-op when the NOTIFY_MSG flag is set.
+*/
+   hv_set_register(HV_REGISTER_CRASH_P0, 0);
+   hv_set_register(HV_REGISTER_CRASH_P1, 0);
+   hv_set_register(HV_REGISTER_CRASH_P2, 0);
+   hv_set_register(HV_REGISTER_CRASH_P3, virt_to_phys(hv_panic_page));
+   hv_set_register(HV_REGISTER_CRASH_P4, bytes_written);
+
+   /*
+* Let Hyper-V know there is crash data available along with
+* the panic message.
+*/
+   hv_set_register(HV_REGISTER_CRASH_CTL,
+  (HV_CRASH_CTL_CRASH_NOTIFY | HV_CRASH_CTL_CRASH_NOTIFY_MSG));
 }
 
 static struct kmsg_dumper hv_kmsg_dumper = {
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index 163d8b0..70b798d 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -173,7 +173,6 @@ static inline int cpumask_to_vpset(struct hv_vpset *vpset,
 }
 
 void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die);
-void hyperv_report_panic_msg(phys_addr_t pa, size_t size);
 bool hv_is_hyperv_initialized(void);
 bool hv_is_hibernation_supported(void);
 enum hv_isolation_type hv_get_isolation_type(void);
-- 
1.8.3.1

[PATCH v3 01/10] Drivers: hv: vmbus: Move Hyper-V page allocator to arch neutral code

[Michael Kelley]

The Hyper-V page allocator functions are implemented in an architecture
neutral way.  Move them into the architecture neutral VMbus module so
a separate implementation for ARM64 is not needed.

No functional change.

Signed-off-by: Michael Kelley 
Reviewed-by: Boqun Feng 
---
 arch/x86/hyperv/hv_init.c   | 22 --
 arch/x86/include/asm/mshyperv.h |  5 -
 drivers/hv/hv.c | 36 
 include/asm-generic/mshyperv.h  |  4 
 4 files changed, 40 insertions(+), 27 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index b81047d..4bdb344 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -54,28 +54,6 @@
 u32 hv_max_vp_index;
 EXPORT_SYMBOL_GPL(hv_max_vp_index);
 
-void *hv_alloc_hyperv_page(void)
-{
-   BUILD_BUG_ON(PAGE_SIZE != HV_HYP_PAGE_SIZE);
-
-   return (void *)__get_free_page(GFP_KERNEL);
-}
-EXPORT_SYMBOL_GPL(hv_alloc_hyperv_page);
-
-void *hv_alloc_hyperv_zeroed_page(void)
-{
-BUILD_BUG_ON(PAGE_SIZE != HV_HYP_PAGE_SIZE);
-
-return (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
-}
-EXPORT_SYMBOL_GPL(hv_alloc_hyperv_zeroed_page);
-
-void hv_free_hyperv_page(unsigned long addr)
-{
-   free_page(addr);
-}
-EXPORT_SYMBOL_GPL(hv_free_hyperv_page);
-
 static int hv_cpu_init(unsigned int cpu)
 {
u64 msr_vp_index;
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index ccf60a8..ef6e968 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -233,9 +233,6 @@ static inline struct hv_vp_assist_page 
*hv_get_vp_assist_page(unsigned int cpu)
 
 void __init hyperv_init(void);
 void hyperv_setup_mmu_ops(void);
-void *hv_alloc_hyperv_page(void);
-void *hv_alloc_hyperv_zeroed_page(void);
-void hv_free_hyperv_page(unsigned long addr);
 void set_hv_tscchange_cb(void (*cb)(void));
 void clear_hv_tscchange_cb(void);
 void hyperv_stop_tsc_emulation(void);
@@ -272,8 +269,6 @@ int hv_map_ioapic_interrupt(int ioapic_id, bool level, int 
vcpu, int vector,
 #else /* CONFIG_HYPERV */
 static inline void hyperv_init(void) {}
 static inline void hyperv_setup_mmu_ops(void) {}
-static inline void *hv_alloc_hyperv_page(void) { return NULL; }
-static inline void hv_free_hyperv_page(unsigned long addr) {}
 static inline void set_hv_tscchange_cb(void (*cb)(void)) {}
 static inline void clear_hv_tscchange_cb(void) {}
 static inline void hyperv_stop_tsc_emulation(void) {};
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index f202ac7..cca8d5e 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -37,6 +37,42 @@ int hv_init(void)
 }
 
 /*
+ * Functions for allocating and freeing memory with size and
+ * alignment HV_HYP_PAGE_SIZE. These functions are needed because
+ * the guest page size may not be the same as the Hyper-V page
+ * size. We depend upon kmalloc() aligning power-of-two size
+ * allocations to the allocation size boundary, so that the
+ * allocated memory appears to Hyper-V as a page of the size
+ * it expects.
+ */
+
+void *hv_alloc_hyperv_page(void)
+{
+   BUILD_BUG_ON(PAGE_SIZE <  HV_HYP_PAGE_SIZE);
+
+   if (PAGE_SIZE == HV_HYP_PAGE_SIZE)
+   return (void *)__get_free_page(GFP_KERNEL);
+   else
+   return kmalloc(HV_HYP_PAGE_SIZE, GFP_KERNEL);
+}
+
+void *hv_alloc_hyperv_zeroed_page(void)
+{
+   if (PAGE_SIZE == HV_HYP_PAGE_SIZE)
+   return (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
+   else
+   return kzalloc(HV_HYP_PAGE_SIZE, GFP_KERNEL);
+}
+
+void hv_free_hyperv_page(unsigned long addr)
+{
+   if (PAGE_SIZE == HV_HYP_PAGE_SIZE)
+   free_page(addr);
+   else
+   kfree((void *)addr);
+}
+
+/*
  * hv_post_message - Post a message using the hypervisor message IPC.
  *
  * This involves a hypercall.
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index dff58a3..694b5bc 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -117,6 +117,10 @@ static inline void vmbus_signal_eom(struct hv_message 
*msg, u32 old_msg_type)
 /* Sentinel value for an uninitialized entry in hv_vp_index array */
 #define VP_INVAL   U32_MAX
 
+void *hv_alloc_hyperv_page(void);
+void *hv_alloc_hyperv_zeroed_page(void);
+void hv_free_hyperv_page(unsigned long addr);
+
 /**
  * hv_cpu_number_to_vp_number() - Map CPU to VP.
  * @cpu_number: CPU number in Linux terms
-- 
1.8.3.1

[PATCH v3 07/10] clocksource/drivers/hyper-v: Handle vDSO differences inline

[Michael Kelley]

While the driver for the Hyper-V Reference TSC and STIMERs is architecture
neutral, vDSO is implemented for x86/x64, but not for ARM64.  Current code
calls into utility functions under arch/x86 (and coming, under arch/arm64)
to handle the difference.

Change this approach to handle the difference inline based on whether
VDSO_CLOCK_MODE_HVCLOCK is present.  The new approach removes code under
arch/* since the difference is tied more to the specifics of the Linux
implementation than to the architecture.

No functional change.

Signed-off-by: Michael Kelley 
Reviewed-by: Boqun Feng 
---
 arch/x86/include/asm/mshyperv.h|  4 
 drivers/clocksource/hyperv_timer.c | 10 --
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index c10dd1c..4f566db 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -27,10 +27,6 @@ static inline u64 hv_get_register(unsigned int reg)
return value;
 }
 
-#define hv_set_clocksource_vdso(val) \
-   ((val).vdso_clock_mode = VDSO_CLOCKMODE_HVCLOCK)
-#define hv_enable_vdso_clocksource() \
-   vclocks_set_used(VDSO_CLOCKMODE_HVCLOCK);
 #define hv_get_raw_timer() rdtsc_ordered()
 
 /*
diff --git a/drivers/clocksource/hyperv_timer.c 
b/drivers/clocksource/hyperv_timer.c
index c73c127..06984fa 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -370,11 +370,13 @@ static void resume_hv_clock_tsc(struct clocksource *arg)
hv_set_register(HV_REGISTER_REFERENCE_TSC, tsc_msr);
 }
 
+#ifdef VDSO_CLOCKMODE_HVCLOCK
 static int hv_cs_enable(struct clocksource *cs)
 {
-   hv_enable_vdso_clocksource();
+   vclocks_set_used(VDSO_CLOCKMODE_HVCLOCK);
return 0;
 }
+#endif
 
 static struct clocksource hyperv_cs_tsc = {
.name   = "hyperv_clocksource_tsc_page",
@@ -384,7 +386,12 @@ static int hv_cs_enable(struct clocksource *cs)
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
.suspend= suspend_hv_clock_tsc,
.resume = resume_hv_clock_tsc,
+#ifdef VDSO_CLOCKMODE_HVCLOCK
.enable = hv_cs_enable,
+   .vdso_clock_mode = VDSO_CLOCKMODE_HVCLOCK,
+#else
+   .vdso_clock_mode = VDSO_CLOCKMODE_NONE,
+#endif
 };
 
 static u64 notrace read_hv_clock_msr(void)
@@ -442,7 +449,6 @@ static bool __init hv_init_tsc_clocksource(void)
tsc_msr = tsc_msr | 0x1 | (u64)phys_addr;
hv_set_register(HV_REGISTER_REFERENCE_TSC, tsc_msr);
 
-   hv_set_clocksource_vdso(hyperv_cs_tsc);
clocksource_register_hz(_cs_tsc, NSEC_PER_SEC/100);
 
hv_sched_clock_offset = hv_read_reference_counter();
-- 
1.8.3.1

[PATCH v3 05/10] Drivers: hv: vmbus: Handle auto EOI quirk inline

[Michael Kelley]

On x86/x64, Hyper-V provides a flag to indicate auto EOI functionality,
but it doesn't on ARM64. Handle this quirk inline instead of calling
into code under arch/x86 (and coming, under arch/arm64).

No functional change.

Signed-off-by: Michael Kelley 
Reviewed-by: Boqun Feng 
---
 arch/x86/include/asm/mshyperv.h |  3 ---
 drivers/hv/hv.c | 12 +++-
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 2590ce5..a6c608d 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -27,9 +27,6 @@ static inline u64 hv_get_register(unsigned int reg)
return value;
 }
 
-#define hv_recommend_using_aeoi() \
-   (!(ms_hyperv.hints & HV_DEPRECATING_AEOI_RECOMMENDED))
-
 #define hv_set_clocksource_vdso(val) \
((val).vdso_clock_mode = VDSO_CLOCKMODE_HVCLOCK)
 #define hv_enable_vdso_clocksource() \
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 0c1fa69..afe7a62 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -219,7 +219,17 @@ void hv_synic_enable_regs(unsigned int cpu)
 
shared_sint.vector = hv_get_vector();
shared_sint.masked = false;
-   shared_sint.auto_eoi = hv_recommend_using_aeoi();
+
+   /*
+* On architectures where Hyper-V doesn't support AEOI (e.g., ARM64),
+* it doesn't provide a recommendation flag and AEOI must be disabled.
+*/
+#ifdef HV_DEPRECATING_AEOI_RECOMMENDED
+   shared_sint.auto_eoi =
+   !(ms_hyperv.hints & HV_DEPRECATING_AEOI_RECOMMENDED);
+#else
+   shared_sint.auto_eoi = 0;
+#endif
hv_set_register(HV_REGISTER_SINT0 + VMBUS_MESSAGE_SINT,
shared_sint.as_uint64);
 
-- 
1.8.3.1

[PATCH v3 06/10] Drivers: hv: vmbus: Move handling of VMbus interrupts

[Michael Kelley]

VMbus interrupts are most naturally modelled as per-cpu IRQs.  But
because x86/x64 doesn't have per-cpu IRQs, the core VMbus interrupt
handling machinery is done in code under arch/x86 and Linux IRQs are
not used.  Adding support for ARM64 means adding equivalent code
using per-cpu IRQs under arch/arm64.

A better model is to treat per-cpu IRQs as the normal path (which it is
for modern architectures), and the x86/x64 path as the exception.  Do this
by incorporating standard Linux per-cpu IRQ allocation into the main VMbus
driver, and bypassing it in the x86/x64 exception case. For x86/x64,
special case code is retained under arch/x86, but no VMbus interrupt
handling code is needed under arch/arm64.

No functional change.

Signed-off-by: Michael Kelley 
Reviewed-by: Boqun Feng 
---
 arch/x86/include/asm/mshyperv.h |  1 -
 arch/x86/kernel/cpu/mshyperv.c  | 13 +++--
 drivers/hv/hv.c |  8 +-
 drivers/hv/vmbus_drv.c  | 63 -
 include/asm-generic/mshyperv.h  |  7 ++---
 5 files changed, 70 insertions(+), 22 deletions(-)

diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index a6c608d..c10dd1c 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -32,7 +32,6 @@ static inline u64 hv_get_register(unsigned int reg)
 #define hv_enable_vdso_clocksource() \
vclocks_set_used(VDSO_CLOCKMODE_HVCLOCK);
 #define hv_get_raw_timer() rdtsc_ordered()
-#define hv_get_vector() HYPERVISOR_CALLBACK_VECTOR
 
 /*
  * Reference to pv_ops must be inline so objtool
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index e88bc29..41fd84a 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -60,23 +60,18 @@
set_irq_regs(old_regs);
 }
 
-int hv_setup_vmbus_irq(int irq, void (*handler)(void))
+void hv_setup_vmbus_handler(void (*handler)(void))
 {
-   /*
-* The 'irq' argument is ignored on x86/x64 because a hard-coded
-* interrupt vector is used for Hyper-V interrupts.
-*/
vmbus_handler = handler;
-   return 0;
 }
+EXPORT_SYMBOL_GPL(hv_setup_vmbus_handler);
 
-void hv_remove_vmbus_irq(void)
+void hv_remove_vmbus_handler(void)
 {
/* We have no way to deallocate the interrupt gate */
vmbus_handler = NULL;
 }
-EXPORT_SYMBOL_GPL(hv_setup_vmbus_irq);
-EXPORT_SYMBOL_GPL(hv_remove_vmbus_irq);
+EXPORT_SYMBOL_GPL(hv_remove_vmbus_handler);
 
 /*
  * Routines to do per-architecture handling of stimer0
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index afe7a62..917b29e 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "hyperv_vmbus.h"
@@ -214,10 +215,12 @@ void hv_synic_enable_regs(unsigned int cpu)
hv_set_register(HV_REGISTER_SIEFP, siefp.as_uint64);
 
/* Setup the shared SINT. */
+   if (vmbus_irq != -1)
+   enable_percpu_irq(vmbus_irq, 0);
shared_sint.as_uint64 = hv_get_register(HV_REGISTER_SINT0 +
VMBUS_MESSAGE_SINT);
 
-   shared_sint.vector = hv_get_vector();
+   shared_sint.vector = vmbus_interrupt;
shared_sint.masked = false;
 
/*
@@ -285,6 +288,9 @@ void hv_synic_disable_regs(unsigned int cpu)
sctrl.as_uint64 = hv_get_register(HV_REGISTER_SCONTROL);
sctrl.enable = 0;
hv_set_register(HV_REGISTER_SCONTROL, sctrl.as_uint64);
+
+   if (vmbus_irq != -1)
+   disable_percpu_irq(vmbus_irq);
 }
 
 
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 7524d71..51c40d5 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -48,8 +48,10 @@ struct vmbus_dynid {
 
 static void *hv_panic_page;
 
+static long __percpu *vmbus_evt;
+
 /* Values parsed from ACPI DSDT */
-static int vmbus_irq;
+int vmbus_irq;
 int vmbus_interrupt;
 
 /*
@@ -1381,7 +1383,13 @@ static void vmbus_isr(void)
tasklet_schedule(_cpu->msg_dpc);
}
 
-   add_interrupt_randomness(hv_get_vector(), 0);
+   add_interrupt_randomness(vmbus_interrupt, 0);
+}
+
+static irqreturn_t vmbus_percpu_isr(int irq, void *dev_id)
+{
+   vmbus_isr();
+   return IRQ_HANDLED;
 }
 
 /*
@@ -1496,9 +1504,28 @@ static int vmbus_bus_init(void)
if (ret)
return ret;
 
-   ret = hv_setup_vmbus_irq(vmbus_irq, vmbus_isr);
-   if (ret)
-   goto err_setup;
+   /*
+* VMbus interrupts are best modeled as per-cpu interrupts. If
+* on an architecture with support for per-cpu IRQs (e.g. ARM64),
+* allocate a per-cpu IRQ using standard Linux kernel functionality.
+* If not on such an architecture (e.g., x86/x64), then rely on
+* code in the arch-specific portion of the code tree to connect
+* the VMbus interrupt handler.
+*/
+
+   if (vmbus_irq == -1) {
+ 

[PATCH v3 00/10] Refactor arch specific Hyper-V code

[Michael Kelley]

To support Linux guests on Hyper-V on multiple architectures, the original
approach factored out all differences between Hyper-V on x86/x64 and
Hyper-V on ARM64 into functions or #defines under arch/x86 and
arch/arm64. Some of these differences are truly related to the
architecture, but others are more properly treated as Linux OS
differences or just quirks in Hyper-V. Feedback from Arnd Bergmann[1]
recommended that differences other than architecture should be
incorporated into the architecture independent Hyper-V code. Each
difference can be handled with conditions specific to the difference
instead of tying it to the broader x86/x64 vs. ARM64. This approach
reduces the amount of code under arch/x86 and arch/arm64 and keeps
the non-architectural differences localized and more easily understood.

This patch set implements the new approach by changing the interface
between the architecture independent code and the architecture dependent
code for x86/x64. The patches move code from arch/x86 to the
architecture independent Hyper-V code whenever possible, and add
architecture independent support needed by other architectures like
ARM64.  No functionality is changed for x86/x64.  A subsequent patch
set will provide the Hyper-V support code under arch/arm64.

This patch set results in an increase in lines of code (though some
of the increase is additional comments).  But the lines needed under
arch/arm64 in the upcoming patch set is significantly reduced, resulting
in a net decrease of about 125 lines.

[1] 
https://lore.kernel.org/lkml/CAK8P3a1hDBVembCd+6=ENUWYFz=72jbtfmrkyz2afd+_q04...@mail.gmail.com/

Change in v3:
  * In patch 7/10, tweak the #ifdefs [Daniel Lezcano]
  * In patch 8/10, tweak the #ifdefs to be around entire functions
[Daniel Lezcano]
  * In patch 10/10, use DEFINE_PER_CPU for stimer0_evt instead of
dynamically allocating per-cpu memory [Daniel Lezcano]

Changes in v2:
  * In patch 9/10, for consistency change the rating on hyperv_cs_msr
along with the rating on hyperv_cs_tsc [Boqun Feng]
  * In patch 10/10, add missing call to hv_remove_stimer0_handler()
[Boqun Feng]
  * In patch 10/10, add clarifying comment that hv_setup_stimer0_irq()
is not used on x86/x64 [Wei Liu]

Michael Kelley (10):
  Drivers: hv: vmbus: Move Hyper-V page allocator to arch neutral code
  x86/hyper-v: Move hv_message_type to architecture neutral module
  Drivers: hv: Redo Hyper-V synthetic MSR get/set functions
  Drivers: hv: vmbus: Move hyperv_report_panic_msg to arch neutral code
  Drivers: hv: vmbus: Handle auto EOI quirk inline
  Drivers: hv: vmbus: Move handling of VMbus interrupts
  clocksource/drivers/hyper-v: Handle vDSO differences inline
  clocksource/drivers/hyper-v: Handle sched_clock differences inline
  clocksource/drivers/hyper-v: Set clocksource rating based on Hyper-V
feature
  clocksource/drivers/hyper-v: Move handling of STIMER0 interrupts

 arch/x86/hyperv/hv_init.c  |  53 +---
 arch/x86/include/asm/hyperv-tlfs.h | 131 ++-
 arch/x86/include/asm/mshyperv.h|  67 ++
 arch/x86/kernel/cpu/mshyperv.c |  23 ++--
 drivers/clocksource/hyperv_timer.c | 249 +
 drivers/hv/hv.c|  93 +++---
 drivers/hv/vmbus_drv.c |  89 +++--
 include/asm-generic/hyperv-tlfs.h  |  35 ++
 include/asm-generic/mshyperv.h |  19 ++-
 include/clocksource/hyperv_timer.h |   3 +-
 10 files changed, 449 insertions(+), 313 deletions(-)

-- 
1.8.3.1

Re: [PATCH 5.10 000/657] 5.10.20-rc4 review

[Pavel Machek]

Hi!

> This is the start of the stable review cycle for the 5.10.20 release.
> There are 657 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.

CIP testing did not find any problems here (failures are caused by
unavailable board).

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

Tested-by: Pavel Machek (CIP) 

Best regards,
Pavel



-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: Digital signature

Re: [PATCH 4.4 00/92] 4.4.259-rc2 review

[Pavel Machek]

Hi!

> This is the start of the stable review cycle for the 4.4.259 release.
> There are 92 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.4.y

Tested-by: Pavel Machek (CIP) 

Best regards,
Pavel



-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: Digital signature

Re: [PATCH 4.19 000/246] 4.19.178-rc4 review

[Pavel Machek]

Hi!

> This is the start of the stable review cycle for the 4.19.178 release.
> There are 246 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.y

Tested-by: Pavel Machek (CIP) 

Best regards,
Pavel



-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: Digital signature

Re: [PATCH] firewire: prevent integer overflow on 32bit systems

[Stefan Richter]

On Mar 02 Dan Carpenter wrote:
> In TCODE_STREAM_DATA mode, on 32bit systems, the "sizeof(*e) +
> request->length" operation can overflow leading to memory corruption.
> 
> Fixes: 18e9b10fcdc0 ("firewire: cdev: add closure to async stream ioctl")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/firewire/core-cdev.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/firewire/core-cdev.c b/drivers/firewire/core-cdev.c
> index fb6c651214f3..314de0384035 100644
> --- a/drivers/firewire/core-cdev.c
> +++ b/drivers/firewire/core-cdev.c
> @@ -587,6 +587,9 @@ static int init_request(struct client *client,
>   request->length < 4)
>   return -EINVAL;
>  
> + if (request->length > ULONG_MAX - sizeof(*e))
> + return -EINVAL;
> +
>   e = kmalloc(sizeof(*e) + request->length, GFP_KERNEL);
>   if (e == NULL)
>   return -ENOMEM;

There is already a length check for asynchronous stream requests.
It happens in ioctl_send_stream_packet().
-- 
Stefan Richter
-==--=-= --== ---=-
http://arcgraph.de/sr/

Re: possible deadlock in sk_clone_lock

[Mike Kravetz]

On 3/2/21 6:29 AM, Michal Hocko wrote:
> On Tue 02-03-21 06:11:51, Shakeel Butt wrote:
>> On Tue, Mar 2, 2021 at 1:44 AM Michal Hocko  wrote:
>>>
>>> On Mon 01-03-21 17:16:29, Mike Kravetz wrote:
 On 3/1/21 9:23 AM, Michal Hocko wrote:
> On Mon 01-03-21 08:39:22, Shakeel Butt wrote:
>> On Mon, Mar 1, 2021 at 7:57 AM Michal Hocko  wrote:
> [...]
>>> Then how come this can ever be a problem? in_task() should exclude soft
>>> irq context unless I am mistaken.
>>>
>>
>> If I take the following example of syzbot's deadlock scenario then
>> CPU1 is the one freeing the hugetlb pages. It is in the process
>> context but has disabled softirqs (see __tcp_close()).
>>
>> CPU0CPU1
>> 
>>lock(hugetlb_lock);
>> local_irq_disable();
>> lock(slock-AF_INET);
>> lock(hugetlb_lock);
>>
>>  lock(slock-AF_INET);
>>
> [...]
>>> Wouldn't something like this help? It is quite ugly but it would be
>>> simple enough and backportable while we come up with a more rigorous
>>> solution. What do you think?
>>>
>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>>> index 4bdb58ab14cb..c9a8b39f678d 100644
>>> --- a/mm/hugetlb.c
>>> +++ b/mm/hugetlb.c
>>> @@ -1495,9 +1495,11 @@ static DECLARE_WORK(free_hpage_work, 
>>> free_hpage_workfn);
>>>  void free_huge_page(struct page *page)
>>>  {
>>> /*
>>> -* Defer freeing if in non-task context to avoid hugetlb_lock 
>>> deadlock.
>>> +* Defer freeing if in non-task context or when put_page is called
>>> +* with IRQ disabled (e.g from via TCP slock dependency chain) to
>>> +* avoid hugetlb_lock deadlock.
>>>  */
>>> -   if (!in_task()) {
>>> +   if (!in_task() || irqs_disabled()) {
>>
>> Does irqs_disabled() also check softirqs?
> 
> Nope it doesn't AFAICS. I was referring to the above lockdep splat which
> claims irq disabled to be the trigger. But now that you are mentioning
> that it would be better to replace in_task() along the way. We have
> discussed that in another email thread and I was suggesting to use
> in_atomic() which should catch also bh disabled situation. The big IF is
> that this needs preempt count to be enabled unconditionally. There are
> changes in the RCU tree heading that direction.

I have not been following developments in preemption and the RCU tree. 
The comment for in_atomic() says:

/*
 * Are we running in atomic context?  WARNING: this macro cannot
 * always detect atomic context; in particular, it cannot know about
 * held spinlocks in non-preemptible kernels.  Thus it should not be
 * used in the general case to determine whether sleeping is possible.
 * Do not use in_atomic() in driver code.
 */

That does seem to be the case.  I verified in_atomic can detect softirq
context even in non-preemptible kernels.  But, as the comment says it
will not detect a held spinlock in non-preemptible kernels.  So, I think
in_atomic would be better than the current check for !in_task.  That
would handle this syzbot issue, but we could still have issues if the
hugetlb put_page path is called while someone is holding a spinlock with
all interrupts enabled.  Looks like there is no way to detect this
today in non-preemptible kernels.  in_atomic does detect spinlocks held
in preemptible kernels.

I might suggest changing !in_task to in_atomic for now, and then work on
a more robust solution.  I'm afraid such a robust solution will
require considerable effort.  It would need to handle put_page being
called in any context: hardirq, softirq, spinlock held ...  The
put_page/free_huge_page path will need to offload (workqueue or
something else) any processing that can possibly sleep.

Is it worth making the in_atomic change now, or should we just start
working on the more robust complete solution?
-- 
Mike Kravetz

[PATCH v1 2/3] driver core: Update device link status properly for device_bind_driver()

[Saravana Kannan]

Device link status was not getting updated correctly when
device_bind_driver() is called on a device. This causes a warning[1].
Fix this by updating device links that can be updated and dropping
device links that can't be updated to a sensible state.

[1] - 
https://lore.kernel.org/lkml/56f7d032-ba5a-a8c7-23de-2969d98c5...@nvidia.com/
Signed-off-by: Saravana Kannan 
---
 drivers/base/base.h |  1 +
 drivers/base/core.c | 35 +++
 drivers/base/dd.c   |  4 +++-
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/base/base.h b/drivers/base/base.h
index 52b3d7b75c27..1b44ed588f66 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -185,6 +185,7 @@ extern int device_links_read_lock(void);
 extern void device_links_read_unlock(int idx);
 extern int device_links_read_lock_held(void);
 extern int device_links_check_suppliers(struct device *dev);
+extern void device_links_force_bind(struct device *dev);
 extern void device_links_driver_bound(struct device *dev);
 extern void device_links_driver_cleanup(struct device *dev);
 extern void device_links_no_driver(struct device *dev);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index f29839382f81..45c75cc96fdc 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1153,6 +1153,41 @@ static ssize_t waiting_for_supplier_show(struct device 
*dev,
 }
 static DEVICE_ATTR_RO(waiting_for_supplier);
 
+/**
+ * device_links_force_bind - Prepares device to be force bound
+ * @dev: Consumer device.
+ *
+ * device_bind_driver() force binds a device to a driver without calling any
+ * driver probe functions. So the consumer really isn't going to wait for any
+ * supplier before it's bound to the driver. We still want the device link
+ * states to be sensible when this happens.
+ *
+ * In preparation for device_bind_driver(), this function goes through each
+ * supplier device links and checks if the supplier is bound. If it is, then
+ * the device link status is set to CONSUMER_PROBE. Otherwise, the device link
+ * is dropped. Links without the DL_FLAG_MANAGED flag set are ignored.
+ */
+void device_links_force_bind(struct device *dev)
+{
+   struct device_link *link, *ln;
+
+   device_links_write_lock();
+
+   list_for_each_entry_safe(link, ln, >links.suppliers, c_node) {
+   if (!(link->flags & DL_FLAG_MANAGED))
+   continue;
+
+   if (link->status != DL_STATE_AVAILABLE) {
+   device_link_drop_managed(link);
+   continue;
+   }
+   WRITE_ONCE(link->status, DL_STATE_CONSUMER_PROBE);
+   }
+   dev->links.status = DL_DEV_PROBING;
+
+   device_links_write_unlock();
+}
+
 /**
  * device_links_driver_bound - Update device links after probing its driver.
  * @dev: Device to update the links for.
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index f18963f42e21..eb201c6d5a6a 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -460,8 +460,10 @@ int device_bind_driver(struct device *dev)
int ret;
 
ret = driver_sysfs_add(dev);
-   if (!ret)
+   if (!ret) {
+   device_links_force_bind(dev);
driver_bound(dev);
+   }
else if (dev->bus)
blocking_notifier_call_chain(>bus->p->bus_notifier,
 BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
-- 
2.30.1.766.gb4fecdf3b7-goog

[PATCH v1 1/3] driver core: Avoid pointless deferred probe attempts

[Saravana Kannan]

There's no point in adding a device to the deferred probe list if we
know for sure that it doesn't have a matching driver. So, check if a
device can match with a driver before adding it to the deferred probe
list.

Signed-off-by: Saravana Kannan 
---
 drivers/base/dd.c  | 6 ++
 include/linux/device.h | 4 
 2 files changed, 10 insertions(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9179825ff646..f18963f42e21 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -123,6 +123,9 @@ static DECLARE_WORK(deferred_probe_work, 
deferred_probe_work_func);
 
 void driver_deferred_probe_add(struct device *dev)
 {
+   if (!dev->can_match)
+   return;
+
mutex_lock(_probe_mutex);
if (list_empty(>p->deferred_probe)) {
dev_dbg(dev, "Added to deferred list\n");
@@ -726,6 +729,7 @@ static int driver_probe_device(struct device_driver *drv, 
struct device *dev)
if (!device_is_registered(dev))
return -ENODEV;
 
+   dev->can_match = true;
pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
 drv->bus->name, __func__, dev_name(dev), drv->name);
 
@@ -829,6 +833,7 @@ static int __device_attach_driver(struct device_driver 
*drv, void *_data)
return 0;
} else if (ret == -EPROBE_DEFER) {
dev_dbg(dev, "Device match requests probe deferral\n");
+   dev->can_match = true;
driver_deferred_probe_add(dev);
} else if (ret < 0) {
dev_dbg(dev, "Bus failed to match device: %d\n", ret);
@@ -1064,6 +1069,7 @@ static int __driver_attach(struct device *dev, void *data)
return 0;
} else if (ret == -EPROBE_DEFER) {
dev_dbg(dev, "Device match requests probe deferral\n");
+   dev->can_match = true;
driver_deferred_probe_add(dev);
} else if (ret < 0) {
dev_dbg(dev, "Bus failed to match device: %d\n", ret);
diff --git a/include/linux/device.h b/include/linux/device.h
index ba660731bd25..569932d282c0 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -439,6 +439,9 @@ struct dev_links_info {
  * @state_synced: The hardware state of this device has been synced to match
  *   the software state of this device by calling the driver/bus
  *   sync_state() callback.
+ * @can_match: The device has matched with a driver at least once or it is in
+ * a bus (like AMBA) which can't check for matching drivers until
+ * other devices probe successfully.
  * @dma_coherent: this particular device is dma coherent, even if the
  * architecture supports non-coherent devices.
  * @dma_ops_bypass: If set to %true then the dma_ops are bypassed for the
@@ -545,6 +548,7 @@ struct device {
booloffline:1;
boolof_node_reused:1;
boolstate_synced:1;
+   boolcan_match:1;
 #if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
 defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
 defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
-- 
2.30.1.766.gb4fecdf3b7-goog

[PATCH v1 3/3] Revert "Revert "driver core: Set fw_devlink=on by default""

[Saravana Kannan]

This reverts commit 3e4c982f1ce75faf5314477b8da296d2d00919df.

Since all reported issues due to fw_devlink=on should be addressed by
this series, revert the revert. fw_devlink=on Take II.

Signed-off-by: Saravana Kannan 
---
 drivers/base/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 45c75cc96fdc..de518178ac36 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1538,7 +1538,7 @@ static void device_links_purge(struct device *dev)
 #define FW_DEVLINK_FLAGS_RPM   (FW_DEVLINK_FLAGS_ON | \
 DL_FLAG_PM_RUNTIME)
 
-static u32 fw_devlink_flags = FW_DEVLINK_FLAGS_PERMISSIVE;
+static u32 fw_devlink_flags = FW_DEVLINK_FLAGS_ON;
 static int __init fw_devlink_setup(char *arg)
 {
if (!arg)
-- 
2.30.1.766.gb4fecdf3b7-goog

Re: XDP socket rings, and LKMM litmus tests

[Alan Stern]

On Tue, Mar 02, 2021 at 07:46:27PM +0100, Björn Töpel wrote:
> Hi!
> 
> Firstly; The long Cc-list is to reach the LKMM-folks.
> 
> Some background; the XDP sockets use a ring-buffer to communicate
> between the kernel and userland. It's a
> single-consumer/single-producer ring, and described in
> net/xdp/xsk_queue.h.
> 
> --8<---
> /* The structure of the shared state of the rings are the same as the
>  * ring buffer in kernel/events/ring_buffer.c. For the Rx and completion
>  * ring, the kernel is the producer and user space is the consumer. For
>  * the Tx and fill rings, the kernel is the consumer and user space is
>  * the producer.
>  *
>  * producer consumer
>  *
>  * if (LOAD ->consumer) {   LOAD ->producer
>  *(A)   smp_rmb()   (C)
>  *STORE $data   LOAD $data
>  *smp_wmb()   (B)   smp_mb()(D)
>  *STORE ->producer  STORE ->consumer
>  * }
>  *
>  * (A) pairs with (D), and (B) pairs with (C).
> ...
> -->8---
> 
> I'd like to replace the smp_{r,w,}mb() barriers with acquire-release
> semantics [1], without breaking existing userspace applications.
> 
> So, I figured I'd use herd7 and the LKMM model to build a litmus test
> for the barrier version, then for the acquire-release version, and
> finally permutations of both.
> 
> The idea is to use a one element ring, with a state machine outlined
> in the litmus test.
> 
> The basic test for the existing smp_{r,w,}mb() barriers looks like:
> 
> $ cat spsc-rb+1p1c.litmus
> C spsc-rb+1p1c
> 
> // Stupid one entry ring:
> // prod cons allowed action   prod cons
> //00 =>   prod  =>   10
> //01 =>   cons  =>   00
> //10 =>   cons  =>   11
> //11 =>   prod  =>   01
> 
> { prod = 1; }
> 
> // Here, we start at prod==1,cons==0, data==0, i.e. producer has
> // written data=0, so from here only the consumer can start, and should
> // consume data==0. Afterwards, producer can continue and write 1 to
> // data. Can we enter state prod==0, cons==1, but consumer observerd
> // the write of 1?
> 
> P0(int *prod, int *cons, int *data)
> {
> int p;
> int c;
> int cond = 0;
> 
> p = READ_ONCE(*prod);
> c = READ_ONCE(*cons);
> if (p == 0)
> if (c == 0)
> cond = 1;
> if (p == 1)
> if (c == 1)
> cond = 1;
> 
> if (cond) {
> smp_mb();
> WRITE_ONCE(*data, 1);
> smp_wmb();
> WRITE_ONCE(*prod, p ^ 1);
> }
> }
> 
> P1(int *prod, int *cons, int *data)
> {
> int p;
> int c;
> int d = -1;
> int cond = 0;
> 
> p = READ_ONCE(*prod);
> c = READ_ONCE(*cons);
> if (p == 1)
> if (c == 0)
> cond = 1;
> if (p == 0)
> if (c == 1)
> cond = 1;
> 
> if (cond == 1) {
> smp_rmb();
> d = READ_ONCE(*data);
> smp_mb();
> WRITE_ONCE(*cons, c ^ 1);
> }
> }
> 
> exists( 1:d=1 /\ prod=0 /\ cons=1 );
> 
> --
> 
> The weird state changing if-statements is because that I didn't get
> '&&' and '||' to work with herd.
> 
> When this is run:
> 
> $ herd7 -conf linux-kernel.cfg litmus-tests/spsc-rb+1p1c.litmus
> Test spsc-rb+1p1c Allowed
> States 2
> 1:d=0; cons=1; prod=0;
> 1:d=0; cons=1; prod=1;
> No
> Witnesses
> Positive: 0 Negative: 2
> Condition exists (1:d=1 /\ prod=0 /\ cons=1)
> Observation spsc-rb+1p1c Never 0 2
> Time spsc-rb+1p1c 0.04
> Hash=b399756d6a1301ca5bda042f32130791
> 
> Now to my question; In P0 there's an smp_mb(). Without that, the d==1
> can be observed from P1 (consumer):
> 
> $ herd7 -conf linux-kernel.cfg litmus-tests/spsc-rb+1p1c.litmus
> Test spsc-rb+1p1c Allowed
> States 3
> 1:d=0; cons=1; prod=0;
> 1:d=0; cons=1; prod=1;
> 1:d=1; cons=1; prod=0;
> Ok
> Witnesses
> Positive: 1 Negative: 2
> Condition exists (1:d=1 /\ prod=0 /\ cons=1)
> Observation spsc-rb+1p1c Sometimes 1 2
> Time spsc-rb+1p1c 0.04
> Hash=0047fc21fa77da9a9aee15e35ec367ef

This result is wrong, apparently because of a bug in herd7.  There 
should be control dependencies from each of the two loads in P0 to each 
of the two stores, but herd7 doesn't detect them.

Maybe Luc can find some time to check whether this really is a bug and 
if it is, fix it.

> In commit c7f2e3cd6c1f ("perf: Optimize ring-buffer write by depending
> on control dependencies") removes the corresponding smp_mb(), and also
> the circular buffer in circular-buffers.txt (pre commit 6c43c091bdc5
> ("documentation: Update circular buffer for
> load-acquire/store-release")) is missing the smp_mb() at the
> producer-side.
> 
> I'm trying to wrap my head around why it's OK to remove the smp_mb()
> in the cases above? I'm worried that the current XDP socket ring
> implementation (which is missing smp_mb()) might be broken.

Because of the control dependencies, the smp_mb isn't needed.  The 
dependencies will 

[PATCH 1/2] mm: disable LRU pagevec during the migration temporarily

[Minchan Kim]

LRU pagevec holds refcount of pages until the pagevec are drained.
It could prevent migration since the refcount of the page is greater
than the expection in migration logic. To mitigate the issue,
callers of migrate_pages drains LRU pagevec via migrate_prep or
lru_add_drain_all before migrate_pages call.

However, it's not enough because pages coming into pagevec after the
draining call still could stay at the pagevec so it could keep
preventing page migration. Since some callers of migrate_pages have
retrial logic with LRU draining, the page would migrate at next trail
but it is still fragile in that it doesn't close the fundamental race
between upcoming LRU pages into pagvec and migration so the migration
failure could cause contiguous memory allocation failure in the end.

To close the race, this patch disables lru caches(i.e, pagevec)
during ongoing migration until migrate is done.

Since it's really hard to reproduce, I measured how many times
migrate_pages retried with force mode below debug code.

int migrate_pages(struct list_head *from, new_page_t get_new_page,
..
..

if (rc && reason == MR_CONTIG_RANGE && pass > 2) {
   printk(KERN_ERR, "pfn 0x%lx reason %d\n", page_to_pfn(page), rc);
   dump_page(page, "fail to migrate");
}

The test was repeating android apps launching with cma allocation
in background every five seconds. Total cma allocation count was
about 500 during the testing. With this patch, the dump_page count
was reduced from 400 to 30.

Signed-off-by: Minchan Kim 
---
* from RFC - 
http://lore.kernel.org/linux-mm/20210216170348.1513483-1-minc...@kernel.org
  * use atomic and lru_add_drain_all for strict ordering - mhocko
  * lru_cache_disable/enable - mhocko

 fs/block_dev.c  |  2 +-
 include/linux/migrate.h |  6 +++--
 include/linux/swap.h|  4 ++-
 mm/compaction.c |  4 +--
 mm/fadvise.c|  2 +-
 mm/gup.c|  2 +-
 mm/khugepaged.c |  2 +-
 mm/ksm.c|  2 +-
 mm/memcontrol.c |  4 +--
 mm/memfd.c  |  2 +-
 mm/memory-failure.c |  2 +-
 mm/memory_hotplug.c |  2 +-
 mm/mempolicy.c  |  6 +
 mm/migrate.c| 15 ++-
 mm/page_alloc.c |  5 +++-
 mm/swap.c   | 55 +++--
 16 files changed, 85 insertions(+), 30 deletions(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 7a814a13f9a4..1fe75dbd0ce0 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -93,7 +93,7 @@ void invalidate_bdev(struct block_device *bdev)
 
if (mapping->nrpages) {
invalidate_bh_lrus();
-   lru_add_drain_all();/* make sure all lru add caches are 
flushed */
+   lru_add_drain_all(false);   /* make sure all lru add caches 
are flushed */
invalidate_mapping_pages(mapping, 0, -1);
}
/* 99% of the time, we don't need to flush the cleancache on the bdev.
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 3a389633b68f..6a23174ea081 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -47,6 +47,7 @@ extern void putback_movable_page(struct page *page);
 
 extern void migrate_prep(void);
 extern void migrate_prep_local(void);
+extern void migrate_finish(void);
 extern void migrate_page_states(struct page *newpage, struct page *page);
 extern void migrate_page_copy(struct page *newpage, struct page *page);
 extern int migrate_huge_page_move_mapping(struct address_space *mapping,
@@ -66,8 +67,9 @@ static inline struct page *alloc_migration_target(struct page 
*page,
 static inline int isolate_movable_page(struct page *page, isolate_mode_t mode)
{ return -EBUSY; }
 
-static inline int migrate_prep(void) { return -ENOSYS; }
-static inline int migrate_prep_local(void) { return -ENOSYS; }
+static inline void migrate_prep(void) { return -ENOSYS; }
+static inline void migrate_prep_local(void) { return -ENOSYS; }
+static inline void migrate_done(void) {}
 
 static inline void migrate_page_states(struct page *newpage, struct page *page)
 {
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 71166bc10d17..8ab7ad7157f3 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -339,10 +339,12 @@ extern void lru_note_cost(struct lruvec *lruvec, bool 
file,
 extern void lru_note_cost_page(struct page *);
 extern void lru_cache_add(struct page *);
 extern void mark_page_accessed(struct page *);
+extern void lru_cache_disable(void);
+extern void lru_cache_enable(void);
 extern void lru_add_drain(void);
 extern void lru_add_drain_cpu(int cpu);
 extern void lru_add_drain_cpu_zone(struct zone *zone);
-extern void lru_add_drain_all(void);
+extern void lru_add_drain_all(bool force_all_cpus);
 extern void rotate_reclaimable_page(struct page *page);
 extern void deactivate_file_page(struct page *page);
 extern void deactivate_page(struct page *page);
diff --git a/mm/compaction.c 

[RESEND PATCH 2/3] mfd: lm3533: Constify static struct attribute_group

[Rikard Falkeborn]

The only usage of lm3533_attribute_group is to pass its address to
sysfs_create_group() and sysfs_remove_group(), both which takes pointers
to const attribute_group structs. Make it const to allow the compiler to
put it in read-only memory.

Done with the help of coccinelle.

Signed-off-by: Rikard Falkeborn 
---
 drivers/mfd/lm3533-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/lm3533-core.c b/drivers/mfd/lm3533-core.c
index 22fdffd564f7..523dcf05db78 100644
--- a/drivers/mfd/lm3533-core.c
+++ b/drivers/mfd/lm3533-core.c
@@ -373,7 +373,7 @@ static umode_t lm3533_attr_is_visible(struct kobject *kobj,
return mode;
 };
 
-static struct attribute_group lm3533_attribute_group = {
+static const struct attribute_group lm3533_attribute_group = {
.is_visible = lm3533_attr_is_visible,
.attrs  = lm3533_attributes
 };
-- 
2.30.1

[RESEND PATCH 3/3] mfd: pcf50633: Constify static struct attribute_group

[Rikard Falkeborn]

The only usage of pcf_attr_group is to pass its address to
sysfs_create_group() and sysfs_remove_group(), both which takes pointers
to const attribute_group structs. Make it const to allow the compiler to
put it in read-only memory.

Done with the help of coccinelle.

Signed-off-by: Rikard Falkeborn 
---
 drivers/mfd/pcf50633-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/pcf50633-core.c b/drivers/mfd/pcf50633-core.c
index 148bcd6120f4..0768d684113a 100644
--- a/drivers/mfd/pcf50633-core.c
+++ b/drivers/mfd/pcf50633-core.c
@@ -131,7 +131,7 @@ static struct attribute *pcf_sysfs_entries[] = {
NULL,
 };
 
-static struct attribute_group pcf_attr_group = {
+static const struct attribute_group pcf_attr_group = {
.name   = NULL, /* put in device directory */
.attrs  = pcf_sysfs_entries,
 };
-- 
2.30.1

[RESEND PATCH 0/3] drivers/mfd: Constify static attribute_group structs

[Rikard Falkeborn]

Seems the first submission somehow didn't make it to LKML, here's a
resend.

The only usage of the structs is to pass their address to
sysfs_create_group() and sysfs_remove_group(), both which takes pointers
to const attribute_group structs. Make them const to allow the compiler
to put them in read-only memory.

Done with the help of coccinelle.

With these patches applied, all static attribute_group structs in
drivers/mfd are const.

Rikard Falkeborn (3):
  mfd: gateworks-gsc: Constify static struct attribute_group
  mfd: lm3533: Constify static struct attribute_group
  mfd: pcf50633: Constify static struct attribute_group

 drivers/mfd/gateworks-gsc.c | 2 +-
 drivers/mfd/lm3533-core.c   | 2 +-
 drivers/mfd/pcf50633-core.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.30.1

[PATCH v1 0/3] driver core: Set fw_devlink=on take II

[Saravana Kannan]

This series fixes the last few remaining issues reported when fw_devlink=on
by default.

Patch 1 is just [6] pulled in without changes into this series. It reduces
some unnecessary probe reordering caused by a combination of fw_devlink and
existing device link code. This fixes some issue caused by fw_devlink=on
with respect to DMAs and IOMMUs [1].

Patch 2 fixes a warning [2] present in code unrelated to fw_devlink. It was
just exposed by fw_devlink.

Jon,

Patch 2 should address the issues you reported[2] even without [3]. Could
you test this series please?

Michael,

I think Patch 1 should fix [4] without [5]. Can you test the series please?

Geert/Marek,

As far as I know, there shouldn't have any more issues you reported that
are still left unfixed after this series. Please correct me if I'm wrong or
if you find new issues.

[1] - 
https://lore.kernel.org/lkml/camuhmduvvr8jes51_8_ypoicr-nwad_2nklyukwey8mbxx9...@mail.gmail.com/
[2] - 
https://lore.kernel.org/lkml/56f7d032-ba5a-a8c7-23de-2969d98c5...@nvidia.com/
[3] - 
https://lore.kernel.org/lkml/5176f496-facb-d7b0-9f4e-a9e4b8974...@nvidia.com/
[4] - https://lore.kernel.org/lkml/4b9ae679b6f76d2f7e340e2ec229d...@walle.cc/
[5] - https://lore.kernel.org/lkml/20210120105246.23218-1-mich...@walle.cc/
[6] - 
https://lore.kernel.org/lkml/20210217235130.1744843-1-sarava...@google.com/

Cc: Michael Walle 
Cc: Jon Hunter 
Cc: Marek Szyprowski 
Cc: Geert Uytterhoeven 
Cc: Guenter Roeck 

Thanks,
Saravana

Saravana Kannan (3):
  driver core: Avoid pointless deferred probe attempts
  driver core: Update device link status properly for
device_bind_driver()
  Revert "Revert "driver core: Set fw_devlink=on by default""

 drivers/base/base.h|  1 +
 drivers/base/core.c| 37 -
 drivers/base/dd.c  | 10 +-
 include/linux/device.h |  4 
 4 files changed, 50 insertions(+), 2 deletions(-)

-- 
2.30.1.766.gb4fecdf3b7-goog

[PATCH 2/2] mm: fs: Invalidate BH LRU during page migration

[Minchan Kim]

Pages containing buffer_heads that are in one of the per-CPU
buffer_head LRU caches will be pinned and thus cannot be migrated.
This can prevent CMA allocations from succeeding, which are often used
on platforms with co-processors (such as a DSP) that can only use
physically contiguous memory. It can also prevent memory
hot-unplugging from succeeding, which involves migrating at least
MIN_MEMORY_BLOCK_SIZE bytes of memory, which ranges from 8 MiB to 1
GiB based on the architecture in use.

Correspondingly, invalidate the BH LRU caches before a migration
starts and stop any buffer_head from being cached in the LRU caches,
until migration has finished.

Suggested-by: Matthew Wilcox 
Signed-off-by: Chris Goldsworthy 
Signed-off-by: Minchan Kim 
---
* from prev - 
https://lore.kernel.org/linux-mm/e8f3e042b902156467a5e978b57c14954213ec59.1611642039.git.cgold...@codeaurora.org/
  * consolidate bh_lru drain logic into lru pagevec - willy

 fs/buffer.c | 12 ++--
 include/linux/buffer_head.h |  2 ++
 include/linux/swap.h|  1 +
 mm/swap.c   |  5 -
 4 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 96c7604f69b3..4492e9d4c9d3 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1301,6 +1301,14 @@ static void bh_lru_install(struct buffer_head *bh)
int i;
 
check_irqs_on();
+   /*
+* buffer_head in bh_lru could increase refcount of the page
+* until it will be invalidated. It causes page migraion failure.
+* Skip putting upcoming bh into bh_lru until migration is done.
+*/
+   if (lru_cache_disabled())
+   return;
+
bh_lru_lock();
 
b = this_cpu_ptr(_lrus);
@@ -1446,7 +1454,7 @@ EXPORT_SYMBOL(__bread_gfp);
  * This doesn't race because it runs in each cpu either in irq
  * or with preempt disabled.
  */
-static void invalidate_bh_lru(void *arg)
+void invalidate_bh_lru(void *arg)
 {
struct bh_lru *b = _cpu_var(bh_lrus);
int i;
@@ -1458,7 +1466,7 @@ static void invalidate_bh_lru(void *arg)
put_cpu_var(bh_lrus);
 }
 
-static bool has_bh_in_lru(int cpu, void *dummy)
+bool has_bh_in_lru(int cpu, void *dummy)
 {
struct bh_lru *b = per_cpu_ptr(_lrus, cpu);
int i;
diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
index 6b47f94378c5..3d98bdabaac9 100644
--- a/include/linux/buffer_head.h
+++ b/include/linux/buffer_head.h
@@ -194,6 +194,8 @@ void __breadahead_gfp(struct block_device *, sector_t 
block, unsigned int size,
 struct buffer_head *__bread_gfp(struct block_device *,
sector_t block, unsigned size, gfp_t gfp);
 void invalidate_bh_lrus(void);
+void invalidate_bh_lru(void *);
+bool has_bh_in_lru(int cpu, void *dummy);
 struct buffer_head *alloc_buffer_head(gfp_t gfp_flags);
 void free_buffer_head(struct buffer_head * bh);
 void unlock_buffer(struct buffer_head *bh);
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 8ab7ad7157f3..94a77e618dba 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -341,6 +341,7 @@ extern void lru_cache_add(struct page *);
 extern void mark_page_accessed(struct page *);
 extern void lru_cache_disable(void);
 extern void lru_cache_enable(void);
+extern bool lru_cache_disabled(void);
 extern void lru_add_drain(void);
 extern void lru_add_drain_cpu(int cpu);
 extern void lru_add_drain_cpu_zone(struct zone *zone);
diff --git a/mm/swap.c b/mm/swap.c
index c1fa6cac04c1..88d51b9ebc8c 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -667,6 +668,7 @@ void lru_add_drain_cpu(int cpu)
pagevec_lru_move_fn(pvec, lru_lazyfree_fn);
 
activate_page_drain(cpu);
+   invalidate_bh_lru(NULL);
 }
 
 /**
@@ -854,7 +856,8 @@ void lru_add_drain_all(bool force_all_cpus)
pagevec_count(_cpu(lru_pvecs.lru_deactivate_file, cpu)) 
||
pagevec_count(_cpu(lru_pvecs.lru_deactivate, cpu)) ||
pagevec_count(_cpu(lru_pvecs.lru_lazyfree, cpu)) ||
-   need_activate_page_drain(cpu)) {
+   need_activate_page_drain(cpu) ||
+   has_bh_in_lru(cpu, NULL)) {
INIT_WORK(work, lru_add_drain_per_cpu);
queue_work_on(cpu, mm_percpu_wq, work);
__cpumask_set_cpu(cpu, _work);
-- 
2.30.1.766.gb4fecdf3b7-goog

[tip:sched/core] BUILD SUCCESS c91b0dcb6482096e7af4adbf39cfe3296af74a78

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
sched/core
branch HEAD: c91b0dcb6482096e7af4adbf39cfe3296af74a78  cpu/hotplug: Add 
cpuhp_invoke_callback_range()

elapsed time: 722m

configs tested: 106
configs skipped: 2

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
nios2 3c120_defconfig
sh  kfr2r09_defconfig
um i386_defconfig
mipsqi_lb60_defconfig
arm  exynos_defconfig
arm  simpad_defconfig
arm  gemini_defconfig
sh   se7724_defconfig
shsh7763rdp_defconfig
powerpc mpc832x_mds_defconfig
mips cu1830-neo_defconfig
c6x defconfig
riscvnommu_virt_defconfig
powerpc pq2fads_defconfig
armmvebu_v7_defconfig
arm  colibri_pxa270_defconfig
powerpc ps3_defconfig
powerpc mpc836x_rdk_defconfig
powerpcge_imp3a_defconfig
armtrizeps4_defconfig
powerpc  obs600_defconfig
mips   xway_defconfig
powerpc  g5_defconfig
arm palmz72_defconfig
sparc   sparc32_defconfig
powerpc tqm8540_defconfig
armpleb_defconfig
c6x  alldefconfig
powerpc mpc512x_defconfig
m68k  multi_defconfig
arm  imote2_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210302
x86_64   randconfig-a001-20210302
x86_64   randconfig-a004-20210302
x86_64   randconfig-a002-20210302
x86_64   randconfig-a005-20210302
x86_64   randconfig-a003-20210302
i386 randconfig-a005-20210302
i386 randconfig-a003-20210302
i386 randconfig-a002-20210302
i386 randconfig-a004-20210302
i386 randconfig-a006-20210302
i386 randconfig-a001-20210302
i386 randconfig-a016-20210302
i386 randconfig-a012-20210302
i386 randconfig-a014-20210302
i386 randconfig-a013-20210302
i386 randconfig-a011-20210302
i386 randconfig-a015-20210302
riscvnommu_k210_defconfig
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64

Re: Why do kprobes and uprobes singlestep?

[Andy Lutomirski]

> On Mar 2, 2021, at 12:24 PM, Alexei Starovoitov 
>  wrote:
> 
> On Tue, Mar 2, 2021 at 10:38 AM Andy Lutomirski  wrote:
>> 
>> Is there something like a uprobe test suite?  How maintained /
>> actively used is uprobe?
> 
> uprobe+bpf is heavily used in production.
> selftests/bpf has only one test for it though.
> 
> Why are you asking?

Because the integration with the x86 entry code is a mess, and I want to know 
whether to mark it BROKEN or how to make sure the any cleanups actually work.

[RESEND PATCH 1/3] mfd: gateworks-gsc: Constify static struct attribute_group

[Rikard Falkeborn]

The only usage of attr_group is to pass its address to
sysfs_create_group() and sysfs_remove_group(), both which takes pointers
to const attribute_group structs. Make it const to allow the compiler to
put it in read-only memory.

Done with the help of coccinelle.

Signed-off-by: Rikard Falkeborn 
---
 drivers/mfd/gateworks-gsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/gateworks-gsc.c b/drivers/mfd/gateworks-gsc.c
index d87876747b91..8745f9d8c26f 100644
--- a/drivers/mfd/gateworks-gsc.c
+++ b/drivers/mfd/gateworks-gsc.c
@@ -150,7 +150,7 @@ static struct attribute *gsc_attrs[] = {
NULL,
 };
 
-static struct attribute_group attr_group = {
+static const struct attribute_group attr_group = {
.attrs = gsc_attrs,
 };
 
-- 
2.30.1

[PATCH 1/2] Makefile: Remove '--gcc-toolchain' flag

[Nathan Chancellor]

This is not necessary anymore now that we specify '--prefix=', which
tells clang exactly where to find the GNU cross tools. This has been
verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as well as a
distribution version of LLVM 11.1.0 without binutils in the LLVM
toolchain locations.

Signed-off-by: Nathan Chancellor 
---
 Makefile | 4 
 1 file changed, 4 deletions(-)

diff --git a/Makefile b/Makefile
index f9b54da2fca0..c20f0ad8be73 100644
--- a/Makefile
+++ b/Makefile
@@ -568,10 +568,6 @@ ifneq ($(CROSS_COMPILE),)
 CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%))
 GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
 CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
-GCC_TOOLCHAIN  := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
-endif
-ifneq ($(GCC_TOOLCHAIN),)
-CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN)
 endif
 ifneq ($(LLVM_IAS),1)
 CLANG_FLAGS+= -no-integrated-as

base-commit: 7a7fd0de4a9804299793e564a555a49c1fc924cb
-- 
2.31.0.rc0.75.gec125d1bc1

[PATCH 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as

[Nathan Chancellor]

When building with LLVM_IAS=1, there is no point to specifying
'--prefix=' because that flag is only used to find the cross assembler,
which is clang itself when building with LLVM_IAS=1. All of the other
tools are invoked directly from PATH or a full path specified via the
command line, which does not depend on the value of '--prefix='.

Sharing commands to reproduce issues becomes a little bit easier without
a '--prefix=' value because that '--prefix=' value is specific to a
user's machine due to it being an absolute path.

Signed-off-by: Nathan Chancellor 
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index c20f0ad8be73..0413b8c594cd 100644
--- a/Makefile
+++ b/Makefile
@@ -566,12 +566,12 @@ CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | 
head -n 1 | sed 's/\#//g
 ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
 ifneq ($(CROSS_COMPILE),)
 CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%))
+ifneq ($(LLVM_IAS),1)
 GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
 CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
-endif
-ifneq ($(LLVM_IAS),1)
 CLANG_FLAGS+= -no-integrated-as
 endif
+endif
 CLANG_FLAGS+= -Werror=unknown-warning-option
 KBUILD_CFLAGS  += $(CLANG_FLAGS)
 KBUILD_AFLAGS  += $(CLANG_FLAGS)
-- 
2.31.0.rc0.75.gec125d1bc1

Re: [PATCH] sched: Optimize __calc_delta.

[Josh Don]

From: Clement Courbet 

A significant portion of __calc_delta time is spent in the loop
shifting a u64 by 32 bits. Use `fls` instead of iterating.

This is ~7x faster on benchmarks.

The generic `fls` implementation (`generic_fls`) is still ~4x faster
than the loop.
Architectures that have a better implementation will make use of it. For
example, on X86 we get an additional factor 2 in speed without dedicated
implementation.

On gcc, the asm versions of `fls` are about the same speed as the
builtin. On clang, the versions that use fls (fls,fls64) are more than
twice as slow as the builtin. This is because the way the `fls` function
is written, clang puts the value in memory:
https://godbolt.org/z/EfMbYe. This can be fixed in a separate patch.

```
name   cpu/op
BM_Calc<__calc_delta_loop> 9.57ms ±12%
BM_Calc<__calc_delta_generic_fls>  2.36ms ±13%
BM_Calc<__calc_delta_asm_fls>  2.45ms ±13%
BM_Calc<__calc_delta_asm_fls_nomem>1.66ms ±12%
BM_Calc<__calc_delta_asm_fls64>2.46ms ±13%
BM_Calc<__calc_delta_asm_fls64_nomem>  1.34ms ±15%
BM_Calc<__calc_delta_builtin>  1.32ms ±11%
```

Signed-off-by: Clement Courbet 
Signed-off-by: Josh Don 
---
 kernel/sched/fair.c  | 30 ++
 kernel/sched/sched.h |  1 +
 2 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8a8bd7b13634..67e5a1d536ad 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -214,6 +214,16 @@ static void __update_inv_weight(struct load_weight *lw)
  lw->inv_weight = WMULT_CONST / w;
 }

+/*
+ * An fls that handles an u32 value on architectures
+ * where `sizeof(unsigned int) < 32`.
+ */
+#if (__SIZEOF_INT__ >= 32)
+# define FLS_AT_LEAST_32(v) fls(v)
+#else
+# define FLS_AT_LEAST_32(v) fls64(v)
+#endif
+
 /*
  * delta_exec * weight / lw.weight
  *   OR
@@ -229,27 +239,31 @@ static void __update_inv_weight(struct load_weight *lw)
 static u64 __calc_delta(u64 delta_exec, unsigned long weight, struct
load_weight *lw)
 {
  u64 fact = scale_load_down(weight);
+ u32 fact_hi = (u32)(fact >> 32);
  int shift = WMULT_SHIFT;
+ int fs;

  __update_inv_weight(lw);

- if (unlikely(fact >> 32)) {
- while (fact >> 32) {
- fact >>= 1;
- shift--;
- }
+ if (unlikely(fact_hi)) {
+ fs = FLS_AT_LEAST_32(fact_hi);
+ shift -= fs;
+ fact >>= fs;
  }

  fact = mul_u32_u32(fact, lw->inv_weight);

- while (fact >> 32) {
- fact >>= 1;
- shift--;
+ fact_hi = (u32)(fact >> 32);
+ if (fact_hi) {
+ fs = FLS_AT_LEAST_32(fact_hi);
+ shift -= fs;
+ fact >>= fs;
  }

  return mul_u64_u32_shr(delta_exec, fact, shift);
 }

+#undef FLS_AT_LEAST_32

 const struct sched_class fair_sched_class;

diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 10a1522b1e30..714af71cf983 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -36,6 +36,7 @@
 #include 

 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.30.1.766.gb4fecdf3b7-goog

Re: [PATCH v1 1/5] mfd: intel_quark_i2c_gpio: revert "Constify static struct resources"

[Rikard Falkeborn]

On Tue, Mar 02, 2021 at 03:56:16PM +0200, Andy Shevchenko wrote:
> The structures are used as place holders, so they are modified at run-time.
> Obviously they may not be constants.
> 
>   BUG: unable to handle page fault for address: d0643220
>   ...
>   CPU: 0 PID: 110 Comm: modprobe Not tainted 5.11.0+ #1
>   Hardware name: Intel Corp. QUARK/GalileoGen2, BIOS 0x01000200 01/01/2014
>   EIP: intel_quark_mfd_probe+0x93/0x1c0 [intel_quark_i2c_gpio]
> 
> This partially reverts the commit c4a164f41554d2899bed94bdcc499263f41787b4.
> 
> While at it, add a comment to avoid similar changes in the future.
> 
> Fixes: c4a164f41554 ("mfd: Constify static struct resources")
> Cc: Rikard Falkeborn 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mfd/intel_quark_i2c_gpio.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mfd/intel_quark_i2c_gpio.c 
> b/drivers/mfd/intel_quark_i2c_gpio.c
> index 55a9e017edee..124c0ee84169 100644
> --- a/drivers/mfd/intel_quark_i2c_gpio.c
> +++ b/drivers/mfd/intel_quark_i2c_gpio.c
> @@ -72,7 +72,8 @@ static const struct dmi_system_id dmi_platform_info[] = {
>   {}
>  };
>  
> -static const struct resource intel_quark_i2c_res[] = {
> +/* This is used as a place holder and will be modified at run-time */
> +static struct resource intel_quark_i2c_res[] = {
>   [INTEL_QUARK_IORES_MEM] = {
>   .flags = IORESOURCE_MEM,
>   },
> @@ -85,7 +86,8 @@ static struct mfd_cell_acpi_match 
> intel_quark_acpi_match_i2c = {
>   .adr = MFD_ACPI_MATCH_I2C,
>  };
>  
> -static const struct resource intel_quark_gpio_res[] = {
> +/* This is used as a place holder and will be modified at run-time */
> +static struct resource intel_quark_gpio_res[] = {
>   [INTEL_QUARK_IORES_MEM] = {
>   .flags = IORESOURCE_MEM,
>   },
> -- 
> 2.30.1
> 

Sorry about that :(

Reviewed-by: Rikard Falkeborn 

Re: [PATCH] ibmvnic: Fix possibly uninitialized old_num_tx_queues variable warning.

[Sukadev Bhattiprolu]

Michal Suchanek [msucha...@suse.de] wrote:
> GCC 7.5 reports:
> ../drivers/net/ethernet/ibm/ibmvnic.c: In function 'ibmvnic_reset_init':
> ../drivers/net/ethernet/ibm/ibmvnic.c:5373:51: warning: 'old_num_tx_queues' 
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> ../drivers/net/ethernet/ibm/ibmvnic.c:5373:6: warning: 'old_num_rx_queues' 
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> The variable is initialized only if(reset) and used only if(reset &&
> something) so this is a false positive. However, there is no reason to
> not initialize the variables unconditionally avoiding the warning.

Yeah, its a false positive, but initializing doesn't hurt.
> 
> Fixes: 635e442f4a48 ("ibmvnic: merge ibmvnic_reset_init and ibmvnic_init")
> Signed-off-by: Michal Suchanek 

Reviewed-by: Sukadev Bhattiprolu 

Re: [PATCH] sched: Optimize __calc_delta.

[Josh Don]

On Fri, Feb 26, 2021 at 1:03 PM Peter Zijlstra  wrote:
>
> On Fri, Feb 26, 2021 at 11:52:39AM -0800, Josh Don wrote:
> > From: Clement Courbet 
> >
> > A significant portion of __calc_delta time is spent in the loop
> > shifting a u64 by 32 bits. Use a __builtin_clz instead of iterating.
> >
> > This is ~7x faster on benchmarks.
>
> Have you tried on hardware without such fancy instructions?

Was not able to find any on hand unfortunately. Clement did rework the
patch to use fls() instead, and has benchmarks for the generic and asm
variations. All of which are faster than the loop. In my next reply,
I'll include the updated patch inline.

[PATCH 6/7] media: controls: Log VP8 stateless control in .std_log

[Ezequiel Garcia]

Simply print the type of the control.

Signed-off-by: Ezequiel Garcia 
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 1a683f4fa978..0fc7180a47e9 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1781,6 +1781,9 @@ static void std_log(const struct v4l2_ctrl *ctrl)
case V4L2_CTRL_TYPE_FWHT_PARAMS:
pr_cont("FWHT_PARAMS");
break;
+   case V4L2_CTRL_TYPE_VP8_FRAME:
+   pr_cont("VP8_FRAME");
+   break;
default:
pr_cont("unknown type %d", ctrl->type);
break;
-- 
2.30.0

Re: [PATCH 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

[Pavel Machek]

Hi!

> This driver adds initial support for several devices from Siemens. It is
> based on a platform driver introduced in an earlier commit.

Ok.

> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 2a698df9da57..c15e1e3c5958 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -93,6 +93,7 @@ obj-$(CONFIG_LEDS_TURRIS_OMNIA) += 
> leds-turris-omnia.o
>  obj-$(CONFIG_LEDS_WM831X_STATUS) += leds-wm831x-status.o
>  obj-$(CONFIG_LEDS_WM8350)+= leds-wm8350.o
>  obj-$(CONFIG_LEDS_WRAP)  += leds-wrap.o
> +obj-$(CONFIG_LEDS_SIEMENS_SIMATIC_IPC)   += simatic-ipc-leds.o

Let's put this into drivers/leds/simple. You'll have to create it.

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */

Remove?

> +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> + {1 << 15, "simatic-ipc:green:run-stop"},
> + {1 << 7,  "simatic-ipc:yellow:run-stop"},
> + {1 << 14, "simatic-ipc:red:error"},
> + {1 << 6,  "simatic-ipc:yellow:error"},
> + {1 << 13, "simatic-ipc:red:maint"},
> + {1 << 5,  "simatic-ipc:yellow:maint"},
> + {0, ""},
> +};

Please use names consistent with other systems, this is user
visible. If you have two-color power led, it should be
:green:power... See include/dt-bindings/leds/common.h .

Please avoid // comments in the code.

> +module_init(simatic_ipc_led_init_module);
> +module_exit(simatic_ipc_led_exit_module);

No need for such verbosity for functions that are static.

> +MODULE_LICENSE("GPL");

GPL v2?

Best regards,
Pavel

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature

[PATCH 7/7] media: uapi: move VP8 stateless controls out of staging

[Ezequiel Garcia]

Until now, the VP8 V4L2 API was not exported as a public API,
and only defined in a private media header (media/vp8-ctrls.h).

The reason for this was a concern about the API not complete
and ready to support VP8 decoding hardware accelerators.

After reviewing the VP8 specification in detail, and now
that the API is able to support Cedrus and Hantro G1,
we can consider this ready.

Signed-off-by: Ezequiel Garcia 
---
 .../media/v4l/ext-ctrls-codec-stateless.rst   | 318 +
 .../media/v4l/ext-ctrls-codec.rst | 323 --
 .../media/v4l/pixfmt-compressed.rst   |  10 +-
 .../media/v4l/vidioc-g-ext-ctrls.rst  |   4 +
 .../media/v4l/vidioc-queryctrl.rst|   6 +
 .../media/videodev2.h.rst.exceptions  |   1 +
 drivers/media/v4l2-core/v4l2-ctrls.c  |   4 +-
 drivers/staging/media/hantro/hantro_drv.c |   2 +-
 .../staging/media/hantro/hantro_g1_vp8_dec.c  |   3 +-
 .../media/hantro/rk3399_vpu_hw_vp8_dec.c  |   3 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |   2 +-
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |   2 +-
 .../staging/media/sunxi/cedrus/cedrus_vp8.c   |   3 +-
 include/media/v4l2-ctrls.h|   1 -
 include/media/vp8-ctrls.h | 210 
 include/uapi/linux/v4l2-controls.h| 195 +++
 include/uapi/linux/videodev2.h|   1 +
 17 files changed, 539 insertions(+), 549 deletions(-)
 delete mode 100644 include/media/vp8-ctrls.h

diff --git 
a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst 
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
index 01e3b1a3fb99..62147b1d341e 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
@@ -791,3 +791,321 @@ FWHT Flags
 * - ``V4L2_FWHT_FL_PIXENC_HSV``
   - 0x0018
   - Set if the pixel encoding is HSV.
+
+.. _v4l2-codec-stateless-vp8:
+
+``V4L2_CID_STATELESS_VP8_FRAME (struct)``
+Specifies the frame parameters for the associated VP8 parsed frame data.
+This includes the necessary parameters for
+configuring a stateless hardware decoding pipeline for VP8.
+The bitstream parameters are defined according to :ref:`vp8`.
+
+.. c:type:: v4l2_ctrl_vp8_frame
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}|
+
+.. flat-table:: struct v4l2_ctrl_vp8_frame
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - struct :c:type:`v4l2_vp8_segment`
+  - ``seg``
+  - Structure with segment-based adjustments metadata.
+* - struct :c:type:`v4l2_vp8_loop_filter`
+  - ``lf``
+  - Structure with loop filter level adjustments metadata.
+* - struct :c:type:`v4l2_vp8_quantization`
+  - ``quant``
+  - Structure with VP8 dequantization indices metadata.
+* - struct :c:type:`v4l2_vp8_entropy`
+  - ``entropy``
+  - Structure with VP8 entropy coder probabilities metadata.
+* - struct :c:type:`v4l2_vp8_entropy_coder_state`
+  - ``coder_state``
+  - Structure with VP8 entropy coder state.
+* - __u16
+  - ``width``
+  - The width of the frame. Must be set for all frames.
+* - __u16
+  - ``height``
+  - The height of the frame. Must be set for all frames.
+* - __u8
+  - ``horizontal_scale``
+  - Horizontal scaling factor.
+* - __u8
+  - ``vertical_scaling factor``
+  - Vertical scale.
+* - __u8
+  - ``version``
+  - Bitstream version.
+* - __u8
+  - ``prob_skip_false``
+  - Indicates the probability that the macroblock is not skipped.
+* - __u8
+  - ``prob_intra``
+  - Indicates the probability that a macroblock is intra-predicted.
+* - __u8
+  - ``prob_last``
+  - Indicates the probability that the last reference frame is used
+for inter-prediction
+* - __u8
+  - ``prob_gf``
+  - Indicates the probability that the golden reference frame is used
+for inter-prediction
+* - __u8
+  - ``num_dct_parts``
+  - Number of DCT coefficients partitions. Must be one of: 1, 2, 4, or 8.
+* - __u32
+  - ``first_part_size``
+  - Size of the first partition, i.e. the control partition.
+* - __u32
+  - ``first_part_header_bits``
+  - Size in bits of the first partition header portion.
+* - __u32
+  - ``dct_part_sizes[8]``
+  - DCT coefficients sizes.
+* - __u64
+  - ``last_frame_ts``
+  - Timestamp for the V4L2 capture buffer to use as last reference frame, 
used
+with inter-coded frames. The timestamp refers to the ``timestamp`` 
field in
+   struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()`
+   function to convert the struct :c:type:`timeval` in struct
+   :c:type:`v4l2_buffer` to a __u64.
+* - __u64
+  - ``golden_frame_ts``
+  - Timestamp 

[PATCH 3/7] media: uapi: vp8: Add proper kernel-doc documentation

[Ezequiel Garcia]

In preparation for making the interface public,
document all the structures.

Signed-off-by: Ezequiel Garcia 
---
 include/media/vp8-ctrls.h | 99 +++
 1 file changed, 99 insertions(+)

diff --git a/include/media/vp8-ctrls.h b/include/media/vp8-ctrls.h
index f20117e825ef..9f6cb40088a6 100644
--- a/include/media/vp8-ctrls.h
+++ b/include/media/vp8-ctrls.h
@@ -23,6 +23,20 @@
 #define V4L2_VP8_SEGMENT_FLAG_UPDATE_FEATURE_DATA  0x04
 #define V4L2_VP8_SEGMENT_FLAG_DELTA_VALUE_MODE 0x08
 
+/**
+ * struct v4l2_vp8_segment - VP8 segment-based adjustments parameters
+ *
+ * @quant_update: update values for the segment quantizer.
+ * @lf_update: update values for the loop filter level.
+ * @segment_probs: branch probabilities of the segment_id decoding tree.
+ * @padding: padding field. Should be zeroed by applications.
+ * @flags: see V4L2_VP8_SEGMENT_FLAG_{}.
+ *
+ * This structure contains segment-based adjustments related parameters.
+ * See the 'update_segmentation()' part of the frame header syntax,
+ * and section '9.3. Segment-Based Adjustments' of the VP8 specification
+ * for more details.
+ */
 struct v4l2_vp8_segment {
__s8 quant_update[4];
__s8 lf_update[4];
@@ -34,6 +48,22 @@ struct v4l2_vp8_segment {
 #define V4L2_VP8_LF_ADJ_ENABLE 0x01
 #define V4L2_VP8_LF_DELTA_UPDATE   0x02
 #define V4L2_VP8_LF_FILTER_TYPE_SIMPLE 0x04
+
+/**
+ * struct v4l2_vp8_loop_filter - VP8 loop filter parameters
+ *
+ * @ref_frm_delta: Reference frame signed delta values.
+ * @mb_mode_delta: MB prediction mode signed delta values.
+ * @sharpness_level: matches sharpness_level syntax element.
+ * @level: matches loop_filter_level syntax element.
+ * @padding: padding field. Should be zeroed by applications.
+ * @flags: see V4L2_VP8_LF_FLAG_{}.
+ *
+ * This structure contains loop filter related parameters.
+ * See the 'mb_lf_adjustments()' part of the frame header syntax,
+ * and section '9.4. Loop Filter Type and Levels' of the VP8 specification
+ * for more details.
+ */
 struct v4l2_vp8_loop_filter {
__s8 ref_frm_delta[4];
__s8 mb_mode_delta[4];
@@ -43,6 +73,22 @@ struct v4l2_vp8_loop_filter {
__u32 flags;
 };
 
+/**
+ * struct v4l2_vp8_quantization - VP8 quantizattion indices
+ *
+ * @y_ac_qi: luma AC coefficient table index.
+ * @y_dc_delta: luma DC delta vaue.
+ * @y2_dc_delta: y2 block DC delta value.
+ * @y2_ac_delta: y2 block AC delta value.
+ * @uv_dc_delta: chroma DC delta value.
+ * @uv_ac_delta: chroma AC delta value.
+ * @padding: padding field. Should be zeroed by applications.
+
+ * This structure contains the quantization indices present
+ * in 'quant_indices()' part of the frame header syntax.
+ * See section '9.6. Dequantization Indices' of the VP8 specification
+ * for more details.
+ */
 struct v4l2_vp8_quantization {
__u8 y_ac_qi;
__s8 y_dc_delta;
@@ -55,6 +101,21 @@ struct v4l2_vp8_quantization {
 
 #define V4L2_VP8_COEFF_PROB_CNT 11
 #define V4L2_VP8_MV_PROB_CNT 19
+
+/**
+ * struct v4l2_vp8_entropy - VP8 update probabilities
+ *
+ * @coeff_probs: coefficient probability update values.
+ * @y_mode_probs: luma intra-prediction probabilities.
+ * @uv_mode_probs: chroma intra-prediction probabilities.
+ * @mv_probs: mv decoding probability.
+ * @padding: padding field. Should be zeroed by applications.
+ *
+ * This structure contains the update probabilities present in
+ * 'token_prob_update()' and 'mv_prob_update()' part of the frame header.
+ * See section '17.2. Probability Updates' of the VP8 specification
+ * for more details.
+ */
 struct v4l2_vp8_entropy {
__u8 coeff_probs[4][8][3][V4L2_VP8_COEFF_PROB_CNT];
__u8 y_mode_probs[4];
@@ -63,6 +124,17 @@ struct v4l2_vp8_entropy {
__u8 padding[3];
 };
 
+/**
+ * struct v4l2_vp8_entropy_coder_state - VP8 boolean coder state
+ *
+ * @range: coder state value for "Range"
+ * @value: coder state value for "Value"
+ * @bit_count: number of bits left in range "Value".
+ * @padding: padding field. Should be zeroed by applications.
+ *
+ * This structure contains the state for the boolean coder, as
+ * explained in section '7. Boolean Entropy Decoder' of the VP8 specification.
+ */
 struct v4l2_vp8_entropy_coder_state {
__u8 range;
__u8 value;
@@ -80,6 +152,33 @@ struct v4l2_vp8_entropy_coder_state {
 #define VP8_FRAME_IS_KEY_FRAME(hdr) \
(!!((hdr)->flags & V4L2_VP8_FRAME_FLAG_KEY_FRAME))
 
+/**
+ * struct v4l2_vp8_frame - VP8 frame parameters
+ *
+ * @seg: segmentation parameters. See _vp8_segment for more details
+ * @lf: loop filter parameters. See _vp8_loop_filter for more details
+ * @quant: quantization parameters. See _vp8_quantization for more details
+ * @probs: probabilities. See _vp9_probabilities for more details
+ * @width: frame width.
+ * @height: frame height.
+ * @horizontal_scale: horizontal scaling factor.
+ * @vertical_scale: vertical scaling factor.
+ * @version: bitstream version.
+ * 

[PATCH 2/7] media: uapi: vp8: Rename v4l2_vp8_loopfilter to v4l2_vp8_loop_filter

[Ezequiel Garcia]

Rename to struct v4l2_vp8_loop_filter, which is closer to the
VP8 syntax. This change is only cosmetics, but since this API
is exposed to userspace, it's worth the trouble to get it consistent.

Signed-off-by: Ezequiel Garcia 
---
 .../userspace-api/media/v4l/ext-ctrls-codec.rst  | 12 ++--
 drivers/staging/media/hantro/hantro_g1_vp8_dec.c |  2 +-
 drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c |  2 +-
 include/media/vp8-ctrls.h|  4 ++--
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst 
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index 006301e88554..8bbfea44a2ca 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1774,7 +1774,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
 * - struct :c:type:`v4l2_vp8_segment`
   - ``seg``
   - Structure with segment-based adjustments metadata.
-* - struct :c:type:`v4l2_vp8_loopfilter`
+* - struct :c:type:`v4l2_vp8_loop_filter`
   - ``lf``
   - Structure with loop filter level adjustments metadata.
 * - struct :c:type:`v4l2_vp8_quantization`
@@ -1958,13 +1958,13 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
   - If is set, the segment feature data mode is delta-value.
 If cleared, it's absolute-value.
 
-.. c:type:: v4l2_vp8_loopfilter
+.. c:type:: v4l2_vp8_loop_filter
 
 .. cssclass:: longtable
 
 .. tabularcolumns:: |p{1.5cm}|p{6.3cm}|p{9.4cm}|
 
-.. flat-table:: struct v4l2_vp8_loopfilter
+.. flat-table:: struct v4l2_vp8_loop_filter
 :header-rows:  0
 :stub-columns: 0
 :widths:   1 1 2
@@ -1986,11 +1986,11 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
   - Applications and drivers must set this to zero.
 * - __u32
   - ``flags``
-  - See :ref:`Loopfilter Flags `
+  - See :ref:`Loop Filter Flags `
 
-.. _vp8_loopfilter_flags:
+.. _vp8_loop_filter_flags:
 
-``Loopfilter Flags``
+``Loop Filter Flags``
 
 .. cssclass:: longtable
 
diff --git a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c 
b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
index 3f4311c1dab8..2de80fef07f4 100644
--- a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
@@ -136,7 +136,7 @@ static void cfg_lf(struct hantro_ctx *ctx,
   const struct v4l2_ctrl_vp8_frame *hdr)
 {
const struct v4l2_vp8_segment *seg = >seg;
-   const struct v4l2_vp8_loopfilter *lf = >lf;
+   const struct v4l2_vp8_loop_filter *lf = >lf;
struct hantro_dev *vpu = ctx->dev;
unsigned int i;
u32 reg;
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c 
b/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
index 5c43f59ad531..cbca123db746 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
@@ -277,7 +277,7 @@ static void cfg_lf(struct hantro_ctx *ctx,
   const struct v4l2_ctrl_vp8_frame *hdr)
 {
const struct v4l2_vp8_segment *seg = >seg;
-   const struct v4l2_vp8_loopfilter *lf = >lf;
+   const struct v4l2_vp8_loop_filter *lf = >lf;
struct hantro_dev *vpu = ctx->dev;
unsigned int i;
u32 reg;
diff --git a/include/media/vp8-ctrls.h b/include/media/vp8-ctrls.h
index 86bb6e774604..f20117e825ef 100644
--- a/include/media/vp8-ctrls.h
+++ b/include/media/vp8-ctrls.h
@@ -34,7 +34,7 @@ struct v4l2_vp8_segment {
 #define V4L2_VP8_LF_ADJ_ENABLE 0x01
 #define V4L2_VP8_LF_DELTA_UPDATE   0x02
 #define V4L2_VP8_LF_FILTER_TYPE_SIMPLE 0x04
-struct v4l2_vp8_loopfilter {
+struct v4l2_vp8_loop_filter {
__s8 ref_frm_delta[4];
__s8 mb_mode_delta[4];
__u8 sharpness_level;
@@ -82,7 +82,7 @@ struct v4l2_vp8_entropy_coder_state {
 
 struct v4l2_ctrl_vp8_frame {
struct v4l2_vp8_segment seg;
-   struct v4l2_vp8_loopfilter lf;
+   struct v4l2_vp8_loop_filter lf;
struct v4l2_vp8_quantization quant;
struct v4l2_vp8_entropy entropy;
struct v4l2_vp8_entropy_coder_state coder_state;
-- 
2.30.0

[PATCH 5/7] media: uapi: Move the VP8 stateless control type out of staging

[Ezequiel Garcia]

Move the VP8 stateless control types out of staging,
and re-number it to avoid any confusion.

Signed-off-by: Ezequiel Garcia 
---
 include/media/vp8-ctrls.h  | 1 -
 include/uapi/linux/videodev2.h | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/media/vp8-ctrls.h b/include/media/vp8-ctrls.h
index 1a5a3d8ab444..051700f33863 100644
--- a/include/media/vp8-ctrls.h
+++ b/include/media/vp8-ctrls.h
@@ -14,7 +14,6 @@
 #include 
 
 #define V4L2_CID_MPEG_VIDEO_VP8_FRAME (V4L2_CID_CODEC_BASE + 2000)
-#define V4L2_CTRL_TYPE_VP8_FRAME 0x301
 
 #define V4L2_VP8_SEGMENT_FLAG_ENABLED  0x01
 #define V4L2_VP8_SEGMENT_FLAG_UPDATE_MAP   0x02
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index a1d903c6f9f0..611b75df7f17 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1793,6 +1793,8 @@ enum v4l2_ctrl_type {
V4L2_CTRL_TYPE_H264_PRED_WEIGHTS= 0x0205,
 
V4L2_CTRL_TYPE_FWHT_PARAMS  = 0x0220,
+
+   V4L2_CTRL_TYPE_VP8_FRAME= 0x0240,
 };
 
 /*  Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
-- 
2.30.0