[PATCH] phy: phy-mtk-tphy: fix checkpatch.pl warning about SPDX_LICENSE_TAG

[Chunfeng Yun]

Use SPDX-License-Identifier tag instead of the GPL license text

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/mediatek/Makefile   |  1 +
 drivers/phy/mediatek/phy-mtk-tphy.c | 10 +-
 2 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index 763a92e..1bdab14 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
 #
 # Makefile for the phy drivers.
 #
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c 
b/drivers/phy/mediatek/phy-mtk-tphy.c
index 38c281b..b962339 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Copyright (c) 2015 MediaTek Inc.
  * Author: Chunfeng Yun 
  *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
  */
 
 #include 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 03/10] cpufreq: exynos: Remove support for Exynos5440

[Viresh Kumar]

On 24-04-18, 22:32, Krzysztof Kozlowski wrote:
> The Exynos5440 is not actively developed, there are no development
> boards available and probably there are no real products with it.
> Remove wide-tree support for Exynos5440.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../bindings/cpufreq/cpufreq-exynos5440.txt|  28 --
>  drivers/cpufreq/Kconfig.arm|  14 -
>  drivers/cpufreq/Makefile   |   1 -
>  drivers/cpufreq/exynos5440-cpufreq.c   | 452 
> -
>  4 files changed, 495 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>  delete mode 100644 drivers/cpufreq/exynos5440-cpufreq.c

Acked-by: Viresh Kumar 

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH resend] usb: chipidea: Don't select EXTCON

[Peter Chen]

 
> > >
> > > The patch doesn't remove extcon support from chipidea driver.
> > > I just want to not select EXTCON unconditionally, but let the users
> > > choose. If the users need extcon, they could enable EXTCON
> > > themselves
> > >
> > > I just searched all the dts in arch/arm/boot/dts and
> > > arch/arm64/boot/dts only the four dts give extcon phandle to chipidea 
> > > host, other
> users don't make use of it:
> > >
> > > arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> > >
> > > arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> > >
> > > arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
> > >
> > > arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts
> > >
> >
> > I see, but I do not want to break msm platforms. You may try to create
> > Glue driver Kconfig entry for chipidea like dwc3, and let msm depends on 
> > EXTCON.
> 
> Got your points. Since multi_v7_defconfig has selected EXTCON, and
> EXTCON_USB_GPIO(which depends on EXTCON) is enabled in arm64 defconfig,
> so what about:
> 
> enable EXTCON explicitly in arm64 defconfig?
> then add this patch?
> 

I am not sure if Qualcomm platforms use these, add Qualcomm guys to confirm it.

Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 0/6] typec: tcpm: Add sink side support for PPS

[Sebastian Reichel]

Hi Greg,

On Tue, Apr 24, 2018 at 03:57:49PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Apr 23, 2018 at 03:10:55PM +0100, Adam Thomson wrote:
> > This patch set adds sink side support for the PPS feature introduced in the
> > USB PD 3.0 specification.
> > 
> > The source PPS supply is represented using the Power Supply framework to 
> > provide
> > access and control APIs for dealing with it's operating voltage and current,
> > and switching between a standard PDO and PPS APDO operation. During 
> > standard PDO
> > operation the voltage and current is read-only, but for APDO PPS these are
> > writable as well to allow for control.
> > 
> > It should be noted that the keepalive for PPS is not handled within TCPM. 
> > The
> > expectation is that the external user will be required to ensure re-requests
> > occur regularly to ensure PPS remains and the source does not hard reset.
> 
> Sebastian, any objection from me taking this series through my USB tree?

I currently have the power-supply bits in a local branch for
testing. I would like to have this in the power-supply
tree, since there is at least one pending driver which could
directly use the newly introduced usb_type.

I can either provide an immutable branch with a signed tag, or
you can merged it and provide me an immutable branch.

If you merge it via the USB tree patch 2-4 are

Reviewed-by: Sebastian Reichel 

-- Sebastian


signature.asc
Description: PGP signature

[PATCH 4/4] usb: gadget: f_fs: Add FUNCTIONFS_CONTROL_ONLY flag

[Jerry Zhang]

This flag allows users to directly specify when
they want a ffs instance to be used for handling
control requests only via the configfs control_config/
group. When the flag is set, user must set *none*
of the speed descriptor flags and provide no
speeds in the descriptor. This ensures that it
cannot be mixed up with a normal function.

Signed-off-by: Jerry Zhang 
---
 drivers/usb/gadget/function/f_fs.c  | 22 +++---
 include/uapi/linux/usb/functionfs.h |  1 +
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 4b2cb9d93176..4ef37ed70c5d 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -338,11 +338,6 @@ static ssize_t ffs_ep0_write(struct file *file, const char 
__user *buf,
case FFS_READ_DESCRIPTORS:
case FFS_READ_STRINGS:
/* Copy data */
-   if (unlikely(len < 16)) {
-   ret = -EINVAL;
-   break;
-   }
-
data = ffs_prepare_buffer(buf, len);
if (IS_ERR(data)) {
ret = PTR_ERR(data);
@@ -2383,10 +2378,19 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
  FUNCTIONFS_VIRTUAL_ADDR |
  FUNCTIONFS_EVENTFD |
  FUNCTIONFS_ALL_CTRL_RECIP |
- FUNCTIONFS_CONFIG0_SETUP)) {
+ FUNCTIONFS_CONFIG0_SETUP |
+ FUNCTIONFS_CONTROL_ONLY)) {
ret = -ENOSYS;
goto error;
}
+   if ((bool) (flags & (FUNCTIONFS_HAS_FS_DESC |
+ FUNCTIONFS_HAS_HS_DESC |
+ FUNCTIONFS_HAS_SS_DESC)) ==
+   (bool) (flags & FUNCTIONFS_CONTROL_ONLY)) {
+   pr_err("Must have at least one speed descriptor "
+   "or CONTROL_ONLY (but not both)\n");
+   goto error;
+   }
data += 12;
len  -= 12;
break;
@@ -2466,7 +2470,7 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
len -= ret;
}
 
-   if (raw_descs == data || len) {
+   if (len) {
ret = -EINVAL;
goto error;
}
@@ -3020,10 +3024,6 @@ static int _ffs_func_bind(struct usb_configuration *c,
 
ENTER();
 
-   /* Has descriptors only for speeds gadget does not support */
-   if (unlikely(!(full | high | super)))
-   return -ENOTSUPP;
-
/* Allocate a single chunk, less management later on */
vlabuf = kzalloc(vla_group_size(d), GFP_KERNEL);
if (unlikely(!vlabuf))
diff --git a/include/uapi/linux/usb/functionfs.h 
b/include/uapi/linux/usb/functionfs.h
index d77ee6b65328..25e55f485a6e 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -24,6 +24,7 @@ enum functionfs_flags {
FUNCTIONFS_EVENTFD = 32,
FUNCTIONFS_ALL_CTRL_RECIP = 64,
FUNCTIONFS_CONFIG0_SETUP = 128,
+   FUNCTIONFS_CONTROL_ONLY = 256,
 };
 
 /* Descriptor of an non-audio endpoint */
-- 
2.17.0.484.g0c8726318c-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 3/4] Documentation: usb: Add docs for configfs control requests

[Jerry Zhang]

Signed-off-by: Jerry Zhang 
---
Changes in V2:
- Updated doc with the FUNCTIONFS_CONTROL_ONLY flag

 Documentation/usb/gadget_configfs.txt | 34 +++
 1 file changed, 34 insertions(+)

diff --git a/Documentation/usb/gadget_configfs.txt 
b/Documentation/usb/gadget_configfs.txt
index 635e57493709..964edc314ee2 100644
--- a/Documentation/usb/gadget_configfs.txt
+++ b/Documentation/usb/gadget_configfs.txt
@@ -285,6 +285,40 @@ e.g.:
 
 $ rmdir g1
 
+8. Handling control requests
+--
+
+A composite gadget with changing configurations may still want to handle
+vendor control requests in a centralized location. In particular, functionfs
+instances can pass control requests to user-space, but there is no
+guarantee that a functionfs is in the current config.
+
+To handle this there is a special config in the root of the gadget
+called control_config. Functions linked here do not appear in the
+configuration, but will receive control requests. To use it:
+
+Create a special instance of functionfs.
+
+$ mkdir functions/ffs.ctrl
+
+Mount the functionfs instance and write descriptors.
+
+mount functionfs ctrl /dev/ffs-ctrl
+# Write functionfs descriptors to /dev/ffs-ctrl/ep0
+# Descriptor header must include ALL_CTRL_RECIP AND CONTROL_ONLY
+# and must *not* include any speed descriptors.
+
+Link the function into control config.
+
+$ ln -s functions/ffs.ctrl control_config/f1
+
+Link normal functions into the appropriate config, and enable the gadget.
+
+$ echo  > UDC
+
+Handle control requests in /dev/ffs-ctrl/ep0. 
+See functionfs documentation on how to do this.
+
 
 
 
-- 
2.17.0.484.g0c8726318c-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 2/4] usb: gadget: configfs: Create control_config group

[Jerry Zhang]

Control_config is a group under gadget that acts
as a normal config group, except it does not
appear in cdev->configs.

Functions that have exactly zero descriptors can
be linked into control_config. These functions
are bound and unbound with the rest of the gadget,
but are never enabled. Also, functions with zero
descriptors cannot be used in real configs.

Create configfs_setup(), which will first attempt
composite setup. If that fails, it will go through
functions in control_config and use req_match to
find and deliver the request to a function that can
handle it.

This allows the user to create a functionfs instance
dedicated to handling non-standard control requests
no matter what functions or configurations are
currently active.

Signed-off-by: Jerry Zhang 
---

