[PATCH] sgl_alloc_order: memory leak

[Douglas Gilbert]

Noticed that when sgl_alloc_order() failed with order > 0 that
free memory on my machine shrank. That function shouldn't call
sgl_free() on its error path since that is only correct when
order==0 .

Signed-off-by: Douglas Gilbert 
---
 lib/scatterlist.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 5d63a8857f36..c448642e0f78 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -514,7 +514,7 @@ struct scatterlist *sgl_alloc_order(unsigned long long 
length,
elem_len = min_t(u64, length, PAGE_SIZE << order);
page = alloc_pages(gfp, order);
if (!page) {
-   sgl_free(sgl);
+   sgl_free_order(sgl, order);
return NULL;
}
 
-- 
2.25.1

Re: [PATCH v2 2/2] Input: atmel_mxt_ts - wake mXT1386 from deep-sleep mode

[Wang, Jiada]

Hi Dmitry

On 2020/09/20 4:49, Dmitry Osipenko wrote:

18.09.2020 18:55, Wang, Jiada пишет:
...

   +static void mxt_wake(struct mxt_data *data)
+{
+    struct i2c_client *client = data->client;
+    struct device *dev = >client->dev;
+    struct device_node *np = dev->of_node;
+    union i2c_smbus_data dummy;
+
+    if (!of_device_is_compatible(np, "atmel,mXT1386"))
+    return;

I'm not sure whether you misses the previous answers from Dmitry
Torokhov and Rob Herring, but they suggested to add a new device-tree
property which should specify the atmel,wakeup-method.


I think Rob Herring prefers for the compatible solution than property.


Actually, seems you're right. But I'm not sure now whether he just made
a typo, because it's actually a board-specific option.


Right, I think since it is a board specific issue,
so "property" is the preferred way,
if I understand you correctly,
compatible combine with property is what you are suggesting, right?


It could be more preferred to skip the i2c_smbus_xfer() for the NONE
variant, but it also should be harmless in practice. I guess we indeed
could keep the current variant of yours patch and then add a clarifying
comment to the commit message and to the code, telling that
i2c_smbus_xfer() is harmless in a case of the hardwired WAKE-LINE.


I will skip dummy read for "NONE" variant.


There are 3 possible variants:

    - NONE
    - GPIO
    - I2C-SCL

Hence we should bail out from mxt_wake() if method is set to NONE or
GPIO.


for "GPIO", we still need 25 ms sleep. but rather than a dummy read,
WAKE line need to be asserted before sleep.


Correct, I just meant to bail out because GPIO is currently unsupported.



OK


...

   static int mxt_initialize(struct mxt_data *data)
   {
   struct i2c_client *client = data->client;
   int recovery_attempts = 0;
   int error;
   +    mxt_wake(data);
+
   while (1) {


I assume the mxt_wake() should be placed here, since there is a 3
seconds timeout in the end of the while-loop, meaning that device may
get back into deep-sleep on a retry.


Can you elaborate a little more why exit from bootload mode after sleep
for 3 second could enter deep-sleep mode.


The loop attempts to exit from bootload mode and then I suppose
mxt_read_info_block() may fail if I2C "accidentally" fails, hence the
deep-sleep mode still will be enabled on a retry.

The datasheet says that there are 2 seconds since the time of the last
I2C access before TS is put back into auto-sleep if deep-sleep mode is
enabled. The wait-loop has msleep(3000).


OK, thanks for the clarification

Thanks,
Jiada

INVESTMENT OFFER / OFFRE D’INVESTISSEMENT

[Mr Tolar OKANSE]

INVESTMENT OFFER

I am Mr Tolar OKANSE, financial advisor, property and private 
assets. I found your contact through a search through the 
Internet and I apologize for this unexpected intrusion on my part 
and the surprised effect it may cause given everything that is 
currently happening on the Internet.

Indeed, I am in direct contact with a Libyan community 
(Politicians, Traders, Businessmen and Military) resident in 
Ghana. The latter have significant funds and would like to make 
investments and investments with their funds in all profitable 
areas and they are looking for a serious manager to whom to 
entrust all management.

If you are interested in my offer, I will put you in contact with 
their representative on site for more details and information.


Please contact me directly at my email address: 
tolaroka...@gmail.com

Cordially...
Mr T. Okanse

…….

OFFRE D’INVESTISSEMENT

Je suis Mr Tolar OKANSE, conseiller financier, des biens et de 
patrimoines privés. J'ai trouvé votre contact suite à une 
recherche via l'Internet et je vous prie de m'excuser pour cette 
intrusion inattendue de ma part et l'effet surpris que cela peut 
causer vu tout ce qui se passe actuellement sur l'Internet.

En effet, je suis en contact direct avec une communauté libyenne 
(Politiciens, Commerçants, Hommes d’affaire et Militaires) 
résidents au Ghana.  Ces derniers disposent d’importants fonds et 
souhaiteraient faire des placements et investissement avec ses 
fonds dans tous les domaines rentables et  ils sont à la 
recherche de manager sérieux à qui confier  toute la gérance.

Dans le cas où vous serez intéressés par mon offre, je vous 
mettrai en contact avec leur représentant sur place pour plus 
amples détails et informations.


Veuillez bien vouloir me contacter directement à mon adresse e-
mail : tolaroka...@gmail.com

Cordialement...
Mr T. Okanse


-- 
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

drivers/vdpa/mlx5/core/resources.c:33: undefined reference to `mlx5_cmd_exec'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   eb5f95f1593f7c22dac681b19e815828e2af3efd
commit: 29064bfdabd5ef49eac6909d3a36a075e3b52255 vdpa/mlx5: Add support library 
for mlx5 VDPA implementation
date:   6 weeks ago
config: riscv-randconfig-p002-20200919 (attached as .config)
compiler: riscv32-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 29064bfdabd5ef49eac6909d3a36a075e3b52255
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=riscv 

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

All errors (new ones prefixed by >>):

   riscv32-linux-ld: drivers/vdpa/mlx5/core/resources.o: in function 
`dealloc_pd':
>> drivers/vdpa/mlx5/core/resources.c:33: undefined reference to `mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/core/resources.o: in function 
`destroy_uctx':
   drivers/vdpa/mlx5/core/resources.c:85: undefined reference to `mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/core/resources.o: in function 
`mlx5_vdpa_create_tis':
   drivers/vdpa/mlx5/core/resources.c:95: undefined reference to `mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/core/resources.o: in function 
`mlx5_vdpa_destroy_tis':
   drivers/vdpa/mlx5/core/resources.c:109: undefined reference to 
`mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/core/resources.o: in function 
`mlx5_vdpa_create_rqt':
   drivers/vdpa/mlx5/core/resources.c:118: undefined reference to 
`mlx5_cmd_exec'
   riscv32-linux-ld: 
drivers/vdpa/mlx5/core/resources.o:drivers/vdpa/mlx5/core/resources.c:132: more 
undefined references to `mlx5_cmd_exec' follow
   riscv32-linux-ld: drivers/vdpa/mlx5/core/resources.o: in function 
`mlx5_vdpa_alloc_resources':
>> drivers/vdpa/mlx5/core/resources.c:230: undefined reference to 
>> `mlx5_get_uars_page'
   riscv32-linux-ld: drivers/vdpa/mlx5/core/resources.o: in function 
`create_uctx':
   drivers/vdpa/mlx5/core/resources.c:69: undefined reference to `mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/core/resources.o: in function 
`mlx5_vdpa_alloc_resources':
>> drivers/vdpa/mlx5/core/resources.c:263: undefined reference to 
>> `mlx5_put_uars_page'
   riscv32-linux-ld: drivers/vdpa/mlx5/core/resources.o: in function `alloc_pd':
   drivers/vdpa/mlx5/core/resources.c:18: undefined reference to `mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/core/resources.o: in function 
`get_null_mkey':
   drivers/vdpa/mlx5/core/resources.c:44: undefined reference to `mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/core/resources.o: in function 
`mlx5_vdpa_free_resources':
   drivers/vdpa/mlx5/core/resources.c:278: undefined reference to 
`mlx5_put_uars_page'

# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29064bfdabd5ef49eac6909d3a36a075e3b52255
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 29064bfdabd5ef49eac6909d3a36a075e3b52255
vim +33 drivers/vdpa/mlx5/core/resources.c

24  
25  static int dealloc_pd(struct mlx5_vdpa_dev *dev, u32 pdn, u16 uid)
26  {
27  u32 in[MLX5_ST_SZ_DW(dealloc_pd_in)] = {};
28  struct mlx5_core_dev *mdev = dev->mdev;
29  
30  MLX5_SET(dealloc_pd_in, in, opcode, MLX5_CMD_OP_DEALLOC_PD);
31  MLX5_SET(dealloc_pd_in, in, pd, pdn);
32  MLX5_SET(dealloc_pd_in, in, uid, uid);
  > 33  return mlx5_cmd_exec_in(mdev, dealloc_pd, in);
34  }
35  
36  static int get_null_mkey(struct mlx5_vdpa_dev *dev, u32 *null_mkey)
37  {
38  u32 out[MLX5_ST_SZ_DW(query_special_contexts_out)] = {};
39  u32 in[MLX5_ST_SZ_DW(query_special_contexts_in)] = {};
40  struct mlx5_core_dev *mdev = dev->mdev;
41  int err;
42  
43  MLX5_SET(query_special_contexts_in, in, opcode, 
MLX5_CMD_OP_QUERY_SPECIAL_CONTEXTS);
44  err = mlx5_cmd_exec_inout(mdev, query_special_contexts, in, 
out);
45  if (!err)
46  *null_mkey = MLX5_GET(query_special_contexts_out, out, 
null_mkey);
47  return err;
48  }
49  
50  static int create_uctx(struct mlx5_vdpa_dev *mvdev, u16 *uid)
51  {
52  u32 out[MLX5_ST_SZ_DW(create_uctx_out)] = {};
53  int inlen;
54  void *in;
55  int err;
56  
57  /* 0 means not supported */
58  if (!MLX5_CAP_GEN(mvdev->mdev, log_max_uctx))
59  return -EOPNOTSUPP;
60  
61  inlen = MLX5_ST_SZ_BYTES(create_uctx_in);
62  in = kzalloc(inlen, GFP_KERNEL);
63 

Re: [PATCH] mm/gup: protect unpin_user_pages() against npages==-ERRNO

[John Hubbard]

On 9/19/20 8:03 PM, Souptick Joarder wrote:

On Thu, Sep 17, 2020 at 1:11 PM Dan Carpenter  wrote:

On Wed, Sep 16, 2020 at 11:57:06PM -0700, John Hubbard wrote:

As suggested by Dan Carpenter, fortify unpin_user_pages() just a bit,
against a typical caller mistake: check if the npages arg is really a
-ERRNO value, which would blow up the unpinning loop: WARN and return.

If this new WARN_ON() fires, then the system *might* be leaking pages
(by leaving them pinned), but probably not. More likely, gup/pup
returned a hard -ERRNO error to the caller, who erroneously passed it
here.

...


Do we need a similar check inside unpin_user_pages_dirty_lock(),
when make_dirty set to false ?



Maybe not. This call is rarely if ever used for error handling, but
rather, for finishing up a successful use of the pages.

There is a balance between protecting against buggy callers and just
fixing any buggy callers. There is also a limit to how much code one can
write in hopes of avoiding bugs in...code that one writes. :)  Which is
why static analysis, unit and regression tests, code reviews are
important too.

Here, I submit that that we're about to cross the line and go too far.
But if you have any examples of buggy callers for
unpin_user_pages_dirty_lock(), that might shift the line.

Or maybe others feel that we haven't gone far enough yet after all?


thanks,
--
John Hubbard
NVIDIA

[git pull] Input updates for v5.9-rc5

[Dmitry Torokhov]

Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. Just a couple of driver
quirks.

Changelog:
-

Hans de Goede (1):
  Input: i8042 - add Entroware Proteus EL07R4 to nomux and reset lists

Vincent Huang (1):
  Input: trackpoint - add new trackpoint variant IDs

Diffstat:


 drivers/input/mouse/trackpoint.c  | 10 ++
 drivers/input/mouse/trackpoint.h  | 10 ++
 drivers/input/serio/i8042-x86ia64io.h | 16 
 3 files changed, 28 insertions(+), 8 deletions(-)

Thanks.


-- 
Dmitry

[GIT PULL] Kbuild fixes for v5.9-rc6

[Masahiro Yamada]

Hi Linus,

Please pull more fixes.
Thanks.




The following changes since commit 856deb866d16e29bd65952e0289066f6078af773:

  Linux 5.9-rc5 (2020-09-13 16:06:00 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kbuild-fixes-v5.9-3

for you to fetch changes up to a46afd11414758233f23798cc5be51e554d04efe:

  kconfig: qconf: revive help message in the info view (2020-09-20
12:58:54 +0900)


Kbuild fixes for v5.9 (3rd)

 - fix qconf warnings and revive help message


Masahiro Yamada (3):
  kconfig: qconf: use delete[] instead of delete to free array (again)
  kconfig: qconf: fix incomplete type 'struct gstr' warning
  kconfig: qconf: revive help message in the info view

 scripts/kconfig/lkc.h   | 47
++-
 scripts/kconfig/lkc_proto.h | 14 --
 scripts/kconfig/qconf.cc| 13 +
 3 files changed, 39 insertions(+), 35 deletions(-)


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] mm/gup: protect unpin_user_pages() against npages==-ERRNO

[Souptick Joarder]

On Thu, Sep 17, 2020 at 1:11 PM Dan Carpenter  wrote:
>
> On Wed, Sep 16, 2020 at 11:57:06PM -0700, John Hubbard wrote:
> > As suggested by Dan Carpenter, fortify unpin_user_pages() just a bit,
> > against a typical caller mistake: check if the npages arg is really a
> > -ERRNO value, which would blow up the unpinning loop: WARN and return.
> >
> > If this new WARN_ON() fires, then the system *might* be leaking pages
> > (by leaving them pinned), but probably not. More likely, gup/pup
> > returned a hard -ERRNO error to the caller, who erroneously passed it
> > here.
> >
> > Cc: Ira Weiny 
> > Cc: Souptick Joarder 
> > Signed-off-by: Dan Carpenter 
> > Signed-off-by: John Hubbard 
> > ---
> >
> > Hi Dan,
> >
> > Is is OK to use your signed-off-by here? Since you came up with this.
> >
>
> Yeah.  That's fine.

Do we need a similar check inside unpin_user_pages_dirty_lock(),
when make_dirty set to false ?

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

[Al Viro]

On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote:

> > 2) have you counted the syscalls that do and do not need that?
> 
> No.

Might be illuminating...

> > 3) how many of those realistically *can* be unified with their
> > compat counterparts?  [hint: ioctl(2) cannot]
> 
> There would be no requirement to unify anything.  The idea is that
> we'd get rid of all the global state flags.

_What_ global state flags?  When you have separate SYSCALL_DEFINE3(ioctl...)
and COMPAT_SYSCALL_DEFINE3(ioctl...), there's no flags at all, global or
local.  They only come into the play when you try to share the same function
for both, right on the top level.

> For ioctl, we'd have a new file_operation:
> 
> long ioctl(struct file *, unsigned int, unsigned long, enum syscall_arch);
> 
> I'm not saying this is easy, but I think it's possible and the result
> would be more obviously correct than what we have now.

No, it would not.  Seriously, from time to time a bit of RTFS before grand
proposals turns out to be useful.

Re: [PATCH] tee: fix some comment typos in header files

[Gustavo A. R. Silva]

Hi,

Here is another one you can solve:

$ git grep -nw overlfow
net/sctp/tsnmap.c:78:* overlfow our map

Thanks
--
Gustavo

On 9/19/20 20:58, Elvira Khabirova wrote:
> struct tee_param: revc -> recv.
> TEE_IOC_SUPPL_SEND: typo introduced by copy-pasting, replace invalid
> description with description from the according argument struct.
> 
> Signed-off-by: Elvira Khabirova 
> ---
>  include/linux/tee_drv.h  | 2 +-
>  include/uapi/linux/tee.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
> index d074302989dd..61557bc0e29f 100644
> --- a/include/linux/tee_drv.h
> +++ b/include/linux/tee_drv.h
> @@ -85,7 +85,7 @@ struct tee_param {
>   * @close_session:   close a session
>   * @invoke_func: invoke a trusted function
>   * @cancel_req:  request cancel of an ongoing invoke or open
> - * @supp_revc:   called for supplicant to get a command
> + * @supp_recv:   called for supplicant to get a command
>   * @supp_send:   called for supplicant to send a response
>   * @shm_register:register shared memory buffer in TEE
>   * @shm_unregister:  unregister shared memory buffer in TEE
> diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h
> index b619f37ee03e..7546be5ed4f8 100644
> --- a/include/uapi/linux/tee.h
> +++ b/include/uapi/linux/tee.h
> @@ -342,7 +342,7 @@ struct tee_iocl_supp_send_arg {
>  };
>  
>  /**
> - * TEE_IOC_SUPPL_SEND - Receive a request for a supplicant function
> + * TEE_IOC_SUPPL_SEND - Send a response to a received request
>   *
>   * Takes a struct tee_ioctl_buf_data which contains a struct
>   * tee_iocl_supp_send_arg followed by any array of struct tee_param
> 

[PATCH] misc: mic: scif: Fix error handling path

[Souptick Joarder]

Inside __scif_pin_pages(), when map_flags != SCIF_MAP_KERNEL it
will call pin_user_pages_fast() to map nr_pages. However,
pin_user_pages_fast() might fail with a return value -ERRNO.

The return value is stored in pinned_pages->nr_pages. which in
turn is passed to unpin_user_pages(), which expects
pinned_pages->nr_pages >=0, else disaster.

Fix this by assigning pinned_pages->nr_pages to 0 if
pin_user_pages_fast() returns -ERRNO.

Fixes:  ba612aa8b487 ("misc: mic: SCIF memory registration and
unregistration")
Signed-off-by: Souptick Joarder 
Cc: John Hubbard 
Cc: Ira Weiny 
Cc: Dan Carpenter 
---
 drivers/misc/mic/scif/scif_rma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/mic/scif/scif_rma.c b/drivers/misc/mic/scif/scif_rma.c
index 2da3b47..18fb9d8 100644
--- a/drivers/misc/mic/scif/scif_rma.c
+++ b/drivers/misc/mic/scif/scif_rma.c
@@ -1392,6 +1392,8 @@ int __scif_pin_pages(void *addr, size_t len, int 
*out_prot,
(prot & SCIF_PROT_WRITE) ? FOLL_WRITE : 0,
pinned_pages->pages);
if (nr_pages != pinned_pages->nr_pages) {
+   if (pinned_pages->nr_pages < 0)
+   pinned_pages->nr_pages = 0;
if (try_upgrade) {
if (ulimit)
__scif_dec_pinned_vm_lock(mm, nr_pages);
@@ -1408,7 +1410,6 @@ int __scif_pin_pages(void *addr, size_t len, int 
*out_prot,
 
if (pinned_pages->nr_pages < nr_pages) {
err = -EFAULT;
-   pinned_pages->nr_pages = nr_pages;
goto dec_pinned;
}
 
@@ -1421,7 +1422,6 @@ int __scif_pin_pages(void *addr, size_t len, int 
*out_prot,
__scif_dec_pinned_vm_lock(mm, nr_pages);
/* Something went wrong! Rollback */
 error_unmap:
-   pinned_pages->nr_pages = nr_pages;
scif_destroy_pinned_pages(pinned_pages);
*pages = NULL;
dev_dbg(scif_info.mdev.this_device,
-- 
1.9.1

[PATCH] tee: fix some comment typos in header files

[Elvira Khabirova]

struct tee_param: revc -> recv.
TEE_IOC_SUPPL_SEND: typo introduced by copy-pasting, replace invalid
description with description from the according argument struct.

Signed-off-by: Elvira Khabirova 
---
 include/linux/tee_drv.h  | 2 +-
 include/uapi/linux/tee.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
index d074302989dd..61557bc0e29f 100644
--- a/include/linux/tee_drv.h
+++ b/include/linux/tee_drv.h
@@ -85,7 +85,7 @@ struct tee_param {
  * @close_session: close a session
  * @invoke_func:   invoke a trusted function
  * @cancel_req:request cancel of an ongoing invoke or open
- * @supp_revc: called for supplicant to get a command
+ * @supp_recv: called for supplicant to get a command
  * @supp_send: called for supplicant to send a response
  * @shm_register:  register shared memory buffer in TEE
  * @shm_unregister:unregister shared memory buffer in TEE
diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h
index b619f37ee03e..7546be5ed4f8 100644
--- a/include/uapi/linux/tee.h
+++ b/include/uapi/linux/tee.h
@@ -342,7 +342,7 @@ struct tee_iocl_supp_send_arg {
 };
 
 /**
- * TEE_IOC_SUPPL_SEND - Receive a request for a supplicant function
+ * TEE_IOC_SUPPL_SEND - Send a response to a received request
  *
  * Takes a struct tee_ioctl_buf_data which contains a struct
  * tee_iocl_supp_send_arg followed by any array of struct tee_param
-- 
2.28.0

Re: [PATCH] wireless: ath9k: hif_usb: fix race condition between usb_get_urb() and usb_kill_anchored_urbs()

[Brooke Basile]

On 9/11/20 3:14 AM, Brooke Basile wrote:

Calls to usb_kill_anchored_urbs() after usb_kill_urb() on multiprocessor
systems create a race condition in which usb_kill_anchored_urbs() deallocates
the URB before the completer callback is called in usb_kill_urb(), resulting
in a use-after-free.
To fix this, add proper lock protection to usb_kill_urb() calls that can
possibly run concurrently with usb_kill_anchored_urbs().

Reported-by: syzbot+89bd486af9427a9fc...@syzkaller.appspotmail.com
Link: 
https://syzkaller.appspot.com/bug?id=cabffad18eb74197f84871802fd2c5117b61febf
Signed-off-by: Brooke Basile 
---
  drivers/net/wireless/ath/ath9k/hif_usb.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 3f563e02d17d..2ed98aaed6fb 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -449,10 +449,19 @@ static void hif_usb_stop(void *hif_handle)
spin_unlock_irqrestore(_dev->tx.tx_lock, flags);

/* The pending URBs have to be canceled. */
+   spin_lock_irqsave(_dev->tx.tx_lock, flags);
list_for_each_entry_safe(tx_buf, tx_buf_tmp,
 _dev->tx.tx_pending, list) {
+   usb_get_urb(tx_buf->urb);
+   spin_unlock_irqrestore(_dev->tx.tx_lock, flags);
usb_kill_urb(tx_buf->urb);
+   list_del(_buf->list);
+   usb_free_urb(tx_buf->urb);
+   kfree(tx_buf->buf);
+   kfree(tx_buf);
+   spin_lock_irqsave(_dev->tx.tx_lock, flags);
}
+   spin_unlock_irqrestore(_dev->tx.tx_lock, flags);

usb_kill_anchored_urbs(_dev->mgmt_submitted);
  }
@@ -762,27 +771,37 @@ static void ath9k_hif_usb_dealloc_tx_urbs(struct 
hif_device_usb *hif_dev)
struct tx_buf *tx_buf = NULL, *tx_buf_tmp = NULL;
unsigned long flags;

+   spin_lock_irqsave(_dev->tx.tx_lock, flags);
list_for_each_entry_safe(tx_buf, tx_buf_tmp,
 _dev->tx.tx_buf, list) {
+   usb_get_urb(tx_buf->urb);
+   spin_unlock_irqrestore(_dev->tx.tx_lock, flags);
usb_kill_urb(tx_buf->urb);
list_del(_buf->list);
usb_free_urb(tx_buf->urb);
kfree(tx_buf->buf);
kfree(tx_buf);
+   spin_lock_irqsave(_dev->tx.tx_lock, flags);
}
+   spin_unlock_irqrestore(_dev->tx.tx_lock, flags);

spin_lock_irqsave(_dev->tx.tx_lock, flags);
hif_dev->tx.flags |= HIF_USB_TX_FLUSH;
spin_unlock_irqrestore(_dev->tx.tx_lock, flags);

+   spin_lock_irqsave(_dev->tx.tx_lock, flags);
list_for_each_entry_safe(tx_buf, tx_buf_tmp,
 _dev->tx.tx_pending, list) {
+   usb_get_urb(tx_buf->urb);
+   spin_unlock_irqrestore(_dev->tx.tx_lock, flags);
usb_kill_urb(tx_buf->urb);
list_del(_buf->list);
usb_free_urb(tx_buf->urb);
kfree(tx_buf->buf);
kfree(tx_buf);
+   spin_lock_irqsave(_dev->tx.tx_lock, flags);
}
+   spin_unlock_irqrestore(_dev->tx.tx_lock, flags);

usb_kill_anchored_urbs(_dev->mgmt_submitted);
  }
--
2.28.0



Hi,

Just wanted to check on the status of this patch, if there's anything 
wrong I'm happy to make it right.

Sorry to bother!

Best,
Brooke Basile

Re: [PULL REQUEST] i2c for 5.9

[pr-tracker-bot]

The pull request you sent on Sat, 19 Sep 2020 18:02:06 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c8d1a46f943877c08d1154a6f90f43a245a671cf

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

[PATCH] x86/boot: Delay BSP init until after FPU initialization

[Mike Hommey]

FPU initialization handles the clearcpuid command line argument. If it
comes after BSP init, clearcpuid cannot be used to disable features that
trigger some parts of the BSP init code.

Signed-off-by: Mike Hommey 
---
 arch/x86/kernel/cpu/common.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

I was trying to use clearcpuid=440 to disable X86_FEATURES_AMD_SSBD to
reproduce the behavior that happens on Zen/Zen+ on a Zen2 machine, but
that didn't work because the command line is handled after the setup for
X86_FEATURE_LS_CFG_SSBD.

I tought about either moving the command line handling earlier, but it
seems there wasn't a specific reason for BSP init being earlier than FPU
initialization so I went with reordering those instead.

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c5d6f17d9b9d..c3bbca91a14b 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1261,9 +1261,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
 
c->cpu_index = 0;
filter_cpuid_features(c, false);
-
-   if (this_cpu->c_bsp_init)
-   this_cpu->c_bsp_init(c);
} else {
setup_clear_cpu_cap(X86_FEATURE_CPUID);
}
@@ -1276,6 +1273,10 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
 
fpu__init_system(c);
 
+   if (have_cpuid_p()) {
+   if (this_cpu->c_bsp_init)
+   this_cpu->c_bsp_init(c);
+   }
 #ifdef CONFIG_X86_32
/*
 * Regardless of whether PCID is enumerated, the SDM says
-- 
2.28.0

Re: R: [PATCH v2 4/4] dt-bindings: net: Document use of mac-address-increment

[Andrew Lunn]

On Sun, Sep 20, 2020 at 02:39:39AM +0200, ansuels...@gmail.com wrote:
> 
> 
> > -Messaggio originale-
> > Da: Andrew Lunn 
> > Inviato: domenica 20 settembre 2020 02:31
> > A: Ansuel Smith 
> > Cc: Miquel Raynal ; Richard Weinberger
> > ; Vignesh Raghavendra ; Rob Herring
> > ; David S. Miller ; Jakub
> > Kicinski ; Heiner Kallweit ;
> > Russell King ; Frank Rowand
> > ; Boris Brezillon ; linux-
> > m...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; net...@vger.kernel.org
> > Oggetto: Re: [PATCH v2 4/4] dt-bindings: net: Document use of mac-
> > address-increment
> > 
> > > +  mac-address-increment:
> > > +description:
> > > +  The MAC address can optionally be increased (or decreased using
> > > +  negative values) from the original value readed (from a nvmem
> cell
> > 
> > Read is irregular, there is no readed, just read.
> > 
> > > +  for example). This can be used if the mac is readed from a
> dedicated
> > > +  partition and must be increased based on the number of device
> > > +  present in the system.
> > 
> > You should probably add there is no underflow/overflow to other bytes
> > of the MAC address. 00:01:02:03:04:ff + 1 == 00:01:02:03:04:00.
> > 
> > > +minimum: -255
> > > +maximum: 255
> > > +
> > > +  mac-address-increment-byte:
> > > +description:
> > > +  If 'mac-address-increment' is defined, this will tell what byte
> of
> > > +  the mac-address will be increased. If 'mac-address-increment' is
> > > +  not defined, this option will do nothing.
> > > +default: 5
> > > +minimum: 0
> > > +maximum: 5
> > 
> > Is there a real need for this? A value of 0 seems like a bad idea,
> > since a unicast address could easily become a multicast address, which
> > is not valid for an interface address. It also does not seem like a
> > good idea to allow the OUI to be changed. So i think only bytes 3-5
> > should be allowed, but even then, i don't think this is needed, unless
> > you do have a clear use case.
> > 
> > Andrew
> 
> Honestly the mac-address-increment-byte is added to give user some control
> but I
> don't really have a use case for it. Should I limit it to 3 or just remove
> the function?

If you have no use case, just remove it and document that last byte
will be incremented. I somebody does need it, it can be added in a
backwards compatible way.

 Andrew

R: [PATCH v2 4/4] dt-bindings: net: Document use of mac-address-increment

[ansuelsmth]

> -Messaggio originale-
> Da: Andrew Lunn 
> Inviato: domenica 20 settembre 2020 02:31
> A: Ansuel Smith 
> Cc: Miquel Raynal ; Richard Weinberger
> ; Vignesh Raghavendra ; Rob Herring
> ; David S. Miller ; Jakub
> Kicinski ; Heiner Kallweit ;
> Russell King ; Frank Rowand
> ; Boris Brezillon ; linux-
> m...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org
> Oggetto: Re: [PATCH v2 4/4] dt-bindings: net: Document use of mac-
> address-increment
> 
> > +  mac-address-increment:
> > +description:
> > +  The MAC address can optionally be increased (or decreased using
> > +  negative values) from the original value readed (from a nvmem
cell
> 
> Read is irregular, there is no readed, just read.
> 
> > +  for example). This can be used if the mac is readed from a
dedicated
> > +  partition and must be increased based on the number of device
> > +  present in the system.
> 
> You should probably add there is no underflow/overflow to other bytes
> of the MAC address. 00:01:02:03:04:ff + 1 == 00:01:02:03:04:00.
> 
> > +minimum: -255
> > +maximum: 255
> > +
> > +  mac-address-increment-byte:
> > +description:
> > +  If 'mac-address-increment' is defined, this will tell what byte
of
> > +  the mac-address will be increased. If 'mac-address-increment' is
> > +  not defined, this option will do nothing.
> > +default: 5
> > +minimum: 0
> > +maximum: 5
> 
> Is there a real need for this? A value of 0 seems like a bad idea,
> since a unicast address could easily become a multicast address, which
> is not valid for an interface address. It also does not seem like a
> good idea to allow the OUI to be changed. So i think only bytes 3-5
> should be allowed, but even then, i don't think this is needed, unless
> you do have a clear use case.
> 
> Andrew

Honestly the mac-address-increment-byte is added to give user some control
but I
don't really have a use case for it. Should I limit it to 3 or just remove
the function?
Will address the other 2 comment in v3.
Thx for review.

Apply For Your Business Loans

[Loan]

Our Financial Loan Grant scheme is Handled by the NAT-WEST BANK( NATIONAL 
WESTMINSTER BANK INTERNATIONAL.)
apply  Now !!!
For Offer of over $3000- $30million or your countries currency, funding support 
for Loan from National West-minister Bank." For more information, Contact us 
via email: manuelfrancobal...@gmail.com  with the following details Below
Name:
Amount:
Duration:
Country:
Phone Number:
Email:

Best Regards..
Mr Manuel Franco.
Finance Director
NOTE:
All responses should be forwarded to: manuelfrancobal...@gmail.com

Re: [PATCH v2 4/4] dt-bindings: net: Document use of mac-address-increment

[Andrew Lunn]

> +  mac-address-increment:
> +description:
> +  The MAC address can optionally be increased (or decreased using
> +  negative values) from the original value readed (from a nvmem cell

Read is irregular, there is no readed, just read.

> +  for example). This can be used if the mac is readed from a dedicated
> +  partition and must be increased based on the number of device
> +  present in the system.

You should probably add there is no underflow/overflow to other bytes
of the MAC address. 00:01:02:03:04:ff + 1 == 00:01:02:03:04:00.

> +minimum: -255
> +maximum: 255
> +
> +  mac-address-increment-byte:
> +description:
> +  If 'mac-address-increment' is defined, this will tell what byte of
> +  the mac-address will be increased. If 'mac-address-increment' is
> +  not defined, this option will do nothing.
> +default: 5
> +minimum: 0
> +maximum: 5

Is there a real need for this? A value of 0 seems like a bad idea,
since a unicast address could easily become a multicast address, which
is not valid for an interface address. It also does not seem like a
good idea to allow the OUI to be changed. So i think only bytes 3-5
should be allowed, but even then, i don't think this is needed, unless
you do have a clear use case.

Andrew

Re: [PATCH v3 2/2] net: mdio-ipq4019: add Clause 45 support

[Andrew Lunn]

> +
> +/* 0 = Clause 22, 1 = Clause 45 */
> +#define MDIO_MODE_BITBIT(8)

How about calling this MDIO_MODE_C45

> + /* Enter Clause 45 mode */
> + data = readl(priv->membase + MDIO_MODE_REG);
> +
> + data |= MDIO_MODE_BIT;
> +
> + writel(data, priv->membase + MDIO_MODE_REG);

It then becomes clearer what this does.

Otherwise this looks O.K.

  Andrew

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

[Andy Lutomirski]

On Sat, Sep 19, 2020 at 4:24 PM Al Viro  wrote:
>
> On Sat, Sep 19, 2020 at 03:53:40PM -0700, Andy Lutomirski wrote:
>
> > > It would not be a win - most of the syscalls don't give a damn
> > > about 32bit vs. 64bit...
> >
> > Any reasonable implementation would optimize it out for syscalls that don’t 
> > care.  Or it could be explicit:
> >
> > DEFINE_MULTIARCH_SYSCALL(...)
>
> 1) what would that look like?

In effect, it would work like this:

/* Arch-specific, but there's a generic case for sane architectures. */
enum syscall_arch {
  SYSCALL_NATIVE,
  SYSCALL_COMPAT,
  SYSCALL_X32,
};

DEFINE_MULTIARCH_SYSCALLn(args, arch)
{
  args are the args here, and arch is the arch.
}

> 2) have you counted the syscalls that do and do not need that?

