Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757331AbcKDV3u (ORCPT ); Fri, 4 Nov 2016 17:29:50 -0400 Received: from mail-qt0-f175.google.com ([209.85.216.175]:35159 "EHLO mail-qt0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754191AbcKDV3s (ORCPT ); Fri, 4 Nov 2016 17:29:48 -0400 MIME-Version: 1.0 In-Reply-To: References: <1478015868-10309-1-git-send-email-andrew.smirnov@gmail.com> <1478015868-10309-2-git-send-email-andrew.smirnov@gmail.com> From: Linus Walleij Date: Fri, 4 Nov 2016 22:29:47 +0100 Message-ID: Subject: Re: [PATCH 01/14] pinctrl-sx150x: Rely on of_modalias_node for OF matching To: Andrey Smirnov Cc: "linux-gpio@vger.kernel.org" , Neil Armstrong , "linux-kernel@vger.kernel.org" , Chris Healy Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1917 Lines: 46 On Fri, Nov 4, 2016 at 9:09 PM, Andrey Smirnov wrote: > On Fri, Nov 4, 2016 at 5:28 AM, Linus Walleij wrote: >> On Tue, Nov 1, 2016 at 4:57 PM, Andrey Smirnov wrote: >> >>> None of the OF match table entries contain any compatiblity strings that >>> could not be matched against using i2c_device_id table above and >>> of_modalias_node. Besides that entries in OF match table do not cary >>> proper device variant information which is need by the drive. Those two >>> facts combined, IMHO, make a compelling case for removal of that code >>> altogether. >>> >>> Signed-off-by: Andrey Smirnov >> (...) >>> -static const struct of_device_id sx150x_of_match[] = { >>> - { .compatible = "semtech,sx1508q" }, >>> - { .compatible = "semtech,sx1509q" }, >>> - { .compatible = "semtech,sx1506q" }, >>> - { .compatible = "semtech,sx1502q" }, >>> - {}, >>> -}; >> >> I'm a bit hesitant about this since we should ideally first match on the >> compatible string for any device. We have tried to alleviate the situation >> in I2C devices but it has been a bit so-so. >> > > Ah, good to know. Let's do it that way then. > >> It would be best if we make a separate patch after this tjat adds it >> back, set the variant data also in the .data of the match and >> use of_device_get_match_data(). > > Do you prefer it as a separate patch, or, instead, should I change > this patch of the series to do what you describe? I'd be happy to do > either and it seems like it would be a trivial change so it should > invalidate any of the testing done by Neil. Yeah it would ideally be a modification of this patch. Whatever is easiest for you to do! BTW this is a great patch set and I'm very grateful for yours+Neils combines contributions on getting this driver into shape. Yours, Linus Walleij