From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934000AbdEVSXH (ORCPT ); Mon, 22 May 2017 14:23:07 -0400 Received: from mail-wr0-f181.google.com ([209.85.128.181]:33111 "EHLO mail-wr0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932791AbdEVSXF (ORCPT ); Mon, 22 May 2017 14:23:05 -0400 Date: Mon, 22 May 2017 19:23:01 +0100 From: Lee Jones To: Andy Shevchenko Cc: Jan Kiszka , Linux Kernel Mailing List , Sascha Weisenberger Subject: Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency Message-ID: <20170522182301.d2nwqf2qdlzstyye@dell> References: <5d426b5dd107daa3524123392f8f15b0b47c09dd.1495450431.git.jan.kiszka@siemens.com> <1c86d9d3-38ec-865a-6532-5915d712412b@siemens.com> <423ab7f7-54cd-5acf-b085-bd5956832c8b@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 22 May 2017, Andy Shevchenko wrote: > On Mon, May 22, 2017 at 8:38 PM, Jan Kiszka wrote: > > On 2017-05-22 19:36, Andy Shevchenko wrote: > >> On Mon, May 22, 2017 at 8:34 PM, Jan Kiszka wrote: > >>> On 2017-05-22 19:26, Andy Shevchenko wrote: > >>>> On Mon, May 22, 2017 at 8:25 PM, Jan Kiszka wrote: > >>>>> On 2017-05-22 19:20, Andy Shevchenko wrote: > >>>>>> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka wrote: > >>>>>>> On 2017-05-22 19:12, Andy Shevchenko wrote: > >>>>>>>> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka wrote: > > >>>>>> And since there is no difference to the frequency the name is enough. > >>>>>> So, I wouldn't go with this series as is. See above. > >>>>> > >>>>> Nope: Just like for the stmmac, we need to include the asset tags to > >>>>> avoid matching variations of the devices which may carry the same board > >>>>> name. While I will try to avoid that this happens, we are better safe > >>>>> than sorry here. > >>>> > >>>> Do we have an issue right now? > >>>> Yes / No > >>> > >>> Andy, we are trying to design a robust upstream driver here, no ad-hoc > >>> BSP that will not survive the hardware anyway. > >> > >> You didn't answer my question... > >> > >> I do not see a good point to solve the issue that might happen in the future. > >> > > > > While I do - that's why your question is misleading. > > > > Then let's leave the decision up to the maintainer. > > Lee, just for your convenience I'm repeating myself here: > > I do not like this series at all since it tries to solve non-existing > issue in over-engineering way. > > If you on opposite side I will be happy to help reviewing it. New code looks cleaner and appears to use an already defined API. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog