Re: [PATCH v5 05/10] power: supply: rt5033_charger: Add RT5033 charger device driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Christophe, Hi all,

On 14.05.23 16:31, Christophe JAILLET wrote:
Le 14/05/2023 à 14:31, Jakob Hauser a écrit :

...

+static int rt5033_charger_probe(struct platform_device *pdev)
+{
+    struct rt5033_charger *charger;
+    struct power_supply_config psy_cfg = {};
+    int ret;
+
+    charger = devm_kzalloc(&pdev->dev, sizeof(*charger), GFP_KERNEL);
+    if (!charger)
+        return -ENOMEM;
+
+    platform_set_drvdata(pdev, charger);
+    charger->dev = &pdev->dev;
+    charger->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+
+    psy_cfg.of_node = pdev->dev.of_node;
+    psy_cfg.drv_data = charger;
+
+    charger->psy = devm_power_supply_register(&pdev->dev,
+                          &rt5033_charger_desc,
+                          &psy_cfg);
+    if (IS_ERR(charger->psy))
+        return dev_err_probe(&pdev->dev, PTR_ERR(charger->psy),
+                     "Failed to register power supply\n");
+
+    charger->chg = rt5033_charger_dt_init(charger);
+    if (IS_ERR_OR_NULL(charger->chg))

Hi,

Nit: charger->chg can't be NULL.

+        return -ENODEV;

Why bother returning specific error code in rt5033_charger_dt_init() if they are eaten here.

return PTR_ERR(charger->chg)?


Thanks for the heads-up.

...

Writing towards the list:

The way it is done in the current patchset is taken from the original patchset of March 2015 [2]. I kept the original as far as possible.

By now I'm not happy with the way of initializing "struct rt5033_charger_data". I realized this in the course of the review. As I didn't want to disturb the review with this, I had planned a small clean-up patch after this review is finished.

The cause of the complicated handling of "struct rt5033_charger_data" lies inside of the "struct rt5033_charger". There the "struct rt5033_charger_data" is initialized as pointer *chg.

The clean-up would be:

 - Inside of "struct rt5033_charger" change the
   "struct rt5033_charger_data" to non-pointer "chg". It is then
   initialized right away.

      struct rt5033_charger_data      chg;

 - Change function rt5033_charger_dt_init() from type
   "struct rt5033_charger_data" to type "int".

      static int rt5033_charger_dt_init(struct rt5033_charger *charger)

 - In the probe function, call the function rt5033_charger_dt_init() in
   the same way like e.g. the following rt5033_charger_reg_init():

      ret = rt5033_charger_dt_init(charger);
              if (ret)
                      return ret;

 - Within function rt5033_charger_dt_init() and all other functions
   using the charger data, get the address of the already-initialized
   struct &charger->chg.

      struct rt5033_charger_data *chg = &charger->chg;

This would also solve the issue reported by Christophe because the errors inside function rt5033_charger_dt_init() would be passed to the probe function by the "ret =" and being returned there with "return ret".

I'm not sure how to handle this now. I would prefer to get the review of this patchset finished and send a clean-up patch afterwards.

[2] https://lore.kernel.org/lkml/1425864191-4121-1-git-send-email-beomho.seo@xxxxxxxxxxx/T/#u

Kind regards,
Jakob




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux