linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jh80.chung@samsung.com (Jaehoon Chung)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC] mmc: add slot argument to mmc_of_parse
Date: Mon, 26 May 2014 16:15:42 +0900	[thread overview]
Message-ID: <5382EA1E.8060202@samsung.com> (raw)
In-Reply-To: <20140526070301.GA12777@ldesroches-Latitude-E6320>

Hi, Ludovic.

I have sent the patch based on your RFC patch..how about?
If you have the comment or other opinion, let me know, plz.

https://patchwork.kernel.org/patch/4230101/

It needs to use your suggestion at dw-mmc controller, so i have posted it.

Best Regards,
Jaehoon Chung

On 05/26/2014 04:03 PM, Ludovic Desroches wrote:
> Hi,
> 
> Sorry I was on vacation, I'll send a cleaner patch updating other drivers
> this week.
> 
> Regards
> 
> Ludovic
> 
> On Fri, May 23, 2014 at 01:38:06PM +0900, Jaehoon Chung wrote:
>> Hi, All.
>>
>> This patch is working on progress?
>> I want to merge this patch for fixing dw-mmc controller problem.
>>
>> If this patch didn't work on progress, i will send the patch based-on this patch.
>>
>> Best Regards,
>> Jaehoon Chung
>>
>> On 05/14/2014 06:53 PM, Ulf Hansson wrote:
>>> On 7 May 2014 12:06, Ludovic Desroches <ludovic.desroches@atmel.com> wrote:
>>>> Some hosts manage several slots. In these case information such as the bus
>>>> width, chip detect and others are into the slot node. So we have to parse
>>>> child nodes. If not NULL, slot node will be used instead of the device
>>>> node.
>>>>
>>>> Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
>>>> ---
>>>>
>>>> Hi,
>>>>
>>>> Since this patch is only a RFC, I have not yet updated drivers using this
>>>> function.
>>>>
>>>> I would like to use mmc_of_parse to reduce code duplication. My issue is that
>>>> atmel mci is a bit different from others mci host since it can provide
>>>> several slots, so it allocates several mmc hosts. By the way, it is not the
>>>> only one.
>>>>
>>>> When calling mmc_alloc_host, host->parent is set to &pdev->dev. mmc_of_parse
>>>> uses host->parent->of_node but in my case settings are in the slot nodes so in
>>>> the child nodes. That's why I would like to have a way to tell which node I
>>>> want to use.
>>>
>>> Seems reasonable, thanks for working on this!
>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>> Ludovic
>>>>
>>>>
>>>>
>>>>  drivers/mmc/core/host.c |    9 +++++++--
>>>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
>>>> index fdea825..ed6cea5 100644
>>>> --- a/drivers/mmc/core/host.c
>>>> +++ b/drivers/mmc/core/host.c
>>>> @@ -300,13 +300,15 @@ static inline void mmc_host_clk_sysfs_init(struct mmc_host *host)
>>>>  /**
>>>>   *     mmc_of_parse() - parse host's device-tree node
>>>>   *     @host: host whose node should be parsed.
>>>> + *     @slot: some devices provide several slots so the node to parse
>>>> + *     is not the host one.
>>>>   *
>>>>   * To keep the rest of the MMC subsystem unaware of whether DT has been
>>>>   * used to to instantiate and configure this host instance or not, we
>>>>   * parse the properties and set respective generic mmc-host flags and
>>>>   * parameters.
>>>>   */
>>>> -int mmc_of_parse(struct mmc_host *host)
>>>> +int mmc_of_parse(struct mmc_host *host, struct device_node *slot)
>>>>  {
>>>>         struct device_node *np;
>>>>         u32 bus_width;
>>>> @@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
>>>>         if (!host->parent || !host->parent->of_node)
>>>>                 return 0;
>>>>
>>>> -       np = host->parent->of_node;
>>>> +       if (slot)
>>>> +               np = slot;
>>>> +       else
>>>> +               np = host->parent->of_node;
>>>>
>>>>         /* "bus-width" is translated to MMC_CAP_*_BIT_DATA flags */
>>>>         if (of_property_read_u32(np, "bus-width", &bus_width) < 0) {
>>>> --
>>>> 1.7.9.5
>>>>
>>>
>>> How about adding a new API, __mmc_of_parse((struct mmc_host *host,
>>> struct device_node *slot)
>>> Then let the old API mmc_of_parse() remain as is, but let it call the
>>> new API with slot == NULL.
>>>
>>> Atmel can then use the new API, but the other drivers can remain as is.
>>>
>>> Kind regards
>>> Ulf Hansson
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2014-05-26  7:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-07 10:06 [PATCH RFC] mmc: add slot argument to mmc_of_parse Ludovic Desroches
2014-05-14  9:53 ` Ulf Hansson
2014-05-23  4:38   ` Jaehoon Chung
2014-05-26  7:03     ` Ludovic Desroches
2014-05-26  7:15       ` Jaehoon Chung [this message]
2014-05-26  7:49       ` Ludovic Desroches

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=5382EA1E.8060202@samsung.com \
    --to=jh80.chung@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.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).