Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 15 Dec 2022 10:34:42 -0500
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
Message-ID: <Y5s+kuxCAtS8Eixj@rowland.harvard.edu>
References: <20221214-uvc-status-alloc-v3-0-9a67616cc549@chromium.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221214-uvc-status-alloc-v3-0-9a67616cc549@chromium.org>
Precedence: bulk

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