Changes in V2:
- Added config_item_type for control_config without default attrs
- Changed bind to fail if the wrong kind of function is linked to
a normal config or control_config
- Changed bind to fail if a control function has no req_match, instead
of skipping it over

 drivers/usb/gadget/configfs.c | 114 --
 1 file changed, 96 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index efba66ca0719..ed3d675ee7bb 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -44,12 +44,22 @@ int check_user_usb_string(const char *name,
 
 static const struct usb_descriptor_header *otg_desc[2];
 
+struct config_usb_cfg {
+   struct config_group group;
+   struct config_group strings_group;
+   struct list_head string_list;
+   struct usb_configuration c;
+   struct list_head func_list;
+   struct usb_gadget_strings *gstrings[MAX_USB_STRING_LANGS + 1];
+};
+
 struct gadget_info {
struct config_group group;
struct config_group functions_group;
struct config_group configs_group;
struct config_group strings_group;
struct config_group os_desc_group;
+   struct config_usb_cfg control_config;
 
struct mutex lock;
struct usb_gadget_strings *gstrings[MAX_USB_STRING_LANGS + 1];
@@ -68,15 +78,6 @@ static inline struct gadget_info *to_gadget_info(struct 
config_item *item)
 return container_of(to_config_group(item), struct gadget_info, group);
 }
 
-struct config_usb_cfg {
-   struct config_group group;
-   struct config_group strings_group;
-   struct list_head string_list;
-   struct usb_configuration c;
-   struct list_head func_list;
-   struct usb_gadget_strings *gstrings[MAX_USB_STRING_LANGS + 1];
-};
-
 static inline struct config_usb_cfg *to_config_usb_cfg(struct config_item 
*item)
 {
return container_of(to_config_group(item), struct config_usb_cfg,
@@ -512,6 +513,16 @@ static const struct config_item_type gadget_config_type = {
.ct_owner   = THIS_MODULE,
 };
 
+static struct configfs_item_operations control_config_item_ops = {
+   .allow_link = config_usb_cfg_link,
+   .drop_link  = config_usb_cfg_unlink,
+};
+
+static const struct config_item_type control_config_type = {
+   .ct_item_ops= &control_config_item_ops,
+   .ct_owner   = THIS_MODULE,
+};
+
 static const struct config_item_type gadget_root_type = {
.ct_item_ops= &gadget_root_item_ops,
.ct_attrs   = gadget_root_attrs,
@@ -1205,11 +1216,10 @@ int composite_os_desc_req_prepare(struct 
usb_composite_dev *cdev,
 static void purge_configs_funcs(struct gadget_info *gi)
 {
struct usb_configuration*c;
+   struct usb_function *f, *tmp;
+   struct config_usb_cfg *cfg;
 
list_for_each_entry(c, &gi->cdev.configs, list) {
-   struct usb_function *f, *tmp;
-   struct config_usb_cfg *cfg;
-
cfg = container_of(c, struct config_usb_cfg, c);
 
list_for_each_entry_safe(f, tmp, &c->functions, list) {
@@ -1229,6 +1239,14 @@ static void purge_configs_funcs(struct gadget_info *gi)
c->highspeed = 0;
c->fullspeed = 0;
}
+
+   cfg = &gi->control_config;
+   c = &cfg->c;
+   list_for_each_entry_safe(f, tmp, &c->functions, list) {
+   list_move_tail(&f->list, &cfg->func_list);
+   if (f->unbind)
+   f->unbind(c, f);
+   }
 }
 
 static int configfs_composite_bind(struct usb_gadget *gadget,
@@ -1242,6 +1260,9 @@ static int configfs_composite_bind(struct usb_gadget 
*gadget,
struct usb_string   *s;
unsignedi;
int ret;
+   struct config_usb_cfg *cfg;
+   struct usb_function *f;
+   struct usb_function *tmp;
 
/* the gi->lock is hold by the caller */
cdev->gadget = gadget;
@@ -1260,8 +1281,6 @@ static int configfs_composite_bind(struct usb_gadget 
*gadget,
 
 
list_for_each_entry(c, &gi->cdev.con

Re: [RFC 00/10] ARM: Remove support for Exynos5440

[Arnd Bergmann]

On Tue, Apr 24, 2018 at 10:56 PM, Krzysztof Kozlowski  wrote:
> On Tue, Apr 24, 2018 at 10:50:58PM +0200, Arnd Bergmann wrote:
>> On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski  
>> wrote:
> The only dependency is through Kconfig symbol (SOC_EXYNOS5440).  After
> applying 10/10, which removes SOC_EXYNOS5440, some automatic code
> testers can complain about non-existing Kconfig option.  That's not big
> issue because all this will go away so indeed we could take everything
> in one release.

Right, I wouldn't worry about that. Kbuild itself doesn't warn about missing
symbols, so this is only for helpful automated checks that tell us that there
is still some pending work.

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] usb: gadget: uvc: disable stream when disconnected

[Paul Elder]

Down the call stack from the ioctl handler for VIDIOC_STREAMON,
uvc_video_alloc_requests contains a BUG_ON, which in the high level,
triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF
being issued previously.

This can also be triggered by starting the stream and then physically
disconnecting usb. To fix this, do the streamoff procedures on usb
disconnect.

Signed-off-by: Paul Elder 
---
Changes in v2: Nothing

 drivers/usb/gadget/function/f_uvc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/gadget/function/f_uvc.c 
b/drivers/usb/gadget/function/f_uvc.c
index fa34dcbe1197..5bb79888e3f7 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -374,9 +374,12 @@ uvc_function_disable(struct usb_function *f)
 {
struct uvc_device *uvc = to_uvc(f);
struct v4l2_event v4l2_event;
+   struct uvc_video *video = &uvc->video;
 
INFO(f->config->cdev, "uvc_function_disable\n");
 
+   uvcg_video_enable(video, 0);
+
memset(&v4l2_event, 0, sizeof(v4l2_event));
v4l2_event.type = UVC_EVENT_DISCONNECT;
v4l2_event_queue(&uvc->vdev, &v4l2_event);
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] usb: gadget: uvc: synchronize streamon/off with uvc_function_set_alt

[Paul Elder]

Down the call stack from the ioctl handler for VIDIOC_STREAMON,
uvc_video_alloc_requests contains a BUG_ON, which in the high level,
triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF
being issued previously.

This could be triggered by uvc_function_set_alt 0 racing and
winning against uvc_v4l2_streamon, or by userspace neglecting to issue
the VIDIOC_STREAMOFF ioctl.

To fix this, add two more uvc states: starting and stopping. Use these
to prevent the racing, and to detect when VIDIOC_STREAMON is issued
without previously issuing VIDIOC_STREAMOFF.

Signed-off-by: Paul Elder 
---
Changes in v2: Nothing

 drivers/usb/gadget/function/f_uvc.c|  8 ++--
 drivers/usb/gadget/function/uvc.h  |  2 ++
 drivers/usb/gadget/function/uvc_v4l2.c | 19 +--
 3 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uvc.c 
b/drivers/usb/gadget/function/f_uvc.c
index 439eba660e95..9b63b28a1ee3 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -325,17 +325,19 @@ uvc_function_set_alt(struct usb_function *f, unsigned 
interface, unsigned alt)
 
switch (alt) {
case 0:
-   if (uvc->state != UVC_STATE_STREAMING)
+   if (uvc->state != UVC_STATE_STREAMING &&
+   uvc->state != UVC_STATE_STARTING)
return 0;
 
if (uvc->video.ep)
usb_ep_disable(uvc->video.ep);
 
+   uvc->state = UVC_STATE_STOPPING;
+
memset(&v4l2_event, 0, sizeof(v4l2_event));
v4l2_event.type = UVC_EVENT_STREAMOFF;
v4l2_event_queue(&uvc->vdev, &v4l2_event);
 
-   uvc->state = UVC_STATE_CONNECTED;
return 0;
 
case 1:
@@ -354,6 +356,8 @@ uvc_function_set_alt(struct usb_function *f, unsigned 
interface, unsigned alt)
return ret;
usb_ep_enable(uvc->video.ep);
 
+   uvc->state = UVC_STATE_STARTING;
+
memset(&v4l2_event, 0, sizeof(v4l2_event));
v4l2_event.type = UVC_EVENT_STREAMON;
v4l2_event_queue(&uvc->vdev, &v4l2_event);
diff --git a/drivers/usb/gadget/function/uvc.h 
b/drivers/usb/gadget/function/uvc.h
index a64e07e61f8c..afb2eac1f337 100644
--- a/drivers/usb/gadget/function/uvc.h
+++ b/drivers/usb/gadget/function/uvc.h
@@ -131,6 +131,8 @@ enum uvc_state {
UVC_STATE_DISCONNECTED,
UVC_STATE_CONNECTED,
UVC_STATE_STREAMING,
+   UVC_STATE_STARTING,
+   UVC_STATE_STOPPING,
 };
 
 struct uvc_device {
diff --git a/drivers/usb/gadget/function/uvc_v4l2.c 
b/drivers/usb/gadget/function/uvc_v4l2.c
index 9a9019625496..fdf02b6987c0 100644
--- a/drivers/usb/gadget/function/uvc_v4l2.c
+++ b/drivers/usb/gadget/function/uvc_v4l2.c
@@ -193,6 +193,9 @@ uvc_v4l2_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
struct uvc_video *video = &uvc->video;
int ret;
 
+   if (uvc->state != UVC_STATE_STARTING)
+   return 0;
+
if (type != video->queue.queue.type)
return -EINVAL;
 
@@ -201,12 +204,13 @@ uvc_v4l2_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
if (ret < 0)
return ret;
 
+   uvc->state = UVC_STATE_STREAMING;
+
/*
 * Complete the alternate setting selection setup phase now that
 * userspace is ready to provide video frames.
 */
uvc_function_setup_continue(uvc);
-   uvc->state = UVC_STATE_STREAMING;
 
return 0;
 }
@@ -217,11 +221,22 @@ uvc_v4l2_streamoff(struct file *file, void *fh, enum 
v4l2_buf_type type)
struct video_device *vdev = video_devdata(file);
struct uvc_device *uvc = video_get_drvdata(vdev);
struct uvc_video *video = &uvc->video;
+   int ret;
+
+   if (uvc->state != UVC_STATE_STOPPING)
+   return 0;
 
if (type != video->queue.queue.type)
return -EINVAL;
 
-   return uvcg_video_enable(video, 0);
+   ret = uvcg_video_enable(video, 0);
+   if (ret < 0)
+   return ret;
+
+   uvc->state = UVC_STATE_CONNECTED;
+
+   return 0;
+
 }
 
 static int
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] usb: gadget: uvc: remove delay usb status phase

[Paul Elder]

The completion of the usb status phase doesn't need to be delayed
from uvc_function_set_alt to uvc_v4l2_streamon/off.
Remove USB_GADGET_DELAYED_STATUS and usb_composite_setup_delay from
these two, respectively.

Signed-off-by: Paul Elder 
---
Changes in v2:
1. Remove delay usb status phase

 drivers/usb/gadget/function/f_uvc.c| 3 ++-
 drivers/usb/gadget/function/uvc_v4l2.c | 6 --
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uvc.c 
b/drivers/usb/gadget/function/f_uvc.c
index 9b63b28a1ee3..fa34dcbe1197 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -361,7 +361,8 @@ uvc_function_set_alt(struct usb_function *f, unsigned 
interface, unsigned alt)
memset(&v4l2_event, 0, sizeof(v4l2_event));
v4l2_event.type = UVC_EVENT_STREAMON;
v4l2_event_queue(&uvc->vdev, &v4l2_event);
-   return USB_GADGET_DELAYED_STATUS;
+
+   return 0;
 
default:
return -EINVAL;
diff --git a/drivers/usb/gadget/function/uvc_v4l2.c 
b/drivers/usb/gadget/function/uvc_v4l2.c
index fdf02b6987c0..138d95b3b8d1 100644
--- a/drivers/usb/gadget/function/uvc_v4l2.c
+++ b/drivers/usb/gadget/function/uvc_v4l2.c
@@ -206,12 +206,6 @@ uvc_v4l2_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
 
uvc->state = UVC_STATE_STREAMING;
 
-   /*
-* Complete the alternate setting selection setup phase now that
-* userspace is ready to provide video frames.
-*/
-   uvc_function_setup_continue(uvc);
-
return 0;
 }
 
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/3] usb: gadget: uvc: fix racing between uvc_function_set_alt and streamon/off

[Paul Elder]

Down the call stack from the ioctl handler for VIDIOC_STREAMON,
uvc_video_alloc_requests contains a BUG_ON, which in the high level,
triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF
being issued previously.

This can happen in a few ways, such as if the userspace uvc gadget
application simply doesn't issue VIDIOC_STREAMOFF. Another way is if
uvc_function_set_alt with alt 0 is called after it is called with 1 but
before VIDIOC_STREAMON is called; in this case, UVC_EVENT_STREAMOFF will
not be queued to userspace, and therefore userspace will never call
VIDIOC_STREAMOFF.

To fix this, add two more uvc states: starting and stopping. The
starting state is entered when uvc_function_set_alt 1 is called, and is
exited in uvc_v4l2_streamon, when the state is changed to streaming. The
stopping state is entered when uvc_function_set_alt 0 is called, and is
exited in uvc_v4l2_streamoff, when the state is changed to connected.

The status phase of the SET_INTERFACE request doesn't need to be delayed
by the uvc gadget driver, so that is removed.

Finally, there is another way to trigger the aforementioned BUG: start
streaming and (physically) disconnect usb. To fix this, call
uvcg_video_enable 0 in uvc_function_disable.

Changes in v2:
1. Remove delay usb status phase

Paul Elder (3):
  usb: gadget: uvc: synchronize streamon/off with uvc_function_set_alt
  usb: gadget: uvc: remove delay usb status phase from uvc
  usb: gadget: uvc: disable stream when disconnected

 drivers/usb/gadget/function/f_uvc.c| 14 +++---
 drivers/usb/gadget/function/uvc.h  |  2 ++
 drivers/usb/gadget/function/uvc_v4l2.c | 21 +++--
 3 files changed, 28 insertions(+), 9 deletions(-)

-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 00/10] ARM: Remove support for Exynos5440

[Krzysztof Kozlowski]

On Tue, Apr 24, 2018 at 10:50:58PM +0200, Arnd Bergmann wrote:
> On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski  wrote:
> > Hi,
> >
> >
> > Overview
> > 
> > Let's continue the removal of old platforms. We already get rid of 
> > Exynos4212.
> > Now it's time for Exynos5440.
> >
> > The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting
> > server platforms but it did not make it to the market really.  There are
> > no development boards with it and probably there are no real products
> > neither.  The development for Exynos5440 ended in 2013 and since then
> > the platform is in maintenance mode.
> >
> > The only development happening around it is the PCIe driver for Exynos5433
> > (ARMv8). [1]
> >
> > Removing Exynos5440, makes our life slightly easier:
> > 1. Less maintenance,
> > 2. Smaller code, less quirks,
> > 3. No need to preserve (imaginary) backward-compatibility for Exynos PCIe
> >driver (so it is easier to add support for Exynos5433).
> >
> >
> > Because of point (3) above - I left the PCIe and PCIe PHY drivers intact.
> >
> >
> > Dependencies
> > 
> > I think about starting with removal of DTS in some kernel release (patch 
> > 1/10).
> > Then all drivers can be removed/updated - subsystem maintainers can pick 
> > their
> > patches freely.
> >
> > Finally, after getting rid of all Exynos5440 symbols, the last patch 
> > (10/10) will
> > end in arm-soc tree.
> >
> >
> > Any comments?
> 
> I don't see any hard dependency here, if this is all unused, I think we
> can apply both patches 1 and 10 into arm-soc at the same time as merging
> the other patches through the respective subsystem trees.

The only dependency is through Kconfig symbol (SOC_EXYNOS5440).  After
applying 10/10, which removes SOC_EXYNOS5440, some automatic code
testers can complain about non-existing Kconfig option.  That's not big
issue because all this will go away so indeed we could take everything
in one release.


Best regards,
rzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 00/10] ARM: Remove support for Exynos5440

[Arnd Bergmann]

On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski  wrote:
> Hi,
>
>
> Overview
> 
> Let's continue the removal of old platforms. We already get rid of Exynos4212.
> Now it's time for Exynos5440.
>
> The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting
> server platforms but it did not make it to the market really.  There are
> no development boards with it and probably there are no real products
> neither.  The development for Exynos5440 ended in 2013 and since then
> the platform is in maintenance mode.
>
> The only development happening around it is the PCIe driver for Exynos5433
> (ARMv8). [1]
>
> Removing Exynos5440, makes our life slightly easier:
> 1. Less maintenance,
> 2. Smaller code, less quirks,
> 3. No need to preserve (imaginary) backward-compatibility for Exynos PCIe
>driver (so it is easier to add support for Exynos5433).
>
>
> Because of point (3) above - I left the PCIe and PCIe PHY drivers intact.
>
>
> Dependencies
> 
> I think about starting with removal of DTS in some kernel release (patch 
> 1/10).
> Then all drivers can be removed/updated - subsystem maintainers can pick their
> patches freely.
>
> Finally, after getting rid of all Exynos5440 symbols, the last patch (10/10) 
> will
> end in arm-soc tree.
>
>
> Any comments?

I don't see any hard dependency here, if this is all unused, I think we
can apply both patches 1 and 10 into arm-soc at the same time as merging
the other patches through the respective subsystem trees.

  Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 04/10] clk: samsung: Remove support for Exynos5440

[Krzysztof Kozlowski]

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 
---
 .../devicetree/bindings/clock/exynos5440-clock.txt |  28 
 drivers/clk/samsung/Makefile   |   1 -
 drivers/clk/samsung/clk-exynos5440.c   | 167 -
 include/dt-bindings/clock/exynos5440.h |  44 --
 4 files changed, 240 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/clock/exynos5440-clock.txt
 delete mode 100644 drivers/clk/samsung/clk-exynos5440.c
 delete mode 100644 include/dt-bindings/clock/exynos5440.h

diff --git a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
deleted file mode 100644
index c7d227c31e95..
--- a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Samsung Exynos5440 Clock Controller
-
-The Exynos5440 clock controller generates and supplies clock to various
-controllers within the Exynos5440 SoC.
-
-Required Properties:
-
-- compatible: should be "samsung,exynos5440-clock".
-
-- reg: physical base address of the controller and length of memory mapped
-  region.
-
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume.
-
-All available clocks are defined as preprocessor macros in
-dt-bindings/clock/exynos5440.h header and can be used in device
-tree sources.
-
-Example: An example of a clock controller node is listed below.
-
-   clock: clock-controller@1001 {
-   compatible = "samsung,exynos5440-clock";
-   reg = <0x16 0x1>;
-   #clock-cells = <1>;
-   };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 513826393158..1a4e6b787978 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -14,7 +14,6 @@ obj-$(CONFIG_SOC_EXYNOS5410)  += clk-exynos5410.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5-subcmu.o
 obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-exynos5433.o
-obj-$(CONFIG_SOC_EXYNOS5440)   += clk-exynos5440.o
 obj-$(CONFIG_EXYNOS_AUDSS_CLK_CON) += clk-exynos-audss.o
 obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos-clkout.o
 obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-exynos7.o
diff --git a/drivers/clk/samsung/clk-exynos5440.c 
b/drivers/clk/samsung/clk-exynos5440.c
deleted file mode 100644
index b08bd54c5e76..
--- a/drivers/clk/samsung/clk-exynos5440.c
+++ /dev/null
@@ -1,167 +0,0 @@
-/*
- * Copyright (c) 2013 Samsung Electronics Co., Ltd.
- * Author: Thomas Abraham 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * Common Clock Framework support for Exynos5440 SoC.
-*/
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "clk.h"
-#include "clk-pll.h"
-
-#define CLKEN_OV_VAL   0xf8
-#define CPU_CLK_STATUS 0xfc
-#define MISC_DOUT1 0x558
-
-static void __iomem *reg_base;
-
-/* parent clock name list */
-PNAME(mout_armclk_p)   = { "cplla", "cpllb" };
-PNAME(mout_spi_p)  = { "div125", "div200" };
-
-/* fixed rate clocks generated outside the soc */
-static struct samsung_fixed_rate_clock exynos5440_fixed_rate_ext_clks[] 
__initdata = {
-   FRATE(0, "xtal", NULL, 0, 0),
-};
-
-/* fixed rate clocks */
-static const struct samsung_fixed_rate_clock exynos5440_fixed_rate_clks[] 
__initconst = {
-   FRATE(0, "ppll", NULL, 0, 10),
-   FRATE(0, "usb_phy0", NULL, 0, 6000),
-   FRATE(0, "usb_phy1", NULL, 0, 6000),
-   FRATE(0, "usb_ohci12", NULL, 0, 1200),
-   FRATE(0, "usb_ohci48", NULL, 0, 4800),
-};
-
-/* fixed factor clocks */
-static const struct samsung_fixed_factor_clock exynos5440_fixed_factor_clks[] 
__initconst = {
-   FFACTOR(0, "div250", "ppll", 1, 4, 0),
-   FFACTOR(0, "div200", "ppll", 1, 5, 0),
-   FFACTOR(0, "div125", "div250", 1, 2, 0),
-};
-
-/* mux clocks */
-static const struct samsung_mux_clock exynos5440_mux_clks[] __initconst = {
-   MUX(0, "mout_spi", mout_spi_p, MISC_DOUT1, 5, 1),
-   MUX(CLK_ARM_CLK, "arm_clk", mout_armclk_p, CPU_CLK_STATUS, 0, 1),
-};
-
-/* divider clocks */
-static const struct samsung_div_clock exynos5440_div_clks[] __initconst = {
-   DIV(CLK_SPI_BAUD, "div_spi", "mout_spi", MISC_DOUT1, 3, 2),
-};
-
-/* gate clocks */
-static const struct samsung_gate_clock exynos5440_gate_clks[] __initconst = {
-   GATE(CLK_PB0_250, "pb0_250", "div250", CLKEN_OV_VAL, 3, 0, 0),
-   GATE(CLK_PR0_250, "pr0_250", "div250", CLKEN_OV_VAL, 4, 0, 0),
-   GATE(CLK_PR1_250, "pr1_250", "div250

[RFC 03/10] cpufreq: exynos: Remove support for Exynos5440

[Krzysztof Kozlowski]

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 
---
 .../bindings/cpufreq/cpufreq-exynos5440.txt|  28 --
 drivers/cpufreq/Kconfig.arm|  14 -
 drivers/cpufreq/Makefile   |   1 -
 drivers/cpufreq/exynos5440-cpufreq.c   | 452 -
 4 files changed, 495 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
 delete mode 100644 drivers/cpufreq/exynos5440-cpufreq.c

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
deleted file mode 100644
index caff1a57436f..
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-
-Exynos5440 cpufreq driver

-
-Exynos5440 SoC cpufreq driver for CPU frequency scaling.
-
-Required properties:
-- interrupts: Interrupt to know the completion of cpu frequency change.
-- operating-points: Table of frequencies and voltage CPU could be transitioned 
into,
-   in the decreasing order. Frequency should be in KHz units and voltage
-   should be in microvolts.
-
-Optional properties:
-- clock-latency: Clock monitor latency in microsecond.
-
-All the required listed above must be defined under node cpufreq.
-
-Example:
-
-   cpufreq@16 {
-   compatible = "samsung,exynos5440-cpufreq";
-   reg = <0x16 0x1000>;
-   interrupts = <0 57 0>;
-   operating-points = <
-   100 975000
-   80  925000>;
-   clock-latency = <10>;
-   };
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 7f56fe5183f2..538a4004a2c5 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -81,20 +81,6 @@ config ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
 
  If in doubt, say N.
 
-config ARM_EXYNOS5440_CPUFREQ
-   tristate "SAMSUNG EXYNOS5440"
-   depends on SOC_EXYNOS5440
-   depends on HAVE_CLK && OF
-   select PM_OPP
-   default y
-   help
- This adds the CPUFreq driver for Samsung EXYNOS5440
- SoC. The nature of exynos5440 clock controller is
- different than previous exynos controllers so not using
- the common exynos framework.
-
- If in doubt, say N.
-
 config ARM_HIGHBANK_CPUFREQ
tristate "Calxeda Highbank-based"
depends on ARCH_HIGHBANK && CPUFREQ_DT && REGULATOR
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade3bd02..56724f867f78 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -56,7 +56,6 @@ obj-$(CONFIG_ARM_ARMADA_37XX_CPUFREQ) += armada-37xx-cpufreq.o
 obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ)  += brcmstb-avs-cpufreq.o
 obj-$(CONFIG_ACPI_CPPC_CPUFREQ)+= cppc_cpufreq.o
 obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)   += exynos5440-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
 obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c 
b/drivers/cpufreq/exynos5440-cpufreq.c
deleted file mode 100644
index 932caa386ece..
--- a/drivers/cpufreq/exynos5440-cpufreq.c
+++ /dev/null
@@ -1,452 +0,0 @@
-/*
- * Copyright (c) 2013 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * Amit Daniel Kachhap 
- *
- * EXYNOS5440 - CPU frequency scaling support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/* Register definitions */
-#define XMU_DVFS_CTRL  0x0060
-#define XMU_PMU_P0_7   0x0064
-#define XMU_C0_3_PSTATE0x0090
-#define XMU_P_LIMIT0x00a0
-#define XMU_P_STATUS   0x00a4
-#define XMU_PMUEVTEN   0x00d0
-#define XMU_PMUIRQEN   0x00d4
-#define XMU_PMUIRQ 0x00d8
-
-/* PMU mask and shift definations */
-#define P_VALUE_MASK   0x7
-
-#define XMU_DVFS_CTRL_EN_SHIFT 0
-
-#define P0_7_CPUCLKDEV_SHIFT   21
-#define P0_7_CPUCLKDEV_MASK0x7
-#define P0_7_ATBCLKDEV_SHIFT   18
-#define P0_7_ATBCLKDEV_MASK0x7
-#define P0_7_CSCLKDEV_SHIFT15
-#define P0_7_CSCLKDEV_MASK 0x7
-#define P0_7_CPUEMA_SHIFT  28
-#define P0_7_CPUEMA_MASK   0xf
-#define P0_7_L2EMA_SHIFT   24
-#define P0_7_L2EMA_MASK0xf
-#define

[RFC 06/10] thermal: samsung: Remove support for Exynos5440

[Krzysztof Kozlowski]

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 
---
 .../devicetree/bindings/thermal/exynos-thermal.txt |  14 +-
 drivers/thermal/samsung/exynos_tmu.c   | 155 +
 drivers/thermal/samsung/exynos_tmu.h   |   1 -
 3 files changed, 4 insertions(+), 166 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index b957acff57aa..ad648d93d961 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -12,7 +12,6 @@
   "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
Exynos5420 (Must pass triminfo base and triminfo clock)
"samsung,exynos5433-tmu"
-  "samsung,exynos5440-tmu"
   "samsung,exynos7-tmu"
 - interrupt-parent : The phandle for the interrupt controller
 - reg : Address range of the thermal registers. For soc's which has multiple
@@ -68,18 +67,7 @@ Example 1):
#thermal-sensor-cells = <0>;
};
 
-Example 2):
-
-   tmuctrl_0: tmuctrl@160118 {
-   compatible = "samsung,exynos5440-tmu";
-   reg = <0x160118 0x230>, <0x160368 0x10>;
-   interrupts = <0 58 0>;
-   clocks = <&clock 21>;
-   clock-names = "tmu_apbif";
-   #thermal-sensor-cells = <0>;
-   };
-
-Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
+Example 2): (In case of Exynos5420 "with misplaced TRIMINFO register")
tmu_cpu2: tmu@10068000 {
compatible = "samsung,exynos5420-tmu-ext-triminfo";
reg = <0x10068000 0x100>, <0x1006c000 0x4>;
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index ed805c7c5ace..f92f470bce21 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -123,28 +123,6 @@
 
 #define EXYNOS5433_PD_DET_EN   1
 
-/*exynos5440 specific registers*/
-#define EXYNOS5440_TMU_S0_7_TRIM   0x000
-#define EXYNOS5440_TMU_S0_7_CTRL   0x020
-#define EXYNOS5440_TMU_S0_7_DEBUG  0x040
-#define EXYNOS5440_TMU_S0_7_TEMP   0x0f0
-#define EXYNOS5440_TMU_S0_7_TH00x110
-#define EXYNOS5440_TMU_S0_7_TH10x130
-#define EXYNOS5440_TMU_S0_7_TH20x150
-#define EXYNOS5440_TMU_S0_7_IRQEN  0x210
-#define EXYNOS5440_TMU_S0_7_IRQ0x230
-/* exynos5440 common registers */
-#define EXYNOS5440_TMU_IRQ_STATUS  0x000
-#define EXYNOS5440_TMU_PMIN0x004
-
-#define EXYNOS5440_TMU_INTEN_RISE0_SHIFT   0
-#define EXYNOS5440_TMU_INTEN_RISE1_SHIFT   1
-#define EXYNOS5440_TMU_INTEN_RISE2_SHIFT   2
-#define EXYNOS5440_TMU_INTEN_RISE3_SHIFT   3
-#define EXYNOS5440_TMU_INTEN_FALL0_SHIFT   4
-#define EXYNOS5440_TMU_TH_RISE4_SHIFT  24
-#define EXYNOS5440_EFUSE_SWAP_OFFSET   8
-
 /* Exynos7 specific registers */
 #define EXYNOS7_THD_TEMP_RISE7_6   0x50
 #define EXYNOS7_THD_TEMP_FALL7_6   0x60
@@ -614,57 +592,6 @@ static int exynos5433_tmu_initialize(struct 
platform_device *pdev)
return ret;
 }
 