No.

> 3) how many of those realistically *can* be unified with their
> compat counterparts?  [hint: ioctl(2) cannot]

There would be no requirement to unify anything.  The idea is that
we'd get rid of all the global state flags.

For ioctl, we'd have a new file_operation:

long ioctl(struct file *, unsigned int, unsigned long, enum syscall_arch);

I'm not saying this is easy, but I think it's possible and the result
would be more obviously correct than what we have now.

[PATCH v2 1/2] exfat: add exfat_update_inode()

[Tetsuhiro Kohada]

Integrate exfat_sync_inode() and mark_inode_dirty() as exfat_update_inode()
Also, return the result of _exfat_write_inode () when sync is specified.

Signed-off-by: Tetsuhiro Kohada 
---
Changes in v2
 - no change

fs/exfat/exfat_fs.h |  2 +-
 fs/exfat/file.c |  5 +
 fs/exfat/inode.c|  9 +++--
 fs/exfat/namei.c| 35 +++
 4 files changed, 16 insertions(+), 35 deletions(-)

diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h
index 44dc04520175..3152c01e47ed 100644
--- a/fs/exfat/exfat_fs.h
+++ b/fs/exfat/exfat_fs.h
@@ -467,7 +467,7 @@ int exfat_count_dir_entries(struct super_block *sb, struct 
exfat_chain *p_dir);
 
 /* inode.c */
 extern const struct inode_operations exfat_file_inode_operations;
-void exfat_sync_inode(struct inode *inode);
+int exfat_update_inode(struct inode *inode);
 struct inode *exfat_build_inode(struct super_block *sb,
struct exfat_dir_entry *info, loff_t i_pos);
 void exfat_hash_inode(struct inode *inode, loff_t i_pos);
diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index 4831a39632a1..dcc99349b816 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -247,10 +247,7 @@ void exfat_truncate(struct inode *inode, loff_t size)
goto write_size;
 
inode->i_ctime = inode->i_mtime = current_time(inode);
-   if (IS_DIRSYNC(inode))
-   exfat_sync_inode(inode);
-   else
-   mark_inode_dirty(inode);
+   exfat_update_inode(inode);
 
inode->i_blocks = ((i_size_read(inode) + (sbi->cluster_size - 1)) &
~(sbi->cluster_size - 1)) >> inode->i_blkbits;
diff --git a/fs/exfat/inode.c b/fs/exfat/inode.c
index 7f90204adef5..f307019afe88 100644
--- a/fs/exfat/inode.c
+++ b/fs/exfat/inode.c
@@ -91,10 +91,15 @@ int exfat_write_inode(struct inode *inode, struct 
writeback_control *wbc)
return ret;
 }
 
-void exfat_sync_inode(struct inode *inode)
+int exfat_update_inode(struct inode *inode)
 {
lockdep_assert_held(_SB(inode->i_sb)->s_lock);
-   __exfat_write_inode(inode, 1);
+
+   if (IS_DIRSYNC(inode))
+   return __exfat_write_inode(inode, 1);
+
+   mark_inode_dirty(inode);
+   return 0;
 }
 
 /*
diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
index b966b9120c9c..4febff3541a9 100644
--- a/fs/exfat/namei.c
+++ b/fs/exfat/namei.c
@@ -571,10 +571,7 @@ static int exfat_create(struct inode *dir, struct dentry 
*dentry, umode_t mode,
 
inode_inc_iversion(dir);
dir->i_ctime = dir->i_mtime = current_time(dir);
-   if (IS_DIRSYNC(dir))
-   exfat_sync_inode(dir);
-   else
-   mark_inode_dirty(dir);
+   exfat_update_inode(dir);
 
i_pos = exfat_make_i_pos();
inode = exfat_build_inode(sb, , i_pos);
@@ -822,10 +819,7 @@ static int exfat_unlink(struct inode *dir, struct dentry 
*dentry)
inode_inc_iversion(dir);
dir->i_mtime = dir->i_atime = current_time(dir);
exfat_truncate_atime(>i_atime);
-   if (IS_DIRSYNC(dir))
-   exfat_sync_inode(dir);
-   else
-   mark_inode_dirty(dir);
+   exfat_update_inode(dir);
 
clear_nlink(inode);
inode->i_mtime = inode->i_atime = current_time(inode);
@@ -856,10 +850,7 @@ static int exfat_mkdir(struct inode *dir, struct dentry 
*dentry, umode_t mode)
 
inode_inc_iversion(dir);
dir->i_ctime = dir->i_mtime = current_time(dir);
-   if (IS_DIRSYNC(dir))
-   exfat_sync_inode(dir);
-   else
-   mark_inode_dirty(dir);
+   exfat_update_inode(dir);
inc_nlink(dir);
 
i_pos = exfat_make_i_pos();
@@ -986,10 +977,7 @@ static int exfat_rmdir(struct inode *dir, struct dentry 
*dentry)
inode_inc_iversion(dir);
dir->i_mtime = dir->i_atime = current_time(dir);
exfat_truncate_atime(>i_atime);
-   if (IS_DIRSYNC(dir))
-   exfat_sync_inode(dir);
-   else
-   mark_inode_dirty(dir);
+   exfat_update_inode(dir);
drop_nlink(dir);
 
clear_nlink(inode);
@@ -1362,19 +1350,13 @@ static int exfat_rename(struct inode *old_dir, struct 
dentry *old_dentry,
new_dir->i_ctime = new_dir->i_mtime = new_dir->i_atime =
EXFAT_I(new_dir)->i_crtime = current_time(new_dir);
exfat_truncate_atime(_dir->i_atime);
-   if (IS_DIRSYNC(new_dir))
-   exfat_sync_inode(new_dir);
-   else
-   mark_inode_dirty(new_dir);
+   exfat_update_inode(new_dir);
 
i_pos = ((loff_t)EXFAT_I(old_inode)->dir.dir << 32) |
(EXFAT_I(old_inode)->entry & 0x);
exfat_unhash_inode(old_inode);
exfat_hash_inode(old_inode, i_pos);
-   if (IS_DIRSYNC(new_dir))
-   exfat_sync_inode(old_inode);
-   else
-   mark_inode_dirty(old_inode);
+   exfat_update_inode(old_inode);
 
if (S_ISDIR(old_inode->i_mode) && old_dir != new_dir) {

[PATCH v2 2/2] exfat: aggregate dir-entry updates into __exfat_write_inode().

[Tetsuhiro Kohada]

The following function writes the updated inode information as dir-entry
by themselves.
 - __exfat_truncate()
 - exfat_map_cluster()
 - exfat_find_empty_entry()
Aggregate these writes into __exfat_write_inode().

Also, in __exfat_write_inode(), rename 'on_disk_size' to 'filesize' and
add adjustment when filesize is 0.

Reported-by: kernel test robot 
Signed-off-by: Tetsuhiro Kohada 
---
Changes in v2
 - Fix endian issue

 fs/exfat/file.c  | 49 +---
 fs/exfat/inode.c | 42 +++--
 fs/exfat/namei.c | 26 +
 3 files changed, 21 insertions(+), 96 deletions(-)

diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index dcc99349b816..d5b026183387 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -100,7 +100,7 @@ int __exfat_truncate(struct inode *inode, loff_t new_size)
struct super_block *sb = inode->i_sb;
struct exfat_sb_info *sbi = EXFAT_SB(sb);
struct exfat_inode_info *ei = EXFAT_I(inode);
-   int evict = (ei->dir.dir == DIR_DELETED) ? 1 : 0;
+   int ret;
 
/* check if the given file ID is opened */
if (ei->type != TYPE_FILE && ei->type != TYPE_DIR)
@@ -150,49 +150,10 @@ int __exfat_truncate(struct inode *inode, loff_t new_size)
ei->attr |= ATTR_ARCHIVE;
 
/* update the directory entry */
-   if (!evict) {
-   struct timespec64 ts;
-   struct exfat_dentry *ep, *ep2;
-   struct exfat_entry_set_cache *es;
-   int err;
-
-   es = exfat_get_dentry_set(sb, &(ei->dir), ei->entry,
-   ES_ALL_ENTRIES);
-   if (!es)
-   return -EIO;
-   ep = exfat_get_dentry_cached(es, 0);
-   ep2 = exfat_get_dentry_cached(es, 1);
-
-   ts = current_time(inode);
-   exfat_set_entry_time(sbi, ,
-   >dentry.file.modify_tz,
-   >dentry.file.modify_time,
-   >dentry.file.modify_date,
-   >dentry.file.modify_time_cs);
-   ep->dentry.file.attr = cpu_to_le16(ei->attr);
-
-   /* File size should be zero if there is no cluster allocated */
-   if (ei->start_clu == EXFAT_EOF_CLUSTER) {
-   ep2->dentry.stream.valid_size = 0;
-   ep2->dentry.stream.size = 0;
-   } else {
-   ep2->dentry.stream.valid_size = cpu_to_le64(new_size);
-   ep2->dentry.stream.size = ep2->dentry.stream.valid_size;
-   }
-
-   if (new_size == 0) {
-   /* Any directory can not be truncated to zero */
-   WARN_ON(ei->type != TYPE_FILE);
-
-   ep2->dentry.stream.flags = ALLOC_FAT_CHAIN;
-   ep2->dentry.stream.start_clu = EXFAT_FREE_CLUSTER;
-   }
-
-   exfat_update_dir_chksum_with_entry_set(es);
-   err = exfat_free_dentry_set(es, inode_needs_sync(inode));
-   if (err)
-   return err;
-   }
+   inode->i_mtime = current_time(inode);
+   ret = exfat_update_inode(inode);
+   if (ret)
+   return ret;
 
/* cut off from the FAT chain */
if (ei->flags == ALLOC_FAT_CHAIN && last_clu != EXFAT_FREE_CLUSTER &&
diff --git a/fs/exfat/inode.c b/fs/exfat/inode.c
index f307019afe88..74e105e95942 100644
--- a/fs/exfat/inode.c
+++ b/fs/exfat/inode.c
@@ -19,7 +19,7 @@
 
 static int __exfat_write_inode(struct inode *inode, int sync)
 {
-   unsigned long long on_disk_size;
+   unsigned long long filesize;
struct exfat_dentry *ep, *ep2;
struct exfat_entry_set_cache *es = NULL;
struct super_block *sb = inode->i_sb;
@@ -68,13 +68,14 @@ static int __exfat_write_inode(struct inode *inode, int 
sync)
NULL);
 
/* File size should be zero if there is no cluster allocated */
-   on_disk_size = i_size_read(inode);
-
+   filesize = i_size_read(inode);
if (ei->start_clu == EXFAT_EOF_CLUSTER)
-   on_disk_size = 0;
+   filesize = 0;
 
-   ep2->dentry.stream.valid_size = cpu_to_le64(on_disk_size);
+   ep2->dentry.stream.valid_size = cpu_to_le64(filesize);
ep2->dentry.stream.size = ep2->dentry.stream.valid_size;
+   ep2->dentry.stream.flags = filesize ? ei->flags : ALLOC_FAT_CHAIN;
+   ep2->dentry.stream.start_clu = cpu_to_le32(filesize ? ei->start_clu : 
EXFAT_FREE_CLUSTER);
 
exfat_update_dir_chksum_with_entry_set(es);
return exfat_free_dentry_set(es, sync);
@@ -223,32 +224,11 @@ static int exfat_map_cluster(struct inode *inode, 
unsigned int clu_offset,
num_clusters += num_to_be_allocated;
*clu = new_clu.dir;
 
-   if (ei->dir.dir != 

Re: [PATCH net-next v2 0/3] 100base Fx link modes

[David Miller]

From: Dan Murphy 
Date: Fri, 18 Sep 2020 14:14:50 -0500

> As per patch https://lore.kernel.org/patchwork/patch/1300241/ the link
> modes for 100base FX full and half duplex modes did not exist.  Adding these
> link modes to the core and ethtool allow devices like the DP83822, DP83869 and
> Broadcomm PHYs to properly advertise the correct mode for Fiber 100Mbps.
> 
> Corresponding user land ethtool patches are available but rely on these 
> patches
> to be applied first.

Series applied, thank you.

Re: [PATCH net-next] net/packet: Fix a comment about network_header

[David Miller]

From: Xie He 
Date: Fri, 18 Sep 2020 06:56:16 -0700

> skb->nh.raw has been renamed as skb->network_header in 2007, in
> commit b0e380b1d8a8 ("[SK_BUFF]: unions of just one member don't get
>   anything done, kill them")
> 
> So here we change it to the new name.
> 
> Cc: Willem de Bruijn 
> Signed-off-by: Xie He 

Applied.

Re: [PATCH 1/2] ethtool: improve compat ioctl handling

[David Miller]

From: Arnd Bergmann 
Date: Fri, 18 Sep 2020 14:05:18 +0200

> --- a/net/ethtool/ioctl.c
> +++ b/net/ethtool/ioctl.c
 ...
> +static inline bool ethtool_translate_compat(void)
> +{

Please don't use the inline keyword in foo.c files.

Thank you.

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

[Al Viro]

On Sat, Sep 19, 2020 at 03:53:40PM -0700, Andy Lutomirski wrote:

> > It would not be a win - most of the syscalls don't give a damn
> > about 32bit vs. 64bit...
> 
> Any reasonable implementation would optimize it out for syscalls that don’t 
> care.  Or it could be explicit:
> 
> DEFINE_MULTIARCH_SYSCALL(...)

1) what would that look like?
2) have you counted the syscalls that do and do not need that?
3) how many of those realistically *can* be unified with their
compat counterparts?  [hint: ioctl(2) cannot]

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

[Andy Lutomirski]

> On Sep 19, 2020, at 3:41 PM, Al Viro  wrote:
> 
> On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote:
>> 
 On Sep 19, 2020, at 3:09 PM, Al Viro  wrote:
>>> 
>>> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> Said that, why not provide a variant that would take an explicit
> "is it compat" argument and use it there?  And have the normal
> one pass in_compat_syscall() to that...
 
 That would help to not introduce a regression with this series yes.
 But it wouldn't fix existing bugs when io_uring is used to access
 read or write methods that use in_compat_syscall().  One example that
 I recently ran into is drivers/scsi/sg.c.
>>> 
>>> So screw such read/write methods - don't use them with io_uring.
>>> That, BTW, is one of the reasons I'm sceptical about burying the
>>> decisions deep into the callchain - we don't _want_ different
>>> data layouts on read/write depending upon the 32bit vs. 64bit
>>> caller, let alone the pointer-chasing garbage that is /dev/sg.
>> 
>> Well, we could remove in_compat_syscall(), etc and instead have an implicit 
>> parameter in DEFINE_SYSCALL.  Then everything would have to be explicit.  
>> This would probably be a win, although it could be quite a bit of work.
> 
> It would not be a win - most of the syscalls don't give a damn
> about 32bit vs. 64bit...

Any reasonable implementation would optimize it out for syscalls that don’t 
care.  Or it could be explicit:

DEFINE_MULTIARCH_SYSCALL(...)

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

[Al Viro]

On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote:
> 
> > On Sep 19, 2020, at 3:09 PM, Al Viro  wrote:
> > 
> > On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
> >>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> >>> Said that, why not provide a variant that would take an explicit
> >>> "is it compat" argument and use it there?  And have the normal
> >>> one pass in_compat_syscall() to that...
> >> 
> >> That would help to not introduce a regression with this series yes.
> >> But it wouldn't fix existing bugs when io_uring is used to access
> >> read or write methods that use in_compat_syscall().  One example that
> >> I recently ran into is drivers/scsi/sg.c.
> > 
> > So screw such read/write methods - don't use them with io_uring.
> > That, BTW, is one of the reasons I'm sceptical about burying the
> > decisions deep into the callchain - we don't _want_ different
> > data layouts on read/write depending upon the 32bit vs. 64bit
> > caller, let alone the pointer-chasing garbage that is /dev/sg.
> 
> Well, we could remove in_compat_syscall(), etc and instead have an implicit 
> parameter in DEFINE_SYSCALL.  Then everything would have to be explicit.  
> This would probably be a win, although it could be quite a bit of work.

It would not be a win - most of the syscalls don't give a damn
about 32bit vs. 64bit...

[PATCH v2 4/4] dt-bindings: net: Document use of mac-address-increment

[Ansuel Smith]

Two new bindings are now supported by the of_net driver to increase (or
decrease) a mac-address. This can be very useful in case where the
system extract the mac-address for the device from a dedicated partition
and have a generic mac-address that needs to be incremented based on the
device number.
- mac-address-increment-byte is used to tell what byte must be
  incremented (if not set the last byte is increased)
- mac-address-increment is used to tell how much to increment of the
  extracted mac-address decided byte.

Signed-off-by: Ansuel Smith 
---
 .../bindings/net/ethernet-controller.yaml | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml 
b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
index fa2baca8c726..43f2f21faf41 100644
--- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -32,6 +32,25 @@ properties:
   - minItems: 6
 maxItems: 6
 
+  mac-address-increment:
+description:
+  The MAC address can optionally be increased (or decreased using
+  negative values) from the original value readed (from a nvmem cell
+  for example). This can be used if the mac is readed from a dedicated
+  partition and must be increased based on the number of device
+  present in the system.
+minimum: -255
+maximum: 255
+
+  mac-address-increment-byte:
+description:
+  If 'mac-address-increment' is defined, this will tell what byte of
+  the mac-address will be increased. If 'mac-address-increment' is
+  not defined, this option will do nothing.
+default: 5
+minimum: 0
+maximum: 5
+
   max-frame-size:
 $ref: /schemas/types.yaml#definitions/uint32
 description:
-- 
2.27.0

[PATCH v2 2/4] dt-bindings: mtd: partition: Document use of nvmem-provider

[Ansuel Smith]

Document the use of this 2 new bindings, nvmem-provider and nvmem-cell,
used to describe the nvmem cell that the subpartition provide to the
nvmem api and the system. Nvmem cell are direct subnode of the
subpartition and are skipped by the 'fixed-partitions' parser if they
contain the 'nvmem-cell' tag. The subpartition must have the
'nvmem-provider' tag or the subpartition will not register the cell to
the nvmem api.

Signed-off-by: Ansuel Smith 
---
 .../devicetree/bindings/mtd/partition.txt | 59 +++
 1 file changed, 59 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
b/Documentation/devicetree/bindings/mtd/partition.txt
index 4a39698221a2..66d3a3f0a021 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -64,6 +64,16 @@ Optional properties:
 - slc-mode: This parameter, if present, allows one to emulate SLC mode on a
   partition attached to an MLC NAND thus making this partition immune to
   paired-pages corruptions
+- nvmem-provider : Optionally a subpartition can be set as a nvmem-provider. 
This can
+  be very useful if some data like the mac-address is stored in a special 
partition
+  at a specific offset. Subpartition that describe nvmem-cell must have set the
+  'nvmem-cell' of they will be treated as a subpartition and not skipped and 
registred
+  as nvmem cells. In this specific case '#address-cells' and '#size-cells' 
must be
+  provided.
+- nvmem-cell : A direct subnode of a subpartition can be described as a 
nvmem-cell and
+  skipped by the fixed-partition parser and registred as a nvmem-cell of the 
registred
+  nvmem subpartition IF it does contain the 'nvmem-provider tag. If the 
subpartition
+  lacks of such tag the subnode will be skipped and the nvmem api won't 
register them.
 
 Examples:
 
@@ -158,3 +168,52 @@ flash@3 {
};
};
 };
+
+flash@0 {
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x000 0x10>;
+   read-only;
+   };
+
+   art: art@120 {
+   label = "art";
+   reg = <0x120 0x014>;
+   read-only;
+   nvmem-provider;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   macaddr_gmac1: macaddr_gmac1@0 {
+   nvmem-cell;
+   reg = <0x0 0x6>;
+   };
+
+   macaddr_gmac2: macaddr_gmac2@6 {
+   nvmem-cell;
+   reg = <0x6 0x6>;
+   };
+
+   macaddr_wifi: macaddr_wifi@6 {
+   nvmem-cell;
+   reg = <0x6 0x6>;
+   };
+
+   pre_cal_24g: pre_cal_24g@1000 {
+   nvmem-cell;
+   reg = <0x1000 0x2f20>;
+   };
+
+   pre_cal_5g: pre_cal_5g@5000{
+   nvmem-cell;
+   reg = <0x5000 0x2f20>;
+   };
+   };
+   };
+};
\ No newline at end of file
-- 
2.27.0

[PATCH v2 1/4] mtd: Add nvmem support for mtd nvmem-providers

[Ansuel Smith]

Introduce 2 new bindings for the mtd structure.
Mtd partitions can be set as 'nvmem-provider' and any subpartition defined
with the tag 'nvmem-cell' are skipped by the 'fixed-partitions' parser
and registred as a nvmem cell by the nvmem api.

Signed-off-by: Ansuel Smith 
---
 drivers/mtd/mtdcore.c| 3 ++-
 drivers/mtd/parsers/ofpart.c | 8 
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 7d930569a7df..ba5236db8318 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -551,6 +551,7 @@ static int mtd_nvmem_reg_read(void *priv, unsigned int 
offset,
 
 static int mtd_nvmem_add(struct mtd_info *mtd)
 {
+   struct device_node *mtd_node = mtd_get_of_node(mtd);
struct nvmem_config config = {};
 
config.id = -1;
@@ -563,7 +564,7 @@ static int mtd_nvmem_add(struct mtd_info *mtd)
config.stride = 1;
config.read_only = true;
config.root_only = true;
-   config.no_of_node = true;
+   config.no_of_node = !of_property_read_bool(mtd_node, "nvmem-provider");
config.priv = mtd;
 
mtd->nvmem = nvmem_register();
diff --git a/drivers/mtd/parsers/ofpart.c b/drivers/mtd/parsers/ofpart.c
index daf507c123e6..442e039214bc 100644
--- a/drivers/mtd/parsers/ofpart.c
+++ b/drivers/mtd/parsers/ofpart.c
@@ -61,6 +61,10 @@ static int parse_fixed_partitions(struct mtd_info *master,
if (!dedicated && node_has_compatible(pp))
continue;
 
+   /* skip adding if a nvmem-cell is detected */
+   if (of_property_read_bool(pp, "nvmem-cell"))
+   continue;
+
nr_parts++;
}
 
@@ -80,6 +84,10 @@ static int parse_fixed_partitions(struct mtd_info *master,
if (!dedicated && node_has_compatible(pp))
continue;
 
+   /* skip adding if a nvmem-cell is detected */
+   if (of_property_read_bool(pp, "nvmem-cell"))
+   continue;
+
reg = of_get_property(pp, "reg", );
if (!reg) {
if (dedicated) {
-- 
2.27.0

[PATCH v2 3/4] of_net: add mac-address-increment support

[Ansuel Smith]

Lots of embedded devices use the mac-address of other interface
extracted from nvmem cells and increments it by one or two. Add two
bindings to integrate this and directly use the right mac-address for
the interface. Some example are some routers that use the gmac
mac-address stored in the art partition and increments it by one for the
wifi. mac-address-increment-byte bindings is used to tell what byte of
the mac-address has to be increased (if not defined the last byte is
increased) and mac-address-increment tells how much the byte decided
early has to be increased.

Signed-off-by: Ansuel Smith 
---
 drivers/of/of_net.c | 53 +++--
 1 file changed, 41 insertions(+), 12 deletions(-)

diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
index 6e411821583e..171f5ea6f371 100644
--- a/drivers/of/of_net.c
+++ b/drivers/of/of_net.c
@@ -45,7 +45,7 @@ int of_get_phy_mode(struct device_node *np, phy_interface_t 
*interface)
 }
 EXPORT_SYMBOL_GPL(of_get_phy_mode);
 
-static const void *of_get_mac_addr(struct device_node *np, const char *name)
+static void *of_get_mac_addr(struct device_node *np, const char *name)
 {
struct property *pp = of_find_property(np, name, NULL);
 
@@ -54,26 +54,31 @@ static const void *of_get_mac_addr(struct device_node *np, 
const char *name)
return NULL;
 }
 
-static const void *of_get_mac_addr_nvmem(struct device_node *np)
+static void *of_get_mac_addr_nvmem(struct device_node *np, int *err)
 {
int ret;
const void *mac;
u8 nvmem_mac[ETH_ALEN];
struct platform_device *pdev = of_find_device_by_node(np);
 
-   if (!pdev)
-   return ERR_PTR(-ENODEV);
+   if (!pdev) {
+   *err = -ENODEV;
+   return NULL;
+   }
 
ret = nvmem_get_mac_address(>dev, _mac);
if (ret) {
put_device(>dev);
-   return ERR_PTR(ret);
+   *err = ret;
+   return NULL;
}
 
mac = devm_kmemdup(>dev, nvmem_mac, ETH_ALEN, GFP_KERNEL);
put_device(>dev);
-   if (!mac)
-   return ERR_PTR(-ENOMEM);
+   if (!mac) {
+   *err = -ENOMEM;
+   return NULL;
+   }
 
return mac;
 }
@@ -98,24 +103,48 @@ static const void *of_get_mac_addr_nvmem(struct 
device_node *np)
  * this case, the real MAC is in 'local-mac-address', and 'mac-address' exists
  * but is all zeros.
  *
+ * DT can tell the system to increment the mac-address after is extracted by
+ * using:
+ * - mac-address-increment-byte to decide what byte to increase
+ *   (if not defined is increased the last byte)
+ * - mac-address-increment to decide how much to increase
+ *
  * Return: Will be a valid pointer on success and ERR_PTR in case of error.
 */
 const void *of_get_mac_address(struct device_node *np)
 {
-   const void *addr;
+   u32 inc_idx, mac_inc;
+   int ret = 0;
+   u8 *addr;
+
+   /* Check first if the increment byte is present and valid.
+* If not set assume to increment the last byte if found.
+*/
+   if (of_property_read_u32(np, "mac-address-increment-byte", _idx))
+   inc_idx = 5;
+   if (inc_idx > 5)
+   return ERR_PTR(-EINVAL);
 
addr = of_get_mac_addr(np, "mac-address");
if (addr)
-   return addr;
+   goto found;
 
addr = of_get_mac_addr(np, "local-mac-address");
if (addr)
-   return addr;
+   goto found;
 
addr = of_get_mac_addr(np, "address");
if (addr)
-   return addr;
+   goto found;
+
+   addr = of_get_mac_addr_nvmem(np, );
+   if (ret)
+   return ERR_PTR(ret);
+
+found:
+   if (!of_property_read_u32(np, "mac-address-increment", _inc))
+   addr[inc_idx] += mac_inc;
 
-   return of_get_mac_addr_nvmem(np);
+   return addr;
 }
 EXPORT_SYMBOL(of_get_mac_address);
-- 
2.27.0

[PATCH v2 0/4] Actually implement nvmem support for mtd

[Ansuel Smith]

The mtd support for the nvmem api has been stalled from 2018 with a patch
half pushed hoping that a scheme is found for the mtd name later. This
pathset try to address this and add a very needed feature for the
mac-address.

My solution to the already discussed problem here [1] is to keep it simple.
A mtd subpartition can be set as a nvmem-provider with a specific tag and
each direct subnode is treat by the nvmem api as a nvmem-cell and gets
correctly registred. The mtd driver will treat a direct subnode of the
subpartition as a legacy subpartition of the subpartition using the
'fixed-partition' parser. To fix this every nvmem-cell has to have the
'nvmem-cell' tag and the fixed-partition parser will skip these node if 
this tag is detected. Simple as that. The subpartition with the tag 
'nvmem-provider' will then be set by the config to not skip the of
registration in the config and the nvmem-cells are correctly registred
and can be used to set mac-address of the devices on the system.

The last 2 patch try to address a problem in the embedded devices (mostly
routers) that have the mac-address saved in a dedicated partition and is
a ""master"" mac-address. Each device increment or decrement the extracted
mac-address based on the device number. The increment function is
implemented in the of_net function to get the mac-address that every net
driver should allready use if they don't have a trusty mac-address source.
(One example of this implementation are many ath10k device that gets the
mac-address from the art mtd partition assigned to the network driver and
increments it 1 for the wifi 2.4ghz and 2 for the wifi 5ghz).

I really hope my mtd nvmem implementation doesn't conflicts with others
and can be used, since this would remove many patch used to get mac-address
and other nvmem data.

[1] https://lore.kernel.org/patchwork/patch/765435/

Changes:
v2:
* Fix compile error (missing mtd_node in mtdcore)

Ansuel Smith (4):
  mtd: Add nvmem support for mtd nvmem-providers
  dt-bindings: mtd: partition: Document use of nvmem-provider
  of_net: add mac-address-increment support
  dt-bindings: net: Document use of mac-address-increment

 .../devicetree/bindings/mtd/partition.txt | 59 +++
 .../bindings/net/ethernet-controller.yaml | 19 ++
 drivers/mtd/mtdcore.c |  3 +-
 drivers/mtd/parsers/ofpart.c  |  8 +++
 drivers/of/of_net.c   | 53 +
 5 files changed, 129 insertions(+), 13 deletions(-)

-- 
2.27.0

Re: [PATCH 1/4] ARM/omap1: switch to use dma_direct_set_offset for lbus DMA offsets

[Janusz Krzysztofik]

Hi Tony,

On Friday, September 18, 2020 7:49:33 A.M. CEST Tony Lindgren wrote:
> * Christoph Hellwig  [200917 17:37]:
> > Switch the omap1510 platform ohci device to use dma_direct_set_offset
> > to set the DMA offset instead of using direct hooks into the DMA
> > mapping code and remove the now unused hooks.
> 
> Looks nice to me :) I still can't test this probably for few more weeks
> though but hopefully Aaro or Janusz (Added to Cc) can test it.

Works for me on Amstrad Delta (tested with a USB ethernet adapter).

Tested-by: Janusz Krzysztofik 

Thanks,
Janusz

> 
> Regards,
> 
> Tony
> 
> > Signed-off-by: Christoph Hellwig 
> > ---
> >  arch/arm/include/asm/dma-direct.h | 18 -
> >  arch/arm/mach-omap1/include/mach/memory.h | 31 ---
> >  arch/arm/mach-omap1/usb.c | 22 
> >  3 files changed, 22 insertions(+), 49 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/dma-direct.h 
> > b/arch/arm/include/asm/dma-direct.h
> > index 436544aeb83405..77fcb7ee5ec907 100644
> > --- a/arch/arm/include/asm/dma-direct.h
> > +++ b/arch/arm/include/asm/dma-direct.h
> > @@ -9,7 +9,6 @@
> >   * functions used internally by the DMA-mapping API to provide DMA
> >   * addresses. They must not be used by drivers.
> >   */
> > -#ifndef __arch_pfn_to_dma
> >  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
> >  {
> > if (dev && dev->dma_range_map)
> > @@ -34,23 +33,6 @@ static inline dma_addr_t virt_to_dma(struct device *dev, 
> > void *addr)
> > return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
> >  }
> >  
> > -#else
> > -static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
> > -{
> > -   return __arch_pfn_to_dma(dev, pfn);
> > -}
> > -
> > -static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
> > -{
> > -   return __arch_dma_to_pfn(dev, addr);
> > -}
> > -
> > -static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
> > -{
> > -   return __arch_virt_to_dma(dev, addr);
> > -}
> > -#endif
> > -
> >  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
> >  {
> > unsigned int offset = paddr & ~PAGE_MASK;
> > diff --git a/arch/arm/mach-omap1/include/mach/memory.h 
> > b/arch/arm/mach-omap1/include/mach/memory.h
> > index 1142560e0078f5..36bccb6ab8 100644
> > --- a/arch/arm/mach-omap1/include/mach/memory.h
> > +++ b/arch/arm/mach-omap1/include/mach/memory.h
> > @@ -14,42 +14,11 @@
> >   * OMAP-1510 bus address is translated into a Local Bus address if the
> >   * OMAP bus type is lbus. We do the address translation based on the
> >   * device overriding the defaults used in the dma-mapping API.
> > - * Note that the is_lbus_device() test is not very efficient on 1510
> > - * because of the strncmp().
> >   */
> > -#if defined(CONFIG_ARCH_OMAP15XX) && !defined(__ASSEMBLER__)
> >  
> >  /*
> >   * OMAP-1510 Local Bus address offset
> >   */
> >  #define OMAP1510_LB_OFFSET UL(0x3000)
> >  
> > -#define virt_to_lbus(x)((x) - PAGE_OFFSET + OMAP1510_LB_OFFSET)
> > -#define lbus_to_virt(x)((x) - OMAP1510_LB_OFFSET + PAGE_OFFSET)
> > -#define is_lbus_device(dev)(cpu_is_omap15xx() && dev && 
> > (strncmp(dev_name(dev), "ohci", 4) == 0))
> > -
> > -#define __arch_pfn_to_dma(dev, pfn)\
> > -   ({ dma_addr_t __dma = __pfn_to_phys(pfn); \
> > -  if (is_lbus_device(dev)) \
> > -   __dma = __dma - PHYS_OFFSET + OMAP1510_LB_OFFSET; \
> > -  __dma; })
> > -
> > -#define __arch_dma_to_pfn(dev, addr)   \
> > -   ({ dma_addr_t __dma = addr; \
> > -  if (is_lbus_device(dev)) \
> > -   __dma += PHYS_OFFSET - OMAP1510_LB_OFFSET;  \
> > -  __phys_to_pfn(__dma);\
> > -   })
> > -
> > -#define __arch_dma_to_virt(dev, addr)  ({ (void *) 
> > (is_lbus_device(dev) ? \
> > -   lbus_to_virt(addr) : \
> > -   __phys_to_virt(addr)); })
> > -
> > -#define __arch_virt_to_dma(dev, addr)  ({ unsigned long __addr = 
> > (unsigned long)(addr); \
> > -  (dma_addr_t) (is_lbus_device(dev) ? \
> > -   virt_to_lbus(__addr) : \
> > -   __virt_to_phys(__addr)); })
> > -
> > -#endif /* CONFIG_ARCH_OMAP15XX */
> > -
> >  #endif
> > diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
> > index d8e9bbda8f7bdd..ba8566204ea9f4 100644
> > --- a/arch/arm/mach-omap1/usb.c
> > +++ b/arch/arm/mach-omap1/usb.c
> > @@ -9,6 +9,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include 
> > @@ -542,6 +543,25 @@ static u32 __init omap1_usb2_init(unsigned nwires, 
> > unsigned alt_pingroup)
> >  /* ULPD_APLL_CTRL */
> >  #define APLL_NDPLL_SWITCH  (1 << 0)
> > 

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

[Andy Lutomirski]

> On Sep 19, 2020, at 3:09 PM, Al Viro  wrote:
> 
> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
>>> Said that, why not provide a variant that would take an explicit
>>> "is it compat" argument and use it there?  And have the normal
>>> one pass in_compat_syscall() to that...
>> 
>> That would help to not introduce a regression with this series yes.
>> But it wouldn't fix existing bugs when io_uring is used to access
>> read or write methods that use in_compat_syscall().  One example that
>> I recently ran into is drivers/scsi/sg.c.
> 
> So screw such read/write methods - don't use them with io_uring.
> That, BTW, is one of the reasons I'm sceptical about burying the
> decisions deep into the callchain - we don't _want_ different
> data layouts on read/write depending upon the 32bit vs. 64bit
> caller, let alone the pointer-chasing garbage that is /dev/sg.

Well, we could remove in_compat_syscall(), etc and instead have an implicit 
parameter in DEFINE_SYSCALL.  Then everything would have to be explicit.  This 
would probably be a win, although it could be quite a bit of work.

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

[Andy Lutomirski]

> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann  wrote:
> 
> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski  wrote:
>>> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig  wrote:
>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
 Said that, why not provide a variant that would take an explicit
 "is it compat" argument and use it there?  And have the normal
 one pass in_compat_syscall() to that...
>>> 
>>> That would help to not introduce a regression with this series yes.
>>> But it wouldn't fix existing bugs when io_uring is used to access
>>> read or write methods that use in_compat_syscall().  One example that
>>> I recently ran into is drivers/scsi/sg.c.
> 
> Ah, so reading /dev/input/event* would suffer from the same issue,
> and that one would in fact be broken by your patch in the hypothetical
> case that someone tried to use io_uring to read /dev/input/event on x32...
> 
> For reference, I checked the socket timestamp handling that has a
> number of corner cases with time32/time64 formats in compat mode,
> but none of those appear to be affected by the problem.
> 
>> Aside from the potentially nasty use of per-task variables, one thing
>> I don't like about PF_FORCE_COMPAT is that it's one-way.  If we're
>> going to have a generic mechanism for this, shouldn't we allow a full
>> override of the syscall arch instead of just allowing forcing compat
>> so that a compat syscall can do a non-compat operation?
> 
> The only reason it's needed here is that the caller is in a kernel
> thread rather than a system call. Are there any possible scenarios
> where one would actually need the opposite?
> 

I can certainly imagine needing to force x32 mode from a kernel thread.

As for the other direction: what exactly are the desired bitness/arch semantics 
of io_uring?  Is the operation bitness chosen by the io_uring creation or by 
the io_uring_enter() bitness?

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

