Re: [PATCH 1/2] [v2] bus: mhi: pci_generic: Introduce Foxconn T99W175 support

ood, I assume that for now, you're relying on additional patches for the control path, like mhi_uci or mhi_wwan_ctrl. Reviewed-by: Loic Poulain > --- > drivers/bus/mhi/pci_generic.c | 47 +++ > 1 file changed, 47 insertions(+) > > diff --git a/drivers/bus/

Re: [PATCH net-next v9 1/2] net: Add a WWAN subsystem

Hi Dan, On Wed, 7 Apr 2021 at 16:32, Dan Williams wrote: > > On Mon, 2021-04-05 at 11:52 +0200, Loic Poulain wrote: > > This change introduces initial support for a WWAN framework. Given > > the > > complexity and heterogeneity of existing WWAN hard

Re: [PATCH] bus: mhi: pci_generic: Introduce Foxconn T99W175 support

Hi Jarvis, On Wed, 7 Apr 2021 at 04:51, Jarvis Jiang wrote: > > Add support for T99W175 modems, this modem series is based on SDX55 > qcom chip. The modem is mainly based on MBIM protocol for both the > data and control path. > > This patch was tested with Ubuntu 20.04 X86_64 PC as host > >

Re: [PATCH] bus: mhi: pci_generic: Add SDX65 based modem support

On Fri, 2 Apr 2021 at 23:33, Bhaumik Bhatt wrote: > > Add generic info for SDX65 based modems. > > Signed-off-by: Bhaumik Bhatt > --- > This patch was tested on SDX65 hardware with Ubuntu X86_64 PC as host. Good to see that! Reviewed-by: Loic Poulain

Re: [PATCH net-next v9 2/2] net: Add Qcom WWAN control driver

On Mon, 5 Apr 2021 at 11:44, Loic Poulain wrote: > > The MHI WWWAN control driver allows MHI QCOM-based modems to expose > different modem control protocols/ports via the WWAN framework, so that > userspace modem tools or daemon (e.g. ModemManager) can control WWAN > config and st

[PATCH net-next v9 2/2] net: Add Qcom WWAN control driver

for controlling a modem, and for which related opensource userpace support exist. Signed-off-by: Loic Poulain --- v2: update copyright (2021) v3: Move driver to dedicated drivers/net/wwan directory v4: Rework to use wwan framework instead of self cdev management v5: Fix errors/typos

[PATCH net-next v9 1/2] net: Add a WWAN subsystem

proposal. This initial version is purposely minimalist, it's essentially moving the generic part of the previously proposed mhi_wwan_ctrl driver inside a common WWAN framework, but the implementation is open and flexible enough to allow extension for further drivers. Signed-off-by: Loic Poulain

Re: [PATCH net-next v8 2/2] net: Add Qcom WWAN control driver

On Fri, 2 Apr 2021 at 17:43, Greg KH wrote: > > On Fri, Apr 02, 2021 at 05:41:01PM +0200, Loic Poulain wrote: > > On Fri, 2 Apr 2021 at 16:05, Greg KH wrote: > > > > > > On Fri, Apr 02, 2021 at 04:06:37PM +0200, Loic Poulain wrote: > > > > The MHI

Re: [PATCH net-next v8 2/2] net: Add Qcom WWAN control driver

On Fri, 2 Apr 2021 at 16:05, Greg KH wrote: > > On Fri, Apr 02, 2021 at 04:06:37PM +0200, Loic Poulain wrote: > > The MHI WWWAN control driver allows MHI QCOM-based modems to expose > > different modem control protocols/ports via the WWAN framework, so that > > userspa

[PATCH net-next v8 2/2] net: Add Qcom WWAN control driver

for controlling a modem, and for which related opensource userpace support exist. Signed-off-by: Loic Poulain --- v2: update copyright (2021) v3: Move driver to dedicated drivers/net/wwan directory v4: Rework to use wwan framework instead of self cdev management v5: Fix errors/typos

[PATCH net-next v8 1/2] net: Add a WWAN subsystem

and flexible enough to allow extension for further drivers. Signed-off-by: Loic Poulain --- v2: not part of the series v3: not part of the series v4: Introduce WWAN framework/subsystem v5: Specify WWAN_CORE module name in Kconfig v6: - Move to unified wwan_core.c file - Make wwan_port

Re: [PATCH v1 7/7] bus: mhi: core: Improve state strings for debug messages

Sadhasivam Reviewed-by: Loic Poulain

Re: [PATCH v1 6/7] bus: mhi: core: Wait for MHI READY state in most scenarios

ove > conditionals in handling firmware load for PBL modes and keeps > the execution environment out of the picture as it can change at > any time. > > Signed-off-by: Bhaumik Bhatt Reviewed-by: Loic Poulain

Re: [PATCH v1 5/7] bus: mhi: core: Identify Flash Programmer as a mission mode use case

ower up instead by identifying Flash > Programmer as a valid mission mode execution environment with a > purpose to flash the device image contents. > > Signed-off-by: Bhaumik Bhatt > Reviewed-by: Manivannan Sadhasivam Reviewed-by: Loic Poulain

Re: [PATCH v1 4/7] bus: mhi: core: Add support for Flash Programmer execution environment

Firehose protocol. Link to USB flashing > tool: https://git.linaro.org/landing-teams/working/qualcomm/qdl.git/ > > Make the necessary changes to allow for this sequence to occur and > allow using the Flash Programmer execution environment. > > Signed-off-by: Carl Yin > Co-deve

Re: [PATCH v1 3/7] bus: mhi: core: Handle EDL mode entry appropriately

gt; within the MHI core driver and helps pave the way for Flash > Programmer execution environment functionality. > > Signed-off-by: Bhaumik Bhatt Reviewed-by: Loic Poulain

Re: [PATCH v1 2/7] bus: mhi: core: Wait for ready after an EDL firmware download

lash Programmer execution environment. > > Signed-off-by: Bhaumik Bhatt > Reviewed-by: Manivannan Sadhasivam Reviewed-by: Loic Poulain

Re: [PATCH v1 1/7] bus: mhi: core: Rely on accurate method to determine EDL mode

ly on the local 'fw_name' variable > as a safer alternative. > > Signed-off-by: Bhaumik Bhatt > Reviewed-by: Manivannan Sadhasivam Reviewed-by: Loic Poulain

Re: [PATCH v4 1/3] bus: mhi: core: Introduce internal register poll helper function

On Thu, 18 Mar 2021 at 17:13, Jeffrey Hugo wrote: > > On 3/17/2021 3:26 PM, Bhaumik Bhatt wrote: > > On 2021-03-11 11:59 AM, Jeffrey Hugo wrote: > >> On 3/11/2021 1:00 AM, Loic Poulain wrote: > >>> Hi Bhaumik, > >>> > >>>

Re: [PATCH][next] bus: mhi: core: remove redundant initialization of variables state and ee

esses-Coverity: ("Unused value") > Signed-off-by: Colin Ian King Reviewed-by: Loic Poulain > --- > drivers/bus/mhi/core/main.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c >

Re: [PATCH net-next v5 1/2] net: Add a WWAN subsystem

Hi Greg, On Fri, 12 Mar 2021 at 07:56, Greg KH wrote: > > On Thu, Mar 11, 2021 at 09:41:03PM +0100, Loic Poulain wrote: > > This change introduces initial support for a WWAN subsystem. Given the > > complexity and heterogeneity of existing WWAN hardwares and interfaces, >

Re: [PATCH net-next v5 2/2] net: Add Qcom WWAN control driver

Hi Greg, On Fri, 12 Mar 2021 at 09:16, Greg KH wrote: > > On Thu, Mar 11, 2021 at 09:41:04PM +0100, Loic Poulain wrote: > > The MHI WWWAN control driver allows MHI QCOM-based modems to expose > > different modem control protocols/ports to userspace, so that userspace > &g

[PATCH net-next v5 2/2] net: Add Qcom WWAN control driver

subsystem (when available) or to be discussed as a new MHI driver (e.g AI accelerator, WiFi debug channels, etc...). Signed-off-by: Loic Poulain --- v2: update copyright (2021) v3: Move driver to dedicated drivers/net/wwan directory v4: Rework to use wwan framework instead of self cdev

[PATCH net-next v5 1/2] net: Add a WWAN subsystem

and flexible enough to allow extension for further drivers. Signed-off-by: Loic Poulain --- v2: not part of the series v3: not part of the series v4: Introduce WWAN framework/subsystem v5: Specify WWAN_CORE module name in Kconfig drivers/net/Kconfig | 2 + drivers/net/Makefile

Re: [PATCH net-next v4 1/2] net: Add a WWAN subsystem

On Thu, 11 Mar 2021 at 17:48, Greg KH wrote: > > On Thu, Mar 11, 2021 at 05:39:05PM +0100, Loic Poulain wrote: > > This change introduces initial support for a WWAN subsystem. Given the > > complexity and heterogeneity of existing WWAN hardwares and interfaces, > > there

[PATCH net-next v4 2/2] net: Add Qcom WWAN control driver

subsystem (when available) or to be discussed as a new MHI driver (e.g AI accelerator, WiFi debug channels, etc...). Signed-off-by: Loic Poulain --- drivers/net/wwan/Kconfig | 14 ++ drivers/net/wwan/Makefile| 1 + drivers/net/wwan/mhi_wwan_ctrl.c | 497

[PATCH net-next v4 1/2] net: Add a WWAN subsystem

and flexible enough to allow extension for further drivers. Signed-off-by: Loic Poulain --- drivers/net/Kconfig | 2 + drivers/net/Makefile | 1 + drivers/net/wwan/Kconfig | 19 ++ drivers/net/wwan/Makefile| 8 +++ drivers/net/wwan/wwan_core.c | 150

Re: [PATCH v4 1/3] bus: mhi: core: Introduce internal register poll helper function

Hi Bhaumik, On Thu, 11 Mar 2021 at 00:31, Bhaumik Bhatt wrote: > > Introduce helper function to allow MHI core driver to poll for > a value in a register field. This helps reach a common path to > read and poll register values along with a retry time interval. > > Signed-off-by: Bhaumik Bhatt >

Re: [PATCH net-next v3] net: Add Qcom WWAN control driver

Hi Greg, On Tue, 9 Mar 2021 at 10:35, Greg KH wrote: > > On Tue, Mar 09, 2021 at 09:42:16AM +0100, Loic Poulain wrote: > > The MHI WWWAN control driver allows MHI Qcom based modems to expose > > different modem control protocols/ports to userspace, so that userspace > &g

[PATCH net-next v3] net: Add Qcom WWAN control driver

-by: Loic Poulain --- v2: update copyright (2021) v3: Move driver to dedicated drivers/net/wwan directory drivers/net/Kconfig | 2 + drivers/net/Makefile | 1 + drivers/net/wwan/Kconfig | 26 ++ drivers/net/wwan/Makefile| 6 + drivers/net/wwan

Re: [PATCH v2] bus: mhi: Add Qcom WWAN control driver

On Tue, 9 Mar 2021 at 09:19, Greg KH wrote: > > On Mon, Mar 08, 2021 at 09:59:27PM +0100, Loic Poulain wrote: > > The MHI WWWAN control driver allows MHI Qcom based modems to expose > > different modem control protocols to userspace, so that userspace > > modem tools or d

Re: [PATCH] bus: mhi: Add Qcom WWAN control driver

Hi Jakub, On Mon, 8 Mar 2021 at 19:51, Jakub Kicinski wrote: > > On Mon, 8 Mar 2021 19:40:51 +0100 Loic Poulain wrote: > > The MHI WWWAN control driver allows MHI Qcom based modems to expose > > different modem control protocols to userspace, so that userspace > > mo

[PATCH v2] bus: mhi: Add Qcom WWAN control driver

) or to be discussed as a new MHI driver (e.g AI accelerator, WiFi debug channels, etc...). Co-developed-by: Hemant Kumar Signed-off-by: Hemant Kumar Signed-off-by: Loic Poulain --- v2: update copyright (2021) drivers/bus/mhi/Kconfig | 12 + drivers/bus/mhi/Makefile| 3 + drivers/bus

[PATCH] bus: mhi: Add Qcom WWAN control driver

) or to be discussed as a new MHI driver (e.g AI accelerator, WiFi debug channels, etc...). Co-developed-by: Hemant Kumar Signed-off-by: Hemant Kumar Signed-off-by: Loic Poulain --- drivers/bus/mhi/Kconfig | 12 + drivers/bus/mhi/Makefile| 3 + drivers/bus/mhi/wwan_ctrl.c | 559

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

On Thu, 4 Mar 2021 at 23:14, Bhaumik Bhatt wrote: > > As per documentation, fields marked as (required) in an MHI > controller structure need to be populated by the controller driver > before calling mhi_register_controller(). Ensure all required > pointers and non-zero fields are present in the

Re: [PATCH v3 1/3] bus: mhi: core: Introduce internal register poll helper function

On Wed, 24 Feb 2021 at 04:44, Bhaumik Bhatt wrote: > > Introduce helper function to allow MHI core driver to poll for > a value in a register field. This helps reach a common path to > read and poll register values along with a retry time interval. > > Signed-off-by: Bhaumik Bhatt > --- >

Re: [PATCH v6 4/4] bus: mhi: core: Update debug prints to include local device state

On Thu, 25 Feb 2021 at 00:23, Bhaumik Bhatt wrote: > > Update debug prints to include local device in the BHI interrupt > handler. This helps show transitions better between MHI states. > > Signed-off-by: Bhaumik Bhatt > Reviewed-by: Manivannan Sadhasivam Reviewed-by: Loic Poulain

Re: [PATCH v6 3/4] bus: mhi: core: Process execution environment changes serially

