Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4358600pxv; Tue, 29 Jun 2021 05:20:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0vY6XYQRCZHcNp28VOc71CHqm3KD3A3Jb9a+C5J/2EA2kBCik4bzFXJP6U73khqBl1juK X-Received: by 2002:a17:906:38c6:: with SMTP id r6mr17236231ejd.411.1624969211237; Tue, 29 Jun 2021 05:20:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624969211; cv=none; d=google.com; s=arc-20160816; b=zW+k+mzujyREdwOAp0tUc0AYrE61+1AD8IVF93EYdRuFW6LF6UzpnkBJQWuq4rInZg Qgq1muF+Q56dyd++OoeP7/IYxT/XhlgdqB1c2JAn8mYK3vq6W/0m3HCjjt7axbyX1d/j c5Q0GjZozsaVPc7/EzU+9bnSgGuzatxOt/fbVI844Z7mrqh9eO+1qtGUNvoMAmlGG5Tj Lwcj2wvvWDxQ3KoHq1rl5YvOcoBkk3VeQjiA2r6Au3T6FdMZaWsvnjAzpHey9oYrb/5V 0SuvUAt6BQob5CMH9WGYnohqngyB4iF+bINwcnfiJN71cTbbi78eiGEgj+2STmc+UMZj e2/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=SRiwRnnchcn1vcsL28FT1wXXR+nVMha32AYgk3A+j7g=; b=p53YgJlsk+yG8F6qrfnJlqucl8P5y/8BdKde3qSoocO5vtPYPfA0IC98H6HrJsunJM Dp4ty6iO1/4MuQEELtePVY8zD80DTKqgJnh+8Up6htptog8Cu8j6O28qJMDd7mbtySOR JjrnCD7bEleklj2Onm1rdFvgzLBmPpIRC6a2Juc+TC3Gujr46mje0igTb1s1ycxBtkMW QV9TW9RVMLaAHjX2oC+zjoQAJSzNPBV0cG8//yV206uNOXeOOi2bjuWcTTZSsO6BzFse CCWlQ5gsTmc5y2N8aeNICDsgbFnaY2iMD08p9e3EesoZvdH1xHJEAbpfPjJanVxZzdbI nZkg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=G0dcM6cX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z12si17686863edr.197.2021.06.29.05.19.46; Tue, 29 Jun 2021 05:20:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=G0dcM6cX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233576AbhF2MUg (ORCPT + 99 others); Tue, 29 Jun 2021 08:20:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:38540 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233384AbhF2MUg (ORCPT ); Tue, 29 Jun 2021 08:20:36 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7B6F861D86; Tue, 29 Jun 2021 12:18:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1624969088; bh=xJthybkGih3MFMOF3skw+21+YncJAonVo4+8Ol8qVbo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=G0dcM6cX+TbGVl0FfK4kDcQJNtzCAWPhusD6p1106AFe9m+x0FDnqU2BbtNFfPAhc I1DX/jJF371OK/iex3fbQrNLRFQjTbUFDWe4j6JKXQieA1S8P8j6pyaauUITQH+3sF E+FUVoWrB9l++fVn0ih3yLstAAQeOA0P1r8I1p7M= Date: Tue, 29 Jun 2021 14:18:06 +0200 From: Greg KH To: Bing Fan Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm pl011 serial: support multi-irq request Message-ID: References: <1624930164-18411-1-git-send-email-hptsfb@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 29, 2021 at 07:32:36PM +0800, Bing Fan wrote: > hello, > > replied as below. > > and new patch is at the bottom. Please submit this properly as the documentation says to do so, I can't take an attachment :( > > > + struct amba_device *amba_dev = (struct amba_device *)uap->port.dev; > > Are you sure you can just cast this like this? Did you test this? > > > Yes, i have tested and applied in my project. > > The function pl011_probe calls pl011_setup_port with &amba_dev->dev and uap > params; > > and pl011_setup_port set uap->port.dev to the address of amba_dev->dev; > > the two structs' relationship is: > >     struct amba_device { > >         struct device dev; > >         …… > >     }; > > When pointer(uap->port.dev) points to amba_dev->dev address, the momery > actully stores > > content of struct amba_device; so the cast assignment can be forced to > amba_dev. That is now how this should work, use the correct container_of() cast instead. That will always work no matter where struct device is in the structure. You got lucky here :) > > > + > > > + if (!amba_dev) > > > + return -1; > > Do not make up error numbers, return a specific -ERR* value. > > changed to "return -ENODEV" So this changed the logic of this function, is that ok? > > > > And how can this happen? > > The function pl011_setup_port isn't called, event pl011_probe isn't called. And how can that ever happen? thanks, greg k-h