All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	linux-leds@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	j.anaszewski@samsung.com
Cc: stewart@linux.vnet.ibm.com, arnd@arndb.de,
	j.anaszewski81@gmail.com, cooloney@gmail.com, rpurdie@rpsys.net,
	khandual@linux.vnet.ibm.com
Subject: Re: [PATCH v7 3/3] leds/powernv: Add driver for PowerNV platform
Date: Thu, 23 Jul 2015 13:38:01 +0530	[thread overview]
Message-ID: <55B0A0E1.1090803@linux.vnet.ibm.com> (raw)
In-Reply-To: <55B09DFB.2080108@gmail.com>

On 07/23/2015 01:25 PM, Jacek Anaszewski wrote:
> Hi Vasant,
> 

Jacek,

.../...

>> +/* PowerNV LED data */
>> +struct powernv_led_data {
>> +    struct led_classdev    cdev;
>> +    char            *loc_code;    /* LED location code */
>> +    int            led_type;    /* OPAL_SLOT_LED_TYPE_* */
>> +    enum led_brightness    value;        /* Brightness value */
> 
> You don't need 'value' as brightness value is already stored in
> cdev.brightness.
> 

Agree. I'll remove.

>> +/*
>> + * LED classdev 'brightness_get' function. This schedules work
>> + * to update LED state.
>> + */
>> +static void powernv_brightness_set(struct led_classdev *led_cdev,
>> +                   enum led_brightness value)
>> +{
>> +    struct powernv_led_data *powernv_led =
>> +        container_of(led_cdev, struct powernv_led_data, cdev);
>> +
>> +    /* Do not modify LED in unload path */
>> +    if (led_disabled)
>> +        return;
>> +
>> +    /* Prepare the request */
>> +    powernv_led->value = value;
>> +
>> +     return powernv_led_set(powernv_led);
> 
> Isn't mutex_lock/unlock missing here?

Yes. I realized this after sending out the patch. I will fix this.
.../...

>> +
>> +    max_led_type = devm_kzalloc(dev, sizeof(*max_led_type), GFP_KERNEL);
>> +    if (!max_led_type)
>> +        return -ENOMEM;
>> +
>> +    mutex_init(lock);
>> +    *max_led_type = cpu_to_be64(OPAL_SLOT_LED_TYPE_MAX);
>> +
>> +    platform_set_drvdata(pdev, lock);
> 
> Setting only lock as drvdata looks odd to me and I haven't noticed
> anyone doing that.
> I'd prefer to put lock, led_disabled and max_led_type in a common
> struct and set it as drvdata. I know that I accepted this design, but
> I didn't take into account these details.

Yeah. Even I looked into existing code and I don't see anyone using like this.
Since it's void * and we just need lock, I added like this.

If I break this into two structure, then I've to use platform_get_drvdata() call
in multiple functions like powernv_brightness_set() to get max_let_type etc. Is
that fine?

-Vasant

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

WARNING: multiple messages have this Message-ID (diff)
From: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	linux-leds@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	j.anaszewski@samsung.com
Cc: stewart@linux.vnet.ibm.com, arnd@arndb.de,
	j.anaszewski81@gmail.com, cooloney@gmail.com, rpurdie@rpsys.net,
	khandual@linux.vnet.ibm.com, mpe@ellerman.id.au,
	benh@kernel.crashing.org
Subject: Re: [PATCH v7 3/3] leds/powernv: Add driver for PowerNV platform
Date: Thu, 23 Jul 2015 13:38:01 +0530	[thread overview]
Message-ID: <55B0A0E1.1090803@linux.vnet.ibm.com> (raw)
In-Reply-To: <55B09DFB.2080108@gmail.com>

On 07/23/2015 01:25 PM, Jacek Anaszewski wrote:
> Hi Vasant,
> 

Jacek,

.../...

>> +/* PowerNV LED data */
>> +struct powernv_led_data {
>> +    struct led_classdev    cdev;
>> +    char            *loc_code;    /* LED location code */
>> +    int            led_type;    /* OPAL_SLOT_LED_TYPE_* */
>> +    enum led_brightness    value;        /* Brightness value */
> 
> You don't need 'value' as brightness value is already stored in
> cdev.brightness.
> 

Agree. I'll remove.

>> +/*
>> + * LED classdev 'brightness_get' function. This schedules work
>> + * to update LED state.
>> + */
>> +static void powernv_brightness_set(struct led_classdev *led_cdev,
>> +                   enum led_brightness value)
>> +{
>> +    struct powernv_led_data *powernv_led =
>> +        container_of(led_cdev, struct powernv_led_data, cdev);
>> +
>> +    /* Do not modify LED in unload path */
>> +    if (led_disabled)
>> +        return;
>> +
>> +    /* Prepare the request */
>> +    powernv_led->value = value;
>> +
>> +     return powernv_led_set(powernv_led);
> 
> Isn't mutex_lock/unlock missing here?

Yes. I realized this after sending out the patch. I will fix this.
.../...

>> +
>> +    max_led_type = devm_kzalloc(dev, sizeof(*max_led_type), GFP_KERNEL);
>> +    if (!max_led_type)
>> +        return -ENOMEM;
>> +
>> +    mutex_init(lock);
>> +    *max_led_type = cpu_to_be64(OPAL_SLOT_LED_TYPE_MAX);
>> +
>> +    platform_set_drvdata(pdev, lock);
> 
> Setting only lock as drvdata looks odd to me and I haven't noticed
> anyone doing that.
> I'd prefer to put lock, led_disabled and max_led_type in a common
> struct and set it as drvdata. I know that I accepted this design, but
> I didn't take into account these details.

Yeah. Even I looked into existing code and I don't see anyone using like this.
Since it's void * and we just need lock, I added like this.

If I break this into two structure, then I've to use platform_get_drvdata() call
in multiple functions like powernv_brightness_set() to get max_let_type etc. Is
that fine?

-Vasant

  reply	other threads:[~2015-07-23  8:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-22 14:52 [PATCH v7 0/3] LED driver for PowerNV platform Vasant Hegde
2015-07-22 14:52 ` [PATCH v7 1/3] powerpc/powernv: Add OPAL interfaces for accessing and modifying system LED states Vasant Hegde
2015-07-22 14:52 ` [PATCH v7 2/3] powerpc/powernv: Create LED platform device Vasant Hegde
2015-07-22 14:52 ` [PATCH v7 3/3] leds/powernv: Add driver for PowerNV platform Vasant Hegde
2015-07-23  7:55   ` Jacek Anaszewski
2015-07-23  8:08     ` Vasant Hegde [this message]
2015-07-23  8:08       ` Vasant Hegde
2015-07-23 12:26       ` Jacek Anaszewski

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=55B0A0E1.1090803@linux.vnet.ibm.com \
    --to=hegdevasant@linux.vnet.ibm.com \
    --cc=arnd@arndb.de \
    --cc=cooloney@gmail.com \
    --cc=j.anaszewski81@gmail.com \
    --cc=j.anaszewski@samsung.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-leds@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=rpurdie@rpsys.net \
    --cc=stewart@linux.vnet.ibm.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.