we use the correct execution environment > to notify the controller driver when the device resets to one of > the PBL execution environments. > > Signed-off-by: Bhaumik Bhatt Looking good now Reviewed-by: Loic Poulain

Re: [PATCH v6 2/4] bus: mhi: core: Download AMSS image from appropriate function

e host download the AMSS > image from the SBL transition of PM state worker thread when a > DEV_ST_TRANSITION_SBL is queued instead of the blocking wait. > > Signed-off-by: Bhaumik Bhatt > Reviewed-by: Manivannan Sadhasivam Reviewed-by: Loic Poulain

Re: [PATCH v6 1/4] bus: mhi: core: Destroy SBL devices when moving to mission mode

e gap and destroy > devices in such scenarios that allow SBL client drivers to clean > up once device enters mission mode. > > Signed-off-by: Bhaumik Bhatt Reviewed-by: Loic Poulain

Re: [PATCH] mhi_bus: core: Return EBUSY if MHI ring is full

On Wed, 17 Feb 2021 at 16:06, Jeffrey Hugo wrote: > > On 2/17/2021 8:02 AM, Loic Poulain wrote: > > On Tue, 16 Feb 2021 at 19:50, Jeffrey Hugo wrote: > >> > >> From: Fan Wu > >> > >> Currently ENOMEM is returned when MHI ring is full. This err

Re: [PATCH] mhi_bus: core: Return EBUSY if MHI ring is full

On Tue, 16 Feb 2021 at 19:50, Jeffrey Hugo wrote: > > From: Fan Wu > > Currently ENOMEM is returned when MHI ring is full. This error code is > very misleading. Change to EBUSY instead. Well, there is no space left in the ring, so it's no so misleading. Regards, Loic

Re: [PATCH] bus: mhi: core: Fix check for syserr at power_up

failure, which is likely to incorrectly cause a device init failure > if syserr was detected at power_up. Fix this. > > Fixes: e18d4e9fa79b ("bus: mhi: core: Handle syserr during power_up") > Signed-off-by: Jeffrey Hugo Reviewed-by: Loic Poulain > --- > drivers/bus/mhi/core

Re: [PATCH] bus: mhi: core: Use current ee in intvec handler for syserr

Add support for basic PM operations") > Signed-off-by: Jeffrey Hugo So in that function, 'ee' should be 'previous_ee', right? Reviewed-by: Loic Poulain

Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver

Hi Jakub, On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski wrote: > > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > > >> Jakub, Dave, Adding you both to get your reviews on this series. I've > > >> provided an explanation above and in the previous iteration [1]. > > > > > >Let's

Re: [PATCH 1/1] PCI: add Telit Vendor ID

Hi Daniele, On Tue, 19 Jan 2021 at 23:06, Bjorn Helgaas wrote: > > On Tue, Jan 19, 2021 at 11:27:57AM +0100, Daniele Palmas wrote: > > Add Telit Vendor ID to pci_ids.h > > From the top of the file: > > * Do not add new entries to this file unless the definitions > * are shared

Re: [PATCH net-next 1/3] bus: mhi: core: Add helper API to return number of free TREs

On Mon, 11 Jan 2021 at 18:28, Jakub Kicinski wrote: > > On Mon, 11 Jan 2021 18:16:17 +0100 Loic Poulain wrote: > > From: Hemant Kumar > > > > Introduce mhi_get_free_desc_count() API to return number > > of TREs available to queue buffer. MHI clients can use th

[PATCH net-next 2/3] net: mhi: Get RX queue size from MHI core

The RX queue size can be determined at runtime by retrieving the number of available transfer descriptors. Signed-off-by: Loic Poulain --- drivers/net/mhi_net.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/mhi_net.c b/drivers/net/mhi_net.c index b7f7f2e

[PATCH net-next 3/3] net: mhi: Get rid of local rx queue count

Use the new mhi_get_free_desc_count helper to track queue usage instead of relying on the locally maintained rx_queued count. Signed-off-by: Loic Poulain --- drivers/net/mhi_net.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/net/mhi_net.c b/drivers

[PATCH net-next 1/3] bus: mhi: core: Add helper API to return number of free TREs

From: Hemant Kumar Introduce mhi_get_free_desc_count() API to return number of TREs available to queue buffer. MHI clients can use this API to know before hand if ring is full without calling queue API. Signed-off-by: Hemant Kumar Reviewed-by: Jeffrey Hugo Reviewed-by: Manivannan Sadhasivam

[PATCH 2/3] net: mhi: Get RX queue size from MHI core

The RX queue size can be determined at runtime by retrieving the number of available transfer descriptors. Signed-off-by: Loic Poulain --- drivers/net/mhi_net.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/mhi_net.c b/drivers/net/mhi_net.c index b7f7f2e

