From: javier@osg•samsung.com (Javier Martinez Canillas)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/2] [media] media-device: split media initialization and registration
Date: Mon, 21 Dec 2015 11:37:34 -0300 [thread overview]
Message-ID: <56780EAE.7090909@osg.samsung.com> (raw)
In-Reply-To: <20151215091342.2f825d91@recife.lan>
Hello Mauro,
On 12/15/2015 08:13 AM, Mauro Carvalho Chehab wrote:
[snip]
>>>
>>> /**
>>> - * media_device_register - register a media device
>>> + * media_device_init() - initialize a media device
>>> * @mdev: The media device
>>> *
>>> * The caller is responsible for initializing the media device before
>>> @@ -534,12 +534,11 @@ static void media_device_release(struct media_devnode *mdev)
>>> *
>>> * - dev must point to the parent device
>>> * - model must be filled with the device model name
>>> + *
>>> + * returns zero on success or a negative error code.
>>> */
>>> -int __must_check __media_device_register(struct media_device *mdev,
>>> - struct module *owner)
>>> +int __must_check media_device_init(struct media_device *mdev)
>>
>> I think I suggested making media_device_init() return void as the only
>> remaining source of errors would be driver bugs.
>>
>> I'd simply replace the WARN_ON() below with BUG().
>
> That sounds like bad idea to me, and it is against the current
> Kernel policy of using BUG() only when there's no other way, e. g. on
> event so severe that the Kernel has no other thing to do except to
> stop running.
>
I agree with you, that was exactly my point and what I told Sakari [0] but
he had a strong opinion about it and I didn't mind too much so I decided at
the end to just change it to a BUG_ON() so I could get his ack for this set.
> For sure, this is not the case here. Also, all drivers have already
> a logic that checks if the device init happened. So, they should already
> be doing the right thing.
>
> Regards,
> Mauro
[0]: https://lkml.org/lkml/2015/9/10/483
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
next prev parent reply other threads:[~2015-12-21 14:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-10 13:03 [PATCH 0/2] [media] Fix race between graph enumeration and entities registration Javier Martinez Canillas
2015-09-10 13:03 ` [PATCH 2/2] [media] media-device: split media initialization and registration Javier Martinez Canillas
2015-09-10 17:14 ` Sakari Ailus
2015-09-10 18:31 ` Javier Martinez Canillas
2015-09-11 5:51 ` Sakari Ailus
2015-09-11 7:31 ` Javier Martinez Canillas
2015-09-11 9:07 ` Mauro Carvalho Chehab
2015-09-11 9:28 ` Sakari Ailus
2015-12-15 11:13 ` Mauro Carvalho Chehab
2015-12-21 14:37 ` Javier Martinez Canillas [this message]
2015-12-28 1:14 ` Sakari Ailus
2015-12-28 10:26 ` Mauro Carvalho Chehab
2015-12-28 12:52 ` Mauro Carvalho Chehab
2015-09-10 17:39 ` Sakari Ailus
2015-09-10 18:33 ` Javier Martinez Canillas
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=56780EAE.7090909@osg.samsung.com \
--to=javier@osg$(echo .)samsung.com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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