[Al Viro]

On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > Said that, why not provide a variant that would take an explicit
> > "is it compat" argument and use it there?  And have the normal
> > one pass in_compat_syscall() to that...
> 
> That would help to not introduce a regression with this series yes.
> But it wouldn't fix existing bugs when io_uring is used to access
> read or write methods that use in_compat_syscall().  One example that
> I recently ran into is drivers/scsi/sg.c.

So screw such read/write methods - don't use them with io_uring.
That, BTW, is one of the reasons I'm sceptical about burying the
decisions deep into the callchain - we don't _want_ different
data layouts on read/write depending upon the 32bit vs. 64bit
caller, let alone the pointer-chasing garbage that is /dev/sg.

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

[Finn Thain]

On Sat, 19 Sep 2020, Arnd Bergmann wrote:

> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski  wrote:
> > On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig  wrote:
> > > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > > > Said that, why not provide a variant that would take an explicit 
> > > > "is it compat" argument and use it there?  And have the normal one 
> > > > pass in_compat_syscall() to that...
> > >
> > > That would help to not introduce a regression with this series yes. 
> > > But it wouldn't fix existing bugs when io_uring is used to access 
> > > read or write methods that use in_compat_syscall().  One example 
> > > that I recently ran into is drivers/scsi/sg.c.
> 
> Ah, so reading /dev/input/event* would suffer from the same issue, and 
> that one would in fact be broken by your patch in the hypothetical case 
> that someone tried to use io_uring to read /dev/input/event on x32...
> 
> For reference, I checked the socket timestamp handling that has a number 
> of corner cases with time32/time64 formats in compat mode, but none of 
> those appear to be affected by the problem.
> 
> > Aside from the potentially nasty use of per-task variables, one thing 
> > I don't like about PF_FORCE_COMPAT is that it's one-way.  If we're 
> > going to have a generic mechanism for this, shouldn't we allow a full 
> > override of the syscall arch instead of just allowing forcing compat 
> > so that a compat syscall can do a non-compat operation?
> 
> The only reason it's needed here is that the caller is in a kernel 
> thread rather than a system call. Are there any possible scenarios where 
> one would actually need the opposite?
> 

Quite possibly. The ext4 vs. compat getdents bug is still unresolved. 
Please see,
https://lore.kernel.org/lkml/cafeaca9w+jk7_trttnl1p2es1knnpjx9wcuvhflwxlq9aug...@mail.gmail.com/

>Arnd
> 

[PATCH 4/4] dt-bindings: net: Document use of mac-address-increment

[Ansuel Smith]

Two new bindings are now supported by the of_net driver to increase (or
decrease) a mac-address. This can be very useful in case where the
system extract the mac-address for the device from a dedicated partition
and have a generic mac-address that needs to be incremented based on the
device number.
- mac-address-increment-byte is used to tell what byte must be
  incremented (if not set the last byte is increased)
- mac-address-increment is used to tell how much to increment of the
  extracted mac-address decided byte.

Signed-off-by: Ansuel Smith 
---
 .../bindings/net/ethernet-controller.yaml | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml 
b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
index fa2baca8c726..43f2f21faf41 100644
--- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -32,6 +32,25 @@ properties:
   - minItems: 6
 maxItems: 6
 
+  mac-address-increment:
+description:
+  The MAC address can optionally be increased (or decreased using
+  negative values) from the original value readed (from a nvmem cell
+  for example). This can be used if the mac is readed from a dedicated
+  partition and must be increased based on the number of device
+  present in the system.
+minimum: -255
+maximum: 255
+
+  mac-address-increment-byte:
+description:
+  If 'mac-address-increment' is defined, this will tell what byte of
+  the mac-address will be increased. If 'mac-address-increment' is
+  not defined, this option will do nothing.
+default: 5
+minimum: 0
+maximum: 5
+
   max-frame-size:
 $ref: /schemas/types.yaml#definitions/uint32
 description:
-- 
2.27.0

[PATCH 1/4] mtd: Add nvmem support for mtd nvmem-providers

[Ansuel Smith]

Introduce 2 new bindings for the mtd structure.
Mtd partitions can be set as 'nvmem-provider' and any subpartition defined
with the tag 'nvmem-cell' are skipped by the 'fixed-partitions' parser
and registred as a nvmem cell by the nvmem api.

Signed-off-by: Ansuel Smith 
---
 drivers/mtd/mtdcore.c| 2 +-
 drivers/mtd/parsers/ofpart.c | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 7d930569a7df..72502c990007 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -563,7 +563,7 @@ static int mtd_nvmem_add(struct mtd_info *mtd)
config.stride = 1;
config.read_only = true;
config.root_only = true;
-   config.no_of_node = true;
+   config.no_of_node = !of_property_read_bool(mtd_node, "nvmem-provider");
config.priv = mtd;
 
mtd->nvmem = nvmem_register();
diff --git a/drivers/mtd/parsers/ofpart.c b/drivers/mtd/parsers/ofpart.c
index daf507c123e6..442e039214bc 100644
--- a/drivers/mtd/parsers/ofpart.c
+++ b/drivers/mtd/parsers/ofpart.c
@@ -61,6 +61,10 @@ static int parse_fixed_partitions(struct mtd_info *master,
if (!dedicated && node_has_compatible(pp))
continue;
 
+   /* skip adding if a nvmem-cell is detected */
+   if (of_property_read_bool(pp, "nvmem-cell"))
+   continue;
+
nr_parts++;
}
 
@@ -80,6 +84,10 @@ static int parse_fixed_partitions(struct mtd_info *master,
if (!dedicated && node_has_compatible(pp))
continue;
 
+   /* skip adding if a nvmem-cell is detected */
+   if (of_property_read_bool(pp, "nvmem-cell"))
+   continue;
+
reg = of_get_property(pp, "reg", );
if (!reg) {
if (dedicated) {
-- 
2.27.0

[PATCH 0/4] Actually implement nvmem support for mtd

[Ansuel Smith]

The mtd support for the nvmem api has been stalled from 2018 with a patch
half pushed hoping that a scheme is found for the mtd name later. This
pathset try to address this and add a very needed feature for the
mac-address.

My solution to the already discussed problem here [1] is to keep it simple.
A mtd subpartition can be set as a nvmem-provider with a specific tag and
each direct subnode is treat by the nvmem api as a nvmem-cell and gets
correctly registred. The mtd driver will treat a direct subnode of the
subpartition as a legacy subpartition of the subpartition using the
'fixed-partition' parser. To fix this every nvmem-cell has to have the
'nvmem-cell' tag and the fixed-partition parser will skip these node if 
this tag is detected. Simple as that. The subpartition with the tag 
'nvmem-provider' will then be set by the config to not skip the of
registration in the config and the nvmem-cells are correctly registred
and can be used to set mac-address of the devices on the system.

The last 2 patch try to address a problem in the embedded devices (mostly
routers) that have the mac-address saved in a dedicated partition and is
a ""master"" mac-address. Each device increment or decrement the extracted
mac-address based on the device number. The increment function is
implemented in the of_net function to get the mac-address that every net
driver should allready use if they don't have a trusty mac-address source.
(One example of this implementation are many ath10k device that gets the
mac-address from the art mtd partition assigned to the network driver and
increments it 1 for the wifi 2.4ghz and 2 for the wifi 5ghz).

I really hope my mtd nvmem implementation doesn't conflicts with others
and can be used, since this would remove many patch used to get mac-address
and other nvmem data.

[1] https://lore.kernel.org/patchwork/patch/765435/

Ansuel Smith (4):
  mtd: Add nvmem support for mtd nvmem-providers
  dt-bindings: mtd: partition: Document use of nvmem-provider
  of_net: add mac-address-increment support
  dt-bindings: net: Document use of mac-address-increment

 .../devicetree/bindings/mtd/partition.txt | 59 +++
 .../bindings/net/ethernet-controller.yaml | 19 ++
 drivers/mtd/mtdcore.c |  2 +-
 drivers/mtd/parsers/ofpart.c  |  8 +++
 drivers/of/of_net.c   | 53 +
 5 files changed, 128 insertions(+), 13 deletions(-)

-- 
2.27.0

[PATCH 3/4] of_net: add mac-address-increment support

[Ansuel Smith]

Lots of embedded devices use the mac-address of other interface
extracted from nvmem cells and increments it by one or two. Add two
bindings to integrate this and directly use the right mac-address for
the interface. Some example are some routers that use the gmac
mac-address stored in the art partition and increments it by one for the
wifi. mac-address-increment-byte bindings is used to tell what byte of
the mac-address has to be increased (if not defined the last byte is
increased) and mac-address-increment tells how much the byte decided
early has to be increased.

Signed-off-by: Ansuel Smith 
---
 drivers/of/of_net.c | 53 +++--
 1 file changed, 41 insertions(+), 12 deletions(-)

diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
index 6e411821583e..171f5ea6f371 100644
--- a/drivers/of/of_net.c
+++ b/drivers/of/of_net.c
@@ -45,7 +45,7 @@ int of_get_phy_mode(struct device_node *np, phy_interface_t 
*interface)
 }
 EXPORT_SYMBOL_GPL(of_get_phy_mode);
 
-static const void *of_get_mac_addr(struct device_node *np, const char *name)
+static void *of_get_mac_addr(struct device_node *np, const char *name)
 {
struct property *pp = of_find_property(np, name, NULL);
 
@@ -54,26 +54,31 @@ static const void *of_get_mac_addr(struct device_node *np, 
const char *name)
return NULL;
 }
 
-static const void *of_get_mac_addr_nvmem(struct device_node *np)
+static void *of_get_mac_addr_nvmem(struct device_node *np, int *err)
 {
int ret;
const void *mac;
u8 nvmem_mac[ETH_ALEN];
struct platform_device *pdev = of_find_device_by_node(np);
 
-   if (!pdev)
-   return ERR_PTR(-ENODEV);
+   if (!pdev) {
+   *err = -ENODEV;
+   return NULL;
+   }
 
ret = nvmem_get_mac_address(>dev, _mac);
if (ret) {
put_device(>dev);
-   return ERR_PTR(ret);
+   *err = ret;
+   return NULL;
}
 
mac = devm_kmemdup(>dev, nvmem_mac, ETH_ALEN, GFP_KERNEL);
put_device(>dev);
-   if (!mac)
-   return ERR_PTR(-ENOMEM);
+   if (!mac) {
+   *err = -ENOMEM;
+   return NULL;
+   }
 
return mac;
 }
@@ -98,24 +103,48 @@ static const void *of_get_mac_addr_nvmem(struct 
device_node *np)
  * this case, the real MAC is in 'local-mac-address', and 'mac-address' exists
  * but is all zeros.
  *
+ * DT can tell the system to increment the mac-address after is extracted by
+ * using:
+ * - mac-address-increment-byte to decide what byte to increase
+ *   (if not defined is increased the last byte)
+ * - mac-address-increment to decide how much to increase
+ *
  * Return: Will be a valid pointer on success and ERR_PTR in case of error.
 */
 const void *of_get_mac_address(struct device_node *np)
 {
-   const void *addr;
+   u32 inc_idx, mac_inc;
+   int ret = 0;
+   u8 *addr;
+
+   /* Check first if the increment byte is present and valid.
+* If not set assume to increment the last byte if found.
+*/
+   if (of_property_read_u32(np, "mac-address-increment-byte", _idx))
+   inc_idx = 5;
+   if (inc_idx > 5)
+   return ERR_PTR(-EINVAL);
 
addr = of_get_mac_addr(np, "mac-address");
if (addr)
-   return addr;
+   goto found;
 
addr = of_get_mac_addr(np, "local-mac-address");
if (addr)
-   return addr;
+   goto found;
 
addr = of_get_mac_addr(np, "address");
if (addr)
-   return addr;
+   goto found;
+
+   addr = of_get_mac_addr_nvmem(np, );
+   if (ret)
+   return ERR_PTR(ret);
+
+found:
+   if (!of_property_read_u32(np, "mac-address-increment", _inc))
+   addr[inc_idx] += mac_inc;
 
-   return of_get_mac_addr_nvmem(np);
+   return addr;
 }
 EXPORT_SYMBOL(of_get_mac_address);
-- 
2.27.0

[PATCH 2/4] dt-bindings: mtd: partition: Document use of nvmem-provider

[Ansuel Smith]

Document the use of this 2 new bindings, nvmem-provider and nvmem-cell,
used to describe the nvmem cell that the subpartition provide to the
nvmem api and the system. Nvmem cell are direct subnode of the
subpartition and are skipped by the 'fixed-partitions' parser if they
contain the 'nvmem-cell' tag. The subpartition must have the
'nvmem-provider' tag or the subpartition will not register the cell to
the nvmem api.

Signed-off-by: Ansuel Smith 
---
 .../devicetree/bindings/mtd/partition.txt | 59 +++
 1 file changed, 59 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
b/Documentation/devicetree/bindings/mtd/partition.txt
index 4a39698221a2..66d3a3f0a021 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -64,6 +64,16 @@ Optional properties:
 - slc-mode: This parameter, if present, allows one to emulate SLC mode on a
   partition attached to an MLC NAND thus making this partition immune to
   paired-pages corruptions
+- nvmem-provider : Optionally a subpartition can be set as a nvmem-provider. 
This can
+  be very useful if some data like the mac-address is stored in a special 
partition
+  at a specific offset. Subpartition that describe nvmem-cell must have set the
+  'nvmem-cell' of they will be treated as a subpartition and not skipped and 
registred
+  as nvmem cells. In this specific case '#address-cells' and '#size-cells' 
must be
+  provided.
+- nvmem-cell : A direct subnode of a subpartition can be described as a 
nvmem-cell and
+  skipped by the fixed-partition parser and registred as a nvmem-cell of the 
registred
+  nvmem subpartition IF it does contain the 'nvmem-provider tag. If the 
subpartition
+  lacks of such tag the subnode will be skipped and the nvmem api won't 
register them.
 
 Examples:
 
@@ -158,3 +168,52 @@ flash@3 {
};
};
 };
+
+flash@0 {
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x000 0x10>;
+   read-only;
+   };
+
+   art: art@120 {
+   label = "art";
+   reg = <0x120 0x014>;
+   read-only;
+   nvmem-provider;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   macaddr_gmac1: macaddr_gmac1@0 {
+   nvmem-cell;
+   reg = <0x0 0x6>;
+   };
+
+   macaddr_gmac2: macaddr_gmac2@6 {
+   nvmem-cell;
+   reg = <0x6 0x6>;
+   };
+
+   macaddr_wifi: macaddr_wifi@6 {
+   nvmem-cell;
+   reg = <0x6 0x6>;
+   };
+
+   pre_cal_24g: pre_cal_24g@1000 {
+   nvmem-cell;
+   reg = <0x1000 0x2f20>;
+   };
+
+   pre_cal_5g: pre_cal_5g@5000{
+   nvmem-cell;
+   reg = <0x5000 0x2f20>;
+   };
+   };
+   };
+};
\ No newline at end of file
-- 
2.27.0

My Dear in the lord

[Mrs. Mina A. Brunel]

My Dear in the lord


My name is Mrs. Mina A. Brunel I am a Norway Citizen who is living in Burkina 
Faso, I am married to Mr. Brunel Patrice, a politicians who owns a small gold 
company in Burkina Faso; He died of Leprosy and Radesyge, in year February 
2010, During his lifetime he deposited the sum of € 8.5 Million Euro) Eight 
million, Five hundred thousand Euros in a bank in Ouagadougou the capital city 
of of Burkina in West Africa. The money was from the sale of his company and 
death benefits payment and entitlements of my deceased husband by his company.

I am sending you this message with heavy tears in my eyes and great sorrow in 
my heart, and also praying that it will reach you in good health because I am 
not in good health, I sleep every night without knowing if I may be alive to 
see the next day. I am suffering from long time cancer and presently I am 
partially suffering from Leprosy, which has become difficult for me to move 
around. I was married to my late husband for more than 6 years without having a 
child and my doctor confided that I have less chance to live, having to know 
when the cup of death will come, I decided to contact you to claim the fund 
since I don't have any relation I grew up from an orphanage home.

I have decided to donate this money for the support of helping Motherless 
babies/Less privileged/Widows and churches also to build the house of God 
because I am dying and diagnosed with cancer for about 3 years ago. I have 
decided to donate from what I have inherited from my late husband to you for 
the good work of Almighty God; I will be going in for an operation surgery soon.

Now I want you to stand as my next of kin to claim the funds for charity 
purposes. Because of this money remains unclaimed after my death, the bank 
executives or the government will take the money as unclaimed fund and maybe 
use it for selfishness and worthless ventures, I need a very honest person who 
can claim this money and use it for Charity works, for orphanages, widows and 
also build schools and churches for less privilege that will be named after my 
late husband and my name.

I need your urgent answer to know if you will be able to execute this project, 
and I will give you more information on how the fund will be transferred to 
your bank account or online banking.

Thanks
Mrs. Mina A. Brunel

[PATCH v2] regulator: unexport regulator_lock/unlock()

[Michał Mirosław]

regulator_lock/unlock() was used only to guard
regulator_notifier_call_chain(). As no users remain, make the functions
internal.

Signed-off-by: Michał Mirosław 
---
 drivers/regulator/core.c | 6 ++
 include/linux/regulator/driver.h | 3 ---
 2 files changed, 2 insertions(+), 7 deletions(-)