[PATCH 1/3] bus: mhi: core: Add helper API to return number of free TREs

From: Hemant Kumar Introduce mhi_get_free_desc_count() API to return number of TREs available to queue buffer. MHI clients can use this API to know before hand if ring is full without calling queue API. Signed-off-by: Hemant Kumar Reviewed-by: Jeffrey Hugo Reviewed-by: Manivannan Sadhasivam

Re: [PATCH v2] net: mhi: Add raw IP mode support

Hi Jakub, On Thu, 17 Dec 2020 at 17:58, Jakub Kicinski wrote: > > On Thu, 17 Dec 2020 16:34:09 +0100 Loic Poulain wrote: > > MHI net is protocol agnostic, the payload protocol depends on the modem > > configuration, which can be either RMNET (IP muxing and aggregation) or >

[PATCH v2] net: mhi: Add raw IP mode support

MHI net is protocol agnostic, the payload protocol depends on the modem configuration, which can be either RMNET (IP muxing and aggregation) or raw IP. This patch adds support for incomming IPv4/IPv6 packets, that was previously unconditionnaly reported as RMNET packets. Signed-off-by: Loic

Re: [PATCH v18 0/3] userspace MHI client interface driver

Hi Folks, On Fri, 11 Dec 2020 at 20:45, Hemant Kumar wrote: > > This patch series adds support for UCI driver. UCI driver enables userspace > clients to communicate to external MHI devices like modem. UCI driver probe > creates standard character device file nodes for userspace clients to >

Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver

On Fri, 11 Dec 2020 at 08:44, Greg KH wrote: > > On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer > > raw data between MHI device and host using standard file operations. > > Driver instantiates UCI device object which

Re: [PATCH v13 4/4] bus: mhi: Add userspace client interface driver

On Tue, 1 Dec 2020 at 18:51, Jeffrey Hugo wrote: > > On 12/1/2020 10:52 AM, Loic Poulain wrote: > > On Tue, 1 Dec 2020 at 18:37, Jeffrey Hugo wrote: > >> > >> On 12/1/2020 10:36 AM, Loic Poulain wrote: > >>> On Tue, 1 Dec 2020 at 02:16,

Re: [PATCH v13 4/4] bus: mhi: Add userspace client interface driver

On Tue, 1 Dec 2020 at 18:37, Jeffrey Hugo wrote: > > On 12/1/2020 10:36 AM, Loic Poulain wrote: > > On Tue, 1 Dec 2020 at 02:16, Hemant Kumar wrote: > >> > >> Hi Loic, > >> > >> On 11/30/20 10:22 AM, Loic Poulain wrote: > &g

Re: [PATCH v13 4/4] bus: mhi: Add userspace client interface driver

On Tue, 1 Dec 2020 at 02:16, Hemant Kumar wrote: > > Hi Loic, > > On 11/30/20 10:22 AM, Loic Poulain wrote: > > On Sat, 28 Nov 2020 at 04:26, Hemant Kumar wrote: > >> > >> This MHI client driver allows userspace clients to transfer > >> raw data be

Re: [PATCH] bus: mhi: core: Fix error handling in mhi_register_controller()

se order of how things were allocated. I changed > the label names to say what the goto does instead of describing where > the goto comes from. > > Fixes: 8f7039787687 ("bus: mhi: core: Move to using high priority workqueue") > Signed-off-by: Dan Carpenter Reviewed-by: Loic Poulain

Re: [PATCH v13 4/4] bus: mhi: Add userspace client interface driver

On Sat, 28 Nov 2020 at 04:26, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer > raw data between MHI device and host using standard file operations. > Driver instantiates UCI device object which is associated to device > file node. UCI device object

Re: [PATCH v12 4/5] bus: mhi: Add userspace client interface driver

Just one comment: On Mon, 16 Nov 2020 at 23:46, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer > raw data between MHI device and host using standard file operations. > Driver instantiates UCI device object which is associated to device > file node. UCI device

Re: [PATCH v12 1/5] bus: mhi: core: Add helper API to return number of free TREs

On Mon, 16 Nov 2020 at 23:46, Hemant Kumar wrote: > > Introduce mhi_get_free_desc_count() API to return number > of TREs available to queue buffer. MHI clients can use this > API to know before hand if ring is full without calling queue > API. > > Signed-off-by: Hemant Kumar > Reviewed-by:

Re: [PATCH v12 5/5] selftest: mhi: Add support to test MHI LOOPBACK channel

