csky-linux-gcc: error: unrecognized command line option '-mbacktrace'; did you mean

2021-03-18 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   8b12a62a4e3ed4ae99c715034f557eb391d6b196
commit: 000591f1ca3312d9a29e15a9e3fe5c4171f75586 csky: Enable LOCKDEP_SUPPORT
date:   12 months ago
config: csky-randconfig-r012-20210318 (attached as .config)
compiler: csky-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
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=000591f1ca3312d9a29e15a9e3fe5c4171f75586
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 000591f1ca3312d9a29e15a9e3fe5c4171f75586
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=csky 

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

All errors (new ones prefixed by >>):

>> csky-linux-gcc: error: unrecognized command line option '-mbacktrace'; did 
>> you mean '-fbacktrace'?
--
>> csky-linux-gcc: error: unrecognized command line option '-mbacktrace'; did 
>> you mean '-fbacktrace'?
   /usr/bin/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x20): multiple definition 
of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first defined here
   collect2: error: ld returned 1 exit status
   make[2]: *** [scripts/Makefile.host:116: scripts/dtc/dtc] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [Makefile:1260: scripts_dtc] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:180: sub-make] Error 2
   make: Target 'prepare' not remade because of errors.

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for FRAME_POINTER
   Depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || 
ARCH_WANT_FRAME_POINTERS
   Selected by
   - LOCKDEP && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT && !MIPS && !PPC && !ARM 
&& !S390 && !MICROBLAZE && !ARC && !X86

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


Re: [PATCHv3 6/6] MAINTAINERS: update Senozhatsky email address

2021-03-18 Thread Sergey Senozhatsky
On (21/03/19 14:53), Sergey Senozhatsky wrote:
> 
> I don't check my @gmail.com addresses often enough these days.
> 

Please ignore this one. It's a different story and does not belong
to this series.

-ss


[PATCH] power: supply: charger-manager: Fix a typo

2021-03-18 Thread Bhaskar Chowdhury
s/systme/system/

Signed-off-by: Bhaskar Chowdhury 
---
 drivers/power/supply/charger-manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/supply/charger-manager.c 
b/drivers/power/supply/charger-manager.c
index 4dea8ecd70bc..45da870aecca 100644
--- a/drivers/power/supply/charger-manager.c
+++ b/drivers/power/supply/charger-manager.c
@@ -1604,7 +1604,7 @@ static int charger_manager_probe(struct platform_device 
*pdev)
mutex_unlock(_list_mtx);

/*
-* Charger-manager is capable of waking up the systme from sleep
+* Charger-manager is capable of waking up the system from sleep
 * when event is happened through cm_notify_event()
 */
device_init_wakeup(>dev, true);
--
2.26.2



[PATCHv3 6/6] MAINTAINERS: update Senozhatsky email address

2021-03-18 Thread Sergey Senozhatsky
I don't check my @gmail.com addresses often enough these days.

Signed-off-by: Sergey Senozhatsky 
---
 MAINTAINERS | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b2baeb5e4a68..01b000cd5774 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14433,7 +14433,7 @@ F:  kernel/sched/psi.c
 
 PRINTK
 M: Petr Mladek 
-M: Sergey Senozhatsky 
+M: Sergey Senozhatsky 
 R: Steven Rostedt 
 R: John Ogness 
 S: Maintained
@@ -19293,7 +19293,7 @@ F:  drivers/net/vrf.c
 VSPRINTF
 M: Petr Mladek 
 M: Steven Rostedt 
-M: Sergey Senozhatsky 
+M: Sergey Senozhatsky 
 R: Andy Shevchenko 
 R: Rasmus Villemoes 
 S: Maintained
@@ -19944,7 +19944,7 @@ F:  drivers/staging/media/zoran/
 ZRAM COMPRESSED RAM BLOCK DEVICE DRVIER
 M: Minchan Kim 
 M: Nitin Gupta 
-R: Sergey Senozhatsky 
+R: Sergey Senozhatsky 
 L: linux-kernel@vger.kernel.org
 S: Maintained
 F: Documentation/admin-guide/blockdev/zram.rst
@@ -19958,7 +19958,7 @@ F:  drivers/tty/serial/zs.*
 ZSMALLOC COMPRESSED SLAB MEMORY ALLOCATOR
 M: Minchan Kim 
 M: Nitin Gupta 
-R: Sergey Senozhatsky 
+R: Sergey Senozhatsky 
 L: linux...@kvack.org
 S: Maintained
 F: Documentation/vm/zsmalloc.rst
-- 
2.31.0.rc2.261.g7f71774620-goog



[PATCHv3 5/6] media: uvcvideo: add UVC 1.5 ROI control

2021-03-18 Thread Sergey Senozhatsky
This patch implements UVC 1.5 Region of Interest (ROI) control.

Note that, UVC 1.5 defines CT_DIGITAL_WINDOW_CONTROL controls
and mentions that ROI rectangle coordinates "must be within
the current Digital Window as specified by the CT_WINDOW control."
(4.2.2.1.20 Digital Region of Interest (ROI) Control).

It's is not entirely clear if we need to implement WINDOW_CONTROL.
ROI is naturally limited by GET_MIN and GET_MAX rectangles.

Another thing to note is that ROI support is implemented as
V4L2 selection target: selection rectangle represents ROI
rectangle and selection flags represent ROI auto-controls.
User-space is required to set valid values for both rectangle
and auto-controls every time SET_CUR is issued.

Usage example:

   struct v4l2_selection roi = {0, };

   roi.target = V4L2_SEL_TGT_ROI;
   roi.r.left = 0;
   roi.r.top  = 0;
   roi.r.width= 42;
   roi.r.height   = 42;
   roi.flags  = V4L2_SEL_FLAG_ROI_AUTO_EXPOSURE;

   ioctl(fd, VIDIOC_S_SELECTION, );

Signed-off-by: Sergey Senozhatsky 
---
 drivers/media/usb/uvc/uvc_v4l2.c | 147 ++-
 include/uapi/linux/usb/video.h   |   1 +
 2 files changed, 145 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index 252136cc885c..d0fe6c33fab6 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -1139,14 +1139,66 @@ static int uvc_ioctl_querymenu(struct file *file, void 
*fh,
return uvc_query_v4l2_menu(chain, qm);
 }
 
-static int uvc_ioctl_g_selection(struct file *file, void *fh,
-struct v4l2_selection *sel)
+/* UVC 1.5 ROI rectangle is half the size of v4l2_rect */
+struct uvc_roi_rect {
+   __u16   top;
+   __u16   left;
+   __u16   bottom;
+   __u16   right;
+   __u16   auto_controls;
+} __packed;
+
+static int uvc_ioctl_g_roi_target(struct file *file, void *fh,
+ struct v4l2_selection *sel)
 {
struct uvc_fh *handle = fh;
struct uvc_streaming *stream = handle->stream;
+   struct uvc_roi_rect *roi;
+   u8 query;
+   int ret;
 
-   if (sel->type != stream->type)
+   switch (sel->target) {
+   case V4L2_SEL_TGT_ROI:
+   query = UVC_GET_CUR;
+   break;
+   case V4L2_SEL_TGT_ROI_DEFAULT:
+   query = UVC_GET_DEF;
+   break;
+   case V4L2_SEL_TGT_ROI_BOUNDS_MIN:
+   query = UVC_GET_MAX;
+   break;
+   case V4L2_SEL_TGT_ROI_BOUNDS_MAX:
+   query = UVC_GET_MAX;
+   break;
+   default:
return -EINVAL;
+   }
+
+   roi = kzalloc(sizeof(struct uvc_roi_rect), GFP_KERNEL);
+   if (!roi)
+   return -ENOMEM;
+
+   ret = uvc_query_ctrl(stream->dev, query, 1, stream->dev->intfnum,
+UVC_CT_REGION_OF_INTEREST_CONTROL, roi,
+sizeof(struct uvc_roi_rect));
+   if (!ret) {
+   /* ROI left, top, right, bottom are global coordinates. */
+   sel->r.left = roi->left;
+   sel->r.top  = roi->top;
+   sel->r.width= roi->right - roi->left + 1;
+   sel->r.height   = roi->bottom - roi->top + 1;
+   sel->flags  = roi->auto_controls;
+   }
+
+   kfree(roi);
+   return ret;
+}
+
+static int uvc_ioctl_g_sel_target(struct file *file, void *fh,
+ struct v4l2_selection *sel)
+{
+   struct uvc_fh *handle = fh;
+   struct uvc_streaming *stream = handle->stream;
 
switch (sel->target) {
case V4L2_SEL_TGT_CROP_DEFAULT:
@@ -1173,6 +1225,94 @@ static int uvc_ioctl_g_selection(struct file *file, void 
*fh,
return 0;
 }
 
+static int uvc_ioctl_g_selection(struct file *file, void *fh,
+struct v4l2_selection *sel)
+{
+   struct uvc_fh *handle = fh;
+   struct uvc_streaming *stream = handle->stream;
+
+   if (sel->type != stream->type)
+   return -EINVAL;
+
+   switch (sel->target) {
+   case V4L2_SEL_TGT_CROP_DEFAULT:
+   case V4L2_SEL_TGT_CROP_BOUNDS:
+   case V4L2_SEL_TGT_COMPOSE_DEFAULT:
+   case V4L2_SEL_TGT_COMPOSE_BOUNDS:
+   return uvc_ioctl_g_sel_target(file, fh, sel);
+   case V4L2_SEL_TGT_ROI:
+   case V4L2_SEL_TGT_ROI_DEFAULT:
+   case V4L2_SEL_TGT_ROI_BOUNDS_MIN:
+   case V4L2_SEL_TGT_ROI_BOUNDS_MAX:
+   return uvc_ioctl_g_roi_target(file, fh, sel);
+   }
+
+   return -EINVAL;
+}
+
+static bool validate_roi_bounds(struct uvc_streaming *stream,
+   struct v4l2_selection *sel)
+{
+   if (sel->r.left > USHRT_MAX ||
+   sel->r.top > USHRT_MAX ||
+   (sel->r.width + 

[PATCHv3 2/6] media: v4l UAPI: document ROI selection targets

2021-03-18 Thread Sergey Senozhatsky
Document V4L2 selection targets that will be used to ROI
implementation.

Signed-off-by: Sergey Senozhatsky 
---
 .../media/v4l/selection-api-configuration.rst | 22 +++
 .../media/v4l/selection-api-examples.rst  | 28 +++
 .../media/v4l/v4l2-selection-targets.rst  | 24 
 3 files changed, 74 insertions(+)

diff --git 
a/Documentation/userspace-api/media/v4l/selection-api-configuration.rst 
b/Documentation/userspace-api/media/v4l/selection-api-configuration.rst
index fee49bf1a1c0..b5fdd765e2db 100644
--- a/Documentation/userspace-api/media/v4l/selection-api-configuration.rst
+++ b/Documentation/userspace-api/media/v4l/selection-api-configuration.rst
@@ -135,3 +135,25 @@ and the height of rectangles obtained using 
``V4L2_SEL_TGT_CROP`` and
 ``V4L2_SEL_TGT_COMPOSE`` targets. If these are not equal then the
 scaling is applied. The application can compute the scaling ratios using
 these values.
+
+Configuration of Region of Interest (ROI)
+=
+
+The range of auto-controls values and of coordinates of the top left
+corner, width and height of areas that can be ROI is given by the
+``V4L2_SEL_TGT_ROI_BOUNDS_MIN`` and ``V4L2_SEL_TGT_ROI_BOUNDS_MAX``
+targets. It is recommended for the driver developers to put the top/left
+corner at position ``(0,0)``.
+
+The top left corner, width and height of the Region of Interest area
+and auto-controls currently being employed by the device are given by
+the ``V4L2_SEL_TGT_ROI`` target. It uses the same coordinate system
+as ``V4L2_SEL_TGT_ROI_BOUNDS_MIN`` and ``V4L2_SEL_TGT_ROI_BOUNDS_MAX``.
+
+In order to change active ROI top left, width and height coordinates
+and ROI auto-controls use ``V4L2_SEL_TGT_ROI`` target.
+
+Each capture device has a default ROI rectangle and auto-controls
+value given by the ``V4L2_SEL_TGT_ROI_DEFAULT`` target. Drivers shall
+set the ROI rectangle to the default when the driver is first loaded,
+but not later.
diff --git a/Documentation/userspace-api/media/v4l/selection-api-examples.rst 
b/Documentation/userspace-api/media/v4l/selection-api-examples.rst
index 5f8e8a1f59d7..ad2664888700 100644
--- a/Documentation/userspace-api/media/v4l/selection-api-examples.rst
+++ b/Documentation/userspace-api/media/v4l/selection-api-examples.rst
@@ -82,3 +82,31 @@ Example: Querying for scaling factors
/* computing scaling factors */
hscale = (double)compose.r.width / crop.r.width;
vscale = (double)compose.r.height / crop.r.height;
+
+Setting Region Of Interest area to half of the default value
+
+Example: Simple ROI
+===
+
+.. code-block:: c
+
+   struct v4l2_selection roi = {
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+   .target = V4L2_SEL_TGT_ROI_DEFAULT,
+   };
+   struct v4l2_rect r;
+
+   ret = ioctl(fd, VIDIOC_G_SELECTION, );
+   if (ret)
+   exit(-1);
+   /* setting smaller ROI rectangle */
+   r.width = roi.r.width / 2;
+   r.height = roi.r.height / 2;
+   r.left = roi.r.width / 4;
+   r.top = roi.r.height / 4;
+   roi.r = r;
+   roi.target = V4L2_SEL_TGT_ROI;
+   roi.flags = V4L2_SEL_FLAG_ROI_AUTO_EXPOSURE;
+   ret = ioctl(fd, VIDIOC_S_SELECTION, );
+   if (ret)
+   exit(-1);
diff --git a/Documentation/userspace-api/media/v4l/v4l2-selection-targets.rst 
b/Documentation/userspace-api/media/v4l/v4l2-selection-targets.rst
index b46bae984f35..d1dc9c50eb05 100644
--- a/Documentation/userspace-api/media/v4l/v4l2-selection-targets.rst
+++ b/Documentation/userspace-api/media/v4l/v4l2-selection-targets.rst
@@ -75,6 +75,30 @@ of the two interfaces they are used.
modified by hardware.
   - Yes
   - No
+* - ``V4L2_SEL_TGT_ROI``
+  - 0x0200
+  - Current Region of Interest rectangle and auto-controls value.
+  - Yes
+  - No
+* - ``V4L2_SEL_TGT_ROI_DEFAULT``
+  - 0x0201
+  - Suggested Region of Interest rectangle and auto-controls value.
+  - Yes
+  - No
+* - ``V4L2_SEL_TGT_ROI_BOUNDS_MIN``
+  - 0x0202
+  - Minimum bounds of the Region of Interest rectangle and minimum
+   auto-controls value. All valid ROI rectangles and auto-controls
+   should be within minimum-maximum range.
+  - Yes
+  - No
+* - ``V4L2_SEL_TGT_ROI_BOUNDS_MAX``
+  - 0x0203
+  - Maximum bounds of the Region of Interest rectangle and maximum
+   auto-controls value. All valid ROI rectangles and auto-controls
+   should be within minimum-maximum range.
+  - Yes
+  - No
 
 .. raw:: latex
 
-- 
2.31.0.rc2.261.g7f71774620-goog



[PATCHv3 4/6] media: v4l UAPI: document ROI auto-controls flags

2021-03-18 Thread Sergey Senozhatsky
Document ROI auto controls.

Signed-off-by: Sergey Senozhatsky 
---
 .../media/v4l/v4l2-selection-flags.rst| 40 +++
 1 file changed, 40 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/v4l2-selection-flags.rst 
b/Documentation/userspace-api/media/v4l/v4l2-selection-flags.rst
index 1cb1531c1e52..536d29a6c4a5 100644
--- a/Documentation/userspace-api/media/v4l/v4l2-selection-flags.rst
+++ b/Documentation/userspace-api/media/v4l/v4l2-selection-flags.rst
@@ -48,6 +48,46 @@ Selection flags
inside the subdevice to all further processing steps.
   - No
   - Yes
+* - ``V4L2_SEL_FLAG_ROI_AUTO_EXPOSURE``
+  - (1 << 0)
+  - Auto Exposure.
+  - Yes
+  - No
+* - ``V4L2_SEL_FLAG_ROI_AUTO_IRIS``
+  - (1 << 1)
+  - Auto Iris.
+  - Yes
+  - No
+* - ``V4L2_SEL_FLAG_ROI_AUTO_WHITE_BALANCE``
+  - (1 << 2)
+  - Auto White Balance.
+  - Yes
+  - No
+* - ``V4L2_SEL_FLAG_ROI_AUTO_FOCUS``
+  - (1 << 3)
+  - Auto Focus.
+  - Yes
+  - No
+* - ``V4L2_SEL_FLAG_ROI_AUTO_FACE_DETECT``
+  - (1 << 4)
+  - Auto Face Detect.
+  - Yes
+  - No
+* - ``V4L2_SEL_FLAG_ROI_AUTO_DETECT_AND_TRACK``
+  - (1 << 5)
+  - Auto Detect and Track.
+  - Yes
+  - No
+* - ``V4L2_SEL_FLAG_ROI_AUTO_IMAGE_STABILIXATION``
+  - (1 << 6)
+  - Image Stabilization.
+  - Yes
+  - No
+* - ``V4L2_SEL_FLAG_ROI_AUTO_HIGHER_QUALITY``
+  - (1 << 7)
+  - Higher Quality.
+  - Yes
+  - No
 
 .. raw:: latex
 
-- 
2.31.0.rc2.261.g7f71774620-goog



[PATCHv3 3/6] media: v4l UAPI: add ROI auto-controls flags

2021-03-18 Thread Sergey Senozhatsky
UVC 1.5 defines the following Region Of Interest auto controls:

D0: Auto Exposure
D1: Auto Iris
D2: Auto White Balance
D3: Auto Focus
D4: Auto Face Detect
D5: Auto Detect and Track
D6: Image Stabilization
D7: Higher Quality
D8 – D15: Reserved, set to zero

Signed-off-by: Sergey Senozhatsky 
---
 include/uapi/linux/v4l2-common.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/uapi/linux/v4l2-common.h b/include/uapi/linux/v4l2-common.h
index 3651ebb8cb23..34f1c262d6aa 100644
--- a/include/uapi/linux/v4l2-common.h
+++ b/include/uapi/linux/v4l2-common.h
@@ -92,6 +92,16 @@
 #define V4L2_SEL_FLAG_LE   (1 << 1)
 #define V4L2_SEL_FLAG_KEEP_CONFIG  (1 << 2)
 
+/* ROI auto-controls flags */
+#define V4L2_SEL_FLAG_ROI_AUTO_EXPOSURE(1 << 0)
+#define V4L2_SEL_FLAG_ROI_AUTO_IRIS(1 << 1)
+#define V4L2_SEL_FLAG_ROI_AUTO_WHITE_BALANCE   (1 << 2)
+#define V4L2_SEL_FLAG_ROI_AUTO_FOCUS   (1 << 3)
+#define V4L2_SEL_FLAG_ROI_AUTO_FACE_DETECT (1 << 4)
+#define V4L2_SEL_FLAG_ROI_AUTO_DETECT_AND_TRACK(1 << 5)
+#define V4L2_SEL_FLAG_ROI_AUTO_IMAGE_STABILIXATION (1 << 6)
+#define V4L2_SEL_FLAG_ROI_AUTO_HIGHER_QUALITY  (1 << 7)
+
 struct v4l2_edid {
__u32 pad;
__u32 start_block;
-- 
2.31.0.rc2.261.g7f71774620-goog



[PATCHv3 0/6] media: uvcvideo: implement UVC 1.5 ROI

2021-03-18 Thread Sergey Senozhatsky
Hello,

This patch set implements UVC 1.5 ROI using v4l2_selection API.

V3:
- reimplemented ROI. We dont' use split controls anymore.
- Ricardo's feedback

Sergey Senozhatsky (6):
  media: v4l UAPI: add ROI selection targets
  media: v4l UAPI: document ROI selection targets
  media: v4l UAPI: add ROI auto-controls flags
  media: v4l UAPI: document ROI auto-controls flags
  media: uvcvideo: add UVC 1.5 ROI control
  MAINTAINERS: update Senozhatsky email address

 .../media/v4l/selection-api-configuration.rst |  22 +++
 .../media/v4l/selection-api-examples.rst  |  28 
 .../media/v4l/v4l2-selection-flags.rst|  40 +
 .../media/v4l/v4l2-selection-targets.rst  |  24 +++
 MAINTAINERS   |   8 +-
 drivers/media/usb/uvc/uvc_v4l2.c  | 147 +-
 include/uapi/linux/usb/video.h|   1 +
 include/uapi/linux/v4l2-common.h  |  18 +++
 8 files changed, 281 insertions(+), 7 deletions(-)

-- 
2.31.0.rc2.261.g7f71774620-goog



[PATCHv3 1/6] media: v4l UAPI: add ROI selection targets

2021-03-18 Thread Sergey Senozhatsky
UVC 1.5 requires Region Of Interest control to implement
GET_CUR, GET_DEF, GET_MIN and GET_MAX requests. This patch
adds new V4L2 selection API targets that will implement
those ROI requests.

Signed-off-by: Sergey Senozhatsky 
---
 include/uapi/linux/v4l2-common.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/uapi/linux/v4l2-common.h b/include/uapi/linux/v4l2-common.h
index 7d21c1634b4d..3651ebb8cb23 100644
--- a/include/uapi/linux/v4l2-common.h
+++ b/include/uapi/linux/v4l2-common.h
@@ -78,6 +78,14 @@
 #define V4L2_SEL_TGT_COMPOSE_BOUNDS0x0102
 /* Current composing area plus all padding pixels */
 #define V4L2_SEL_TGT_COMPOSE_PADDED0x0103
+/* Current Region of Interest area */
+#define V4L2_SEL_TGT_ROI   0x0200
+/* Default Region of Interest area */
+#define V4L2_SEL_TGT_ROI_DEFAULT   0x0201
+/* Region of Interest minimum values */
+#define V4L2_SEL_TGT_ROI_BOUNDS_MIN0x0202
+/* Region of Interest maximum values */
+#define V4L2_SEL_TGT_ROI_BOUNDS_MAX0x0203
 
 /* Selection flags */
 #define V4L2_SEL_FLAG_GE   (1 << 0)
-- 
2.31.0.rc2.261.g7f71774620-goog



Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver

2021-03-18 Thread Viresh Kumar
On 16-03-21, 18:35, Jie Deng wrote:
> +++ b/drivers/i2c/busses/i2c-virtio.c
> +static int virtio_i2c_send_reqs(struct virtqueue *vq,
> + struct virtio_i2c_req *reqs,
> + struct i2c_msg *msgs, int nr)
> +{
> + struct scatterlist *sgs[3], out_hdr, msg_buf, in_hdr;
> + int i, outcnt, incnt, err = 0;
> +
> + for (i = 0; i < nr; i++) {
> + if (!msgs[i].len)
> + break;
> +
> + /*
> +  * Only 7-bit mode supported for this moment. For the address 
> format,
> +  * Please check the Virtio I2C Specification.
> +  */
> + reqs[i].out_hdr.addr = cpu_to_le16(msgs[i].addr << 1);
> +
> + if (i != nr - 1)
> + reqs[i].out_hdr.flags = 
> cpu_to_le32(VIRTIO_I2C_FLAGS_FAIL_NEXT);
> +
> + outcnt = incnt = 0;
> + sg_init_one(_hdr, [i].out_hdr, 
> sizeof(reqs[i].out_hdr));
> + sgs[outcnt++] = _hdr;
> +
> + reqs[i].buf = i2c_get_dma_safe_msg_buf([i], 1);

You allocate a buffer here, lets see if they are freeing properly or not (I
remember that I gave same feedback earlier as well, but anyway).

> + if (!reqs[i].buf)
> + break;
> +
> + sg_init_one(_buf, reqs[i].buf, msgs[i].len);
> +
> + if (msgs[i].flags & I2C_M_RD)
> + sgs[outcnt + incnt++] = _buf;
> + else
> + sgs[outcnt++] = _buf;
> +
> + sg_init_one(_hdr, [i].in_hdr, sizeof(reqs[i].in_hdr));
> + sgs[outcnt + incnt++] = _hdr;
> +
> + err = virtqueue_add_sgs(vq, sgs, outcnt, incnt, [i], 
> GFP_KERNEL);
> + if (err < 0) {
> + pr_err("failed to add msg[%d] to virtqueue.\n", i);
> + i2c_put_dma_safe_msg_buf(reqs[i].buf, [i], false);

On failure here, you freed the buffers for request "i" but not others..

> + break;
> + }
> + }
> +
> + return i;
> +}
> +
> +static int virtio_i2c_complete_reqs(struct virtqueue *vq,
> + struct virtio_i2c_req *reqs,
> + struct i2c_msg *msgs, int nr)
> +{
> + struct virtio_i2c_req *req;
> + unsigned int len;
> + int i, j;
> +
> + for (i = 0; i < nr; i++) {
> + req = virtqueue_get_buf(vq, );
> + if (!(req && req == [i])) {
> + pr_err("msg[%d]: addr=0x%x is out of order.\n", i, 
> msgs[i].addr);
> + break;

Since you break here, what will happen to the buffer ? I thought
virtqueue_get_buf() will return a req only once and then you can't access it ?

> + }
> +
> + if (req->in_hdr.status != VIRTIO_I2C_MSG_OK) {
> + pr_err("msg[%d]: addr=0x%x backend error.\n", i, 
> msgs[i].addr);
> + break;
> + }
> +
> + i2c_put_dma_safe_msg_buf(req->buf, [i], true);
> + }
> +
> + /*
> +  * Detach all the used buffers from the vq and
> +  * Release unused DMA safe buffer if any.
> +  */
> + for (j = i; j < nr; j++) {
> + req = virtqueue_get_buf(vq, );
> + if (req)
> + i2c_put_dma_safe_msg_buf(req->buf, [j], false);

This will come in play only if something failed in the earlier loop ? Or my
understanding incorrect ? Also this should be merged with the above for loop
itself, it is just doing part of it.

> + }
> +
> + return i;
> +}
> +
> +static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, 
> int num)
> +{
> + struct virtio_i2c *vi = i2c_get_adapdata(adap);
> + struct virtqueue *vq = vi->vq;
> + struct virtio_i2c_req *reqs;
> + unsigned long time_left;
> + int ret, nr;
> +
> + reqs = kcalloc(num, sizeof(*reqs), GFP_KERNEL);
> + if (!reqs)
> + return -ENOMEM;
> +
> + mutex_lock(>lock);
> +
> + ret = virtio_i2c_send_reqs(vq, reqs, msgs, num);
> + if (ret == 0)
> + goto err_unlock_free;
> +
> + nr = ret;
> + reinit_completion(>completion);
> + virtqueue_kick(vq);
> +
> + time_left = wait_for_completion_timeout(>completion, adap->timeout);
> + if (!time_left) {

On error here, we will surely not free the buffers, isn't it ?

> + dev_err(>dev, "virtio i2c backend timeout.\n");
> + ret = -ETIMEDOUT;
> + goto err_unlock_free;
> + }
> +
> + ret = virtio_i2c_complete_reqs(vq, reqs, msgs, nr);
> +
> +err_unlock_free:
> + mutex_unlock(>lock);
> + kfree(reqs);
> + return ret;
> +}
-- 
viresh


Re: [PATCH] fs/cifs/: fix misspellings using codespell tool

2021-03-18 Thread Steve French
merged into cifs-2.6.git for-next

On Thu, Mar 18, 2021 at 7:50 PM  wrote:
>
> From: Liu xuzhi 
>
> A typo is found out by codespell tool in 251th lines of cifs_swn.c:
>
> $ codespell ./fs/cifs/
> ./cifs_swn.c:251: funciton  ==> function
>
> Fix a typo found by codespell.
>
> Signed-off-by: Liu xuzhi 
> ---
>  fs/cifs/cifs_swn.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/cifs_swn.c b/fs/cifs/cifs_swn.c
> index f2d730fffccb..d829b8bf833e 100644
> --- a/fs/cifs/cifs_swn.c
> +++ b/fs/cifs/cifs_swn.c
> @@ -248,7 +248,7 @@ static int cifs_swn_send_unregister_message(struct 
> cifs_swn_reg *swnreg)
>
>  /*
>   * Try to find a matching registration for the tcon's server name and share 
> name.
> - * Calls to this funciton must be protected by cifs_swnreg_idr_mutex.
> + * Calls to this function must be protected by cifs_swnreg_idr_mutex.
>   * TODO Try to avoid memory allocations
>   */
>  static struct cifs_swn_reg *cifs_find_swn_reg(struct cifs_tcon *tcon)
> --
> 2.25.1
>


-- 
Thanks,

Steve


Re: [PATCH 1/1] leds: lgm: Improve Kconfig help

2021-03-18 Thread Rahul Tanwar
Hi Pavel,

On 19/3/2021 4:37 am, Pavel Machek wrote:
> Hi!
> 
> 
>  > > > help
>  > > > - Parallel to serial conversion, which is also called SSO
>  > > > controller,
>  > > > - can drive external shift register for LED outputs.
>  > > > - This enables LED support for Serial Shift Output controller(SSO).
>  > > > + This option enables support for LEDs connected to GPIO lines on
>  > > > + Lightning Mountain(LGM) SoC. These LEDs are driven by a Serial
>  > > > + Shift Output(SSO) controller. The driver supports hardware
>  > >
>  > > What is Lightning Mountain? The codename is not widely known. Where
>  > > can we find that hardware? Notebooks? Phones? Only some development
>  > > boards?
>  > >
>  >
>  > Lightning Mountain is generically a network processor with a primary
>  > targeted application as Gateway SoC. It has already been added as a
>  > valid Intel Atom processor variant in
>  > arch/x86/include/asm/intel-family.h as below:
> 
> Yep, but Kconfig users are not going to read header files.
> 
> If the SoC is not shipping in any products, state so.
> 


Got your point. Will update the help text.


>  > > > *
>  > > > - * Copyright (c) 2020 Intel Corporation.
>  > > > + * Copyright (c) 2021 MaxLinear, Inc.
>  > > > */
>  > > >
>  > >
>  > > I don't think you can do that, and I don't think you should be doing
>  > > it in the same patch.
>  >
>  > Well noted. Will revert it back now and update later in a separate
>  > patch. Thanks.
> 
> Don't. You can't update copyright like that.
>

Well noted.

Regards,
Rahul


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





[PATCH 1/2] mm: memcontrol: don't allocate cgroup swap arrays when memcg is disabled

2021-03-18 Thread Johannes Weiner
Since commit 2d1c498072de ("mm: memcontrol: make swap tracking an
integral part of memory control"), the cgroup swap arrays are used to
track memory ownership at the time of swap readahead and swapoff, even
if swap space *accounting* has been turned off by the user via
swapaccount=0 (which sets cgroup_memory_noswap).

However, the patch was overzealous: by simply dropping the
cgroup_memory_noswap conditionals in the swapon, swapoff and uncharge
path, it caused the cgroup arrays being allocated even when the memory
controller as a whole is disabled. This is a waste of that memory.

Restore mem_cgroup_disabled() checks, implied previously by
cgroup_memory_noswap, in the swapon, swapoff, and swap_entry_free
callbacks.

Fixes: 2d1c498072de ("mm: memcontrol: make swap tracking an integral part of 
memory control")
Reported-by: Hugh Dickins 
Signed-off-by: Johannes Weiner 
---
 mm/memcontrol.c  | 3 +++
 mm/swap_cgroup.c | 6 ++
 2 files changed, 9 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 668d1d7c2645..49bdcf603af1 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -7101,6 +7101,9 @@ void mem_cgroup_uncharge_swap(swp_entry_t entry, unsigned 
int nr_pages)
struct mem_cgroup *memcg;
unsigned short id;
 
+   if (mem_cgroup_disabled())
+   return;
+
id = swap_cgroup_record(entry, 0, nr_pages);
rcu_read_lock();
memcg = mem_cgroup_from_id(id);
diff --git a/mm/swap_cgroup.c b/mm/swap_cgroup.c
index 7f34343c075a..08c3246f9269 100644
--- a/mm/swap_cgroup.c
+++ b/mm/swap_cgroup.c
@@ -171,6 +171,9 @@ int swap_cgroup_swapon(int type, unsigned long max_pages)
unsigned long length;
struct swap_cgroup_ctrl *ctrl;
 
+   if (mem_cgroup_disabled())
+   return 0;
+
length = DIV_ROUND_UP(max_pages, SC_PER_PAGE);
array_size = length * sizeof(void *);
 
@@ -206,6 +209,9 @@ void swap_cgroup_swapoff(int type)
unsigned long i, length;
struct swap_cgroup_ctrl *ctrl;
 
+   if (mem_cgroup_disabled())
+   return;
+
mutex_lock(_cgroup_mutex);
ctrl = _cgroup_ctrl[type];
map = ctrl->map;
-- 
2.30.1



[PATCH 2/2] mm: memcontrol: deprecate swapaccounting=0 mode

2021-03-18 Thread Johannes Weiner
The swapaccounting= commandline option already does very little
today. To close a trivial containment failure case, the swap ownership
tracking part of the swap controller has recently become mandatory
(see commit 2d1c498072de ("mm: memcontrol: make swap tracking an
integral part of memory control") for details), which makes up the
majority of the work during swapout, swapin, and the swap slot map.

The only thing left under this flag is the page_counter operations and
the visibility of the swap control files in the first place, which are
rather meager savings. There also aren't many scenarios, if any, where
controlling the memory of a cgroup while allowing it unlimited access
to a global swap space is a workable resource isolation stragegy.

On the other hand, there have been several bugs and confusion around
the many possible swap controller states (cgroup1 vs cgroup2 behavior,
memory accounting without swap accounting, memcg runtime disabled).

This puts the maintenance overhead of retaining the toggle above its
practical benefits. Deprecate it.

Suggested-by: Shakeel Butt 
Signed-off-by: Johannes Weiner 
---
 .../admin-guide/kernel-parameters.txt |  5 --
 include/linux/memcontrol.h|  4 --
 mm/memcontrol.c   | 48 ++-
 3 files changed, 15 insertions(+), 42 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 942bbef8f128..986d45dd8c37 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5322,11 +5322,6 @@
This parameter controls use of the Protected
Execution Facility on pSeries.
 
-   swapaccount=[0|1]
-   [KNL] Enable accounting of swap in memory resource
-   controller if no parameter or 1 is given or disable
-   it if 0 is given (See 
Documentation/admin-guide/cgroup-v1/memory.rst)
-
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
Format: {  | force | noforce }
 -- Number of I/O TLB slabs
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 4064c9dda534..ef9613538d36 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -874,10 +874,6 @@ struct mem_cgroup *mem_cgroup_get_oom_group(struct 
task_struct *victim,
struct mem_cgroup *oom_domain);
 void mem_cgroup_print_oom_group(struct mem_cgroup *memcg);
 
-#ifdef CONFIG_MEMCG_SWAP
-extern bool cgroup_memory_noswap;
-#endif
-
 void lock_page_memcg(struct page *page);
 void unlock_page_memcg(struct page *page);
 
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 49bdcf603af1..b036c4fb0fa7 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -85,13 +85,6 @@ static bool cgroup_memory_nosocket;
 /* Kernel memory accounting disabled? */
 static bool cgroup_memory_nokmem;
 
-/* Whether the swap controller is active */
-#ifdef CONFIG_MEMCG_SWAP
-bool cgroup_memory_noswap __read_mostly;
-#else
-#define cgroup_memory_noswap   1
-#endif
-
 #ifdef CONFIG_CGROUP_WRITEBACK
 static DECLARE_WAIT_QUEUE_HEAD(memcg_cgwb_frn_waitq);
 #endif
@@ -99,7 +92,11 @@ static DECLARE_WAIT_QUEUE_HEAD(memcg_cgwb_frn_waitq);
 /* Whether legacy memory+swap accounting is active */
 static bool do_memsw_account(void)
 {
-   return !cgroup_subsys_on_dfl(memory_cgrp_subsys) && 
!cgroup_memory_noswap;
+   /* cgroup2 doesn't do mem+swap accounting */
+   if (cgroup_subsys_on_dfl(memory_cgrp_subsys))
+   return false;
+
+   return true;
 }
 
 #define THRESHOLDS_EVENTS_TARGET 128
@@ -7019,7 +7016,7 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t 
entry)
if (!mem_cgroup_is_root(memcg))
page_counter_uncharge(>memory, nr_entries);
 
-   if (!cgroup_memory_noswap && memcg != swap_memcg) {
+   if (memcg != swap_memcg) {
if (!mem_cgroup_is_root(swap_memcg))
page_counter_charge(_memcg->memsw, nr_entries);
page_counter_uncharge(>memsw, nr_entries);
@@ -7073,7 +7070,7 @@ int mem_cgroup_try_charge_swap(struct page *page, 
swp_entry_t entry)
 
memcg = mem_cgroup_id_get_online(memcg);
 
-   if (!cgroup_memory_noswap && !mem_cgroup_is_root(memcg) &&
+   if (!mem_cgroup_is_root(memcg) &&
!page_counter_try_charge(>swap, nr_pages, )) {
memcg_memory_event(memcg, MEMCG_SWAP_MAX);
memcg_memory_event(memcg, MEMCG_SWAP_FAIL);
@@ -7108,7 +7105,7 @@ void mem_cgroup_uncharge_swap(swp_entry_t entry, unsigned 
int nr_pages)
rcu_read_lock();
memcg = mem_cgroup_from_id(id);
if (memcg) {
-   if (!cgroup_memory_noswap && !mem_cgroup_is_root(memcg)) {
+   if (!mem_cgroup_is_root(memcg)) {
if 

[PATCH] MAINTAINERS: update Senozhatsky email address

2021-03-18 Thread Sergey Senozhatsky
I don't check my @gmail.com addresses often enough these days.

Signed-off-by: Sergey Senozhatsky 
---
 MAINTAINERS | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b2baeb5e4a68..01b000cd5774 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14433,7 +14433,7 @@ F:  kernel/sched/psi.c
 
 PRINTK
 M: Petr Mladek 
-M: Sergey Senozhatsky 
+M: Sergey Senozhatsky 
 R: Steven Rostedt 
 R: John Ogness 
 S: Maintained
@@ -19293,7 +19293,7 @@ F:  drivers/net/vrf.c
 VSPRINTF
 M: Petr Mladek 
 M: Steven Rostedt 
-M: Sergey Senozhatsky 
+M: Sergey Senozhatsky 
 R: Andy Shevchenko 
 R: Rasmus Villemoes 
 S: Maintained
@@ -19944,7 +19944,7 @@ F:  drivers/staging/media/zoran/
 ZRAM COMPRESSED RAM BLOCK DEVICE DRVIER
 M: Minchan Kim 
 M: Nitin Gupta 
-R: Sergey Senozhatsky 
+R: Sergey Senozhatsky 
 L: linux-kernel@vger.kernel.org
 S: Maintained
 F: Documentation/admin-guide/blockdev/zram.rst
@@ -19958,7 +19958,7 @@ F:  drivers/tty/serial/zs.*
 ZSMALLOC COMPRESSED SLAB MEMORY ALLOCATOR
 M: Minchan Kim 
 M: Nitin Gupta 
-R: Sergey Senozhatsky 
+R: Sergey Senozhatsky 
 L: linux...@kvack.org
 S: Maintained
 F: Documentation/vm/zsmalloc.rst
-- 
2.31.0.rc2.261.g7f71774620-goog



[PATCH] drm/amd/display: Set AMDGPU_DM_DEFAULT_MIN_BACKLIGHT to 0

2021-03-18 Thread Evan Benn
AMDGPU_DM_DEFAULT_MIN_BACKLIGHT was set to the value of 12
to ensure no display backlight will flicker at low user brightness
settings. However this value is quite bright, so for devices that do not
implement the ACPI ATIF
ATIF_FUNCTION_QUERY_BRIGHTNESS_TRANSFER_CHARACTERISTICS
functionality the user cannot set the brightness to a low level even if
the display would support such a low PWM.

This ATIF feature is not implemented on for example AMD grunt chromebooks.

Signed-off-by: Evan Benn 

---
I could not find a justification for the reason for the value. It has
caused some noticable regression for users: 
https://bugzilla.kernel.org/show_bug.cgi?id=203439

Maybe this can be either user controlled or userspace configured, but
preventing users from turning their backlight dim seems wrong.

Also reviewed here: 
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2748377

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 573cf17262da..0129bd69b94e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3151,7 +3151,7 @@ static int amdgpu_dm_mode_config_init(struct 
amdgpu_device *adev)
return 0;
 }
 
-#define AMDGPU_DM_DEFAULT_MIN_BACKLIGHT 12
+#define AMDGPU_DM_DEFAULT_MIN_BACKLIGHT 0
 #define AMDGPU_DM_DEFAULT_MAX_BACKLIGHT 255
 #define AUX_BL_DEFAULT_TRANSITION_TIME_MS 50
 
-- 
2.31.0.291.g576ba9dcdaf-goog



Re: remove the legacy ide driver

2021-03-18 Thread Christoph Hellwig
On Fri, Mar 19, 2021 at 12:43:48PM +1100, Finn Thain wrote:
> A few months ago I wrote another patch to move some more platforms away 
> from macide but it has not been tested yet. That is not to say you should 
> wait. However, my patch does have some changes that are missing from your 
> patch series, relating to ide platform devices in arch/m68k/mac/config.c. 
> I hope to be able to test this patch before the 5.13 merge window closes.

Normally we do not remove drivers for hardware that is still used.  So
at leat for macide my plan was not to take it away unless the users 
are sufficiently happy.  Or in other words:  I think waiting it the
right choice, but hopefully we can make that wait as short as possible.


Re: [PATCH] x86/sgx: Avoid returning NULL in __sgx_alloc_epc_page()

2021-03-18 Thread Jarkko Sakkinen
On Fri, Mar 19, 2021 at 05:06:02PM +1300, Kai Huang wrote:
> Below kernel bug happened when running simple SGX application when EPC
> is under pressure.  The root cause is with commit 5b8719504e3a
> ("x86/sgx: Add a basic NUMA allocation scheme to sgx_alloc_epc_page()"),
> __sgx_alloc_epc_page() returns NULL when there's no free EPC page can be
> allocated, while old behavior was it always returned ERR_PTR(-ENOMEM) in
> such case.
> 
> Fix by directly returning the page if __sgx_alloc_epc_page_from_node()
> allocates a valid page in fallback to non-local allocation, and always
> returning ERR_PTR(-ENOMEM) if no EPC page can be allocated.
> 
> [  253.474764] BUG: kernel NULL pointer dereference, address: 0008
> [  253.500101] #PF: supervisor write access in kernel mode
> [  253.525462] #PF: error_code(0x0002) - not-present page
> ...
> [  254.102041] Call Trace:
> [  254.126699]  sgx_ioc_enclave_add_pages+0x241/0x770
> [  254.151305]  sgx_ioctl+0x194/0x4b0
> [  254.174976]  ? handle_mm_fault+0xd0/0x260
> [  254.198470]  ? do_user_addr_fault+0x1ef/0x570
> [  254.221827]  __x64_sys_ioctl+0x91/0xc0
> [  254.244546]  do_syscall_64+0x38/0x90
> [  254.266728]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> [  254.289232] RIP: 0033:0x7fdc4cf4031b
> ...
> [  254.711480] CR2: 0008
> [  254.735494] ---[ end trace 970dce6d4cdf7f64 ]---
> [  254.759915] RIP: 0010:sgx_alloc_epc_page+0x46/0x152
> ...
> 
> Fixes: 5b8719504e3a("x86/sgx: Add a basic NUMA allocation scheme to 
> sgx_alloc_epc_page()")
> Signed-off-by: Kai Huang 


Reviewed-by: Jarkko Sakkinen 

> ---
>  arch/x86/kernel/cpu/sgx/main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
> index fe26e7e91c25..7105e34da530 100644
> --- a/arch/x86/kernel/cpu/sgx/main.c
> +++ b/arch/x86/kernel/cpu/sgx/main.c
> @@ -508,10 +508,10 @@ struct sgx_epc_page *__sgx_alloc_epc_page(void)
>  
>   page = __sgx_alloc_epc_page_from_node(nid);
>   if (page)
> - break;
> + return page;
>   }
>  
> - return page;
> + return ERR_PTR(-ENOMEM);
>  }
>  
>  /**
> -- 
> 2.30.2
> 
> 

/Jarkko


Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver

2021-03-18 Thread Viresh Kumar
On 19-03-21, 13:31, Jie Deng wrote:
> 
> On 2021/3/19 11:54, Viresh Kumar wrote:
> > On 18-03-21, 15:52, Arnd Bergmann wrote:
> > > Allowing multiple virtio-i2c controllers in one system, and multiple i2c
> > > devices attached to each controller is clearly something that has to work.
> > Good.
> > 
> > > I don't actually see a limitation though. Viresh, what is the problem
> > > you see for having multiple controllers?
> > I thought this would be a problem in that case as we are using the global
> > virtio_adapter here.
> > 
> > +   vi->adap = _adapter;
> > +   i2c_set_adapdata(vi->adap, vi);
> > 
> > Multiple calls to probe() will end up updating the same pointer inside adap.
> > 
> > +   vi->adap->dev.parent = >dev;
> > 
> > Same here, overwrite.
> > 
> > +   /* Setup ACPI node for controlled devices which will be probed 
> > through ACPI */
> > +   ACPI_COMPANION_SET(>adap->dev, ACPI_COMPANION(pdev));
> > +   vi->adap->timeout = HZ / 10;
> > 
> > These may be fine, but still not ideal I believe.
> > 
> > +   ret = i2c_add_adapter(vi->adap);
> > i
> > This should be a problem as well, we must be adding this to some sort of 
> > list,
> > doing some RPM stuff, etc ?
> > 
> > Jie, the solution is to allocate memory for adap at runtime in probe and 
> > remove
> > the virtio_adapter structure completely.
> 
> 
> If you want to support that. Then I think we don't need to change the
> following at all.
> 
> > +    .algo = _algorithm,
> > +
> > +    return ret;
> > +
> > +    vi->adap = virtio_adapter;
> This is strange, why are you allocating memory for adapter twice ?
> Once for virtio_adapter and once for vi->adap ? Either fill the fields
> directly for v->adap here and remove virtio_adapter or make vi->adap a
> pointer.

Yes, your previous version was partly okay but you don't need the
virtio_algorithm structure to be allocated. There are only 4 fields you are
updating here, just fill them directly in vi->adap.

(FWIW, I also suggested the same when I said
"Either fill the fields directly for v->adap here and remove virtio_adapter".
)

See how drivers/i2c/busses/i2c-versatile.c and most of the other drivers have
done it.

-- 
viresh


Re: [PATCH] x86/sgx: fix uninitialized 'nid' variable

2021-03-18 Thread Jarkko Sakkinen
On Thu, Mar 18, 2021 at 02:49:33PM -0700, Dave Hansen wrote:
> The NUMA fallback in __sgx_alloc_epc_page() recently grew an
> additional 'nid' variable to prevent extra trips through the
> fallback loop in case where the thread is migrated around.
> 
> But, the new copy is not properly initialized.  Fix it.
> 
> This was found by some fancy clang that 0day runs.  My gcc
> does not detect it.
> 
> Fixes: 5b8719504e3a ("x86/sgx: Add a basic NUMA allocation scheme to 
> sgx_alloc_epc_page()")
> Reported-by: kernel test robot 
> Signed-off-by: Dave Hansen 
> Cc: Jarkko Sakkinen 
> Cc: Borislav Petkov 
> Cc: x...@kernel.org
> Cc: linux-...@vger.kernel.org


Reviewed-by: Jarkko Sakkinen 

> ---
>  arch/x86/kernel/cpu/sgx/main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
> index 2a0031e4a4dc..1b4d8a0e0915 100644
> --- a/arch/x86/kernel/cpu/sgx/main.c
> +++ b/arch/x86/kernel/cpu/sgx/main.c
> @@ -489,7 +489,7 @@ struct sgx_epc_page *__sgx_alloc_epc_page(void)
>  {
>   struct sgx_epc_page *page;
>   int nid_of_current = numa_node_id();
> - int nid;
> + int nid = nid_of_current;
>  
>   if (node_isset(nid_of_current, sgx_numa_mask)) {
>   page = __sgx_alloc_epc_page_from_node(nid_of_current);
> -- 
> 2.19.1
> 
> 

/Jarkko


Re: [PATCH 06/11] i2c: imx-lpi2c: improve i2c driver probe priority

2021-03-18 Thread Wolfram Sang
On Wed, Mar 17, 2021 at 02:53:54PM +0800, Clark Wang wrote:
> From: Gao Pan 
> 
> use subsys_initcall for i2c driver to improve i2c driver probe priority
> 
> Signed-off-by: Gao Pan 

I usually don't take subsys_initcall patches anymore. In most cases, the
client drivers can be fixed instead. If this is not the case for you,
you need to state that explicitly in the commit message.



signature.asc
Description: PGP signature


Re: [PATCH] selftests/sgx: improve error detection and messages

2021-03-18 Thread Jarkko Sakkinen
On Thu, Mar 18, 2021 at 12:43:01PM -0700, Dave Hansen wrote:
> 
> From: Dave Hansen 
> 
> The SGX device file (/dev/sgx_enclave) is unusual in that it requires
> execute permissions.  It has to be both "chmod +x" *and* be on a
> filesystem without 'noexec'.
> 
> In the future, udev and systemd should get updates to set up systems
> automatically.  But, for now, nobody's systems do this automatically,
> and everybody gets error messages like this when running ./test_sgx:
> 
>   0x 0x2000 0x03
>   0x2000 0x1000 0x05
>   0x3000 0x3000 0x03
>   mmap() failed, errno=1.
> 
> That isn't very user friendly, even for forgetful kernel developers.
> 
> Further, the test case is rather haphazard about its use of fprintf()
> versus perror().
> 
> Improve the error messages.  Use perror() where possible.  Lastly,
> do some sanity checks on opening and mmap()ing the device file so
> that we can get a decent error message out to the user.
> 
> Now, if your user doesn't have permission, you'll get the following:
> 
>   $ ls -l /dev/sgx_enclave
>   crw--- 1 root root 10, 126 Mar 18 11:29 /dev/sgx_enclave
>   $ ./test_sgx
>   Unable to open /dev/sgx_enclave: Permission denied
> 
> If you then 'chown dave:dave /dev/sgx_enclave' (or whatever), but
> you leave execute permissions off, you'll get:
> 
>   $ ls -l /dev/sgx_enclave
>   crw--- 1 dave dave 10, 126 Mar 18 11:29 /dev/sgx_enclave
>   $ ./test_sgx
>   no execute permissions on device file
> 
> If you fix that with "chmod ug+x /dev/sgx" but you leave /dev as
> noexec, you'll get this:
> 
>   $ mount | grep "/dev .*noexec"
>   udev on /dev type devtmpfs (rw,nosuid,noexec,...)
>   $ ./test_sgx
>   ERROR: mmap for exec: Operation not permitted
>   mmap() succeeded for PROT_READ, but failed for PROT_EXEC
>   check that user has execute permissions on /dev/sgx_enclave and
>   that /dev does not have noexec set: 'mount | grep "/dev .*noexec"'
> 
> That can be fixed with:
> 
>   mount -o remount,noexec /devESC
> 
> Hopefully, the combination of better error messages and the search
> engines indexing this message will help people fix their systems
> until we do this properly.
> 
> Signed-off-by: Dave Hansen 
> Cc: Jarkko Sakkinen 
> Cc: Shuah Khan 
> Cc: Borislav Petkov 
> Cc: x...@kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-kselft...@vger.kernel.org


Reviewed-by: Jarkko Sakkinen 

> ---
> 
>  b/tools/testing/selftests/sgx/load.c |   66 
> +++
>  b/tools/testing/selftests/sgx/main.c |2 -
>  2 files changed, 53 insertions(+), 15 deletions(-)
> 
> diff -puN tools/testing/selftests/sgx/load.c~sgx-selftest-err-rework 
> tools/testing/selftests/sgx/load.c
> --- a/tools/testing/selftests/sgx/load.c~sgx-selftest-err-rework  
> 2021-03-18 12:18:38.649828215 -0700
> +++ b/tools/testing/selftests/sgx/load.c  2021-03-18 12:40:46.388824904 
> -0700
> @@ -45,19 +45,19 @@ static bool encl_map_bin(const char *pat
>  
>   fd = open(path, O_RDONLY);
>   if (fd == -1)  {
> - perror("open()");
> + perror("enclave executable open()");
>   return false;
>   }
>  
>   ret = stat(path, );
>   if (ret) {
> - perror("stat()");
> + perror("enclave executable stat()");
>   goto err;
>   }
>  
>   bin = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
>   if (bin == MAP_FAILED) {
> - perror("mmap()");
> + perror("enclave executable mmap()");
>   goto err;
>   }
>  
> @@ -90,8 +90,7 @@ static bool encl_ioc_create(struct encl
>   ioc.src = (unsigned long)secs;
>   rc = ioctl(encl->fd, SGX_IOC_ENCLAVE_CREATE, );
>   if (rc) {
> - fprintf(stderr, "SGX_IOC_ENCLAVE_CREATE failed: errno=%d\n",
> - errno);
> + perror("SGX_IOC_ENCLAVE_CREATE failed");
>   munmap((void *)secs->base, encl->encl_size);
>   return false;
>   }
> @@ -116,31 +115,69 @@ static bool encl_ioc_add_pages(struct en
>  
>   rc = ioctl(encl->fd, SGX_IOC_ENCLAVE_ADD_PAGES, );
>   if (rc < 0) {
> - fprintf(stderr, "SGX_IOC_ENCLAVE_ADD_PAGES failed: errno=%d.\n",
> - errno);
> + perror("SGX_IOC_ENCLAVE_ADD_PAGES failed");
>   return false;
>   }
>  
>   return true;
>  }
>  
> +
> +
>  bool encl_load(const char *path, struct encl *encl)
>  {
> + const char device_path[] = "/dev/sgx_enclave";
>   Elf64_Phdr *phdr_tbl;
>   off_t src_offset;
>   Elf64_Ehdr *ehdr;
> + struct stat sb;
> + void *ptr;
>   int i, j;
>   int ret;
> + int fd = -1;
>  
>   memset(encl, 0, sizeof(*encl));
>  
> - ret = open("/dev/sgx_enclave", O_RDWR);
> - if (ret < 0) {
> - fprintf(stderr, "Unable to 

Re: [PATCHv2 3/3] media: uvcvideo: add UVC 1.5 ROI control

2021-03-18 Thread Sergey Senozhatsky
On (21/03/18 22:19), Ricardo Ribalda wrote:
> >
> > May I please ask for more opinions on this?
> 
> Could you try setting the roi in a loop in your device and verify that
> it accepts all the values with no modification. If so we can implement
> the set/get as a quirk for other devices.

Tested on two (very) different devices.

Firmware D:

   CLAP all passed, we are cool

Firmware H:

   CLAP all passed, we are cool


Code sample

---
   in_selection.target = V4L2_SEL_TGT_ROI;
   in_selection.flags  = V4L2_SEL_FLAG_ROI_AUTO_EXPOSURE;

   for (int i = 0; i < 1001; i++) {
   in_selection.r.left = 0 + i;
   in_selection.r.top  = 0 + i;
   in_selection.r.width= 42 + i;
   in_selection.r.height   = 42 + i;

   ret = doioctl(fd, VIDIOC_S_SELECTION, _selection);
   if (ret) {
   fprintf(stderr, "BOOM %d\n", ret);
   exit(1);
   }

   ret = doioctl(fd, VIDIOC_G_SELECTION, _selection);
   if (ret) {
   fprintf(stderr, "BANG %d\n", ret);
   exit(2);
   }

   if (in_selection.r.left != i ||
   in_selection.r.top != i ||
   in_selection.r.width != i + 42 ||
   in_selection.r.height != i + 42) {

   fprintf(stderr, "SNAP %d %d %d %d != %d %d %d %d\n",
   i, i, i + 42, i + 42,
   in_selection.r.left,
   in_selection.r.top,
   in_selection.r.width,
   in_selection.r.height);
   exit(3);
   }
   }

   fprintf(stderr, "CLAP all passed, we are cool\n");
---


RE: [PATCH 02/11] i2c: imx-lpi2c: add runtime pm support

2021-03-18 Thread Clark Wang

> -Original Message-
> From: Aisheng Dong 
> Sent: Friday, March 19, 2021 12:40
> To: Clark Wang ; shawn...@kernel.org;
> s.ha...@pengutronix.de
> Cc: ker...@pengutronix.de; feste...@gmail.com; dl-linux-imx  i...@nxp.com>; sumit.sem...@linaro.org; christian.koe...@amd.com;
> linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Subject: RE: [PATCH 02/11] i2c: imx-lpi2c: add runtime pm support
> 
> > From: Clark Wang 
> > Sent: Wednesday, March 17, 2021 2:54 PM
> > Subject: [PATCH 02/11] i2c: imx-lpi2c: add runtime pm support
> >
> > - Add runtime pm support to dynamicly manage the clock.
> > - Put the suspend to suspend_noirq.
> > - Call .pm_runtime_force_suspend() to force runtime pm suspended
> >   in .suspend_noirq().
> >
> 
> The patch title needs to be improved as the driver already supports rpm.
> And do one thing in one patch.

Thanks. I will split this patch into several and resend.

Best Regards,
Clark Wang
> 
> > Signed-off-by: Fugang Duan 
> > Signed-off-by: Gao Pan 
> > Reviewed-by: Anson Huang 
> 
> Please add your sign-off.
> 
> > ---
> >  drivers/i2c/busses/i2c-imx-lpi2c.c | 50
> > --
> >  1 file changed, 33 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> > b/drivers/i2c/busses/i2c-imx-lpi2c.c
> > index bbf44ac95021..1e920e7ac7c1 100644
> > --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> > +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> > @@ -574,7 +574,8 @@ static int lpi2c_imx_probe(struct platform_device
> > *pdev)
> > if (ret)
> > lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
> >
> > -   ret = devm_request_irq(>dev, irq, lpi2c_imx_isr, 0,
> > +   ret = devm_request_irq(>dev, irq, lpi2c_imx_isr,
> > +  IRQF_NO_SUSPEND,
> 
> This belongs to a separate patch
> 
> >pdev->name, lpi2c_imx);
> > if (ret) {
> > dev_err(>dev, "can't claim irq %d\n", irq); @@ -
> 584,35
> > +585,32 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
> > i2c_set_adapdata(_imx->adapter, lpi2c_imx);
> > platform_set_drvdata(pdev, lpi2c_imx);
> >
> > -   ret = clk_prepare_enable(lpi2c_imx->clk);
> > -   if (ret) {
> > -   dev_err(>dev, "clk enable failed %d\n", ret);
> > -   return ret;
> > -   }
> > -
> > pm_runtime_set_autosuspend_delay(>dev,
> I2C_PM_TIMEOUT);
> > pm_runtime_use_autosuspend(>dev);
> > -   pm_runtime_get_noresume(>dev);
> > -   pm_runtime_set_active(>dev);
> > pm_runtime_enable(>dev);
> >
> > +   ret = pm_runtime_get_sync(>dev);
> > +   if (ret < 0) {
> > +   pm_runtime_put_noidle(>dev);
> > +   dev_err(>dev, "failed to enable clock\n");
> > +   return ret;
> > +   }
> 
> Can't current clk control via rpm work well?
> Please describe why need change.
> 
> > +
> > temp = readl(lpi2c_imx->base + LPI2C_PARAM);
> > lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
> > lpi2c_imx->rxfifosize = 1 << ((temp >> 8) & 0x0f);
> >
> > +   pm_runtime_put(>dev);
> > +
> > ret = i2c_add_adapter(_imx->adapter);
> > if (ret)
> > goto rpm_disable;
> >
> > -   pm_runtime_mark_last_busy(>dev);
> > -   pm_runtime_put_autosuspend(>dev);
> > -
> > dev_info(_imx->adapter.dev, "LPI2C adapter registered\n");
> >
> > return 0;
> >
> >  rpm_disable:
> > -   pm_runtime_put(>dev);
> > pm_runtime_disable(>dev);
> > pm_runtime_dont_use_autosuspend(>dev);
> >
> > @@ -636,7 +634,7 @@ static int __maybe_unused
> > lpi2c_runtime_suspend(struct device *dev)
> > struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
> >
> > clk_disable_unprepare(lpi2c_imx->clk);
> > -   pinctrl_pm_select_sleep_state(dev);
> > +   pinctrl_pm_select_idle_state(dev);
> 
> This belongs to a separate patch
> 
> >
> > return 0;
> >  }
> > @@ -649,16 +647,34 @@ static int __maybe_unused
> > lpi2c_runtime_resume(struct device *dev)
> > pinctrl_pm_select_default_state(dev);
> > ret = clk_prepare_enable(lpi2c_imx->clk);
> > if (ret) {
> > -   dev_err(dev, "failed to enable I2C clock, ret=%d\n", ret);
> > +   dev_err(dev, "can't enable I2C clock, ret=%d\n", ret);
> 
> Probably unnecessary change
> 
> > return ret;
> > }
> >
> > +   return ret;
> > +}
> > +
> > +static int lpi2c_suspend_noirq(struct device *dev) {
> > +   int ret;
> > +
> > +   ret = pm_runtime_force_suspend(dev);
> > +   if (ret)
> > +   return ret;
> > +
> > +   pinctrl_pm_select_sleep_state(dev);
> > +
> > return 0;
> >  }
> >
> > +static int lpi2c_resume_noirq(struct device *dev) {
> > +   return pm_runtime_force_resume(dev); }
> > +
> >  static const struct dev_pm_ops lpi2c_pm_ops = {
> > -   SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> > - pm_runtime_force_resume)
> > +   SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(lpi2c_suspend_noirq,
> > +

Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver

2021-03-18 Thread Jie Deng



On 2021/3/19 11:54, Viresh Kumar wrote:

On 18-03-21, 15:52, Arnd Bergmann wrote:

Allowing multiple virtio-i2c controllers in one system, and multiple i2c
devices attached to each controller is clearly something that has to work.

Good.


I don't actually see a limitation though. Viresh, what is the problem
you see for having multiple controllers?

I thought this would be a problem in that case as we are using the global
virtio_adapter here.

+   vi->adap = _adapter;
+   i2c_set_adapdata(vi->adap, vi);

Multiple calls to probe() will end up updating the same pointer inside adap.

+   vi->adap->dev.parent = >dev;

Same here, overwrite.

+   /* Setup ACPI node for controlled devices which will be probed through 
ACPI */
+   ACPI_COMPANION_SET(>adap->dev, ACPI_COMPANION(pdev));
+   vi->adap->timeout = HZ / 10;

These may be fine, but still not ideal I believe.

+   ret = i2c_add_adapter(vi->adap);
i
This should be a problem as well, we must be adding this to some sort of list,
doing some RPM stuff, etc ?

Jie, the solution is to allocate memory for adap at runtime in probe and remove
the virtio_adapter structure completely.



If you want to support that. Then I think we don't need to change the 
following at all.



+    .algo = _algorithm,
+
+    return ret;
+
+    vi->adap = virtio_adapter;

This is strange, why are you allocating memory for adapter twice ?
Once for virtio_adapter and once for vi->adap ? Either fill the fields
directly for v->adap here and remove virtio_adapter or make vi->adap a
pointer.




[PATCH] io_uring: Try to merge io requests only for regular files

2021-03-18 Thread Dmitry Monakhov
Otherwise we may endup blocking on pipe or socket.

Fixes: 6d5d5ac ("io_uring: extend async work merge")
Testcase: 
https://github.com/dmonakhov/liburing/commit/16d171b6ef9d68e6db66650a83d98c5c721d01f6
Signed-off-by: Dmitry Monakhov 
---
 fs/io_uring.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 478df7e..848657c 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -2183,6 +2183,9 @@ static int __io_submit_sqe(struct io_ring_ctx *ctx, 
struct io_kiocb *req,
 static struct async_list *io_async_list_from_req(struct io_ring_ctx *ctx,
 struct io_kiocb *req)
 {
+   if (!(req->flags & REQ_F_ISREG))
+   return NULL;
+
switch (req->submit.opcode) {
case IORING_OP_READV:
case IORING_OP_READ_FIXED:
-- 
2.7.4



RE: [PATCH 11/11] i2c: imx-lpi2c: add edma mode support

2021-03-18 Thread Aisheng Dong
> From: Clark Wang 
> Sent: Wednesday, March 17, 2021 2:54 PM
> 
> Add eDMA receive and send mode support.
> Support to read and write data larger than 256 bytes in one frame.
> 
> Signed-off-by: Clark Wang 
> Reviewed-by: Li Jun 
> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 291 -

Pease update dt-binding first

>  1 file changed, 289 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 1e26672d47bf..6d920bf0dbd4 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -8,6 +8,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -31,6 +33,7 @@
>  #define LPI2C_MCR0x10/* i2c contrl register */
>  #define LPI2C_MSR0x14/* i2c status register */
>  #define LPI2C_MIER   0x18/* i2c interrupt enable */
> +#define LPI2C_MDER   0x1C/* i2c DMA enable */
>  #define LPI2C_MCFGR0 0x20/* i2c master configuration */
>  #define LPI2C_MCFGR1 0x24/* i2c master configuration */
>  #define LPI2C_MCFGR2 0x28/* i2c master configuration */
> @@ -72,11 +75,15 @@
>  #define MCFGR1_AUTOSTOP  BIT(8)
>  #define MCFGR1_IGNACKBIT(9)
>  #define MRDR_RXEMPTY BIT(14)
> +#define MDER_TDDEBIT(0)
> +#define MDER_RDDEBIT(1)
> 
>  #define I2C_CLK_RATIO24 / 59
>  #define CHUNK_DATA   256
> 
>  #define I2C_PM_TIMEOUT   1000 /* ms */
> +#define I2C_DMA_THRESHOLD16 /* bytes */
> +#define I2C_USE_PIO  (-150)

Can you clarify a bit why need using this strange value?

> 
>  enum lpi2c_imx_mode {
>   STANDARD,   /* <=100Kbps */
> @@ -95,6 +102,7 @@ enum lpi2c_imx_pincfg {
> 
>  struct lpi2c_imx_struct {
>   struct i2c_adapter  adapter;
> + resource_size_t phy_addr;
>   int irq;
>   struct clk  *clk_per;
>   struct clk  *clk_ipg;
> @@ -114,6 +122,17 @@ struct lpi2c_imx_struct {
>   struct pinctrl *pinctrl;
>   struct pinctrl_state *pinctrl_pins_default;
>   struct pinctrl_state *pinctrl_pins_gpio;
> +
> + boolcan_use_dma;
> + boolusing_dma;
> + boolxferred;
> + struct i2c_msg  *msg;
> + dma_addr_t  dma_addr;
> + struct dma_chan *dma_tx;
> + struct dma_chan *dma_rx;
> + enum dma_data_direction dma_direction;
> + u8  *dma_buf;
> + unsigned intdma_len;
>  };
> 
>  static void lpi2c_imx_intctrl(struct lpi2c_imx_struct *lpi2c_imx, @@ -289,6
> +308,9 @@ static int lpi2c_imx_master_enable(struct lpi2c_imx_struct
> *lpi2c_imx)
>   if (ret)
>   goto rpm_put;
> 
> + if (lpi2c_imx->can_use_dma)
> + writel(MDER_TDDE | MDER_RDDE, lpi2c_imx->base + LPI2C_MDER);
> +
>   temp = readl(lpi2c_imx->base + LPI2C_MCR);
>   temp |= MCR_MEN;
>   writel(temp, lpi2c_imx->base + LPI2C_MCR); @@ -462,6 +484,154 @@
> static void lpi2c_imx_read(struct lpi2c_imx_struct *lpi2c_imx,
>   lpi2c_imx_intctrl(lpi2c_imx, MIER_RDIE | MIER_NDIE);  }
> 
> +static void lpi2c_dma_unmap(struct lpi2c_imx_struct *lpi2c_imx) {
> + struct dma_chan *chan = lpi2c_imx->dma_direction ==
> DMA_FROM_DEVICE
> + ? lpi2c_imx->dma_rx : lpi2c_imx->dma_tx;
> +
> + dma_unmap_single(chan->device->dev, lpi2c_imx->dma_addr,
> +  lpi2c_imx->dma_len, lpi2c_imx->dma_direction);
> +
> + lpi2c_imx->dma_direction = DMA_NONE;
> +}
> +
> +static void lpi2c_cleanup_dma(struct lpi2c_imx_struct *lpi2c_imx) {
> + if (lpi2c_imx->dma_direction == DMA_NONE)
> + return;
> + else if (lpi2c_imx->dma_direction == DMA_FROM_DEVICE)
> + dmaengine_terminate_all(lpi2c_imx->dma_rx);
> + else if (lpi2c_imx->dma_direction == DMA_TO_DEVICE)
> + dmaengine_terminate_all(lpi2c_imx->dma_tx);
> +
> + lpi2c_dma_unmap(lpi2c_imx);
> +}
> +
> +static void lpi2c_dma_callback(void *data) {
> + struct lpi2c_imx_struct *lpi2c_imx = (struct lpi2c_imx_struct *)data;
> +
> + lpi2c_dma_unmap(lpi2c_imx);
> + writel(GEN_STOP << 8, lpi2c_imx->base + LPI2C_MTDR);
> + lpi2c_imx->xferred = true;
> +
> + complete(_imx->complete);
> +}
> +
> +static int lpi2c_dma_submit(struct lpi2c_imx_struct *lpi2c_imx,
> +struct i2c_msg *msg)
> +{
> + bool read = msg->flags & I2C_M_RD;
> + enum dma_data_direction dir = read ? DMA_FROM_DEVICE :
> DMA_TO_DEVICE;
> + struct dma_chan *chan = read ? lpi2c_imx->dma_rx : lpi2c_imx->dma_tx;
> + struct dma_async_tx_descriptor *txdesc;
> + dma_cookie_t cookie;
> +
> + lpi2c_imx->dma_len = read ? msg->len - 1 : msg->len;
> + lpi2c_imx->msg = msg;
> + lpi2c_imx->dma_direction = dir;
> +
> + if (IS_ERR(chan))
> + return PTR_ERR(chan);
> +
> + 

[PATCH] w1: slaves: Typo fixes

2021-03-18 Thread Bhaskar Chowdhury
s/mesured/measured/  ...twice

Signed-off-by: Bhaskar Chowdhury 
---
 drivers/w1/slaves/w1_therm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index 976eea28f268..d3b4ceb07622 100644
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1/slaves/w1_therm.c
@@ -63,8 +63,8 @@ static u16 bulk_read_device_counter; /* =0 as per C standard 
*/
 #define EEPROM_CMD_READ "restore"  /* cmd for read eeprom sysfs */
 #define BULK_TRIGGER_CMD"trigger"  /* cmd to trigger a bulk read */

-#define MIN_TEMP   -55 /* min temperature that can be mesured */
-#define MAX_TEMP   125 /* max temperature that can be mesured */
+#define MIN_TEMP   -55 /* min temperature that can be measured */
+#define MAX_TEMP   125 /* max temperature that can be measured */

 /* Allowed values for sysfs conv_time attribute */
 #define CONV_TIME_DEFAULT 0
--
2.26.2



Re: [PATCH v2 0/2] AM64: Add support for GPIO

2021-03-18 Thread Aswath Govindraju
Hi Nishanth,

On 09/03/21 9:28 pm, Nishanth Menon wrote:
> On 21:20-20210309, Aswath Govindraju wrote:
>> Hi Nishanth,
>>
>> On 09/03/21 8:13 pm, Nishanth Menon wrote:
>>> On 16:59-20210304, Aswath Govindraju wrote:
 The following series of patches adds support for gpio on AM642 evm/sk.

 Changes since v1:
 - Added DT for gpio subsystem present in MCU domain
 - reserved the mcu gpio for firmware usage

 This series of patches depend on,
 https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439039
 https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439153


 Aswath Govindraju (2):
   arm64: dts: ti: k3-am64: Add GPIO DT nodes
   arm64: dts: ti: k3-am642: reserve gpio in mcu domain for firmware
 usage

  arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 45 
  arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi  | 27 ++
  arch/arm64/boot/dts/ti/k3-am642-evm.dts  |  5 +++
  arch/arm64/boot/dts/ti/k3-am642-sk.dts   |  5 +++
  4 files changed, 82 insertions(+)

 -- 
 2.17.1

>>>
>>>
>>> Based on your offline comment:
>>> -
>>>
>>> On going through the bootlogs before posting for I found the following
>>> errors,
>>>
>>> [1.091117] davinci_gpio 601000.gpio: IRQ index 2 not found
>>> [1.101522] davinci_gpio 601000.gpio: error -ENXIO: IRQ not populated
>>>
>>> Some issues in allocating interrupts in case of main_gpio1. I
>>> accumulated the gpio with interrupt numbers. I'll try to debug the
>>> reason behind it and update you with its status. (bootlogs of ti-sdk,
>>> also have this error).
>>>
>>> -
>>>
>>> I am going to drop this off my queue, please update if the fixup is some
>>> system configuration error or repost with fix.
>>>
>>
>> This is expected to be a fixup in the system configuration and not a bug
>> in the patch series. So, can you please have these patches in your queue
>> ? I'll soon post the test results indicating the functioning of GPIOs.
> 
> 
> Thanks for clarifying. I will wait till the test results are posted.
> Thanks in advance for digging into this and detailed testing.
> 

I've posted a respin(v3) of this series after rebasing on top of
ti-k3-dts-next branch and adding the GPIO test logs.

Thanks,
Aswath


Re: [PATCH] futex: use wake_up_process() instead of wake_up_state()

2021-03-18 Thread Mike Galbraith
On Fri, 2021-03-19 at 10:59 +0800, Wang Qing wrote:
> Using wake_up_process() is more simpler and friendly,
> and it is more convenient for analysis and statistics

I likely needn't bother, and don't have a NAK to paste on this thing,
but here's another copy of my NOPE for yet another gratuitous change
with complete BS justification.

>
> Signed-off-by: Wang Qing 
> ---
>  kernel/futex.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index e68db77..078a1f9
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -1820,7 +1820,7 @@ void requeue_pi_wake_futex(struct futex_q *q, union 
> futex_key *key,
>
>   q->lock_ptr = >lock;
>
> - wake_up_state(q->task, TASK_NORMAL);
> + wake_up_process(q->task);
>  }
>
>  /**



Re: [PATCH v5 1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S

2021-03-18 Thread Tianling Shen
Sorry everyone, please ignore these patches as I forgot to update them...
New patches were sent.

On 2021-03-19 13:10, Tianling Shen  wrote:
>
> Add devicetree binding documentation for the FriendlyARM NanoPi R4S.
>
> Changes in v5:
> - Dropped the empty PCIe node
> - Dropped useless `/delete-property/`
> - Renamed LED nodes
>
> Changes in v4:
> - Correctly dropped `display-subsystem` node
> - Dropped meaningless `pwm-fan` node
> - Dropped wrong `sdmmc` node
> - Disabled `i2c4` and `uart0` as they don't exist in the design
> - Format fixes
>
> Changes in v3:
> - Dropped non-existent node `display_subsystem`
>
> Changes in v2:
> - Disable display for NanoPi R4S (reference commit: 74532de460ec)
> - Light "sys" LED on NanoPi R4S (reference commit: 833821eeab91)
>
> Signed-off-by: Tianling Shen 
> ---
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
> b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index c3036f95c7bc..4a6f772c1043 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -134,6 +134,7 @@ properties:
>- friendlyarm,nanopi-m4
>- friendlyarm,nanopi-m4b
>- friendlyarm,nanopi-neo4
> +  - friendlyarm,nanopi-r4s
>- const: rockchip,rk3399
>
>- description: GeekBuying GeekBox
> --
> 2.17.1
>


[PATCH v3 1/2] arm64: dts: ti: k3-am64: Add GPIO DT nodes

2021-03-18 Thread Aswath Govindraju
Add device tree nodes for GPIO modules and interrupt controller in main
and mcu domains.

Signed-off-by: Aswath Govindraju 
---
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 45 
 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi  | 27 ++
 2 files changed, 72 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index a03b66456062..b997d13f9ec5 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -373,6 +373,51 @@
clocks = <_clks 145 0>;
};
 
+   main_gpio_intr: interrupt-controller0 {
+   compatible = "ti,sci-intr";
+   ti,intr-trigger-type = <1>;
+   interrupt-controller;
+   interrupt-parent = <>;
+   #interrupt-cells = <1>;
+   ti,sci = <>;
+   ti,sci-dev-id = <3>;
+   ti,interrupt-ranges = <0 32 16>;
+   };
+
+   main_gpio0: gpio@60 {
+   compatible = "ti,am64-gpio", "ti,keystone-gpio";
+   reg = <0x0 0x0060 0x0 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <_gpio_intr>;
+   interrupts = <190>, <191>, <192>,
+<193>, <194>, <195>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <87>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <_pds 77 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 77 0>;
+   clock-names = "gpio";
+   };
+
+   main_gpio1: gpio@601000 {
+   compatible = "ti,am64-gpio", "ti,keystone-gpio";
+   reg = <0x0 0x00601000 0x0 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <_gpio_intr>;
+   interrupts = <180>, <181>, <182>,
+<183>, <184>, <185>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <88>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <_pds 78 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 78 0>;
+   clock-names = "gpio";
+   };
+
sdhci0: mmc@fa1 {
compatible = "ti,am64-sdhci-8bit";
reg = <0x00 0xfa1 0x00 0x260>, <0x00 0xfa18000 0x00 0x134>;
diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi 
b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
index 1d2be485a669..99e94dee1bd4 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
@@ -73,4 +73,31 @@
power-domains = <_pds 148 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 148 0>;
};
+
+   mcu_gpio_intr: interrupt-controller1 {
+   compatible = "ti,sci-intr";
+   ti,intr-trigger-type = <1>;
+   interrupt-controller;
+   interrupt-parent = <>;
+   #interrupt-cells = <1>;
+   ti,sci = <>;
+   ti,sci-dev-id = <5>;
+   ti,interrupt-ranges = <0 104 4>;
+   };
+
+   mcu_gpio0: gpio@4201000 {
+   compatible = "ti,am64-gpio", "keystone-gpio";
+   reg = <0x0 0x4201000 0x0 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <_gpio_intr>;
+   interrupts = <30>, <31>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <23>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <_pds 79 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 79 0>;
+   clock-names = "gpio";
+   };
 };
-- 
2.17.1



[PATCH v3 2/2] arm64: dts: ti: k3-am642: reserve gpio in mcu domain for firmware usage

2021-03-18 Thread Aswath Govindraju
The gpio0 subsystem present in MCU domain might be used by firmware and is
not pinned out in evm/sk. Therefore, reserve it for MCU firmware.

Signed-off-by: Aswath Govindraju 
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 5 +
 arch/arm64/boot/dts/ti/k3-am642-sk.dts  | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts 
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 9522f104d979..385d99a3bc4f 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -310,6 +310,11 @@
};
 };
 
+/* mcu_gpio0 is reserved for mcu firmware usage */
+_gpio0 {
+   status = "reserved";
+};
+
 _i2c0 {
status = "disabled";
 };
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts 
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 3a5bee4b0b0c..282fb4185db9 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -220,6 +220,11 @@
status = "disabled";
 };
 
+/* mcu_gpio0 is reserved for mcu firmware usage */
+_gpio0 {
+   status = "reserved";
+};
+
  {
/* SD/MMC */
vmmc-supply = <_mmc1>;
-- 
2.17.1



[PATCH v3 0/2] AM64: Add support for GPIO

2021-03-18 Thread Aswath Govindraju
The following series of patches adds support for gpio on AM642 evm/sk.

GPIO test logs,
AM642-evm: https://pastebin.ubuntu.com/p/PCGmY34spb/
AM642-sk:  https://pastebin.ubuntu.com/p/nrxzyQTKkX/

Changes since v2:
- Rebased the series on top of ti-k3-dts-next branch
- Added gpio test logs.

Changes since v1:
- Added DT for gpio subsystem present in MCU domain
- reserved the mcu gpio for firmware usage

Aswath Govindraju (2):
  arm64: dts: ti: k3-am64: Add GPIO DT nodes
  arm64: dts: ti: k3-am642: reserve gpio in mcu domain for firmware
usage

 arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 45 
 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi  | 27 ++
 arch/arm64/boot/dts/ti/k3-am642-evm.dts  |  5 +++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts   |  5 +++
 4 files changed, 82 insertions(+)

-- 
2.17.1



[PATCH] MIPS: PCI: Fix a typo

2021-03-18 Thread Bhaskar Chowdhury


s/packt/packet/

Signed-off-by: Bhaskar Chowdhury 
---
 arch/mips/pci/pci-xtalk-bridge.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/pci/pci-xtalk-bridge.c b/arch/mips/pci/pci-xtalk-bridge.c
index 50f7d42cca5a..d2216942af18 100644
--- a/arch/mips/pci/pci-xtalk-bridge.c
+++ b/arch/mips/pci/pci-xtalk-bridge.c
@@ -385,7 +385,7 @@ static int bridge_domain_activate(struct irq_domain *domain,
bridge_set(bc, b_int_enable, 0x7e00); /* more stuff in int_enable */

/*
-* Enable sending of an interrupt clear packt to the hub on a high to
+* Enable sending of an interrupt clear packet to the hub on a high to
 * low transition of the interrupt pin.
 *
 * IRIX sets additional bits in the address which are documented as
--
2.26.2



[PATCH v6 1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S

2021-03-18 Thread Tianling Shen
Add devicetree binding documentation for the FriendlyARM NanoPi R4S.

Changes in v6:
- Fixed format of LED nodes

Changes in v5:
- Dropped the empty PCIe node
- Dropped useless `/delete-property/`
- Renamed LED nodes

Changes in v4:
- Correctly dropped `display-subsystem` node
- Dropped meaningless `pwm-fan` node
- Dropped wrong `sdmmc` node
- Disabled `i2c4` and `uart0` as they don't exist in the design
- Format fixes

Changes in v3:
- Dropped non-existent node `display_subsystem`

Changes in v2:
- Disable display for NanoPi R4S (reference commit: 74532de460ec)
- Light "sys" LED on NanoPi R4S (reference commit: 833821eeab91)

Signed-off-by: Tianling Shen 
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index c3036f95c7bc..4a6f772c1043 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -134,6 +134,7 @@ properties:
   - friendlyarm,nanopi-m4
   - friendlyarm,nanopi-m4b
   - friendlyarm,nanopi-neo4
+  - friendlyarm,nanopi-r4s
   - const: rockchip,rk3399
 
   - description: GeekBuying GeekBox
-- 
2.17.1



[PATCH v6 2/2] rockchip: rk3399: Add support for FriendlyARM NanoPi R4S

2021-03-18 Thread Tianling Shen
This adds support for the NanoPi R4S from FriendlyArm.

Rockchip RK3399 SoC
1GB DDR3 or 4GB LPDDR4 RAM
Gigabit Ethernet (WAN)
Gigabit Ethernet (PCIe) (LAN)
USB 3.0 Port x 2
MicroSD slot
Reset button
WAN - LAN - SYS LED

[initial DTS file]
Co-developed-by: Jensen Huang 
Signed-off-by: Jensen Huang 
[minor adjustments]
Co-developed-by: Marty Jones 
Signed-off-by: Marty Jones 
[further adjustments, fixed format issues]
Signed-off-by: Tianling Shen 
---
 arch/arm64/boot/dts/rockchip/Makefile |   1 +
 .../boot/dts/rockchip/rk3399-nanopi-r4s.dts   | 133 ++
 2 files changed, 134 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index 62d3abc17a24..c3e00c0e2db7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -36,6 +36,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-r4s.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-pinebook-pro.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
new file mode 100644
index ..fa5809887643
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPC-T4 board device tree source
+ *
+ * Copyright (c) 2020 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ *
+ * Copyright (c) 2020 Jensen Huang 
+ * Copyright (c) 2020 Marty Jones 
+ * Copyright (c) 2021 Tianling Shen 
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+   model = "FriendlyElec NanoPi R4S";
+   compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
+
+   /delete-node/ display-subsystem;
+
+   gpio-leds {
+   pinctrl-0 = <_led_pin>, <_led_pin>, <_led_pin>;
+
+   /delete-node/ led-0;
+
+   lan_led: led-lan {
+   gpios = < RK_PA1 GPIO_ACTIVE_HIGH>;
+   label = "green:lan";
+   };
+
+   sys_led: led-sys {
+   gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+   label = "red:sys";
+   default-state = "on";
+   };
+
+   wan_led: led-wan {
+   gpios = < RK_PA0 GPIO_ACTIVE_HIGH>;
+   label = "green:wan";
+   };
+   };
+
+   gpio-keys {
+   pinctrl-0 = <_button_pin>;
+
+   /delete-node/ power;
+
+   reset {
+   debounce-interval = <50>;
+   gpios = < RK_PC6 GPIO_ACTIVE_LOW>;
+   label = "reset";
+   linux,code = ;
+   };
+   };
+
+   vdd_5v: vdd-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "vdd_5v";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+_phy {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   max-link-speed = <1>;
+   num-lanes = <1>;
+   vpcie3v3-supply = <_sys>;
+};
+
+ {
+   gpio-leds {
+   /delete-node/ status-led-pin;
+
+   lan_led_pin: lan-led-pin {
+   rockchip,pins = <1 RK_PA1 RK_FUNC_GPIO _pull_none>;
+   };
+
+   sys_led_pin: sys-led-pin {
+   rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO _pull_none>;
+   };
+
+   wan_led_pin: wan-led-pin {
+   rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO _pull_none>;
+   };
+   };
+
+   rockchip-key {
+   /delete-node/ power-key;
+
+   reset_button_pin: reset-button-pin {
+   rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO _pull_up>;
+   };
+   };
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
+
+_host {
+   phy-supply = <_5v>;
+};
+
+_host {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
+
+_dwc3_0 {
+   dr_mode = "host";
+};
+
+_sys {
+   vin-supply = <_sys>;
+};
-- 
2.17.1



RE: [PATCH 10/11] i2c: imx-lpi2c: fix type char overflow issue when calculating the clock cycle

2021-03-18 Thread Aisheng Dong
> From: Clark Wang 
> Sent: Wednesday, March 17, 2021 2:54 PM
> 
> Claim clkhi and clklo as integer type to avoid possible calculation errors 
> caused
> by data overflow.
> 
> Reviewed-by: Fugang Duan 
> Signed-off-by: Clark Wang 

Reviewed-by: Dong Aisheng 

Regards
Aisheng

> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 5dbe85126f24..1e26672d47bf 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -213,8 +213,8 @@ static void lpi2c_imx_stop(struct lpi2c_imx_struct
> *lpi2c_imx)
> CLKHI = I2C_CLK_RATIO * clk_cycle */  static int lpi2c_imx_config(struct
> lpi2c_imx_struct *lpi2c_imx)  {
> - u8 prescale, filt, sethold, clkhi, clklo, datavd;
> - unsigned int clk_rate, clk_cycle;
> + u8 prescale, filt, sethold, datavd;
> + unsigned int clk_rate, clk_cycle, clkhi, clklo;
>   enum lpi2c_imx_pincfg pincfg;
>   unsigned int temp;
> 
> --
> 2.25.1



RE: [PATCH 09/11] i2c: imx-lpi2c: fix i2c timing issue

2021-03-18 Thread Aisheng Dong
> From: Clark Wang 
> Sent: Wednesday, March 17, 2021 2:54 PM
> 
> The clkhi and clklo ratio was not very precise before that can make the time 
> of
> START/STOP/HIGH LEVEL out of specification.
> 
> Therefore, the calculation of these times has been modified in this patch.
> At the same time, the mode rate definition of i2c is corrected.
> 
> Reviewed-by: Fugang Duan 
> Signed-off-by: Clark Wang 
> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 27 ++-
>  1 file changed, 14 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 7216a393095d..5dbe85126f24 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -73,17 +73,17 @@
>  #define MCFGR1_IGNACKBIT(9)
>  #define MRDR_RXEMPTY BIT(14)
> 
> -#define I2C_CLK_RATIO2
> +#define I2C_CLK_RATIO24 / 59

Where is this ratio coming from?
Can you describe why use it in commit message?

Regards
Aisheng

>  #define CHUNK_DATA   256
> 
>  #define I2C_PM_TIMEOUT   1000 /* ms */
> 
>  enum lpi2c_imx_mode {
> - STANDARD,   /* 100+Kbps */
> - FAST,   /* 400+Kbps */
> - FAST_PLUS,  /* 1.0+Mbps */
> - HS, /* 3.4+Mbps */
> - ULTRA_FAST, /* 5.0+Mbps */
> + STANDARD,   /* <=100Kbps */
> + FAST,   /* <=400Kbps */
> + FAST_PLUS,  /* <=1.0Mbps */
> + HS, /* <=3.4Mbps */
> + ULTRA_FAST, /* <=5.0Mbps */
>  };
> 
>  enum lpi2c_imx_pincfg {
> @@ -156,13 +156,13 @@ static void lpi2c_imx_set_mode(struct
> lpi2c_imx_struct *lpi2c_imx)
>   unsigned int bitrate = lpi2c_imx->bitrate;
>   enum lpi2c_imx_mode mode;
> 
> - if (bitrate < I2C_MAX_FAST_MODE_FREQ)
> + if (bitrate <= I2C_MAX_STANDARD_MODE_FREQ)
>   mode = STANDARD;
> - else if (bitrate < I2C_MAX_FAST_MODE_PLUS_FREQ)
> + else if (bitrate <= I2C_MAX_FAST_MODE_FREQ)
>   mode = FAST;
> - else if (bitrate < I2C_MAX_HIGH_SPEED_MODE_FREQ)
> + else if (bitrate <= I2C_MAX_FAST_MODE_PLUS_FREQ)
>   mode = FAST_PLUS;
> - else if (bitrate < I2C_MAX_ULTRA_FAST_MODE_FREQ)
> + else if (bitrate <= I2C_MAX_HIGH_SPEED_MODE_FREQ)
>   mode = HS;
>   else
>   mode = ULTRA_FAST;
> @@ -209,7 +209,8 @@ static void lpi2c_imx_stop(struct lpi2c_imx_struct
> *lpi2c_imx)
>   } while (1);
>  }
> 
> -/* CLKLO = I2C_CLK_RATIO * CLKHI, SETHOLD = CLKHI, DATAVD = CLKHI/2 */
> +/* CLKLO = (1 - I2C_CLK_RATIO) * clk_cycle, SETHOLD = CLKHI, DATAVD =
> CLKHI/2
> +   CLKHI = I2C_CLK_RATIO * clk_cycle */
>  static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx)  {
>   u8 prescale, filt, sethold, clkhi, clklo, datavd; @@ -232,8 +233,8 @@
> static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx)
> 
>   for (prescale = 0; prescale <= 7; prescale++) {
>   clk_cycle = clk_rate / ((1 << prescale) * lpi2c_imx->bitrate)
> - - 3 - (filt >> 1);
> - clkhi = (clk_cycle + I2C_CLK_RATIO) / (I2C_CLK_RATIO + 1);
> + - (2 + filt) / (1 << prescale);
> + clkhi = clk_cycle * I2C_CLK_RATIO;
>   clklo = clk_cycle - clkhi;
>   if (clklo < 64)
>   break;
> --
> 2.25.1



[PATCH] MAINTAINERS: Update MCAN MMIO device driver maintainer

2021-03-18 Thread Pankaj Sharma
Update Chandrasekar Ramakrishnan as maintainer for mcan mmio device driver as I
will be moving to a different role.

Signed-off-by: Pankaj Sharma 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a50a543e3c81..76db44337f6c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10820,7 +10820,7 @@ F:  drivers/media/radio/radio-maxiradio*
 
 MCAN MMIO DEVICE DRIVER
 M: Dan Murphy 
-M: Pankaj Sharma 
+M: Chandrasekar Ramakrishnan 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
-- 
2.17.1



RE: [PATCH 08/11] i2c: imx-lpi2c: add bus recovery feature

2021-03-18 Thread Aisheng Dong
> From: Clark Wang 
> Sent: Wednesday, March 17, 2021 2:54 PM
> 
> Add bus recovery feature for LPI2C.
> Need add gpio pinctrl, scl-gpios and sda-gpios configuration in dts.
> 

Pls also update dt-binding first

> Signed-off-by: Clark Wang 
> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 83 ++
>  1 file changed, 83 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index c0cb77c66090..7216a393095d 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -108,6 +109,11 @@ struct lpi2c_imx_struct {
>   unsigned inttxfifosize;
>   unsigned intrxfifosize;
>   enum lpi2c_imx_mode mode;
> +
> + struct i2c_bus_recovery_info rinfo;
> + struct pinctrl *pinctrl;
> + struct pinctrl_state *pinctrl_pins_default;
> + struct pinctrl_state *pinctrl_pins_gpio;
>  };
> 
>  static void lpi2c_imx_intctrl(struct lpi2c_imx_struct *lpi2c_imx, @@ -135,6
> +141,8 @@ static int lpi2c_imx_bus_busy(struct lpi2c_imx_struct *lpi2c_imx)
> 
>   if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
>   dev_dbg(_imx->adapter.dev, "bus not work\n");
> + if (lpi2c_imx->adapter.bus_recovery_info)
> + i2c_recover_bus(_imx->adapter);
>   return -ETIMEDOUT;
>   }
>   schedule();
> @@ -192,6 +200,8 @@ static void lpi2c_imx_stop(struct lpi2c_imx_struct
> *lpi2c_imx)
> 
>   if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
>   dev_dbg(_imx->adapter.dev, "stop timeout\n");
> + if (lpi2c_imx->adapter.bus_recovery_info)
> + i2c_recover_bus(_imx->adapter);
>   break;
>   }
>   schedule();
> @@ -329,6 +339,8 @@ static int lpi2c_imx_txfifo_empty(struct
> lpi2c_imx_struct *lpi2c_imx)
> 
>   if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
>   dev_dbg(_imx->adapter.dev, "txfifo empty 
> timeout\n");
> + if (lpi2c_imx->adapter.bus_recovery_info)
> + i2c_recover_bus(_imx->adapter);
>   return -ETIMEDOUT;
>   }
>   schedule();
> @@ -528,6 +540,71 @@ static irqreturn_t lpi2c_imx_isr(int irq, void *dev_id)
>   return IRQ_HANDLED;
>  }
> 
> +static void lpi2c_imx_prepare_recovery(struct i2c_adapter *adap) {
> + struct lpi2c_imx_struct *lpi2c_imx;
> +
> + lpi2c_imx = container_of(adap, struct lpi2c_imx_struct, adapter);
> +
> + pinctrl_select_state(lpi2c_imx->pinctrl,
> +lpi2c_imx->pinctrl_pins_gpio); }
> +
> +static void lpi2c_imx_unprepare_recovery(struct i2c_adapter *adap) {
> + struct lpi2c_imx_struct *lpi2c_imx;
> +
> + lpi2c_imx = container_of(adap, struct lpi2c_imx_struct, adapter);
> +
> + pinctrl_select_state(lpi2c_imx->pinctrl,
> +lpi2c_imx->pinctrl_pins_default); }
> +
> +/*
> + * We switch SCL and SDA to their GPIO function and do some bitbanging
> + * for bus recovery. These alternative pinmux settings can be
> + * described in the device tree by a separate pinctrl state "gpio". If
> + * this is missing this is not a big problem, the only implication is
> + * that we can't do bus recovery.
> + */
> +static int lpi2c_imx_init_recovery_info(struct lpi2c_imx_struct *lpi2c_imx,
> + struct platform_device *pdev)
> +{
> + struct i2c_bus_recovery_info *rinfo = _imx->rinfo;
> +
> + lpi2c_imx->pinctrl = devm_pinctrl_get(>dev);
> + if (!lpi2c_imx->pinctrl || IS_ERR(lpi2c_imx->pinctrl)) {
> + dev_info(>dev, "can't get pinctrl, bus recovery not
> supported\n");
> + return PTR_ERR(lpi2c_imx->pinctrl);
> + }
> +
> + lpi2c_imx->pinctrl_pins_default = 
> pinctrl_lookup_state(lpi2c_imx->pinctrl,
> + PINCTRL_STATE_DEFAULT);
> + lpi2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(lpi2c_imx->pinctrl,
> + "gpio");
> + rinfo->sda_gpiod = devm_gpiod_get(>dev, "sda", GPIOD_IN);
> + rinfo->scl_gpiod = devm_gpiod_get(>dev, "scl",
> +GPIOD_OUT_HIGH_OPEN_DRAIN);
> +
> + if (PTR_ERR(rinfo->sda_gpiod) == -EPROBE_DEFER ||
> + PTR_ERR(rinfo->scl_gpiod) == -EPROBE_DEFER) {
> + return -EPROBE_DEFER;
> + } else if (IS_ERR(rinfo->sda_gpiod) ||
> +IS_ERR(rinfo->scl_gpiod) ||
> +IS_ERR(lpi2c_imx->pinctrl_pins_default) ||
> +IS_ERR(lpi2c_imx->pinctrl_pins_gpio)) {
> + dev_dbg(>dev, "recovery information incomplete\n");
> + return 0;
> + }
> +
> + dev_info(>dev, "using scl%s for recovery\n",
> +  rinfo->sda_gpiod ? ",sda" : "");
> +
> + 

RE: [PATCH 07/11] i2c: imx-lpi2c: increase PM timeout to avoid operate clk frequently

2021-03-18 Thread Aisheng Dong
> From: Clark Wang 
> Sent: Wednesday, March 17, 2021 2:54 PM
> 
> Switching the clock frequently will affect the data transmission efficiency, 
> and
> prolong the timeout to reduce autosuspend times for lpi2c.
> 
> Acked-by: Fugang Duan 
> Signed-off-by: Clark Wang 

Reviewed-by: Dong Aisheng 

Regards
Aisheng

> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 86b69852f7be..c0cb77c66090 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -75,7 +75,7 @@
>  #define I2C_CLK_RATIO2
>  #define CHUNK_DATA   256
> 
> -#define I2C_PM_TIMEOUT   10 /* ms */
> +#define I2C_PM_TIMEOUT   1000 /* ms */
> 
>  enum lpi2c_imx_mode {
>   STANDARD,   /* 100+Kbps */
> --
> 2.25.1



[PATCH v5 1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S

2021-03-18 Thread Tianling Shen
Add devicetree binding documentation for the FriendlyARM NanoPi R4S.

Changes in v5:
- Dropped the empty PCIe node
- Dropped useless `/delete-property/`
- Renamed LED nodes

Changes in v4:
- Correctly dropped `display-subsystem` node
- Dropped meaningless `pwm-fan` node
- Dropped wrong `sdmmc` node
- Disabled `i2c4` and `uart0` as they don't exist in the design
- Format fixes

Changes in v3:
- Dropped non-existent node `display_subsystem`

Changes in v2:
- Disable display for NanoPi R4S (reference commit: 74532de460ec)
- Light "sys" LED on NanoPi R4S (reference commit: 833821eeab91)

Signed-off-by: Tianling Shen 
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index c3036f95c7bc..4a6f772c1043 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -134,6 +134,7 @@ properties:
   - friendlyarm,nanopi-m4
   - friendlyarm,nanopi-m4b
   - friendlyarm,nanopi-neo4
+  - friendlyarm,nanopi-r4s
   - const: rockchip,rk3399
 
   - description: GeekBuying GeekBox
-- 
2.17.1



[PATCH v5 2/2] rockchip: rk3399: Add support for FriendlyARM NanoPi R4S

2021-03-18 Thread Tianling Shen
This adds support for the NanoPi R4S from FriendlyArm.

Rockchip RK3399 SoC
1GB DDR3 or 4GB LPDDR4 RAM
Gigabit Ethernet (WAN)
Gigabit Ethernet (PCIe) (LAN)
USB 3.0 Port x 2
MicroSD slot
Reset button
WAN - LAN - SYS LED

[initial DTS file]
Co-developed-by: Jensen Huang 
Signed-off-by: Jensen Huang 
[minor adjustments]
Co-developed-by: Marty Jones 
Signed-off-by: Marty Jones 
[further adjustments, fixed format issues]
Signed-off-by: Tianling Shen 
---
 arch/arm64/boot/dts/rockchip/Makefile |   1 +
 .../boot/dts/rockchip/rk3399-nanopi-r4s.dts   | 133 ++
 2 files changed, 134 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index 62d3abc17a24..c3e00c0e2db7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -36,6 +36,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-r4s.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-pinebook-pro.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
new file mode 100644
index ..0aa19c06908d
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPC-T4 board device tree source
+ *
+ * Copyright (c) 2020 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ *
+ * Copyright (c) 2020 Jensen Huang 
+ * Copyright (c) 2020 Marty Jones 
+ * Copyright (c) 2021 Tianling Shen 
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+   model = "FriendlyElec NanoPi R4S";
+   compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
+
+   /delete-node/ display-subsystem;
+
+   gpio-leds {
+   pinctrl-0 = <_led_pin>, <_led_pin>, <_led_pin>;
+
+   /delete-node/ led-0;
+
+   lan_led: lan-led {
+   gpios = < RK_PA1 GPIO_ACTIVE_HIGH>;
+   label = "nanopi-r4s:green:lan";
+   };
+
+   sys_led: sys-led {
+   gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+   label = "nanopi-r4s:red:sys";
+   default-state = "on";
+   };
+
+   wan_led: wan-led {
+   gpios = < RK_PA0 GPIO_ACTIVE_HIGH>;
+   label = "nanopi-r4s:green:wan";
+   };
+   };
+
+   gpio-keys {
+   pinctrl-0 = <_button_pin>;
+
+   /delete-node/ power;
+
+   reset {
+   debounce-interval = <50>;
+   gpios = < RK_PC6 GPIO_ACTIVE_LOW>;
+   label = "reset";
+   linux,code = ;
+   };
+   };
+
+   vdd_5v: vdd-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "vdd_5v";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+_phy {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   max-link-speed = <1>;
+   num-lanes = <1>;
+   vpcie3v3-supply = <_sys>;
+};
+
+ {
+   gpio-leds {
+   /delete-node/ status-led-pin;
+
+   lan_led_pin: lan-led-pin {
+   rockchip,pins = <1 RK_PA1 RK_FUNC_GPIO _pull_none>;
+   };
+
+   sys_led_pin: sys-led-pin {
+   rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO _pull_none>;
+   };
+
+   wan_led_pin: wan-led-pin {
+   rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO _pull_none>;
+   };
+   };
+
+   rockchip-key {
+   /delete-node/ power-key;
+
+   reset_button_pin: reset-button-pin {
+   rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO _pull_up>;
+   };
+   };
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
+
+_host {
+   phy-supply = <_5v>;
+};
+
+_host {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
+
+_dwc3_0 {
+   dr_mode = "host";
+};
+
+_sys {
+   vin-supply = <_sys>;
+};
-- 
2.17.1



Re: [PATCH V3] exit: trigger panic when global init has exited

2021-03-18 Thread qianli zhao
Hi,Oleg

> But then I don't understand the SIGNAL_GROUP_EXIT check added by your
> patch. Do we really need it if we want to avoid zap_pid_ns_processes()
> when the global init exits?

I think check SIGNAL_GROUP_EXIT is necessary,or panic() will happen
after all init sub-threads do_exit(),so the following two situations
will happen:
1.According to the timing in the changelog,
zap_pid_ns_processes()->BUG() maybe happened.
2.The key variables of each init sub-threads will be in the exit
state(such task->mm=NULL,task->flags=PF_EXITING,task->nsproxy=NULL),resulting
in the failure to parse coredump from fulldump.

So i think check SIGNAL_GROUP_EXIT is a simple and effective way to
prevent these

> Does this connect to SIGNAL_GROUP_EXIT check? Do you mean that you want
> to panic earlier, before other init's sub-threads exit?

Yes, my patch just want panic earlier before other init's sub-threads exit

Oleg Nesterov  于2021年3月19日周五 上午2:05写道:
>
> On 03/18, qianli zhao wrote:
> >
> > Hi,Oleg
> >
> > Thank you for your reply.
> >
> > >> When init sub-threads running on different CPUs exit at the same time,
> > >> zap_pid_ns_processe()->BUG() may be happened.
> >
> > > and why do you think your patch can't prevent this?
> >
> > > Sorry, I must have missed something. But it seems to me that you are 
> > > trying
> > > to fix the wrong problem. Yes, zap_pid_ns_processes() must not be called 
> > > in
> > > the root namespace, and this has nothing to do with CONFIG_PID_NS.
> >
> > Yes, i try to fix this exception by test SIGNAL_GROUP_EXIT and call
> > panic before setting PF_EXITING to prevent zap_pid_ns_processes()
> > being called when init do_exit().
>
> Ah, I didn't notice your patch does atomic_dec_and_test(signal->live)
> before exit_signals() which sets PF_EXITING. Thanks for correcting me.
>
> So yes, I was wrong, your patch can prevent this. Although I'd like to
> recheck if every do-something-if-group-dead action is correct in the
> case we have a non-PF_EXITING thread...
>
> But then I don't understand the SIGNAL_GROUP_EXIT check added by your
> patch. Do we really need it if we want to avoid zap_pid_ns_processes()
> when the global init exits?
>
> > In addition, the patch also protects the init process state to
> > successfully get usable init coredump.
>
> Could you spell please?
>
> Does this connect to SIGNAL_GROUP_EXIT check? Do you mean that you want
> to panic earlier, before other init's sub-threads exit?
>
> Thanks,
>
> Oleg.
>


RE: [PATCH 06/11] i2c: imx-lpi2c: improve i2c driver probe priority

2021-03-18 Thread Aisheng Dong
> From: Clark Wang 
> Sent: Wednesday, March 17, 2021 2:54 PM
> 
> use subsys_initcall for i2c driver to improve i2c driver probe priority

Will this affect DMA support which will be probed much later compared with 
subsys_initcall?

> 
> Signed-off-by: Gao Pan 

Add your sign-off

> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 8f9dd3dd2951..86b69852f7be 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -710,7 +710,17 @@ static struct platform_driver lpi2c_imx_driver = {
>   },
>  };
> 
> -module_platform_driver(lpi2c_imx_driver);
> +static int __init lpi2c_imx_init(void)
> +{
> + return platform_driver_register(_imx_driver);
> +}
> +subsys_initcall(lpi2c_imx_init);
> +
> +static void __exit lpi2c_imx_exit(void) {
> + platform_driver_unregister(_imx_driver);
> +}
> +module_exit(lpi2c_imx_exit);
> 
>  MODULE_AUTHOR("Gao Pan ");
> MODULE_DESCRIPTION("I2C adapter driver for LPI2C bus");
> --
> 2.25.1



Re: [PATCH] swiotlb: Make SWIOTLB_NO_FORCE perform no allocation

2021-03-18 Thread Konrad Rzeszutek Wilk
On Thu, Mar 18, 2021 at 09:00:54PM -0700, Florian Fainelli wrote:
> When SWIOTLB_NO_FORCE is used, there should really be no allocations of
> io_tlb_nslabs to occur since we are not going to use those slabs. If a
> platform was somehow setting swiotlb_no_force and a later call to
> swiotlb_init() was to be made we would still be proceeding with
> allocating the default SWIOTLB size (64MB), whereas if swiotlb=noforce
> was set on the kernel command line we would have only allocated 2KB.
> 
> This would be inconsistent and the point of initializing io_tlb_nslabs
> to 1, was to avoid hitting the test for io_tlb_nslabs being 0/not
> initialized.

Could you rebase this on devel/for-linus-5.13 in

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git

please?
> 
> Signed-off-by: Florian Fainelli 
> ---
>  kernel/dma/swiotlb.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index c10e855a03bc..526c8321b76f 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -121,12 +121,10 @@ setup_io_tlb_npages(char *str)
>   }
>   if (*str == ',')
>   ++str;
> - if (!strcmp(str, "force")) {
> + if (!strcmp(str, "force"))
>   swiotlb_force = SWIOTLB_FORCE;
> - } else if (!strcmp(str, "noforce")) {
> + else if (!strcmp(str, "noforce"))
>   swiotlb_force = SWIOTLB_NO_FORCE;
> - io_tlb_nslabs = 1;
> - }
>  
>   return 0;
>  }
> @@ -284,6 +282,9 @@ swiotlb_init(int verbose)
>   unsigned char *vstart;
>   unsigned long bytes;
>  
> + if (swiotlb_force == SWIOTLB_NO_FORCE)
> + goto out;
> +
>   if (!io_tlb_nslabs) {
>   io_tlb_nslabs = (default_size >> IO_TLB_SHIFT);
>   io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
> @@ -302,6 +303,7 @@ swiotlb_init(int verbose)
>   io_tlb_start = 0;
>   }
>   pr_warn("Cannot allocate buffer");
> +out:
>   no_iotlb_memory = true;
>  }
>  
> -- 
> 2.25.1
> 


Re: [PATCH net-next 4/4] net: ipa: activate some commented assertions

2021-03-18 Thread Leon Romanovsky
On Thu, Mar 18, 2021 at 11:29:23PM -0500, Alex Elder wrote:
> Convert some commented assertion statements into real calls to
> ipa_assert().  If the IPA device pointer is available, provide it,
> otherwise pass NULL for that.
> 
> There are lots more places to convert, but this serves as an initial
> verification of the new mechanism.  The assertions here implement
> both runtime and build-time assertions, both with and without the
> device pointer.
> 
> Signed-off-by: Alex Elder 
> ---
>  drivers/net/ipa/ipa_reg.h   | 7 ---
>  drivers/net/ipa/ipa_table.c | 5 -
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ipa/ipa_reg.h b/drivers/net/ipa/ipa_reg.h
> index 732e691e9aa62..d0de85de9f08d 100644
> --- a/drivers/net/ipa/ipa_reg.h
> +++ b/drivers/net/ipa/ipa_reg.h
> @@ -9,6 +9,7 @@
>  #include 
>  
>  #include "ipa_version.h"
> +#include "ipa_assert.h"
>  
>  struct ipa;
>  
> @@ -212,7 +213,7 @@ static inline u32 ipa_reg_bcr_val(enum ipa_version 
> version)
>   BCR_HOLB_DROP_L2_IRQ_FMASK |
>   BCR_DUAL_TX_FMASK;
>  
> - /* assert(version != IPA_VERSION_4_5); */
> + ipa_assert(NULL, version != IPA_VERSION_4_5);

This assert will fire for IPA_VERSION_4_2, I doubt that this is
something you want.

Thanks


[PATCH v2] hwmon: add driver for NZXT Kraken X42/X52/X62/X72

2021-03-18 Thread Jonas Malaco
These are "all-in-one" CPU liquid coolers that can be monitored and
controlled through a proprietary USB HID protocol.

While the models have differently sized radiators and come with varying
numbers of fans, they are all indistinguishable at the software level.

The driver exposes fan/pump speeds and coolant temperature through the
standard hwmon sysfs interface.

Fan and pump control, while supported by the devices, are not currently
exposed.  The firmware accepts up to 61 trip points per channel
(fan/pump), but the same set of trip temperatures has to be maintained
for both; with pwmX_auto_point_Y_temp attributes, users would need to
maintain this invariant themselves.

Instead, fan and pump control, as well as LED control (which the device
also supports for 9 addressable RGB LEDs on the CPU water block) are
left for existing and already mature user-space tools, which can still
be used alongside the driver, thanks to hidraw.  A link to one, which I
also maintain, is provided in the documentation.

The implementation is based on USB traffic analysis.  It has been
runtime tested on x86_64, both as a built-in driver and as a module.

Signed-off-by: Jonas Malaco 
---
Changes in v2:
- remove unnecessary type, attr and channel checks from _is_visible
- remove unnecessary attr and channel checks from _read/_read_string
- remove the spinlock by computing values in the event handler
- add comment describing how the device reports data
- report missing or stale data to user-space
- adjust copyright notice

 Documentation/hwmon/index.rst|   1 +
 Documentation/hwmon/nzxt-kraken2.rst |  42 +
 MAINTAINERS  |   7 +
 drivers/hwmon/Kconfig|  10 ++
 drivers/hwmon/Makefile   |   1 +
 drivers/hwmon/nzxt-kraken2.c | 235 +++
 6 files changed, 296 insertions(+)
 create mode 100644 Documentation/hwmon/nzxt-kraken2.rst
 create mode 100644 drivers/hwmon/nzxt-kraken2.c

diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index d4b422edbe3a..48bfa7887dd4 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -143,6 +143,7 @@ Hardware Monitoring Kernel Drivers
npcm750-pwm-fan
nsa320
ntc_thermistor
+   nzxt-kraken2
occ
pc87360
pc87427
diff --git a/Documentation/hwmon/nzxt-kraken2.rst 
b/Documentation/hwmon/nzxt-kraken2.rst
new file mode 100644
index ..94025de65a81
--- /dev/null
+++ b/Documentation/hwmon/nzxt-kraken2.rst
@@ -0,0 +1,42 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver nzxt-kraken2
+==
+
+Supported devices:
+
+* NZXT Kraken X42
+* NZXT Kraken X52
+* NZXT Kraken X62
+* NZXT Kraken X72
+
+Author: Jonas Malaco
+
+Description
+---
+
+This driver enables hardware monitoring support for NZXT Kraken X42/X52/X62/X72
+all-in-one CPU liquid coolers.  Three sensors are available: fan speed, pump
+speed and coolant temperature.
+
+Fan and pump control, while supported by the firmware, are not currently
+exposed.  The addressable RGB LEDs, present in the integrated CPU water block
+and pump head, are not supported either.  But both features can be found in
+existing user-space tools (e.g. `liquidctl`_).
+
+.. _liquidctl: https://github.com/liquidctl/liquidctl
+
+Usage Notes
+---
+
+As these are USB HIDs, the driver can be loaded automatically by the kernel and
+supports hot swapping.
+
+Sysfs entries
+-
+
+===

+fan1_input Fan speed (in rpm)
+fan2_input Pump speed (in rpm)
+temp1_inputCoolant temperature (in millidegrees Celsius)
+===

diff --git a/MAINTAINERS b/MAINTAINERS
index 0635b30e467c..b8f9fc5eaf08 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12911,6 +12911,13 @@ L: linux-...@lists.01.org (moderated for 
non-subscribers)
 S: Supported
 F: drivers/nfc/nxp-nci
 
+NZXT-KRAKEN2 HARDWARE MONITORING DRIVER
+M: Jonas Malaco 
+L: linux-hw...@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/nzxt-kraken2.rst
+F: drivers/hwmon/nzxt-kraken2.c
+
 OBJAGG
 M: Jiri Pirko 
 L: net...@vger.kernel.org
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 54f04e61fb83..0ddc974b102e 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1492,6 +1492,16 @@ config SENSORS_NSA320
  This driver can also be built as a module. If so, the module
  will be called nsa320-hwmon.
 
+config SENSORS_NZXT_KRAKEN2
+   tristate "NZXT Kraken X42/X51/X62/X72 liquid coolers"
+   depends on USB_HID
+   help
+ If you say yes here you get support for hardware monitoring for the
+ NZXT Kraken X42/X52/X62/X72 all-in-one CPU liquid coolers.
+
+ This driver can also be built as a module. If so, the 

Re: [PATCH v2] perf stat: Align CSV output for summary mode

2021-03-18 Thread Jin, Yao

Hi Arnaldo,

On 3/18/2021 9:15 PM, Arnaldo Carvalho de Melo wrote:

Em Wed, Mar 17, 2021 at 02:51:42PM -0700, Andi Kleen escreveu:

If you care about not breaking existing scripts, then the output they
get with what they use as command line options must continue to produce
the same output.


It's not clear there are any useful ones (except for tools that handle
both). It's really hard to parse the previous mess. It's simply not
valid CSV.

That's why I'm arguing that keeping compatibility is not useful here.

We would be stuck with the broken mess as default forever.


Fair enough, lets fix the default then. Jin, can you please consider
adding a 'perf test' shell entry to parse the CSV mode with/without that
summary? This way we'll notice when the new normal gets broken.

- Arnaldo



Thanks Arnaldo! I will post v3 with the perf test script.

Thanks
Jin Yao



RE: [PATCH 05/11] i2c: imx-lpi2c: add debug message when i2c peripheral clk doesn't work

2021-03-18 Thread Aisheng Dong
> From: Clark Wang 
> Sent: Wednesday, March 17, 2021 2:54 PM
> 
> add debug message when i2c peripheral clk rate is 0, then directly return
> -EINVAL.
> 
> Signed-off-by: Gao Pan 
> Reviewed-by: Andy Duan 

Drop old review when patch is changed

> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index e718bb6b2387..8f9dd3dd2951 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -209,7 +209,12 @@ static int lpi2c_imx_config(struct lpi2c_imx_struct
> *lpi2c_imx)
> 
>   lpi2c_imx_set_mode(lpi2c_imx);
> 
> - clk_rate = clk_get_rate(lpi2c_imx->clk);

I guess the kernel can't compile right before this patch because lpi2c_imx->clk 
was
Removed In former patch
You need double check not break bisect

> + clk_rate = clk_get_rate(lpi2c_imx->clk_per);
> + if (!clk_rate) {
> + dev_dbg(_imx->adapter.dev, "clk_per rate is 0\n");

s/dev_dbg/dev_err

> + return -EINVAL;
> + }
> +
>   if (lpi2c_imx->mode == HS || lpi2c_imx->mode == ULTRA_FAST)
>   filt = 0;
>   else
> --
> 2.25.1



[PATCH] microblaze: Fix a typo

2021-03-18 Thread Bhaskar Chowdhury


s/storign/storing/

Signed-off-by: Bhaskar Chowdhury 
---
 arch/microblaze/lib/uaccess_old.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/microblaze/lib/uaccess_old.S 
b/arch/microblaze/lib/uaccess_old.S
index 0e8cc2710c27..eca290090038 100644
--- a/arch/microblaze/lib/uaccess_old.S
+++ b/arch/microblaze/lib/uaccess_old.S
@@ -188,7 +188,7 @@ w2: sw  r4, r5, r3
.text

 .align 4 /* Alignment is important to keep icache happy */
-page:  /* Create room on stack and save registers for storign values */
+page:  /* Create room on stack and save registers for storing values */
addik   r1, r1, -40
swi r5, r1, 0
swi r6, r1, 4
--
2.26.2



Re: [PATCH net-next 3/4] net: ipa: introduce ipa_assert()

2021-03-18 Thread Leon Romanovsky
On Thu, Mar 18, 2021 at 11:29:22PM -0500, Alex Elder wrote:
> Create a new macro ipa_assert() to verify that a condition is true.
> This produces a build-time error if the condition can be evaluated
> at build time; otherwise __ipa_assert_runtime() is called (described
> below).
> 
> Another macro, ipa_assert_always() verifies that an expression
> yields true at runtime, and if it does not, reports an error
> message.
> 
> When IPA validation is enabled, __ipa_assert_runtime() becomes a
> call to ipa_assert_always(), resulting in runtime verification of
> the asserted condition.  Otherwise __ipa_assert_runtime() has no
> effect, so such ipa_assert() calls are effectively ignored.
> 
> IPA assertion errors will be reported using the IPA device if
> possible.
> 
> Signed-off-by: Alex Elder 
> ---
>  drivers/net/ipa/ipa_assert.h | 50 
>  1 file changed, 50 insertions(+)
>  create mode 100644 drivers/net/ipa/ipa_assert.h
> 
> diff --git a/drivers/net/ipa/ipa_assert.h b/drivers/net/ipa/ipa_assert.h
> new file mode 100644
> index 0..7e5b9d487f69d
> --- /dev/null
> +++ b/drivers/net/ipa/ipa_assert.h
> @@ -0,0 +1,50 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2021 Linaro Ltd.
> + */
> +#ifndef _IPA_ASSERT_H_
> +#define _IPA_ASSERT_H_
> +
> +#include 
> +#include 
> +#include 
> +
> +/* Verify the expression yields true, and fail at build time if possible */
> +#define ipa_assert(dev, expr) \
> + do { \
> + if (__builtin_constant_p(expr)) \
> + compiletime_assert(expr, __ipa_failure_msg(expr)); \
> + else \
> + __ipa_assert_runtime(dev, expr); \
> + } while (0)
> +
> +/* Report an error if the given expression evaluates to false at runtime */
> +#define ipa_assert_always(dev, expr) \
> + do { \
> + if (unlikely(!(expr))) { \
> + struct device *__dev = (dev); \
> + \
> + if (__dev) \
> + dev_err(__dev, __ipa_failure_msg(expr)); \
> + else  \
> + pr_err(__ipa_failure_msg(expr)); \
> + } \
> + } while (0)

It will be much better for everyone if you don't obfuscate existing
kernel primitives and don't hide constant vs. dynamic expressions.

So any random kernel developer will be able to change the code without
investing too much time to understand this custom logic.

And constant expressions are checked with BUILD_BUG_ON().

If you still feel need to provide assertion like this, it should be done
in general code.

Thanks

> +
> +/* Constant message used when an assertion fails */
> +#define __ipa_failure_msg(expr)  "IPA assertion failed: " #expr "\n"
> +
> +#ifdef IPA_VALIDATION
> +
> +/* Only do runtime checks for "normal" assertions if validating the code */
> +#define __ipa_assert_runtime(dev, expr)  ipa_assert_always(dev, expr)
> +
> +#else /* !IPA_VALIDATION */
> +
> +/* "Normal" assertions aren't checked when validation is disabled */
> +#define __ipa_assert_runtime(dev, expr)  \
> + do { (void)(dev); (void)(expr); } while (0)
> +
> +#endif /* !IPA_VALIDATION */
> +
> +#endif /* _IPA_ASSERT_H_ */
> -- 
> 2.27.0
> 


RE: [PATCH 04/11] i2c: imx-lpi2c: manage irq resource request/release in runtime pm

2021-03-18 Thread Aisheng Dong
> From: Clark Wang 
> Sent: Wednesday, March 17, 2021 2:54 PM
> 
> Manage irq resource request/release in runtime pm to save irq domain's
> power.
> 
> Signed-off-by: Frank Li 
> Signed-off-by: Fugang Duan 
> Reviewed-by: Frank Li 
> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 664fcc0dba51..e718bb6b2387 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -94,6 +94,7 @@ enum lpi2c_imx_pincfg {
> 
>  struct lpi2c_imx_struct {
>   struct i2c_adapter  adapter;
> + int irq;
>   struct clk  *clk_per;
>   struct clk  *clk_ipg;
>   void __iomem*base;
> @@ -543,7 +544,7 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev)  {
>   struct lpi2c_imx_struct *lpi2c_imx;
>   unsigned int temp;
> - int irq, ret;
> + int ret;
> 
>   lpi2c_imx = devm_kzalloc(>dev, sizeof(*lpi2c_imx), GFP_KERNEL);
>   if (!lpi2c_imx)
> @@ -553,9 +554,9 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev)
>   if (IS_ERR(lpi2c_imx->base))
>   return PTR_ERR(lpi2c_imx->base);
> 
> - irq = platform_get_irq(pdev, 0);
> - if (irq < 0)
> - return irq;
> + lpi2c_imx->irq = platform_get_irq(pdev, 0);
> + if (lpi2c_imx->irq < 0)
> + return lpi2c_imx->irq;
> 
>   lpi2c_imx->adapter.owner= THIS_MODULE;
>   lpi2c_imx->adapter.algo = _imx_algo;
> @@ -581,14 +582,6 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev)
>   if (ret)
>   lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
> 
> - ret = devm_request_irq(>dev, irq, lpi2c_imx_isr,
> -IRQF_NO_SUSPEND,
> -pdev->name, lpi2c_imx);
> - if (ret) {
> - dev_err(>dev, "can't claim irq %d\n", irq);
> - return ret;
> - }
> -
>   i2c_set_adapdata(_imx->adapter, lpi2c_imx);
>   platform_set_drvdata(pdev, lpi2c_imx);
> 
> @@ -640,6 +633,7 @@ static int __maybe_unused
> lpi2c_runtime_suspend(struct device *dev)  {
>   struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
> 
> + devm_free_irq(dev, lpi2c_imx->irq, lpi2c_imx);
>   clk_disable_unprepare(lpi2c_imx->clk_ipg);
>   clk_disable_unprepare(lpi2c_imx->clk_per);
>   pinctrl_pm_select_idle_state(dev);
> @@ -665,6 +659,14 @@ static int __maybe_unused
> lpi2c_runtime_resume(struct device *dev)
>   dev_err(dev, "can't enable I2C ipg clock, ret=%d\n", ret);
>   }
> 
> + ret = devm_request_irq(dev, lpi2c_imx->irq, lpi2c_imx_isr,

I guess unnecessary to use devm in rpm

> +IRQF_NO_SUSPEND,
> +dev_name(dev), lpi2c_imx);
> + if (ret) {
> + dev_err(dev, "can't claim irq %d\n", lpi2c_imx->irq);
> + return ret;
> + }
> +
>   return ret;
>  }
> 
> --
> 2.25.1



[PATCH] sch_red: Fix a typo

2021-03-18 Thread Bhaskar Chowdhury


s/recalcultion/recalculation/

Signed-off-by: Bhaskar Chowdhury 
---
 include/net/red.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/red.h b/include/net/red.h
index 932f0d79d60c..6b418b69dc48 100644
--- a/include/net/red.h
+++ b/include/net/red.h
@@ -287,7 +287,7 @@ static inline unsigned long 
red_calc_qavg_from_idle_time(const struct red_parms
int  shift;

/*
-* The problem: ideally, average length queue recalcultion should
+* The problem: ideally, average length queue recalculation should
 * be done over constant clock intervals. This is too expensive, so
 * that the calculation is driven by outgoing packets.
 * When the queue is idle we have to model this clock by hand.
--
2.26.2



RE: [PATCH 03/11] i2c: imx-lpi2c: add ipg clk for lpi2c driver

2021-03-18 Thread Aisheng Dong
> From: Clark Wang 
> Sent: Wednesday, March 17, 2021 2:54 PM
> 
> The lpi2c IP needs two clks: ipg clk and per clk. The old lpi2c driver missed 
> ipg
> clk. This patch adds ipg clk for lpi2c driver.
> 

Pleas also update dt-binding and sent along with this patchset.(before this one)

> Signed-off-by: Gao Pan 
> Signed-off-by: Clark Wang 
> Acked-by: Fugang Duan 

You can drop the Ack tag if the patch was changed 

> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 1e920e7ac7c1..664fcc0dba51 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -94,7 +94,8 @@ enum lpi2c_imx_pincfg {
> 
>  struct lpi2c_imx_struct {
>   struct i2c_adapter  adapter;
> - struct clk  *clk;
> + struct clk  *clk_per;
> + struct clk  *clk_ipg;
>   void __iomem*base;
>   __u8*rx_buf;
>   __u8*tx_buf;
> @@ -563,10 +564,16 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev)
>   strlcpy(lpi2c_imx->adapter.name, pdev->name,
>   sizeof(lpi2c_imx->adapter.name));
> 
> - lpi2c_imx->clk = devm_clk_get(>dev, NULL);
> - if (IS_ERR(lpi2c_imx->clk)) {
> + lpi2c_imx->clk_per = devm_clk_get(>dev, "per");
> + if (IS_ERR(lpi2c_imx->clk_per)) {
>   dev_err(>dev, "can't get I2C peripheral clock\n");
> - return PTR_ERR(lpi2c_imx->clk);
> + return PTR_ERR(lpi2c_imx->clk_per);
> + }
> +
> + lpi2c_imx->clk_ipg = devm_clk_get(>dev, "ipg");
> + if (IS_ERR(lpi2c_imx->clk_ipg)) {
> + dev_err(>dev, "can't get I2C ipg clock\n");
> + return PTR_ERR(lpi2c_imx->clk_ipg);
>   }

Will this break exist dts?

Regards
Aisheng

> 
>   ret = of_property_read_u32(pdev->dev.of_node,
> @@ -633,7 +640,8 @@ static int __maybe_unused
> lpi2c_runtime_suspend(struct device *dev)  {
>   struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
> 
> - clk_disable_unprepare(lpi2c_imx->clk);
> + clk_disable_unprepare(lpi2c_imx->clk_ipg);
> + clk_disable_unprepare(lpi2c_imx->clk_per);
>   pinctrl_pm_select_idle_state(dev);
> 
>   return 0;
> @@ -645,12 +653,18 @@ static int __maybe_unused
> lpi2c_runtime_resume(struct device *dev)
>   int ret;
> 
>   pinctrl_pm_select_default_state(dev);
> - ret = clk_prepare_enable(lpi2c_imx->clk);
> + ret = clk_prepare_enable(lpi2c_imx->clk_per);
>   if (ret) {
> - dev_err(dev, "can't enable I2C clock, ret=%d\n", ret);
> + dev_err(dev, "can't enable I2C per clock, ret=%d\n", ret);
>   return ret;
>   }
> 
> + ret = clk_prepare_enable(lpi2c_imx->clk_ipg);
> + if (ret) {
> + clk_disable_unprepare(lpi2c_imx->clk_per);
> + dev_err(dev, "can't enable I2C ipg clock, ret=%d\n", ret);
> + }
> +
>   return ret;
>  }
> 
> --
> 2.25.1



Re: [PATCH] PCI: keystone: Let AM65 use the pci_ops defined in pcie-designware-host.c

2021-03-18 Thread Krzysztof Wilczyński
Hi Kishon,

Thank you for the fix!

[...]
> @@ -798,7 +798,8 @@ static int __init ks_pcie_host_init(struct pcie_port *pp)
>   int ret;
>  
>   pp->bridge->ops = _pcie_ops;
> - pp->bridge->child_ops = _child_pcie_ops;
> + if (!ks_pcie->is_am6)
> + pp->bridge->child_ops = _child_pcie_ops;
>  
>   ret = ks_pcie_config_legacy_irq(ks_pcie);
>   if (ret)
[...]

Reviewed-by: Krzysztof Wilczyński 

Krzysztof


Re: [PATCH] cifsd: fix a precedence bug in parse_dacl()

2021-03-18 Thread Sergey Senozhatsky
On (21/03/18 16:10), Dan Carpenter wrote:
> 
> The shift has higher precedence than mask so this doesn't work as
> intended.
> 
> Fixes: ef24dca82789 ("cifsd: add support for ACLs")
> Signed-off-by: Dan Carpenter 

Thanks.

Reviewed-by: Sergey Senozhatsky 

-ss


Re: [PATCH RESEND] cifsd: fix a IS_ERR() vs NULL bug

2021-03-18 Thread Sergey Senozhatsky
On (21/03/18 16:11), Dan Carpenter wrote:
> 
> The smb_direct_alloc_sendmsg() function never returns NULL, it only
> returns error pointers so the check needs to be updated.
> 
> Fixes: cabcebc31de4 ("cifsd: introduce SMB3 kernel server")
> Signed-off-by: Dan Carpenter 

Thanks.

Reviewed-by: Sergey Senozhatsky 

-ss


Re: [PATCH v2 5/6] PCI: fu740: Add SiFive FU740 PCIe host controller driver

2021-03-18 Thread Krzysztof Wilczyński
Hi,

[...]
> > +   /* Wait for wait_idle */
> > +   ret = readl_poll_timeout(phy_cr_para_ack, val, val, 10, 5000);
> > +   if (ret)
> > +   dev_err(dev, "Wait for wait_ilde state failed!\n");
> 
> It would be "wait_idle" rather than "wait_idle".
[...]

Apologies, meant to say "wait_ilde" in the "rather than" part, but went
ahead and somehow used the correct spelling. :)

Krzysztof


Re: [PATCH] cifsd: Fix a use after free on error path

2021-03-18 Thread Sergey Senozhatsky
On (21/03/18 16:12), Dan Carpenter wrote:
> The ksmbd_free_work_struct() frees "work" so we need to swap the order
> of these two function calls to avoid a use after free.
> 
> Fixes: cabcebc31de4 ("cifsd: introduce SMB3 kernel server")
> Signed-off-by: Dan Carpenter 

Thanks.

Reviewed-by: Sergey Senozhatsky 

-ss


RE: [PATCH 02/11] i2c: imx-lpi2c: add runtime pm support

2021-03-18 Thread Aisheng Dong
> From: Clark Wang 
> Sent: Wednesday, March 17, 2021 2:54 PM
> Subject: [PATCH 02/11] i2c: imx-lpi2c: add runtime pm support
> 
> - Add runtime pm support to dynamicly manage the clock.
> - Put the suspend to suspend_noirq.
> - Call .pm_runtime_force_suspend() to force runtime pm suspended
>   in .suspend_noirq().
> 

The patch title needs to be improved as the driver already supports rpm.
And do one thing in one patch.

> Signed-off-by: Fugang Duan 
> Signed-off-by: Gao Pan 
> Reviewed-by: Anson Huang 

Please add your sign-off.

> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 50 --
>  1 file changed, 33 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index bbf44ac95021..1e920e7ac7c1 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -574,7 +574,8 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev)
>   if (ret)
>   lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
> 
> - ret = devm_request_irq(>dev, irq, lpi2c_imx_isr, 0,
> + ret = devm_request_irq(>dev, irq, lpi2c_imx_isr,
> +IRQF_NO_SUSPEND,

This belongs to a separate patch

>  pdev->name, lpi2c_imx);
>   if (ret) {
>   dev_err(>dev, "can't claim irq %d\n", irq); @@ -584,35
> +585,32 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
>   i2c_set_adapdata(_imx->adapter, lpi2c_imx);
>   platform_set_drvdata(pdev, lpi2c_imx);
> 
> - ret = clk_prepare_enable(lpi2c_imx->clk);
> - if (ret) {
> - dev_err(>dev, "clk enable failed %d\n", ret);
> - return ret;
> - }
> -
>   pm_runtime_set_autosuspend_delay(>dev, I2C_PM_TIMEOUT);
>   pm_runtime_use_autosuspend(>dev);
> - pm_runtime_get_noresume(>dev);
> - pm_runtime_set_active(>dev);
>   pm_runtime_enable(>dev);
> 
> + ret = pm_runtime_get_sync(>dev);
> + if (ret < 0) {
> + pm_runtime_put_noidle(>dev);
> + dev_err(>dev, "failed to enable clock\n");
> + return ret;
> + }

Can't current clk control via rpm work well?
Please describe why need change.

> +
>   temp = readl(lpi2c_imx->base + LPI2C_PARAM);
>   lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
>   lpi2c_imx->rxfifosize = 1 << ((temp >> 8) & 0x0f);
> 
> + pm_runtime_put(>dev);
> +
>   ret = i2c_add_adapter(_imx->adapter);
>   if (ret)
>   goto rpm_disable;
> 
> - pm_runtime_mark_last_busy(>dev);
> - pm_runtime_put_autosuspend(>dev);
> -
>   dev_info(_imx->adapter.dev, "LPI2C adapter registered\n");
> 
>   return 0;
> 
>  rpm_disable:
> - pm_runtime_put(>dev);
>   pm_runtime_disable(>dev);
>   pm_runtime_dont_use_autosuspend(>dev);
> 
> @@ -636,7 +634,7 @@ static int __maybe_unused
> lpi2c_runtime_suspend(struct device *dev)
>   struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
> 
>   clk_disable_unprepare(lpi2c_imx->clk);
> - pinctrl_pm_select_sleep_state(dev);
> + pinctrl_pm_select_idle_state(dev);

This belongs to a separate patch

> 
>   return 0;
>  }
> @@ -649,16 +647,34 @@ static int __maybe_unused
> lpi2c_runtime_resume(struct device *dev)
>   pinctrl_pm_select_default_state(dev);
>   ret = clk_prepare_enable(lpi2c_imx->clk);
>   if (ret) {
> - dev_err(dev, "failed to enable I2C clock, ret=%d\n", ret);
> + dev_err(dev, "can't enable I2C clock, ret=%d\n", ret);

Probably unnecessary change

>   return ret;
>   }
> 
> + return ret;
> +}
> +
> +static int lpi2c_suspend_noirq(struct device *dev) {
> + int ret;
> +
> + ret = pm_runtime_force_suspend(dev);
> + if (ret)
> + return ret;
> +
> + pinctrl_pm_select_sleep_state(dev);
> +
>   return 0;
>  }
> 
> +static int lpi2c_resume_noirq(struct device *dev) {
> + return pm_runtime_force_resume(dev);
> +}
> +
>  static const struct dev_pm_ops lpi2c_pm_ops = {
> - SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> -   pm_runtime_force_resume)
> + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(lpi2c_suspend_noirq,
> +  lpi2c_resume_noirq)

Belongs to separate change and explain why need do this

>   SET_RUNTIME_PM_OPS(lpi2c_runtime_suspend,
>  lpi2c_runtime_resume, NULL)
>  };
> --
> 2.25.1



[PATCH] drm: i915: Fix a typo

2021-03-18 Thread Bhaskar Chowdhury


s/nothign/nothing/

Signed-off-by: Bhaskar Chowdhury 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index f6ad257a260e..14d784a6fae5 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -4185,7 +4185,7 @@ static void icl_pll_disable(struct drm_i915_private 
*dev_priv,
/*
 * DVFS pre sequence would be here, but in our driver the cdclk code
 * paths should already be setting the appropriate voltage, hence we do
-* nothign here.
+* nothing here.
 */

val = intel_de_read(dev_priv, enable_reg);
--
2.26.2



Re: [PATCH v2 5/6] PCI: fu740: Add SiFive FU740 PCIe host controller driver

2021-03-18 Thread Krzysztof Wilczyński
Hi,

[...]
> +static void fu740_phyregwrite(const uint8_t phy, const uint16_t addr,
> +   const uint16_t wrdata, struct fu740_pcie *afp)
> +{
> + struct device *dev = afp->pci.dev;
> + void __iomem *phy_cr_para_addr;
> + void __iomem *phy_cr_para_wr_data;
> + void __iomem *phy_cr_para_wr_en;
> + void __iomem *phy_cr_para_ack;
> + int ret, val;
> +
> + /* Setup */
> + if (phy) {
> + phy_cr_para_addr = afp->mgmt_base + 
> PCIEX8MGMT_PHY1_CR_PARA_ADDR;
> + phy_cr_para_wr_data = afp->mgmt_base + 
> PCIEX8MGMT_PHY1_CR_PARA_WR_DATA;
> + phy_cr_para_wr_en = afp->mgmt_base + 
> PCIEX8MGMT_PHY1_CR_PARA_WR_EN;
> + phy_cr_para_ack = afp->mgmt_base + PCIEX8MGMT_PHY1_CR_PARA_ACK;
> + } else {
> + phy_cr_para_addr = afp->mgmt_base + 
> PCIEX8MGMT_PHY0_CR_PARA_ADDR;
> + phy_cr_para_wr_data = afp->mgmt_base + 
> PCIEX8MGMT_PHY0_CR_PARA_WR_DATA;
> + phy_cr_para_wr_en = afp->mgmt_base + 
> PCIEX8MGMT_PHY0_CR_PARA_WR_EN;
> + phy_cr_para_ack = afp->mgmt_base + PCIEX8MGMT_PHY0_CR_PARA_ACK;
> + }
> +
> + writel_relaxed(addr, phy_cr_para_addr);
> + writel_relaxed(wrdata, phy_cr_para_wr_data);
> + writel_relaxed(1, phy_cr_para_wr_en);
> +
> + /* Wait for wait_idle */
> + ret = readl_poll_timeout(phy_cr_para_ack, val, val, 10, 5000);
> + if (ret)
> + dev_err(dev, "Wait for wait_ilde state failed!\n");

It would be "wait_idle" rather than "wait_idle".

[...]
> + /* Wait for ~wait_idle */
> + ret = readl_poll_timeout(phy_cr_para_ack, val, !val, 10, 5000);
> + if (ret)
> + dev_err(dev, "Wait for !wait_ilde state failed!\n");
[...]

Same as above, it would be "wait_idle" in the above.

> +static void fu740_pcie_ltssm_enable(struct device *dev)
> +{
> + struct fu740_pcie *afp = dev_get_drvdata(dev);
> +
> + /* Enable LTSSM */
> + writel_relaxed(0x1, afp->mgmt_base + PCIEX8MGMT_APP_LTSSM_ENABLE);
> +}
> +
> +static int fu740_pcie_start_link(struct dw_pcie *pci)
> +{
> + struct device *dev = pci->dev;
> +
> + /* Start LTSSM. */

Nitpick.  No need for a dot in this comment to keep it consistent with
the comment in the function above this one.

> +static int fu740_pcie_host_init(struct pcie_port *pp)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct fu740_pcie *afp = to_fu740_pcie(pci);
> + struct device *dev = pci->dev;
> + int ret;
> +
> + /* Power on reset */
> + fu740_pcie_drive_perstn(afp);
> +
> + /* Enable pcieauxclk */
> + ret = clk_prepare_enable(afp->pcie_aux);
> + if (ret)
> + dev_err(dev, "unable to enable pcie_aux clock\n");
> +
> + /*
> +  * Assert hold_phy_rst (hold the controller LTSSM in reset after
> +  * power_up_rst_n for register programming with cr_para)
> +  */
> + writel_relaxed(0x1, afp->mgmt_base + PCIEX8MGMT_APP_HOLD_PHY_RST);
> +
> + /* Deassert power_up_rst_n */
> + ret = reset_control_deassert(afp->rst);
> + if (ret)
> + dev_err(dev, "unable to deassert pcie_power_up_rst_n\n");
> +
> + fu740_pcie_init_phy(afp);
> +
> + /* Disable pcieauxclk */
> + clk_disable_unprepare(afp->pcie_aux);
> + /* Clear hold_phy_rst */
> + writel_relaxed(0x0, afp->mgmt_base + PCIEX8MGMT_APP_HOLD_PHY_RST);
> + /* Enable pcieauxclk */
> + ret = clk_prepare_enable(afp->pcie_aux);
> + /* Set RC mode */
> + writel_relaxed(0x4, afp->mgmt_base + PCIEX8MGMT_DEVICE_TYPE);
> +
> + return 0;
> +}
[...]

It seems that the error handling is somewhat broken in the above
function, especially when you look at how the "ret" variables does not
seem to be used for anything once there was an error.

Krzysztof


[PATCH net-next 1/4] net: ipa: fix init header command validation

2021-03-18 Thread Alex Elder
We use ipa_cmd_header_valid() to ensure certain values we will
program into hardware are within range, well in advance of when we
actually program them.  This way we avoid having to check for errors
when we actually program the hardware.

Unfortunately the dev_err() call for a bad offset value does not
supply the arguments to match the format specifiers properly.
Fix this.

There was also supposed to be a check to ensure the size to be
programmed fits in the field that holds it.  Add this missing check.

Rearrange the way we ensure the header table fits in overall IPA
memory range.

Signed-off-by: Alex Elder 
---
 drivers/net/ipa/ipa_cmd.c | 49 +--
 1 file changed, 32 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ipa/ipa_cmd.c b/drivers/net/ipa/ipa_cmd.c
index 35e35852c25c5..b40f031a905a7 100644
--- a/drivers/net/ipa/ipa_cmd.c
+++ b/drivers/net/ipa/ipa_cmd.c
@@ -175,21 +175,23 @@ bool ipa_cmd_table_valid(struct ipa *ipa, const struct 
ipa_mem *mem,
: field_max(IP_FLTRT_FLAGS_NHASH_ADDR_FMASK);
if (mem->offset > offset_max ||
ipa->mem_offset > offset_max - mem->offset) {
-   dev_err(dev, "IPv%c %s%s table region offset too large "
- "(0x%04x + 0x%04x > 0x%04x)\n",
- ipv6 ? '6' : '4', hashed ? "hashed " : "",
- route ? "route" : "filter",
- ipa->mem_offset, mem->offset, offset_max);
+   dev_err(dev, "IPv%c %s%s table region offset too large\n",
+   ipv6 ? '6' : '4', hashed ? "hashed " : "",
+   route ? "route" : "filter");
+   dev_err(dev, "(0x%04x + 0x%04x > 0x%04x)\n",
+   ipa->mem_offset, mem->offset, offset_max);
+
return false;
}
 
if (mem->offset > ipa->mem_size ||
mem->size > ipa->mem_size - mem->offset) {
-   dev_err(dev, "IPv%c %s%s table region out of range "
- "(0x%04x + 0x%04x > 0x%04x)\n",
- ipv6 ? '6' : '4', hashed ? "hashed " : "",
- route ? "route" : "filter",
- mem->offset, mem->size, ipa->mem_size);
+   dev_err(dev, "IPv%c %s%s table region out of range\n",
+   ipv6 ? '6' : '4', hashed ? "hashed " : "",
+   route ? "route" : "filter");
+   dev_err(dev, "(0x%04x + 0x%04x > 0x%04x)\n",
+   mem->offset, mem->size, ipa->mem_size);
+
return false;
}
 
@@ -205,22 +207,35 @@ static bool ipa_cmd_header_valid(struct ipa *ipa)
u32 size_max;
u32 size;
 
+   /* In ipa_cmd_hdr_init_local_add() we record the offset and size
+* of the header table memory area.  Make sure the offset and size
+* fit in the fields that need to hold them, and that the entire
+* range is within the overall IPA memory range.
+*/
offset_max = field_max(HDR_INIT_LOCAL_FLAGS_HDR_ADDR_FMASK);
if (mem->offset > offset_max ||
ipa->mem_offset > offset_max - mem->offset) {
-   dev_err(dev, "header table region offset too large "
- "(0x%04x + 0x%04x > 0x%04x)\n",
- ipa->mem_offset + mem->offset, offset_max);
+   dev_err(dev, "header table region offset too large\n");
+   dev_err(dev, "(0x%04x + 0x%04x > 0x%04x)\n",
+   ipa->mem_offset, mem->offset, offset_max);
+
return false;
}
 
size_max = field_max(HDR_INIT_LOCAL_FLAGS_TABLE_SIZE_FMASK);
size = ipa->mem[IPA_MEM_MODEM_HEADER].size;
size += ipa->mem[IPA_MEM_AP_HEADER].size;
-   if (mem->offset > ipa->mem_size || size > ipa->mem_size - mem->offset) {
-   dev_err(dev, "header table region out of range "
- "(0x%04x + 0x%04x > 0x%04x)\n",
- mem->offset, size, ipa->mem_size);
+   if (size > size_max) {
+   dev_err(dev, "header table region too large\n");
+   dev_err(dev, "(0x%04x > 0x%04x)\n", size, size_max);
+
+   return false;
+   }
+   if (size > ipa->mem_size || mem->offset > ipa->mem_size - size) {
+   dev_err(dev, "header table region out of range\n");
+   dev_err(dev, "(0x%04x + 0x%04x > 0x%04x)\n",
+   mem->offset, size, ipa->mem_size);
+
return false;
}
 
-- 
2.27.0



[PATCH net-next 4/4] net: ipa: activate some commented assertions

2021-03-18 Thread Alex Elder
Convert some commented assertion statements into real calls to
ipa_assert().  If the IPA device pointer is available, provide it,
otherwise pass NULL for that.

There are lots more places to convert, but this serves as an initial
verification of the new mechanism.  The assertions here implement
both runtime and build-time assertions, both with and without the
device pointer.

Signed-off-by: Alex Elder 
---
 drivers/net/ipa/ipa_reg.h   | 7 ---
 drivers/net/ipa/ipa_table.c | 5 -
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ipa/ipa_reg.h b/drivers/net/ipa/ipa_reg.h
index 732e691e9aa62..d0de85de9f08d 100644
--- a/drivers/net/ipa/ipa_reg.h
+++ b/drivers/net/ipa/ipa_reg.h
@@ -9,6 +9,7 @@
 #include 
 
 #include "ipa_version.h"
+#include "ipa_assert.h"
 
 struct ipa;
 
@@ -212,7 +213,7 @@ static inline u32 ipa_reg_bcr_val(enum ipa_version version)
BCR_HOLB_DROP_L2_IRQ_FMASK |
BCR_DUAL_TX_FMASK;
 
-   /* assert(version != IPA_VERSION_4_5); */
+   ipa_assert(NULL, version != IPA_VERSION_4_5);
 
return 0x;
 }
@@ -413,7 +414,7 @@ static inline u32 ipa_header_size_encoded(enum ipa_version 
version,
 
val = u32_encode_bits(size, HDR_LEN_FMASK);
if (version < IPA_VERSION_4_5) {
-   /* ipa_assert(header_size == size); */
+   ipa_assert(NULL, header_size == size);
return val;
}
 
@@ -433,7 +434,7 @@ static inline u32 ipa_metadata_offset_encoded(enum 
ipa_version version,
 
val = u32_encode_bits(off, HDR_OFST_METADATA_FMASK);
if (version < IPA_VERSION_4_5) {
-   /* ipa_assert(offset == off); */
+   ipa_assert(NULL, offset == off);
return val;
}
 
diff --git a/drivers/net/ipa/ipa_table.c b/drivers/net/ipa/ipa_table.c
index aa8b3ce7e21d9..7784b42fbaccc 100644
--- a/drivers/net/ipa/ipa_table.c
+++ b/drivers/net/ipa/ipa_table.c
@@ -23,6 +23,7 @@
 #include "ipa_cmd.h"
 #include "gsi.h"
 #include "gsi_trans.h"
+#include "ipa_assert.h"
 
 /**
  * DOC: IPA Filter and Route Tables
@@ -237,11 +238,13 @@ static void ipa_table_validate_build(void)
 static dma_addr_t ipa_table_addr(struct ipa *ipa, bool filter_mask, u16 count)
 {
u32 skip;
+   u32 max;
 
if (!count)
return 0;
 
-/* assert(count <= max_t(u32, IPA_FILTER_COUNT_MAX, IPA_ROUTE_COUNT_MAX)); */
+   max = max_t(u32, IPA_FILTER_COUNT_MAX, IPA_ROUTE_COUNT_MAX);
+   ipa_assert(>pdev->dev, max);
 
/* Skip over the zero rule and possibly the filter mask */
skip = filter_mask ? 1 : 2;
-- 
2.27.0



[PATCH net-next 2/4] net: ipa: fix IPA validation

2021-03-18 Thread Alex Elder
There are blocks of IPA code that sanity-check various values, at
compile time where possible.  Most of these checks can be done once
during development but skipped for normal operation.  These checks
permit the driver to make certain assumptions, thereby avoiding the
need for runtime error checking.

The checks are defined conditionally, but not consistently.  In
some cases IPA_VALIDATION enables the optional checks, while in
others IPA_VALIDATE is used.

Fix this by using IPA_VALIDATION consistently.

Signed-off-by: Alex Elder 
---
 drivers/net/ipa/Makefile   | 2 +-
 drivers/net/ipa/gsi_trans.c| 8 
 drivers/net/ipa/ipa_cmd.c  | 4 ++--
 drivers/net/ipa/ipa_cmd.h  | 6 +++---
 drivers/net/ipa/ipa_endpoint.c | 6 +++---
 drivers/net/ipa/ipa_main.c | 6 +++---
 drivers/net/ipa/ipa_mem.c  | 6 +++---
 drivers/net/ipa/ipa_table.c| 6 +++---
 drivers/net/ipa/ipa_table.h| 6 +++---
 9 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/net/ipa/Makefile b/drivers/net/ipa/Makefile
index afe5df1e6..014ae36ac6004 100644
--- a/drivers/net/ipa/Makefile
+++ b/drivers/net/ipa/Makefile
@@ -1,5 +1,5 @@
 # Un-comment the next line if you want to validate configuration data
-#ccflags-y +=  -DIPA_VALIDATE
+# ccflags-y+=  -DIPA_VALIDATION
 
 obj-$(CONFIG_QCOM_IPA) +=  ipa.o
 
diff --git a/drivers/net/ipa/gsi_trans.c b/drivers/net/ipa/gsi_trans.c
index 6c3ed5b17b80c..284063b39b33c 100644
--- a/drivers/net/ipa/gsi_trans.c
+++ b/drivers/net/ipa/gsi_trans.c
@@ -90,14 +90,14 @@ int gsi_trans_pool_init(struct gsi_trans_pool *pool, size_t 
size, u32 count,
 {
void *virt;
 
-#ifdef IPA_VALIDATE
+#ifdef IPA_VALIDATION
if (!size || size % 8)
return -EINVAL;
if (count < max_alloc)
return -EINVAL;
if (!max_alloc)
return -EINVAL;
-#endif /* IPA_VALIDATE */
+#endif /* IPA_VALIDATION */
 
/* By allocating a few extra entries in our pool (one less
 * than the maximum number that will be requested in a
@@ -140,14 +140,14 @@ int gsi_trans_pool_init_dma(struct device *dev, struct 
gsi_trans_pool *pool,
dma_addr_t addr;
void *virt;
 
-#ifdef IPA_VALIDATE
+#ifdef IPA_VALIDATION
if (!size || size % 8)
return -EINVAL;
if (count < max_alloc)
return -EINVAL;
if (!max_alloc)
return -EINVAL;
-#endif /* IPA_VALIDATE */
+#endif /* IPA_VALIDATION */
 
/* Don't let allocations cross a power-of-two boundary */
size = __roundup_pow_of_two(size);
diff --git a/drivers/net/ipa/ipa_cmd.c b/drivers/net/ipa/ipa_cmd.c
index b40f031a905a7..87e1ca2e27106 100644
--- a/drivers/net/ipa/ipa_cmd.c
+++ b/drivers/net/ipa/ipa_cmd.c
@@ -162,7 +162,7 @@ static void ipa_cmd_validate_build(void)
 #undef TABLE_SIZE
 }
 
-#ifdef IPA_VALIDATE
+#ifdef IPA_VALIDATION
 
 /* Validate a memory region holding a table */
 bool ipa_cmd_table_valid(struct ipa *ipa, const struct ipa_mem *mem,
@@ -316,7 +316,7 @@ bool ipa_cmd_data_valid(struct ipa *ipa)
return true;
 }
 
-#endif /* IPA_VALIDATE */
+#endif /* IPA_VALIDATION */
 
 int ipa_cmd_pool_init(struct gsi_channel *channel, u32 tre_max)
 {
diff --git a/drivers/net/ipa/ipa_cmd.h b/drivers/net/ipa/ipa_cmd.h
index 6dd3d35cf315d..429245f075122 100644
--- a/drivers/net/ipa/ipa_cmd.h
+++ b/drivers/net/ipa/ipa_cmd.h
@@ -50,7 +50,7 @@ struct ipa_cmd_info {
enum dma_data_direction direction;
 };
 
-#ifdef IPA_VALIDATE
+#ifdef IPA_VALIDATION
 
 /**
  * ipa_cmd_table_valid() - Validate a memory region holding a table
@@ -73,7 +73,7 @@ bool ipa_cmd_table_valid(struct ipa *ipa, const struct 
ipa_mem *mem,
  */
 bool ipa_cmd_data_valid(struct ipa *ipa);
 
-#else /* !IPA_VALIDATE */
+#else /* !IPA_VALIDATION */
 
 static inline bool ipa_cmd_table_valid(struct ipa *ipa,
   const struct ipa_mem *mem, bool route,
@@ -87,7 +87,7 @@ static inline bool ipa_cmd_data_valid(struct ipa *ipa)
return true;
 }
 
-#endif /* !IPA_VALIDATE */
+#endif /* !IPA_VALIDATION */
 
 /**
  * ipa_cmd_pool_init() - initialize command channel pools
diff --git a/drivers/net/ipa/ipa_endpoint.c b/drivers/net/ipa/ipa_endpoint.c
index 7209ee3c31244..1a4de4e9eafcd 100644
--- a/drivers/net/ipa/ipa_endpoint.c
+++ b/drivers/net/ipa/ipa_endpoint.c
@@ -75,7 +75,7 @@ struct ipa_status {
 #define IPA_STATUS_FLAGS1_RT_RULE_ID_FMASK GENMASK(31, 22)
 #define IPA_STATUS_FLAGS2_TAG_FMASKGENMASK_ULL(63, 16)
 
-#ifdef IPA_VALIDATE
+#ifdef IPA_VALIDATION
 
 static bool ipa_endpoint_data_valid_one(struct ipa *ipa, u32 count,
const struct ipa_gsi_endpoint_data *all_data,
@@ -225,7 +225,7 @@ static bool ipa_endpoint_data_valid(struct ipa *ipa, u32 
count,
return true;
 }
 
-#else /* !IPA_VALIDATE */
+#else /* !IPA_VALIDATION */
 
 static bool ipa_endpoint_data_valid(struct ipa *ipa, u32 count,

[PATCH net-next 3/4] net: ipa: introduce ipa_assert()

2021-03-18 Thread Alex Elder
Create a new macro ipa_assert() to verify that a condition is true.
This produces a build-time error if the condition can be evaluated
at build time; otherwise __ipa_assert_runtime() is called (described
below).

Another macro, ipa_assert_always() verifies that an expression
yields true at runtime, and if it does not, reports an error
message.

When IPA validation is enabled, __ipa_assert_runtime() becomes a
call to ipa_assert_always(), resulting in runtime verification of
the asserted condition.  Otherwise __ipa_assert_runtime() has no
effect, so such ipa_assert() calls are effectively ignored.

IPA assertion errors will be reported using the IPA device if
possible.

Signed-off-by: Alex Elder 
---
 drivers/net/ipa/ipa_assert.h | 50 
 1 file changed, 50 insertions(+)
 create mode 100644 drivers/net/ipa/ipa_assert.h

diff --git a/drivers/net/ipa/ipa_assert.h b/drivers/net/ipa/ipa_assert.h
new file mode 100644
index 0..7e5b9d487f69d
--- /dev/null
+++ b/drivers/net/ipa/ipa_assert.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2021 Linaro Ltd.
+ */
+#ifndef _IPA_ASSERT_H_
+#define _IPA_ASSERT_H_
+
+#include 
+#include 
+#include 
+
+/* Verify the expression yields true, and fail at build time if possible */
+#define ipa_assert(dev, expr) \
+   do { \
+   if (__builtin_constant_p(expr)) \
+   compiletime_assert(expr, __ipa_failure_msg(expr)); \
+   else \
+   __ipa_assert_runtime(dev, expr); \
+   } while (0)
+
+/* Report an error if the given expression evaluates to false at runtime */
+#define ipa_assert_always(dev, expr) \
+   do { \
+   if (unlikely(!(expr))) { \
+   struct device *__dev = (dev); \
+   \
+   if (__dev) \
+   dev_err(__dev, __ipa_failure_msg(expr)); \
+   else  \
+   pr_err(__ipa_failure_msg(expr)); \
+   } \
+   } while (0)
+
+/* Constant message used when an assertion fails */
+#define __ipa_failure_msg(expr)"IPA assertion failed: " #expr "\n"
+
+#ifdef IPA_VALIDATION
+
+/* Only do runtime checks for "normal" assertions if validating the code */
+#define __ipa_assert_runtime(dev, expr)ipa_assert_always(dev, expr)
+
+#else /* !IPA_VALIDATION */
+
+/* "Normal" assertions aren't checked when validation is disabled */
+#define __ipa_assert_runtime(dev, expr)\
+   do { (void)(dev); (void)(expr); } while (0)
+
+#endif /* !IPA_VALIDATION */
+
+#endif /* _IPA_ASSERT_H_ */
-- 
2.27.0



[PATCH net-next 0/4] net: ipa: fix validation

2021-03-18 Thread Alex Elder
There is sanity checking code in the IPA driver that's meant to be
enabled only during development.  This allows the driver to make
certain assumptions, but not have to verify those assumptions are
true at (operational) runtime.  This code is built conditional on
IPA_VALIDATION, set (if desired) inside the IPA makefile.

Unfortunately, this validation code has some errors.  First, there
are some mismatched arguments supplied to some dev_err() calls in
ipa_cmd_table_valid() and ipa_cmd_header_valid(), and these are
exposed if validation is enabled.  Second, the tag that enables
this conditional code isn't used consistently (it's IPA_VALIDATE
in some spots and IPA_VALIDATION in others).

This series fixes those two problems with the conditional validation
code.

In addition, this series introduces some new assertion macros.  I
have been meaning to add this for a long time.  There are comments
indicating places where assertions could be checked throughout the
code.

The macros are designed so that any asserted condition will be
checked at compile time if possible.  Otherwise, the condition
will be checked at runtime *only* if IPA_VALIDATION is enabled,
and ignored otherwise.

NOTE:  The third patch produces two bogus (but understandable)
warnings from checkpatch.pl.  It does not recognize that the "expr"
argument passed to those macros aren't actually evaluated more than
once.  In both cases, all but one reference is consumed by the
preprocessor or compiler.

A final patch converts a handful of commented assertions into
"real" ones.  Some existing validation code can done more simply
with assertions, so over time such cases will be converted.  For
now though, this series adds this assertion capability.

-Alex

Alex Elder (4):
  net: ipa: fix init header command validation
  net: ipa: fix IPA validation
  net: ipa: introduce ipa_assert()
  net: ipa: activate some commented assertions

 drivers/net/ipa/Makefile   |  2 +-
 drivers/net/ipa/gsi_trans.c|  8 ++---
 drivers/net/ipa/ipa_assert.h   | 50 
 drivers/net/ipa/ipa_cmd.c  | 53 ++
 drivers/net/ipa/ipa_cmd.h  |  6 ++--
 drivers/net/ipa/ipa_endpoint.c |  6 ++--
 drivers/net/ipa/ipa_main.c |  6 ++--
 drivers/net/ipa/ipa_mem.c  |  6 ++--
 drivers/net/ipa/ipa_reg.h  |  7 +++--
 drivers/net/ipa/ipa_table.c| 11 ---
 drivers/net/ipa/ipa_table.h|  6 ++--
 11 files changed, 115 insertions(+), 46 deletions(-)
 create mode 100644 drivers/net/ipa/ipa_assert.h

-- 
2.27.0



Re: [PATCH v3 9/9] dt-bindings: serial: stm32: add phandle 'bluetooth' to fix dtbs_check warrning

2021-03-18 Thread dillon min
No changes, Just loop lkp in.


Hi lkp,

Sorry for the late reply, thanks for your report.
This patch is to fix the build warning message.

Thanks.
Regards

On Mon, Mar 15, 2021 at 5:45 PM  wrote:
>
> From: dillon min 
>
> when run make dtbs_check with 'bluetoothi brcm,bcm43438-bt'
> dts enabled on stm32h7, there is a warrning popup:
>
> >> arch/arm/boot/dts/stm32h750i-art-pi.dt.yaml: serial@40004800: 'bluetooth'
>does not match any of the regexes: 'pinctrl-[0-9]+'
>
> to make dtbs_check happy, so add a phandle bluetooth
>
> Fixes: 500cdb23d608 ("ARM: dts: stm32: Add STM32H743 MCU and STM32H743i-EVAL 
> board")
> Signed-off-by: dillon min 
> Reported-by: kernel test robot 
> ---
>  Documentation/devicetree/bindings/serial/st,stm32-uart.yaml | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml 
> b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> index 8631678283f9..5e674840e62d 100644
> --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> @@ -50,6 +50,11 @@ properties:
>  minItems: 1
>  maxItems: 2
>
> +  bluetooth:
> +type: object
> +description: |
> +  phandles to the usart controller and bluetooth
> +
>  # cts-gpios and rts-gpios properties can be used instead of 'uart-has-rtscts'
>  # or 'st,hw-flow-ctrl' (deprecated) for making use of any gpio pins for flow
>  # control instead of dedicated pins.
> --
> 1.9.1
>


Re: [PATCH v6 3/3] arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems

2021-03-18 Thread Kishon Vijay Abraham I
Hi Aswath,

On 19/03/21 9:14 am, Aswath Govindraju wrote:
> The following speed modes are now supported in J7200 SoC,
> - HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1].
> - UHS-I speed modes in MMCSD1 subsystem [1].
> 
> Add support for UHS-I modes by adding voltage regulator device tree nodes
> and corresponding pinmux details, to power cycle and voltage switch cards.
> Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1
> device tree nodes.
> 
> Also update the delay values for various speed modes supported, based on
> the revised january 2021 J7200 datasheet[2].
> 
> [1] - section 12.3.6.1.1 MMCSD Features, in
>   https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf,
>   (SPRUIU1A – JULY 2020 – REVISED JANUARY 2021)
> 
> [2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf,
>   (SPRSP57B – APRIL 2020 – REVISED JANUARY 2021)

Thanks for fixing the link.

Reviewed-by: Kishon Vijay Abraham I 
> 
> Signed-off-by: Aswath Govindraju 
> ---
>  .../dts/ti/k3-j7200-common-proc-board.dts | 42 +++
>  arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 14 ++-
>  2 files changed, 54 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts 
> b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> index b493f939b09a..6f90c3b1cf45 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> @@ -16,6 +16,29 @@
>   stdout-path = "serial2:115200n8";
>   bootargs = "console=ttyS2,115200n8 
> earlycon=ns16550a,mmio32,0x0280";
>   };
> +
> + vdd_mmc1: fixedregulator-sd {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_mmc1";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + enable-active-high;
> + gpios = < 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + vdd_sd_dv: gpio-regulator-vdd-sd-dv {
> + compatible = "regulator-gpio";
> + regulator-name = "vdd_sd_dv";
> + pinctrl-names = "default";
> + pinctrl-0 = <_sd_dv_pins_default>;
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + gpios = <_gpio0 55 GPIO_ACTIVE_HIGH>;
> + states = <180 0x0
> +   330 0x1>;
> + };
>  };
>  
>  _pmx0 {
> @@ -45,6 +68,13 @@
>  };
>  
>  _pmx0 {
> + main_i2c0_pins_default: main-i2c0-pins-default {
> + pinctrl-single,pins = <
> + J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL 
> */
> + J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA 
> */
> + >;
> + };
> +
>   main_i2c1_pins_default: main-i2c1-pins-default {
>   pinctrl-single,pins = <
>   J721E_IOPAD(0xdc, PIN_INPUT_PULLUP, 3) /* (U3) 
> ECAP0_IN_APWM_OUT.I2C1_SCL */
> @@ -70,6 +100,12 @@
>   J721E_IOPAD(0x120, PIN_OUTPUT, 0) /* (T4) USB0_DRVVBUS 
> */
>   >;
>   };
> +
> + vdd_sd_dv_pins_default: vdd_sd_dv_pins_default {
> + pinctrl-single,pins = <
> + J721E_IOPAD(0xd0, PIN_INPUT, 7) /* (T5) 
> SPI0_D1.GPIO0_55 */
> + >;
> + };
>  };
>  
>  _uart0 {
> @@ -157,6 +193,10 @@
>  };
>  
>  _i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c0_pins_default>;
> + clock-frequency = <40>;
> +
>   exp1: gpio@20 {
>   compatible = "ti,tca6416";
>   reg = <0x20>;
> @@ -206,6 +246,8 @@
>   /* SD card */
>   pinctrl-0 = <_mmc1_pins_default>;
>   pinctrl-names = "default";
> + vmmc-supply = <_mmc1>;
> + vqmmc-supply = <_sd_dv>;
>   ti,driver-strength-ohm = <50>;
>   disable-wp;
>  };
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi 
> b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> index e60650a62b14..f86c493a44f1 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> @@ -512,11 +512,16 @@
>   ti,otap-del-sel-mmc-hs = <0x0>;
>   ti,otap-del-sel-ddr52 = <0x6>;
>   ti,otap-del-sel-hs200 = <0x8>;
> - ti,otap-del-sel-hs400 = <0x0>;
> + ti,otap-del-sel-hs400 = <0x5>;
> + ti,itap-del-sel-legacy = <0x10>;
> + ti,itap-del-sel-mmc-hs = <0xa>;
>   ti,strobe-sel = <0x77>;
> + ti,clkbuf-sel = <0x7>;
>   ti,trm-icp = <0x8>;
>   bus-width = <8>;
>   mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
>   dma-coherent;
>   };
>  
> @@ -534,7 +539,12 @@
>   ti,otap-del-sel-sdr50 = <0xc>;
>   ti,otap-del-sel-sdr104 = 

Re: [PATCH v3 6/9] ARM: dts: stm32: add support for art-pi board based on stm32h750xbh6

2021-03-18 Thread dillon min
No changes, Just loop lkp in.


Hi lkp,

Sorry for the late reply, thanks for your report.
This patch is to fix the build warning message.

Thanks.

On Mon, Mar 15, 2021 at 5:45 PM  wrote:
>
> From: dillon min 
>
> This patchset has following changes:
>
> - introduce stm32h750.dtsi to support stm32h750 value line
> - add stm32h750i-art-pi.dtb (arch/arm/boot/dts/Makefile)
> - add dts binding usart3 for bt, uart4 for console
>   usart3/uart4 pinctrl in stm32h7-pinctrl.dtsi
>   usart3/uart4 register in stm32h743.dtsi
> - add dts binding sdmmc2 for wifi
>   sdmmc2 pinctrl in stm32h7-pinctrl.dtsi
>   sdmmc2 register in stm32h743.dtsi
> - add spi1 pinctrl in stm32h7-pinctrl.dtsi for spi flash
> - add stm32h750-art-pi.dts to support art-pi board
> - move pinctrl: pin-controller{} from stm32h7-pinctrl.dtsi to stm32h743.dtsi
>   to fix dtbs_check warrning
> - change 'i2c4: i2c@58001C00' to 'i2c4: i2c@58001c00', else will get
>   dtbs_check warrning:
>   >> arch/arm/boot/dts/stm32h750i-art-pi.dt.yaml: soc: 'i2c@40005C00',
>  'i2c@58001C00' do not match any of the regexes:
>  '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+'
>   ...
>
> art-pi board component:
> - 8MiB qspi flash
> - 16MiB spi flash
> - 32MiB sdram
> - ap6212 wifi
>
> the detail board information can be found at:
> https://art-pi.gitee.io/website/
>
> Fixes: 500cdb23d608 ("ARM: dts: stm32: Add STM32H743 MCU and STM32H743i-EVAL 
> board")
> Signed-off-by: dillon min 
> Reported-by: kernel test robot 
> ---
> v3:
> - move pinctrl: pin-controller{} from stm32h7-pinctrl.dtsi to stm32h743.dtsi
>   to fix dtbs_check warrning
>   >> arch/arm/boot/dts/stm32h743i-eval.dt.yaml: soc: pin-controller: {'type':
>   'object'} is not allowed for {'#address-cells': [[1]], '#size-cells':
>   [[1]], 'ranges': [[0,
> - fix dtbs_check warrning:
>   arch/arm/boot/dts/stm32h750i-art-pi.dt.yaml: soc: 'i2c@40005C00',
>   'i2c@58001C00' do not match any of the regexes:
>   '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+'
>
> v2:
> - fix author name/copyright mistake
> - make item in stm32h750i-art-pi.dts sort by letter
>
>  arch/arm/boot/dts/Makefile  |   1 +
>  arch/arm/boot/dts/stm32h743.dtsi| 153 -
>  arch/arm/boot/dts/stm32h750.dtsi|   5 +
>  arch/arm/boot/dts/stm32h750i-art-pi.dts | 228 
> 
>  4 files changed, 385 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/dts/stm32h750.dtsi
>  create mode 100644 arch/arm/boot/dts/stm32h750i-art-pi.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 8e5d4ab4e75e..a19c5ab9df84 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1071,6 +1071,7 @@ dtb-$(CONFIG_ARCH_STM32) += \
> stm32746g-eval.dtb \
> stm32h743i-eval.dtb \
> stm32h743i-disco.dtb \
> +   stm32h750i-art-pi.dtb \
> stm32mp153c-dhcom-drc02.dtb \
> stm32mp157a-avenger96.dtb \
> stm32mp157a-dhcor-avenger96.dtb \
> diff --git a/arch/arm/boot/dts/stm32h743.dtsi 
> b/arch/arm/boot/dts/stm32h743.dtsi
> index 4ebffb0a45a3..4379063d36a2 100644
> --- a/arch/arm/boot/dts/stm32h743.dtsi
> +++ b/arch/arm/boot/dts/stm32h743.dtsi
> @@ -135,6 +135,22 @@
> clocks = < USART2_CK>;
> };
>
> +   usart3: serial@40004800 {
> +   compatible = "st,stm32h7-uart";
> +   reg = <0x40004800 0x400>;
> +   interrupts = <39>;
> +   status = "disabled";
> +   clocks = < USART3_CK>;
> +   };
> +
> +   uart4: serial@40004c00 {
> +   compatible = "st,stm32h7-uart";
> +   reg = <0x40004c00 0x400>;
> +   interrupts = <52>;
> +   status = "disabled";
> +   clocks = < UART4_CK>;
> +   };
> +
> i2c1: i2c@40005400 {
> compatible = "st,stm32f7-i2c";
> #address-cells = <1>;
> @@ -159,7 +175,7 @@
> status = "disabled";
> };
>
> -   i2c3: i2c@40005C00 {
> +   i2c3: i2c@40005c00 {
> compatible = "st,stm32f7-i2c";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -368,6 +384,20 @@
> max-frequency = <12000>;
> };
>
> +   sdmmc2: mmc@48022400 {
> +   compatible = "arm,pl18x", "arm,primecell";
> +   arm,primecell-periphid = <0x10153180>;
> +   reg = <0x48022400 0x400>;
> +   interrupts = <124>;
> +   interrupt-names = "cmd_irq";
> +   clocks = < SDMMC2_CK>;
> +   clock-names = "apb_pclk";
> +   resets = 

RE: [PATCH 01/11] i2c: imx-lpi2c: directly retrun ISR when detect a NACK

2021-03-18 Thread Aisheng Dong
> From: Clark Wang 
> Sent: Wednesday, March 17, 2021 2:54 PM
> 
> A NACK flag in ISR means i2c bus error. In such codition, there is no need to 
> do
> read/write operation. It's better to return ISR directly and then stop i2c
> transfer.
> 
> Signed-off-by: Gao Pan 
> Signed-off-by: Clark Wang 

Reviewed-by: Dong Aisheng 

Regards
Aisheng

> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index 9db6ccded5e9..bbf44ac95021 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -507,15 +507,17 @@ static irqreturn_t lpi2c_imx_isr(int irq, void *dev_id)
>   lpi2c_imx_intctrl(lpi2c_imx, 0);
>   temp = readl(lpi2c_imx->base + LPI2C_MSR);
> 
> + if (temp & MSR_NDF) {
> + complete(_imx->complete);
> + goto ret;
> + }
> +
>   if (temp & MSR_RDF)
>   lpi2c_imx_read_rxfifo(lpi2c_imx);
> -
> - if (temp & MSR_TDF)
> + else if (temp & MSR_TDF)
>   lpi2c_imx_write_txfifo(lpi2c_imx);
> 
> - if (temp & MSR_NDF)
> - complete(_imx->complete);
> -
> +ret:
>   return IRQ_HANDLED;
>  }
> 
> --
> 2.25.1



[RFC PATCH v5 4/4] scheduler: Add cluster scheduler level for x86

2021-03-18 Thread Barry Song
From: Tim Chen 

There are x86 CPU architectures (e.g. Jacobsville) where L2 cahce
is shared among a cluster of cores instead of being exclusive
to one single core.

To prevent oversubscription of L2 cache, load should be
balanced between such L2 clusters, especially for tasks with
no shared data.

Also with cluster scheduling policy where tasks are woken up
in the same L2 cluster, we will benefit from keeping tasks
related to each other and likely sharing data in the same L2
cluster.

Add CPU masks of CPUs sharing the L2 cache so we can build such
L2 cluster scheduler domain.

Signed-off-by: Tim Chen 
Signed-off-by: Barry Song 
---
 arch/x86/Kconfig|  8 
 arch/x86/include/asm/smp.h  |  7 +++
 arch/x86/include/asm/topology.h |  1 +
 arch/x86/kernel/cpu/cacheinfo.c |  1 +
 arch/x86/kernel/cpu/common.c|  3 +++
 arch/x86/kernel/smpboot.c   | 43 -
 6 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879..d597de2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1002,6 +1002,14 @@ config NR_CPUS
  This is purely to save memory: each supported CPU adds about 8KB
  to the kernel image.
 
+config SCHED_CLUSTER
+   bool "Cluster scheduler support"
+   default n
+   help
+Cluster scheduler support improves the CPU scheduler's decision
+making when dealing with machines that have clusters of CPUs
+sharing L2 cache. If unsure say N here.
+
 config SCHED_SMT
def_bool y if SMP
 
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index c0538f8..9cbc4ae 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -16,7 +16,9 @@
 DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_die_map);
 /* cpus sharing the last level cache: */
 DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_llc_shared_map);
+DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_l2c_shared_map);
 DECLARE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id);
+DECLARE_PER_CPU_READ_MOSTLY(u16, cpu_l2c_id);
 DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);
 
 static inline struct cpumask *cpu_llc_shared_mask(int cpu)
@@ -24,6 +26,11 @@ static inline struct cpumask *cpu_llc_shared_mask(int cpu)
return per_cpu(cpu_llc_shared_map, cpu);
 }
 
+static inline struct cpumask *cpu_l2c_shared_mask(int cpu)
+{
+   return per_cpu(cpu_l2c_shared_map, cpu);
+}
+
 DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid);
 DECLARE_EARLY_PER_CPU_READ_MOSTLY(u32, x86_cpu_to_acpiid);
 DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_bios_cpu_apicid);
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index 9239399..2a11ccc 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -103,6 +103,7 @@ static inline void setup_node_to_cpumask_map(void) { }
 #include 
 
 extern const struct cpumask *cpu_coregroup_mask(int cpu);
+extern const struct cpumask *cpu_clustergroup_mask(int cpu);
 
 #define topology_logical_package_id(cpu)   (cpu_data(cpu).logical_proc_id)
 #define topology_physical_package_id(cpu)  (cpu_data(cpu).phys_proc_id)
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 3ca9be4..0d03a71 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -846,6 +846,7 @@ void init_intel_cacheinfo(struct cpuinfo_x86 *c)
l2 = new_l2;
 #ifdef CONFIG_SMP
per_cpu(cpu_llc_id, cpu) = l2_id;
+   per_cpu(cpu_l2c_id, cpu) = l2_id;
 #endif
}
 
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index ab640ab..0ba282d 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -78,6 +78,9 @@
 /* Last level cache ID of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id) = BAD_APICID;
 
+/* L2 cache ID of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(u16, cpu_l2c_id) = BAD_APICID;
+
 /* correctly size the local cpu masks */
 void __init setup_cpu_local_masks(void)
 {
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 02813a7..c85ffa8 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -101,6 +101,8 @@
 
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_llc_shared_map);
 
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_l2c_shared_map);
+
 /* Per CPU bogomips and other parameters */
 DEFINE_PER_CPU_READ_MOSTLY(struct cpuinfo_x86, cpu_info);
 EXPORT_PER_CPU_SYMBOL(cpu_info);
@@ -501,6 +503,21 @@ static bool match_llc(struct cpuinfo_x86 *c, struct 
cpuinfo_x86 *o)
return topology_sane(c, o, "llc");
 }
 
+static bool match_l2c(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
+{
+   int cpu1 = c->cpu_index, cpu2 = o->cpu_index;
+
+   /* Do not match if we do not have a valid APICID for cpu: */
+   if (per_cpu(cpu_l2c_id, cpu1) == BAD_APICID)
+   return false;
+
+   /* Do not match if 

[RFC PATCH v5 0/4] scheduler: expose the topology of clusters and add cluster scheduler

2021-03-18 Thread Barry Song
ARM64 server chip Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each
cluster has 4 cpus. All clusters share L3 cache data while each cluster has
local L3 tag. On the other hand, each cluster will share some internal system
bus. This means cache is much more affine inside one cluster than across
clusters.

+---+  +-+
|  +--++--++---+ |
|  | CPU0 || cpu1 | |+---+ | |
|  +--++--+ ||   | | |
|   ++L3 | | |
|  +--++--+   cluster   ||tag| | |
|  | CPU2 || CPU3 | ||   | | |
|  +--++--+ |+---+ | |
|   |  | |
+---+  | |
+---+  | |
|  +--++--+ +--+ |
|  |  ||  | |+---+ | |
|  +--++--+ ||   | | |
|   ||L3 | | |
|  +--++--+ ++tag| | |
|  |  ||  | ||   | | |
|  +--++--+ |+---+ | |
|   |  | |
+---+  |   L3|
   |   data  |
+---+  | |
|  +--++--+ |+---+ | |
|  |  ||  | ||   | | |
|  +--++--+ ++L3 | | |
|   ||tag| | |
|  +--++--+ ||   | | |
|  |  ||  |+++---+ | |
|  +--++--+|---+ |
+---|  | |
+---|  | |
|  +--++--++---+ |
|  |  ||  | |+---+ | |
|  +--++--+ ||   | | |
|   ++L3 | | |
|  +--++--+ ||tag| | |
|  |  ||  | ||   | | |
|  +--++--+ |+---+ | |
|   |  | |
+---+  | |
+---+  | |
|  +--++--+ +--+ |
|  |  ||  | |   +---+  | |
|  +--++--+ |   |   |  | |


There is a similar need for clustering in x86.  Some x86 cores could share L2 
caches
that is similar to the cluster in Kupeng 920 (e.g. on Jacobsville there are 6 
clusters
of 4 Atom cores, each cluster sharing a separate L2, and 24 cores sharing L3).  

Having a sched_domain for clusters will bring two aspects of improvement:
1. spreading unrelated tasks among clusters, which decreases the contention of 
resources
and improve the throughput.
unrelated tasks might be put randomly without cluster sched_domain:
+---++-+
| ++   ++   || |
| |task|   |task|   || |
| |1   |   |2   |   || |
| ++   ++   || |
|   || |
|   cluster1|| cluster2|
+---++-+

but with cluster sched_domain, they are likely to spread due to LB:
+---++-+
| ++|| ++  |
| |task||| |task|  |
| |1   ||| 

[RFC PATCH v5 3/4] scheduler: scan idle cpu in cluster before scanning the whole llc

2021-03-18 Thread Barry Song
On kunpeng920, cpus within one cluster can communicate wit each other
much faster than cpus across different clusters. A simple hackbench
can prove that.
hackbench running on 4 cpus in single one cluster and 4 cpus in
different clusters shows a large contrast:
(1) within a cluster:
root@ubuntu:~# taskset -c 0,1,2,3 hackbench -p -T -l 2 -g 1
Running in threaded mode with 1 groups using 40 file descriptors each
(== 40 tasks)
Each sender will pass 2 messages of 100 bytes
Time: 4.285

(2) across clusters:
root@ubuntu:~# taskset -c 0,4,8,12 hackbench -p -T -l 2 -g 1
Running in threaded mode with 1 groups using 40 file descriptors each
(== 40 tasks)
Each sender will pass 2 messages of 100 bytes
Time: 5.524

This inspires us to change the wake_affine path to scan cluster before
scanning the whole LLC to try to gatter related tasks in one cluster,
which is done by this patch.

To evaluate the performance impact to related tasks talking with each
other, we run the below hackbench with different -g parameter from 2
to 14, for each different g, we run the command 10 times and get the
average time:
$ numactl -N 0 hackbench -p -T -l 2 -g $1

hackbench will report the time which is needed to complete a certain number
of messages transmissions between a certain number of tasks, for example:
$ numactl -N 0 hackbench -p -T -l 2 -g 10
Running in threaded mode with 10 groups using 40 file descriptors each
(== 400 tasks)
Each sender will pass 2 messages of 100 bytes

The below is the result of hackbench w/ and w/o cluster patch:
g=2  4 6   8  10 12  14
w/o: 1.8151 3.8499 5.5142 7.2491 9.0340 10.7345 12.0929
w/ : 1.7881 3.7371 5.3301 6.9747 8.6909  9.9235 11.2608

Obviously some recent commits have improved the hackbench. So the change
in wake_affine path brings less increase on hackbench compared to what
we got in RFC v4.
And obviously it is much more tricky to leverage wake_affine compared to
leveraging the scatter of tasks in the previous patch as load balance
might pull tasks which have been compact in a cluster so alternative
suggestions welcome.

In order to figure out how many times cpu is picked from the cluster and
how many times cpu is picked out of the cluster, a tracepoint for debug
purpose is added in this patch. And an userspace bcc script to print the
histogram of the result of select_idle_cpu():
#!/usr/bin/python
#
# selectidlecpu.py  select idle cpu histogram.
#
# A Ctrl-C will print the gathered histogram then exit.
#
# 18-March-2021 Barry Song Created this.

from __future__ import print_function
from bcc import BPF
from time import sleep

# load BPF program
b = BPF(text="""

BPF_HISTOGRAM(dist);

TRACEPOINT_PROBE(sched, sched_select_idle_cpu)
{
u32 e;
if (args->idle / 4 == args->target/4)
e = 0; /* idle cpu from same cluster */
else if (args->idle != -1)
e = 1; /* idle cpu from different clusters */
else
e = 2; /* no idle cpu */

dist.increment(e);
return 0;
}
""")

# header
print("Tracing... Hit Ctrl-C to end.")

# trace until Ctrl-C
try:
sleep()
except KeyboardInterrupt:
print()

# output

print("\nlinear histogram")
print("")
b["dist"].print_linear_hist("idle")

Even while g=14 and the system is quite busy, we can see there are some
chances idle cpu is picked from local cluster:
linear histogram
~~
 idle  : count distribution
0  : 15234281 |*** |
1  : 18494||
2  : 53066152 ||

0: local cluster
1: out of the cluster
2: select_idle_cpu() returns -1

Signed-off-by: Barry Song 
---
 include/trace/events/sched.h | 22 ++
 kernel/sched/fair.c  | 32 +++-
 2 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index cbe3e15..86608cf 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -136,6 +136,28 @@
 );
 
 /*
+ * Tracepoint for select_idle_cpu:
+ */
+TRACE_EVENT(sched_select_idle_cpu,
+
+   TP_PROTO(int target, int idle),
+
+   TP_ARGS(target, idle),
+
+   TP_STRUCT__entry(
+   __field(int,target  )
+   __field(int,idle)
+   ),
+
+   TP_fast_assign(
+   __entry->target = target;
+   __entry->idle = idle;
+   ),
+
+   TP_printk("target=%d idle=%d", __entry->target, __entry->idle)
+);
+
+/*
  * Tracepoint for waking up a task:
  */
 DECLARE_EVENT_CLASS(sched_wakeup_template,
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c92ad9f2..3892d42 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6150,7 +6150,12 @@ static int 

[RFC PATCH v5 2/4] scheduler: add scheduler level for clusters

2021-03-18 Thread Barry Song
ARM64 chip Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each
cluster has 4 cpus. All clusters share L3 cache data, but each cluster
has local L3 tag. On the other hand, each clusters will share some
internal system bus. This means cache coherence overhead inside one
cluster is much less than the overhead across clusters.

This patch adds the sched_domain for clusters. On kunpeng 920, without
this patch, domain0 of cpu0 would be MC with cpu0~cpu23 with ; with this
patch, MC becomes domain1, a new domain0 "CLS" including cpu0-cpu3.

This will help spread unrelated tasks among clusters, thus decrease the
contention and improve the throughput, for example, stream benchmark can
improve 20%+ while parallelism is 6 and improve around 5% while paralle-
lism is 12:

(1) -P  6
$ numactl -N 0 /usr/lib/lmbench/bin/stream -P 6 -M 1024M -N 5

w/o patch:
STREAM copy latency: 2.46 nanoseconds
STREAM copy bandwidth: 39096.28 MB/sec
STREAM scale latency: 2.46 nanoseconds
STREAM scale bandwidth: 38970.26 MB/sec
STREAM add latency: 4.45 nanoseconds
STREAM add bandwidth: 32332.04 MB/sec
STREAM triad latency: 4.07 nanoseconds
STREAM triad bandwidth: 35387.69 MB/sec

w/ patch:
STREAM copy latency: 2.02 nanoseconds
STREAM copy bandwidth: 47604.47 MB/sec   +21.7%
STREAM scale latency: 2.04 nanoseconds
STREAM scale bandwidth: 47066.84 MB/sec  +20.8%
STREAM add latency: 3.35 nanoseconds
STREAM add bandwidth: 42942.15 MB/sec+32.8%
STREAM triad latency: 3.16 nanoseconds
STREAM triad bandwidth: 45619.18 MB/sec  +28.9%

On the other hand,stream result could change significantly during different
tests without the patch, eg:
a.
STREAM copy latency: 2.16 nanoseconds
STREAM copy bandwidth: 8.45 MB/sec
STREAM scale latency: 2.17 nanoseconds
STREAM scale bandwidth: 44320.77 MB/sec
STREAM add latency: 3.77 nanoseconds
STREAM add bandwidth: 38230.54 MB/sec
STREAM triad latency: 3.88 nanoseconds
STREAM triad bandwidth: 37072.10 MB/sec

b.
STREAM copy latency: 2.16 nanoseconds
STREAM copy bandwidth: 44403.22 MB/sec
STREAM scale latency: 2.39 nanoseconds
STREAM scale bandwidth: 40173.69 MB/sec
STREAM add latency: 3.77 nanoseconds
STREAM add bandwidth: 38232.56 MB/sec
STREAM triad latency: 3.38 nanoseconds
STREAM triad bandwidth: 42592.04 MB/sec

Obviously it is because the 6 threads are put randomly in 6 cores. Sometimes
they are packed in clusters, sometimes they are spread widely.

(2) -P  12
$ numactl -N 0 /usr/lib/lmbench/bin/stream -P 12 -M 1024M -N 5

w/o patch:
STREAM copy latency: 3.37 nanoseconds
STREAM copy bandwidth: 57008.80 MB/sec
STREAM scale latency: 3.38 nanoseconds
STREAM scale bandwidth: 56848.47 MB/sec
STREAM add latency: 5.50 nanoseconds
STREAM add bandwidth: 52398.62 MB/sec
STREAM triad latency: 5.09 nanoseconds
STREAM triad bandwidth: 56591.60 MB/sec

w/ patch:
STREAM copy latency: 3.24 nanoseconds
STREAM copy bandwidth: 59338.60 MB/sec  +4.1%
STREAM scale latency: 3.25 nanoseconds
STREAM scale bandwidth: 58993.23 MB/sec +3.7%
STREAM add latency: 5.19 nanoseconds
STREAM add bandwidth: 55517.45 MB/sec   +5.9%
STREAM triad latency: 4.86 nanoseconds
STREAM triad bandwidth: 59245.34 MB/sec +4.7%

To evaluate the performance impact to related tasks talking with each
other, we run the below hackbench with different -g parameter from 2
to 14, for each different g, we run the command 10 times and get the
average time:
$ numactl -N 0 hackbench -p -T -l 2 -g $1

hackbench will report the time which is needed to complete a certain number
of messages transmissions between a certain number of tasks, for example:
$ numactl -N 0 hackbench -p -T -l 2 -g 10
Running in threaded mode with 10 groups using 40 file descriptors each
(== 400 tasks)
Each sender will pass 2 messages of 100 bytes

The below is the result of hackbench w/ and w/o the patch:
g=2  4 6   8  10 12  14
w/o: 1.8151 3.8499 5.5142 7.2491 9.0340 10.7345 12.0929
w/ : 1.8396 3.8250 5.4780 7.3442 9.0172 10.5950 11.9113

Obviously this patch doesn't impact hackbench too much.

Signed-off-by: Barry Song 
---
 arch/arm64/Kconfig |  7 +++
 include/linux/sched/cluster.h  | 19 +++
 include/linux/sched/topology.h |  7 +++
 include/linux/topology.h   |  7 +++
 kernel/sched/core.c| 20 
 kernel/sched/fair.c|  4 
 kernel/sched/sched.h   |  1 +
 kernel/sched/topology.c|  5 +
 8 files changed, 70 insertions(+)
 create mode 100644 include/linux/sched/cluster.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1f212b4..9432a30 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -977,6 +977,13 @@ config SCHED_MC
  making when dealing with multi-core CPU chips at a cost of slightly
  increased overhead in some places. If unsure say N here.
 
+config SCHED_CLUSTER
+   bool "Cluster scheduler support"
+   help
+ Cluster scheduler support improves the CPU scheduler's decision
+ 

[RFC PATCH v5 1/4] topology: Represent clusters of CPUs within a die

2021-03-18 Thread Barry Song
From: Jonathan Cameron 

Both ACPI and DT provide the ability to describe additional layers of
topology between that of individual cores and higher level constructs
such as the level at which the last level cache is shared.
In ACPI this can be represented in PPTT as a Processor Hierarchy
Node Structure [1] that is the parent of the CPU cores and in turn
has a parent Processor Hierarchy Nodes Structure representing
a higher level of topology.

For example Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each
cluster has 4 cpus. All clusters share L3 cache data, but each cluster
has local L3 tag. On the other hand, each clusters will share some
internal system bus.

+---+  +-+
|  +--++--++---+ |
|  | CPU0 || cpu1 | |+---+ | |
|  +--++--+ ||   | | |
|   ++L3 | | |
|  +--++--+   cluster   ||tag| | |
|  | CPU2 || CPU3 | ||   | | |
|  +--++--+ |+---+ | |
|   |  | |
+---+  | |
+---+  | |
|  +--++--+ +--+ |
|  |  ||  | |+---+ | |
|  +--++--+ ||   | | |
|   ||L3 | | |
|  +--++--+ ++tag| | |
|  |  ||  | ||   | | |
|  +--++--+ |+---+ | |
|   |  | |
+---+  |   L3|
   |   data  |
+---+  | |
|  +--++--+ |+---+ | |
|  |  ||  | ||   | | |
|  +--++--+ ++L3 | | |
|   ||tag| | |
|  +--++--+ ||   | | |
|  |  ||  |+++---+ | |
|  +--++--+|---+ |
+---|  | |
+---|  | |
|  +--++--++---+ |
|  |  ||  | |+---+ | |
|  +--++--+ ||   | | |
|   ++L3 | | |
|  +--++--+ ||tag| | |
|  |  ||  | ||   | | |
|  +--++--+ |+---+ | |
|   |  | |
+---+  | |
+---+  | |
|  +--++--+ +--+ |
|  |  ||  | |   +---+  | |
|  +--++--+ |   |   |  | |
|   |   |L3 |  | |
|  +--++--+ +---+tag|  | |
|  |  ||  | |   |   |  | |
|  +--++--+ |   +---+  | |
|   |  | |
+---+  | |
+---+ ++ |
|  +--++--+ +--+ |
|  |  ||  | |  +---+   | |
|  +--++--+ |  |   |   | |
|   |  |L3 |   | |
|  +--++--+ +--+tag|   | |
|  |  ||  | |  |   |   | |
|  +--++--+ |  

Re: [PATCH v2] erofs: fix bio->bi_max_vecs behavior change

2021-03-18 Thread Gao Xiang
Hi Chao,

On Fri, Mar 19, 2021 at 10:15:18AM +0800, Chao Yu wrote:
> On 2021/3/6 12:04, Gao Xiang wrote:

...

> > +   (*last_block + 1 != current_block || !*eblks)) {
> 
> Xiang,
> 
> I found below function during checking bi_max_vecs usage in f2fs:
> 
> /**
>  * bio_full - check if the bio is full
>  * @bio:bio to check
>  * @len:length of one segment to be added
>  *
>  * Return true if @bio is full and one segment with @len bytes can't be
>  * added to the bio, otherwise return false
>  */
> static inline bool bio_full(struct bio *bio, unsigned len)
> {
> if (bio->bi_vcnt >= bio->bi_max_vecs)
> return true;
> 
> if (bio->bi_iter.bi_size > UINT_MAX - len)
> return true;
> 
> return false;
> }
> 
> Could you please check that whether it will be better to use bio_full()
> rather than using left-space-in-bio maintained by erofs itself? something
> like:
> 
> if (bio && (bio_full(bio, PAGE_SIZE) ||
>   /* not continuous */
>   (*last_block + 1 != current_block))
> 
> I'm thinking we need to decouple bio detail implementation as much as
> possible, to avoid regression whenever bio used/max size definition
> updates, though I've no idea how to fix f2fs case.

Thanks for your suggestion.

Not quite sure I understand the idea... The original problem was that
when EROFS bio_alloc, the number of requested bvec also partially stood
for remaining blocks of the current on-disk extent to limit the read
length. but after that bio behavior change, bi_max_vec could be increased
internally by block layer (e.g. 1 --> 4), so bi_max_vecs is no longer
as what we expect (I mean passed-in). so could cause read request
out-of-bound or hung. That's why I decided to record it manually (never
rely on bio statistics anymore...)

Also btw, AFAIK, Jianan is still investigating to use iomap instead
(mainly resolve tail-packing inline path). And I'm also busy in big
pcluster and LZMA new features for the next cycle. So I think we might
leave it just as is and it would be replaced with iomap in the future.

Thanks,
Gao Xiang

> 
> Let me know if you have other concern.
> 
> Thanks,



Re: [PATCH] atl1c: optimize rx loop

2021-03-18 Thread Willy Tarreau
On Fri, Mar 19, 2021 at 12:04:47PM +0800, Sieng Piaw Liew wrote:
> Remove this trivial bit of inefficiency from the rx receive loop,
> results in increase of a few Mbps in iperf3. Tested on Intel Core2
> platform.
> 
> Signed-off-by: Sieng Piaw Liew 
> ---
>  drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c 
> b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> index 3f65f2b370c5..b995f9a0479c 100644
> --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> @@ -1796,9 +1796,7 @@ static void atl1c_clean_rx_irq(struct atl1c_adapter 
> *adapter,
>   struct atl1c_recv_ret_status *rrs;
>   struct atl1c_buffer *buffer_info;
>  
> - while (1) {
> - if (*work_done >= work_to_do)
> - break;
> + while (*work_done < work_to_do) {

It should not change anything, or only based on the compiler's optimization
and should not result in a measurable difference because what it does is
exactly the same. Have you really compared the compiled output code to
explain the difference ? I strongly suspect you'll find no difference at
all.

Thus for me it's certainly not an optimization, it could be qualified as
a cleanup to improve code readability however.

Willy


[PATCH] atl1c: use napi_alloc_skb

2021-03-18 Thread Sieng Piaw Liew
Using napi_alloc_skb in NAPI context avoids enable/disable IRQs, which
increases iperf3 result by a few Mbps. Since napi_alloc_skb() uses
NET_IP_ALIGN, convert other alloc methods to the same padding. Tested
on Intel Core2 and AMD K10 platforms.

Signed-off-by: Sieng Piaw Liew 
---
 .../net/ethernet/atheros/atl1c/atl1c_main.c   | 28 +++
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c 
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 3f65f2b370c5..66325ba5b3a1 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -47,7 +47,7 @@ static void atl1c_down(struct atl1c_adapter *adapter);
 static int atl1c_reset_mac(struct atl1c_hw *hw);
 static void atl1c_reset_dma_ring(struct atl1c_adapter *adapter);
 static int atl1c_configure(struct atl1c_adapter *adapter);
-static int atl1c_alloc_rx_buffer(struct atl1c_adapter *adapter);
+static int atl1c_alloc_rx_buffer(struct atl1c_adapter *adapter, bool 
napi_mode);
 
 
 static const u32 atl1c_default_msg = NETIF_MSG_DRV | NETIF_MSG_PROBE |
@@ -470,7 +470,7 @@ static void atl1c_set_rxbufsize(struct atl1c_adapter 
*adapter,
adapter->rx_buffer_len = mtu > AT_RX_BUF_SIZE ?
roundup(mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN, 8) : 
AT_RX_BUF_SIZE;
 
-   head_size = SKB_DATA_ALIGN(adapter->rx_buffer_len + NET_SKB_PAD) +
+   head_size = SKB_DATA_ALIGN(adapter->rx_buffer_len + NET_SKB_PAD + 
NET_IP_ALIGN) +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
adapter->rx_frag_size = roundup_pow_of_two(head_size);
 }
@@ -1434,7 +1434,7 @@ static int atl1c_configure(struct atl1c_adapter *adapter)
atl1c_set_multi(netdev);
atl1c_restore_vlan(adapter);
 
-   num = atl1c_alloc_rx_buffer(adapter);
+   num = atl1c_alloc_rx_buffer(adapter, false);
if (unlikely(num == 0))
return -ENOMEM;
 
@@ -1650,14 +1650,20 @@ static inline void atl1c_rx_checksum(struct 
atl1c_adapter *adapter,
skb_checksum_none_assert(skb);
 }
 
-static struct sk_buff *atl1c_alloc_skb(struct atl1c_adapter *adapter)
+static struct sk_buff *atl1c_alloc_skb(struct atl1c_adapter *adapter,
+  bool napi_mode)
 {
struct sk_buff *skb;
struct page *page;
 
-   if (adapter->rx_frag_size > PAGE_SIZE)
-   return netdev_alloc_skb(adapter->netdev,
-   adapter->rx_buffer_len);
+   if (adapter->rx_frag_size > PAGE_SIZE) {
+   if (likely(napi_mode))
+   return napi_alloc_skb(>napi,
+ adapter->rx_buffer_len);
+   else
+   return netdev_alloc_skb_ip_align(adapter->netdev,
+
adapter->rx_buffer_len);
+   }
 
page = adapter->rx_page;
if (!page) {
@@ -1670,7 +1676,7 @@ static struct sk_buff *atl1c_alloc_skb(struct 
atl1c_adapter *adapter)
skb = build_skb(page_address(page) + adapter->rx_page_offset,
adapter->rx_frag_size);
if (likely(skb)) {
-   skb_reserve(skb, NET_SKB_PAD);
+   skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
adapter->rx_page_offset += adapter->rx_frag_size;
if (adapter->rx_page_offset >= PAGE_SIZE)
adapter->rx_page = NULL;
@@ -1680,7 +1686,7 @@ static struct sk_buff *atl1c_alloc_skb(struct 
atl1c_adapter *adapter)
return skb;
 }
 
-static int atl1c_alloc_rx_buffer(struct atl1c_adapter *adapter)
+static int atl1c_alloc_rx_buffer(struct atl1c_adapter *adapter, bool napi_mode)
 {
struct atl1c_rfd_ring *rfd_ring = >rfd_ring;
struct pci_dev *pdev = adapter->pdev;
@@ -1701,7 +1707,7 @@ static int atl1c_alloc_rx_buffer(struct atl1c_adapter 
*adapter)
while (next_info->flags & ATL1C_BUFFER_FREE) {
rfd_desc = ATL1C_RFD_DESC(rfd_ring, rfd_next_to_use);
 
-   skb = atl1c_alloc_skb(adapter);
+   skb = atl1c_alloc_skb(adapter, napi_mode);
if (unlikely(!skb)) {
if (netif_msg_rx_err(adapter))
dev_warn(>dev, "alloc rx buffer 
failed\n");
@@ -1857,7 +1863,7 @@ static void atl1c_clean_rx_irq(struct atl1c_adapter 
*adapter,
count++;
}
if (count)
-   atl1c_alloc_rx_buffer(adapter);
+   atl1c_alloc_rx_buffer(adapter, true);
 }
 
 /**
-- 
2.17.1



Re: [RFC PATCH v3 00/18] dynamic debug diet plan

2021-03-18 Thread Andi Kleen
Jim Cromie  writes:

> CONFIG_DYNAMIC_DEBUG creates a struct _ddebug (56 bytes) for each
> callsite, which includes 3 pointers to: module, filename, function.
> These are repetetive, and compressible, this patch series goes about
> doing that, it:

So how much memory does it actually save?
-Andi


Re: [PATCH] ASoC: fsl_sai: remove reset code from dai_probe

2021-03-18 Thread Shengjiu Wang
Hi Mark

On Tue, Mar 16, 2021 at 9:51 PM Mark Brown  wrote:
>
> On Tue, Mar 16, 2021 at 01:42:40PM +, Viorel Suman wrote:
>
> > To me it makes sense to manage the clocks and reset from the same place.
> > Currently we have the clocks management moved completely into runtime PM
> > fsl_sai_runtime_resume and fsl_sai_runtime_suspend callbacks.
>
> Usually the pattern is to have probe() leave everything powered up then
> let runtime PM power things down if it's enabled, you can often do the
> power up by having an open coded call to the resume callback in probe().

It seems some drivers very depend on runtime PM, if the CONFIG_PM=n,
the drivers should not work.  What's the strategy for this?
Do we need to support both cases, or only one case is also acceptable?

Best regards
Wang Shengjiu


[PATCH] x86/sgx: Avoid returning NULL in __sgx_alloc_epc_page()

2021-03-18 Thread Kai Huang
Below kernel bug happened when running simple SGX application when EPC
is under pressure.  The root cause is with commit 5b8719504e3a
("x86/sgx: Add a basic NUMA allocation scheme to sgx_alloc_epc_page()"),
__sgx_alloc_epc_page() returns NULL when there's no free EPC page can be
allocated, while old behavior was it always returned ERR_PTR(-ENOMEM) in
such case.

Fix by directly returning the page if __sgx_alloc_epc_page_from_node()
allocates a valid page in fallback to non-local allocation, and always
returning ERR_PTR(-ENOMEM) if no EPC page can be allocated.

[  253.474764] BUG: kernel NULL pointer dereference, address: 0008
[  253.500101] #PF: supervisor write access in kernel mode
[  253.525462] #PF: error_code(0x0002) - not-present page
...
[  254.102041] Call Trace:
[  254.126699]  sgx_ioc_enclave_add_pages+0x241/0x770
[  254.151305]  sgx_ioctl+0x194/0x4b0
[  254.174976]  ? handle_mm_fault+0xd0/0x260
[  254.198470]  ? do_user_addr_fault+0x1ef/0x570
[  254.221827]  __x64_sys_ioctl+0x91/0xc0
[  254.244546]  do_syscall_64+0x38/0x90
[  254.266728]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  254.289232] RIP: 0033:0x7fdc4cf4031b
...
[  254.711480] CR2: 0008
[  254.735494] ---[ end trace 970dce6d4cdf7f64 ]---
[  254.759915] RIP: 0010:sgx_alloc_epc_page+0x46/0x152
...

Fixes: 5b8719504e3a("x86/sgx: Add a basic NUMA allocation scheme to 
sgx_alloc_epc_page()")
Signed-off-by: Kai Huang 
---
 arch/x86/kernel/cpu/sgx/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index fe26e7e91c25..7105e34da530 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -508,10 +508,10 @@ struct sgx_epc_page *__sgx_alloc_epc_page(void)
 
page = __sgx_alloc_epc_page_from_node(nid);
if (page)
-   break;
+   return page;
}
 
-   return page;
+   return ERR_PTR(-ENOMEM);
 }
 
 /**
-- 
2.30.2



Re: [External] Re: [PATCH v4 4/5] mm: memcontrol: use obj_cgroup APIs to charge kmem pages

2021-03-18 Thread Muchun Song
On Fri, Mar 19, 2021 at 11:40 AM Shakeel Butt  wrote:
>
> On Thu, Mar 18, 2021 at 4:08 AM Muchun Song  wrote:
> >
> [...]
> >
> > +static inline struct mem_cgroup *get_obj_cgroup_memcg(struct obj_cgroup 
> > *objcg)
>
> I would prefer get_mem_cgroup_from_objcg().

Inspired by obj_cgroup_memcg() which returns the memcg from objcg.
So I introduce get_obj_cgroup_memcg() which obtains a reference of
memcg on the basis of obj_cgroup_memcg().

So that the names are more consistent. Just my thought.

So should I rename it to get_mem_cgroup_from_objcg?

>
> > +{
> > +   struct mem_cgroup *memcg;
> > +
> > +   rcu_read_lock();
> > +retry:
> > +   memcg = obj_cgroup_memcg(objcg);
> > +   if (unlikely(!css_tryget(>css)))
> > +   goto retry;
> > +   rcu_read_unlock();
> > +
> > +   return memcg;
> > +}
> > +
> >  #ifdef CONFIG_MEMCG_KMEM
> >  int memcg_alloc_page_obj_cgroups(struct page *page, struct kmem_cache *s,
> >  gfp_t gfp, bool new_page)
> > @@ -3070,15 +3088,8 @@ static int obj_cgroup_charge_pages(struct obj_cgroup 
> > *objcg, gfp_t gfp,
> > struct mem_cgroup *memcg;
> > int ret;
> >
> > -   rcu_read_lock();
> > -retry:
> > -   memcg = obj_cgroup_memcg(objcg);
> > -   if (unlikely(!css_tryget(>css)))
> > -   goto retry;
> > -   rcu_read_unlock();
> > -
> > +   memcg = get_obj_cgroup_memcg(objcg);
> > ret = __memcg_kmem_charge(memcg, gfp, nr_pages);
>
> Why not manually inline __memcg_kmem_charge() here? This is the only user.
>
> Similarly manually inline __memcg_kmem_uncharge() into
> obj_cgroup_uncharge_pages() and call obj_cgroup_uncharge_pages() in
> obj_cgroup_release().

Good point. I will do this.

>
> > -
> > css_put(>css);
> >
> > return ret;
> > @@ -3143,18 +3154,18 @@ static void __memcg_kmem_uncharge(struct mem_cgroup 
> > *memcg, unsigned int nr_page
> >   */
> >  int __memcg_kmem_charge_page(struct page *page, gfp_t gfp, int order)
> >  {
> > -   struct mem_cgroup *memcg;
> > +   struct obj_cgroup *objcg;
> > int ret = 0;
> >
> > -   memcg = get_mem_cgroup_from_current();
>
> This was the only use of get_mem_cgroup_from_current(). Why not remove it?

I saw a potential user.

[PATCH v10 0/3] Charge loop device i/o to issuing cgroup

To avoid reintroducing them. So I did not remove it.

>
> > -   if (memcg && !mem_cgroup_is_root(memcg)) {
> > -   ret = __memcg_kmem_charge(memcg, gfp, 1 << order);
> > +   objcg = get_obj_cgroup_from_current();
> > +   if (objcg) {
> > +   ret = obj_cgroup_charge_pages(objcg, gfp, 1 << order);
> > if (!ret) {
> > -   page->memcg_data = (unsigned long)memcg |
> > +   page->memcg_data = (unsigned long)objcg |
> > MEMCG_DATA_KMEM;
> > return 0;
> > }
> > -   css_put(>css);
> > +   obj_cgroup_put(objcg);
> > }
> > return ret;
> >  }
> [...]
> >  static void uncharge_page(struct page *page, struct uncharge_gather *ug)
> >  {
> > unsigned long nr_pages;
> > +   struct mem_cgroup *memcg;
> > +   struct obj_cgroup *objcg;
> >
> > VM_BUG_ON_PAGE(PageLRU(page), page);
> >
> > -   if (!page_memcg(page))
> > -   return;
> > -
> > /*
> >  * Nobody should be changing or seriously looking at
> > -* page_memcg(page) at this point, we have fully
> > +* page memcg or objcg at this point, we have fully
> >  * exclusive access to the page.
> >  */
> > +   if (PageMemcgKmem(page)) {
> > +   objcg = __page_objcg(page);
> > +   memcg = get_obj_cgroup_memcg(objcg);
>
> Can you add a comment that this get matches the put at the end of the
> function and kmem pages do not hold memcg references anymore.

Make sense. Will do.

Thanks for your suggestions.

>
> > +   } else {
> > +   memcg = __page_memcg(page);
> > +   }
> > +
> > +   if (!memcg)
> > +   return;
> >
> > -   if (ug->memcg != page_memcg(page)) {
> > +   if (ug->memcg != memcg) {
> > if (ug->memcg) {
> > uncharge_batch(ug);
> > uncharge_gather_clear(ug);
> > }
> > -   ug->memcg = page_memcg(page);
> > +   ug->memcg = memcg;
> > ug->dummy_page = page;
> >
> > /* pairs with css_put in uncharge_batch */
> > -   css_get(>memcg->css);
> > +   css_get(>css);
> > }
> >
> > nr_pages = compound_nr(page);
> > -   ug->nr_pages += nr_pages;
> >
> > -   if (PageMemcgKmem(page))
> > +   if (PageMemcgKmem(page)) {
> > +   ug->nr_memory += nr_pages;
> > ug->nr_kmem += nr_pages;
> > -   else
> > +
> > +  

[PATCH] atl1c: optimize rx loop

2021-03-18 Thread Sieng Piaw Liew
Remove this trivial bit of inefficiency from the rx receive loop,
results in increase of a few Mbps in iperf3. Tested on Intel Core2
platform.

Signed-off-by: Sieng Piaw Liew 
---
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c 
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 3f65f2b370c5..b995f9a0479c 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -1796,9 +1796,7 @@ static void atl1c_clean_rx_irq(struct atl1c_adapter 
*adapter,
struct atl1c_recv_ret_status *rrs;
struct atl1c_buffer *buffer_info;
 
-   while (1) {
-   if (*work_done >= work_to_do)
-   break;
+   while (*work_done < work_to_do) {
rrs = ATL1C_RRD_DESC(rrd_ring, rrd_ring->next_to_clean);
if (likely(RRS_RXD_IS_VALID(rrs->word3))) {
rfd_num = (rrs->word0 >> RRS_RX_RFD_CNT_SHIFT) &
-- 
2.17.1



[PATCH] ARM: Qualify enabling of swiotlb_init()

2021-03-18 Thread Florian Fainelli
We do not need a SWIOTLB unless we have DRAM that is addressable beyond
the arm_dma_limit. Compare max_pfn with arm_dma_pfn_limit to determine
whether we do need a SWIOTLB to be initialized.

Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs")
Signed-off-by: Florian Fainelli 
---
 arch/arm/mm/init.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 828a2561b229..8356bf1daa28 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -301,7 +301,11 @@ static void __init free_highpages(void)
 void __init mem_init(void)
 {
 #ifdef CONFIG_ARM_LPAE
-   swiotlb_init(1);
+   if (swiotlb_force == SWIOTLB_FORCE ||
+   max_pfn > arm_dma_pfn_limit)
+   swiotlb_init(1);
+   else
+   swiotlb_force = SWIOTLB_NO_FORCE;
 #endif
 
set_max_mapnr(pfn_to_page(max_pfn) - mem_map);
-- 
2.25.1



Re: [PATCH v4 00/25] Page folios

2021-03-18 Thread Matthew Wilcox
On Fri, Mar 05, 2021 at 04:18:36AM +, Matthew Wilcox (Oracle) wrote:
> Our type system does not currently distinguish between tail pages and
> head or single pages.  This is a problem because we call compound_head()
> multiple times (and the compiler cannot optimise it out), bloating the
> kernel.  It also makes programming hard as it is often unclear whether
> a function operates on an individual page, or an entire compound page.

I've pushed a new version out here:
https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/folio

I think it takes into account everyone's comments so far.  It even compiles.


[PATCH] swiotlb: Make SWIOTLB_NO_FORCE perform no allocation

2021-03-18 Thread Florian Fainelli
When SWIOTLB_NO_FORCE is used, there should really be no allocations of
io_tlb_nslabs to occur since we are not going to use those slabs. If a
platform was somehow setting swiotlb_no_force and a later call to
swiotlb_init() was to be made we would still be proceeding with
allocating the default SWIOTLB size (64MB), whereas if swiotlb=noforce
was set on the kernel command line we would have only allocated 2KB.

This would be inconsistent and the point of initializing io_tlb_nslabs
to 1, was to avoid hitting the test for io_tlb_nslabs being 0/not
initialized.

Signed-off-by: Florian Fainelli 
---
 kernel/dma/swiotlb.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index c10e855a03bc..526c8321b76f 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -121,12 +121,10 @@ setup_io_tlb_npages(char *str)
}
if (*str == ',')
++str;
-   if (!strcmp(str, "force")) {
+   if (!strcmp(str, "force"))
swiotlb_force = SWIOTLB_FORCE;
-   } else if (!strcmp(str, "noforce")) {
+   else if (!strcmp(str, "noforce"))
swiotlb_force = SWIOTLB_NO_FORCE;
-   io_tlb_nslabs = 1;
-   }
 
return 0;
 }
@@ -284,6 +282,9 @@ swiotlb_init(int verbose)
unsigned char *vstart;
unsigned long bytes;
 
+   if (swiotlb_force == SWIOTLB_NO_FORCE)
+   goto out;
+
if (!io_tlb_nslabs) {
io_tlb_nslabs = (default_size >> IO_TLB_SHIFT);
io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
@@ -302,6 +303,7 @@ swiotlb_init(int verbose)
io_tlb_start = 0;
}
pr_warn("Cannot allocate buffer");
+out:
no_iotlb_memory = true;
 }
 
-- 
2.25.1



[PATCH net-next] atl1c: switch to napi_gro_receive

2021-03-18 Thread Sieng Piaw Liew
Changing to napi_gro_receive() improves efficiency significantly. Tested
on Intel Core2-based motherboards and iperf3.

Signed-off-by: Sieng Piaw Liew 
---
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c 
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 3f65f2b370c5..3e440c2dc68a 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -1851,7 +1851,7 @@ static void atl1c_clean_rx_irq(struct atl1c_adapter 
*adapter,
vlan = le16_to_cpu(vlan);
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan);
}
-   netif_receive_skb(skb);
+   napi_gro_receive(>napi, skb);
 
(*work_done)++;
count++;
-- 
2.17.1



Re: [V2,1/1] platform/x86: add support for Advantech software defined button

2021-03-18 Thread YingChieh, Ho
Hi Hans,

Thank you for your kindly review.
As a beginner in driver coding, I got gains much from your suggestions.
Path v3 is ready at patchwork.^^

Hans de Goede  於 2021年3月19日 週五 上午12:21寫道:
>
> Hi,
>
> On 3/12/21 9:11 AM, YingChieh Ho wrote:
> > From: "Andrea.Ho" 
> >
> > Advantech sw_button is a ACPI event trigger button.
> >
> > With this driver, we can report KEY_EVENT on the
> > Advantech Tabletop Network Appliances products and it has been
> > tested in FWA1112VC.
> >
> > Add the software define button support to report EV_REP key_event
> > (KEY_PROG1) by pressing button that cloud be get on user
> > interface and trigger the customized actions.
> >
> > Signed-off-by: Andrea.Ho 
> >
> > v2:
> > - change evdev key-code from BTN_TRIGGER_HAPPY to KEY_PROG1
> > - to rewrite the driver to be a regular platform_driver
> > - use specific names instead of generic names,
> >   "Software Button" to "Advantech Software Button",
> >   "button" to "adv_swbutton"
> > - remove unused defines or use-once defines, ACPI_BUTTON_FILE_INFO,
> >   ACPI_BUTTON_FILE_STATE, ACPI_BUTTON_TYPE_UNKNOWN, ACPI_SWBTN_NAME
>
> Thank you this version is much better, I have various review remarks below.
>
> Please send a v3 with those fixed.
>
>
> > ---
> >  MAINTAINERS |   5 +
> >  drivers/platform/x86/Kconfig|  11 ++
> >  drivers/platform/x86/Makefile   |   3 +
> >  drivers/platform/x86/adv_swbutton.c | 192 
> >  4 files changed, 211 insertions(+)
> >  create mode 100644 drivers/platform/x86/adv_swbutton.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 68f21d46614c..e35c48e411b7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -562,6 +562,11 @@ S: Maintained
> >  F: Documentation/scsi/advansys.rst
> >  F: drivers/scsi/advansys.c
> >
> > +ADVANTECH SWBTN DRIVER
> > +M: Andrea Ho 
> > +S: Maintained
> > +F: drivers/platform/x86/adv_swbutton.c
> > +
> >  ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346)
> >  M: Michael Hennerich 
> >  S: Supported
> > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > index 0581a54cf562..b1340135c5e9 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -180,6 +180,17 @@ config ACER_WMI
> >   If you have an ACPI-WMI compatible Acer/ Wistron laptop, say Y or 
> > M
> >   here.
>
> This is supposed to be indented by a space (from the diff format) and then
> a tab + 2 spaces, but in your patch this is now indented by 10 spaces.
>
> In general your entire patch has all tabs replaced by spaces, I guess that
> your mail-client or editor is mangling things. Please do the following:
>
> 1. Check your patch for checkpatch errors:
>
> git format-patch HEAD~
> scripts/checkpatch.pl 0001-platform...patch
>
> And fix all reported issues, both whitespace issues and others.
>
> 2. Send the next version of the patch like this:
>
> git format-patch -v3 HEAD~
> git send-email v3-0001-platform...patch
>
> Do NOT edit the v3-0001-platform...patch file between these 2 steps.
>
>
> > +config ADV_SWBUTTON
> > +tristate "Advantech ACPI Software Button Driver"
>
> You are using indent steps of 4 spaces here, that should be a tab
> > +depends on ACPI
> > +help
> > +  Say Y here to enable support for Advantech software defined
> > +  button feature. More information can be fount at
> > +  
>
> And a tab and 2 spaces for the help text.
>
> > +
> > +  To compile this driver as a module, choose M here. The module will
> > +  be called adv_swbutton.
> > +
> >  config APPLE_GMUX
> > tristate "Apple Gmux Driver"
> > depends on ACPI && PCI
> > diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> > index 2b85852a1a87..76a321fc58ba 100644
> > --- a/drivers/platform/x86/Makefile
> > +++ b/drivers/platform/x86/Makefile
> > @@ -22,6 +22,9 @@ obj-$(CONFIG_ACERHDF) += acerhdf.o
> >  obj-$(CONFIG_ACER_WIRELESS)+= acer-wireless.o
> >  obj-$(CONFIG_ACER_WMI) += acer-wmi.o
> >
> > +# Advantech
> > +obj-$(CONFIG_ADV_SWBUTTON)  += adv_swbutton.o
> > +
>
> The indent before the += should use tabs not spaces.
>
> >  # Apple
> >  obj-$(CONFIG_APPLE_GMUX)   += apple-gmux.o
> >
> > diff --git a/drivers/platform/x86/adv_swbutton.c
> > b/drivers/platform/x86/adv_swbutton.c
> > new file mode 100644
> > index ..f4387220e8a0
> > --- /dev/null
> > +++ b/drivers/platform/x86/adv_swbutton.c
> > @@ -0,0 +1,192 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + *  adv_swbutton.c - Software Button Interface Driver.
> > + *
> > + *  (C) Copyright 2020 Advantech Corporation, Inc
> > + *
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > 

Re: CLANG LTO compatibility issue with DEBUG_INFO_BTF

2021-03-18 Thread Yonghong Song




On 3/18/21 8:45 PM, Jisheng Zhang wrote:

Hi,

When trying the latest 5.12-rc3 with both LTO_CLANG_THIN and DEBUG_INFO_BTF
enabled, I met lots of warnings such as:

...
tag__recode_dwarf_type: couldn't find 0x4a7ade5 type for 0x4ab9f88 
(subroutine_type)!
ftype__recode_dwarf_types: couldn't find 0x4a7ade5 type for 0x4ab9fa4 
(formal_parameter)!
...
namespace__recode_dwarf_types: couldn't find 0x4a8ff4a type for 0x4aba05c 
(member)!
namespace__recode_dwarf_types: couldn't find 0x4a7ae9b type for 0x4aba084 
(member)!
...
WARN: multiple IDs found for 'path': 281, 729994 - using 281
WARN: multiple IDs found for 'task_struct': 421, 730101 - using 421
...


then finally get build error:
FAILED unresolved symbol vfs_truncate


Is this a known issue? Do we need to make DEBUG_INFO_BTF depend on !LTO?


This is a known issue for pahole. pahole does not handle dwarf well 
generated with LTO. Bill Wendling from google is looking at the issue 
and I will help look at the issue as well. Since bpf heavily depends

on BTF, at this point, I suggest if you are using bpf, please do not
turn on LTO. Or if you build with LTO, just turn off DEBUG_INFO_BTF
in your config. Thanks!



pahole version: v1.20
clang version: 11.0


Thanks



Re: [PATCH v2 4/6] dt-bindings: PCI: Add SiFive FU740 PCIe host controller

2021-03-18 Thread Krzysztof Wilczyński
Hi,

Thank you for sending the patches over!

A few nitpicks.

> +title: SiFive fu740 PCIe host controller
> +
> +description:
> +  SiFive fu740 PCIe host controller is based on the Synopsys DesignWare
> +  PCI core. It shares common features with the PCIe DesignWare core and
> +  inherits common properties defined in
> +  Documentation/devicetree/bindings/pci/designware-pcie.txt.
[...]

In the above title and description it would be "FU740" to keep this
consistent with everything else.

Also, as this is a YAML file, a multi-line description might be better
expressed as "description: |" or "description: |+", of course it depends
on whether you would like or not to preserve line endings.

[...]
> +  dma-coherent:
> +description: Indicates that the PCIe IP block can ensure the coherency
> +
> +  bus-range:
> +description: Range of bus numbers associated with this controller.
[...]
> +  resets:
> +description: A phandle to the PCIe power up reset line
> +
> +  pwren-gpios:
> +description: Should specify the GPIO for controlling the PCI bus device 
> power on
> +
> +  perstn-gpios:
> +description: Should specify the GPIO for controlling the PCI bus device 
> reset
[...]

All the above descriptions should end with a period, so that we keep
things consistent throughout.

Krzysztof


Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver

2021-03-18 Thread Viresh Kumar
On 18-03-21, 15:52, Arnd Bergmann wrote:
> Allowing multiple virtio-i2c controllers in one system, and multiple i2c
> devices attached to each controller is clearly something that has to work.

Good.

> I don't actually see a limitation though. Viresh, what is the problem
> you see for having multiple controllers?

I thought this would be a problem in that case as we are using the global
virtio_adapter here.

+   vi->adap = _adapter;
+   i2c_set_adapdata(vi->adap, vi);

Multiple calls to probe() will end up updating the same pointer inside adap.

+   vi->adap->dev.parent = >dev;

Same here, overwrite.

+   /* Setup ACPI node for controlled devices which will be probed through 
ACPI */
+   ACPI_COMPANION_SET(>adap->dev, ACPI_COMPANION(pdev));
+   vi->adap->timeout = HZ / 10;

These may be fine, but still not ideal I believe.

+   ret = i2c_add_adapter(vi->adap);
i
This should be a problem as well, we must be adding this to some sort of list,
doing some RPM stuff, etc ?

Jie, the solution is to allocate memory for adap at runtime in probe and remove
the virtio_adapter structure completely.

-- 
viresh


[PATCH v4 4/4] arm64: dts: mt8183: Add kukui-jacuzzi-juniper board

2021-03-18 Thread Hsin-Yi Wang
Juniper is known as Acer Chromebook Spin 311 (CP311-3H).

Signed-off-by: Hsin-Yi Wang 
---
 arch/arm64/boot/dts/mediatek/Makefile |  1 +
 .../mt8183-kukui-jacuzzi-juniper-sku16.dts| 13 +
 .../mt8183-kukui-jacuzzi-juniper.dtsi | 27 +++
 3 files changed, 41 insertions(+)
 create mode 100644 
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper-sku16.dts
 create mode 100644 
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
b/arch/arm64/boot/dts/mediatek/Makefile
index 554105d2c389..db4753d82a4b 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -14,6 +14,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana-rev7.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-evb.dtb
diff --git 
a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper-sku16.dts 
b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper-sku16.dts
new file mode 100644
index ..36d2c3b3cadf
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper-sku16.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-juniper.dtsi"
+
+/ {
+   model = "Google juniper sku16 board";
+   compatible = "google,juniper-sku16", "google,juniper", 
"mediatek,mt8183";
+};
+
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper.dtsi
new file mode 100644
index ..078bc765646f
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper.dtsi
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+ {
+   trackpad@2c {
+   compatible = "hid-over-i2c";
+   reg = <0x2c>;
+   hid-descr-addr = <0x20>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   interrupts-extended = < 7 IRQ_TYPE_LEVEL_LOW>;
+
+   wakeup-source;
+   };
+};
+
+_wifi {
+   qcom,ath10k-calibration-variant = "GO_JUNIPER";
+};
+
-- 
2.31.0.rc2.261.g7f71774620-goog



[PATCH v4 3/4] arm64: dts: mt8183: Add kukui-jacuzzi-damu board

2021-03-18 Thread Hsin-Yi Wang
Damu is known as ASUS Chromebook Flip CM3.

Signed-off-by: Hsin-Yi Wang 
---
v3->v4: none
v2->v3: remove unused nodes
v1->v2: fix pp3300_panel regulator property
---
 arch/arm64/boot/dts/mediatek/Makefile |   1 +
 .../mediatek/mt8183-kukui-jacuzzi-damu.dts|  31 ++
 .../dts/mediatek/mt8183-kukui-jacuzzi.dtsi| 474 ++
 3 files changed, 506 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
b/arch/arm64/boot/dts/mediatek/Makefile
index deba27ab7657..554105d2c389 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana-rev7.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dts 
b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dts
new file mode 100644
index ..42ba9c00866c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+/ {
+   model = "Google damu board";
+   compatible = "google,damu", "mediatek,mt8183";
+};
+
+ {
+   status = "okay";
+
+   compatible = "hid-over-i2c";
+   reg = <0x10>;
+   interrupt-parent = <>;
+   interrupts = <155 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   post-power-on-delay-ms = <10>;
+   hid-descr-addr = <0x0001>;
+};
+
+_wifi {
+   qcom,ath10k-calibration-variant = "GO_DAMU";
+};
+
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
new file mode 100644
index ..4049dff8464b
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
@@ -0,0 +1,474 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+#include "mt8183-kukui.dtsi"
+
+/ {
+   panel: panel {
+   compatible = "auo,b116xw03";
+   power-supply = <_panel>;
+   ddc-i2c-bus = <>;
+   backlight = <_lcd0>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   pp1200_mipibrdg: pp1200-mipibrdg {
+   compatible = "regulator-fixed";
+   regulator-name = "pp1200_mipibrdg";
+   pinctrl-names = "default";
+   pinctrl-0 = <_mipibrdg_en>;
+
+   enable-active-high;
+   regulator-boot-on;
+
+   gpio = < 54 GPIO_ACTIVE_HIGH>;
+   };
+
+   pp1800_mipibrdg: pp1800-mipibrdg {
+   compatible = "regulator-fixed";
+   regulator-name = "pp1800_mipibrdg";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_en>;
+
+   enable-active-high;
+   regulator-boot-on;
+
+   gpio = < 36 GPIO_ACTIVE_HIGH>;
+   };
+
+   pp3300_panel: pp3300-panel {
+   compatible = "regulator-fixed";
+   regulator-name = "pp3300_panel";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_panel_pins>;
+
+   enable-active-high;
+   regulator-boot-on;
+
+   gpio = < 35 GPIO_ACTIVE_HIGH>;
+   };
+
+   vddio_mipibrdg: vddio-mipibrdg {
+   compatible = "regulator-fixed";
+   regulator-name = "vddio_mipibrdg";
+   pinctrl-names = "default";
+   pinctrl-0 = <_mipibrdg_en>;
+
+   enable-active-high;
+   regulator-boot-on;
+
+   gpio = < 37 GPIO_ACTIVE_HIGH>;
+   };
+
+   volume_buttons: volume-buttons {
+   compatible = "gpio-keys";
+   pinctrl-names = "default";
+   pinctrl-0 = <_button_pins>;
+
+   volume_down {
+   label = "Volume Down";
+   linux,code = ;
+   debounce-interval = <100>;
+
+   gpios = < 6 GPIO_ACTIVE_LOW>;
+   };
+
+   volume_up {
+   label = "Volume Up";
+   linux,code = ;
+   

[PATCH v4 2/4] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-juniper

2021-03-18 Thread Hsin-Yi Wang
mt8183-kukui-jacuzzi-juniper board also known as Acer Chromebook Spin 311,
using mediatek mt8183 SoC.

Signed-off-by: Hsin-Yi Wang 
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml 
b/Documentation/devicetree/bindings/arm/mediatek.yaml
index a86716cdd408..edee2c3f8620 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -129,6 +129,11 @@ properties:
 items:
   - const: google,damu
   - const: mediatek,mt8183
+  - description: Google Juniper (Acer Chromebook Spin 311)
+items:
+  - const: google,juniper-sku16
+  - const: google,juniper
+  - const: mediatek,mt8183
 
 additionalProperties: true
 
-- 
2.31.0.rc2.261.g7f71774620-goog



[PATCH v4 1/4] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-damu

2021-03-18 Thread Hsin-Yi Wang
mt8183-kukui-jacuzzi-damu board also known as ASUS Chromebook Flip CM3,
using mediatek mt8183 SoC.

Signed-off-by: Hsin-Yi Wang 
Reviewed-by: Enric Balletbo i Serra 
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml 
b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 93b3bdf6eaeb..a86716cdd408 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -125,6 +125,10 @@ properties:
   - google,krane-sku176
   - const: google,krane
   - const: mediatek,mt8183
+  - description: Google Damu (ASUS Chromebook Flip CM3)
+items:
+  - const: google,damu
+  - const: mediatek,mt8183
 
 additionalProperties: true
 
-- 
2.31.0.rc2.261.g7f71774620-goog



Re: [PATCH 00/30] [Set 2] Rid W=1 warnings in SCSI

2021-03-18 Thread Martin K. Petersen
On Fri, 12 Mar 2021 09:47:08 +, Lee Jones wrote:

> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
> 
> Lee Jones (30):
>   scsi: mpt3sas: mpt3sas_config: Fix a bunch of potential naming doc-rot
>   scsi: ufs: ufshcd: Fix incorrectly named
> ufshcd_find_max_sup_active_icc_level()
>   scsi: lpfc: lpfc_scsi: Fix a bunch of kernel-doc misdemeanours
>   scsi: lpfc: lpfc_attr: Fix a bunch of misnamed functions
>   scsi: libfc: fc_rport: Fix incorrect naming of fc_rport_adisc_resp()
>   scsi: mpt3sas: mpt3sas_transport: Fix a couple of misdocumented
> functions/params
>   scsi: libfc: fc_fcp: Fix misspelling of fc_fcp_destroy()
>   scsi: qla2xxx: qla_mr: Fix a couple of misnamed functions
>   scsi: mpt3sas: mpt3sas_ctl: Fix some kernel-doc misnaming issues
>   scsi: qla2xxx: qla_nx2: Fix incorrectly named function
> qla8044_check_temp()
>   scsi: qla2xxx: qla_target: Fix a couple of misdocumented functions
>   scsi: lpfc: lpfc_debugfs: Fix incorrectly documented function
> lpfc_debugfs_commonxripools_data()
>   scsi: lpfc: lpfc_bsg: Fix a few incorrectly named functions
>   scsi: bfa: bfa_fcs_lport: Move a large struct from the stack onto the
> heap
>   scsi: lpfc: lpfc_nvme: Fix kernel-doc formatting issue
>   scsi: ufs: cdns-pltfrm: Supply function names for headers
>   scsi: cxgbi: cxgb3i: cxgb3i: Fix misnaming of ddp_setup_conn_digest()
>   scsi: esas2r: esas2r_log: Supply __printf(x, y) formatting for
> esas2r_log_master()
>   scsi: be2iscsi: be_iscsi: Fix incorrect naming of
> beiscsi_iface_config_vlan()
>   scsi: be2iscsi: be_main: Provide missing function name in header
>   scsi: be2iscsi: be_mgmt: Fix beiscsi_phys_port()'s name in header
>   scsi: bnx2i: bnx2i_sysfs: Fix bnx2i_set_ccell_info()'s name in
> description
>   scsi: initio: Remove unused variable 'prev'
>   scsi: a100u2w: Remove unused variable 'bios_phys'
>   scsi: dc395x: Fix incorrect naming in function headers
>   scsi: atp870u: Fix naming and demote incorrect and non-conformant
> kernel-doc header
>   scsi: myrs: Remove a couple of unused 'status' variables
>   scsi: 3w-: Remove 2 unused variables 'response_que_value' and
> 'tw_dev'
>   scsi: 3w-9xxx: Remove a few set but unused variables
>   scsi: 3w-sas: Remove unused variables 'sglist' and 'tw_dev'
> 
> [...]

Applied to 5.13/scsi-queue, thanks!

[01/30] scsi: mpt3sas: mpt3sas_config: Fix a bunch of potential naming doc-rot
https://git.kernel.org/mkp/scsi/c/cf9e575e62a4
[02/30] scsi: ufs: ufshcd: Fix incorrectly named 
ufshcd_find_max_sup_active_icc_level()
https://git.kernel.org/mkp/scsi/c/11eea9b3fd4d
[03/30] scsi: lpfc: lpfc_scsi: Fix a bunch of kernel-doc misdemeanours
https://git.kernel.org/mkp/scsi/c/0bb87e01d815
[04/30] scsi: lpfc: lpfc_attr: Fix a bunch of misnamed functions
https://git.kernel.org/mkp/scsi/c/a3dbf5145d01
[05/30] scsi: libfc: fc_rport: Fix incorrect naming of fc_rport_adisc_resp()
https://git.kernel.org/mkp/scsi/c/0dbea7c18873
[06/30] scsi: mpt3sas: mpt3sas_transport: Fix a couple of misdocumented 
functions/params
https://git.kernel.org/mkp/scsi/c/54cb88dc3083
[07/30] scsi: libfc: fc_fcp: Fix misspelling of fc_fcp_destroy()
https://git.kernel.org/mkp/scsi/c/775b4d65a6fb
[08/30] scsi: qla2xxx: qla_mr: Fix a couple of misnamed functions
https://git.kernel.org/mkp/scsi/c/381095668d51
[09/30] scsi: mpt3sas: mpt3sas_ctl: Fix some kernel-doc misnaming issues
https://git.kernel.org/mkp/scsi/c/782a1ab33f71
[10/30] scsi: qla2xxx: qla_nx2: Fix incorrectly named function 
qla8044_check_temp()
https://git.kernel.org/mkp/scsi/c/a736e4490442
[11/30] scsi: qla2xxx: qla_target: Fix a couple of misdocumented functions
https://git.kernel.org/mkp/scsi/c/dc49ab48a77c
[12/30] scsi: lpfc: lpfc_debugfs: Fix incorrectly documented function 
lpfc_debugfs_commonxripools_data()
https://git.kernel.org/mkp/scsi/c/2c6400b78243
[13/30] scsi: lpfc: lpfc_bsg: Fix a few incorrectly named functions
https://git.kernel.org/mkp/scsi/c/3145d2d69e16
[14/30] scsi: bfa: bfa_fcs_lport: Move a large struct from the stack onto the 
heap
https://git.kernel.org/mkp/scsi/c/a7a11b6cfec2
[15/30] scsi: lpfc: lpfc_nvme: Fix kernel-doc formatting issue
https://git.kernel.org/mkp/scsi/c/f6b35a75042b
[16/30] scsi: ufs: cdns-pltfrm: Supply function names for headers
https://git.kernel.org/mkp/scsi/c/d5db88b0ce89
[17/30] scsi: cxgbi: cxgb3i: cxgb3i: Fix misnaming of ddp_setup_conn_digest()
https://git.kernel.org/mkp/scsi/c/181883786427
[18/30] scsi: esas2r: esas2r_log: Supply __printf(x, y) formatting for 
esas2r_log_master()
https://git.kernel.org/mkp/scsi/c/1c666a3e0a54
[19/30] scsi: be2iscsi: be_iscsi: Fix incorrect naming of 
beiscsi_iface_config_vlan()
https://git.kernel.org/mkp/scsi/c/1b8a7ee9308e
[20/30] 

  1   2   3   4   5   6   7   8   9   10   >