All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chanwoo Choi <cw00.choi@samsung.com>
To: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Cc: myungjoo.ham@samsung.com, broonie@kernel.org,
	patches@opensource.wolfsonmicro.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] extcon: arizona: Get pdata from arizona structure not device
Date: Tue, 01 Oct 2013 08:14:39 +0900	[thread overview]
Message-ID: <524A05DF.7070008@samsung.com> (raw)
In-Reply-To: <524A0369.1080101@samsung.com>

On 10/01/2013 08:04 AM, Chanwoo Choi wrote:
> On 09/30/2013 06:52 PM, Charles Keepax wrote:
>> On Mon, Sep 30, 2013 at 08:37:30AM +0900, Chanwoo Choi wrote:
>>> No, extcon-arizona driver don't currently support DT to get platform data.
>>> I cannot find some dt function to parse data from dts file.
>>> You have to implement extcon-arizona driver by using DT binding style
>>> to get platform data. I think this patch is not necessary.
>>
>> Currently the Arizona MFD driver reads the device tree
>> information and populates the pdata structure, this happens in
>> drivers/mfd/arizona-core.c. Then the various drivers just use the
>> pdata as normal.
>>
>> Admittedly, at the moment we don't parse any data for the extcon
>> driver but without this patch we will attempt to use a NULL
>> pointer on device tree systems.
>>
>> I would also be happy to implement this as a NULL check on the
>> pdata when we use it if that is preferable? But since we have the
>> cached pdata seems we might as well use it.
>>
> 
> I find below pdata list for extcon-arizona driver.
> But, drivers/mfd/arizona-core.c don't parse dt data for below pdata list
> of extcon-arizona. Did you test this patch for extcon-arizona operation?
> 
> arizona->pdata.micd_pol_gpio
> arizona->pdata.micd_force_micbias	
> arizona->pdata.hpdet_id_gpio
> arizona->pdata.hpdet_acc_id
> arizona->pdata.hpdet_acc_id_line
> arizona->pdata.micd_detect_debounce
> arizona->pdata.jd_gpio5
> arizona->pdata.micd_timeout
> arizona->pdata.num_micd_configs
> arizona->pdata.micd_configs
> arizona->pdata.micd_bias_start_time
> arizona->pdata.micd_rate
> arizona->pdata.micd_dbtime
> arizona->pdata.num_micd_ranges
> ...
> 
> If you fix NULL pointer error about pdata,
> I think only that extcon-arizona modify it as following:
> 
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index e557130..3429906 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1088,6 +1088,10 @@ static int arizona_extcon_probe(struct platform_device *pdev)
>                 return -EPROBE_DEFER;
>  
>         pdata = dev_get_platdata(arizona->dev);
> +       if (!pdata) {
> +               dev_err(&pdev->dev, "Failed to get platform data\n");
> +               return -EINVAL;
> +       }
>  
>         info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
>         if (!info) {
> 

Additionally,I have a question.
As I mentioned, extcon-arizon driver don't get pdata from dt parsing.
I think extcon-arizona haven't operated without pdata.

Did you only build test for extcon-arizona?

I'd like you to implement parse function for extcon-arizona
to solve this issue(NULL pointer error).

Thanks
Chanwoo Choi





  reply	other threads:[~2013-09-30 23:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-28 14:34 [PATCH] extcon: arizona: Get pdata from arizona structure not device Charles Keepax
2013-09-29 23:37 ` Chanwoo Choi
2013-09-30  9:52   ` Charles Keepax
2013-09-30 23:04     ` Chanwoo Choi
2013-09-30 23:14       ` Chanwoo Choi [this message]
2013-09-30 23:27         ` Mark Brown
2013-09-30 23:25       ` Mark Brown
2013-10-01  8:22       ` Charles Keepax
2013-10-01  8:33         ` Chanwoo Choi

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=524A05DF.7070008@samsung.com \
    --to=cw00.choi@samsung.com \
    --cc=broonie@kernel.org \
    --cc=ckeepax@opensource.wolfsonmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=patches@opensource.wolfsonmicro.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.