-static int exynos5440_tmu_initialize(struct platform_device *pdev)
-{
-   struct exynos_tmu_data *data = platform_get_drvdata(pdev);
-   unsigned int trim_info = 0, con, rising_threshold;
-   int threshold_code;
-   int crit_temp = 0;
-
-   /*
-* For exynos5440 soc triminfo value is swapped between TMU0 and
-* TMU2, so the below logic is needed.
-*/
-   switch (data->id) {
-   case 0:
-   trim_info = readl(data->base + EXYNOS5440_EFUSE_SWAP_OFFSET +
-EXYNOS5440_TMU_S0_7_TRIM);
-   break;
-   case 1:
-   trim_info = readl(data->base + EXYNOS5440_TMU_S0_7_TRIM);
-   break;
-   case 2:
-   trim_info = readl(data->base - EXYNOS5440_EFUSE_SWAP_OFFSET +
- EXYNOS5440_TMU_S0_7_TRIM);
-   }
-   sanitize_temp_error(data, trim_info);
-
-   /* Write temperature code for rising and falling threshold */
-   rising_threshold = readl(data->base + EXYNOS5440_TMU_S0_7_TH0);
-   rising_threshold = get_th_reg(data, rising_threshold, false);
-   writel(rising_threshold, data->base + EXYNOS5440_TMU_S0_7_TH0);
-   writel(0, data->base + EXYNOS5440_TMU_S0_7_TH1);
-
-   data->tmu_clear_irqs(data);
-
-   /* if last threshold limit is also present */
-   if (!data->tzd->ops->get_crit_temp(data->tzd, &crit_temp)) {
-   t

[RFC 02/10] ata: ahci-platform: Remove support for Exynos5440

[Krzysztof Kozlowski]

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 
---
 Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 -
 drivers/ata/ahci_platform.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt 
b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index c760ecb81381..663766685818 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -17,7 +17,6 @@ Required properties:
   - "marvell,armada-380-ahci"
   - "marvell,armada-3700-ahci"
   - "snps,dwc-ahci"
-  - "snps,exynos5440-ahci"
   - "snps,spear-ahci"
   - "generic-ahci"
 - interrupts: 
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a895a459..564570ea3e27 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -75,7 +75,6 @@ static const struct of_device_id ahci_of_match[] = {
{ .compatible = "generic-ahci", },
/* Keep the following compatibles for device tree compatibility */
{ .compatible = "snps,spear-ahci", },
-   { .compatible = "snps,exynos5440-ahci", },
{ .compatible = "ibm,476gtr-ahci", },
{ .compatible = "snps,dwc-ahci", },
{ .compatible = "hisilicon,hisi-ahci", },
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 07/10] pinctrl: samsung: Remove support for Exynos5440

[Krzysztof Kozlowski]

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/pinctrl/samsung/Kconfig  |   10 +-
 drivers/pinctrl/samsung/Makefile |1 -
 drivers/pinctrl/samsung/pinctrl-exynos5440.c | 1005 --
 3 files changed, 2 insertions(+), 1014 deletions(-)
 delete mode 100644 drivers/pinctrl/samsung/pinctrl-exynos5440.c

diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
index 11b5eeb14c4a..425fadd6c346 100644
--- a/drivers/pinctrl/samsung/Kconfig
+++ b/drivers/pinctrl/samsung/Kconfig
@@ -8,26 +8,20 @@ config PINCTRL_SAMSUNG
select PINCONF
 
 config PINCTRL_EXYNOS
-   bool "Pinctrl driver data for Samsung EXYNOS SoCs other than 5440"
+   bool "Pinctrl driver data for Samsung EXYNOS SoCs"
depends on OF && GPIOLIB && (ARCH_EXYNOS || ARCH_S5PV210)
select PINCTRL_SAMSUNG
select PINCTRL_EXYNOS_ARM if ARM && (ARCH_EXYNOS || ARCH_S5PV210)
select PINCTRL_EXYNOS_ARM64 if ARM64 && ARCH_EXYNOS
 
 config PINCTRL_EXYNOS_ARM
-   bool "ARMv7-specific pinctrl driver data for Exynos (except 
Exynos5440)" if COMPILE_TEST
+   bool "ARMv7-specific pinctrl driver data for Exynos" if COMPILE_TEST
depends on PINCTRL_EXYNOS
 
 config PINCTRL_EXYNOS_ARM64
bool "ARMv8-specific pinctrl driver data for Exynos" if COMPILE_TEST
depends on PINCTRL_EXYNOS
 
-config PINCTRL_EXYNOS5440
-   bool "Samsung EXYNOS5440 SoC pinctrl driver"
-   depends on SOC_EXYNOS5440
-   select PINMUX
-   select PINCONF
-
 config PINCTRL_S3C24XX
bool "Samsung S3C24XX SoC pinctrl driver"
depends on ARCH_S3C24XX && OF
diff --git a/drivers/pinctrl/samsung/Makefile b/drivers/pinctrl/samsung/Makefile
index df426561d067..ed951df6a112 100644
--- a/drivers/pinctrl/samsung/Makefile
+++ b/drivers/pinctrl/samsung/Makefile
@@ -5,6 +5,5 @@ obj-$(CONFIG_PINCTRL_SAMSUNG)   += pinctrl-samsung.o
 obj-$(CONFIG_PINCTRL_EXYNOS)   += pinctrl-exynos.o
 obj-$(CONFIG_PINCTRL_EXYNOS_ARM)   += pinctrl-exynos-arm.o
 obj-$(CONFIG_PINCTRL_EXYNOS_ARM64) += pinctrl-exynos-arm64.o
-obj-$(CONFIG_PINCTRL_EXYNOS5440)   += pinctrl-exynos5440.o
 obj-$(CONFIG_PINCTRL_S3C24XX)  += pinctrl-s3c24xx.o
 obj-$(CONFIG_PINCTRL_S3C64XX)  += pinctrl-s3c64xx.o
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos5440.c 
b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
deleted file mode 100644
index 3d8d5e812839..
--- a/drivers/pinctrl/samsung/pinctrl-exynos5440.c
+++ /dev/null
@@ -1,1005 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-//
-// pin-controller/pin-mux/pin-config/gpio-driver for Samsung's EXYNOS5440 SoC.
-//
-// Author: Thomas Abraham 
-//
-// Copyright (c) 2012 Samsung Electronics Co., Ltd.
-// http://www.samsung.com
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "../core.h"
-
-/* EXYNOS5440 GPIO and Pinctrl register offsets */
-#define GPIO_MUX   0x00
-#define GPIO_IE0x04
-#define GPIO_INT   0x08
-#define GPIO_TYPE  0x0C
-#define GPIO_VAL   0x10
-#define GPIO_OE0x14
-#define GPIO_IN0x18
-#define GPIO_PE0x1C
-#define GPIO_PS0x20
-#define GPIO_SR0x24
-#define GPIO_DS0   0x28
-#define GPIO_DS1   0x2C
-
-#define EXYNOS5440_MAX_PINS23
-#define EXYNOS5440_MAX_GPIO_INT8
-#define PIN_NAME_LENGTH10
-
-#define GROUP_SUFFIX   "-grp"
-#define FUNCTION_SUFFIX"-mux"
-
-/*
- * pin configuration type and its value are packed together into a 16-bits.
- * The upper 8-bits represent the configuration type and the lower 8-bits
- * hold the value of the configuration type.
- */
-#define PINCFG_TYPE_MASK   0xFF
-#define PINCFG_VALUE_SHIFT 8
-#define PINCFG_VALUE_MASK  (0xFF << PINCFG_VALUE_SHIFT)
-#define PINCFG_PACK(type, value)   (((value) << PINCFG_VALUE_SHIFT) | type)
-#define PINCFG_UNPACK_TYPE(cfg)((cfg) & PINCFG_TYPE_MASK)
-#define PINCFG_UNPACK_VALUE(cfg)   (((cfg) & PINCFG_VALUE_MASK) >> \
-   PINCFG_VALUE_SHIFT)
-
-/**
- * enum pincfg_type - possible pin configuration types supported.
- * @PINCFG_TYPE_PUD: Pull up/down configuration.
- * @PINCFG_TYPE_DRV: Drive strength configuration.
- * @PINCFG_TYPE_SKEW_RATE: Skew rate configuration.
- * @PINCFG_TYPE_INPUT_TYPE: Pin input type configuration.
- */
-enum pincfg_type {
-   PINCFG_TYPE_PUD,
-   PINCFG_TYPE_DRV,
-   PINCFG_TYPE_SKEW_RATE,
-   PINCFG_TYPE_INPUT_TYPE
-};
-
-/**
- * struct exynos5440_

[RFC 10/10] ARM: exynos: Remove support for Exynos5440

[Krzysztof Kozlowski]

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/Kconfig  | 12 
 arch/arm/mach-exynos/common.h |  8 
 arch/arm/mach-exynos/exynos.c | 15 ++-
 3 files changed, 2 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 647c319f9f5f..219d389a8521 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -108,18 +108,6 @@ config SOC_EXYNOS5420
default y
depends on ARCH_EXYNOS5
 
-config SOC_EXYNOS5440
-   bool "SAMSUNG EXYNOS5440"
-   default y
-   depends on ARCH_EXYNOS5
-   select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
-   select HAVE_ARM_ARCH_TIMER
-   select AUTO_ZRELADDR
-   select PINCTRL_EXYNOS5440
-   select PM_OPP
-   help
- Enable EXYNOS5440 SoC support
-
 config SOC_EXYNOS5800
bool "SAMSUNG EXYNOS5800"
default y
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 098f84a149a3..f332c654784b 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -21,7 +21,6 @@
 #define EXYNOS5250_SOC_ID  0x4352
 #define EXYNOS5410_SOC_ID  0xE541
 #define EXYNOS5420_SOC_ID  0xE542
-#define EXYNOS5440_SOC_ID  0xE544
 #define EXYNOS5800_SOC_ID  0xE5422000
 #define EXYNOS5_SOC_MASK   0xF000
 
@@ -39,7 +38,6 @@ IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, 
EXYNOS4_CPU_MASK)
 IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)
 IS_SAMSUNG_CPU(exynos5410, EXYNOS5410_SOC_ID, EXYNOS5_SOC_MASK)
 IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK)
-IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
 IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK)
 
 #if defined(CONFIG_SOC_EXYNOS3250)
@@ -82,12 +80,6 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, 
EXYNOS5_SOC_MASK)
 # define soc_is_exynos5420()   0
 #endif
 
-#if defined(CONFIG_SOC_EXYNOS5440)
-# define soc_is_exynos5440()   is_samsung_exynos5440()
-#else
-# define soc_is_exynos5440()   0
-#endif
-
 #if defined(CONFIG_SOC_EXYNOS5800)
 # define soc_is_exynos5800()   is_samsung_exynos5800()
 #else
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 8c4f5e342dc1..460ae13b3145 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -63,15 +63,6 @@ void __init exynos_sysram_init(void)
}
 }
 
-static void __init exynos_init_late(void)
-{
-   if (of_machine_is_compatible("samsung,exynos5440"))
-   /* to be supported later */
-   return;
-
-   exynos_pm_init();
-}
-
 static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
int depth, void *data)
 {
@@ -79,8 +70,7 @@ static int __init exynos_fdt_map_chipid(unsigned long node, 
const char *uname,
const __be32 *reg;
int len;
 
-   if (!of_flat_dt_is_compatible(node, "samsung,exynos4210-chipid") &&
-   !of_flat_dt_is_compatible(node, "samsung,exynos5440-clock"))
+   if (!of_flat_dt_is_compatible(node, "samsung,exynos4210-chipid"))
return 0;
 
reg = of_get_flat_dt_prop(node, "reg", &len);
@@ -209,7 +199,6 @@ static char const *const exynos_dt_compat[] __initconst = {
"samsung,exynos5250",
"samsung,exynos5260",
"samsung,exynos5420",
-   "samsung,exynos5440",
NULL
 };
 
@@ -232,7 +221,7 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened 
Device Tree)")
.init_early = exynos_firmware_init,
.init_irq   = exynos_init_irq,
.init_machine   = exynos_dt_machine_init,
-   .init_late  = exynos_init_late,
+   .init_late  = exynos_pm_init,
.dt_compat  = exynos_dt_compat,
.dt_fixup   = exynos_dt_fixup,
 MACHINE_END
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 09/10] usb: host: exynos: Remove support for Exynos5440

[Krzysztof Kozlowski]

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/usb/host/ehci-exynos.c | 7 ---
 drivers/usb/host/ohci-exynos.c | 6 --
 2 files changed, 13 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index d9145a8f35d2..8e3bab1e0c1f 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -161,16 +161,10 @@ static int exynos_ehci_probe(struct platform_device *pdev)
}
exynos_ehci = to_exynos_ehci(hcd);
 
-   if (of_device_is_compatible(pdev->dev.of_node,
-   "samsung,exynos5440-ehci"))
-   goto skip_phy;
-
err = exynos_ehci_get_phy(&pdev->dev, exynos_ehci);
if (err)
goto fail_clk;
 
-skip_phy:
-
exynos_ehci->clk = devm_clk_get(&pdev->dev, "usbhost");
 
if (IS_ERR(exynos_ehci->clk)) {
@@ -304,7 +298,6 @@ static const struct dev_pm_ops exynos_ehci_pm_ops = {
 #ifdef CONFIG_OF
 static const struct of_device_id exynos_ehci_match[] = {
{ .compatible = "samsung,exynos4210-ehci" },
-   { .compatible = "samsung,exynos5440-ehci" },
{},
 };
 MODULE_DEVICE_TABLE(of, exynos_ehci_match);
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index a39fae41bc70..c0c4dcca6f3c 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -130,15 +130,10 @@ static int exynos_ohci_probe(struct platform_device *pdev)
 
exynos_ohci = to_exynos_ohci(hcd);
 
-   if (of_device_is_compatible(pdev->dev.of_node,
-   "samsung,exynos5440-ohci"))
-   goto skip_phy;
-
err = exynos_ohci_get_phy(&pdev->dev, exynos_ohci);
if (err)
goto fail_clk;
 
-skip_phy:
exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
 
if (IS_ERR(exynos_ohci->clk)) {
@@ -270,7 +265,6 @@ static const struct dev_pm_ops exynos_ohci_pm_ops = {
 #ifdef CONFIG_OF
 static const struct of_device_id exynos_ohci_match[] = {
{ .compatible = "samsung,exynos4210-ohci" },
-   { .compatible = "samsung,exynos5440-ohci" },
{},
 };
 MODULE_DEVICE_TABLE(of, exynos_ohci_match);
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 08/10] spi: s3c64xx: samsung: Remove support for Exynos5440

[Krzysztof Kozlowski]

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/spi/spi-s3c64xx.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 755ab2dc6969..f55dc78957ad 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1376,15 +1376,6 @@ static struct s3c64xx_spi_port_config 
exynos4_spi_port_config = {
.clk_from_cmu   = true,
 };
 
-static struct s3c64xx_spi_port_config exynos5440_spi_port_config = {
-   .fifo_lvl_mask  = { 0x1ff },
-   .rx_lvl_offset  = 15,
-   .tx_st_done = 25,
-   .high_speed = true,
-   .clk_from_cmu   = true,
-   .quirks = S3C64XX_SPI_QUIRK_POLL,
-};
-
 static struct s3c64xx_spi_port_config exynos7_spi_port_config = {
.fifo_lvl_mask  = { 0x1ff, 0x7F, 0x7F, 0x7F, 0x7F, 0x1ff},
.rx_lvl_offset  = 15,
@@ -1428,9 +1419,6 @@ static const struct of_device_id s3c64xx_spi_dt_match[] = 
{
{ .compatible = "samsung,exynos4210-spi",
.data = (void *)&exynos4_spi_port_config,
},
-   { .compatible = "samsung,exynos5440-spi",
-   .data = (void *)&exynos5440_spi_port_config,
-   },
{ .compatible = "samsung,exynos7-spi",
.data = (void *)&exynos7_spi_port_config,
},
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 05/10] i2c: s3c2410: Remove support for Exynos5440

[Krzysztof Kozlowski]

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 
---
 Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt | 4 +---
 drivers/i2c/busses/i2c-s3c2410.c  | 2 --
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt 
b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
index 89b3250f049b..66ae46d3bc2f 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
@@ -8,9 +8,7 @@ Required properties:
   (b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c.
   (c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used
   inside HDMIPHY block found on several samsung SoCs
-  (d) "samsung, exynos5440-i2c", for s3c2440-like i2c used
-  on EXYNOS5440 which does not need GPIO configuration.
-  (e) "samsung, exynos5-sata-phy-i2c", for s3c2440-like i2c used as
+  (d) "samsung, exynos5-sata-phy-i2c", for s3c2440-like i2c used as
   a host to SATA PHY controller on an internal bus.
   - reg: physical base address of the controller and length of memory mapped
 region.
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 5d97510ee48b..9fe2b6951895 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -154,8 +154,6 @@ static const struct of_device_id s3c24xx_i2c_match[] = {
{ .compatible = "samsung,s3c2440-i2c", .data = (void *)QUIRK_S3C2440 },
{ .compatible = "samsung,s3c2440-hdmiphy-i2c",
  .data = (void *)(QUIRK_S3C2440 | QUIRK_HDMIPHY | QUIRK_NO_GPIO) },
-   { .compatible = "samsung,exynos5440-i2c",
- .data = (void *)(QUIRK_S3C2440 | QUIRK_NO_GPIO) },
{ .compatible = "samsung,exynos5-sata-phy-i2c",
  .data = (void *)(QUIRK_S3C2440 | QUIRK_POLL | QUIRK_NO_GPIO) },
{},
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 01/10] ARM: dts: exynos: Remove Exynos5440

[Krzysztof Kozlowski]

The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting
server platforms but it did not make it to the market really.  There are
no development boards with it and probably there are no real products
neither.  The development for Exynos5440 ended in 2013 and since then
the platform is in maintenance mode.

Remove all Device Tree sources for Exynos5440, as first step of removal
of the platform to simplify the code and drivers.

Signed-off-by: Krzysztof Kozlowski 
---
 .../bindings/arm/samsung/samsung-boards.txt|   2 -
 arch/arm/boot/dts/Makefile |   2 -
 arch/arm/boot/dts/exynos5440-sd5v1.dts |  42 ---
 arch/arm/boot/dts/exynos5440-ssdk5440.dts  |  81 -
 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi  |  20 --
 arch/arm/boot/dts/exynos5440-trip-points.dtsi  |  21 --
 arch/arm/boot/dts/exynos5440.dtsi  | 355 -
 7 files changed, 523 deletions(-)
 delete mode 100644 arch/arm/boot/dts/exynos5440-sd5v1.dts
 delete mode 100644 arch/arm/boot/dts/exynos5440-ssdk5440.dts
 delete mode 100644 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
 delete mode 100644 arch/arm/boot/dts/exynos5440-trip-points.dtsi
 delete mode 100644 arch/arm/boot/dts/exynos5440.dtsi

diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt 
b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
index 14510b215480..bdadc3da9556 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
@@ -21,8 +21,6 @@ Required root node properties:
- "samsung,smdk5420"- for Exynos5420-based Samsung SMDK5420 eval 
board.
- "samsung,tm2" - for Exynos5433-based Samsung TM2 board.
- "samsung,tm2e"- for Exynos5433-based Samsung TM2E board.
-   - "samsung,sd5v1"   - for Exynos5440-based Samsung board.
-   - "samsung,ssdk5440"- for Exynos5440-based Samsung board.
 
 * Other companies Exynos SoC based
   * FriendlyARM
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9ea57f8ebc4e..bf098f59fd0a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -191,8 +191,6 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5422-odroidxu3.dtb \
exynos5422-odroidxu3-lite.dtb \
exynos5422-odroidxu4.dtb \
-   exynos5440-sd5v1.dtb \
-   exynos5440-ssdk5440.dtb \
exynos5800-peach-pi.dtb
 dtb-$(CONFIG_ARCH_GEMINI) += \
gemini-dlink-dir-685.dtb \
diff --git a/arch/arm/boot/dts/exynos5440-sd5v1.dts 
b/arch/arm/boot/dts/exynos5440-sd5v1.dts
deleted file mode 100644
index c4b8392d1ae1..
--- a/arch/arm/boot/dts/exynos5440-sd5v1.dts
+++ /dev/null
@@ -1,42 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * SAMSUNG SD5v1 board device tree source
- *
- * Copyright (c) 2013 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- */
-
-/dts-v1/;
-#include "exynos5440.dtsi"
-
-/ {
-   model = "SAMSUNG SD5v1 board based on EXYNOS5440";
-   compatible = "samsung,sd5v1", "samsung,exynos5440", "samsung,exynos5";
-
-   chosen {
-   bootargs = "root=/dev/sda2 rw rootwait ignore_loglevel 
earlyprintk no_console_suspend mem=2048M@0x8000 mem=6144M@0x1 
console=ttySAC0,115200";
-   };
-
-   /* FIXME: set reg property with correct start address and size */
-   memory@0 {
-   device_type = "memory";
-   reg = <0 0>;
-   };
-
-   fixed-rate-clocks {
-   xtal {
-   compatible = "samsung,clock-xtal";
-   clock-frequency = <5000>;
-   };
-   };
-
-   spi {
-   status = "disabled";
-   };
-
-};
-
-&gmac {
-   fixed_phy;
-   phy_addr = <1>;
-};
diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts 
b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
deleted file mode 100644
index a33c4fc29ae5..
--- a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
+++ /dev/null
@@ -1,81 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * SAMSUNG SSDK5440 board device tree source
- *
- * Copyright (c) 2012 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- */
-
-/dts-v1/;
-#include "exynos5440.dtsi"
-#include 
-
-/ {
-   model = "SAMSUNG SSDK5440 board based on EXYNOS5440";
-   compatible = "samsung,ssdk5440", "samsung,exynos5440", 
"samsung,exynos5";
-
-   chosen {
-   bootargs = "root=/dev/sda2 rw rootwait ignore_loglevel 
earlyprintk no_console_suspend mem=2048M@0x8000 mem=6144M@0x1 
console=ttySAC0,115200";
-   };
-
-   /* FIXME: set reg property with correct start address and size */
-   memory@0 {
-   device_type = "memory";
-   reg = <0 0>;
-   };
-
-   fixed-rate-clocks {
-   xtal {
-   compatible = "samsung,clock-xtal"

[RFC 00/10] ARM: Remove support for Exynos5440

[Krzysztof Kozlowski]

Hi,


Overview

Let's continue the removal of old platforms. We already get rid of Exynos4212.
Now it's time for Exynos5440.

The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting
server platforms but it did not make it to the market really.  There are
no development boards with it and probably there are no real products
neither.  The development for Exynos5440 ended in 2013 and since then
the platform is in maintenance mode.

The only development happening around it is the PCIe driver for Exynos5433
(ARMv8). [1]

Removing Exynos5440, makes our life slightly easier:
1. Less maintenance,
2. Smaller code, less quirks,
3. No need to preserve (imaginary) backward-compatibility for Exynos PCIe
   driver (so it is easier to add support for Exynos5433).


Because of point (3) above - I left the PCIe and PCIe PHY drivers intact.


Dependencies

I think about starting with removal of DTS in some kernel release (patch 1/10).
Then all drivers can be removed/updated - subsystem maintainers can pick their
patches freely.

Finally, after getting rid of all Exynos5440 symbols, the last patch (10/10) 
will
end in arm-soc tree.


Any comments?


Best regards,
Krzysztof

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1569919.html

Krzysztof Kozlowski (10):
  ARM: dts: exynos: Remove Exynos5440
  ata: ahci-platform: Remove support for Exynos5440
  cpufreq: exynos: Remove support for Exynos5440
  clk: samsung: Remove support for Exynos5440
  i2c: s3c2410: Remove support for Exynos5440
  thermal: samsung: Remove support for Exynos5440
  pinctrl: samsung: Remove support for Exynos5440
  spi: s3c64xx: samsung: Remove support for Exynos5440
  usb: host: exynos: Remove support for Exynos5440
  ARM: exynos: Remove support for Exynos5440

 .../bindings/arm/samsung/samsung-boards.txt|2 -
 .../devicetree/bindings/ata/ahci-platform.txt  |1 -
 .../devicetree/bindings/clock/exynos5440-clock.txt |   28 -
 .../bindings/cpufreq/cpufreq-exynos5440.txt|   28 -
 .../devicetree/bindings/i2c/i2c-s3c2410.txt|4 +-
 .../devicetree/bindings/thermal/exynos-thermal.txt |   14 +-
 arch/arm/boot/dts/Makefile |2 -
 arch/arm/boot/dts/exynos5440-sd5v1.dts |   42 -
 arch/arm/boot/dts/exynos5440-ssdk5440.dts  |   81 --
 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi  |   20 -
 arch/arm/boot/dts/exynos5440-trip-points.dtsi  |   21 -
 arch/arm/boot/dts/exynos5440.dtsi  |  355 ---
 arch/arm/mach-exynos/Kconfig   |   12 -
 arch/arm/mach-exynos/common.h  |8 -
 arch/arm/mach-exynos/exynos.c  |   15 +-
 drivers/ata/ahci_platform.c|1 -
 drivers/clk/samsung/Makefile   |1 -
 drivers/clk/samsung/clk-exynos5440.c   |  167 
 drivers/cpufreq/Kconfig.arm|   14 -
 drivers/cpufreq/Makefile   |1 -
 drivers/cpufreq/exynos5440-cpufreq.c   |  452 -
 drivers/i2c/busses/i2c-s3c2410.c   |2 -
 drivers/pinctrl/samsung/Kconfig|   10 +-
 drivers/pinctrl/samsung/Makefile   |1 -
 drivers/pinctrl/samsung/pinctrl-exynos5440.c   | 1005 
 drivers/spi/spi-s3c64xx.c  |   12 -
 drivers/thermal/samsung/exynos_tmu.c   |  155 +--
 drivers/thermal/samsung/exynos_tmu.h   |1 -
 drivers/usb/host/ehci-exynos.c |7 -
 drivers/usb/host/ohci-exynos.c |6 -
 include/dt-bindings/clock/exynos5440.h |   44 -
 31 files changed, 9 insertions(+), 2503 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/clock/exynos5440-clock.txt
 delete mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
 delete mode 100644 arch/arm/boot/dts/exynos5440-sd5v1.dts
 delete mode 100644 arch/arm/boot/dts/exynos5440-ssdk5440.dts
 delete mode 100644 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
 delete mode 100644 arch/arm/boot/dts/exynos5440-trip-points.dtsi
 delete mode 100644 arch/arm/boot/dts/exynos5440.dtsi
 delete mode 100644 drivers/clk/samsung/clk-exynos5440.c
 delete mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
 delete mode 100644 drivers/pinctrl/samsung/pinctrl-exynos5440.c
 delete mode 100644 include/dt-bindings/clock/exynos5440.h

-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Request for information how to disable USB bulk endpoint transfer validation

[Elvinas]

Hello,

On 04/23/2018 11:50 PM, Alan Stern wrote:


In ZWO forums there was a suggestion to revert USB packet validation by applying a 
"break"
to Linux kernel. With some changes to line locations I have applied the patch 
below and
camera started to work on a desktop with USB 2.0 host.


The patch you wrote isn't ideal; the one below is better.  In fact, the
code should be like this already.  It was an oversight.

Well, that was not my patch. I have just updated line numbers.


Question: can anyone point what lines should be commented out to ignore packet 
sizes for
USB 2.0 device, when attached to USB 3.0 host?


As far as I know, there is no way to do this.  USB-3 xHCI host
controllers validate maxpacket sizes in the hardware, not in software,
and there isn't any way to change the hardware's behavior.  But I am
not an expert on xHCI.

Does the camera work when attached to a USB-3 host controller on a
computer running Windows or Mac OS X?


It looks you are right. Camera does not work properly on a Windows computer with USB 3.0 
host. So it may be as you said - data is validated by hardware, device does not work and I 
will have thrown some money out.


Anyway thanks for the help

--

Informatikas - diagnozė, o ne specialybė
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb:serial:optrion: fix dwm-158 3g modem interface

[Johan Hovold]

On Mon, Apr 23, 2018 at 11:21:32PM -0500, Dan Williams wrote:
> On Tue, 2018-04-24 at 09:55 +0700, Lars Melin wrote:
> > On 4/23/2018 23:54, Dan Williams wrote:
> > 
> > > > MI_00 D-Link Mobile Broadband Device  (cdc_ether)
> > > > MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp m
> > > > MI_03 D-Link HSPA+DataCard NMEA Device
> > > > MI_04 D-Link HSPA+DataCard Speech Port
> > > 
> > > Any idea what format this port speaks?  Some Huawei Qualcomm-based
> > > devices still use a TTY driver but send/receive 16-bit 8000hz PCM
> > > audio
> > > frames via a serial port.  If the D-Link does something similar, it
> > > may
> > > still make sense to drive it via option.
> > > 
> > > > MI_05 D-Link HSPA+DataCard Debug Port
> > > 
> > > If it's FCCID KA2WM158B1 then it's a Qualcomm device, and this port
> > > may
> > > be a DIAG port.  It should also be driven by option if that's the
> > > case.
> > > 
> > > I looked but couldn't find downloadable drivers for the DWM-158 so
> > > I
> > > couldn't double-check myself.
> > > 
> > > Dan
> > 
> > This is a DWM-158D1 or maybe they have versioned it E1, it is
> > Mediatek 
> > based.
> 
> Fair enough, then it certainly won't have DM/DIAG.

Thanks for verifying. I'll go drop the stable tags from this one just in
case.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb:serial:optrion: fix dwm-158 3g modem interface

[Johan Hovold]

On Mon, Apr 23, 2018 at 11:54:32AM -0500, Dan Williams wrote:
> On Mon, 2018-04-23 at 14:14 +0700, Lars Melin wrote:

> > Blacklisting interface 4 and 5 is correct because:
> > 
> > MI_00 D-Link Mobile Broadband Device  (cdc_ether)
> > MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp modem)
> > MI_03 D-Link HSPA+DataCard NMEA Device
> > MI_04 D-Link HSPA+DataCard Speech Port
> 
> Any idea what format this port speaks?  Some Huawei Qualcomm-based
> devices still use a TTY driver but send/receive 16-bit 8000hz PCM audio
> frames via a serial port.

Wow. Shouldn't this really be handled by an ALSA driver?

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

[Sedat Dilek]

On Tue, Apr 24, 2018 at 5:22 PM, Linus Torvalds
 wrote:
> On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek  wrote:
>>
>> $ objdump -S clang-eflag.o
>>
>> Does this now look good?
>
> Looks fine to me. The instruction choice is still pretty odd:
>
>   1a:   f6 c3 fftest   $0xff,%bl
>   1d:   74 02   je 21 
>
> that "test   $0xff,%bl" is a rather odd way of testing the byte for zero, 
> since
>
>   1a:   84 dbtest   %bl,%bl
>   1c:   74 02   je 20 
>
> would have been a byte shorter and is the canonical way on x86 to test
> a register against zero.
>
> But that's just a "looks odd to somebody who is used to x86 asm", not
> a bug or anything really noticeable.
>
>   Linus

Thanks for the quick reply and the confirmation.

Personally, I do not speak x86/asm.
I hope CCed LLVM folks know on how to improve things.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

[Linus Torvalds]

On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek  wrote:
>
> $ objdump -S clang-eflag.o
>
> Does this now look good?

Looks fine to me. The instruction choice is still pretty odd:

  1a:   f6 c3 fftest   $0xff,%bl
  1d:   74 02   je 21 

that "test   $0xff,%bl" is a rather odd way of testing the byte for zero, since

  1a:   84 dbtest   %bl,%bl
  1c:   74 02   je 20 

would have been a byte shorter and is the canonical way on x86 to test
a register against zero.

But that's just a "looks odd to somebody who is used to x86 asm", not
a bug or anything really noticeable.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 02/11] dt-bindings: usb: add usb role switch driver

[Rob Herring]

On Wed, Apr 18, 2018 at 05:09:56PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a new documentation for a usb role switch driver.
> The usb role switch framework will parse this to get each device
> pointer by using each remote-endpoint.

Bindings describe h/w, not drivers. This doesn't look like a h/w device.

> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  .../devicetree/bindings/usb/usb-role-switch.txt| 42 
> ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb-role-switch.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-role-switch.txt 
> b/Documentation/devicetree/bindings/usb/usb-role-switch.txt
> new file mode 100644
> index 000..941d582
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-role-switch.txt
> @@ -0,0 +1,42 @@
> +USB role switch driver
> +
> +Optional nodes:
> +- If a role switch driver has OF graph ports, the usb role switch framework
> +  will parse the remote-endpoints in usb_role_switch_register(). The OF graph
> +  port number as follows:
> +0: USB 2.0 host port
> +1: USB 3.0 host port
> +2: UDC port
> +
> +For example:
> + usb-role-sw {
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + usb2_host_sw0: endpoint {
> + remote-endpoint = <&usb2_host_ep0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + usb3_host_sw0: endpoint {
> + remote-endpoint = <&usb3_host_ep0>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + udc_sw0: endpoint {
> + remote-endpoint = <&udc_ep0>;
> + };
> + };
> + };
> + };
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 01/11] Documentation: of: Add device-connection-id property

[Rob Herring]

On Wed, Apr 18, 2018 at 05:09:55PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a new property for device connection framework.

What's the "device connection framework" and what does it have to do 
with DT?

> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/graph.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/graph.txt 
> b/Documentation/devicetree/bindings/graph.txt
> index 0415e2c..fca0030 100644
> --- a/Documentation/devicetree/bindings/graph.txt
> +++ b/Documentation/devicetree/bindings/graph.txt
> @@ -125,4 +125,4 @@ Optional endpoint properties
>  
>  
>  - remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
> -
> +- device-connection-id: string for device connection.

Why do we need this?

> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] doc: usb: ci-hdrc-usb2: Add property "mux-controls"

[Rob Herring]

On Tue, Apr 17, 2018 at 04:53:25PM +0300, Yossi Mansharoff wrote:
> The chipidea usb controller may be connected, in some platforms,
> to an external mux to toggle between different usb ports for
> different roles (host and device).
> 
> The mux-controller property, if set, binds the chipidea usb
> controller with a mux for this use.
> 
> Signed-off-by: Yossi Mansharoff 
> ---
>  Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 6 ++
>  1 file changed, 6 insertions(+)

Reviewed-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 0/6] typec: tcpm: Add sink side support for PPS

[Greg Kroah-Hartman]

On Mon, Apr 23, 2018 at 03:10:55PM +0100, Adam Thomson wrote:
> This patch set adds sink side support for the PPS feature introduced in the
> USB PD 3.0 specification.
> 
> The source PPS supply is represented using the Power Supply framework to 
> provide
> access and control APIs for dealing with it's operating voltage and current,
> and switching between a standard PDO and PPS APDO operation. During standard 
> PDO
> operation the voltage and current is read-only, but for APDO PPS these are
> writable as well to allow for control.
> 
> It should be noted that the keepalive for PPS is not handled within TCPM. The
> expectation is that the external user will be required to ensure re-requests
> occur regularly to ensure PPS remains and the source does not hard reset.

Sebastian, any objection from me taking this series through my USB tree?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

[Alan Stern]

On Tue, 24 Apr 2018, Mathias Nyman wrote:

> >>> In this situation, the HCD_WAKEUP_PENDING(hcd) test in
> >>> hcd-pci.c:suspend_common() should prevent the controller from going
> >>> back into D3.  The WAKEUP_PENDING bit gets set in
> >>> usb_hcd_resume_root_hub() and it doesn't get cleared until
> >>> hcd_bus_resume() runs.
> >>>
> >>
> >> I think xhci never calls usb_hcd_resume_root_hub() in xhci_resume() in this
> >> specific failing case
> >>
> >> xhci_resume() has a check:
> >> /* Resume root hubs only when have pending events. */
> >> status = readl(&xhci->op_regs->status);
> >>   if (status & STS_EINT) {
> >> usb_hcd_resume_root_hub(xhci->shared_hcd);
> >> usb_hcd_resume_root_hub(hcd);
> >>   }
> >>
> >> If the check fails, then WAKEUP_PENDING bit is not set, and runtime PM
> >> can suspend host controller again. when xhci driver finally gets to handle 
> >> the interrupt
> >> the controller may be in D3 already
> >>
> >> This should only happen if xhci_resume() is called before xhci driver sees 
> >> a pending interrupt,
> >> could be possible as xhci has interrupt moderation enabled.
> > 
> > Then maybe that test should be removed.  Calling
> > usb_hcd_resume_root_hub() for every wakeup shouldn't be too bad,
> > because there probably are not very many times when the controller gets
> > resumed without the root hub also being resumed.
> > 
> 
> The check was added to fix system suspend issue on a runtime suspended host:
> 
> commit d6236f6d1d885aa19d1cd7317346fe795227a3cc
> 
>  xhci: Fix runtime suspended xhci from blocking system suspend.
>  
>  The system suspend flow as following:
>  1, Freeze all user processes and kenrel threads.
>  
>  2, Try to suspend all devices.
>  
>  2.1, If pci device is in RPM suspended state, then pci driver will try
>  to resume it to RPM active state in the prepare stage.
>  
>  2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
>  workqueue items to resume usb2&usb3 roothub devices.
>  
>  2.3, Call suspend callbacks of devices.
>  
>  2.3.1, All suspend callbacks of all hcd's children, including
>  roothub devices are called.
>  
>  2.3.2, Finally, hcd_pci_suspend callback is called.
>  
>  Due to workqueue threads were already frozen in step 1, the workqueue
>  items can't be scheduled, and the roothub devices can't be resumed in
>  this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
>  usb_hcd_resume_root_hub won't be cleared. Finally,
>  hcd_pci_suspend will return -EBUSY, and system suspend fails.

Hmmm.  I don't recall seeing this problem occur with ehci-hcd.  But 
then, I haven't tested it very much recently.

We could change to a different work queue, one that doesn't get 
frozen.  But there's no guarantee that the work items would run before 
your step 2.3.2.

Maybe we can avoid step 2.1.  I think there have been some recent
changes to the PM code in this area.  There may be a flag you can set
that will prevent the PCI core from resuming the host controller.

Or maybe we can change step 2.3.1, so that the root hub's suspend 
callback will first do a resume if the WAKEUP_PENDING flag is set.  
That might be the most reliable approach.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

[Sedat Dilek]

On Tue, Apr 24, 2018 at 3:28 PM, Sedat Dilek  wrote:
> On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds
>  wrote:
>> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek  wrote:
>>>
>>> $ objdump -S clang-eflag.o
>>>
>>> clang-eflag.o: file format elf64-x86-64
>>>
>>>
>>> Disassembly of section .text:
>>>
>>>  :
>>>0:   55  push   %rbp
>>>1:   48 89 e5mov%rsp,%rbp
>>>4:   53  push   %rbx
>>>5:   50  push   %rax
>>>6:   e8 00 00 00 00  callq  b 
>>>b:   ff 0d 00 00 00 00   decl   0x0(%rip)# 11 
>>>   11:   9c  pushfq
>>>   12:   5b  pop%rbx
>>>   13:   e8 00 00 00 00  callq  18 
>>>   18:   b8 01 00 00 00  mov$0x1,%eax
>>>   1d:   53  push   %rbx
>>>   1e:   9d  popfq
>>>   1f:   75 07   jne28 
>>
>>
>> Yeah, the above is pure garbage.
>>
>>> So, the issue is still alive.
>>>
>>> What do you mean by "for the kernel we at a minimum need a way to
>>> disable that code generation"?
>>> Can this be fixed in the Linux-kernel?
>>
>> No. This will never be fixed in the kernel. It's a compiler bug.
>>
>> The compiler generates shit code. It's absolutely atrociously bad even
>> if you ignore any kernel issues, because that kind of code just
>> performs badly (the compiler should have used "setcc" or something
>> similar to just set the comparison value, not save and restore eflags.
>>
>> And quite frankly, any compiler writer that thinks it is good code is
>> not somebody I want touching a compiler that the kernel depends on
>> anyway.
>>
>> But it is not just bad code for the kernel, it's actively buggy code,
>> since it corrupts the IF.
>>
>> Until this gets fixed in LLVM, there's no way in hell that we will
>> ever have a kernel compiled with that piece of shit.
>>
>> Really. If the LLVM developers cannot fix their crap code generation,
>> it's not worth touching that shit with a ten-foot pole.
>>
>> I'd love to be able to compile the kernel with LLVM, but the fact that
>> the broken eflags code apparently _still_ hasn't been fixed makes me
>> just go "not worth it".
>>
>> And if the LLVM developers don't see this as an obvious bug, it's even
>> less worth it - because that shows not just that the compiler is
>> broken, but that the developers involved with it are broken too.
>>
>>   Linus
>
> [ Changed Subject ]
> [ CC Matthias ]
> [ CC Michael test-case ]
> [ CC Chandler ]
>
> Hi Linus,
>
> Matthias pointed me in [0] to [1] in the LLVM-BTS.
>
> ...and I tried again the test-case from Michael from [3] "[LLVMdev]
> optimizer clobber EFLAGS"...
>
> ...with clang-7 (version:
> 7~svn330207-1~exp1+0~20180417201234.1709~1.gbp6fb10d) from
> .
>
> [ TEST-CASE ]
>
> [ clang-eflag.c ]
> #include 
> #include 
>
> void foo(void);
> int a;
>
> int bar(void)
> {
>  foo();
>
>  bool const zero = a -= 1;
>
>  asm volatile ("" : : : "cc");
>  foo();
>
>  if (zero) {
>  return EXIT_FAILURE;
>  }
>
>  foo();
>
>  return EXIT_SUCCESS;
> }
> - EOF -
>
> $ clang-7 -O2 -c -o clang-eflag.o clang-eflag.c
>
> [ OBJDUMP ]
>
> $ objdump -S clang-eflag.o
>
> clang-eflag.o: file format elf64-x86-64
>
>
> Disassembly of section .text:
>
>  :
>0:   53  push   %rbx
>1:   e8 00 00 00 00  callq  6 
>6:   83 05 00 00 00 00 ffaddl   $0x,0x0(%rip)#
> d 
>d:   0f 95 c3setne  %bl
>   10:   e8 00 00 00 00  callq  15 
>   15:   b8 01 00 00 00  mov$0x1,%eax
>   1a:   f6 c3 fftest   $0xff,%bl
>   1d:   74 02   je 21 
>   1f:   5b  pop%rbx
>   20:   c3  retq
>   21:   e8 00 00 00 00  callq  26 
>   26:   31 c0   xor%eax,%eax
>   28:   5b  pop%rbx
>   29:   c3  retq
>
> Does this now look good?
>
> Thanks.
>
> Kind regards,
> - Sedat -
>
> [0] https://marc.info/?l=linux-kernel&m=152450535720279&w=2
> [1] https://bugs.llvm.org/show_bug.cgi?id=36028
> [2] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088766.html
> [3] https://marc.info/?l=linux-kernel&m=152457089205170&w=2

For the sake of completeness the two fixes in LLVM upstream.

>From [4]:

Chandler Carruth 2018-04-09 23:41:58 PDT

This should finally be resolved in its entirety with r329657 (and r329673).

"[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues"
https://github.com/llvm-mirror/llvm/commit/21a0c18174343502c9f2b546a01333d1c351d9c0
svn -r329657

"[x86] Model the direction flag (DF) separately from the rest of EFLAGS."
https://github.com/llvm-mirror/llvm/commit/9f8f7c5e8ab12afcc92f51d0ed596ac0867eb0fa
svn-r329673

-

Re: [PATCH 1/2] usb: typec: tps6598x: handle block reads separately with plain-I2C adapters

[Heikki Krogerus]

On Tue, Apr 24, 2018 at 06:02:56AM -0700, Guenter Roeck wrote:
> The chip should return the number of bytes it has available and then NAK
> the transfer. The chip driver should then report the number of bytes read
> to its caller. This is why i2c_smbus_read_block_data() and friends return
> not just 0/-errno, but the number of bytes read.

Thanks for the info.


Br,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usbnet: ipheth: fix ipheth_tx()'s return type

[Luc Van Oostenryck]

The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, but the implementation in this
driver returns an 'int'.

Fix this by returning 'netdev_tx_t' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/net/usb/ipheth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index 7275761a1..53eab6fb9 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -413,7 +413,7 @@ static int ipheth_close(struct net_device *net)
return 0;
 }
 
-static int ipheth_tx(struct sk_buff *skb, struct net_device *net)
+static netdev_tx_t ipheth_tx(struct sk_buff *skb, struct net_device *net)
 {
struct ipheth_device *dev = netdev_priv(net);
struct usb_device *udev = dev->udev;
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

[Mathias Nyman]

On 24.04.2018 16:24, Alan Stern wrote:

On Tue, 24 Apr 2018, Mathias Nyman wrote:


On 23.04.2018 18:11, Alan Stern wrote:

On Mon, 23 Apr 2018, Mathias Nyman wrote:


On 22.04.2018 09:29, russianneuroman...@ya.ru wrote:

Hello!

So far I tested attached patch but didn't tried to revert commit yet,
will do next week.

Result of running patched kernel with recommended debug options:
https://paste.fedoraproject.org/paste/UpezexD~tDmQthoxV2BFbg



Logs show there is a race, controller is suspended, then resumed,
but no interrupt is pending in xhci_resume so roothubs are not resumed,
and host starts to suspend again.

We get the interrupt only after we already started suspending xhci
controller again.

My guess is that when we handle the interrupt we queue work to resume the 
roothub,
but controller is probably put to D3 suspended state by then,
returning 0x from some register reads, which driver understands as a 
dead host.

I need to look into this a bit more.


In this situation, the HCD_WAKEUP_PENDING(hcd) test in
hcd-pci.c:suspend_common() should prevent the controller from going
back into D3.  The WAKEUP_PENDING bit gets set in
usb_hcd_resume_root_hub() and it doesn't get cleared until
hcd_bus_resume() runs.



I think xhci never calls usb_hcd_resume_root_hub() in xhci_resume() in this
specific failing case

xhci_resume() has a check:
/* Resume root hubs only when have pending events. */
status = readl(&xhci->op_regs->status);
  if (status & STS_EINT) {
usb_hcd_resume_root_hub(xhci->shared_hcd);
usb_hcd_resume_root_hub(hcd);
  }

If the check fails, then WAKEUP_PENDING bit is not set, and runtime PM
can suspend host controller again. when xhci driver finally gets to handle the 
interrupt
the controller may be in D3 already

This should only happen if xhci_resume() is called before xhci driver sees a 
pending interrupt,
could be possible as xhci has interrupt moderation enabled.


Then maybe that test should be removed.  Calling
usb_hcd_resume_root_hub() for every wakeup shouldn't be too bad,
because there probably are not very many times when the controller gets
resumed without the root hub also being resumed.



The check was added to fix system suspend issue on a runtime suspended host:

commit d6236f6d1d885aa19d1cd7317346fe795227a3cc

xhci: Fix runtime suspended xhci from blocking system suspend.

The system suspend flow as following:

1, Freeze all user processes and kenrel threads.

2, Try to suspend all devices.

2.1, If pci device is in RPM suspended state, then pci driver will try

to resume it to RPM active state in the prepare stage.

2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two

workqueue items to resume usb2&usb3 roothub devices.

2.3, Call suspend callbacks of devices.

2.3.1, All suspend callbacks of all hcd's children, including

roothub devices are called.

2.3.2, Finally, hcd_pci_suspend callback is called.

Due to workqueue threads were already frozen in step 1, the workqueue

items can't be scheduled, and the roothub devices can't be resumed in
this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
usb_hcd_resume_root_hub won't be cleared. Finally,
hcd_pci_suspend will return -EBUSY, and system suspend fails.

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

[Sedat Dilek]

On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds
 wrote:
> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek  wrote:
>>
>> $ objdump -S clang-eflag.o
>>
>> clang-eflag.o: file format elf64-x86-64
>>
>>
>> Disassembly of section .text:
>>
>>  :
>>0:   55  push   %rbp
>>1:   48 89 e5mov%rsp,%rbp
>>4:   53  push   %rbx
>>5:   50  push   %rax
>>6:   e8 00 00 00 00  callq  b 
>>b:   ff 0d 00 00 00 00   decl   0x0(%rip)# 11 
>>   11:   9c  pushfq
>>   12:   5b  pop%rbx
>>   13:   e8 00 00 00 00  callq  18 
>>   18:   b8 01 00 00 00  mov$0x1,%eax
>>   1d:   53  push   %rbx
>>   1e:   9d  popfq
>>   1f:   75 07   jne28 
>
>
> Yeah, the above is pure garbage.
>
>> So, the issue is still alive.
>>
>> What do you mean by "for the kernel we at a minimum need a way to
>> disable that code generation"?
>> Can this be fixed in the Linux-kernel?
>
> No. This will never be fixed in the kernel. It's a compiler bug.
>
> The compiler generates shit code. It's absolutely atrociously bad even
> if you ignore any kernel issues, because that kind of code just
> performs badly (the compiler should have used "setcc" or something
> similar to just set the comparison value, not save and restore eflags.
>
> And quite frankly, any compiler writer that thinks it is good code is
> not somebody I want touching a compiler that the kernel depends on
> anyway.
>
> But it is not just bad code for the kernel, it's actively buggy code,
> since it corrupts the IF.
>
> Until this gets fixed in LLVM, there's no way in hell that we will
> ever have a kernel compiled with that piece of shit.
>
> Really. If the LLVM developers cannot fix their crap code generation,
> it's not worth touching that shit with a ten-foot pole.
>
> I'd love to be able to compile the kernel with LLVM, but the fact that
> the broken eflags code apparently _still_ hasn't been fixed makes me
> just go "not worth it".
>
> And if the LLVM developers don't see this as an obvious bug, it's even
> less worth it - because that shows not just that the compiler is
> broken, but that the developers involved with it are broken too.
>
>   Linus

[ Changed Subject ]
[ CC Matthias ]
[ CC Michael test-case ]
[ CC Chandler ]

Hi Linus,

Matthias pointed me in [0] to [1] in the LLVM-BTS.

...and I tried again the test-case from Michael from [3] "[LLVMdev]
optimizer clobber EFLAGS"...

...with clang-7 (version:
7~svn330207-1~exp1+0~20180417201234.1709~1.gbp6fb10d) from
.

[ TEST-CASE ]

[ clang-eflag.c ]
#include 
#include 

void foo(void);
int a;

int bar(void)
{
 foo();

 bool const zero = a -= 1;

 asm volatile ("" : : : "cc");
 foo();

 if (zero) {
 return EXIT_FAILURE;
 }

 foo();

 return EXIT_SUCCESS;
}
- EOF -

$ clang-7 -O2 -c -o clang-eflag.o clang-eflag.c

[ OBJDUMP ]

$ objdump -S clang-eflag.o

clang-eflag.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   53  push   %rbx
   1:   e8 00 00 00 00  callq  6 
   6:   83 05 00 00 00 00 ffaddl   $0x,0x0(%rip)#
d 
   d:   0f 95 c3setne  %bl
  10:   e8 00 00 00 00  callq  15 
  15:   b8 01 00 00 00  mov$0x1,%eax
  1a:   f6 c3 fftest   $0xff,%bl
  1d:   74 02   je 21 
  1f:   5b  pop%rbx
  20:   c3  retq
  21:   e8 00 00 00 00  callq  26 
  26:   31 c0   xor%eax,%eax
  28:   5b  pop%rbx
  29:   c3  retq

Does this now look good?

Thanks.

Kind regards,
- Sedat -

[0] https://marc.info/?l=linux-kernel&m=152450535720279&w=2
[1] https://bugs.llvm.org/show_bug.cgi?id=36028
[2] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088766.html
[3] https://marc.info/?l=linux-kernel&m=152457089205170&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: gadget: f_phonet: fix pn_net_xmit()'s return type

[Luc Van Oostenryck]

The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, but the implementation in this
driver returns an 'int'.

Fix this by returning 'netdev_tx_t' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/usb/gadget/function/f_phonet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_phonet.c 
b/drivers/usb/gadget/function/f_phonet.c
index 7889bcc05..8b72b192c 100644
--- a/drivers/usb/gadget/function/f_phonet.c
+++ b/drivers/usb/gadget/function/f_phonet.c
@@ -221,7 +221,7 @@ static void pn_tx_complete(struct usb_ep *ep, struct 
usb_request *req)
netif_wake_queue(dev);
 }
 
-static int pn_net_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t pn_net_xmit(struct sk_buff *skb, struct net_device *dev)
 {
struct phonet_port *port = netdev_priv(dev);
struct f_phonet *fp;
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

[Alan Stern]

On Tue, 24 Apr 2018, Mathias Nyman wrote:

> On 23.04.2018 18:11, Alan Stern wrote:
> > On Mon, 23 Apr 2018, Mathias Nyman wrote:
> > 
> >> On 22.04.2018 09:29, russianneuroman...@ya.ru wrote:
> >>> Hello!
> >>>
> >>> So far I tested attached patch but didn't tried to revert commit yet,
> >>> will do next week.
> >>>
> >>> Result of running patched kernel with recommended debug options:
> >>> https://paste.fedoraproject.org/paste/UpezexD~tDmQthoxV2BFbg
> >>>
> >>
> >> Logs show there is a race, controller is suspended, then resumed,
> >> but no interrupt is pending in xhci_resume so roothubs are not resumed,
> >> and host starts to suspend again.
> >>
> >> We get the interrupt only after we already started suspending xhci
> >> controller again.
> >>
> >> My guess is that when we handle the interrupt we queue work to resume the 
> >> roothub,
> >> but controller is probably put to D3 suspended state by then,
> >> returning 0x from some register reads, which driver understands as 
> >> a dead host.
> >>
> >> I need to look into this a bit more.
> > 
> > In this situation, the HCD_WAKEUP_PENDING(hcd) test in
> > hcd-pci.c:suspend_common() should prevent the controller from going
> > back into D3.  The WAKEUP_PENDING bit gets set in
> > usb_hcd_resume_root_hub() and it doesn't get cleared until
> > hcd_bus_resume() runs.
> > 
> 
> I think xhci never calls usb_hcd_resume_root_hub() in xhci_resume() in this
> specific failing case
> 
> xhci_resume() has a check:
> /* Resume root hubs only when have pending events. */
>status = readl(&xhci->op_regs->status);
>  if (status & STS_EINT) {
>usb_hcd_resume_root_hub(xhci->shared_hcd);
>usb_hcd_resume_root_hub(hcd);
>  }
> 
> If the check fails, then WAKEUP_PENDING bit is not set, and runtime PM
> can suspend host controller again. when xhci driver finally gets to handle 
> the interrupt
> the controller may be in D3 already
> 
> This should only happen if xhci_resume() is called before xhci driver sees a 
> pending interrupt,
> could be possible as xhci has interrupt moderation enabled.

Then maybe that test should be removed.  Calling 
usb_hcd_resume_root_hub() for every wakeup shouldn't be too bad, 
because there probably are not very many times when the controller gets 
resumed without the root hub also being resumed.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

[Mathias Nyman]

On 23.04.2018 18:11, Alan Stern wrote:

On Mon, 23 Apr 2018, Mathias Nyman wrote:


On 22.04.2018 09:29, russianneuroman...@ya.ru wrote:

Hello!

So far I tested attached patch but didn't tried to revert commit yet,
will do next week.

Result of running patched kernel with recommended debug options:
https://paste.fedoraproject.org/paste/UpezexD~tDmQthoxV2BFbg



Logs show there is a race, controller is suspended, then resumed,
but no interrupt is pending in xhci_resume so roothubs are not resumed,
and host starts to suspend again.

We get the interrupt only after we already started suspending xhci
controller again.

My guess is that when we handle the interrupt we queue work to resume the 
roothub,
but controller is probably put to D3 suspended state by then,
returning 0x from some register reads, which driver understands as a 
dead host.

I need to look into this a bit more.


In this situation, the HCD_WAKEUP_PENDING(hcd) test in
hcd-pci.c:suspend_common() should prevent the controller from going
back into D3.  The WAKEUP_PENDING bit gets set in
usb_hcd_resume_root_hub() and it doesn't get cleared until
hcd_bus_resume() runs.



I think xhci never calls usb_hcd_resume_root_hub() in xhci_resume() in this
specific failing case

xhci_resume() has a check:
/* Resume root hubs only when have pending events. */
  status = readl(&xhci->op_regs->status);
if (status & STS_EINT) {
  usb_hcd_resume_root_hub(xhci->shared_hcd);
  usb_hcd_resume_root_hub(hcd);
}

If the check fails, then WAKEUP_PENDING bit is not set, and runtime PM
can suspend host controller again. when xhci driver finally gets to handle the 
interrupt
the controller may be in D3 already

This should only happen if xhci_resume() is called before xhci driver sees a 
pending interrupt,
could be possible as xhci has interrupt moderation enabled.

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: typec: tps6598x: handle block reads separately with plain-I2C adapters

[Guenter Roeck]

On 04/24/2018 04:46 AM, Heikki Krogerus wrote:

On Mon, Apr 23, 2018 at 09:43:57AM -0700, Guenter Roeck wrote:

On Mon, Apr 23, 2018 at 11:03:09AM +0300, Heikki Krogerus wrote:

On Fri, Apr 20, 2018 at 10:26:08AM -0700, Guenter Roeck wrote:

On Wed, Apr 18, 2018 at 03:34:09PM +0300, Heikki Krogerus wrote:

If the I2C adapter that the PD controller is attached to
does not support SMBus protocol, the driver needs to handle
block reads separately. The first byte returned in block
read protocol will show the total number of bytes. It needs
to be stripped away.

This is handled separately in the driver only because right
now we have no way of requesting the used protocol with
regmap-i2c. This is in practice a workaround for what is
really a problem in regmap-i2c. The other option would have
been to register custom regmap, or not use regmap at all,
however, since the solution is very simple, I choose to use
it in this case for convenience. It is easy to remove once
we figure out how to handle this kind of cases in
regmap-i2c.

Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery 
controllers")
Signed-off-by: Heikki Krogerus 
---
  drivers/usb/typec/tps6598x.c | 42 ++--
  1 file changed, 35 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
index 8b8406867c02..82f09cd9792d 100644
--- a/drivers/usb/typec/tps6598x.c
+++ b/drivers/usb/typec/tps6598x.c
@@ -73,6 +73,7 @@ struct tps6598x {
struct device *dev;
struct regmap *regmap;
struct mutex lock; /* device lock */
+   u8 i2c_protocol:1;
  
  	struct typec_port *port;

struct typec_partner *partner;
@@ -80,6 +81,23 @@ struct tps6598x {
struct typec_capability typec_cap;
  };
  
+static int

+tps6598x_block_read(struct tps6598x *tps, u8 reg, void *val, ssize_t len)
+{
+   u8 data[len + 1];
+   int ret;
+
+   if (!tps->i2c_protocol)
+   return regmap_raw_read(tps->regmap, reg, val, len);
+
+   ret = regmap_raw_read(tps->regmap, reg, data, sizeof(data));
+   if (ret)
+   return ret;
+


Sanity check ?
if (data[0] != len)
return -Esomething;


No. Then we would not even need the len parameter. The idea is to
allow reading a number of bytes specified by caller, regardless of the
maximum size of the block.


If I2C_FUNC_I2C is not supported but I2C_FUNC_SMBUS_I2C_BLOCK is, the
regmap core will use i2c_smbus_read_i2c_block_data() and validate the
return length. It will return -EIO if it does not match. That seems
inconsistent.


For some reason I though that regmap-i2c supports
I2C_FUNC_SMBUS_BLOCK_DATA functionality instead of
I2C_FUNC_SMBUS_I2C_BLOCK_DATA. I stand corrected.


Also, I am not sure how you know that at least the minimum
required number of bytes is returned if the number of bytes requested
is larger than the number of bytes returned by the chip. Am I missing
something ?


If the slave chip returns less bytes then what we are asking from it,
the adapter driver should return an error, timeout most likely, no? Or
did I misunderstood the question?



The chip should return the number of bytes it has available and then NAK
the transfer. The chip driver should then report the number of bytes read
to its caller. This is why i2c_smbus_read_block_data() and friends return
not just 0/-errno, but the number of bytes read.

Guenter


In any case, I will add some sanity checks. I just wanted to make sure
we don't add useless checks.


Also, I notice that your patch does not touch tps6598x_read16(). Yet,
according to "TPS65981, TPS65982, and TPS65986 Host Interface Technical
Reference Manual", it appears that the 2-byte command used (0x3f) does
support/use block commands. Is that an oversight or on purpose ?


I did not change it because in my test I did not see the byte count in
the first byte, but I'm questioning myself now... I need to re-check
it. I may have done that test with wrong platform.


Thanks Guenter,



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 5/6] typec: tcpm: Represent source supply through power_supply

[Heikki Krogerus]

On Mon, Apr 23, 2018 at 03:11:00PM +0100, Adam Thomson wrote:
> This commit adds a power_supply class instance to represent a
> PD source's voltage and current properties. This provides an
> interface for reading these properties from user-space or other
> drivers.
> 
> For PPS enabled Sources, this also provides write access to set
> the current and voltage and allows for swapping between standard
> PDO and PPS APDO.
> 
> As this represents a superset of the information provided in the
> fusb302 driver, the power_supply instance in that code is removed
> as part of this change, so reverting the commit titled
> 'typec: tcpm: Represent source supply through power_supply class'
> 
> Signed-off-by: Adam Thomson 
> Reviewed-by: Guenter Roeck 

Reviewed-by: Heikki Krogerus 

> ---
>  drivers/usb/typec/Kconfig   |   1 +
>  drivers/usb/typec/fusb302/Kconfig   |   2 +-
>  drivers/usb/typec/fusb302/fusb302.c |  63 +
>  drivers/usb/typec/tcpm.c| 251 
> +++-
>  4 files changed, 251 insertions(+), 66 deletions(-)
> 
> diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
> index 030f88c..2c8eab1 100644
> --- a/drivers/usb/typec/Kconfig
> +++ b/drivers/usb/typec/Kconfig
> @@ -49,6 +49,7 @@ config TYPEC_TCPM
>   tristate "USB Type-C Port Controller Manager"
>   depends on USB
>   select USB_ROLE_SWITCH
> + select POWER_SUPPLY
>   help
> The Type-C Port Controller Manager provides a USB PD and USB Type-C
> state machine for use with Type-C Port Controllers.
> diff --git a/drivers/usb/typec/fusb302/Kconfig 
> b/drivers/usb/typec/fusb302/Kconfig
> index 48a4f2f..fce099f 100644
> --- a/drivers/usb/typec/fusb302/Kconfig
> +++ b/drivers/usb/typec/fusb302/Kconfig
> @@ -1,6 +1,6 @@
>  config TYPEC_FUSB302
>   tristate "Fairchild FUSB302 Type-C chip driver"
> - depends on I2C && POWER_SUPPLY
> + depends on I2C
>   help
> The Fairchild FUSB302 Type-C chip driver that works with
> Type-C Port Controller Manager to provide USB PD and USB
> diff --git a/drivers/usb/typec/fusb302/fusb302.c 
> b/drivers/usb/typec/fusb302/fusb302.c
> index 664463d..eba6bb8 100644
> --- a/drivers/usb/typec/fusb302/fusb302.c
> +++ b/drivers/usb/typec/fusb302/fusb302.c
> @@ -18,7 +18,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -99,11 +98,6 @@ struct fusb302_chip {
>   /* lock for sharing chip states */
>   struct mutex lock;
>  
> - /* psy + psy status */
> - struct power_supply *psy;
> - u32 current_limit;
> - u32 supply_voltage;
> -
>   /* chip status */
>   enum toggling_mode toggling_mode;
>   enum src_current_status src_current_status;
> @@ -862,13 +856,11 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on, 
> bool charge)
>   chip->vbus_on = on;
>   fusb302_log(chip, "vbus := %s", on ? "On" : "Off");
>   }
> - if (chip->charge_on == charge) {
> + if (chip->charge_on == charge)
>   fusb302_log(chip, "charge is already %s",
>   charge ? "On" : "Off");
> - } else {
> + else
>   chip->charge_on = charge;
> - power_supply_changed(chip->psy);
> - }
>  
>  done:
>   mutex_unlock(&chip->lock);
> @@ -884,11 +876,6 @@ static int tcpm_set_current_limit(struct tcpc_dev *dev, 
> u32 max_ma, u32 mv)
>   fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
>   max_ma, mv);
>  
> - chip->supply_voltage = mv;
> - chip->current_limit = max_ma;
> -
> - power_supply_changed(chip->psy);
> -
>   return 0;
>  }
>  
> @@ -1682,43 +1669,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void 
> *dev_id)
>   return IRQ_HANDLED;
>  }
>  
> -static int fusb302_psy_get_property(struct power_supply *psy,
> - enum power_supply_property psp,
> - union power_supply_propval *val)
> -{
> - struct fusb302_chip *chip = power_supply_get_drvdata(psy);
> -
> - switch (psp) {
> - case POWER_SUPPLY_PROP_ONLINE:
> - val->intval = chip->charge_on;
> - break;
> - case POWER_SUPPLY_PROP_VOLTAGE_NOW:
> - val->intval = chip->supply_voltage * 1000; /* mV -> ??V */
> - break;
> - case POWER_SUPPLY_PROP_CURRENT_MAX:
> - val->intval = chip->current_limit * 1000; /* mA -> ??A */
> - break;
> - default:
> - return -ENODATA;
> - }
> -
> - return 0;
> -}
> -
> -static enum power_supply_property fusb302_psy_properties[] = {
> - POWER_SUPPLY_PROP_ONLINE,
> - POWER_SUPPLY_PROP_VOLTAGE_NOW,
> - POWER_SUPPLY_PROP_CURRENT_MAX,
> -};
> -
> -static const struct power_supply_desc fusb302_psy_desc = {
> - .name   = "fusb302-typec-source",
> - .type   = POWER_SUPPLY_TYPE_USB_TYPE_C,
> - .properties   

Re: [PATCH v8 4/6] power: supply: Add 'usb_type' property and supporting code

[Heikki Krogerus]

On Mon, Apr 23, 2018 at 03:10:59PM +0100, Adam Thomson wrote:
> This commit adds the 'usb_type' property to represent USB supplies
> which can report a number of different types based on a connection
> event.
> 
> Examples of this already exist in drivers whereby the existing 'type'
> property is updated, based on an event, to represent what was
> connected (e.g. USB, USB_DCP, USB_ACA, ...). Current implementations
> however don't show all supported connectable types, so this knowledge
> has to be exlicitly known for each driver that supports this.
> 
> The 'usb_type' property is intended to fill this void and show users
> all possible USB types supported by a driver. The property, when read,
> shows all available types for the driver, and the one currently chosen
> is highlighted/bracketed. It is expected that the 'type' property
> would then just show the top-level type 'USB', and this would be
> static.
> 
> Currently the 'usb_type' enum contains all of the USB variant types
> that exist for the 'type' enum at this time, and in addition has
> SDP and PPS types. The mirroring is intentional so as to not impact
> existing usage of the 'type' property.
> 
> Signed-off-by: Adam Thomson 

Reviewed-by: Heikki Krogerus 

> ---
>  Documentation/ABI/testing/sysfs-class-power | 12 
>  drivers/power/supply/power_supply_core.c|  8 -
>  drivers/power/supply/power_supply_sysfs.c   | 45 
> +
>  include/linux/power_supply.h| 16 ++
>  4 files changed, 80 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-power 
> b/Documentation/ABI/testing/sysfs-class-power
> index e046566..5e23e22 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -409,6 +409,18 @@ Description:
>   Access: Read
>   Valid values: Represented in 1/10 Degrees Celsius
>  
> +What:/sys/class/power_supply//usb_type
> +Date:March 2018
> +Contact: linux...@vger.kernel.org
> +Description:
> + Reports what type of USB connection is currently active for
> + the supply, for example it can show if USB-PD capable source
> + is attached.
> +
> + Access: Read-Only
> + Valid values: "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
> +   "PD_DRP", "PD_PPS", "BrickID"
> +
>  What:/sys/class/power_supply//voltage_max
>  Date:January 2008
>  Contact: linux...@vger.kernel.org
> diff --git a/drivers/power/supply/power_supply_core.c 
> b/drivers/power/supply/power_supply_core.c
> index a7984af..ecd68c2 100644
> --- a/drivers/power/supply/power_supply_core.c
> +++ b/drivers/power/supply/power_supply_core.c
> @@ -843,7 +843,7 @@ static void psy_unregister_cooler(struct power_supply 
> *psy)
>  {
>   struct device *dev;
>   struct power_supply *psy;
> - int rc;
> + int i, rc;
>  
>   if (!parent)
>   pr_warn("%s: Expected proper parent device for '%s'\n",
> @@ -852,6 +852,12 @@ static void psy_unregister_cooler(struct power_supply 
> *psy)
>   if (!desc || !desc->name || !desc->properties || !desc->num_properties)
>   return ERR_PTR(-EINVAL);
>  
> + for (i = 0; i < desc->num_properties; ++i) {
> + if ((desc->properties[i] == POWER_SUPPLY_PROP_USB_TYPE) &&
> + (!desc->usb_types || !desc->num_usb_types))
> + return ERR_PTR(-EINVAL);
> + }
> +
>   psy = kzalloc(sizeof(*psy), GFP_KERNEL);
>   if (!psy)
>   return ERR_PTR(-ENOMEM);
> diff --git a/drivers/power/supply/power_supply_sysfs.c 
> b/drivers/power/supply/power_supply_sysfs.c
> index 5204f11..1350068 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -46,6 +46,11 @@
>   "USB_PD", "USB_PD_DRP", "BrickID"
>  };
>  
> +static const char * const power_supply_usb_type_text[] = {
> + "Unknown", "SDP", "DCP", "CDP", "ACA", "C",
> + "PD", "PD_DRP", "PD_PPS", "BrickID"
> +};
> +
>  static const char * const power_supply_status_text[] = {
>   "Unknown", "Charging", "Discharging", "Not charging", "Full"
>  };
> @@ -73,6 +78,41 @@
>   "Unknown", "System", "Device"
>  };
>  
> +static ssize_t power_supply_show_usb_type(struct device *dev,
> +   enum power_supply_usb_type *usb_types,
> +   ssize_t num_usb_types,
> +   union power_supply_propval *value,
> +   char *buf)
> +{
> + enum power_supply_usb_type usb_type;
> + ssize_t count = 0;
> + bool match = false;
> + int i;
> +
> + for (i = 0; i < num_usb_types; ++i) {
> + usb_type = usb_types[i];
> +
> + if (value->intval == usb_type) {
> + co

Re: [PATCH v8 3/6] power: supply: Add error checking of psy desc during registration

[Heikki Krogerus]

On Mon, Apr 23, 2018 at 03:10:58PM +0100, Adam Thomson wrote:
> Currently there's no error checking of this parameter in the
> registration function and it's blindly added to psy class and
> subsequently used as is. For example if this is NULL the call
> to psy_register_thermal() will try to dereference the pointer
> thus causing a kernel dump.
> 
> This commit updates the registration code to add some basic
> checks on the desc pointer validity, name, and presence of
> properties.
> 
> Signed-off-by: Adam Thomson 

Reviewed-by: Heikki Krogerus 

> ---
>  drivers/power/supply/power_supply_core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/power/supply/power_supply_core.c 
> b/drivers/power/supply/power_supply_core.c
> index feac7b0..a7984af 100644
> --- a/drivers/power/supply/power_supply_core.c
> +++ b/drivers/power/supply/power_supply_core.c
> @@ -849,6 +849,9 @@ static void psy_unregister_cooler(struct power_supply 
> *psy)
>   pr_warn("%s: Expected proper parent device for '%s'\n",
>   __func__, desc->name);
>  
> + if (!desc || !desc->name || !desc->properties || !desc->num_properties)
> + return ERR_PTR(-EINVAL);
> +
>   psy = kzalloc(sizeof(*psy), GFP_KERNEL);
>   if (!psy)
>   return ERR_PTR(-ENOMEM);

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 2/6] Documentation: power: Initial effort to document power_supply ABI

[Heikki Krogerus]

On Mon, Apr 23, 2018 at 03:10:57PM +0100, Adam Thomson wrote:
> This commit adds generic ABI information regarding power_supply
> properties. This is an initial attempt to try and align the usage
> of these properties between drivers. As part of this commit,
> common Battery and USB related properties have been listed.
> 
> Signed-off-by: Adam Thomson 

Thank you a lot for doing this Adam! FWIW:

Reviewed-by: Heikki Krogerus 

> ---
>  Documentation/ABI/testing/sysfs-class-power | 443 
> 
>  MAINTAINERS |   1 +
>  2 files changed, 444 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-power 
> b/Documentation/ABI/testing/sysfs-class-power
> index f85ce9e..e046566 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -1,3 +1,446 @@
> += General Properties =
> +
> +What:/sys/class/power_supply//manufacturer
> +Date:May 2007
> +Contact: linux...@vger.kernel.org
> +Description:
> + Reports the name of the device manufacturer.
> +
> + Access: Read
> + Valid values: Represented as string
> +
> +What:/sys/class/power_supply//model_name
> +Date:May 2007
> +Contact: linux...@vger.kernel.org
> +Description:
> + Reports the name of the device model.
> +
> + Access: Read
> + Valid values: Represented as string
> +
> +What:/sys/class/power_supply//serial_number
> +Date:January 2008
> +Contact: linux...@vger.kernel.org
> +Description:
> + Reports the serial number of the device.
> +
> + Access: Read
> + Valid values: Represented as string
> +
> +What:/sys/class/power_supply//type
> +Date:May 2010
> +Contact: linux...@vger.kernel.org
> +Description:
> + Describes the main type of the supply.
> +
> + Access: Read
> + Valid values: "Battery", "UPS", "Mains", "USB"
> +
> += Battery Properties =
> +
> +What:/sys/class/power_supply//capacity
> +Date:May 2007
> +Contact: linux...@vger.kernel.org
> +Description:
> + Fine grain representation of battery capacity.
> + Access: Read
> + Valid values: 0 - 100 (percent)
> +
> +What:/sys/class/power_supply//capacity_alert_max
> +Date:July 2012
> +Contact: linux...@vger.kernel.org
> +Description:
> + Maximum battery capacity trip-wire value where the supply will
> + notify user-space of the event. This is normally used for the
> + battery discharging scenario where user-space needs to know the
> + battery has dropped to an upper level so it can take
> + appropriate action (e.g. warning user that battery level is
> + low).
> +
> + Access: Read, Write
> + Valid values: 0 - 100 (percent)
> +
> +What:/sys/class/power_supply//capacity_alert_min
> +Date:July 2012
> +Contact: linux...@vger.kernel.org
> +Description:
> + Minimum battery capacity trip-wire value where the supply will
> + notify user-space of the event. This is normally used for the
> + battery discharging scenario where user-space needs to know the
> + battery has dropped to a lower level so it can take
> + appropriate action (e.g. warning user that battery level is
> + critically low).
> +
> + Access: Read, Write
> + Valid values: 0 - 100 (percent)
> +
> +What:/sys/class/power_supply//capacity_level
> +Date:June 2009
> +Contact: linux...@vger.kernel.org
> +Description:
> + Coarse representation of battery capacity.
> +
> + Access: Read
> + Valid values: "Unknown", "Critical", "Low", "Normal", "High",
> +   "Full"
> +
> +What:/sys/class/power_supply//current_avg
> +Date:May 2007
> +Contact: linux...@vger.kernel.org
> +Description:
> + Reports an average IBAT current reading for the battery, over a
> + fixed period. Normally devices will provide a fixed interval in
> + which they average readings to smooth out the reported value.
> +
> + Access: Read
> + Valid values: Represented in microamps
> +
> +What:/sys/class/power_supply//current_max
> +Date:October 2010
> +Contact: linux...@vger.kernel.org
> +Description:
> + Reports the maximum IBAT current allowed into the battery.
> +
> + Access: Read
> + Valid values: Represented in microamps
> +
> +What:/sys/class/power_supply//current_now
> 

Re: [PATCH/RFC 04/11] of: platform: add device connection parsing

[Heikki Krogerus]

Hi Yoshihiro,

On Wed, Apr 18, 2018 at 05:09:58PM +0900, Yoshihiro Shimoda wrote:
> This patch adds device connection parsing in of_platform_populate().
> 
> TODO:
>  - How to free the devcon memories?
>  - How to remove the devcon instances?
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/of/platform.c | 66 
> +++
>  include/linux/of.h|  1 +
>  2 files changed, 67 insertions(+)
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index c00d81d..41c018d 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -326,6 +327,63 @@ static const struct of_dev_auxdata *of_dev_lookup(const 
> struct of_dev_auxdata *l
>   return NULL;
>  }
>  
> +static int of_parse_device_connection(struct device_node *np)
> +{
> + struct device_node *child_ep, *parent, *remote_parent;
> + struct platform_device *pdev, *remote_pdev;
> + struct device_connection *devcon = NULL;
> + const char *id;
> +
> + if (of_node_check_flag(np, OF_DEVICE_CONNECTED)) {
> + pr_debug("%s() - skipping %pOF, already device connected\n",
> + __func__, np);
> + return 0;
> + }
> +
> + of_node_set_flag(np, OF_DEVICE_CONNECTED);
> +
> + for_each_endpoint_of_node(np, child_ep) {
> + if (of_property_read_string(child_ep, "device-connection-id",
> + &id) < 0)
> + continue;
> +
> + remote_parent = of_graph_get_remote_port_parent(child_ep);
> + if (!remote_parent)
> + return 0;
> +
> + parent = of_graph_get_port_parent(child_ep);
> + if (!parent)
> + return 0;
> +
> + pdev = of_find_device_by_node(parent);
> + if (!pdev)
> + return 0;
> +
> + /*
> +  * WARN_ON in really_probe() may happen if devm_kzalloc is
> +  * used. TODO: How to free this?
> +  */
> + devcon = kzalloc(sizeof(*devcon), GFP_KERNEL);
> + if (!devcon)
> + return -ENOMEM;
> +
> + devcon->id = id;
> + remote_pdev = of_find_device_by_node(remote_parent);
> + if (!remote_pdev) {
> + kfree(devcon);
> + return 0;
> + }
> +
> + devcon->endpoint[0] = dev_name(&pdev->dev);
> + devcon->endpoint[1] = dev_name(&remote_pdev->dev);
> +
> + /* TODO: How to remove the connection? */
> + device_connection_add(devcon);

This is wrong. You are converting a connection that is described in
graph into a "build-in" one. If the connection is already described in
graph there is no need to, actually, we _should not_, add it to the
list of "build-in" connection descriptions.

What should be done is that we parse the graph the moment
device_connection_find*() is called. And that should be done in
drivers/base/devcon.c .

> + }
> +
> + return 0;
> +}
> +
>  /**
>   * of_platform_bus_create() - Create a device for a node and its children.
>   * @bus: device node of the bus to instantiate
> @@ -477,6 +535,14 @@ int of_platform_populate(struct device_node *root,
>   }
>   of_node_set_flag(root, OF_POPULATED_BUS);
>  
> + for_each_child_of_node(root, child) {
> + rc = of_parse_device_connection(child);
> + if (rc) {
> + of_node_put(child);
> + break;
> + }
> + }
> +
>   of_node_put(root);
>   return rc;
>  }
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 4d25e4f..30aa103 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -143,6 +143,7 @@ static inline void of_node_put(struct device_node *node) 
> { }
>  #define OF_DETACHED  2 /* node has been detached from the device tree */
>  #define OF_POPULATED 3 /* device already created for the node */
>  #define OF_POPULATED_BUS 4 /* of_platform_populate recursed to children 
> of this node */
> +#define OF_DEVICE_CONNECTED  5 /* checked devcon on of_platform_populate */
>  
>  #define OF_BAD_ADDR  ((u64)-1)


Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] musb fixes backport to v4.9+

[Greg KH]

On Mon, Apr 23, 2018 at 12:41:12PM -0500, Bin Liu wrote:
> Hi,
> 
> Here are several patches backported to v4.9+ to fix runtime PM problems in 
> musb
> drivers.

All now applied, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: typec: tps6598x: handle block reads separately with plain-I2C adapters

[Heikki Krogerus]

On Mon, Apr 23, 2018 at 09:43:57AM -0700, Guenter Roeck wrote:
> On Mon, Apr 23, 2018 at 11:03:09AM +0300, Heikki Krogerus wrote:
> > On Fri, Apr 20, 2018 at 10:26:08AM -0700, Guenter Roeck wrote:
> > > On Wed, Apr 18, 2018 at 03:34:09PM +0300, Heikki Krogerus wrote:
> > > > If the I2C adapter that the PD controller is attached to
> > > > does not support SMBus protocol, the driver needs to handle
> > > > block reads separately. The first byte returned in block
> > > > read protocol will show the total number of bytes. It needs
> > > > to be stripped away.
> > > > 
> > > > This is handled separately in the driver only because right
> > > > now we have no way of requesting the used protocol with
> > > > regmap-i2c. This is in practice a workaround for what is
> > > > really a problem in regmap-i2c. The other option would have
> > > > been to register custom regmap, or not use regmap at all,
> > > > however, since the solution is very simple, I choose to use
> > > > it in this case for convenience. It is easy to remove once
> > > > we figure out how to handle this kind of cases in
> > > > regmap-i2c.
> > > > 
> > > > Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power 
> > > > Delivery controllers")
> > > > Signed-off-by: Heikki Krogerus 
> > > > ---
> > > >  drivers/usb/typec/tps6598x.c | 42 ++--
> > > >  1 file changed, 35 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
> > > > index 8b8406867c02..82f09cd9792d 100644
> > > > --- a/drivers/usb/typec/tps6598x.c
> > > > +++ b/drivers/usb/typec/tps6598x.c
> > > > @@ -73,6 +73,7 @@ struct tps6598x {
> > > > struct device *dev;
> > > > struct regmap *regmap;
> > > > struct mutex lock; /* device lock */
> > > > +   u8 i2c_protocol:1;
> > > >  
> > > > struct typec_port *port;
> > > > struct typec_partner *partner;
> > > > @@ -80,6 +81,23 @@ struct tps6598x {
> > > > struct typec_capability typec_cap;
> > > >  };
> > > >  
> > > > +static int
> > > > +tps6598x_block_read(struct tps6598x *tps, u8 reg, void *val, ssize_t 
> > > > len)
> > > > +{
> > > > +   u8 data[len + 1];
> > > > +   int ret;
> > > > +
> > > > +   if (!tps->i2c_protocol)
> > > > +   return regmap_raw_read(tps->regmap, reg, val, len);
> > > > +
> > > > +   ret = regmap_raw_read(tps->regmap, reg, data, sizeof(data));
> > > > +   if (ret)
> > > > +   return ret;
> > > > +
> > > 
> > > Sanity check ?
> > >   if (data[0] != len)
> > >   return -Esomething;
> > 
> > No. Then we would not even need the len parameter. The idea is to
> > allow reading a number of bytes specified by caller, regardless of the
> > maximum size of the block.
> > 
> If I2C_FUNC_I2C is not supported but I2C_FUNC_SMBUS_I2C_BLOCK is, the
> regmap core will use i2c_smbus_read_i2c_block_data() and validate the
> return length. It will return -EIO if it does not match. That seems
> inconsistent.

For some reason I though that regmap-i2c supports
I2C_FUNC_SMBUS_BLOCK_DATA functionality instead of
I2C_FUNC_SMBUS_I2C_BLOCK_DATA. I stand corrected.

> Also, I am not sure how you know that at least the minimum
> required number of bytes is returned if the number of bytes requested
> is larger than the number of bytes returned by the chip. Am I missing
> something ?

If the slave chip returns less bytes then what we are asking from it,
the adapter driver should return an error, timeout most likely, no? Or
did I misunderstood the question?

In any case, I will add some sanity checks. I just wanted to make sure
we don't add useless checks.

> Also, I notice that your patch does not touch tps6598x_read16(). Yet,
> according to "TPS65981, TPS65982, and TPS65986 Host Interface Technical
> Reference Manual", it appears that the 2-byte command used (0x3f) does
> support/use block commands. Is that an oversight or on purpose ?

I did not change it because in my test I did not see the byte count in
the first byte, but I'm questioning myself now... I need to re-check
it. I may have done that test with wrong platform.


Thanks Guenter,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB regression for Android phone and sound card in 4.14

[Nazar Mokrynskyi]

My expectation is that kernel will figure out what to load first on its own.

What HCD stands for in your message? USB hub is connected to native USB 2.0 
port on motherboard with Z370 chipset.

Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

24.04.18 11:04, Oliver Neukum пише:
> Am Dienstag, den 24.04.2018, 07:35 +0300 schrieb Nazar Mokrynskyi:
>> I've tried to bisect kernels from 4.13 to 4.14 and didn't find the reason. 
>> Then I found that with upstream 4.13 the issue is still present on Ubuntu 
>> 18.04, so there should be something more than just a kernel.
>>
>> Eventually, I found that issue is somehow related to USB hub I use for my 
>> periferals (mouse, keyboard and sound card).
>>
>> When sound card is connected separately, it is properly initialized as USB 
>> 2.0 device: https://pastebin.com/0rv1aUBz
>>
>> However, when connected to USB hub, it initializes as USB 1.1 device, in 
>> which case it disables some of its capabilities, like 5.1 output mode: 
>> https://pastebin.com/i4qE9JTZ
>>
>> Can't blame USB hub for this, since when I unplug it with mentioned 3 
>> devices and plug back - everything works fine, the issue only happens on 
>> system boot.
>>
>> USB hub I use at the moment (used another before with the same outcome): 
>> https://pastebin.com/wkA6D9TP
> You need to make sure ehci/hcd is loaded before ohci or uhci, if indeed
> you have a setup with true companion controllers. Which HCD are you
> using?
>
>   Regards
>   Oliver
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Oliver Neukum]

Am Montag, den 23.04.2018, 18:35 +0530 schrieb Tushar Nimkar:
> hi,
> 
> On 2018-04-23 18:20, Oliver Neukum wrote:
> > Am Donnerstag, den 19.04.2018, 20:18 +0530 schrieb Tushar Nimkar:

> > No. But for testing we don't need to. Can you confirm that
> > the problem is triggered by specific commands?
> 
> Observed with REPORT_LUN or READ_CAP16 or INQUIRY command.

Well, that is not the same thing. It is possible that these commands
generally fail, but x86_64 has a working error handling but ARM does
not.

> Are you planning to test it with dwc3?

No, I am sorry. I would need to acquire some very specific hardware.

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] usb: dwc2: fix isoc split in transfer with no data

[wlf]

Dear Sergei,


在 2018年04月24日 16:27, Sergei Shtylyov 写道:

Hello!

On 4/24/2018 5:43 AM, William Wu wrote:


If isoc split in transfer with no data (the length of DATA0
packet is 0), we can't simply return immediately. Because the
DATA0 can be the first transaction or the second transaction for
the isoc split in transaction. If the DATA0 packet with on data

  ^^ no?

Thank you for correcting me. I will fix it in next patch version.



is in the first transaction, we can return immediately. But if
the the DATA0 packet with on data is in the second transaction


  One "the" too many. And that "on data" again... :-)
Ah, sorry to make such a simple mistake. I will fix these in next patch 
version.



of isoc split in transaction sequence, we need to increase the
qtd->isoc_frame_index and giveback urb to device driver if needed,
otherwise, the MDATA packet will be lost.

A typical test case is that connect the dwc2 controller with an
usb hs Hub (GL852G-12), and plug an usb fs audio device (Plantronics
headset) into the downstream port of Hub. Then use the usb mic
to record, we can find noise when playback.

In the case, the isoc split in transaction sequence like this:

- SSPLIT IN transaction
- CSPLIT IN transaction
   - MDATA packet (176 bytes)
- CSPLIT IN transaction
   - DATA0 packet (0 byte)

This patch use both the length of DATA0 and qtd->isoc_split_offset
to check if the DATA0 is in the second transaction.

Signed-off-by: William Wu 

[...]

MBR, Sergei

Best regards,
    wulf







--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Heiko Stübner]

Hi Tomeu,

Am Montag, 23. April 2018, 15:24:04 CEST schrieb Tomeu Vizoso:
> Hi,
> 
> could this patch be picked up, please? Or if for some reason it cannot
> be, could the commit that introduced the regression be reverted?
> 
> It's causing some tests in KernelCI to fail:
> 
> https://storage.kernelci.org/next/master/next-20180423/arm/multi_v7_defconfi
> g/lab-collabora/sleep-rk3288-veyron-jaq.html

I think at this point, it might be good to do a "v4 RESEND" in a _new_ mail 
thread, because from the lack of communication it really looks like this
fell through completely.

Ideally also include in the commit message that his breaks kernelCI tests
and real board users (and of course recent tags).


Heiko

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: always build usb/common/ targets; fixes extcon-axp288 build error

[Hans de Goede]

Hi,

On 24-04-18 09:42, Chanwoo Choi wrote:

On 2018년 04월 17일 18:01, Hans de Goede wrote:

Hi,

On 17-04-18 07:14, Randy Dunlap wrote:

From: Randy Dunlap 

The extcon-axp288 driver selects USB_ROLE_SWITCH, but the USB
Makefile does not currently build drivers/usb/common/ (where
USB_ROLE_SWITCH code is) unless USB_COMMON is set, so modify
the USB Makefile to always descend into drivers/usb/common/
to build its configured targets.

Fixes these build errors:

ERROR: "usb_role_switch_get" [drivers/extcon/extcon-axp288.ko] undefined!
ERROR: "usb_role_switch_set_role" [drivers/extcon/extcon-axp288.ko] undefined!
ERROR: "usb_role_switch_get_role" [drivers/extcon/extcon-axp288.ko] undefined!
ERROR: "usb_role_switch_put" [drivers/extcon/extcon-axp288.ko] undefined!

An alternative patch would be to select USB_COMMON in the EXTCON_AXP288
driver Kconfig entry, but this would build more code in
drivers/usb/common/ than is necessary.


Ah, that variant of fixing this got posted yesterday and I acked that,
but I agree that this version is better.

Greg, what is your take on this fix?

Chanwoo Choi, please wait with merging the fix from yesterday until
we've a decision which fix to use.


OK. I'll not send pull request for fix patches until deciding them.


Greg has picked up another patch to fix this, so you can drop this.

Regards,

Hans

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] usb: dwc2: fix isoc split in transfer with no data

[Sergei Shtylyov]

Hello!

On 4/24/2018 5:43 AM, William Wu wrote:


If isoc split in transfer with no data (the length of DATA0
packet is 0), we can't simply return immediately. Because the
DATA0 can be the first transaction or the second transaction for
the isoc split in transaction. If the DATA0 packet with on data

  ^^ no?


is in the first transaction, we can return immediately. But if
the the DATA0 packet with on data is in the second transaction


  One "the" too many. And that "on data" again... :-)


of isoc split in transaction sequence, we need to increase the
qtd->isoc_frame_index and giveback urb to device driver if needed,
otherwise, the MDATA packet will be lost.

A typical test case is that connect the dwc2 controller with an
usb hs Hub (GL852G-12), and plug an usb fs audio device (Plantronics
headset) into the downstream port of Hub. Then use the usb mic
to record, we can find noise when playback.

In the case, the isoc split in transaction sequence like this:

- SSPLIT IN transaction
- CSPLIT IN transaction
   - MDATA packet (176 bytes)
- CSPLIT IN transaction
   - DATA0 packet (0 byte)

This patch use both the length of DATA0 and qtd->isoc_split_offset
to check if the DATA0 is in the second transaction.

Signed-off-by: William Wu 

[...]

MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB regression for Android phone and sound card in 4.14

[Oliver Neukum]

Am Dienstag, den 24.04.2018, 07:35 +0300 schrieb Nazar Mokrynskyi:
> I've tried to bisect kernels from 4.13 to 4.14 and didn't find the reason. 
> Then I found that with upstream 4.13 the issue is still present on Ubuntu 
> 18.04, so there should be something more than just a kernel.
> 
> Eventually, I found that issue is somehow related to USB hub I use for my 
> periferals (mouse, keyboard and sound card).
> 
> When sound card is connected separately, it is properly initialized as USB 
> 2.0 device: https://pastebin.com/0rv1aUBz
> 
> However, when connected to USB hub, it initializes as USB 1.1 device, in 
> which case it disables some of its capabilities, like 5.1 output mode: 
> https://pastebin.com/i4qE9JTZ
> 
> Can't blame USB hub for this, since when I unplug it with mentioned 3 devices 
> and plug back - everything works fine, the issue only happens on system boot.
> 
> USB hub I use at the moment (used another before with the same outcome): 
> https://pastebin.com/wkA6D9TP

You need to make sure ehci/hcd is loaded before ohci or uhci, if indeed
you have a setup with true companion controllers. Which HCD are you
using?

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: always build usb/common/ targets; fixes extcon-axp288 build error

[Chanwoo Choi]

On 2018년 04월 17일 18:01, Hans de Goede wrote:
> Hi,
> 
> On 17-04-18 07:14, Randy Dunlap wrote:
>> From: Randy Dunlap 
>>
>> The extcon-axp288 driver selects USB_ROLE_SWITCH, but the USB
>> Makefile does not currently build drivers/usb/common/ (where
>> USB_ROLE_SWITCH code is) unless USB_COMMON is set, so modify
>> the USB Makefile to always descend into drivers/usb/common/
>> to build its configured targets.
>>
>> Fixes these build errors:
>>
>> ERROR: "usb_role_switch_get" [drivers/extcon/extcon-axp288.ko] undefined!
>> ERROR: "usb_role_switch_set_role" [drivers/extcon/extcon-axp288.ko] 
>> undefined!
>> ERROR: "usb_role_switch_get_role" [drivers/extcon/extcon-axp288.ko] 
>> undefined!
>> ERROR: "usb_role_switch_put" [drivers/extcon/extcon-axp288.ko] undefined!
>>
>> An alternative patch would be to select USB_COMMON in the EXTCON_AXP288
>> driver Kconfig entry, but this would build more code in
>> drivers/usb/common/ than is necessary.
> 
> Ah, that variant of fixing this got posted yesterday and I acked that,
> but I agree that this version is better.
> 
> Greg, what is your take on this fix?
> 
> Chanwoo Choi, please wait with merging the fix from yesterday until
> we've a decision which fix to use.

OK. I'll not send pull request for fix patches until deciding them.

> 
> Regards,
> 
> Hans
> 
> 
> 
>>
>> Reported-by: Fengguang Wu 
>> Signed-off-by: Randy Dunlap 
>> Cc: MyungJoo Ham 
>> Cc: Chanwoo Choi 
>> Cc: Hans de Goede 
>> Cc: Greg Kroah-Hartman 
>> Cc: Andy Shevchenko 
>> Cc: Heikki Krogerus 
>> Cc: linux-usb@vger.kernel.org
>> ---
>>   drivers/usb/Makefile |2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> --- lnx-417-rc1.orig/drivers/usb/Makefile
>> +++ lnx-417-rc1/drivers/usb/Makefile
>> @@ -60,7 +60,7 @@ obj-$(CONFIG_USB_CHIPIDEA)+= chipidea/
>>   obj-$(CONFIG_USB_RENESAS_USBHS)+= renesas_usbhs/
>>   obj-$(CONFIG_USB_GADGET)+= gadget/
>>   -obj-$(CONFIG_USB_COMMON)+= common/
>> +obj-y+= common/
>> obj-$(CONFIG_USBIP_CORE)+= usbip/
>>  
>>
> 
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html