All of lore.kernel.org
 help / color / mirror / Atom feed
From: ygardi@codeaurora.org
To: Akinobu Mita <akinobu.mita@gmail.com>,
	merez@qti.qualcomm.com, dovl@qti.qualcomm.com
Cc: Yaniv Gardi <ygardi@codeaurora.org>,
	Jej B <james.bottomley@hansenpartnership.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	linux-arm-msm@vger.kernel.org, Santosh Y <santoshsy@gmail.com>,
	linux-scsi-owner@vger.kernel.org,
	Subhash Jadavani <subhashj@codeaurora.org>,
	Paul Bolle <pebolle@tiscali.nl>,
	Gilad Broner <gbroner@codeaurora.org>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Vinayak Holikatti <vinholikatti@gmail.com>,
	"James E.J. Bottomley" <jbottomley@odin.com>,
	Dolev Raviv <draviv@codeaurora.org>,
	Christoph Hellwig <hch@lst.de>,
	Sujit Reddy Thumma <sthumma@codeaurora.org>,
	Raviv Shvili <rshvili@codeaurora.org>Sahitya Tummala <s>
Subject: Re: [PATCH v2 4/4] scsi: ufs: probe and init of variant driver from the platform device
Date: Thu, 4 Jun 2015 20:53:16 -0000	[thread overview]
Message-ID: <763dbc7b708b5d5b18ce0b5adcc41016.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <CAC5umyis6HU06KU-aSGoy6mCt-u+5Pz16nDk1qHrcsTnFo_2hA@mail.gmail.com>

> Hi Yaniv,
>
> 2015-06-03 18:37 GMT+09:00 Yaniv Gardi <ygardi@codeaurora.org>:
>> @@ -321,7 +313,22 @@ static int ufshcd_pltfrm_probe(struct
>> platform_device *pdev)
>>                 goto out;
>>         }
>>
>> -       hba->vops = get_variant_ops(&pdev->dev);
>> +       err = of_platform_populate(node, NULL, NULL, &pdev->dev);
>> +       if (err)
>> +               dev_err(&pdev->dev,
>> +                       "%s: of_platform_populate() failed\n",
>> __func__);
>> +
>> +       ufs_variant_node = of_get_next_available_child(node, NULL);
>> +
>> +       if (!ufs_variant_node) {
>> +               dev_dbg(&pdev->dev, "failed to find ufs_variant_node
>> child\n");
>> +       } else {
>> +               ufs_variant_pdev =
>> of_find_device_by_node(ufs_variant_node);
>> +
>> +               if (ufs_variant_pdev)
>> +                       hba->vops = (struct ufs_hba_variant_ops *)
>> +                               dev_get_drvdata(&ufs_variant_pdev->dev);
>> +       }
>
> I have no strong objection to 'ufs_variant' sub-node.  But why can't we
> simply add an of_device_id to ufs_of_match, like below:
>
> static const struct of_device_id ufs_of_match[] = {
>         { .compatible = "jedec,ufs-1.1"},
> #if IS_ENABLED(SCSI_UFS_QCOM)
>         { .compatible = "qcom,ufs", .data = &ufs_hba_qcom_vops },
> #neidf
>         {},
> };
>
> and get hba->vops by get_variant_ops()?
>

Hi Mita,
thanks for your comments.

The whole idea, of having a sub-node which includes all variant specific
attributes is to separate the UFS Platform device component, from the need
to know "qcom" or any other future variant.
I believe it keeps the code more modular, and clean - meaning - no
#ifdef's and no need to include all variant attributes inside the driver
DT node.
in that case, we simply have a DT node that is compatible to the Jdec
standard, and sub-node to include variant info.

I hope you agree with this new design, since it provides a good answer
to every future variant that will be added, without the need to change the
platform file.

thanks for your time, Mita
please share your thoughts.

> There is something similar in
> drivers/net/ethernet/freescale/fsl_pq_mdio.c
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



WARNING: multiple messages have this Message-ID (diff)
From: ygardi@codeaurora.org
To: "Akinobu Mita" <akinobu.mita@gmail.com>,
	merez@qti.qualcomm.com, dovl@qti.qualcomm.com
Cc: "Yaniv Gardi" <ygardi@codeaurora.org>,
	"Jej B" <james.bottomley@hansenpartnership.com>,
	"LKML" <linux-kernel@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	linux-arm-msm@vger.kernel.org, "Santosh Y" <santoshsy@gmail.com>,
	linux-scsi-owner@vger.kernel.org,
	"Subhash Jadavani" <subhashj@codeaurora.org>,
	"Paul Bolle" <pebolle@tiscali.nl>,
	"Gilad Broner" <gbroner@codeaurora.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Pawel Moll" <pawel.moll@arm.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
	"Kumar Gala" <galak@codeaurora.org>,
	"Vinayak Holikatti" <vinholikatti@gmail.com>,
	"James E.J. Bottomley" <jbottomley@odin.com>,
	"Dolev Raviv" <draviv@codeaurora.org>,
	"Christoph Hellwig" <hch@lst.de>,
	"Sujit Reddy Thumma" <sthumma@codeaurora.org>,
	"Raviv Shvili" <rshvili@codeaurora.org>,
	"Sahitya Tummala" <stummala@codeaurora.org>,
	"open list:OPEN FIRMWARE AND..." <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 4/4] scsi: ufs: probe and init of variant driver from the platform device
Date: Thu, 4 Jun 2015 20:53:16 -0000	[thread overview]
Message-ID: <763dbc7b708b5d5b18ce0b5adcc41016.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <CAC5umyis6HU06KU-aSGoy6mCt-u+5Pz16nDk1qHrcsTnFo_2hA@mail.gmail.com>

> Hi Yaniv,
>
> 2015-06-03 18:37 GMT+09:00 Yaniv Gardi <ygardi@codeaurora.org>:
>> @@ -321,7 +313,22 @@ static int ufshcd_pltfrm_probe(struct
>> platform_device *pdev)
>>                 goto out;
>>         }
>>
>> -       hba->vops = get_variant_ops(&pdev->dev);
>> +       err = of_platform_populate(node, NULL, NULL, &pdev->dev);
>> +       if (err)
>> +               dev_err(&pdev->dev,
>> +                       "%s: of_platform_populate() failed\n",
>> __func__);
>> +
>> +       ufs_variant_node = of_get_next_available_child(node, NULL);
>> +
>> +       if (!ufs_variant_node) {
>> +               dev_dbg(&pdev->dev, "failed to find ufs_variant_node
>> child\n");
>> +       } else {
>> +               ufs_variant_pdev =
>> of_find_device_by_node(ufs_variant_node);
>> +
>> +               if (ufs_variant_pdev)
>> +                       hba->vops = (struct ufs_hba_variant_ops *)
>> +                               dev_get_drvdata(&ufs_variant_pdev->dev);
>> +       }
>
> I have no strong objection to 'ufs_variant' sub-node.  But why can't we
> simply add an of_device_id to ufs_of_match, like below:
>
> static const struct of_device_id ufs_of_match[] = {
>         { .compatible = "jedec,ufs-1.1"},
> #if IS_ENABLED(SCSI_UFS_QCOM)
>         { .compatible = "qcom,ufs", .data = &ufs_hba_qcom_vops },
> #neidf
>         {},
> };
>
> and get hba->vops by get_variant_ops()?
>

Hi Mita,
thanks for your comments.

The whole idea, of having a sub-node which includes all variant specific
attributes is to separate the UFS Platform device component, from the need
to know "qcom" or any other future variant.
I believe it keeps the code more modular, and clean - meaning - no
#ifdef's and no need to include all variant attributes inside the driver
DT node.
in that case, we simply have a DT node that is compatible to the Jdec
standard, and sub-node to include variant info.

I hope you agree with this new design, since it provides a good answer
to every future variant that will be added, without the need to change the
platform file.

thanks for your time, Mita
please share your thoughts.

> There is something similar in
> drivers/net/ethernet/freescale/fsl_pq_mdio.c
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



  reply	other threads:[~2015-06-04 20:53 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-03  9:37 [PATCH v2 0/4] fixing building errors and warnings when components Yaniv Gardi
2015-06-03  9:37 ` [PATCH v2 1/4] phy: qcom-ufs: fix build error when the component is built as a module Yaniv Gardi
2015-06-03  9:37 ` [PATCH v2 2/4] scsi: ufs-qcom: fix compilation warning if compiled " Yaniv Gardi
2015-06-03  9:37 ` [PATCH v2 3/4] scsi: ufs-qcom: update configuration option of SCSI_UFS_QCOM component Yaniv Gardi
2015-06-03  9:37 ` [PATCH v2 4/4] scsi: ufs: probe and init of variant driver from the platform device Yaniv Gardi
2015-06-03  9:37   ` Yaniv Gardi
2015-06-04 14:07   ` Paul Bolle
2015-06-04 14:42     ` Paul Bolle
2015-06-04 20:42     ` ygardi
2015-06-07 15:22     ` ygardi-sgV2jX0FEOL9JmXXK+q4OQ
2015-06-07 15:22       ` ygardi
2015-06-04 14:32   ` Akinobu Mita
2015-06-04 14:32     ` Akinobu Mita
2015-06-04 20:53     ` ygardi [this message]
2015-06-04 20:53       ` ygardi
2015-06-05 16:47       ` Akinobu Mita
2015-06-05 16:47         ` Akinobu Mita
2015-06-07 15:32         ` ygardi
2015-06-07 15:32           ` ygardi
2015-06-08 14:47           ` Akinobu Mita
2015-06-08 14:47             ` Akinobu Mita
2015-06-08 15:02           ` Rob Herring
2015-06-08 15:02             ` Rob Herring
2015-06-09  5:53             ` Dov Levenglick
2015-06-09  5:53               ` Dov Levenglick
     [not found]               ` <bfade46f9d953e10240acb835105b81d.squirrel-mMfbam+mt9083fI46fginR2eb7JE58TQ@public.gmane.org>
2015-06-09 12:53                 ` Rob Herring
2015-06-09 12:53                   ` Rob Herring
2015-06-17  7:42                   ` Dov Levenglick
2015-06-17  7:42                     ` Dov Levenglick
2015-06-17 12:46                     ` Rob Herring
2015-06-17 12:46                       ` Rob Herring
2015-06-17 13:17                       ` Dov Levenglick
2015-06-17 13:17                         ` Dov Levenglick
2015-06-17 13:37                         ` Rob Herring
2015-06-17 13:37                           ` Rob Herring
2015-06-17 14:21                           ` Dov Levenglick
2015-06-17 14:21                             ` Dov Levenglick
2015-06-17 14:31                             ` James Bottomley
2015-06-17 14:31                               ` James Bottomley
2015-06-17 14:38                               ` Dov Levenglick
2015-06-17 14:38                                 ` Dov Levenglick
     [not found]     ` <CAC5umyis6HU06KU-aSGoy6mCt-u+5Pz16nDk1qHrcsTnFo_2hA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-08 14:51       ` Rob Herring
2015-06-08 14:51         ` Rob Herring

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=763dbc7b708b5d5b18ce0b5adcc41016.squirrel@www.codeaurora.org \
    --to=ygardi@codeaurora.org \
    --cc=akinobu.mita@gmail.com \
    --cc=dovl@qti.qualcomm.com \
    --cc=draviv@codeaurora.org \
    --cc=galak@codeaurora.org \
    --cc=gbroner@codeaurora.org \
    --cc=hch@lst.de \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=jbottomley@odin.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi-owner@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=merez@qti.qualcomm.com \
    --cc=pawel.moll@arm.com \
    --cc=pebolle@tiscali.nl \
    --cc=robh+dt@kernel.org \
    --cc=rshvili@codeaurora.org \
    --cc=santoshsy@gmail.com \
    --cc=sthumma@codeaurora.org \
    --cc=subhashj@codeaurora.org \
    --cc=vinholikatti@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.