From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751825AbdHBAzB (ORCPT ); Tue, 1 Aug 2017 20:55:01 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:60042 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751761AbdHBAy7 (ORCPT ); Tue, 1 Aug 2017 20:54:59 -0400 Date: Tue, 1 Aug 2017 17:54:55 -0700 From: Greg Kroah-Hartman To: Boris Brezillon Cc: Wolfram Sang , linux-i2c@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Arnd Bergmann , Przemyslaw Sroka , Arkadiusz Golec , Alan Douglas , Bartosz Folta , Damian Kos , Alicja Jurasik-Urbaniak , Jan Kotas , Cyprian Wronka , Alexandre Belloni , Thomas Petazzoni , Nishanth Menon , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 2/5] i3c: Add core I3C infrastructure Message-ID: <20170802005455.GA16611@kroah.com> References: <1501518290-5723-1-git-send-email-boris.brezillon@free-electrons.com> <1501518290-5723-3-git-send-email-boris.brezillon@free-electrons.com> <20170801014021.GA20004@kroah.com> <20170801124801.38bbc431@bbrezillon> <20170801175133.GA30520@kroah.com> <20170801233001.4b08834f@bbrezillon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170801233001.4b08834f@bbrezillon> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote: > > > > No release type? Oh that's bad bad bad and implies you have never > > > > removed a device from your system as the kernel would have complained > > > > loudly at you. > > > > > > You got me, never tried to remove a device :-). Note that these > > > ->release() hooks will just be dummy ones, because right now, device > > > resources are freed at bus destruction time. > > > > You better not have a "dummy" release hook, do that and as per the > > kernel documentation, I get to make fun of you in public for doing that > > :( > > I'm not afraid of admitting I don't know everything, even the > simplest things that you consider as basics for a kernel developer. You > can make fun of me publicly if you want but that's not helping :-P. No, I am referring to the Documentation/kobject.txt file, where it says: One important point cannot be overstated: every kobject must have a release() method, and the kobject must persist (in a consistent state) until that method is called. If these constraints are not met, the code is flawed. Note that the kernel will warn you if you forget to provide a release() method. Do not try to get rid of this warning by providing an "empty" release function; you will be mocked mercilessly by the kobject maintainer if you attempt this. Sometimes I wonder why I even write documentation... The point is, you have to release the memory the device structure "owns" in the release callback, if not, then the model is not correct. That's all, please fix up your code to do so and I will be glad to review it again. I'm not trying to be rude here at all, but please, at the least, read the documentation we have already first... thanks, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Kroah-Hartman Subject: Re: [RFC 2/5] i3c: Add core I3C infrastructure Date: Tue, 1 Aug 2017 17:54:55 -0700 Message-ID: <20170802005455.GA16611@kroah.com> References: <1501518290-5723-1-git-send-email-boris.brezillon@free-electrons.com> <1501518290-5723-3-git-send-email-boris.brezillon@free-electrons.com> <20170801014021.GA20004@kroah.com> <20170801124801.38bbc431@bbrezillon> <20170801175133.GA30520@kroah.com> <20170801233001.4b08834f@bbrezillon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20170801233001.4b08834f@bbrezillon> Sender: linux-kernel-owner@vger.kernel.org To: Boris Brezillon Cc: Wolfram Sang , linux-i2c@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Arnd Bergmann , Przemyslaw Sroka , Arkadiusz Golec , Alan Douglas , Bartosz Folta , Damian Kos , Alicja Jurasik-Urbaniak , Jan Kotas , Cyprian Wronka , Alexandre Belloni , Thomas Petazzoni , Nishanth Menon , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala List-Id: devicetree@vger.kernel.org On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote: > > > > No release type? Oh that's bad bad bad and implies you have never > > > > removed a device from your system as the kernel would have complained > > > > loudly at you. > > > > > > You got me, never tried to remove a device :-). Note that these > > > ->release() hooks will just be dummy ones, because right now, device > > > resources are freed at bus destruction time. > > > > You better not have a "dummy" release hook, do that and as per the > > kernel documentation, I get to make fun of you in public for doing that > > :( > > I'm not afraid of admitting I don't know everything, even the > simplest things that you consider as basics for a kernel developer. You > can make fun of me publicly if you want but that's not helping :-P. No, I am referring to the Documentation/kobject.txt file, where it says: One important point cannot be overstated: every kobject must have a release() method, and the kobject must persist (in a consistent state) until that method is called. If these constraints are not met, the code is flawed. Note that the kernel will warn you if you forget to provide a release() method. Do not try to get rid of this warning by providing an "empty" release function; you will be mocked mercilessly by the kobject maintainer if you attempt this. Sometimes I wonder why I even write documentation... The point is, you have to release the memory the device structure "owns" in the release callback, if not, then the model is not correct. That's all, please fix up your code to do so and I will be glad to review it again. I'm not trying to be rude here at all, but please, at the least, read the documentation we have already first... thanks, greg k-h