Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp268362imm; Wed, 30 May 2018 23:22:10 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJU85FCLFEgJhGLmC+mu+W7uM9oFvOEezo9eCwe1x2KzwIfkCUFIXslaike0d80ZdcVK9Yr X-Received: by 2002:a17:902:5602:: with SMTP id h2-v6mr5852154pli.115.1527747730790; Wed, 30 May 2018 23:22:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527747730; cv=none; d=google.com; s=arc-20160816; b=k+S3dPeB+JiBSKW2hmeI4/leRhetn2I0mN1o/AFdxe/wTjmotD04wiedn6ZzuCLOIg K+OurjbRYBa5VHChJ0XaGjlKBBc4dg2yQ5flfvHy8WIiQxcu8jDXOZiEiBAswmXGxFUK ao7j3vC0mI6isikaFJe7OOpFp7ZThX/znSFm5EAOFwuXggm0tmAboJCiUbM1+IMPnQjF l4O4RCjHBm3v8id5L0Wj+FeDJizCbTTRbuhpGkd8BWJC4FubA0BK7RJgFLmh+mL6EvCc vwoE6P4ha+mT/jiAGMpB6SGRIRrvIufNPT49h5/EG/Ht2WenUw7kdq5pDnHA8KHBwZsv 4t6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=pZJ8bZiw5Slz+EF/HvJVOI/R2WcePyZncDHll2B+Wag=; b=jzzYRfEPGW3qzuq0I5Uw5S0BeIWhp0SKrTzNUWByXXvN8pcjbrhDdcY3/Lm6SuHk7e yy2OzEYFOgCwNJe86n0QScd82cmxsnB15/Qfue6nsKQ7RIt0KBb50OmrZq5UAXplBS1R 9Jgob2XN5Elb80lata8BSpv64SXLenwltQZdL/Q2bAMY8IOKHh1XLGUaA5t/orB1sRVY gqvJMQs1yNCLTfuxoHuXn6ncNN4u94XM62GuthcC+8YIcEI6Gj3A5izE3/lcDQBLrbhq LbRW9mRk3Zwek9vChxul1L2PTWuQygV1sxR3wJ+6DhD8TTHYNvQzNNHUjw0xP61N806Q rVBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MNsdDQVz; 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 y17-v6si20448688plp.485.2018.05.30.23.21.56; Wed, 30 May 2018 23:22:10 -0700 (PDT) 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=MNsdDQVz; 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 S1753925AbeEaGVa (ORCPT + 99 others); Thu, 31 May 2018 02:21:30 -0400 Received: from mail-qt0-f195.google.com ([209.85.216.195]:41826 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751037AbeEaGV0 (ORCPT ); Thu, 31 May 2018 02:21:26 -0400 Received: by mail-qt0-f195.google.com with SMTP id y20-v6so349368qto.8; Wed, 30 May 2018 23:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pZJ8bZiw5Slz+EF/HvJVOI/R2WcePyZncDHll2B+Wag=; b=MNsdDQVzMf8LctuOIKm5mDSuj6trHKoAxWwHV5XXUouaUj2JXlAVxCNsjUqexxdPmd clCEgd/wEF1NSIbjSed/yXMGBnBFP2UpUka3EyBTNEk9mpywyKruQoX4koPJQQGfQPqF bJOUf2KUg/GyyRS11TQQGzAHz9j+CIIv4cQiqYm4WCCEmV9mvo0PBkkwq+mfZptavmh/ q9b6tk81kjl+75nGQH0VNL5mn5PwSwXZ+xho4KLztwGeQWhtIGnAVzoezrqz0kG04CRp HDUEOOOTeIbZFjZ2+FYKP1dPPkMT5Bdk73DwbcdBsDx9s7cqoQbkYGLLJWPPpzf0MEcn FJyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pZJ8bZiw5Slz+EF/HvJVOI/R2WcePyZncDHll2B+Wag=; b=TBQ77/0+RF1X1fhmjj1yXiCoKdN94fNjN1tS+lNO7omnR7EZGZtYCDRKIDQ9mW6gf0 +z/wDdxuriuT8GF+deNqUYtsDmdzvZCEs25m+N/AcigdVThN/GS3YuhepU/CSn7Ymjrn Q6ugk36PbKBrjceoc8Eo26s1S2gYE47MjgpS9vuTndIdyENNLneS5/CkujjPCxQ6bUtM C22sIqQYlK+i5JGVU5WA0oKPEJU16W4Naq+ZSHt0v+VxtO9v8VR+8MRUWyq5VTjpq+16 JUMcSUgcpwozw7kRRTnoDc4DmoDjqvAGQb0NvT2R9KQyM7hBi0C1NDyaWvcwRsbP22QZ m4uA== X-Gm-Message-State: APt69E1qJSj0Lnx0FxwX2t+pCCMWiwx7+BkPSd3LjQ3y/ztqWHuLnV4P i1Z27XU73m6gM9DwLsIR4L+5Qhfcdl7VEcEROQk= X-Received: by 2002:a0c:b2ca:: with SMTP id d10-v6mr476157qvf.16.1527747686046; Wed, 30 May 2018 23:21:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:9896:0:0:0:0:0 with HTTP; Wed, 30 May 2018 23:21:25 -0700 (PDT) In-Reply-To: <48444d16bd410188bd43ca5eea97f03f70c80f42.camel@kernel.crashing.org> References: <1527632665-25707-1-git-send-email-eajames@linux.vnet.ibm.com> <1527632665-25707-4-git-send-email-eajames@linux.vnet.ibm.com> <48444d16bd410188bd43ca5eea97f03f70c80f42.camel@kernel.crashing.org> From: Andy Shevchenko Date: Thu, 31 May 2018 09:21:25 +0300 Message-ID: Subject: Re: [PATCH v7 3/7] drivers/i2c: Add port structure to FSI algorithm To: Benjamin Herrenschmidt Cc: Eddie James , linux-i2c , Linux Kernel Mailing List , devicetree , Wolfram Sang , Rob Herring , Joel Stanley , Mark Rutland , Greg Kroah-Hartman , "Edward A. James" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 31, 2018 at 1:34 AM, Benjamin Herrenschmidt wrote: > On Thu, 2018-05-31 at 00:27 +0300, Andy Shevchenko wrote: >> On Wed, May 30, 2018 at 6:47 PM, Eddie James wrote: >> > On 05/29/2018 06:19 PM, Andy Shevchenko wrote: >> > > On Wed, May 30, 2018 at 1:24 AM, Eddie James >> > > wrote: >> > > Isn't below somehow repeats of_i2c_register_devices() ? >> > > Why not to use it? >> > Because I need to assign all these port structure fields. Also looks like >> > of_i2c_register_devices creates new devices; I just want an adapter for each >> > port. >> >> Hmm... Wolfram, what is your opinion on this design? > > Andy, I don't understand your issue. > > of_i2c_register_devices() is about discovering the i2c devices below a > given bus. This is not what is happening here. > > This is a driver for a master that supports multiple busses, so it the > above loop creates all the busses. My issue here, that it feels like a lot of duplication with existing approaches. Though, it might be a right thing to do at the end. So, let's just assume maintainer will give their point of view. >> > > > + devm_kfree(dev, port); >> > > >> > > This hurts my eyes. Why?! >> > What would you suggest instead? >> >> You even didn't wait for answer, why to ask then? > > Please stop being so rude. OK. >> Moreover, you didn't answer to my question. Why are you doing that >> call implicitly? > > "implicitly" ? What's implicit here ? This is just pretty standard > cleanup after failure, you are being very cryptic here. > > Please state precisely what it is you dislike with that code instead of > expecting us to guess and being nasty about it. Eddie was a genuine > question, he doesn't see what you think is "hurtful to the eyes" in the > code you quoted. In 99% cases when someone calls devm_kfree() it means wrong choice of devm_k*alloc() in the first place. So, with explanation given why it's done in this way I would rather suggest to switch to plain k*alloc() / kfree(). Or do we really care about few hundreds of bytes wasted? -- With Best Regards, Andy Shevchenko