From: Krzysztof Halasa <khc@pm.waw.pl>
To: "Matti Linnanvuori" <mattilinn@gmail.com>
Cc: jgarzik@pobox.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1.2.26] wan: new driver retina
Date: Fri, 30 May 2008 18:15:55 +0200 [thread overview]
Message-ID: <m3lk1rhio4.fsf@maximus.localdomain> (raw)
In-Reply-To: <ca0148c30805300552u7eb5da43tfc75127a2e819d1@mail.gmail.com> (Matti Linnanvuori's message of "Fri\, 30 May 2008 15\:52\:59 +0300")
"Matti Linnanvuori" <mattilinn@gmail.com> writes:
> I would not like to change a legacy driver much.
But this is a new driver, right? I guess the SIOCDEVPRIVATEs will go
at some point so the change can't be really avoided.
>>> +static int fepci_char_open(struct inode *inode, struct file *filp)
>>> +{
>>> + unsigned int minor = MINOR(inode->i_rdev);
>>> + if (unlikely(minor >= find_cnt || card_privates[minor].pci_dev == NULL))
>>> + return -ENXIO;
>>> + filp->f_op = &fepci_char_fops;
>>> + if (unlikely(!try_module_get(THIS_MODULE)))
>>> + return -EBUSY;
>>
>> That won't work race-free, use owner field.
>
> You mean the f_op assignment? I have removed that.
Actually I meant try_module_get() from within the driver, for example
your module may get unloaded while in this function, before this
try_module_get(), and that would be fatal. If you set the owner field
the reference count will be incremented by the caller first.
Though you may be right about the assignement as well.
>>> +static int fepci_stream_open_down(struct net_device *dev,
>>> + struct fepci_ch_private *fp)
>>> +{
>>> + unsigned tx_pages, rx_pages, tx_order, rx_order;
>>> + unsigned page_number;
>>> + unsigned int i;
>>> +
>>> + if (unlikely(fp->in_eth_mode)) {
>>> + dev_warn(&dev->dev,
>>> + "Interface is in Ethernet mode, "
>>> + "cannot open stream interface\n");
>>> + return -EBUSY;
>>> + }
> Private net device ioctls are locked with rtnl_lock, so I see no
> race there.
Yes, I thought stream mode = character device but now I see it's
another flavour of network device(?), which is never up and exists
only for the ability to receive netdev ioctls (though it also uses
char dev ioctls).
Did I get this right?
Why not simply use a character device, with normal read, write etc?
--
Krzysztof Halasa
next prev parent reply other threads:[~2008-05-30 16:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-28 10:42 [PATCH v1.2.26] wan: new driver retina Matti Linnanvuori
2008-05-28 12:30 ` Krzysztof Halasa
2008-05-30 12:52 ` Matti Linnanvuori
2008-05-30 16:15 ` Krzysztof Halasa [this message]
2008-06-01 5:59 ` Matti Linnanvuori
2008-06-03 12:08 ` Matti Linnanvuori
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=m3lk1rhio4.fsf@maximus.localdomain \
--to=khc@pm.waw.pl \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mattilinn@gmail.com \
--cc=netdev@vger.kernel.org \
/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