linux-kernel - Re: [PATCH v4 2/5] gpio: Add support for Intel LJCA USB GPIO driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 10 Mar 2023 16:59:17 +0800
From:   "Ye, Xiang" <xiang.ye@...el.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Oliver Neukum <oneukum@...e.com>, Arnd Bergmann <arnd@...db.de>,
        "Matthias Kaehlcke" <mka@...omium.org>, Lee Jones <lee@...nel.org>,
        Wolfram Sang <wsa@...nel.org>,
        Tyrone Ting <kfting@...oton.com>,
        Mark Brown <broonie@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        "Bartosz Golaszewski" <brgl@...ev.pl>, <linux-usb@...r.kernel.org>,
        <linux-i2c@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-spi@...r.kernel.org>, <linux-gpio@...r.kernel.org>,
        <srinivas.pandruvada@...el.com>, <heikki.krogerus@...ux.intel.com>,
        <andriy.shevchenko@...ux.intel.com>,
        <sakari.ailus@...ux.intel.com>, <zhifeng.wang@...el.com>,
        <wentong.wu@...el.com>, <lixu.zhang@...el.com>
Subject: Re: [PATCH v4 2/5] gpio: Add support for Intel LJCA USB GPIO driver

On Fri, Mar 10, 2023 at 08:53:10AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 10, 2023 at 03:39:07PM +0800, Ye, Xiang wrote:
> > On Fri, Mar 10, 2023 at 08:11:04AM +0100, Greg Kroah-Hartman wrote:
> > > On Fri, Mar 10, 2023 at 01:01:11PM +0800, Ye, Xiang wrote:
> > > > On Thu, Mar 09, 2023 at 02:40:10PM +0100, Oliver Neukum wrote:
> > > > > 
> > > > > 
> > > > > On 09.03.23 08:10, Ye Xiang wrote:
> > > > > 
> > > > > > +#define LJCA_GPIO_BUF_SIZE 60
> > > > > > +struct ljca_gpio_dev {
> > > > > > +	struct platform_device *pdev;
> > > > > > +	struct gpio_chip gc;
> > > > > > +	struct ljca_gpio_info *gpio_info;
> > > > > > +	DECLARE_BITMAP(unmasked_irqs, LJCA_MAX_GPIO_NUM);
> > > > > > +	DECLARE_BITMAP(enabled_irqs, LJCA_MAX_GPIO_NUM);
> > > > > > +	DECLARE_BITMAP(reenable_irqs, LJCA_MAX_GPIO_NUM);
> > > > > > +	u8 *connect_mode;
> > > > > > +	/* mutex to protect irq bus */
> > > > > > +	struct mutex irq_lock;
> > > > > > +	struct work_struct work;
> > > > > > +	/* lock to protect package transfer to Hardware */
> > > > > > +	struct mutex trans_lock;
> > > > > > +
> > > > > > +	u8 obuf[LJCA_GPIO_BUF_SIZE];
> > > > > > +	u8 ibuf[LJCA_GPIO_BUF_SIZE];
> > > > > 
> > > > > And here we have a violation of DMA coherency rules.
> > > > > Basically you cannot embed buffers into other data structures
> > > > > if they can be subject to DMA.
> > > > But obuf and ibuf does not used to do DMA transfer here.
> > > > It is actually copied from or to ljca buffer to do URB transfer.
> > > 
> > > urb transfers _ARE_ DMA transfers.
> > > 
> > > > Should it still need to follow the DMA coherency rules?
> > > 
> > > Yes, all buffers for USB urbs are required to follow those rules.
> > But these two buffers are not used to do USB urb transfer directly.
> > For the "u8 obuf[LJCA_GPIO_BUF_SIZE]",  it will be copied to ljca buffer
> > ("header->data" as below code [1] showed) first. Then the "header" is used
> > to do the actual urb transfer.
> > 
> > And the "header" is allocated by using kmalloc. It should has met the DMA
> > coherency rules.
> > 
> > [1] """
> > struct ljca_msg *header;
> > ...
> > header = kmalloc(msg_len, GFP_KERNEL);
> > if (!header)
> > 	return -ENOMEM;
> 
> Ok, that's good, but why have 2 buffers for this then?
"u8 obuf[LJCA_GPIO_BUF_SIZE]" is used as a out buffer of LJCA GPIO
package.
"u8 ibuf[LJCA_GPIO_BUF_SIZE]" is used as a in buffer of LJCA GPIO
package.

Both obuf and ibuf here are not used to do URB transfer directly.

This obuf and ibuf somtimes are using at the same time when calling
ljca_transfer. So we need these two buffers.

--
Thanks
Ye Xiang