From: Alan Stern <stern@rowland.harvard.edu>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Max Staudt <mstaudt@chromium.org>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Ming Lei <tom.leiming@gmail.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Yunke Cao <yunkec@chromium.org>, Christoph Hellwig <hch@lst.de>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org
Subject: Re: [PATCH v3 0/2] media: uvcvideo: Code cleanup for dev->status
Date: Thu, 15 Dec 2022 10:34:42 -0500 [thread overview]
Message-ID: <Y5s+kuxCAtS8Eixj@rowland.harvard.edu> (raw)
In-Reply-To: <20221214-uvc-status-alloc-v3-0-9a67616cc549@chromium.org>
On Thu, Dec 15, 2022 at 11:57:17AM +0100, Ricardo Ribalda wrote:
> There is no need to make a kzalloc just for 16 bytes. Let's embed the data
> into the main data structure.
>
> Now that we are at it, lets remove all the castings and open coding of
> offsets for it.
>
> [Christoph, do you think dma wise we are violating any non written rules? :) thanks]
There _is_ a rule, and it is not exactly unwritten. The kerneldoc for
the transfer_buffer member of struct urb says:
This buffer must be suitable for DMA; allocate it with
kmalloc() or equivalent.
Which in general means that the buffer must not be part of a larger
structure -- not unless the driver can guarantee that the structure will
_never_ be accessed while a USB transfer to/from the buffer is taking
place.
There are examples all over the USB subsystem where buffers as small as
one or two bytes get kmalloc'ed in order to obey this rule. 16 bytes is
certainly big enough that you shouldn't worry about it being allocated
separately.
Alan Stern
next prev parent reply other threads:[~2022-12-15 15:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-15 10:57 [PATCH v3 0/2] media: uvcvideo: Code cleanup for dev->status Ricardo Ribalda
2022-12-15 10:57 ` [PATCH v3 1/2] media: uvcvideo: Remove void casting for the status endpoint Ricardo Ribalda
2022-12-15 11:07 ` Ricardo Ribalda
2022-12-15 10:57 ` [PATCH v3 2/2] media: uvcvideo: Do not alloc dev->status Ricardo Ribalda
2022-12-15 12:48 ` Christoph Hellwig
2022-12-20 22:59 ` Ricardo Ribalda
2022-12-15 15:34 ` Alan Stern [this message]
2022-12-16 8:55 ` [PATCH v3 0/2] media: uvcvideo: Code cleanup for dev->status Ricardo Ribalda
2022-12-16 15:45 ` Alan Stern
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=Y5s+kuxCAtS8Eixj@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=Jonathan.Cameron@huawei.com \
--cc=hch@lst.de \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=mstaudt@chromium.org \
--cc=ribalda@chromium.org \
--cc=senozhatsky@chromium.org \
--cc=tom.leiming@gmail.com \
--cc=yunkec@chromium.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