[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191001124841.GM2714@lahna.fi.intel.com>
Date: Tue, 1 Oct 2019 15:48:41 +0300
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-usb@...r.kernel.org,
Andreas Noever <andreas.noever@...il.com>,
Michael Jamet <michael.jamet@...el.com>,
Yehezkel Bernat <YehezkelShB@...il.com>,
Rajmohan Mani <rajmohan.mani@...el.com>,
Nicholas Johnson <nicholas.johnson-opensource@...look.com.au>,
Lukas Wunner <lukas@...ner.de>,
Alan Stern <stern@...land.harvard.edu>,
Mario.Limonciello@...l.com,
Anthony Wong <anthony.wong@...onical.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 03/22] thunderbolt: Log warning if adding switch fails
On Tue, Oct 01, 2019 at 02:18:04PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Oct 01, 2019 at 02:38:11PM +0300, Mika Westerberg wrote:
> > If we fail to add a switch for some reason log a warning with the error
> > code. This is useful for debugging.
> >
> > Signed-off-by: Mika Westerberg <mika.westerberg@...ux.intel.com>
> > ---
> > drivers/thunderbolt/tb.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
> > index 1f7a9e1cc09c..541295be9bfc 100644
> > --- a/drivers/thunderbolt/tb.c
> > +++ b/drivers/thunderbolt/tb.c
> > @@ -143,6 +143,7 @@ static void tb_scan_port(struct tb_port *port)
> > struct tb_cm *tcm = tb_priv(port->sw->tb);
> > struct tb_port *upstream_port;
> > struct tb_switch *sw;
> > + int ret;
> >
> > if (tb_is_upstream_port(port))
> > return;
> > @@ -203,7 +204,9 @@ static void tb_scan_port(struct tb_port *port)
> > if (!tcm->hotplug_active)
> > dev_set_uevent_suppress(&sw->dev, true);
> >
> > - if (tb_switch_add(sw)) {
> > + ret = tb_switch_add(sw);
> > + if (ret) {
> > + dev_warn(&sw->dev, "failed to register switch: %d\n", ret);
>
> Shouldn't tb_switch_add() do the error reporting instead? That way it
> makes it easier to call functions and not always have to print failure
> messages :)
Yes, that's better - I'll move it there.
Powered by blists - more mailing lists