linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeffrey Hugo <jhugo@codeaurora.org>
To: manivannan.sadhasivam@linaro.org, hemantk@codeaurora.org
Cc: bbhatt@codeaurora.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jeffrey Hugo <jhugo@codeaurora.org>
Subject: [PATCH v3 6/6] bus: mhi: core: Fix channel device name conflict
Date: Mon, 27 Apr 2020 09:59:13 -0600	[thread overview]
Message-ID: <1588003153-13139-7-git-send-email-jhugo@codeaurora.org> (raw)
In-Reply-To: <1588003153-13139-1-git-send-email-jhugo@codeaurora.org>

When multiple instances of the same MHI product are present in a system,
we can see a splat from mhi_create_devices() - "sysfs: cannot create
duplicate filename".

This is because the device names assigned to the MHI channel devices are
non-unique.  They consist of the channel's name, and the channel's pipe
id.  For identical products, each instance is going to have the same
set of channel (both in name and pipe id).

To fix this, we prepend the device name of the parent device that the
MHI channels belong to.  Since different instances of the same product
should have unique device names, this makes the MHI channel devices for
each product also unique.

Additionally, remove the pipe id from the MHI channel device name.  This
is an internal detail to the MHI product that provides little value, and
imposes too much device specific internal details to userspace.  It is
expected that channel with a specific name (ie "SAHARA") has a specific
client, and it does not matter what pipe id that channel is enumerated on.
The pipe id is an internal detail between the MHI bus, and the hardware.
The client is not expected to make decisions based on the pipe id, and to
do so would require the client to have intimate knowledge of the hardware,
which is inappropiate as it may violate the layering provided by the MHI
bus.  The limitation of doing this is that each product may only have one
instance of a channel by a unique name.  This limitation is appropriate
given the usecases of MHI channels.

Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
---
 drivers/bus/mhi/core/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 580d72b..0ac0643 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -327,7 +327,8 @@ void mhi_create_devices(struct mhi_controller *mhi_cntrl)
 
 		/* Channel name is same for both UL and DL */
 		mhi_dev->chan_name = mhi_chan->name;
-		dev_set_name(&mhi_dev->dev, "%04x_%s", mhi_chan->chan,
+		dev_set_name(&mhi_dev->dev, "%s_%s",
+			     dev_name(mhi_cntrl->cntrl_dev),
 			     mhi_dev->chan_name);
 
 		/* Init wakeup source if available */
-- 
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

  parent reply	other threads:[~2020-04-27 15:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27 15:59 [PATCH v3 0/6] Misc MHI fixes Jeffrey Hugo
2020-04-27 15:59 ` [PATCH v3 1/6] bus: mhi: core: Make sure to powerdown if mhi_sync_power_up fails Jeffrey Hugo
2020-04-28 18:52   ` Hemant Kumar
2020-04-30 16:55   ` Manivannan Sadhasivam
2020-04-27 15:59 ` [PATCH v3 2/6] bus: mhi: core: Remove link_status() callback Jeffrey Hugo
2020-04-28 18:54   ` Hemant Kumar
2020-04-27 15:59 ` [PATCH v3 3/6] bus: mhi: core: Offload register accesses to the controller Jeffrey Hugo
2020-04-28 18:56   ` Hemant Kumar
2020-04-30 16:57   ` Manivannan Sadhasivam
2020-04-27 15:59 ` [PATCH v3 4/6] bus: mhi: core: Fix typo in comment Jeffrey Hugo
2020-04-28 18:56   ` Hemant Kumar
2020-04-30 16:59   ` Manivannan Sadhasivam
2020-04-27 15:59 ` [PATCH v3 5/6] bus: mhi: core: Handle syserr during power_up Jeffrey Hugo
2020-04-27 15:59 ` Jeffrey Hugo [this message]
2020-04-28 18:57   ` [PATCH v3 6/6] bus: mhi: core: Fix channel device name conflict Hemant Kumar
2020-04-30 17:01   ` Manivannan Sadhasivam
2020-04-30 17:20 ` [PATCH v3 0/6] Misc MHI fixes Manivannan Sadhasivam
2020-04-30 17:54   ` Jeffrey Hugo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1588003153-13139-7-git-send-email-jhugo@codeaurora.org \
    --to=jhugo@codeaurora.org \
    --cc=bbhatt@codeaurora.org \
    --cc=hemantk@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).