From owner-svn-src-all@freebsd.org Wed May 29 20:52:17 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D26A915AD289 for ; Wed, 29 May 2019 20:52:16 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2309786DB7 for ; Wed, 29 May 2019 20:52:15 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1559163125; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Bna28+wxyZ+ijgaTGa7MUrB4wslNIKccWeac3dZeLU5+HzBWOXoGHZ1FYLNCI0JPwuDWRYsbVRxQD ZoTEk19AN77mFaWMPQgFw4c84CP+xde7tjqoJ98uucxGIiCzhBUmrXe2OjVlB/nZOMT8LtrEMwn610 /HYh9oDAK5esHyV9OuXVDrYc1caoZrDWEAPTElVFz2GeiyeLWkkFAcl8e29krP2hP2a2BCsl+WziOh nvuj4yAV4FI9wbabPrFgbar1wgbRpCe7yo7g5bLqjIIGj1p85yHUJliscJ5k+JegqPe4RLvWaIQGyl gBUQXj9O2bHGNI/EVQJ+ayemv0ZZtsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=XAg3i3rPBzahmcDf2Qnsd6gUTTZpWADMSIiPeRYPMYI=; b=Gw9sk027bk4pakARLG4ug/AAeE1xduvqBAsBeUGF0dKKDyg+bf7DG2g4wQufjo1Yw4Oeklv5zmeuM GM3KrZSdj0sQtFsWD1n4YpTLUQ7BrwwA4OldK5ptGI3jsNJsPRF/7vcPhQtnjDt9oN6FTpQpg3MPOT mYsENQPjzbtaRcnN8KO0r6sfbI4MIaCBZ3Ze4n289GGutNIbHkSCUE+OzYap8Fx19QTAZ4wk3oYv1Y veHdwx4s1uWxx5DY1LfUrHybm/I4dYxRASjO82SHlrTEatm5pxRsX+0AwbzcadNQAu8DjJcrRzktDG +9Hfx/MwL/fMYb0f39sxKVNXy5vNlHQ== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=XAg3i3rPBzahmcDf2Qnsd6gUTTZpWADMSIiPeRYPMYI=; b=e64deZmyG9cYEFBRoxFGGd49Q1wK4iPhSyPADUBUXE2+Tpmrzhlt98ZTNzsF0Gnzjsubg7tqOUVAS x3EJHYNAOc5JRAfnCIqIoZG9GfLW1kumMKv3wDQX3U2ZFw86TEJkU0lD1XZSuOoALasdZ7hpLW2stI P68ME8cdJydgYlTS1634H/c+INcT/HXNhaufcB0wqBvqDXtxeiGuar3TE43A0vz7a1s9zJikn5Csip B+Fnaq6I7n61VAdQAgRwCmSxk6pahtIZL3d04/Jbl+ZzZRP5Agmwc58RbS7169W4OM1+u7htPjmc7W HFATncUvlSCXjQmdOSvmbWgapeEkX4A== X-MHO-RoutePath: aGlwcGll X-MHO-User: 9b08a4f0-8253-11e9-85c6-c97e5c048ed3 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id 9b08a4f0-8253-11e9-85c6-c97e5c048ed3; Wed, 29 May 2019 20:52:02 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x4TKq0j6036036; Wed, 29 May 2019 14:52:00 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: svn commit: r348355 - head/sys/dev/iicbus From: Ian Lepore To: Andriy Gapon , Niclas Zeising , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Wed, 29 May 2019 14:52:00 -0600 In-Reply-To: References: <201905290908.x4T98L89066643@repo.freebsd.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2309786DB7 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 20:52:17 -0000 On Wed, 2019-05-29 at 15:12 +0300, Andriy Gapon wrote: > On 29/05/2019 14:54, Niclas Zeising wrote: > > On 2019-05-29 11:08, Andriy Gapon wrote: > > > Author: avg > > > Date: Wed May 29 09:08:20 2019 > > > New Revision: 348355 > > > URL: https://svnweb.freebsd.org/changeset/base/348355 > > > > > > Log: > > > revert r273728 and parts of r306589, iicbus no-stop by default feature > > > Since drm2 removal, there has not been any consumer of the feature in the > > > tree. I am also unaware of any out-of-tree consumer. > > > More importantly, the feature has been broken from the very start, both > > > before and after r306589, because the ivar was set on a device that does > > > not support it and it was read from another device that also does not > > > support it. > > > A bus-wide no-stop flag cannot be implemented as an ivar as iicbus > > > attaches as a child of various drivers. Implementing the ivar in each > > > and every I2C driver is just impractical. > > > If we ever want to implement this feature properly, then probably the > > > easiest way to do it would be via a flag in the softc of iicbus. > > > In fact, we might have to do that in the stable branches if we want to > > > fix the code for them. > > > Reported by: ian (long time ago) > > > MFC after: 1 month (maybe) > > > X-MFC-note: cannot just merge the change, must keep drm2 happy > > > > > > > Hi! > > Just a note, be aware that drm2 lives on in ports as drm-legacy-kmod. I haven't > > tested, but, from the description above I worry that it will affect the port. > > What do you think? > > Oh, I forgot about that one... > I think that it could be affected if it still uses FreeBSD iic code. > I guess I might have to revert the change. > > I don't think so, because I don't think this change ever worked. I'm not sure how anybody convinced themselves that it did. It attempts to retrieve ivars from a device that doesn't have them, so the net effect is that the nostop variable is initialized from stack garbage. Maybe whoever wrote and tested it was lucky enough to have that accidentally be consistently zero or non-zero, so their testing appeared to work. Looking at the drm2 code that is the only user of this, it appears that the nostop value is only used in the case where the driver falls back to using the builtin intel_iicbb_driver. That driver relies on iicbus_transfer_gen() which is where the nostop kludge was added. That's the fundamental problem in all of this: the right thing to do, IMO, would have been to implement the iicbus_transfer method directly in the intel_iicbb_driver (probably by just cut-and-pasting the code from iicconf.c then doing whatever is necessary to ignore stops). And we can still do that, pretty trivially, if necessary. -- Ian