On Mon, 16 Nov 2020 at 23:46, Hemant Kumar wrote: > > Loopback test opens the MHI device file node and writes > a data buffer to it. MHI UCI kernel space driver copies > the data and sends it to MHI uplink (Tx) LOOPBACK channel. > MHI device loops back the same data to MHI downlink (Rx) >

Re: [PATCH v1 3/4] bus: mhi: core: Add support to pause or resume channel data transfers

Hi Bhaumik, On Wed, 11 Nov 2020 at 01:40, Bhaumik Bhatt wrote: > > Hi Loic, > > On 2020-11-10 03:14, Loic Poulain wrote: > > Hi Bhaumik, > > > > On Mon, 9 Nov 2020 at 23:44, Bhaumik Bhatt > > wrote: > >> > >> Some MHI clients may wa

Re: [PATCH v1 3/4] bus: mhi: core: Add support to pause or resume channel data transfers

Hi Bhaumik, On Mon, 9 Nov 2020 at 23:44, Bhaumik Bhatt wrote: > > Some MHI clients may want to request for pausing or resuming of the > data transfers for their channels. Enable them to do so using the new > APIs provided for the same. > > Signed-off-by: Bhaumik Bhatt > --- >

Re: [PATCH v8 4/4] bus: mhi: Add userspace client interface driver

Hi Hemant, A few comments inline. On Thu, 22 Oct 2020 at 10:22, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer > raw data between MHI device and host using standard file operations. > Driver instantiates UCI device object which is associated to device > file

Re: [PATCH v7 1/4] bus: mhi: core: Add helper API to return number of free TREs

On Wed, 21 Oct 2020 at 18:25, Manivannan Sadhasivam wrote: > > On Wed, Oct 21, 2020 at 05:43:14PM +0200, Loic Poulain wrote: > > On Wed, 21 Oct 2020 at 17:27, Manivannan Sadhasivam < > > manivannan.sadhasi...@linaro.org> wrote: > > > > > On Fri, Oct 16,

Re: [PATCH v6 4/4] bus: mhi: Add userspace client interface driver

Hi Hemant, See comments inline, but globally, the locking and ref counting is more complicated than it should be. On Wed, 16 Sep 2020 at 21:57, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer > raw data between MHI device and host using standard file

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

On Thu, 3 Sep 2020 at 09:19, Jie Deng wrote: > > > On 2020/9/3 14:12, Jason Wang wrote: > > > > On 2020/9/3 下午1:34, Jie Deng wrote: > >> Add an I2C bus driver for virtio para-virtualization. > >> > >> The controller can be emulated by the backend driver in > >> any device model software by

Re: msm8996: sdhci-msm: apq8096-db820c sdhci fails to init - "Timeout waiting for hardware interrupt."

/git/torvalds/linux.git/commit/?id=03864e57770a9541e7ff3990bacf2d9a2fffcd5d > > No dice, same exact problem. > > But the patch is present downstream[1]: > > commit c26727f853308dc4a6645dad09e9565429f8604f > Author: Loic Poulain > Date: Wed Dec 12 17:51:48 2018 +010

Re: [PATCH 1/2] watchdog: pm8916_wdt: fix pretimeout registration flow

On Wed, 11 Sep 2019 at 19:54, Guenter Roeck wrote: > > On Wed, Sep 11, 2019 at 10:04:12AM +0200, Loic Poulain wrote: > > Hi Guenter, Jorge, > > > > On Mon, 9 Sep 2019 at 00:50, Guenter Roeck wrote: > > > > > On 9/6/19 1:30 PM, Jorge Ramirez-Ortiz wrote: &g

Re: [RESEND PATCH] media: i2c: ov5640: Add pixel clock support

Hi Sakari, >> Any comments on this change? > > > > There's also another set that adds PIXEL_CLOCK (as well as LINK_FREQ) > support to the driver, that seems more complete than this patch but > requires

Re: [RESEND PATCH] media: i2c: ov5640: Add pixel clock support

Hi Sakari, >> Any comments on this change? > > https://patchwork.linuxtv.org/project/linux-media/list/?submitter=Maxime+Ripard=*=ov5640> > > There's also another set that adds PIXEL_CLOCK (as well as LINK_FREQ) > support to the driver, that seems more complete than this patch but > requires a

Re: [RESEND PATCH] media: i2c: ov5640: Add pixel clock support

0 camera sensor driver. > > According to the datasheet, 96MHz can be used as a pixel clock rate for > most of the modes. > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasi...@linaro.org> Tested-by: Loic Poulain <loic.poul...@linaro.org> It works for me on Drag

Re: [RESEND PATCH] media: i2c: ov5640: Add pixel clock support

> According to the datasheet, 96MHz can be used as a pixel clock rate for > most of the modes. > > Signed-off-by: Manivannan Sadhasivam Tested-by: Loic Poulain It works for me on Dragonboard 410c + D3 camera mezzanine (ov5640) . Any comments on this change? Regards, Loic

Re: [PATCH v2] ARM: dts: qcom: Add apq8064 Dragon Board 600c support

Hi Srini, On 16 March 2018 at 22:54, wrote: > From: Srinivas Kandagatla > > This patch add support to DB600c board, which is another > 96boards based on Qualcomm APQ8064 SoC. > > Support for USB, HDMI, PCIe, I2C, SPI, eMMC,

Re: [PATCH v2] ARM: dts: qcom: Add apq8064 Dragon Board 600c support

Hi Srini, On 16 March 2018 at 22:54, wrote: > From: Srinivas Kandagatla > > This patch add support to DB600c board, which is another > 96boards based on Qualcomm APQ8064 SoC. > > Support for USB, HDMI, PCIe, I2C, SPI, eMMC, microSD card, LEDs > device tree nodes is added in this patch. > >

Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610

Hi Ramon, On 29 March 2018 at 09:32, Ramon Fried wrote: >> Should we document qcom,wcn3610 just like wcn3620 is: >> >> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt: >>"qcom,wcn3620", > IMHO the mentioned bindings is related to the

Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610

Hi Ramon, On 29 March 2018 at 09:32, Ramon Fried wrote: >> Should we document qcom,wcn3610 just like wcn3620 is: >> >> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt: >>"qcom,wcn3620", > IMHO the mentioned bindings is related to the PIL (peripheral image

Re: [PATCH 3/3] Bluetooth: hci_qca: Add serdev support

On 13 March 2018 at 17:03, Thierry Escande wrote: > From: Thierry Escande > > Add support for Qualcomm serial slave devices. Probe the serial device, > retrieve its maximum speed and register a new hci uart device. > > Signed-off-by:

Re: [PATCH 3/3] Bluetooth: hci_qca: Add serdev support

On 13 March 2018 at 17:03, Thierry Escande wrote: > From: Thierry Escande > > Add support for Qualcomm serial slave devices. Probe the serial device, > retrieve its maximum speed and register a new hci uart device. > > Signed-off-by: Thierry Escande > --- > drivers/bluetooth/Kconfig | 2 +-

Re: [PATCH][next] wcn36xx: remove redundant assignment to msg_body.min_ch_time

Hi Colin, Bjorn, On 26 December 2017 at 21:13, Bjorn Andersson wrote: > On Tue 19 Dec 09:04 PST 2017, Colin King wrote: > >> From: Colin Ian King >> >> msg_body.min_ch_time is being assigned twice; remove the redundant >> first assignment.

Re: [PATCH][next] wcn36xx: remove redundant assignment to msg_body.min_ch_time

Hi Colin, Bjorn, On 26 December 2017 at 21:13, Bjorn Andersson wrote: > On Tue 19 Dec 09:04 PST 2017, Colin King wrote: > >> From: Colin Ian King >> >> msg_body.min_ch_time is being assigned twice; remove the redundant >> first assignment. >> >> Detected by CoverityScan, CID#1463042 ("Unused

Re: [GIT PULL 1/2] bcm2835-dt-fixes-2017-10-06

Hi Peter, > So it seems it's actually working fine albeit the strange mac addr, no > idea what I was trying before, although there's an error about loading > firmware: > > [ 31.035291] Bluetooth: hci0: BCM: chip id 94 > [ 31.035801] Bluetooth: hci0: BCM: features 0x2e > [ 31.037483]

Re: [GIT PULL 1/2] bcm2835-dt-fixes-2017-10-06

Hi Peter, > So it seems it's actually working fine albeit the strange mac addr, no > idea what I was trying before, although there's an error about loading > firmware: > > [ 31.035291] Bluetooth: hci0: BCM: chip id 94 > [ 31.035801] Bluetooth: hci0: BCM: features 0x2e > [ 31.037483]

Re: [PATCH v12 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

ace mdelay() with msleep() v5: Addresses review comments from Loic Poulain a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG b) Used static functions where required and removed forward delcarations c) Edited comments for the function hci_uart_recv_data d) Made HCI_

Re: [PATCH v12 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

parameter and global variables e) Add logic to pick right firmware image v4: Addresses review comments from Alan a) Use existing kernel helper APIs instead of writing own. b) Replace mdelay() with msleep() v5: Addresses review comments from Loic Poulain a) Use bt_dev_err/warn/dbg helpers

Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download for Marvell

Hi Amitkumar, Hi Marcel, I suggest you to add Marcel as recipient of your patches. From: Jeffy Chen [mailto:jeffy.c...@rock-chips.com] Sent: Friday, June 24, 2016 11:32 AM To: Amitkumar Karwar; linux-blueto...@vger.kernel.org Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat Subject: Re:

Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download for Marvell