---
 v2: rebased on current regulator/for-linus

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 7ff507ec875a..8da37e0d1100 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -190,11 +190,10 @@ static inline int regulator_lock_nested(struct 
regulator_dev *rdev,
  * than the one, which initially locked the mutex, it will
  * wait on mutex.
  */
-void regulator_lock(struct regulator_dev *rdev)
+static void regulator_lock(struct regulator_dev *rdev)
 {
regulator_lock_nested(rdev, NULL);
 }
-EXPORT_SYMBOL_GPL(regulator_lock);
 
 /**
  * regulator_unlock - unlock a single regulator
@@ -203,7 +202,7 @@ EXPORT_SYMBOL_GPL(regulator_lock);
  * This function unlocks the mutex when the
  * reference counter reaches 0.
  */
-void regulator_unlock(struct regulator_dev *rdev)
+static void regulator_unlock(struct regulator_dev *rdev)
 {
mutex_lock(_nesting_mutex);
 
@@ -216,7 +215,6 @@ void regulator_unlock(struct regulator_dev *rdev)
 
mutex_unlock(_nesting_mutex);
 }
-EXPORT_SYMBOL_GPL(regulator_unlock);
 
 static bool regulator_supply_is_couple(struct regulator_dev *rdev)
 {
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 8539f34ae42b..11cade73726c 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -533,9 +533,6 @@ int regulator_set_current_limit_regmap(struct regulator_dev 
*rdev,
 int regulator_get_current_limit_regmap(struct regulator_dev *rdev);
 void *regulator_get_init_drvdata(struct regulator_init_data *reg_init_data);
 
-void regulator_lock(struct regulator_dev *rdev);
-void regulator_unlock(struct regulator_dev *rdev);
-
 /*
  * Helper functions intended to be used by regulator drivers prior registering
  * their regulators.
-- 
2.20.1

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

[Michał Mirosław]

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

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

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

[PATCH v7 0/4] input: elants: Support Asus TF300T and Nexus 7 touchscreen

[Michał Mirosław]

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

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

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

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

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

-- 
2.20.1

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

[Michał Mirosław]

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

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

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

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

[Michał Mirosław]

From: Dmitry Osipenko 

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

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

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

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

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

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

[Michał Mirosław]

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

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

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

[PATCH] staging:r8188eu: replace WIFI_REASON_CODE enum with native ieee80211_reasoncode

[Ivan Safonov]

WIFI_REASON_CODE is duplication of enum ieee80211_reasoncode.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_mlme_ext.c |  4 +--
 drivers/staging/rtl8188eu/include/wifi.h  | 31 ---
 2 files changed, 2 insertions(+), 33 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 4df790c83d9f..cef15cb937d2 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -2929,7 +2929,7 @@ static unsigned int OnAssocReq(struct adapter *padapter,
 
pstat = rtw_get_stainfo(pstapriv, GetAddr2Ptr(pframe));
if (!pstat) {
-   status = _RSON_CLS2_;
+   status = WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA;
goto asoc_class2_error;
}
 
@@ -2943,7 +2943,7 @@ static unsigned int OnAssocReq(struct adapter *padapter,
/*  check if this stat has been successfully authenticated/assocated */
if (!((pstat->state) & WIFI_FW_AUTH_SUCCESS)) {
if (!((pstat->state) & WIFI_FW_ASSOC_SUCCESS)) {
-   status = _RSON_CLS2_;
+   status = WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA;
goto asoc_class2_error;
} else {
pstat->state &= (~WIFI_FW_ASSOC_SUCCESS);
diff --git a/drivers/staging/rtl8188eu/include/wifi.h 
b/drivers/staging/rtl8188eu/include/wifi.h
index a549b6d0159a..757c582ba4d9 100644
--- a/drivers/staging/rtl8188eu/include/wifi.h
+++ b/drivers/staging/rtl8188eu/include/wifi.h
@@ -74,37 +74,6 @@ enum WIFI_FRAME_SUBTYPE {
WIFI_QOS_DATA_NULL  = (BIT(6) | WIFI_QOS_DATA_TYPE),
 };
 
-enum WIFI_REASON_CODE  {
-   _RSON_RESERVED_ = 0,
-   _RSON_UNSPECIFIED_  = 1,
-   _RSON_AUTH_NO_LONGER_VALID_ = 2,
-   _RSON_DEAUTH_STA_LEAVING_   = 3,
-   _RSON_INACTIVITY_   = 4,
-   _RSON_UNABLE_HANDLE_= 5,
-   _RSON_CLS2_ = 6,
-   _RSON_CLS3_ = 7,
-   _RSON_DISAOC_STA_LEAVING_   = 8,
-   _RSON_ASOC_NOT_AUTH_= 9,
-
-   /*  WPA reason */
-   _RSON_INVALID_IE_   = 13,
-   _RSON_MIC_FAILURE_  = 14,
-   _RSON_4WAY_HNDSHK_TIMEOUT_  = 15,
-   _RSON_GROUP_KEY_UPDATE_TIMEOUT_ = 16,
-   _RSON_DIFF_IE_  = 17,
-   _RSON_MLTCST_CIPHER_NOT_VALID_  = 18,
-   _RSON_UNICST_CIPHER_NOT_VALID_  = 19,
-   _RSON_AKMP_NOT_VALID_   = 20,
-   _RSON_UNSUPPORT_RSNE_VER_   = 21,
-   _RSON_INVALID_RSNE_CAP_ = 22,
-   _RSON_IEEE_802DOT1X_AUTH_FAIL_  = 23,
-
-   /* belowing are Realtek definition */
-   _RSON_PMK_NOT_AVAILABLE_= 24,
-   _RSON_TDLS_TEAR_TOOFAR_ = 25,
-   _RSON_TDLS_TEAR_UN_RSN_ = 26,
-};
-
 enum WIFI_STATUS_CODE {
_STATS_SUCCESSFUL_  = 0,
_STATS_FAILURE_ = 1,
-- 
2.26.2

Re: [PATCH net-next] net: neterion: Remove set but not used variable

[David Miller]

From: Zheng Yongjun 
Date: Sat, 19 Sep 2020 15:40:47 +0800

> @@ -179,7 +175,7 @@ enum vxge_hw_status vxge_hw_vpath_intr_disable(
>   (u32)VXGE_HW_INTR_MASK_ALL,
>   _reg->vpath_general_int_mask);
>  
> - val64 = VXGE_HW_TIM_CLR_INT_EN_VP(1 << (16 - vpath->vp_id));
> + VXGE_HW_TIM_CLR_INT_EN_VP(1 << (16 - vpath->vp_id));

This makes no sense, this macro is calculating an integer value.

This looks like a mechanical change made without considering what
the code is actually doing or should be doing.

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

[Arnd Bergmann]

On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski  wrote:
> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig  wrote:
> > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > > Said that, why not provide a variant that would take an explicit
> > > "is it compat" argument and use it there?  And have the normal
> > > one pass in_compat_syscall() to that...
> >
> > That would help to not introduce a regression with this series yes.
> > But it wouldn't fix existing bugs when io_uring is used to access
> > read or write methods that use in_compat_syscall().  One example that
> > I recently ran into is drivers/scsi/sg.c.

Ah, so reading /dev/input/event* would suffer from the same issue,
and that one would in fact be broken by your patch in the hypothetical
case that someone tried to use io_uring to read /dev/input/event on x32...

For reference, I checked the socket timestamp handling that has a
number of corner cases with time32/time64 formats in compat mode,
but none of those appear to be affected by the problem.

> Aside from the potentially nasty use of per-task variables, one thing
> I don't like about PF_FORCE_COMPAT is that it's one-way.  If we're
> going to have a generic mechanism for this, shouldn't we allow a full
> override of the syscall arch instead of just allowing forcing compat
> so that a compat syscall can do a non-compat operation?

The only reason it's needed here is that the caller is in a kernel
thread rather than a system call. Are there any possible scenarios
where one would actually need the opposite?

   Arnd

Re: [PATCH net-next] net: micrel: Remove set but not used variable

[David Miller]

From: Zheng Yongjun 
Date: Sat, 19 Sep 2020 10:32:35 +0800

> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/ethernet/micrel/ksz884x.c: In function rx_proc:
> drivers/net/ethernet/micrel/ksz884x.c:4981:6: warning: variable ‘rx_status’ 
> set but not used [-Wunused-but-set-variable]
> 
> drivers/net/ethernet/micrel/ksz884x.c: In function netdev_get_ethtool_stats:
> drivers/net/ethernet/micrel/ksz884x.c:6512:6: warning: variable ‘rc’ set but 
> not used [-Wunused-but-set-variable]
> 
> these variable is never used, so remove it.
> 
> Signed-off-by: Zheng Yongjun 

Applied.

Re: [PATCH net-next] net: liquidio: Remove set but not used variable

[David Miller]

From: Zheng Yongjun 
Date: Sat, 19 Sep 2020 09:31:23 +0800

> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function 
> lio_pci_readq:
> drivers/net/ethernet/cavium/liquidio/octeon_device.c:1327:6: warning: 
> variable ‘val32’ set but not used [-Wunused-but-set-variable]
> 
> drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function 
> lio_pci_writeq:
> drivers/net/ethernet/cavium/liquidio/octeon_device.c:1358:6: warning: 
> variable ‘val32’ set but not used [-Wunused-but-set-variable]
> 
> these variable is never used, so remove it.
> 
> Signed-off-by: Zheng Yongjun 

Applied.

Re: [PATCH net-next] net: e1000: Remove set but not used variable

[David Miller]

From: Zheng Yongjun 
Date: Sat, 19 Sep 2020 09:50:20 +0800

> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/ethernet/intel/e1000/e1000_hw.c: In function 
> e1000_phy_init_script:
> drivers/net/ethernet/intel/e1000/e1000_hw.c:132:6: warning: variable 
> ‘ret_val’ set but not used [-Wunused-but-set-variable]
> 
> `ret_val` is never used, so remove it.
> 
> Signed-off-by: Zheng Yongjun 

Applied.

Re: [PATCH net-next] net: marvell: Remove set but not used variable

[David Miller]

From: Zheng Yongjun 
Date: Sat, 19 Sep 2020 10:05:50 +0800

> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/ethernet/marvell/pxa168_eth.c: In function pxa168_eth_change_mtu:
> drivers/net/ethernet/marvell/pxa168_eth.c:1190:6: warning: variable ‘retval’ 
> set but not used [-Wunused-but-set-variable]
> 
> `retval` is never used, so remove it.
> 
> Signed-off-by: Zheng Yongjun 

This change is already in the net-next GIT tree.

Re: 答复: [PATCH net-next] net: microchip: Remove set but not used variable

[David Miller]

From: zhengyongjun 
Date: Sat, 19 Sep 2020 03:02:39 +

> This is the bad patch, please ignore it, thank you very much.

Please do not quote your entire patch when you reply like this.

It makes the reply look like a brand new patch to our patchwork
tracking system, which makes more work for us.

Re: [PATCH net-next] net: natsemi: Remove set but not used variable

[David Miller]

From: Zheng Yongjun 
Date: Sat, 19 Sep 2020 10:46:44 +0800

> @@ -1226,8 +1226,8 @@ static int ns83820_get_link_ksettings(struct net_device 
> *ndev,
>  
>   /* read current configuration */
>   cfg   = readl(dev->base + CFG) ^ SPDSTS_POLARITY;
> - tanar = readl(dev->base + TANAR);
>   tbicr = readl(dev->base + TBICR);
> + readl(dev->base + TANAR);
>  

Please do not change the order of the readl() operations, it might
matter.

Re: [PATCH net-next] net: microchip: Remove set but not used variable

[David Miller]

From: Zheng Yongjun 
Date: Sat, 19 Sep 2020 10:39:09 +0800

> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/ethernet/microchip/lan743x_main.c: In function lan743x_pm_suspend:
> drivers/net/ethernet/microchip/lan743x_main.c:3041:6: warning: variable ‘ret’ 
> set but not used [-Wunused-but-set-variable]
> 
> `ret` is set but not used, so check it's value.

Subject is still wrong, please fix this and take your time doing
so.

Thanks.

Re: [PATCH net-next] net: microchip: Remove set but not used variable

[David Miller]

From: Zheng Yongjun 
Date: Sat, 19 Sep 2020 10:37:32 +0800

> `ret` is never used, so remove it.

You are not removing it:

> @@ -3053,7 +3053,7 @@ static int lan743x_pm_suspend(struct device *dev)
>   /* Host sets PME_En, put D3hot */
>   ret = pci_prepare_to_sleep(pdev);
>  
> - return 0;
> + return ret;
>  }

In fact, you are making it get used properly.

Please fix your commit message.

Re: [PATCH v3 2/2] mailbox: Add Broadcom STB mailbox driver

[Jim Quinlan]

On Sat, Sep 19, 2020 at 3:32 PM Randy Dunlap  wrote:
>
> Hi Jim,
>
> On 9/19/20 12:22 PM, Jim Quinlan wrote:
> > ---
> >  drivers/mailbox/Kconfig   |  12 +++
> >  drivers/mailbox/Makefile  |   2 +
> >  drivers/mailbox/brcmstb-mailbox.c | 173 ++
> >  3 files changed, 187 insertions(+)
> >  create mode 100644 drivers/mailbox/brcmstb-mailbox.c
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> > index 05b1009e2820..96faf1139cb9 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -254,4 +254,16 @@ config QCOM_IPCC
> > acts as an interrupt controller for receiving interrupts from 
> > clients.
> > Say Y here if you want to build this driver.
> >
> > +config BRCMSTB_MBOX
> > + tristate "Broadcom STB Mailbox"
> > + depends on ARM64 || ARM
> > + depends on ARM_SCMI_PROTOCOL && ARCH_BRCMSTB
> > + default ARM_SCMI_PROTOCOL && ARCH_BRCMSTB
> > +help
>
> "help" is still indented with spaces instead of one tab.
> You probably should wait a bit to see if there are other comments on this 
> patch
> before doing a v4.
Hi Randy,

Will fix, then wait...
>
> > +   Mailbox implementation of the Broadcom STB for the sole purposes
> > +   of SCMI communication.  This is used by the SCMI drivers to
> > +   communicate with FW that runs in EL3.  This mailbox only implements
> > +   the agent-to-platform channgel of SCMI but may be augmented in
> > +   the future to add the platform-to-agent channel.
> > +
> >  endif
> > diff --git a/drivers/mailbox/brcmstb-mailbox.c 
> > b/drivers/mailbox/brcmstb-mailbox.c
> > new file mode 100644
> > index ..27d87938b08c
> > --- /dev/null
> > +++ b/drivers/mailbox/brcmstb-mailbox.c
> > @@ -0,0 +1,173 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright (c) 2017, Broadcom */
>
> 2017 is a little surprising.
Will fix.

>
>
> > +#if defined(CONFIG_ARM64) || defined(CONFIG_ARM)
> > +static int announce_msg(unsigned int mbox_num, unsigned int ch)
> > +{
> > + struct arm_smccc_res res;
> > +
> > + if (ch >= NUM_CHAN)
> > + return -EIO;
> > + arm_smccc_smc(BRCM_FID(ch), mbox_num, 0, 0, 0, 0, 0, 0, );
> > + if (res.a0)
> > + return -EIO;
> > + return 0;
> > +}
> > +#else
> > +#error Func announce_msg() not defined for the current ARCH
> > +#endif
>
> This is handled by the Kconfig depends on clause.
> Why is it repeated here?
Will fix.

Thanks,
Jim
>
>
>
> thanks.
> --
> ~Randy
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Linux-kernel-mentees] [PATCH] fs: fix KMSAN uninit-value bug by initializing nd in do_file_open_root

[Anant Thazhemadam]

On 19-09-2020 17:03, Anant Thazhemadam wrote:
> On 19-09-2020 22:25, Al Viro wrote:
>> On Sat, Sep 19, 2020 at 05:17:27PM +0100, Al Viro wrote:
>>
>>> Lovely...  That would get an empty path and non-directory for a starting
>>> point, but it should end up with LAST_ROOT in nd->last_type.  Which should
>>> not be able to reach the readers of those fields...  Which kernel had
>>> that been on?
>> Yecchhh...  I see what's going on; I suspect that this ought to be enough.
>> Folks, could somebody test it on the original reproducer setup?
> Sure. I can do that.

Looks like this patch actually fixes this bug.
I made syzbot test the patch, and no issues were triggered!

Note:    syzbot tested the patch with the KMSAN kernel, which
was recently rebased on v5.9-rc4.

Thanks,
Anant

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

[Drew Fustini]

Document the values in pinctrl-single,pins when #pinctrl-cells = <2>

Fixes: 27c90e5e48d0 ("ARM: dts: am33xx-l4: change #pinctrl-cells from 1 to 2")
Reported-by: Trent Piepho 
Link: https://lore.kernel.org/linux-omap/3139716.CMS8C0sQ7x@zen.local/
Signed-off-by: Drew Fustini 
---
v2 change:
- rephrase to make it clear that the pin conf value and pin mux value
  are OR'd together with #pinctrl-cells = <2>


 .../bindings/pinctrl/pinctrl-single.txt   | 21 ---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index e705acd3612c..f903eb4471f8 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -94,16 +94,23 @@ pinctrl-single,bit-per-mux is set), and uses the common 
pinctrl bindings as
 specified in the pinctrl-bindings.txt document in this directory.
 
 The pin configuration nodes for pinctrl-single are specified as pinctrl
-register offset and value pairs using pinctrl-single,pins. Only the bits
-specified in pinctrl-single,function-mask are updated. For example, setting
-a pin for a device could be done with:
+register offset and values using pinctrl-single,pins. Only the bits specified
+in pinctrl-single,function-mask are updated.
+
+When #pinctrl-cells = 1, then setting a pin for a device could be done with:
 
pinctrl-single,pins = <0xdc 0x118>;
 
-Where 0xdc is the offset from the pinctrl register base address for the
-device pinctrl register, and 0x118 contains the desired value of the
-pinctrl register. See the device example and static board pins example
-below for more information.
+Where 0xdc is the offset from the pinctrl register base address for the device
+pinctrl register, and 0x118 contains the desired value of the pinctrl register.
+
+When #pinctrl-cells = 2, then setting a pin for a device could be done with:
+
+   pinctrl-single,pins = <0xdc 0x30 0x07>;
+
+Where 0x30 is the pin configuration value and 0x07 is the pin mux mode value.
+These two values are OR'd together to produce the value stored at offset 0xdc.
+See the device example and static board pins example below for more 
information.
 
 In case when one register changes more than one pin's mux the
 pinctrl-single,bits need to be used which takes three parameters:
-- 
2.25.1

[PATCH] HID: multitouch: Lenovo X1 Tablet Gen3 trackpoint and buttons

[Mikael Wikström]

One more device that needs 40d5bb87 to resolve regression for the trackpoint
and three mouse buttons on the type cover of the Lenovo X1 Tablet Gen3.

It is probably also needed for the Lenovo X1 Tablet Gen2 with PID 0x60a3

Signed-off-by: Mikael Wikström 
---
 drivers/hid/hid-ids.h| 1 +
 drivers/hid/hid-multitouch.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 74fc1df6e3c2..6a6e2c1b6090 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -727,6 +727,7 @@
 #define USB_DEVICE_ID_LENOVO_TP10UBKBD 0x6062
 #define USB_DEVICE_ID_LENOVO_TPPRODOCK 0x6067
 #define USB_DEVICE_ID_LENOVO_X1_COVER 0x6085
+#define USB_DEVICE_ID_LENOVO_X1_TAB3 0x60b5
 #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_608D 0x608d
 #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019 0x6019
 #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_602E 0x602e
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index e3152155c4b8..99f041afd5c0 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1973,6 +1973,12 @@ static const struct hid_device_id mt_devices[] = {
  HID_DEVICE(BUS_I2C, HID_GROUP_GENERIC,
  USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_7010) },

+ /* Lenovo X1 TAB Gen 3 */
+ { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
+ HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8,
+USB_VENDOR_ID_LENOVO,
+USB_DEVICE_ID_LENOVO_X1_TAB3) },
+
  /* MosArt panels */
  { .driver_data = MT_CLS_CONFIDENCE_MINUS_ONE,
  MT_USB_DEVICE(USB_VENDOR_ID_ASUS,
-- 
2.26.2

[PATCH] ARM: dts: am335x: guardian: switch to AM33XX_PADCONF

[Drew Fustini]

Change the pin defintions from AM33XX_IOPAD to AM33XX_PADCONF macro so
that it correctly handles changes to #pinctrl-cells.

Fixes: 27c90e5e48d0 ("ARM: dts: am33xx-l4: change #pinctrl-cells from 1 to 2")
Reported-by: Trent Piepho 
Link: https://lore.kernel.org/linux-omap/3139716.CMS8C0sQ7x@zen.local/
Signed-off-by: Drew Fustini 
---
 arch/arm/boot/dts/am335x-guardian.dts | 172 +-
 1 file changed, 86 insertions(+), 86 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-guardian.dts 
b/arch/arm/boot/dts/am335x-guardian.dts
index 1918766c1f80..56c9cd674d98 100644
--- a/arch/arm/boot/dts/am335x-guardian.dts
+++ b/arch/arm/boot/dts/am335x-guardian.dts
@@ -339,152 +339,152 @@ _pinmux {
 
clkout2_pin: pinmux_clkout2_pin {
pinctrl-single,pins = <
-   AM33XX_IOPAD(0x9b4, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
+   AM33XX_PADCONF(0x9b4, PIN_OUTPUT_PULLDOWN, MUX_MODE3)
>;
};
 
dmtimer7_pins: pinmux_dmtimer7_pins {
pinctrl-single,pins = <
-   AM33XX_IOPAD(0x968, PIN_OUTPUT | MUX_MODE5)
+   AM33XX_PADCONF(0x968, PIN_OUTPUT, MUX_MODE5)
>;
};
 
gpio_keys_pins: pinmux_gpio_keys_pins {
pinctrl-single,pins = <
-   AM33XX_IOPAD(0x940, PIN_INPUT | MUX_MODE7)
+   AM33XX_PADCONF(0x940, PIN_INPUT, MUX_MODE7)
>;
};
 
gpio_pins: pinmux_gpio_pins {
pinctrl-single,pins = <
-   AM33XX_IOPAD(0x928, PIN_OUTPUT | MUX_MODE7)
-   AM33XX_IOPAD(0x990, PIN_OUTPUT | MUX_MODE7)
+   AM33XX_PADCONF(0x928, PIN_OUTPUT, MUX_MODE7)
+   AM33XX_PADCONF(0x990, PIN_OUTPUT, MUX_MODE7)
>;
};
 
i2c0_pins: pinmux_i2c0_pins {
pinctrl-single,pins = <
-   AM33XX_IOPAD(0x988, PIN_INPUT_PULLUP | MUX_MODE0)
-   AM33XX_IOPAD(0x98c, PIN_INPUT_PULLUP | MUX_MODE0)
+   AM33XX_PADCONF(0x988, PIN_INPUT_PULLUP, MUX_MODE0)
+   AM33XX_PADCONF(0x98c, PIN_INPUT_PULLUP, MUX_MODE0)
>;
};
 
lcd_disen_pins: pinmux_lcd_disen_pins {
pinctrl-single,pins = <
-   AM33XX_IOPAD(0x9a4, PIN_OUTPUT_PULLUP | SLEWCTRL_SLOW | 
MUX_MODE7)
+   AM33XX_PADCONF(0x9a4, PIN_OUTPUT_PULLUP | 
SLEWCTRL_SLOW, MUX_MODE7)
>;
};
 
lcd_pins_default: pinmux_lcd_pins_default {
pinctrl-single,pins = <
-   AM33XX_IOPAD(0x820, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE1)
-   AM33XX_IOPAD(0x824, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE1)
-   AM33XX_IOPAD(0x828, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE1)
-   AM33XX_IOPAD(0x82c, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE1)
-   AM33XX_IOPAD(0x830, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE1)
-   AM33XX_IOPAD(0x834, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE1)
-   AM33XX_IOPAD(0x838, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE1)
-   AM33XX_IOPAD(0x83c, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE1)
-   AM33XX_IOPAD(0x8a0, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8a4, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8a8, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8ac, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8b0, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8b4, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8b8, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8bc, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8c0, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8c4, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8c8, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8cc, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8d0, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8d4, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8d8, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8dc, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8e0, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8e4, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-   AM33XX_IOPAD(0x8e8, PIN_OUTPUT | SLEWCTRL_SLOW | 
MUX_MODE0)
-

Re: [PATCH v2] staging: media: atomisp: Fix error path in lm3554_probe()

[Alex Dewar]

On 2020-09-03 19:24, Alex Dewar wrote:

The error path for lm3554_probe() contains a number of bugs, including:
  * resource leaks
  * jumping to error labels out of sequence
  * not setting the return value appropriately

Ping?


Fix it up and give the labels more memorable names.

This issue has existed since the code was originally contributed in
commit a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2"),
although the code was subsequently removed altogether and then
reinstated with commit ad85094b293e ("Revert "media: staging: atomisp: Remove 
driver"").

Addresses-Coverity: 1496802 ("Resource leaks")
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Alex Dewar 
---
  .../media/atomisp/i2c/atomisp-lm3554.c| 53 +++
  1 file changed, 30 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c 
b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 7ca7378b1859..cca10a4c2db0 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -833,7 +833,6 @@ static void *lm3554_platform_data_func(struct i2c_client 
*client)
  
  static int lm3554_probe(struct i2c_client *client)

  {
-   int err = 0;
struct lm3554 *flash;
unsigned int i;
int ret;
@@ -843,36 +842,38 @@ static int lm3554_probe(struct i2c_client *client)
return -ENOMEM;
  
  	flash->pdata = lm3554_platform_data_func(client);

-   if (IS_ERR(flash->pdata))
-   return PTR_ERR(flash->pdata);
+   if (IS_ERR(flash->pdata)) {
+   ret = PTR_ERR(flash->pdata);
+   goto err_free_flash;
+   }
  
  	v4l2_i2c_subdev_init(>sd, client, _ops);

flash->sd.internal_ops = _internal_ops;
flash->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
flash->mode = ATOMISP_FLASH_MODE_OFF;
flash->timeout = LM3554_MAX_TIMEOUT / LM3554_TIMEOUT_STEPSIZE - 1;
-   ret =
-   v4l2_ctrl_handler_init(>ctrl_handler,
-  ARRAY_SIZE(lm3554_controls));
+   ret = v4l2_ctrl_handler_init(>ctrl_handler,
+ARRAY_SIZE(lm3554_controls));
if (ret) {
-   dev_err(>dev, "error initialize a ctrl_handler.\n");
-   goto fail2;
+   dev_err(>dev, "error initializing ctrl_handler");
+   goto err_unregister_sd;
}
  
  	for (i = 0; i < ARRAY_SIZE(lm3554_controls); i++)

v4l2_ctrl_new_custom(>ctrl_handler, _controls[i],
 NULL);
  
-	if (flash->ctrl_handler.error) {

-   dev_err(>dev, "ctrl_handler error.\n");
-   goto fail2;
+   ret = flash->ctrl_handler.error;
+   if (ret) {
+   dev_err(>dev, "ctrl_handler error");
+   goto err_free_ctrl_handler;
}
  
  	flash->sd.ctrl_handler = >ctrl_handler;

-   err = media_entity_pads_init(>sd.entity, 0, NULL);
-   if (err) {
-   dev_err(>dev, "error initialize a media entity.\n");
-   goto fail1;
+   ret = media_entity_pads_init(>sd.entity, 0, NULL);
+   if (ret) {
+   dev_err(>dev, "error initializing media entity");
+   goto err_free_ctrl_handler;
}
  
  	flash->sd.entity.function = MEDIA_ENT_F_FLASH;

@@ -881,20 +882,26 @@ static int lm3554_probe(struct i2c_client *client)
  
  	timer_setup(>flash_off_delay, lm3554_flash_off_delay, 0);
  
-	err = lm3554_gpio_init(client);

-   if (err) {
+   ret = lm3554_gpio_init(client);
+   if (ret) {
dev_err(>dev, "gpio request/direction_output fail");
-   goto fail2;
+   goto err_del_timer;
}
-   return atomisp_register_i2c_module(>sd, NULL, LED_FLASH);
-fail2:
+
+   ret = atomisp_register_i2c_module(>sd, NULL, LED_FLASH);
+   if (!ret)
+   return 0;
+
+err_del_timer:
+   del_timer_sync(>flash_off_delay);
media_entity_cleanup(>sd.entity);
+err_free_ctrl_handler:
v4l2_ctrl_handler_free(>ctrl_handler);
-fail1:
+err_unregister_sd:
v4l2_device_unregister_subdev(>sd);
+err_free_flash:
kfree(flash);
-
-   return err;
+   return ret;
  }
  
  static int lm3554_remove(struct i2c_client *client)

Re: [PATCH v2 2/2] Input: atmel_mxt_ts - wake mXT1386 from deep-sleep mode

[Dmitry Osipenko]

18.09.2020 18:55, Wang, Jiada пишет:
...
>>>   +static void mxt_wake(struct mxt_data *data)
>>> +{
>>> +    struct i2c_client *client = data->client;
>>> +    struct device *dev = >client->dev;
>>> +    struct device_node *np = dev->of_node;
>>> +    union i2c_smbus_data dummy;
>>> +
>>> +    if (!of_device_is_compatible(np, "atmel,mXT1386"))
>>> +    return;
>> I'm not sure whether you misses the previous answers from Dmitry
>> Torokhov and Rob Herring, but they suggested to add a new device-tree
>> property which should specify the atmel,wakeup-method.
>>
> I think Rob Herring prefers for the compatible solution than property.

Actually, seems you're right. But I'm not sure now whether he just made
a typo, because it's actually a board-specific option.

It could be more preferred to skip the i2c_smbus_xfer() for the NONE
variant, but it also should be harmless in practice. I guess we indeed
could keep the current variant of yours patch and then add a clarifying
comment to the commit message and to the code, telling that
i2c_smbus_xfer() is harmless in a case of the hardwired WAKE-LINE.

>> There are 3 possible variants:
>>
>>    - NONE
>>    - GPIO
>>    - I2C-SCL
>>
>> Hence we should bail out from mxt_wake() if method is set to NONE or
>> GPIO.
>>
> for "GPIO", we still need 25 ms sleep. but rather than a dummy read,
> WAKE line need to be asserted before sleep.

Correct, I just meant to bail out because GPIO is currently unsupported.

...
>>>   static int mxt_initialize(struct mxt_data *data)
>>>   {
>>>   struct i2c_client *client = data->client;
>>>   int recovery_attempts = 0;
>>>   int error;
>>>   +    mxt_wake(data);
>>> +
>>>   while (1) {
>>
>> I assume the mxt_wake() should be placed here, since there is a 3
>> seconds timeout in the end of the while-loop, meaning that device may
>> get back into deep-sleep on a retry.
>>
> Can you elaborate a little more why exit from bootload mode after sleep
> for 3 second could enter deep-sleep mode.

The loop attempts to exit from bootload mode and then I suppose
mxt_read_info_block() may fail if I2C "accidentally" fails, hence the
deep-sleep mode still will be enabled on a retry.

The datasheet says that there are 2 seconds since the time of the last
I2C access before TS is put back into auto-sleep if deep-sleep mode is
enabled. The wait-loop has msleep(3000).

Re: [PATCH] checkpatch: extend author Signed-off-by check for split From: header

[Joe Perches]

On Sun, 2020-09-20 at 01:08 +0530, Dwaipayan Ray wrote:
> On Sun, Sep 20, 2020 at 12:06 AM Lukas Bulwahn  
> wrote:
> > On Sat, 19 Sep 2020, Joe Perches wrote:
> > > On Sat, 2020-09-19 at 20:12 +0200, Lukas Bulwahn wrote:
> > > > On Sat, 19 Sep 2020, Joe Perches wrote:
> > > > > On Sat, 2020-09-19 at 13:42 +0530, Dwaipayan Ray wrote:
> > > > > > Checkpatch did not handle cases where the author From: header
> > > > > > was split into two lines. The author string went empty and
> > > > > > checkpatch generated a false NO_AUTHOR_SIGN_OFF warning.
> > > > > 
> > > > > It's good to provide an example where the current code
> > > > > doesn't work.
> > > > > 
> > > > Joe, as this is a linux-kernel-mentees patch, we discussed that before
> > > > reaching out to you; you can find Dwaipayan's own evaluation here:
> > > > 
> > > > https://lore.kernel.org/linux-kernel-mentees/cabjpp5botg0qlfsarjtb2vaz_hjf229oaqihhkg4syd35i_...@mail.gmail.com/
> > > > 
> > > > Dwaipayan, Joe's comment is still valid; it would be good to describe
> > > > the reasons why patches might have split lines (as far as see, long
> > > > encodings for non-ascii names).
> > > > 
> > > > I will run my own evaluation of checkpatch.pl before and after patch
> > > > application on Monday and then check if I can confirm Dwaipayan's 
> > > > results.
> > > > 
> > > > > It likely would be better to do this by searching forward for
> > > > > any extension lines after a "^From:' rather than searching
> > > > > backwards as there can be any number of extension lines.
> > > > > 
> > > > Just to sure what you are talking about...
> > > > 
> > > > You mean just to access the next line through the lines array, rather
> > > > than using prevheader and trying to decode that one line twice.
> > > > 
> > > > I agree the logic is a bit redundant and complicated at the moment.
> > > > 
> > > > Once prevheader is non-empty, it already clear that author is '' and
> > > > prevheader decodes with that match, because that is the only way to
> > > > make prevheader non-empty in the first place; at least as far I see it
> > > > right now.
> > > 
> > > Yeah, something like this (completely untested):
> > > ---
> > >  scripts/checkpatch.pl | 8 ++--
> > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > > index 3e474072aa90..2c710d05b184 100755
> > > --- a/scripts/checkpatch.pl
> > > +++ b/scripts/checkpatch.pl
> > > @@ -2679,9 +2679,13 @@ sub process {
> > >   }
> > > 
> > >  # Check the patch for a From:
> > > - if (decode("MIME-Header", $line) =~ /^From:\s*(.*)/) {
> > > + if ($line =~ /^From:\s*(.*)/i) {
> > >   $author = $1;
> > > - $author = encode("utf8", $author) if ($line =~ 
> > > /=\?utf-8\?/i);
> > > + my $curline = $linenr;
> > > + while (defined($rawlines[$curline] && 
> > > $rawlines[$curline++] =~ /^ \s*(.*)/) {
> > > + $author .= $1;
> > > + }
> > > + $author = encode("utf8", $author) if ($author =~ 
> > > /=\?utf-8\?/i);
> > >   $author =~ s/"//g;
> > >   $author = reformat_email($author);
> > >   }
> > > 
> 
> Hi,
> 
> Yeah I think the backwards checking was pretty redundant after all. If the
> extended encoding went too long, the From: header would be split into
> more than two lines and my proposed solution would fail.
> 
> Thanks for the heads up, Joe!
> 
> > Yeah, I get how you would like to see that being implemented. I will work
> > with Dwaipayan to get that properly implemented, properly described and
> > tested.
> > 
> > But let us keep the fun of that task to Dwaipayan... that is what a
> > mentorship is all about :)
> > 
> > Lukas
> 
> Yes definitely, the task is interesting for me, and I would like to solve
> it in a proper way.
> 
> As for the fix, shouldn't we stop the author string concatenation once
> an email address is found? something like:
> 
>   last if  $rawlines[$curline] = ~/^\s*(\S+\@\S+)\s*/

Probably not.

I think it should follow the rfc standard with extension
lines starting with a space.

See rfc 5322, 2.2.3 Long Header Fields

> I will update the patch and sync up with Lukas on this.

Enjoy.

I believe I now have a working version, we can compare later.

cheers, Joe

Re: [PATCH] checkpatch: extend author Signed-off-by check for split From: header

[Dwaipayan Ray]

On Sun, Sep 20, 2020 at 12:06 AM Lukas Bulwahn  wrote:
>
>
>
> On Sat, 19 Sep 2020, Joe Perches wrote:
>
> > On Sat, 2020-09-19 at 20:12 +0200, Lukas Bulwahn wrote:
> > >
> > > On Sat, 19 Sep 2020, Joe Perches wrote:
> > >
> > > > On Sat, 2020-09-19 at 13:42 +0530, Dwaipayan Ray wrote:
> > > > > Checkpatch did not handle cases where the author From: header
> > > > > was split into two lines. The author string went empty and
> > > > > checkpatch generated a false NO_AUTHOR_SIGN_OFF warning.
> > > >
> > > > It's good to provide an example where the current code
> > > > doesn't work.
> > > >
> > >
> > > Joe, as this is a linux-kernel-mentees patch, we discussed that before
> > > reaching out to you; you can find Dwaipayan's own evaluation here:
> > >
> > > https://lore.kernel.org/linux-kernel-mentees/cabjpp5botg0qlfsarjtb2vaz_hjf229oaqihhkg4syd35i_...@mail.gmail.com/
> > >
> > > Dwaipayan, Joe's comment is still valid; it would be good to describe
> > > the reasons why patches might have split lines (as far as see, long
> > > encodings for non-ascii names).
> > >
> > > I will run my own evaluation of checkpatch.pl before and after patch
> > > application on Monday and then check if I can confirm Dwaipayan's results.
> > >
> > > > It likely would be better to do this by searching forward for
> > > > any extension lines after a "^From:' rather than searching
> > > > backwards as there can be any number of extension lines.
> > > >
> > >
> > > Just to sure what you are talking about...
> > >
> > > You mean just to access the next line through the lines array, rather
> > > than using prevheader and trying to decode that one line twice.
> > >
> > > I agree the logic is a bit redundant and complicated at the moment.
> > >
> > > Once prevheader is non-empty, it already clear that author is '' and
> > > prevheader decodes with that match, because that is the only way to
> > > make prevheader non-empty in the first place; at least as far I see it
> > > right now.
> >
> > Yeah, something like this (completely untested):
> > ---
> >  scripts/checkpatch.pl | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 3e474072aa90..2c710d05b184 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -2679,9 +2679,13 @@ sub process {
> >   }
> >
> >  # Check the patch for a From:
> > - if (decode("MIME-Header", $line) =~ /^From:\s*(.*)/) {
> > + if ($line =~ /^From:\s*(.*)/i) {
> >   $author = $1;
> > - $author = encode("utf8", $author) if ($line =~ 
> > /=\?utf-8\?/i);
> > + my $curline = $linenr;
> > + while (defined($rawlines[$curline] && 
> > $rawlines[$curline++] =~ /^ \s*(.*)/) {
> > + $author .= $1;
> > + }
> > + $author = encode("utf8", $author) if ($author =~ 
> > /=\?utf-8\?/i);
> >   $author =~ s/"//g;
> >   $author = reformat_email($author);
> >   }
> >
>

Hi,

Yeah I think the backwards checking was pretty redundant after all. If the
extended encoding went too long, the From: header would be split into
more than two lines and my proposed solution would fail.

Thanks for the heads up, Joe!

> Yeah, I get how you would like to see that being implemented. I will work
> with Dwaipayan to get that properly implemented, properly described and
> tested.
>
> But let us keep the fun of that task to Dwaipayan... that is what a
> mentorship is all about :)
>
> Lukas

Yes definitely, the task is interesting for me, and I would like to solve
it in a proper way.

As for the fix, shouldn't we stop the author string concatenation once
an email address is found? something like:

  last if  $rawlines[$curline] = ~/^\s*(\S+\@\S+)\s*/

I will update the patch and sync up with Lukas on this.

Thanks,
Dwaipayan.

[PATCH 2/3] drm/atomic: Use kthread worker for nonblocking commits

[Rob Clark]

From: Rob Clark 

This will allow us to more easily switch scheduling rules based on what
userspace wants.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_atomic_helper.c | 13 
 include/drm/drm_atomic.h| 31 +
 2 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9e1ad493e689..75eeec5e7b10 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1659,11 +1659,11 @@ static void commit_tail(struct drm_atomic_state 
*old_state)
drm_atomic_state_put(old_state);
 }
 
-static void commit_work(struct work_struct *work)
+static void commit_work(struct kthread_work *work)
 {
struct drm_atomic_state *state = container_of(work,
  struct drm_atomic_state,
- commit_work);
+ commit_kwork);
commit_tail(state);
 }
 
@@ -1797,6 +1797,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 struct drm_atomic_state *state,
 bool nonblock)
 {
+   struct kthread_worker *worker = NULL;
int ret;
 
if (state->async_update) {
@@ -1814,7 +1815,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
if (ret)
return ret;
 
-   INIT_WORK(>commit_work, commit_work);
+   kthread_init_work(>commit_kwork, commit_work);
 
ret = drm_atomic_helper_prepare_planes(dev, state);
if (ret)
@@ -1857,8 +1858,12 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 */
 
drm_atomic_state_get(state);
+
if (nonblock)
-   queue_work(system_unbound_wq, >commit_work);
+   worker = drm_atomic_pick_worker(state);
+
+   if (worker)
+   kthread_queue_work(worker, >commit_kwork);
else
commit_tail(state);
 
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index d07c851d255b..8d0ee19953df 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -373,8 +373,18 @@ struct drm_atomic_state {
 *
 * Work item which can be used by the driver or helpers to execute the
 * commit without blocking.
+*
+* This is deprecated, use commit_kwork.
 */
struct work_struct commit_work;
+
+   /**
+* @commit_kwork:
+*
+* Work item which can be used by the driver or helpers to execute the
+* commit without blocking.
+*/
+   struct kthread_work commit_kwork;
 };
 
 void __drm_crtc_commit_free(struct kref *kref);
@@ -954,6 +964,27 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
  (new_obj_state) = (__state)->private_objs[__i].new_state, 
1); \
 (__i)++)
 
+/**
+ * drm_atomic_pick_worker - helper to get kworker to use for nonblocking commit
+ * @state: the _atomic_state for the commit
+ *
+ * Pick an appropriate worker for a given atomic update.  The first CRTC
+ * invovled in the atomic update is used to pick the worker, to prevent
+ * serializing multiple pageflips / atomic-updates on indenpendent CRTCs.
+ */
+static inline struct kthread_worker *
+drm_atomic_pick_worker(const struct drm_atomic_state *state)
+{
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   unsigned i;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+   return crtc->worker;
+
+   return NULL;
+}
+
 /**
  * drm_atomic_crtc_needs_modeset - compute combined modeset need
  * @state: _crtc_state for the CRTC
-- 
2.26.2

[PATCH 0/3] drm: commit_work scheduling

[Rob Clark]

From: Rob Clark 

The android userspace treats the display pipeline as a realtime problem.
And arguably, if your goal is to not miss frame deadlines (ie. vblank),
it is.  (See https://lwn.net/Articles/809545/ for the best explaination
that I found.)

But this presents a problem with using workqueues for non-blocking
atomic commit_work(), because the SCHED_FIFO userspace thread(s) can
preempt the worker.  Which is not really the outcome you want.. once
the required fences are scheduled, you want to push the atomic commit
down to hw ASAP.

But the decision of whether commit_work should be RT or not really
depends on what userspace is doing.  For a pure CFS userspace display
pipeline, commit_work() should remain SCHED_NORMAL.

To handle this, convert non-blocking commit_work() to use per-CRTC
kthread workers, instead of system_unbound_wq.  Per-CRTC workers are
used to avoid serializing commits when userspace is using a per-CRTC
update loop.

A client-cap is introduced so that userspace can opt-in to SCHED_FIFO
priority commit work.

A potential issue is that since 616d91b68cd ("sched: Remove
sched_setscheduler*() EXPORTs") we have limited RT priority levels,
meaning that commit_work() ends up running at the same priority level
as vblank-work.  This shouldn't be a big problem *yet*, due to limited
use of vblank-work at this point.  And if it could be arranged that
vblank-work is scheduled before signaling out-fences and/or sending
pageflip events, it could probably work ok to use a single priority
level for both commit-work and vblank-work.

Rob Clark (3):
  drm/crtc: Introduce per-crtc kworker
  drm/atomic: Use kthread worker for nonblocking commits
  drm: Add a client-cap to set scheduling mode

 drivers/gpu/drm/drm_atomic_helper.c | 13 ++
 drivers/gpu/drm/drm_auth.c  |  4 
 drivers/gpu/drm/drm_crtc.c  | 37 +
 drivers/gpu/drm/drm_ioctl.c | 13 ++
 include/drm/drm_atomic.h| 31 
 include/drm/drm_crtc.h  | 10 
 include/uapi/drm/drm.h  | 13 ++
 7 files changed, 117 insertions(+), 4 deletions(-)

-- 
2.26.2

[PATCH 3/3] drm: Add a client-cap to set scheduling mode

[Rob Clark]

From: Rob Clark 

Add DRM_CLIENT_CAP_SCHED_MODE so that userspace can control the
scheduling mode for nonblocking atomic commits.  Userspace such as
android, which treats the display pipeline as realtime (SCHED_FIFO)
should set DRM_CLIENT_CAP_SCHED_FIFO to prevent userspace components
of the display pipeline (like surfaceflinger) from preempting atomic
commit_work.

This cap may only be set by the drm master, after setting the
DRM_CLIENT_CAP_ATOMIC cap.  The scheduling mode is returned to default
(SCHED_NORMAL) after master is dropped.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_auth.c  |  4 
 drivers/gpu/drm/drm_crtc.c  | 26 ++
 drivers/gpu/drm/drm_ioctl.c | 13 +
 include/drm/drm_crtc.h  |  2 ++
 include/uapi/drm/drm.h  | 13 +
 5 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index f2d46b7ac6f9..217f422389f9 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -31,6 +31,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -335,6 +336,9 @@ void drm_master_release(struct drm_file *file_priv)
drm_lease_revoke(master);
}
 
+   if (drm_core_check_feature(dev, DRIVER_ATOMIC) && file_priv->is_master)
+   drm_crtc_set_sched_mode(dev, DRM_CLIENT_CAP_SCHED_NORMAL);
+
/* drop the master reference held by the file priv */
if (file_priv->master)
drm_master_put(_priv->master);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4f7c0bfce0a3..02f2be0b1700 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -93,6 +93,32 @@ struct drm_crtc *drm_crtc_from_index(struct drm_device *dev, 
int idx)
 }
 EXPORT_SYMBOL(drm_crtc_from_index);
 
+/**
+ * drm_crtc_set_sched_mode:
+ * @dev: DRM device
+ * @mode: one of DRM_CLIENT_CAP_SCHED_x
+ *
+ * Set the scheduling mode for per-CRTC kthread workers.  This controls
+ * whether nonblocking atomic commits will run with SCHED_NORMAL or
+ * SCHED_FIFO (rt) priority.
+ */
+void drm_crtc_set_sched_mode(struct drm_device *dev, int mode)
+{
+   struct drm_crtc *crtc;
+
+   drm_for_each_crtc(crtc, dev) {
+   switch (mode) {
+   case DRM_CLIENT_CAP_SCHED_NORMAL:
+   /* zero is default nice value for kthreads: */
+   sched_set_normal(crtc->worker->task, 0);
+   break;
+   case DRM_CLIENT_CAP_SCHED_FIFO:
+   sched_set_fifo(crtc->worker->task);
+   break;
+   }
+   }
+}
+
 int drm_crtc_force_disable(struct drm_crtc *crtc)
 {
struct drm_mode_set set = {
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 789ee65ac1f5..44920621571c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -362,6 +362,19 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
return -EINVAL;
file_priv->writeback_connectors = req->value;
break;
+   case DRM_CLIENT_CAP_SCHED_MODE:
+   if (!file_priv->is_master)
+   return -EPERM;
+   if (!file_priv->atomic)
+   return -EOPNOTSUPP;
+   switch (req->value) {
+   case DRM_CLIENT_CAP_SCHED_NORMAL:
+   case DRM_CLIENT_CAP_SCHED_FIFO:
+   drm_crtc_set_sched_mode(dev, req->value);
+   return 0;
+   default:
+   return -EINVAL;
+   }
default:
return -EINVAL;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8964a3732bca..6dd4d01b7191 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1245,6 +1245,8 @@ static inline uint32_t drm_crtc_mask(const struct 
drm_crtc *crtc)
 int drm_mode_set_config_internal(struct drm_mode_set *set);
 struct drm_crtc *drm_crtc_from_index(struct drm_device *dev, int idx);
 
+void drm_crtc_set_sched_mode(struct drm_device *dev, int mode);
+
 /**
  * drm_crtc_find - look up a CRTC object from its ID
  * @dev: DRM device
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 808b48a93330..989e007ef608 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -698,6 +698,19 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS5
 
+/**
+ * DRM_CLIENT_CAP_SCHED_MODE
+ *
+ * Allow userspace to control the scheduling parameters for nonblocking
+ * commit.  The default is SCHED_NORMAL/CFS.  Userspace using SCHED_FIFO
+ * in the rendering/display pipeline should use DRM_CLIENT_CAP_SCHED_FIFO
+ * to prevent userspace portions of the display pipeline from preempting
+ * nonblocking commit_work.
+ */
+#define DRM_CLIENT_CAP_SCHED_MODE 6
+#  define DRM_CLIENT_CAP_SCHED_NORMAL 0
+#  

[PATCH 1/3] drm/crtc: Introduce per-crtc kworker

[Rob Clark]

From: Rob Clark 

This will be used for non-block atomic commits.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc.c | 11 +++
 include/drm/drm_crtc.h |  8 
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index aecdd7ea26dc..4f7c0bfce0a3 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -326,6 +326,14 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
   config->prop_out_fence_ptr, 0);
drm_object_attach_property(>base,
   config->prop_vrr_enabled, 0);
+
+   crtc->worker = kthread_create_worker(0, "%s-worker", 
crtc->name);
+   if (IS_ERR(crtc->worker)) {
+   drm_mode_object_unregister(dev, >base);
+   ret = PTR_ERR(crtc->worker);
+   crtc->worker = NULL;
+   return ret;
+   }
}
 
return 0;
@@ -366,6 +374,9 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
 
kfree(crtc->name);
 
+   if (crtc->worker)
+   kthread_destroy_worker(crtc->worker);
+
memset(crtc, 0, sizeof(*crtc));
 }
 EXPORT_SYMBOL(drm_crtc_cleanup);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 59b51a09cae6..8964a3732bca 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1172,6 +1173,13 @@ struct drm_crtc {
 * Initialized via drm_self_refresh_helper_init().
 */
struct drm_self_refresh_data *self_refresh_data;
+
+   /**
+* worker:
+*
+* Per-CRTC worker for nonblock atomic commits.
+*/
+   struct kthread_worker *worker;
 };
 
 /**
-- 
2.26.2

Re: [PATCH 2/2] staging: media: atomisp: Remove unhelpful info message

[Alex Dewar]

On 2020-09-03 19:31, Alex Dewar wrote:

We don't really need to know that the LED pin reset successfully.

Ping?


Signed-off-by: Alex Dewar 
---
  drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c 
b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 621555b0cf6b..77b7f59e62d7 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -771,7 +771,6 @@ static int lm3554_gpio_init(struct i2c_client *client)
ret = gpiod_direction_output(pdata->gpio_reset, 0);
if (ret < 0)
return ret;
-   dev_info(>dev, "flash led reset successfully\n");
  
  	if (!pdata->gpio_strobe)

return -EINVAL;

Re: [PATCH] power: supply: charger-manager: Tidy function

[Alex Dewar]

On 2020-09-02 17:58, Alex Dewar wrote:

check_charging_duration() contains some copy-pasted code, which makes it
less readable. Refactor the function to be a bit tidier.

Ping?


I've also fixed a couple of typos.

Signed-off-by: Alex Dewar 
---
  drivers/power/supply/charger-manager.c | 39 +-
  1 file changed, 14 insertions(+), 25 deletions(-)

diff --git a/drivers/power/supply/charger-manager.c 
b/drivers/power/supply/charger-manager.c
index 07992821e252..67c7b1fb6601 100644
--- a/drivers/power/supply/charger-manager.c
+++ b/drivers/power/supply/charger-manager.c
@@ -443,42 +443,31 @@ static int try_charger_enable(struct charger_manager *cm, 
bool enable)
   * check_charging_duration - Monitor charging/discharging duration
   * @cm: the Charger Manager representing the battery.
   *
- * If whole charging duration exceed 'charging_max_duration_ms',
+ * If whole charging duration exceeds 'charging_max_duration_ms',
   * cm stop charging to prevent overcharge/overheat. If discharging
- * duration exceed 'discharging _max_duration_ms', charger cable is
+ * duration exceeds 'discharging _max_duration_ms', charger cable is
   * attached, after full-batt, cm start charging to maintain fully
   * charged state for battery.
   */
  static int check_charging_duration(struct charger_manager *cm)
  {
struct charger_desc *desc = cm->desc;
-   u64 curr = ktime_to_ms(ktime_get());
u64 duration;
-   int ret = false;
  
-	if (!desc->charging_max_duration_ms &&

-   !desc->discharging_max_duration_ms)
-   return ret;
-
-   if (cm->charger_enabled) {
-   duration = curr - cm->charging_start_time;
-
-   if (duration > desc->charging_max_duration_ms) {
-   dev_info(cm->dev, "Charging duration exceed %ums\n",
-desc->charging_max_duration_ms);
-   ret = true;
-   }
-   } else if (cm->battery_status == POWER_SUPPLY_STATUS_NOT_CHARGING) {
-   duration = curr - cm->charging_end_time;
+   if ((desc->charging_max_duration_ms == 0 &&
+   desc->discharging_max_duration_ms == 0))
+   return false;
+   if (!cm->charger_enabled &&
+   cm->battery_status != POWER_SUPPLY_STATUS_NOT_CHARGING)
+   return false;
  
-		if (duration > desc->charging_max_duration_ms) {

-   dev_info(cm->dev, "Discharging duration exceed %ums\n",
-desc->discharging_max_duration_ms);
-   ret = true;
-   }
+   duration = ktime_to_ms(ktime_get()) - cm->charging_start_time;
+   if (duration > desc->charging_max_duration_ms) {
+   dev_info(cm->dev, "Charging duration exceeds %ums\n",
+   desc->charging_max_duration_ms);
+   return true;
}
-
-   return ret;
+   return false;
  }
  
  static int cm_get_battery_temperature_by_psy(struct charger_manager *cm,

Re: [PATCH v3 2/2] mailbox: Add Broadcom STB mailbox driver

[Randy Dunlap]

Hi Jim,

On 9/19/20 12:22 PM, Jim Quinlan wrote:
> ---
>  drivers/mailbox/Kconfig   |  12 +++
>  drivers/mailbox/Makefile  |   2 +
>  drivers/mailbox/brcmstb-mailbox.c | 173 ++
>  3 files changed, 187 insertions(+)
>  create mode 100644 drivers/mailbox/brcmstb-mailbox.c
> 
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index 05b1009e2820..96faf1139cb9 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -254,4 +254,16 @@ config QCOM_IPCC
> acts as an interrupt controller for receiving interrupts from clients.
> Say Y here if you want to build this driver.
>  
> +config BRCMSTB_MBOX
> + tristate "Broadcom STB Mailbox"
> + depends on ARM64 || ARM
> + depends on ARM_SCMI_PROTOCOL && ARCH_BRCMSTB
> + default ARM_SCMI_PROTOCOL && ARCH_BRCMSTB
> +help

"help" is still indented with spaces instead of one tab.
You probably should wait a bit to see if there are other comments on this patch
before doing a v4.

> +   Mailbox implementation of the Broadcom STB for the sole purposes
> +   of SCMI communication.  This is used by the SCMI drivers to
> +   communicate with FW that runs in EL3.  This mailbox only implements
> +   the agent-to-platform channgel of SCMI but may be augmented in
> +   the future to add the platform-to-agent channel.
> +
>  endif
> diff --git a/drivers/mailbox/brcmstb-mailbox.c 
> b/drivers/mailbox/brcmstb-mailbox.c
> new file mode 100644
> index ..27d87938b08c
> --- /dev/null
> +++ b/drivers/mailbox/brcmstb-mailbox.c
> @@ -0,0 +1,173 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2017, Broadcom */

2017 is a little surprising.


> +#if defined(CONFIG_ARM64) || defined(CONFIG_ARM)
> +static int announce_msg(unsigned int mbox_num, unsigned int ch)
> +{
> + struct arm_smccc_res res;
> +
> + if (ch >= NUM_CHAN)
> + return -EIO;
> + arm_smccc_smc(BRCM_FID(ch), mbox_num, 0, 0, 0, 0, 0, 0, );
> + if (res.a0)
> + return -EIO;
> + return 0;
> +}
> +#else
> +#error Func announce_msg() not defined for the current ARCH
> +#endif

This is handled by the Kconfig depends on clause.
Why is it repeated here?



thanks.
-- 
~Randy

Re: [PATCH] drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy

[Alex Dewar]

On 2020-09-11 13:57, Neil Armstrong wrote:

On 09/09/2020 21:02, Alex Dewar wrote:

kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
this pattern.

Friendly ping?


Issue identified with Coccinelle.

Signed-off-by: Alex Dewar 
---
  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 52f5c5a2ed64..7e9a62ad56e8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -1049,12 +1049,10 @@ static void debugfs_create_files(void *data)
};
int i;
  
-	dsi->debugfs_vpg = kmalloc(sizeof(debugfs), GFP_KERNEL);

+   dsi->debugfs_vpg = kmemdup(debugfs, sizeof(debugfs), GFP_KERNEL);
if (!dsi->debugfs_vpg)
return;
  
-	memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs));

-
for (i = 0; i < ARRAY_SIZE(debugfs); i++)
debugfs_create_file(dsi->debugfs_vpg[i].name, 0644,
dsi->debugfs, >debugfs_vpg[i],


Acked-by: Neil Armstrong 

Thanks,
Neil

Re: [PATCH] staging: media: atomisp: Don't do unnecessary zeroing of memory

[Alex Dewar]

On 2020-09-09 21:48, Alex Dewar wrote:

In a few places in pci/sh_css_params.c, memset is used to zero memory
immediately before it is freed. As none of these structs appear to
contain sensitive information, just remove the calls to memset.

Friendly ping?


Suggested-by: Dan Carpenter 
Signed-off-by: Alex Dewar 
---
  drivers/staging/media/atomisp/pci/sh_css_params.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/sh_css_params.c 
b/drivers/staging/media/atomisp/pci/sh_css_params.c
index 2c67c23b3700..24fc497bd491 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_params.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_params.c
@@ -4378,7 +4378,6 @@ ia_css_3a_statistics_free(struct ia_css_3a_statistics *me)
if (me) {
kvfree(me->rgby_data);
kvfree(me->data);
-   memset(me, 0, sizeof(struct ia_css_3a_statistics));
kvfree(me);
}
  }
@@ -4417,7 +4416,6 @@ ia_css_dvs_statistics_free(struct ia_css_dvs_statistics 
*me)
if (me) {
kvfree(me->hor_proj);
kvfree(me->ver_proj);
-   memset(me, 0, sizeof(struct ia_css_dvs_statistics));
kvfree(me);
}
  }
@@ -4459,7 +4457,6 @@ ia_css_dvs_coefficients_free(struct 
ia_css_dvs_coefficients *me)
if (me) {
kvfree(me->hor_coefs);
kvfree(me->ver_coefs);
-   memset(me, 0, sizeof(struct ia_css_dvs_coefficients));
kvfree(me);
}
  }
@@ -4551,7 +4548,6 @@ ia_css_dvs2_statistics_free(struct ia_css_dvs2_statistics 
*me)
kvfree(me->ver_prod.odd_imag);
kvfree(me->ver_prod.even_real);
kvfree(me->ver_prod.even_imag);
-   memset(me, 0, sizeof(struct ia_css_dvs2_statistics));
kvfree(me);
}
  }
@@ -4635,7 +4631,6 @@ ia_css_dvs2_coefficients_free(struct 
ia_css_dvs2_coefficients *me)
kvfree(me->ver_coefs.odd_imag);
kvfree(me->ver_coefs.even_real);
kvfree(me->ver_coefs.even_imag);
-   memset(me, 0, sizeof(struct ia_css_dvs2_coefficients));
kvfree(me);
}
  }
@@ -4710,7 +4705,6 @@ ia_css_dvs2_6axis_config_free(struct 
ia_css_dvs_6axis_config *dvs_6axis_config)
kvfree(dvs_6axis_config->ycoords_y);
kvfree(dvs_6axis_config->xcoords_uv);
kvfree(dvs_6axis_config->ycoords_uv);
-   memset(dvs_6axis_config, 0, sizeof(struct 
ia_css_dvs_6axis_config));
kvfree(dvs_6axis_config);
}
  }

Re: [PATCH v2] PCI: keystone: Enable compile-testing on !ARM

[Alex Dewar]

On 2020-09-06 20:51, Alex Dewar wrote:

Currently the Keystone driver can only be compile-tested on ARM, but
this restriction seems unnecessary. Get rid of it to increase test
coverage.

Friendly ping?


Build-tested with allyesconfig on x86, ppc, mips and riscv.

Signed-off-by: Alex Dewar 
---
  drivers/pci/controller/dwc/Kconfig | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/Kconfig 
b/drivers/pci/controller/dwc/Kconfig
index 044a3761c44f..ca36691314ed 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -107,7 +107,7 @@ config PCI_KEYSTONE
  
  config PCI_KEYSTONE_HOST

bool "PCI Keystone Host Mode"
-   depends on ARCH_KEYSTONE || ARCH_K3 || ((ARM || ARM64) && COMPILE_TEST)
+   depends on ARCH_KEYSTONE || ARCH_K3 || COMPILE_TEST
depends on PCI_MSI_IRQ_DOMAIN
select PCIE_DW_HOST
select PCI_KEYSTONE
@@ -119,7 +119,7 @@ config PCI_KEYSTONE_HOST
  
  config PCI_KEYSTONE_EP

bool "PCI Keystone Endpoint Mode"
-   depends on ARCH_KEYSTONE || ARCH_K3 || ((ARM || ARM64) && COMPILE_TEST)
+   depends on ARCH_KEYSTONE || ARCH_K3 || COMPILE_TEST
depends on PCI_ENDPOINT
select PCIE_DW_EP
select PCI_KEYSTONE

[PATCH v2] net: dsa: mt7530: Add some return-value checks

[Alex Dewar]

In mt7531_cpu_port_config(), if the variable port is neither 5 nor 6,
then variable interface will be used uninitialised. Change the function
to return -EINVAL in this case.

As the return value of mt7531_cpu_port_config() is never checked
(even though it returns an int) add a check in the correct place so that
the error can be passed up the call stack. Now that we correctly handle
errors thrown in this function, also check the return value of
mt7531_mac_config() in case an error occurs here. Also add misisng
checks to mt7530_setup() and mt7531_setup(), which are another level
further up the call stack.

Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch")
Addresses-Coverity: 1496993 ("Uninitialized variables")
Signed-off-by: Alex Dewar 
---
v2:
- fix typo in commit message
- split variable declarations onto multiple lines (Gustavo)
- add additional checks for mt753*_setup (Landen)

 drivers/net/dsa/mt7530.c | 31 ++-
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 61388945d316..cb3efa7de7a8 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -945,10 +945,14 @@ static int
 mt753x_cpu_port_enable(struct dsa_switch *ds, int port)
 {
struct mt7530_priv *priv = ds->priv;
+   int ret;
 
/* Setup max capability of CPU port at first */
-   if (priv->info->cpu_port_config)
-   priv->info->cpu_port_config(ds, port);
+   if (priv->info->cpu_port_config) {
+   ret = priv->info->cpu_port_config(ds, port);
+   if (ret)
+   return ret;
+   }
 
/* Enable Mediatek header mode on the cpu port */
mt7530_write(priv, MT7530_PVC_P(port),
@@ -1631,9 +1635,11 @@ mt7530_setup(struct dsa_switch *ds)
mt7530_rmw(priv, MT7530_PCR_P(i), PCR_MATRIX_MASK,
   PCR_MATRIX_CLR);
 
-   if (dsa_is_cpu_port(ds, i))
-   mt753x_cpu_port_enable(ds, i);
-   else
+   if (dsa_is_cpu_port(ds, i)) {
+   ret = mt753x_cpu_port_enable(ds, i);
+   if (ret)
+   return ret;
+   } else
mt7530_port_disable(ds, i);
 
/* Enable consistent egress tag */
@@ -1785,9 +1791,11 @@ mt7531_setup(struct dsa_switch *ds)
 
mt7530_set(priv, MT7531_DBG_CNT(i), MT7531_DIS_CLR);
 
-   if (dsa_is_cpu_port(ds, i))
-   mt753x_cpu_port_enable(ds, i);
-   else
+   if (dsa_is_cpu_port(ds, i)) {
+   ret = mt753x_cpu_port_enable(ds, i);
+   if (ret)
+   return ret;
+   } else
mt7530_port_disable(ds, i);
 
/* Enable consistent egress tag */
@@ -2276,6 +2284,7 @@ mt7531_cpu_port_config(struct dsa_switch *ds, int port)
struct mt7530_priv *priv = ds->priv;
phy_interface_t interface;
int speed;
+   int ret;
 
switch (port) {
case 5:
@@ -2293,6 +2302,8 @@ mt7531_cpu_port_config(struct dsa_switch *ds, int port)
 
priv->p6_interface = interface;
break;
+   default:
+   return -EINVAL;
}
 
if (interface == PHY_INTERFACE_MODE_2500BASEX)
@@ -2300,7 +2311,9 @@ mt7531_cpu_port_config(struct dsa_switch *ds, int port)
else
speed = SPEED_1000;
 
-   mt7531_mac_config(ds, port, MLO_AN_FIXED, interface);
+   ret = mt7531_mac_config(ds, port, MLO_AN_FIXED, interface);
+   if (ret)
+   return ret;
mt7530_write(priv, MT7530_PMCR_P(port),
 PMCR_CPU_PORT_SETTING(priv->id));
mt753x_phylink_mac_link_up(ds, port, MLO_AN_FIXED, interface, NULL,
-- 
2.28.0

[PATCH v3 1/2] dt-bindings: Add bindings for BrcmSTB SCMI mailbox driver

[Jim Quinlan]

Bindings are added.  Only one interrupt is needed because
we do not yet employ the SCMI p2a channel.

Signed-off-by: Jim Quinlan 
---
 .../bindings/mailbox/brcm,brcmstb-mbox.yaml   | 39 +++
 1 file changed, 39 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/brcm,brcmstb-mbox.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/brcm,brcmstb-mbox.yaml 
b/Documentation/devicetree/bindings/mailbox/brcm,brcmstb-mbox.yaml
new file mode 100644
index ..797c0cc609a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,brcmstb-mbox.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+$id: http://devicetree.org/schemas/mailbox/brcm,brcmstb-mbox.yaml#
+
+title: Broadcom STB mailbox driver bindings
+
+maintainers:
+  - Jim Quinlan 
+
+properties:
+  compatible:
+enum:
+  - brcm,brcmstb-mbox
+
+  interrupts:
+items:
+  - description: a2p return interrupt, indicates SCMI msg completion.
+
+  "#mbox-cells":
+const: 1
+
+required:
+  - compatible
+  - interrupts
+  - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+mailbox {
+  compatible = "brcm,brcmstb-mailbox";
+  #mbox-cells = <1>;
+  interrupts = ;
+};
+...
-- 
2.17.1



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver

[Jason Gunthorpe]

On Sat, Sep 19, 2020 at 07:27:30PM +0200, Greg Kroah-Hartman wrote:
> > It's probably heresy, but why do I need to integrate into the RDMA 
> > subsystem ?
> > I understand your reasoning about networking (Ethernet) as the driver
> > connects to the kernel networking stack (netdev), but with RDMA the
> > driver doesn't use or connect to anything in that stack. If I were to
> > support IBverbs and declare that I support it, then of course I would
> > need to integrate to the RDMA subsystem and add my backend to
> > rdma-core.
> 
> IBverbs are horrid and I would not wish them on anyone.  Seriously.

I'm curious what drives this opinion? Did you have it since you
reviewed the initial submission all those years ago?

> I think the general rdma apis are the key here, not the userspace api.

Are you proposing that habana should have uAPI in drivers/misc and
present a standard rdma-core userspace for it? This is the only
userspace programming interface for RoCE HW. I think that would be
much more work.

If not, what open source userspace are you going to ask them to
present to merge the kernel side into misc?

> Note, I do not know exactly what they are, but no, IBverbs are not ok.

Should we stop merging new drivers and abandon the RDMA subsystem? Is
there something you'd like to see fixed?

Don't really understand your position, sorry.

Jason

[PATCH v3 2/2] mailbox: Add Broadcom STB mailbox driver

[Jim Quinlan]

This is a simple mailbox driver to be used by the SCMI protocol stack.  It
only implements the agent-to-platform channel; we may implement the
platform-to-agent channel in the future.  An unusual aspect of this driver
is how the completion of an SCMI message is indicated.  An SCMI message is
initiated with an ARM SMC call, but the return of this call does not
indicate the execution or completion of the message.  Rather, the message's
completion is signaled by an interrupt.

Signed-off-by: Jim Quinlan 
Signed-off-by: Florian Fainelli 
---
 drivers/mailbox/Kconfig   |  12 +++
 drivers/mailbox/Makefile  |   2 +
 drivers/mailbox/brcmstb-mailbox.c | 173 ++
 3 files changed, 187 insertions(+)
 create mode 100644 drivers/mailbox/brcmstb-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 05b1009e2820..96faf1139cb9 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -254,4 +254,16 @@ config QCOM_IPCC
  acts as an interrupt controller for receiving interrupts from clients.
  Say Y here if you want to build this driver.
 
+config BRCMSTB_MBOX
+   tristate "Broadcom STB Mailbox"
+   depends on ARM64 || ARM
+   depends on ARM_SCMI_PROTOCOL && ARCH_BRCMSTB
+   default ARM_SCMI_PROTOCOL && ARCH_BRCMSTB
+help
+ Mailbox implementation of the Broadcom STB for the sole purposes
+ of SCMI communication.  This is used by the SCMI drivers to
+ communicate with FW that runs in EL3.  This mailbox only implements
+ the agent-to-platform channgel of SCMI but may be augmented in
+ the future to add the platform-to-agent channel.
+
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 60d224b723a1..a74efd02eece 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -54,3 +54,5 @@ obj-$(CONFIG_SUN6I_MSGBOX)+= sun6i-msgbox.o
 obj-$(CONFIG_SPRD_MBOX)+= sprd-mailbox.o
 
 obj-$(CONFIG_QCOM_IPCC)+= qcom-ipcc.o
+
+obj-$(CONFIG_BRCMSTB_MBOX) += brcmstb-mailbox.o
diff --git a/drivers/mailbox/brcmstb-mailbox.c 
b/drivers/mailbox/brcmstb-mailbox.c
new file mode 100644
index ..27d87938b08c
--- /dev/null
+++ b/drivers/mailbox/brcmstb-mailbox.c
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2017, Broadcom */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#if defined(CONFIG_ARM64) || defined(CONFIG_ARM)
+#include 
+#endif
+
+#define BRCM_SCMI_SMC_OEM_FUNC 0x400
+#define BRCM_SCMI_MBOX_NUM 0
+#define BRCM_FID(ch) ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   IS_ENABLED(CONFIG_ARM64), \
+   ARM_SMCCC_OWNER_OEM, \
+   BRCM_SCMI_SMC_OEM_FUNC + (ch))
+enum {
+   A2P_CHAN = 0,
+   NUM_CHAN
+};
+
+struct chan_priv {
+   unsigned int mbox_num;
+   unsigned int ch;
+};
+
+struct brcm_mbox {
+   struct mbox_controller controller;
+   int irqs[NUM_CHAN];
+};
+
+static struct mbox_chan *brcm_mbox_of_xlate(struct mbox_controller *controller,
+   const struct of_phandle_args *sp)
+{
+   unsigned int ch = sp->args[0];
+   struct brcm_mbox *mbox
+   = container_of(controller, struct brcm_mbox, controller);
+
+   if (!mbox || ch >= NUM_CHAN)
+   return ERR_PTR(-ENOENT);
+
+   return >controller.chans[ch];
+}
+
+#if defined(CONFIG_ARM64) || defined(CONFIG_ARM)
+static int announce_msg(unsigned int mbox_num, unsigned int ch)
+{
+   struct arm_smccc_res res;
+
+   if (ch >= NUM_CHAN)
+   return -EIO;
+   arm_smccc_smc(BRCM_FID(ch), mbox_num, 0, 0, 0, 0, 0, 0, );
+   if (res.a0)
+   return -EIO;
+   return 0;
+}
+#else
+#error Func announce_msg() not defined for the current ARCH
+#endif
+
+static int brcm_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+   struct chan_priv *priv = chan->con_priv;
+
+   return announce_msg(priv->mbox_num, priv->ch);
+}
+
+static int brcm_mbox_startup(struct mbox_chan *chan)
+{
+   return 0;
+}
+
+static const struct mbox_chan_ops brcm_mbox_ops = {
+   .send_data = brcm_mbox_send_data,
+   .startup = brcm_mbox_startup,
+};
+
+static irqreturn_t brcm_a2p_isr(int irq, void *data)
+{
+   struct mbox_chan *chan = data;
+
+   mbox_chan_received_data(chan, NULL);
+   return IRQ_HANDLED;
+}
+
+static int brcm_mbox_probe(struct platform_device *pdev)
+{
+   struct brcm_mbox *mbox;
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
+   struct chan_priv *chan_priv;
+   int ret;
+
+   if (!np)
+   return -EINVAL;
+
+   mbox = devm_kzalloc(>dev, sizeof(*mbox), GFP_KERNEL);
+   if (!mbox)
+   return -ENOMEM;
+
+   /* Allocate channels */
+   

[PATCH v3 0/2] mailbox: Add Broadcom STB mailbox driver

[Jim Quinlan]

Patchset Summary:
  Adds a simple mailbox driver to be used by the ARM SCMI drivers.

v3:
  Commit "mailbox: Add Broadcom STB mailbox driver"
  -- Fixed indentation on Kconfig file (RandyD).

v2:
  Commit "mailbox: Add Broadcom STB mailbox driver"
  -- Remove the Kconfig dependency on SMP (Florian)
  Commit "mailbox: Add Broadcom STB mailbox driver"
  -- Drop label,unit address; changed title,description (RobH)

v1:
  -- Original submission.

Jim Quinlan (2):
  dt-bindings: Add bindings for BrcmSTB SCMI mailbox driver
  mailbox: Add Broadcom STB mailbox driver

 .../bindings/mailbox/brcm,brcmstb-mbox.yaml   |  39 
 drivers/mailbox/Kconfig   |  12 ++
 drivers/mailbox/Makefile  |   2 +
 drivers/mailbox/brcmstb-mailbox.c | 173 ++
 4 files changed, 226 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/brcm,brcmstb-mbox.yaml
 create mode 100644 drivers/mailbox/brcmstb-mailbox.c

-- 
2.17.1



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH -next v2] usb: gadget: lpc32xx_udc: Convert to DEFINE_SHOW_ATTRIBUTE

[Vladimir Zapolskiy]

On 9/19/20 5:52 AM, Qinglang Miao wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
> 
> Signed-off-by: Qinglang Miao 

Acked-by: Vladimir Zapolskiy 

--
Best wishes,
Vladimir

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

[Linus Torvalds]

On Sat, Sep 19, 2020 at 10:39 AM Matthew Wilcox  wrote:
>
> My concern with that is people might use kmap() and then pass the address
> to a different task.  So we need to audit the current users of kmap()
> and convert any that do that into using vmap() instead.

Ahh. Yes, I guess they might do that. It sounds strange, but not
entirely crazy - I could imagine some "PIO thread" that does IO to a
page that has been set up by somebody else using kmap(). Or similar.

Linus

Re: [PATCH 4/7] crypto: sun4i-ss: handle BigEndian for cipher

[LABBE Corentin]

On Fri, Sep 18, 2020 at 06:09:15PM +1000, Herbert Xu wrote:
> On Fri, Sep 18, 2020 at 10:06:58AM +0200, LABBE Corentin wrote:
> >
> > But I think only me will see it and since I already have this on my TODO 
> > list, I dont see any interest to leave it failing.
> > Furthermore, having a clean BE boot will permit to enable BE boots for 
> > thoses SoCs on kernelCI.
> 
> I'll happily accept patches that fix the actual bug but not ones
> just papering over it.
> 

I am sorry, you are right.
Furthermore, while respining to fix it, it seems that the current fix is enough.
I have rerun a clean rebuild and test on A10/A13/A20/A33 with BE and sun4i-ss 
is working fine.

I will sent a clean v2.

Regards

[PATCH v2] dmaengine: qcom: Add ADM driver

[Jonathan McDowell]

Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA
controller found in the MSM8x60 and IPQ/APQ8064 platforms.

The ADM supports both memory to memory transactions and memory
to/from peripheral device transactions.  The controller also provides
flow control capabilities for transactions to/from peripheral devices.

The initial release of this driver supports slave transfers to/from
peripherals and also incorporates CRCI (client rate control interface)
flow control.

Signed-off-by: Andy Gross 
Signed-off-by: Thomas Pedersen 
Signed-off-by: Jonathan McDowell 

(I'm not sure how best to attribute this. It's originally from Andy
Gross, the version I picked up was a later version from Thomas Pedersen,
and I can't find clear indication of why the latest version wasn't
applied. The device tree details were added back in September 2014. The
driver is the missing piece in mainline for IPQ8064 NAND support and
I've been using it successfully with my RB3011 device on 5.8+)

v2:
- Address Vinod's review comments
  - GFP_NOWAIT instead of GFP_ATOMIC
  - Use devm_platform_ioremap_resource()
  - Call tasklet_kill on remove
  - Sort Kconfig/Makefile entries
  - SPDX identifier
  - Formatting fixes for checkpatch --strict
---
 drivers/dma/qcom/Kconfig|  11 +
 drivers/dma/qcom/Makefile   |   1 +
 drivers/dma/qcom/qcom_adm.c | 909 
 3 files changed, 921 insertions(+)
 create mode 100644 drivers/dma/qcom/qcom_adm.c

diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index 3bcb689162c6..c78e8dfd0c2d 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -1,4 +1,15 @@
 # SPDX-License-Identifier: GPL-2.0-only
+config QCOM_ADM
+   tristate "Qualcomm ADM support"
+   depends on (ARCH_QCOM || COMPILE_TEST) && !64BIT
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Enable support for the Qualcomm Application Data Mover (ADM) DMA
+ controller, as present on MSM8x60, APQ8064, and IPQ8064 devices.
+ This controller provides DMA capabilities for both general purpose
+ and on-chip peripheral devices.
+
 config QCOM_BAM_DMA
tristate "QCOM BAM DMA support"
depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 1ae92da88b0c..346e643fbb6d 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_QCOM_ADM) += qcom_adm.o
 obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
 obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
 hdma_mgmt-objs  := hidma_mgmt.o hidma_mgmt_sys.o
diff --git a/drivers/dma/qcom/qcom_adm.c b/drivers/dma/qcom/qcom_adm.c
new file mode 100644
index ..a5672039fc6b
--- /dev/null
+++ b/drivers/dma/qcom/qcom_adm.c
@@ -0,0 +1,909 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../dmaengine.h"
+#include "../virt-dma.h"
+
+/* ADM registers - calculated from channel number and security domain */
+#define ADM_CHAN_MULTI 0x4
+#define ADM_CI_MULTI   0x4
+#define ADM_CRCI_MULTI 0x4
+#define ADM_EE_MULTI   0x800
+#define ADM_CHAN_OFFS(chan)(ADM_CHAN_MULTI * (chan))
+#define ADM_EE_OFFS(ee)(ADM_EE_MULTI * (ee))
+#define ADM_CHAN_EE_OFFS(chan, ee) (ADM_CHAN_OFFS(chan) + ADM_EE_OFFS(ee))
+#define ADM_CHAN_OFFS(chan)(ADM_CHAN_MULTI * (chan))
+#define ADM_CI_OFFS(ci)(ADM_CHAN_OFF(ci))
+#define ADM_CH_CMD_PTR(chan, ee)   (ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_RSLT(chan, ee)  (0x40 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_FLUSH_STATE0(chan, ee)  (0x80 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_STATUS_SD(chan, ee) (0x200 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_CONF(chan)  (0x240 + ADM_CHAN_OFFS(chan))
+#define ADM_CH_RSLT_CONF(chan, ee) (0x300 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_SEC_DOMAIN_IRQ_STATUS(ee)  (0x380 + ADM_EE_OFFS(ee))
+#define ADM_CI_CONF(ci)(0x390 + (ci) * ADM_CI_MULTI)
+#define ADM_GP_CTL 0x3d8
+#define ADM_CRCI_CTL(crci, ee) (0x400 + (crci) * ADM_CRCI_MULTI + \
+   ADM_EE_OFFS(ee))
+
+/* channel status */
+#define ADM_CH_STATUS_VALIDBIT(1)
+
+/* channel result */
+#define ADM_CH_RSLT_VALID  BIT(31)
+#define ADM_CH_RSLT_ERRBIT(3)
+#define ADM_CH_RSLT_FLUSH  BIT(2)
+#define ADM_CH_RSLT_TPDBIT(1)
+
+/* channel conf */
+#define ADM_CH_CONF_SHADOW_EN  

[tip: x86/cpu] KVM: SVM: Don't flush cache if hardware enforces cache coherency across encryption domains

[tip-bot2 for Krish Sadhukhan]

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID: e1ebb2b49048c4767cfa0d8466f9c701e549fa5e
Gitweb:
https://git.kernel.org/tip/e1ebb2b49048c4767cfa0d8466f9c701e549fa5e
Author:Krish Sadhukhan 
AuthorDate:Thu, 17 Sep 2020 21:20:38 
Committer: Borislav Petkov 
CommitterDate: Sat, 19 Sep 2020 20:46:59 +02:00

KVM: SVM: Don't flush cache if hardware enforces cache coherency across 
encryption domains

In some hardware implementations, coherency between the encrypted and
unencrypted mappings of the same physical page in a VM is enforced. In
such a system, it is not required for software to flush the VM's page
from all CPU caches in the system prior to changing the value of the
C-bit for the page.

So check that bit before flushing the cache.

Signed-off-by: Krish Sadhukhan 
Signed-off-by: Borislav Petkov 
Acked-by: Paolo Bonzini 
Link: https://lkml.kernel.org/r/20200917212038.5090-4-krish.sadhuk...@oracle.com
---
 arch/x86/kvm/svm/sev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 402dc42..567792f 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -384,7 +384,8 @@ static void sev_clflush_pages(struct page *pages[], 
unsigned long npages)
uint8_t *page_virtual;
unsigned long i;
 
-   if (npages == 0 || pages == NULL)
+   if (this_cpu_has(X86_FEATURE_SME_COHERENT) || npages == 0 ||
+   pages == NULL)
return;
 
for (i = 0; i < npages; i++) {

Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver

[Andrew Lunn]

On Sat, Sep 19, 2020 at 07:43:28PM +0300, Oded Gabbay wrote:
> It's probably heresy, but why do I need to integrate into the RDMA subsystem ?

Hi Oded

I don't know the RDMA subsystem at all. So i will give a more generic
answer. Are you reinventing things which a subsystem core already has?
The subsystem core will be well tested, since lots of devices use
it. Because of this, subsystem cores generally have a lower bug count
per line of code than driver code. Using core code means drivers are
smaller, and smaller code has less bugs by definition.

We as maintainers have to assume you are going to abandon the driver
at some point, while the hardware still exists, and leave the
community to maintain it. So a smaller driver, which makes heavy use
of the core is much easier to maintain.

By making use of core code, you also get freebies. Somebody adds new
functionality to the core, your driver automatically gets it.

Look at this from the opposite perspective. Say every driver
implemented their own TCP/IP stack? Or DMA engine? SPI infrastructure?
How big a nightmare would it be to maintain?

In your case, some parts of you hardware looks a bit like RDMA? So you
ideally want to use the core code from the RDMA subsystem. Maybe you
just need some of the lower layers? Maybe you need to refactor some of
the RDMA core to make it a library you can pick and choice the bits
useful to you? What you really want to avoid is re-implementing stuff
in your driver which is already in the core.

  Andrew

Re: [PATCH] checkpatch: extend author Signed-off-by check for split From: header

[Lukas Bulwahn]

On Sat, 19 Sep 2020, Joe Perches wrote:

> On Sat, 2020-09-19 at 20:12 +0200, Lukas Bulwahn wrote:
> > 
> > On Sat, 19 Sep 2020, Joe Perches wrote:
> > 
> > > On Sat, 2020-09-19 at 13:42 +0530, Dwaipayan Ray wrote:
> > > > Checkpatch did not handle cases where the author From: header
> > > > was split into two lines. The author string went empty and
> > > > checkpatch generated a false NO_AUTHOR_SIGN_OFF warning.
> > > 
> > > It's good to provide an example where the current code
> > > doesn't work.
> > > 
> > 
> > Joe, as this is a linux-kernel-mentees patch, we discussed that before 
> > reaching out to you; you can find Dwaipayan's own evaluation here:
> > 
> > https://lore.kernel.org/linux-kernel-mentees/cabjpp5botg0qlfsarjtb2vaz_hjf229oaqihhkg4syd35i_...@mail.gmail.com/
> > 
> > Dwaipayan, Joe's comment is still valid; it would be good to describe
> > the reasons why patches might have split lines (as far as see, long 
> > encodings for non-ascii names).
> > 
> > I will run my own evaluation of checkpatch.pl before and after patch 
> > application on Monday and then check if I can confirm Dwaipayan's results.
> > 
> > > It likely would be better to do this by searching forward for
> > > any extension lines after a "^From:' rather than searching
> > > backwards as there can be any number of extension lines.
> > > 
> > 
> > Just to sure what you are talking about...
> > 
> > You mean just to access the next line through the lines array, rather 
> > than using prevheader and trying to decode that one line twice.
> > 
> > I agree the logic is a bit redundant and complicated at the moment.
> > 
> > Once prevheader is non-empty, it already clear that author is '' and 
> > prevheader decodes with that match, because that is the only way to
> > make prevheader non-empty in the first place; at least as far I see it 
> > right now.
> 
> Yeah, something like this (completely untested):
> ---
>  scripts/checkpatch.pl | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 3e474072aa90..2c710d05b184 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2679,9 +2679,13 @@ sub process {
>   }
>  
>  # Check the patch for a From:
> - if (decode("MIME-Header", $line) =~ /^From:\s*(.*)/) {
> + if ($line =~ /^From:\s*(.*)/i) {
>   $author = $1;
> - $author = encode("utf8", $author) if ($line =~ 
> /=\?utf-8\?/i);
> + my $curline = $linenr;
> + while (defined($rawlines[$curline] && 
> $rawlines[$curline++] =~ /^ \s*(.*)/) {
> + $author .= $1;
> + }
> + $author = encode("utf8", $author) if ($author =~ 
> /=\?utf-8\?/i);
>   $author =~ s/"//g;
>   $author = reformat_email($author);
>   }
>

Yeah, I get how you would like to see that being implemented. I will work 
with Dwaipayan to get that properly implemented, properly described and 
tested.

But let us keep the fun of that task to Dwaipayan... that is what a 
mentorship is all about :)

Lukas

Re: [PATCH] checkpatch: extend author Signed-off-by check for split From: header

[Joe Perches]

On Sat, 2020-09-19 at 20:12 +0200, Lukas Bulwahn wrote:
> 
> On Sat, 19 Sep 2020, Joe Perches wrote:
> 
> > On Sat, 2020-09-19 at 13:42 +0530, Dwaipayan Ray wrote:
> > > Checkpatch did not handle cases where the author From: header
> > > was split into two lines. The author string went empty and
> > > checkpatch generated a false NO_AUTHOR_SIGN_OFF warning.
> > 
> > It's good to provide an example where the current code
> > doesn't work.
> > 
> 
> Joe, as this is a linux-kernel-mentees patch, we discussed that before 
> reaching out to you; you can find Dwaipayan's own evaluation here:
> 
> https://lore.kernel.org/linux-kernel-mentees/cabjpp5botg0qlfsarjtb2vaz_hjf229oaqihhkg4syd35i_...@mail.gmail.com/
> 
> Dwaipayan, Joe's comment is still valid; it would be good to describe
> the reasons why patches might have split lines (as far as see, long 
> encodings for non-ascii names).
> 
> I will run my own evaluation of checkpatch.pl before and after patch 
> application on Monday and then check if I can confirm Dwaipayan's results.
> 
> > It likely would be better to do this by searching forward for
> > any extension lines after a "^From:' rather than searching
> > backwards as there can be any number of extension lines.
> > 
> 
> Just to sure what you are talking about...
> 
> You mean just to access the next line through the lines array, rather 
> than using prevheader and trying to decode that one line twice.
> 
> I agree the logic is a bit redundant and complicated at the moment.
> 
> Once prevheader is non-empty, it already clear that author is '' and 
> prevheader decodes with that match, because that is the only way to
> make prevheader non-empty in the first place; at least as far I see it 
> right now.

Yeah, something like this (completely untested):
---
 scripts/checkpatch.pl | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3e474072aa90..2c710d05b184 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2679,9 +2679,13 @@ sub process {
}
 
 # Check the patch for a From:
-   if (decode("MIME-Header", $line) =~ /^From:\s*(.*)/) {
+   if ($line =~ /^From:\s*(.*)/i) {
$author = $1;
-   $author = encode("utf8", $author) if ($line =~ 
/=\?utf-8\?/i);
+   my $curline = $linenr;
+   while (defined($rawlines[$curline] && 
$rawlines[$curline++] =~ /^ \s*(.*)/) {
+   $author .= $1;
+   }
+   $author = encode("utf8", $author) if ($author =~ 
/=\?utf-8\?/i);
$author =~ s/"//g;
$author = reformat_email($author);
}

Re: [PATCH 1/4] x86: add __X32_COND_SYSCALL() macro

[hpa]

On September 19, 2020 9:23:22 AM PDT, Andy Lutomirski  wrote:
>On Fri, Sep 18, 2020 at 10:35 PM Christoph Hellwig 
>wrote:
>>
>> On Fri, Sep 18, 2020 at 03:24:36PM +0200, Arnd Bergmann wrote:
>> > sys_move_pages() is an optional syscall, and once we remove
>> > the compat version of it in favor of the native one with an
>> > in_compat_syscall() check, the x32 syscall table refers to
>> > a __x32_sys_move_pages symbol that may not exist when the
>> > syscall is disabled.
>> >
>> > Change the COND_SYSCALL() definition on x86 to also include
>> > the redirection for x32.
>> >
>> > Signed-off-by: Arnd Bergmann 
>>
>> Adding the x86 maintainers and Brian Gerst.  Brian proposed another
>> problem to the mess that most of the compat syscall handlers used by
>> x32 here:
>>
>>https://lkml.org/lkml/2020/6/16/664
>>
>> hpa didn't particularly like it, but with your and my pending series
>> we'll soon use more native than compat syscalls for x32, so something
>> will need to change..
>
>I'm fine with either solution.

My main objection was naming. x64 is a widely used synonym for x86-64, and so 
that is confusing.

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

Re: [PATCH AUTOSEL 5.4 265/330] drm/amd/powerplay: try to do a graceful shutdown on SW CTF

[Sasha Levin]

On Fri, Sep 18, 2020 at 09:57:37AM -0400, Alex Deucher wrote:

On Fri, Sep 18, 2020 at 3:17 AM Quan, Evan  wrote:


[AMD Official Use Only - Internal Distribution Only]

Hi @Sasha Levin @Deucher, Alexander,

The following changes need to be applied also.
Otherwise, you may see unexpected shutdown on stress gpu loading on Vega10.

drm/amd/pm: avoid false alarm due to confusing softwareshutdowntemp setting
drm/amd/pm: correct the thermal alert temperature limit settings
drm/amd/pm: correct Vega20 swctf limit setting
drm/amd/pm: correct Vega12 swctf limit setting
drm/amd/pm: correct Vega10 swctf limit setting


I would suggest we just drop this patch for kernels prior to 5.8
(where it was introduced).


Will do, thanks.

--
Thanks,
Sasha

Re: [PATCH 2/2] Add a new sysctl knob: unprivileged_userfaultfd_user_mode_only

[Nick Kralevich]

On Fri, Sep 4, 2020 at 5:36 PM Lokesh Gidra  wrote:
>
> On Thu, Sep 3, 2020 at 8:34 PM Andrea Arcangeli  wrote:
> >
> > 1) why don't you enforce the block of kernel initiated faults with
> >seccomp-bpf instead of adding a sysctl value 2? Is the sysctl just
> >an optimization to remove a few instructions per syscall in the bpf
> >execution of Android unprivileged apps? You should block a lot of
> >other syscalls by default to all unprivileged processes, including
> >vmsplice.
> >
> >In other words if it's just for Android, why can't Android solve it
> >with only patch 1/2 by tweaking the seccomp filter?
>
> I would let Nick (nnk@) and Jeff (jeffv@) respond to this.
>
> The previous responses from both of them on this email thread
> (https://lore.kernel.org/lkml/CABXk95A-E4NYqA5qVrPgDF18YW-z4_udzLwa0cdo2OfqVsy=s...@mail.gmail.com/
> and 
> https://lore.kernel.org/lkml/CAFJ0LnGfrzvVgtyZQ+UqRM6F3M7iXOhTkUBTc+9sV+=rrfn...@mail.gmail.com/)
> suggest that the performance overhead of seccomp-bpf is too much. Kees
> also objected to it
> (https://lore.kernel.org/lkml/202005200921.2BD5A0ADD@keescook/)
>
> I'm not familiar with how seccomp-bpf works. All that I can add here
> is that userfaultfd syscall is usually not invoked in a performance
> critical code path. So, if the performance overhead of seccomp-bpf (if
> enabled) is observed on all syscalls originating from a process, then
> I'd say patch 2/2 is essential. Otherwise, it should be ok to let
> seccomp perform the same functionality instead.
>

There are two primary reasons why seccomp isn't viable here.

1) Seccomp was never designed for whole-of-system protections, and is
impractical to deploy for anything other than "leaf" processes.
2) Attempts to enable seccomp on Android have run into performance
problems, even for trivial seccomp filters.

Let's go into each one.

Issue #1: Seccomp was never designed for whole-of-system protections,
and is impractical to deploy for anything other than "leaf" processes.

Andrea suggests deploying a seccomp filter purely focused on Android
unprivileged[1] (third party installed) apps. However, the intention
is for this security control to be used system-wide[2]. Only processes
which have a need for kernel initiated faults should be allowed to use
them; all other processes should be denied by default. And when I say
"all' processes, I mean "all" processes, even those which run with
UID=0. Andrea's proposal is akin to a denylist, where many modern
distributions (such as Android) use allowlists.

The seemingly obvious solution is to apply a global seccomp filter in
init (PID=1), but it falls down in practice. Seccomp is an incredibly
useful tool, but it wasn't designed to be applied system-wide. Seccomp
is fundamentally hierarchical in nature. A seccomp filter, once
applied, cannot be subsequently relaxed or removed in child processes.
While this restriction is great for leaf processes, it causes problems
for OS designers - a parent process must maintain an unused capability
if any process in the parent's process tree uses that capability. This
makes applying a userfaultfd seccomp filter in init impossible, since
we expect a few of init's children (but not init itself or most of
init's children) to use userfaultfd kernel faults. We end up back to a
wack-a-mole (denylist) problem of trying to modify each individual
process to block userfaultfd kernel faults, defeating the goals of
system-wide protection, and introducing significant complexity into
the system design.

Seccomp should be used in the context where it provides the most value
-- process leaf nodes. But trying to apply seccomp as a system-wide
control just isn't viable.

Lokesh's sysctl proposal doesn't have these problems. When the sysctl
is set to 2 by the OS distributor, all processes which don't have
CAP_SYS_PTRACE are denied kernel generated faults, making the system
safe-by-default. Only processes which are on the OS distributor's
CAP_SYS_PTRACE allowlist (see Android's allowlist at [3]) can generate
these faults, and capabilities can be managed without regards to
process hierarchy. This keeps the system minimally privileged and
safe.

Seccomp isn't a viable solution here.

Issue #2: Attempts to enable seccomp on Android globally have run into
performance problems, even for trivial seccomp filters.

Android has tried a few times to enable seccomp globally, but even
excluding the above-mentioned hierarchical process problems, we've
seen performance regressions across the board. Imposing a seccomp
filter merely for userfaultfd imposes a tax on every syscall, even if
the process never makes use of userfaultfd. Lokesh's sysctl proposal
avoids this tax and places the check where it's most effective, with
the rest of the userfaultfd functionality.

See also the threads that Lokesh mentioned above:

* 
https://lore.kernel.org/lkml/CABXk95A-E4NYqA5qVrPgDF18YW-z4_udzLwa0cdo2OfqVsy=s...@mail.gmail.com/
* 

Re: [PATCH] checkpatch: extend author Signed-off-by check for split From: header

[Lukas Bulwahn]

On Sat, 19 Sep 2020, Joe Perches wrote:

> On Sat, 2020-09-19 at 13:42 +0530, Dwaipayan Ray wrote:
> > Checkpatch did not handle cases where the author From: header
> > was split into two lines. The author string went empty and
> > checkpatch generated a false NO_AUTHOR_SIGN_OFF warning.
> 
> It's good to provide an example where the current code
> doesn't work.
>

Joe, as this is a linux-kernel-mentees patch, we discussed that before 
reaching out to you; you can find Dwaipayan's own evaluation here:

https://lore.kernel.org/linux-kernel-mentees/cabjpp5botg0qlfsarjtb2vaz_hjf229oaqihhkg4syd35i_...@mail.gmail.com/

Dwaipayan, Joe's comment is still valid; it would be good to describe
the reasons why patches might have split lines (as far as see, long 
encodings for non-ascii names).

I will run my own evaluation of checkpatch.pl before and after patch 
application on Monday and then check if I can confirm Dwaipayan's results.

> It likely would be better to do this by searching forward for
> any extension lines after a "^From:' rather than searching
> backwards as there can be any number of extension lines.
>

Just to sure what you are talking about...

You mean just to access the next line through the lines array, rather 
than using prevheader and trying to decode that one line twice.

I agree the logic is a bit redundant and complicated at the moment.

Once prevheader is non-empty, it already clear that author is '' and 
prevheader decodes with that match, because that is the only way to
make prevheader non-empty in the first place; at least as far I see it 
right now.


Lukas
 
> > Support split From: headers in AUTHOR_SIGN_OFF check by adding
> > an additional clause to resolve author identity in such cases.
> > 
> > Signed-off-by: Dwaipayan Ray 
> > ---
> >  scripts/checkpatch.pl | 28 
> >  1 file changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 504d2e431c60..86975baead22 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -1210,6 +1210,16 @@ sub reformat_email {
> > return format_email($email_name, $email_address);
> >  }
> >  
> > +sub format_author_email {
> > +   my ($email, $from) = @_;
> > +
> > +   $email = encode("utf8", $email) if ($from =~ /=\?utf-8\?/i);
> > +   $email =~ s/"//g;
> > +   $email = reformat_email($email);
> > +
> > +   return $email;
> > +}
> > +
> >  sub same_email_addresses {
> > my ($email1, $email2) = @_;
> >  
> > @@ -2347,6 +2357,7 @@ sub process {
> > my $signoff = 0;
> > my $author = '';
> > my $authorsignoff = 0;
> > +   my $prevheader = '';
> > my $is_patch = 0;
> > my $is_binding_patch = -1;
> > my $in_header_lines = $file ? 0 : 1;
> > @@ -2658,12 +2669,21 @@ sub process {
> > }
> > }
> >  
> > +# Check the patch for a split From:
> > +   if($prevheader ne '') {
> > +   if ($author eq '' && decode("MIME-Header", $prevheader) 
> > =~ /^From:\s*(.*)/) {
> > +   my $email = $1.$line;
> > +   $author = format_author_email($email, 
> > $prevheader);
> > +   }
> > +   $prevheader = '';
> > +   }
> > +
> >  # Check the patch for a From:
> > if (decode("MIME-Header", $line) =~ /^From:\s*(.*)/) {
> > -   $author = $1;
> > -   $author = encode("utf8", $author) if ($line =~ 
> > /=\?utf-8\?/i);
> > -   $author =~ s/"//g;
> > -   $author = reformat_email($author);
> > +   $author = format_author_email($1, $line);
> > +   if($author eq '') {
> > +   $prevheader = $line;
> > +   }
> > }
> >  
> >  # Check the patch for a signoff:
> 
> 

Re: [PATCH AUTOSEL 5.4 101/330] powerpc/powernv/ioda: Fix ref count for devices with their own PE

[Sasha Levin]

On Fri, Sep 18, 2020 at 08:35:06AM +0200, Frederic Barrat wrote:



Le 18/09/2020 à 03:57, Sasha Levin a écrit :

From: Frederic Barrat 

[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]



This patch is not desirable for stable, for 5.4 and 4.19 (it was 
already flagged by autosel back in April. Not sure why it's showing 
again now)


Hey Fred,

This was a bit of a "lie", it wasn't a run of AUTOSEL, but rather an
audit of patches that went into distro/vendor trees but not into the
upstream stable trees.

I can see that this patch was pulled into Ubuntu's 5.4 tree, is it not
needed in the upstream stable tree?

--
Thanks,
Sasha

Re: [PATCH v5 1/3] leds: pwm: Remove platform_data support

[Marek Behun]

Besides Pavel's note about the __attribute__((nonnull)) position

Reviewed-by: Marek Behún