[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM5PR07MB319618AFCB415501CD33741FC1CD0@DM5PR07MB3196.namprd07.prod.outlook.com>
Date: Tue, 8 Dec 2020 05:47:51 +0000
From: Parshuram Raju Thombare <pthombar@...ence.com>
To: Nicolas Pitre <nico@...xnic.net>
CC: "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
"slongerbeam@...il.com" <slongerbeam@...il.com>,
"vitor.soares@...opsys.com" <vitor.soares@...opsys.com>,
"praneeth@...com" <praneeth@...com>,
Milind Parab <mparab@...ence.com>,
"linux-i3c@...ts.infradead.org" <linux-i3c@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v10 2/7] i3c: master: use i3c_master_register only for
main master
>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.
Regards,
Parshuram Thombare
Powered by blists - more mailing lists