From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760502AbdEVRir (ORCPT ); Mon, 22 May 2017 13:38:47 -0400 Received: from goliath.siemens.de ([192.35.17.28]:47354 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758646AbdEVRiq (ORCPT ); Mon, 22 May 2017 13:38:46 -0400 Subject: Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency To: Andy Shevchenko Cc: Lee Jones , Linux Kernel Mailing List , Sascha Weisenberger References: <5d426b5dd107daa3524123392f8f15b0b47c09dd.1495450431.git.jan.kiszka@siemens.com> <1c86d9d3-38ec-865a-6532-5915d712412b@siemens.com> From: Jan Kiszka Message-ID: <423ab7f7-54cd-5acf-b085-bd5956832c8b@siemens.com> Date: Mon, 22 May 2017 19:38:43 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux