From: Johannes Berg <johannes@sipsolutions.net>
To: Aloisio Almeida Jr <aloisio.almeida@openbossa.org>
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
sameo@linux.intel.com, lauro.venancio@openbossa.org,
marcio.macedo@openbossa.org, Waldemar.Rymarkiewicz@tieto.com
Subject: Re: [RFC][PATCH v2 3/7] NFC: add nfc generic netlink interface
Date: Wed, 22 Jun 2011 09:34:44 +0200 [thread overview]
Message-ID: <1308728084.3883.9.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1308592212-5755-4-git-send-email-aloisio.almeida@openbossa.org> (sfid-20110620_195221_616961_4428A127)
> + * @NFC_ATTR_TARGET_SENS_RES: extra information for NFC-A targets
> + * @NFC_ATTR_TARGET_SEL_RES: extra information for NFC-A targets
Those descriptions aren't very useful to me, but hopefully if I knew
anything about NFC I'd understand :)
> +struct nfc_target {
> + u32 idx;
> + u32 supported_protocols;
> + u16 sens_res;
> + u8 sel_res;
> +};
There's no list_head here.
> struct nfc_dev {
> unsigned idx;
> + unsigned target_idx;
> + struct nfc_target *targets;
And this looks like an array. Do you really want to do that? That means
lots of reallocations.
> +/**
> + * nfc_targets_found - inform that targets were found
> + *
> + * @dev: The nfc device that found the targets
> + * @targets: array of nfc targets found
> + * @ntargets: targets array size
> + *
> + * The device driver must call this function when one or many nfc targets
> + * are found. After calling this function, the device driver must stop
> + * polling for targets.
> + */
> +int nfc_targets_found(struct nfc_dev *dev, struct nfc_target *targets,
> + int n_targets)
I haven't looked at the API users, but do you really expect them to
build an array? That seems rather odd since I'd typically expect targets
to be discovered one by one, not en bloc.
> + dev->targets_generation++;
> +
> + kfree(dev->targets);
> + dev->targets = kzalloc(n_targets * sizeof(struct nfc_target),
> + GFP_ATOMIC);
> + if (!dev->targets) {
> + dev->n_targets = 0;
> + spin_unlock_bh(&dev->targets_lock);
> + return -ENOMEM;
> + }
> +
> + memcpy(dev->targets, targets, n_targets * sizeof(struct nfc_target));
> + dev->n_targets = n_targets;
If you really want to keep the array thing at least you should use
kmemdup(). I'd argue that the overhead won't be huge even if you don't,
since as you said yourself you don't expect tons of targets (and if you
do have tons of targets, this approach breaks down anyway).
I'd really consider going with a linked list.
> @@ -298,7 +353,10 @@ int nfc_register_device(struct nfc_dev *dev)
> rc = device_add(&dev->dev);
> mutex_unlock(&nfc_devlist_mutex);
>
> - return rc;
> + if (rc < 0)
> + return rc;
> +
> + return nfc_genl_device_added(dev);
No rollback if nfc_genl_device_added() fails? Either you need to ignore
the error or roll back I think.
> +int nfc_genl_device_added(struct nfc_dev *dev)
> +{
> + struct sk_buff *msg;
> + void *hdr;
> +
> + pr_debug("%s\n", __func__);
> +
> + msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
> + if (!msg)
> + return -ENOMEM;
I'd probably ignore the errors since any error just means userspace
wasn't notified, but it can still later look up the devices.
johannes
next prev parent reply other threads:[~2011-06-22 7:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-20 17:50 [RFC][PATCH v2 0/7] NFC subsystem Aloisio Almeida Jr
2011-06-20 17:50 ` [RFC][PATCH v2 1/7] netlink: advertise incomplete dumps Aloisio Almeida Jr
2011-06-20 17:50 ` [RFC][PATCH v2 2/7] NFC: add nfc subsystem core Aloisio Almeida Jr
2011-06-21 21:55 ` Gustavo F. Padovan
2011-06-22 2:24 ` Marcel Holtmann
2011-06-22 14:18 ` Aloisio Almeida
2011-06-20 17:50 ` [RFC][PATCH v2 3/7] NFC: add nfc generic netlink interface Aloisio Almeida Jr
2011-06-21 22:05 ` Gustavo F. Padovan
2011-06-21 22:15 ` Eliad Peller
2011-06-22 20:03 ` Gustavo F. Padovan
2011-06-22 6:56 ` Johannes Berg
2011-06-22 19:55 ` Gustavo F. Padovan
2011-06-22 14:07 ` Aloisio Almeida
2011-06-22 7:34 ` Johannes Berg [this message]
2011-06-22 12:57 ` Samuel Ortiz
2011-06-22 13:08 ` Johannes Berg
2011-06-22 13:27 ` Samuel Ortiz
2011-06-22 16:49 ` Aloisio Almeida
2011-06-23 7:55 ` Johannes Berg
2011-06-20 17:50 ` [RFC][PATCH v2 4/7] NFC: add NFC socket family Aloisio Almeida Jr
2011-06-20 17:50 ` [RFC][PATCH v2 5/7] NFC: add the NFC socket raw protocol Aloisio Almeida Jr
2011-06-20 17:50 ` [RFC][PATCH v2 6/7] NFC: pn533: add NXP pn533 nfc device driver Aloisio Almeida Jr
2011-06-20 17:50 ` [RFC][PATCH v2 7/7] NFC: add Documentation/networking/nfc.txt Aloisio Almeida Jr
2011-06-20 20:24 ` [RFC][PATCH v3 " Aloisio Almeida Jr
2011-06-21 21:23 ` Randy Dunlap
2011-06-22 14:13 ` Aloisio Almeida
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=1308728084.3883.9.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=Waldemar.Rymarkiewicz@tieto.com \
--cc=aloisio.almeida@openbossa.org \
--cc=lauro.venancio@openbossa.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=marcio.macedo@openbossa.org \
--cc=sameo@linux.intel.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).