Hi Amitkumar, Hi Marcel, I suggest you to add Marcel as recipient of your patches. From: Jeffy Chen [mailto:jeffy.c...@rock-chips.com] Sent: Friday, June 24, 2016 11:32 AM To: Amitkumar Karwar; linux-blueto...@vger.kernel.org Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat Subject: Re:

Re: [PATCH v5] Bluetooth: hci_uart: Support firmware download for Marvell

f module parameter and global variables e) Add logic to pick right firmware image v4: Addresses review comments from Alan a) Use existing kernel helper APIs instead of writing own. b) Replace mdelay() with msleep() v5: Addresses review comments from Loic Poulain a) Use bt_dev_er

Re: [PATCH v5] Bluetooth: hci_uart: Support firmware download for Marvell

image v4: Addresses review comments from Alan a) Use existing kernel helper APIs instead of writing own. b) Replace mdelay() with msleep() v5: Addresses review comments from Loic Poulain a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG b) Used static functions where

Re: [PATCH v4] Bluetooth: hci_uart: Support firmware download for Marvell

Hi Amitkumar, Quick review inline. On 03/03/2016 12:56, Amitkumar Karwar wrote: From: Ganapathi Bhat This patch implement firmware download feature for Marvell Bluetooth devices. If firmware is already downloaded, it will skip downloading. Signed-off-by: Ganapathi Bhat

Re: [PATCH v4] Bluetooth: hci_uart: Support firmware download for Marvell

Hi Amitkumar, Quick review inline. On 03/03/2016 12:56, Amitkumar Karwar wrote: From: Ganapathi Bhat This patch implement firmware download feature for Marvell Bluetooth devices. If firmware is already downloaded, it will skip downloading. Signed-off-by: Ganapathi Bhat Signed-off-by:

[PATCH v3 2/2] regmap: Add iBT register access over HCI support

0x0e) plen 4 Unknown (0x3f|0x005d) ncmd 1 00 Then, if we read the same register with opcode_read 0xfc5e: < HCI Command (0x3f|0x005e) plen 6 [hci0] 04 8c 00 00 02 04 > HCI Event (0x0e) plen 12 [hci0] Unknown (0x3f|0x005e) ncmd 1 00 04 8c 00 00 2a 00 00 00 Signed-of

[PATCH v3 1/2] Bluetooth: Add hci_cmd_sync

Send a HCI command and wait for command complete event. This function serializes the requests by grabbing the req_lock. Signed-off-by: Loic Poulain --- v1: v2: no patch 1/2 v3: Add hci_cmd_sync function, used by regmap-ibt include/net/bluetooth/hci_core.h | 3 +++ net/bluetooth/hci_core.c

[PATCH v3 2/2] regmap: Add iBT register access over HCI support

0x0e) plen 4 Unknown (0x3f|0x005d) ncmd 1 00 Then, if we read the same register with opcode_read 0xfc5e: < HCI Command (0x3f|0x005e) plen 6 [hci0] 04 8c 00 00 02 04 > HCI Event (0x0e) plen 12 [hci0] Unknown (0x3f|0x005e) ncmd 1 00 04 8c 00 00 2a 00 00 00 Signed-of

[PATCH v3 1/2] Bluetooth: Add hci_cmd_sync

Send a HCI command and wait for command complete event. This function serializes the requests by grabbing the req_lock. Signed-off-by: Loic Poulain <loic.poul...@intel.com> --- v1: v2: no patch 1/2 v3: Add hci_cmd_sync function, used by regmap-ibt include/net/bluetooth/hci_core.

[PATCH v2] regmap: Add HCI iBT support

0x0e) plen 4 Unknown (0x3f|0x005d) ncmd 1 00 Then, if we read the same register with opcode_read 0xfc5e: < HCI Command (0x3f|0x005e) plen 6 [hci0] 04 8c 00 00 02 04 > HCI Event (0x0e) plen 12 [hci0] Unknown (0x3f|0x005e) ncmd 1 00 04 8c 00 00 2a 00 00 00 Signed-of

[PATCH v2] regmap: Add HCI iBT support

0x0e) plen 4 Unknown (0x3f|0x005d) ncmd 1 00 Then, if we read the same register with opcode_read 0xfc5e: < HCI Command (0x3f|0x005e) plen 6 [hci0] 04 8c 00 00 02 04 > HCI Event (0x0e) plen 12 [hci0] Unknown (0x3f|0x005e) ncmd 1 00 04 8c 00 00 2a 00 00 00 Signed-of

  1   2   >