From: Peter Hong <peter_hong@fintek.com.tw>
To: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Cc: <wg@grandegger.com>, <mkl@pengutronix.de>,
<michal.swiatkowski@linux.intel.com>,
<Steen.Hegelund@microchip.com>, <davem@davemloft.net>,
<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
<frank.jungclaus@esd.eu>, <linux-kernel@vger.kernel.org>,
<linux-can@vger.kernel.org>, <netdev@vger.kernel.org>,
<hpeter+linux_kernel@gmail.com>
Subject: Re: [PATCH V3] can: usb: f81604: add Fintek F81604 support
Date: Mon, 10 Apr 2023 13:50:30 +0800 [thread overview]
Message-ID: <7e9c01da-74be-3d8d-bb0c-d90935d82081@fintek.com.tw> (raw)
In-Reply-To: <CAMZ6RqLnWARxkJx0gBsee4NsyQicpg6=bPaysmoFo6KRc-j23g@mail.gmail.com>
Hi Vincent,
Vincent MAILHOL 於 2023/3/30 下午 09:11 寫道:
> Hmm, I am still not a fan of setting a mutex for a single concurrency
> issue which can only happen during probing.
>
> What about this:
>
> static int __f81604_set_termination(struct net_device *netdev, u16 term)
> {
> struct f81604_port_priv *port_priv = netdev_priv(netdev);
> u8 mask, data = 0;
>
> if (netdev->dev_id == 0)
> mask = F81604_CAN0_TERM;
> else
> mask = F81604_CAN1_TERM;
>
> if (term == F81604_TERMINATION_ENABLED)
> data = mask;
>
> return f81604_mask_set_register(port_priv->dev, F81604_TERMINATOR_REG,
> mask, data);
> }
>
> static int f81604_set_termination(struct net_device *netdev, u16 term)
> {
> ASSERT_RTNL();
>
> return __f81604_set_termination(struct net_device *netdev, u16 term);
> }
>
> static int f81604_init_termination(struct f81604_priv *priv)
> {
> int i, ret;
>
> for (i = 0; i < ARRAY_SIZE(f81604_priv->netdev); i++) {
> ret = __f81604_set_termination(f81604_priv->netdev[i],
> F81604_TERMINATION_DISABLED);
> if (ret)
> return ret;
> }
> }
>
> static int f81604_probe(struct usb_interface *intf,
> const struct usb_device_id *id)
> {
> /* ... */
>
> err = f81604_init_termination(priv);
> if (err)
> goto failure_cleanup;
>
> for (i = 0; i < ARRAY_SIZE(f81604_priv->netdev); i++) {
> /* ... */
> }
>
> /* ... */
> }
>
> Initialise all resistors with __f81604_set_termination() in probe()
> before registering any network device. Use f81604_set_termination()
> which has the lock assert elsewhere.
The f81604_set_termination() will transform into the following code:
static int f81604_write(struct usb_device *dev, u16 reg, u8 data);
static int f81604_read(struct usb_device *dev, u16 reg, u8 *data);
static int f81604_update_bits(struct usb_device *dev, u16 reg, u8 mask,
u8 data);
static int __f81604_set_termination(struct usb_device *dev, int idx, u16
term)
{
u8 mask, data = 0;
if (idx == 0)
mask = F81604_CAN0_TERM;
else
mask = F81604_CAN1_TERM;
if (term)
data = mask;
return f81604_update_bits(dev, F81604_TERMINATOR_REG, mask, data);
}
static int f81604_set_termination(struct net_device *netdev, u16 term)
{
struct f81604_port_priv *port_priv = netdev_priv(netdev);
struct f81604_priv *priv;
ASSERT_RTNL();
priv = usb_get_intfdata(port_priv->intf);
return __f81604_set_termination(port_priv->dev, netdev->dev_id, term);
}
and also due to f81604_write() / f81604_read() / f81604_update_bits()
may use
in f81604_probe() without port private data, so we'll change their first
parameter
from "struct f81604_port_priv *priv" to "struct usb_device *dev". Is it OK ?
> Also, looking at your probe() function, in label clean_candev:, if the
> second can channel fails its initialization, you do not clean the
> first can channel. I suggest adding a f81604_init_netdev() and
> handling the netdev issue and cleanup in that function.
When the second can channel failed its initialization, the label
"clean_candev" will
clear second "netdev" object and the first "netdev" will cleanup in
f81604_disconnect().
Could I remain this section of code ?
Thanks
next prev parent reply other threads:[~2023-04-10 5:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-27 5:10 Ji-Ze Hong (Peter Hong)
2023-03-27 7:55 ` Steen.Hegelund
2023-03-27 10:27 ` Vincent MAILHOL
2023-03-28 3:18 ` Peter Hong
2023-03-28 4:49 ` Vincent MAILHOL
2023-03-28 6:24 ` Marc Kleine-Budde
2023-03-30 6:46 ` Peter Hong
2023-03-30 13:11 ` Vincent MAILHOL
2023-04-10 5:50 ` Peter Hong [this message]
2023-04-10 6:26 ` Vincent MAILHOL
2023-03-27 15:09 ` Marc Kleine-Budde
2023-03-30 5:40 ` Peter Hong
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=7e9c01da-74be-3d8d-bb0c-d90935d82081@fintek.com.tw \
--to=peter_hong@fintek.com.tw \
--cc=Steen.Hegelund@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=frank.jungclaus@esd.eu \
--cc=hpeter+linux_kernel@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol.vincent@wanadoo.fr \
--cc=michal.swiatkowski@linux.intel.com \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=wg@grandegger.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
all inboxes | Powered by JetHome®