From: Dan Carpenter <dan.carpenter@oracle.com>
To: Ojaswin Mujoo <ojaswin98@gmail.com>
Cc: nsaenz@kernel.org, gregkh@linuxfoundation.org,
stefan.wahren@i2se.com, arnd@arndb.de, phil@raspberrypi.com,
bcm-kernel-feedback-list@broadcom.com,
linux-arm-kernel@lists.infradead.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] staging: vchiq: Refactor vchiq cdev code
Date: Mon, 21 Jun 2021 11:21:32 +0300 [thread overview]
Message-ID: <20210621082132.GC1901@kadam> (raw)
In-Reply-To: <e786f8c7f92561065b840490c32959932526dac6.1624185152.git.ojaswin98@gmail.com>
On Sun, Jun 20, 2021 at 06:25:46PM +0530, Ojaswin Mujoo wrote:
> vchiq_debugfs_init();
>
> vchiq_log_info(vchiq_arm_log_level,
> - "vchiq: initialised - version %d (min %d), device %d.%d",
> - VCHIQ_VERSION, VCHIQ_VERSION_MIN,
> - MAJOR(vchiq_devid), MINOR(vchiq_devid));
> + "vchiq: platform initialised - version %d (min %d)",
> + VCHIQ_VERSION, VCHIQ_VERSION_MIN);
> +
> + /*
> + * We don't handle error here since the function handles
> + * cleanup in cases of failure. Further, we can proceed
> + * even if this function fails.
> + */
> + vchiq_register_chrdev(&pdev->dev);
I feel like ignoring errors and just continuing seems helpful, but it's
actually doing the users a disservice. If it's an error during, boot
that's different, in that case it's better to get some kind of minimally
useful boot so the user can debug the problem. But if the error isn't
going to prevent the system from booting then it's better to just return
an error so they can fix the problem and try again.
regards,
dan carpenter
next prev parent reply other threads:[~2021-06-21 8:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-20 12:55 [PATCH v2 0/5] vchiq: Patch to separate platform and cdev code Ojaswin Mujoo
2021-06-20 12:55 ` [PATCH v2 1/5] staging: vchiq: Refactor vchiq " Ojaswin Mujoo
2021-06-21 8:21 ` Dan Carpenter [this message]
2021-06-21 14:22 ` Ojaswin Mujoo
2021-06-20 12:56 ` [PATCH v2 2/5] staging: vchiq: Move certain declarations to vchiq_arm.h Ojaswin Mujoo
2021-06-20 12:56 ` [PATCH v2 3/5] staging: vchiq: Move vchiq char driver to its own file Ojaswin Mujoo
2021-06-21 9:56 ` Dan Carpenter
2021-06-21 14:28 ` Ojaswin Mujoo
2021-06-20 12:57 ` [PATCH v2 4/5] staging: vchiq: Make creation of vchiq cdev optional Ojaswin Mujoo
2021-06-20 12:57 ` [PATCH v2 5/5] staging: vchiq: Combine vchiq platform code into single file Ojaswin Mujoo
2021-06-20 13:28 ` [PATCH v2 0/5] vchiq: Patch to separate platform and cdev code Stefan Wahren
2021-06-21 14:11 ` Ojaswin Mujoo
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=20210621082132.GC1901@kadam \
--to=dan.carpenter@oracle.com \
--cc=arnd@arndb.de \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=nsaenz@kernel.org \
--cc=ojaswin98@gmail.com \
--cc=phil@raspberrypi.com \
--cc=stefan.wahren@i2se.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).