linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] lm3697: Rename struct into more appropiate name
@ 2020-10-05 20:17 ultracoolguy
  2020-10-06 23:26 ` Marek Behun
  0 siblings, 1 reply; 6+ messages in thread
From: ultracoolguy @ 2020-10-05 20:17 UTC (permalink / raw)
  To: Pavel, Dmurphy; +Cc: Marek Behun, Linux Leds, Linux Kernel

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

Subject says it all. This rename was briefly discussed in this other patch: https://www.spinics.net/lists/linux-leds/msg16865.html (I don't know another way to link to emails, so I'll just use this archive).

Feel free to suggest another name for the commit; that was just the better name I could come up with :/ .





[-- Attachment #2: 0001-lm3697-Rename-struct-into-more-appropriate-name.patch --]
[-- Type: text/x-patch, Size: 6930 bytes --]

From 5e0b0aa5f5c1e9a6837151fdeb08b56757c8bc31 Mon Sep 17 00:00:00 2001
From: Gabriel David <ultracoolguy@tutanota.com>
Date: Mon, 5 Oct 2020 15:16:34 -0400
Subject: [PATCH] lm3697: Rename struct into more appropriate name

The mentioned struct is lm3697_led, which is now lm3697_bank.
The pointers referring to it were also renamed.

Signed-off-by: Gabriel David <ultracoolguy@tutanota.com>
---
 drivers/leds/leds-lm3697.c | 78 +++++++++++++++++++-------------------
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/drivers/leds/leds-lm3697.c b/drivers/leds/leds-lm3697.c
index 7d216cdb9..287165097 100644
--- a/drivers/leds/leds-lm3697.c
+++ b/drivers/leds/leds-lm3697.c
@@ -39,7 +39,7 @@
 #define LM3697_MAX_CONTROL_BANKS 2
 
 /**
- * struct lm3697_led -
+ * struct lm3697_bank -
  * @hvled_strings: Array of LED strings associated with a control bank
  * @label: LED label
  * @led_dev: LED class device
@@ -48,7 +48,7 @@
  * @control_bank: Control bank the LED is associated to. 0 is control bank A
  *		   1 is control bank B
  */
-struct lm3697_led {
+struct lm3697_bank {
 	u32 hvled_strings[LM3697_MAX_LED_STRINGS];
 	char label[LED_MAX_NAME_SIZE];
 	struct led_classdev led_dev;
@@ -80,7 +80,7 @@ struct lm3697 {
 	int bank_cfg;
 	int num_banks;
 
-	struct lm3697_led leds[];
+	struct lm3697_bank banks[];
 };
 
 static const struct reg_default lm3697_reg_defs[] = {
@@ -113,32 +113,32 @@ static const struct regmap_config lm3697_regmap_config = {
 static int lm3697_brightness_set(struct led_classdev *led_cdev,
 				enum led_brightness brt_val)
 {
-	struct lm3697_led *led = container_of(led_cdev, struct lm3697_led,
+	struct lm3697_bank *bank = container_of(led_cdev, struct lm3697_bank,
 					      led_dev);
-	int ctrl_en_val = (1 << led->control_bank);
-	struct device *dev = led->priv->dev;
+	int ctrl_en_val = (1 << bank->control_bank);
+	struct device *dev = bank->priv->dev;
 	int ret;
 
-	mutex_lock(&led->priv->lock);
+	mutex_lock(&bank->priv->lock);
 
 	if (brt_val == LED_OFF) {
-		ret = regmap_update_bits(led->priv->regmap, LM3697_CTRL_ENABLE,
+		ret = regmap_update_bits(bank->priv->regmap, LM3697_CTRL_ENABLE,
 					 ctrl_en_val, ~ctrl_en_val);
 		if (ret) {
 			dev_err(dev, "Cannot write ctrl register\n");
 			goto brightness_out;
 		}
 
-		led->enabled = LED_OFF;
+		bank->enabled = LED_OFF;
 	} else {
-		ret = ti_lmu_common_set_brightness(&led->lmu_data, brt_val);
+		ret = ti_lmu_common_set_brightness(&bank->lmu_data, brt_val);
 		if (ret) {
 			dev_err(dev, "Cannot write brightness\n");
 			goto brightness_out;
 		}
 
-		if (!led->enabled) {
-			ret = regmap_update_bits(led->priv->regmap,
+		if (!bank->enabled) {
+			ret = regmap_update_bits(bank->priv->regmap,
 						 LM3697_CTRL_ENABLE,
 						 ctrl_en_val, ctrl_en_val);
 			if (ret) {
@@ -146,19 +146,19 @@ static int lm3697_brightness_set(struct led_classdev *led_cdev,
 				goto brightness_out;
 			}
 
-			led->enabled = brt_val;
+			bank->enabled = brt_val;
 		}
 	}
 
 brightness_out:
-	mutex_unlock(&led->priv->lock);
+	mutex_unlock(&bank->priv->lock);
 	return ret;
 }
 
 static int lm3697_init(struct lm3697 *priv)
 {
 	struct device *dev = priv->dev;
-	struct lm3697_led *led;
+	struct lm3697_bank *bank;
 	int i, ret;
 
 	if (priv->enable_gpio) {
@@ -182,8 +182,8 @@ static int lm3697_init(struct lm3697 *priv)
 		dev_err(dev, "Cannot write OUTPUT config\n");
 
 	for (i = 0; i < priv->num_banks; i++) {
-		led = &priv->leds[i];
-		ret = ti_lmu_common_set_ramp(&led->lmu_data);
+		bank = &priv->banks[i];
+		ret = ti_lmu_common_set_ramp(&bank->lmu_data);
 		if (ret)
 			dev_err(dev, "Setting the ramp rate failed\n");
 	}
@@ -195,7 +195,7 @@ static int lm3697_probe_dt(struct lm3697 *priv)
 {
 	struct fwnode_handle *child = NULL;
 	struct device *dev = priv->dev;
-	struct lm3697_led *led;
+	struct lm3697_bank *bank;
 	int ret = -EINVAL;
 	int control_bank;
 	size_t i = 0;
@@ -230,42 +230,42 @@ static int lm3697_probe_dt(struct lm3697 *priv)
 			goto child_out;
 		}
 
-		led = &priv->leds[i];
+		bank = &priv->banks[i];
 
-		ret = ti_lmu_common_get_brt_res(dev, child, &led->lmu_data);
+		ret = ti_lmu_common_get_brt_res(dev, child, &bank->lmu_data);
 		if (ret)
 			dev_warn(dev,
 				 "brightness resolution property missing\n");
 
-		led->control_bank = control_bank;
-		led->lmu_data.regmap = priv->regmap;
-		led->lmu_data.runtime_ramp_reg = LM3697_CTRL_A_RAMP +
+		bank->control_bank = control_bank;
+		bank->lmu_data.regmap = priv->regmap;
+		bank->lmu_data.runtime_ramp_reg = LM3697_CTRL_A_RAMP +
 						 control_bank;
-		led->lmu_data.msb_brightness_reg = LM3697_CTRL_A_BRT_MSB +
-						   led->control_bank * 2;
-		led->lmu_data.lsb_brightness_reg = LM3697_CTRL_A_BRT_LSB +
-						   led->control_bank * 2;
+		bank->lmu_data.msb_brightness_reg = LM3697_CTRL_A_BRT_MSB +
+						   bank->control_bank * 2;
+		bank->lmu_data.lsb_brightness_reg = LM3697_CTRL_A_BRT_LSB +
+						   bank->control_bank * 2;
 
-		led->num_leds = fwnode_property_count_u32(child, "led-sources");
-		if (led->num_leds > LM3697_MAX_LED_STRINGS) {
+		bank->num_leds = fwnode_property_count_u32(child, "led-sources");
+		if (bank->num_leds > LM3697_MAX_LED_STRINGS) {
 			dev_err(dev, "Too many LED strings defined\n");
 			continue;
 		}
 
 		ret = fwnode_property_read_u32_array(child, "led-sources",
-						    led->hvled_strings,
-						    led->num_leds);
+						    bank->hvled_strings,
+						    bank->num_leds);
 		if (ret) {
 			dev_err(dev, "led-sources property missing\n");
 			fwnode_handle_put(child);
 			goto child_out;
 		}
 
-		for (j = 0; j < led->num_leds; j++)
+		for (j = 0; j < bank->num_leds; j++)
 			priv->bank_cfg |=
-				(led->control_bank << led->hvled_strings[j]);
+				(bank->control_bank << bank->hvled_strings[j]);
 
-		ret = ti_lmu_common_get_ramp_params(dev, child, &led->lmu_data);
+		ret = ti_lmu_common_get_ramp_params(dev, child, &bank->lmu_data);
 		if (ret)
 			dev_warn(dev, "runtime-ramp properties missing\n");
 
@@ -274,11 +274,11 @@ static int lm3697_probe_dt(struct lm3697 *priv)
 		/* for backwards compatibility if `label` is not present */
 		init_data.default_label = ":";
 
-		led->priv = priv;
-		led->led_dev.max_brightness = led->lmu_data.max_brightness;
-		led->led_dev.brightness_set_blocking = lm3697_brightness_set;
+		bank->priv = priv;
+		bank->led_dev.max_brightness = bank->lmu_data.max_brightness;
+		bank->led_dev.brightness_set_blocking = lm3697_brightness_set;
 
-		ret = devm_led_classdev_register_ext(dev, &led->led_dev,
+		ret = devm_led_classdev_register_ext(dev, &bank->led_dev,
 						     &init_data);
 		if (ret) {
 			dev_err(dev, "led register err: %d\n", ret);
@@ -307,7 +307,7 @@ static int lm3697_probe(struct i2c_client *client,
 		return -ENODEV;
 	}
 
-	led = devm_kzalloc(dev, struct_size(led, leds, count), GFP_KERNEL);
+	led = devm_kzalloc(dev, struct_size(led, banks, count), GFP_KERNEL);
 	if (!led)
 		return -ENOMEM;
 
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] lm3697: Rename struct into more appropiate name
  2020-10-05 20:17 [PATCH] lm3697: Rename struct into more appropiate name ultracoolguy
@ 2020-10-06 23:26 ` Marek Behun
  2020-10-07 12:21   ` ultracoolguy
  0 siblings, 1 reply; 6+ messages in thread
From: Marek Behun @ 2020-10-06 23:26 UTC (permalink / raw)
  To: ultracoolguy; +Cc: Pavel, Dmurphy, Linux Leds, Linux Kernel

On Mon, 5 Oct 2020 22:17:14 +0200 (CEST)
ultracoolguy@tutanota.com wrote:

> Subject says it all. This rename was briefly discussed in this other patch: https://www.spinics.net/lists/linux-leds/msg16865.html (I don't know another way to link to emails, so I'll just use this archive).
> 
> Feel free to suggest another name for the commit; that was just the better name I could come up with :/ .
> 
> 
> 
> 

Gabriel,

the subject of the patch should be
  leds: lm3697: Rename struct into more appropiate name
("leds: " is prefixed). Look at history
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/leds?h=v5.9-rc8

The commit message should mention why you are renaming the type
(something like "to be semantically more correct, since that structure
represents LED control bank as described by the datasheet").

Also it seems that you are using git format-patch for generating patch
files, but you are sending these patches as regular e-mail attachements.
You should instead use git send-email, as is normally required
for kernel patches (and they would also appear in patchwork
(https://patches.linaro.org/project/linux-leds/list/). Please look at
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
and https://git-send-email.io/.

Marek

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] lm3697: Rename struct into more appropiate name
  2020-10-06 23:26 ` Marek Behun
@ 2020-10-07 12:21   ` ultracoolguy
  2020-10-07 14:56     ` Dan Murphy
  0 siblings, 1 reply; 6+ messages in thread
From: ultracoolguy @ 2020-10-07 12:21 UTC (permalink / raw)
  To: Marek Behun; +Cc: Pavel, Dmurphy, Linux Leds, Linux Kernel

The reason I didn't use git send-mail earlier is because Tutanota doesn't supports SMTP and Protonmail requires a paid account for using SMTP/IMAP. However, I made an account creation request for Disroot(which does support SMTP for free), so when/if the account gets created I'll send future patches through there.
Oct 6, 2020, 23:26 by kabel@blackhole.sk:

> On Mon, 5 Oct 2020 22:17:14 +0200 (CEST)
> ultracoolguy@tutanota.com wrote:
>
>> Subject says it all. This rename was briefly discussed in this other patch: https://www.spinics.net/lists/linux-leds/msg16865.html (I don't know another way to link to emails, so I'll just use this archive).
>>
>> Feel free to suggest another name for the commit; that was just the better name I could come up with :/ .
>>
>>
>>
>
> Gabriel,
>
> the subject of the patch should be
>  leds: lm3697: Rename struct into more appropiate name
> ("leds: " is prefixed). Look at history
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/leds?h=v5.9-rc8
>
> The commit message should mention why you are renaming the type
> (something like "to be semantically more correct, since that structure
> represents LED control bank as described by the datasheet").
>
> Also it seems that you are using git format-patch for generating patch
> files, but you are sending these patches as regular e-mail attachements.
> You should instead use git send-email, as is normally required
> for kernel patches (and they would also appear in patchwork
> (https://patches.linaro.org/project/linux-leds/list/). Please look at
> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
> and https://git-send-email.io/.
>
> Marek
>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] lm3697: Rename struct into more appropiate name
  2020-10-07 12:21   ` ultracoolguy
@ 2020-10-07 14:56     ` Dan Murphy
  2020-10-08 12:10       ` ultracoolguy
  0 siblings, 1 reply; 6+ messages in thread
From: Dan Murphy @ 2020-10-07 14:56 UTC (permalink / raw)
  To: ultracoolguy, Marek Behun; +Cc: Pavel, Linux Leds, Linux Kernel

Gabriel

On 10/7/20 7:21 AM, ultracoolguy@tutanota.com wrote:
> The reason I didn't use git send-mail earlier is because Tutanota doesn't supports SMTP and Protonmail requires a paid account for using SMTP/IMAP. However, I made an account creation request for Disroot(which does support SMTP for free), so when/if the account gets created I'll send future patches through there.
> Oct 6, 2020, 23:26 by kabel@blackhole.sk:
>
>
Also please note top posting on emails is not preferred. As you will 
find in the LED domain bottom posts and trimming emails to what is being 
commented on is preferred.

As demonstrated.

Dan


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] lm3697: Rename struct into more appropiate name
  2020-10-07 14:56     ` Dan Murphy
@ 2020-10-08 12:10       ` ultracoolguy
  2020-10-08 15:27         ` ultracoolguy
  0 siblings, 1 reply; 6+ messages in thread
From: ultracoolguy @ 2020-10-08 12:10 UTC (permalink / raw)
  To: Dan Murphy, Pavel; +Cc: Marek Behun, Linux Leds, Linux Kernel

Gotcha.

From now on I'm gonna respond with this new email: ultracoolguy@disroot.org .

Oct 7, 2020, 14:56 by dmurphy@ti.com:

> Gabriel
>
> On 10/7/20 7:21 AM, ultracoolguy@tutanota.com wrote:
>
>> The reason I didn't use git send-mail earlier is because Tutanota doesn't supports SMTP and Protonmail requires a paid account for using SMTP/IMAP. However, I made an account creation request for Disroot(which does support SMTP for free), so when/if the account gets created I'll send future patches through there.
>> Oct 6, 2020, 23:26 by kabel@blackhole.sk:
>>
> Also please note top posting on emails is not preferred. As you will find in the LED domain bottom posts and trimming emails to what is being commented on is preferred.
>
> As demonstrated.
>
> Dan
>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] lm3697: Rename struct into more appropiate name
  2020-10-08 12:10       ` ultracoolguy
@ 2020-10-08 15:27         ` ultracoolguy
  0 siblings, 0 replies; 6+ messages in thread
From: ultracoolguy @ 2020-10-08 15:27 UTC (permalink / raw)
  To: Dan Murphy, Pavel; +Cc: Marek Behun, Linux Leds, Linux Kernel


Umm:

<linux-kernel@vger.kernel.org>: host vger.kernel.org[23.128.96.18] said: 553
    5.7.1 Hello [178.21.23.139], for your MAIL FROM address
    <ultracoolguy@disroot.org> policy analysis reported: Your address is not
    liked source for email (in reply to MAIL FROM command)Is disroot.org banned?

Oct 8, 2020, 12:10 by ultracoolguy@tutanota.com:

> Gotcha.
>
> From now on I'm gonna respond with this new email: > ultracoolguy@disroot.org>  .
>
> Oct 7, 2020, 14:56 by dmurphy@ti.com:
>
>> Gabriel
>>
>> On 10/7/20 7:21 AM, ultracoolguy@tutanota.com wrote:
>>
>>> The reason I didn't use git send-mail earlier is because Tutanota doesn't supports SMTP and Protonmail requires a paid account for using SMTP/IMAP. However, I made an account creation request for Disroot(which does support SMTP for free), so when/if the account gets created I'll send future patches through there.
>>> Oct 6, 2020, 23:26 by kabel@blackhole.sk:
>>>
>> Also please note top posting on emails is not preferred. As you will find in the LED domain bottom posts and trimming emails to what is being commented on is preferred.
>>
>> As demonstrated.
>>
>> Dan
>>
>
>


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-10-08 15:27 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-05 20:17 [PATCH] lm3697: Rename struct into more appropiate name ultracoolguy
2020-10-06 23:26 ` Marek Behun
2020-10-07 12:21   ` ultracoolguy
2020-10-07 14:56     ` Dan Murphy
2020-10-08 12:10       ` ultracoolguy
2020-10-08 15:27         ` ultracoolguy

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).