Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1213693imu; Wed, 9 Jan 2019 13:49:23 -0800 (PST) X-Google-Smtp-Source: ALg8bN4cZ19IegQzCPvhq3k5s3OKv6ykSsfNR1yQNpmZgVxzU46L6jQ8FwNjkFXEPPWkpKyRb9jY X-Received: by 2002:a63:85c6:: with SMTP id u189mr4607365pgd.156.1547070562988; Wed, 09 Jan 2019 13:49:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547070562; cv=none; d=google.com; s=arc-20160816; b=BC/3MVPPGBqU+yaP86ZmZ+DH2dSJ7hw3coHVX+NqptQY5FiCd/bvEjrUQZG5IIvg5o xYAG6KN/2na3AfiAFF9UoX/kh8IOwj8lqfvsOdVSEtuYE2YCyyy+J0FcXUXesBi9JOVO p5409IF9E7172B7kPAnnEqnqvwGQ2RapJhfH947ArmD5Vs92mtPNC1bTfhZ9ICZ9gYsz Rzyn/bCZIPcVLb/yDnvFhvV5wrggnt7RWecWjIwTGUrfFPeP60SjT7tJSk1iN7l0CK46 Ygu2abeLowIssxm57tB/QHyMsN7BxhGnZdDA+wAJClDl77usEH/io8iAaj0fLy6LvcO5 krDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=wbPtCnCMYFXNwMaTry6/291aYlawOCT2SxLb0zLOzsI=; b=EJW07gbM5lsq2x17dxkcF0Rta+z1KmgtzqElxIHnF6pNodoNzSVqGFxvFfZAe3eN0O 4aRE9+RouzMKhsaimw0cKkXu4Lmbgyi26I/cp+5hAl6w82I3GHRNysHG84LKa4I6FWqb r0h/7+O5/p6AQwBs1VwgAQi8c84CcLN8Olr7dNw8FYea1F3h3UQKTXey1CUzrsMFEgU6 FQHSuB7WMut81sQWThELMnpC6eoBCP9/EjQwcuyj0/S8BUTuSc53XGk4fPDN/CAhYrvI 4W45vbZx37XmOqQN7FvK0dByUkrWceqt/Cvw9Hs20TyU025RPhXEP+muVQnM+TYXFsoA iPHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=huyvVBDM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y2si3546485pfy.29.2019.01.09.13.49.07; Wed, 09 Jan 2019 13:49:22 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=huyvVBDM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726913AbfAIVsC (ORCPT + 99 others); Wed, 9 Jan 2019 16:48:02 -0500 Received: from mail-wr1-f66.google.com ([209.85.221.66]:38257 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726221AbfAIVsB (ORCPT ); Wed, 9 Jan 2019 16:48:01 -0500 Received: by mail-wr1-f66.google.com with SMTP id v13so9203223wrw.5; Wed, 09 Jan 2019 13:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wbPtCnCMYFXNwMaTry6/291aYlawOCT2SxLb0zLOzsI=; b=huyvVBDM3pwU3ksnZy8h/Ic6cXlyob6PrXIz5bHNSdK11APCdBieVVnd73ytxEvwJO +lYwXs1ZTDWf4+opAkxkwCUnIQNmIDdIK/bnsb43r6C4a1ewVLQGzKNRTm0bgpMf08OI roHpZ5vL/3wIu+zNLio0Bu9+lkbBzkrVlQgI4hF/qMccVTHZKqjlRSNTpkiPh7AoZZg0 JYal0su6f5IwbumvfbPoc/sYyzZgjDnVLg5jlA75vYi+3WfughVUGMiCHQlPKTaInk0X goE5gPHHRejqfcU+g0n2RbHXO6NUJyjnpFdk9cv2zUGJH1SHBhLgJ3rqSQSI4maqBk5u C6Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wbPtCnCMYFXNwMaTry6/291aYlawOCT2SxLb0zLOzsI=; b=SN54WdYZR1a+vxWIexICjWyplAxGJrvCOISeUb9dyVsg16L7f7CG+LukSCy5MEfaia oAeUhIP2SbqxqzH6A/rBf2xH8oX3XaDG3t0SCG6yPrh7Hm5XyQMKUGlf4TZQtmPq71ia yKjPMbo5qnr+yoOfzhoz/V7IiilRpnEjxVdaImBiHIZcDMVArk6BvqvZZOdNSS0/DmLc b1+IZ4V+y7Xv3ez8x1PFugou0+GeMsP7ZIWw6UoYEBqhM07xHmEYbdulx4RTubzS+xbm 2J2M8uyOPQkxARcWcNP6G86SEZ2jVOYDzblKBTxezKL+xcLVLUNdaEHDmvMRTleZ60bf dLVw== X-Gm-Message-State: AJcUukdhxYaaRMKEEV6PAuK1dKc81hO1edIEi6kk8dBTPQTbl71kMY5z 0mTYu/e30IudnaV4snyX7uE= X-Received: by 2002:adf:9d08:: with SMTP id k8mr6945177wre.203.1547070479392; Wed, 09 Jan 2019 13:47:59 -0800 (PST) Received: from localhost.localdomain ([46.216.128.22]) by smtp.gmail.com with ESMTPSA id g129sm13917603wmf.39.2019.01.09.13.47.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 09 Jan 2019 13:47:58 -0800 (PST) Received: from [127.0.0.1] (helo=jeknote.loshitsa1.net) by localhost.localdomain with esmtp (Exim 4.91) (envelope-from ) id 1ghLhc-0005FV-Ik; Thu, 10 Jan 2019 00:47:56 +0300 Date: Thu, 10 Jan 2019 00:47:56 +0300 From: Yauhen Kharuzhy To: Charles Keepax Cc: wsa@the-dreams.de, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, patches@opensource.cirrus.com Subject: Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove Message-ID: <20190109214756.GA18115@jeknote.loshitsa1.net> References: <20181019085958.32694-1-ckeepax@opensource.cirrus.com> <20181019085958.32694-2-ckeepax@opensource.cirrus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181019085958.32694-2-ckeepax@opensource.cirrus.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 19, 2018 at 09:59:58AM +0100, Charles Keepax wrote: > The IRQ will be mapped in i2c_device_probe only if client->irq is zero and > i2c_device_remove does not clear this. When rebinding an I2C device, > whos IRQ provider has also been rebound this means that an IRQ mapping > will never be created, causing the I2C device to fail to acquire its > IRQ. Fix this issue by clearing client->irq in i2c_device_remove, > forcing i2c_device_probe to lookup the mapping again. Hi. I found driver i2c/busses/i2c-cht-wc.c which instantiates I2C device (battery charger) and passes IRQ to driver not using standard I2C IRQ mapping code. So if we reprobe I2C device (by reloading I2C device driver module or by manipulations with sysfs), we get invalid IRQ number for client: adap->client_irq = irq_create_mapping(adap->irq_domain, 0); ... irq_set_chip_data(adap->client_irq, adap); irq_set_chip_and_handler(adap->client_irq, &adap->irqchip, handle_simple_irq); ... board_info.irq = adap->client_irq; adap->client = i2c_new_device(&adap->adapter, &board_info); adap->client->irq will be reset after device removing here. Any advice to fix this? Maybe move initial i2c_client->irq value to new field like client->init_irq and copy it to client->irq at probing, for example? > > Signed-off-by: Charles Keepax > Reviewed-by: Benjamin Tissoires > --- > drivers/i2c/i2c-core-base.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c > index 656f0a6fe3adf..28460f6a60cc1 100644 > --- a/drivers/i2c/i2c-core-base.c > +++ b/drivers/i2c/i2c-core-base.c > @@ -430,6 +430,8 @@ static int i2c_device_remove(struct device *dev) > dev_pm_clear_wake_irq(&client->dev); > device_init_wakeup(&client->dev, false); > > + client->irq = 0; > + > return status; > } > -- Yauhen Kharuzhy