Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1946269imu; Thu, 10 Jan 2019 05:53:23 -0800 (PST) X-Google-Smtp-Source: ALg8bN42u0d+ncaLqu8iL9WAsS6+EMYtOgKTpc4FyyY8cw/6Mh9lw4+GfloiopAArOuj+4M/twXo X-Received: by 2002:aa7:8354:: with SMTP id z20mr10156227pfm.81.1547128403058; Thu, 10 Jan 2019 05:53:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547128403; cv=none; d=google.com; s=arc-20160816; b=o8CR54HIDolm7YCnhVbiRHpbGwhbqd5dC7aAycOnwVRwNZRZZqMCDeCAoAd2YUi/y7 mmNgKhTLjI4Fi7QWuIQZSXP1BMp9IPRWBMj6Jna7V62KJ0CHXp/CR7yps/TMfLz/Ra1G Gt152+Z9oe/VbpmTiJVk1SHGzlJIqF6lVsEUT9pWrpeBsSXeTHXXEAuoHdW/XStzKxaa tSsPye4V58dBSz/q351NtoWIjDKFABI+QXFEzGtHXRwIkLuX8D7lTcX81XNRoclT5vvj 6pmudNm3sfvd+Y29TiQEWIsbXzl5sJCRoY/+PO27HqcRLDdHbswGZ49E9RbEvw2AfYvq 5u1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=91EPZ+aenJDZuoJy56T+IQP+vVcCviuRxLa7PXWOvjs=; b=GYaJNtupRsMwXMB1eHFJ0m3LYqZ11nL3kb7qMYvhKdUSdPWnlA4cpMdDOZS3FBa0G0 BF4fsXdzXIL7x7T1ZLKdpbqqfbNKOrIIw72laBHDGStvoJd8YkYTqcgEW0OgWNlOrozK +qfH3nlZYre/mLLBVdW+Jph+dCZM8RVGZTDV0kYi4kO3amMAb8ajVHpMoc8IgwJ4Nzsf q6Fg880Sf+OyeyHEadA5GPxP3b1Ao21QHUP3OPqPQ8S51xUzmVkQWmdxjTGBRqkli2OM 7/1iakZDmG07zqxqbsfLPQecuD6lO+VFQ5+gMtGz9AWLmaozCrlO5n264t07UPPzwld2 fxHw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=cirrus.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g10si19183514plq.371.2019.01.10.05.53.07; Thu, 10 Jan 2019 05:53:23 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=cirrus.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728958AbfAJNcm (ORCPT + 99 others); Thu, 10 Jan 2019 08:32:42 -0500 Received: from mx0a-001ae601.pphosted.com ([67.231.149.25]:49858 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728733AbfAJNcm (ORCPT ); Thu, 10 Jan 2019 08:32:42 -0500 Received: from pps.filterd (m0077473.ppops.net [127.0.0.1]) by mx0a-001ae601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0ADJXdH031611; Thu, 10 Jan 2019 07:32:38 -0600 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.cirrus.com Received: from mail4.cirrus.com ([87.246.98.35]) by mx0a-001ae601.pphosted.com with ESMTP id 2pu19vsa6k-1; Thu, 10 Jan 2019 07:32:37 -0600 Received: from EX17.ad.cirrus.com (unknown [172.20.9.81]) by mail4.cirrus.com (Postfix) with ESMTP id CDED8611C8B5; Thu, 10 Jan 2019 07:36:47 -0600 (CST) Received: from imbe.wolfsonmicro.main (198.61.95.81) by EX17.ad.cirrus.com (172.20.9.81) with Microsoft SMTP Server id 14.3.408.0; Thu, 10 Jan 2019 13:32:36 +0000 Received: from imbe.wolfsonmicro.main (imbe.wolfsonmicro.main [198.61.95.81]) by imbe.wolfsonmicro.main (8.14.4/8.14.4) with ESMTP id x0ADWaWZ024648; Thu, 10 Jan 2019 13:32:36 GMT Date: Thu, 10 Jan 2019 13:32:36 +0000 From: Charles Keepax To: Yauhen Kharuzhy CC: , , , Subject: Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove Message-ID: <20190110133236.GC3837@imbe.wolfsonmicro.main> References: <20181019085958.32694-1-ckeepax@opensource.cirrus.com> <20181019085958.32694-2-ckeepax@opensource.cirrus.com> <20190109214756.GA18115@jeknote.loshitsa1.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20190109214756.GA18115@jeknote.loshitsa1.net> User-Agent: Mutt/1.5.20 (2009-12-10) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=488 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901100108 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 10, 2019 at 12:47:56AM +0300, Yauhen Kharuzhy wrote: > 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? > Could you be a little more specific here, are you saying if you reprobe the battery charger device or if you reprobe the I2C controller itself? Apologies but I am having a little difficulty working out the path through which the IRQ is not reinitialised. As I would have through the battery chargers probe would have reset up the IRQ then the core would pick it up again from there. Thanks, Charles