linux-i3c.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Parshuram Raju Thombare <pthombar@cadence.com>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Nicolas Pitre <nico@fluxnic.net>,
	"slongerbeam@gmail.com" <slongerbeam@gmail.com>,
	"vitor.soares@synopsys.com" <vitor.soares@synopsys.com>,
	"praneeth@ti.com" <praneeth@ti.com>,
	Milind Parab <mparab@cadence.com>,
	"linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v10 2/7] i3c: master: use i3c_master_register only for main master
Date: Thu, 17 Jun 2021 08:42:28 +0000	[thread overview]
Message-ID: <CY4PR07MB27570948E3536C160662AEEAC10E9@CY4PR07MB2757.namprd07.prod.outlook.com> (raw)
In-Reply-To: <YL/7XP1fs/2bRiTM@piout.net>

Hi Alexandre,

Thank you for review comments.

>On 08/12/2020 05:47:51+0000, Parshuram Raju Thombare wrote:
>> >This looks a bit confusing. Here you're rolling back detailss in
>> >i3c_primary_master_register() that were factored out in
>> >i3c_master_init(). If i3c_master_init() is successful, then you
>> >shouldn't be undoing its things openly in i3c_primary_master_register().
>> >Instead, there should be another function that does the reverse of
>> >i3c_master_init() here.
>>
>> Every function do its cleanup in case of failures.
>> And if any failure occur after successful i3c_master_init(), we have
>> function i3c_master_bus_cleanup() which does the major cleanup.
>>
>
>The point from Nicolas here was that the workqueue is allocated in
>i3c_master_init so you should have a function to destroy it instead of
>having to do that separately in i3c_primary_master_register. The same is
>true for the put_device. Or you have to ensure i3c_masterdev_release
>is called when i3c_primary_master_register fails.

Ok, IIUC, it is just that we need separate clean up function. 
i3c_master_bus_cleanup is used here to call driver cleanup function and
detach + release devices from bus, and I am not sure i3c_masterdev_release
can be used for that.
Better alternative is i3c_master_unregister(). However, it doesn't handle
the case where device_add fails, as this function unconditionally calls
device_unregister which call both device_del and put_device.

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

  reply	other threads:[~2021-06-17  8:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30  6:16 [PATCH v10 0/7] I3C mastership handover support Parshuram Thombare
2020-11-30  6:16 ` [PATCH v10 1/7] i3c: master: master initialization flow document Parshuram Thombare
2020-11-30  6:17 ` [PATCH v10 2/7] i3c: master: use i3c_master_register only for main master Parshuram Thombare
2020-12-04  4:24   ` Nicolas Pitre
2020-12-08  5:47     ` Parshuram Raju Thombare
2021-06-08 23:21       ` Alexandre Belloni
2021-06-17  8:42         ` Parshuram Raju Thombare [this message]
2020-11-30  6:18 ` [PATCH v10 3/7] i3c: master: add i3c_secondary_master_register Parshuram Thombare
2020-12-04  4:42   ` Nicolas Pitre
2020-12-08  6:00     ` Parshuram Raju Thombare
2020-11-30  6:18 ` [PATCH v10 4/7] i3c: master: add mastership handover support Parshuram Thombare
2020-11-30  6:19 ` [PATCH v10 5/7] i3c: master: add defslvs processing Parshuram Thombare
2020-11-30  6:20 ` [PATCH v10 6/7] i3c: master: sysfs key for acquire bus Parshuram Thombare
2021-06-08 23:33   ` Alexandre Belloni
2021-06-17  9:13     ` Parshuram Raju Thombare
2020-11-30  6:20 ` [PATCH v10 7/7] i3c: master: mastership handover, defslvs processing in cdns controller driver Parshuram Thombare
2021-06-08 23:47   ` Alexandre Belloni
2021-06-17 10:28     ` Parshuram Raju Thombare
2021-03-04 10:06 ` [PATCH v10 0/7] I3C mastership handover support Parshuram Raju Thombare

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=CY4PR07MB27570948E3536C160662AEEAC10E9@CY4PR07MB2757.namprd07.prod.outlook.com \
    --to=pthombar@cadence.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mparab@cadence.com \
    --cc=nico@fluxnic.net \
    --cc=praneeth@ti.com \
    --cc=slongerbeam@gmail.com \
    --cc=vitor.soares@synopsys.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 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).