Hi,
> -Original Message-
> From: Mats Karrman [mailto:mats.dev.l...@gmail.com]
> Sent: 2018年4月30日 15:41
> To: Jun Li
> Cc: robh...@kernel.org; gre...@linuxfoundation.org;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; a.ha...@samsung.com;
> shufan_...@richtek.com; Peter Chen ;
> de
Hi
> -Original Message-
> From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com]
> Sent: 2018年4月30日 19:24
> To: Jun Li
> Cc: robh...@kernel.org; gre...@linuxfoundation.org; li...@roeck-us.net;
> a.ha...@samsung.com; shufan_...@richtek.com; Peter Chen
> ; devicet...@vger.kernel.org;
Hi,
On 30-04-18 14:41, Heikki Krogerus wrote:
The driver will not probe unless bq24190 is loaded, so
making it a dependency.
Hmm, the dependency is pure run-time, with this Kconfig
change if a user now decides to builtin the intel_cht_int33fe
driver, the bq24190 driver must also be builtin, I'
Hi,
On 30-04-18 14:41, Heikki Krogerus wrote:
The ref count for the USB role switch device must be
released after we are done using the switch.
Fixes: c6962c29729c ("usb: typec: tcpm: Set USB role switch to device mode when
configured as such")
Signed-off-by: Heikki Krogerus
Makes sense:
R
Hi,
On 30-04-18 14:41, Heikki Krogerus wrote:
Trying to determine the USB port type with this mux is very
difficult. To simplify the situation, always allowing user
control, even if the port is USB Type-C port.
Signed-off-by: Heikki Krogerus > ---
drivers/usb/roles/intel-xhci-usb-role-switch
On Mon, Apr 30, 2018 at 11:08:42PM +0200, Paul Kocialkowski wrote:
> Hi,
>
> Le samedi 21 avril 2018 à 09:34 -0500, Bin Liu a écrit :
> > Okay, this came down to an argument that whether we should require
> > loading a gadget driver on a dual-role port to work in host mode,
> > which is currently
Hi,
Le mardi 01 mai 2018 à 07:25 -0500, Bin Liu a écrit :
> On Mon, Apr 30, 2018 at 11:08:42PM +0200, Paul Kocialkowski wrote:
> > Hi,
> >
> > Le samedi 21 avril 2018 à 09:34 -0500, Bin Liu a écrit :
> > > Okay, this came down to an argument that whether we should require
> > > loading a gadget d
On Mon, Apr 30, 2018 at 11:05 AM, Greg Kroah-Hartman
wrote:
>
> On Mon, Apr 30, 2018 at 07:54:17AM -0500, David R. Bild wrote:
> > This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
> > hardware module for authenticating IoT devices and gateways.
> >
> Overall it looks good to me,
Hi,
On Fri, Apr 27, 2018 at 03:00:05PM +0200, Daniel Glöckner wrote:
> It has been observed that writing 0xF2 to the power register while it
> reads as 0xF4 results in the register having the value 0xF0, i.e. clearing
> RESUME and setting SUSPENDM in one go does not work. It might also violate
> t
On Tue, Apr 24, 2018 at 10:32:30PM +0200, Krzysztof Kozlowski wrote:
> 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. Th
On Tue, Apr 24, 2018 at 10:32:31PM +0200, 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
> ---
>
Hi Felipe,
2018-04-19 20:03 GMT+09:00 Masahiro Yamada :
> It is not a good idea to directly modify the resource of a platform
> device. Modify its local copy, and pass it to devm_ioremap_resource()
> so that we do not need to restore it in the failure path and the remove
> hook.
>
> Signed-off-b
On Tue, Apr 24, 2018 at 10:32:32PM +0200, 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
> ---
>
On Wed, Apr 25, 2018 at 03:45:28PM +0800, Chunfeng Yun wrote:
> Add a DT binding documentation of XS-PHY for MediaTek SoCs
> with USB3.1 GEN2 controller
>
> Signed-off-by: Chunfeng Yun
> ---
> .../devicetree/bindings/phy/phy-mtk-xsphy.txt | 127
>
> 1 file changed, 12
On Thu, Apr 26, 2018 at 01:21:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> From: Krzysztof Kozlowski
> Subject: [PATCH] thermal: samsung: Remove support for Exynos5440
>
> The Exynos5440 is not actively developed, there are no development
> boards available and probably there are no real produc
On Tue, May 01, 2018 at 03:26:57PM +0200, Paul Kocialkowski wrote:
> Hi,
>
> Le mardi 01 mai 2018 à 07:25 -0500, Bin Liu a écrit :
> > On Mon, Apr 30, 2018 at 11:08:42PM +0200, Paul Kocialkowski wrote:
> > > Hi,
> > >
> > > Le samedi 21 avril 2018 à 09:34 -0500, Bin Liu a écrit :
> > > > Okay, th
Quoting Krzysztof Kozlowski (2018-04-24 13:32:33)
> 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
> ---
Acked-by: Stephen Boy
This patch adds documentation of properties allowing the supported
set of mux modes to be restricted in situations where a bad mode
selection may have negative effects.
Signed-off-by: Mats Karrman
---
Documentation/devicetree/bindings/usb/typec-mux.txt | 18 ++
1 file changed, 18
To avoid unnecessary dependencies on tcpm.h and to pave the way
for comming patches, move the tcpc_mux_mode enum from tcpm.h to
typec.h and change its name to typec_mux_mode (the enum constants
already follow this naming).
Signed-off-by: Mats Karrman
---
drivers/usb/typec/mux/pi3usb30532.c | 6
For some devices it is necessary to specify a different initial
mux mode to use after connection. E.g. some devices may not have
USB SS support but just USB HS and an alternate mode and thus
prefer TYPEC_MUX_NONE as default mode.
Signed-off-by: Mats Karrman
---
Documentation/devicetree/bindings/
The current naming used for tcpc_mux_mode constants makes
too much assumptioms about the usage of the signals.
This patch replaces the names with generic names more closely
tied to the Type-C specifications and also adds some new ones.
At the same time TCPC_MUX_* defines are removed as they do not
This series is based on usb-next commit 252427037a36 ("typec: tcpm: Fix
incorrect 'and' operator").
In my work trying to adapt my project to the latest kernel I have ran into
a number of issues. Consider the following series an initial poll on the
acceptance of the solutions I have found.
In shor
Signed-off-by: Mats Karrman
---
drivers/usb/typec/class.c | 22 ++
include/linux/usb/typec.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 53df10d..c5432f4 100644
--- a/drivers/usb/typec/class.c
+++ b/driver
Signed-off-by: Mats Karrman
---
drivers/usb/typec/mux/pi3usb30532.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/typec/mux/pi3usb30532.c
b/drivers/usb/typec/mux/pi3usb30532.c
index d995883..3e564e6 100644
--- a/drivers/usb/typec/m
This patch allows the default mux mode to be specified using
a firmware property.
Signed-off-by: Mats Karrman
---
drivers/usb/typec/mux/pi3usb30532.c | 18 ++
drivers/usb/typec/tcpm.c| 2 +-
include/linux/usb/typec.h | 1 +
3 files changed, 20 insertions(+
Hi,
On Tue, May 01, 2018 at 08:48:11AM -0500, Bin Liu wrote:
> On Fri, Apr 27, 2018 at 03:00:05PM +0200, Daniel Glöckner wrote:
> > It has been observed that writing 0xF2 to the power register while it
> > reads as 0xF4 results in the register having the value 0xF0, i.e. clearing
> > RESUME and se
This patch fix dma unaligned problem and data lost problem for
isoc split in transfer.
Test on rk3288 platform, use an usb hs Hub (GL852G-12) and an usb
fs audio device (Plantronics headset) to capture and playback.
William Wu (2):
usb: dwc2: alloc dma aligned buffer for isoc split in
usb: dw
The commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in
a more supported way") rips out a lot of code to simply the
allocation of aligned DMA. However, it also introduces a new
issue when use isoc split in transfer.
In my test case, I connect the dwc2 controller with an usb hs
Hub (GL852G-12
If isoc split in transfer with no data (the length of DATA0
packet is zero), 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 no
data is in the first transaction, we can return im
Hi,
On Tue, May 1, 2018 at 8:04 PM, William Wu wrote:
> The commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in
> a more supported way") rips out a lot of code to simply the
> allocation of aligned DMA. However, it also introduces a new
> issue when use isoc split in transfer.
>
> In my tes
Hi,
On Tue, May 1, 2018 at 8:04 PM, William Wu wrote:
> If isoc split in transfer with no data (the length of DATA0
> packet is zero), 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 p
The table is never modified by the function. This allows us
to use it on a statically defined table that is marked const.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/usb/gadget/usbstring.c | 2 +-
include/linux/usb/gadget.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
The Aspeed BMC SoCs support a "virtual hub" function. It provides some
HW support for a top-level USB2 hub behind which sit 5 gadget "ports".
This driver adds support for the full functionality, emulating the
hub standard requests and exposing 5 UDC gadget drivers corresponding
to the ports.
The
Hi,
Greg Kroah-Hartman writes:
> On Fri, Apr 27, 2018 at 11:09:50AM +0300, Felipe Balbi wrote:
>>
>> Hi Greg,
>>
>> here's a tiny, 7 fixes only, pull request for the current -rc cycle. Let
>> me know if you want anything to be changed.
>>
>> cheers
>>
>> The following changes since commit 6d
On Mon, Apr 30, 2018 at 06:34:03AM -0700, Guenter Roeck wrote:
> On 04/30/2018 05:41 AM, Heikki Krogerus wrote:
> > Removing the "fusb302" debugfs directory when unloading
> > the driver. That allows the driver to be loaded more then
> > ones.
> >
> > This fixes an issue where the driver, if unloa
On Tue, May 01, 2018 at 11:57:55AM +0200, Hans de Goede wrote:
> Hi,
>
> On 30-04-18 14:41, Heikki Krogerus wrote:
> > Trying to determine the USB port type with this mux is very
> > difficult. To simplify the situation, always allowing user
> > control, even if the port is USB Type-C port.
> >
>
36 matches
Mail list logo
