From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753553AbbKQNig (ORCPT ); Tue, 17 Nov 2015 08:38:36 -0500 Received: from lists.s-osg.org ([54.187.51.154]:57688 "EHLO lists.s-osg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752811AbbKQNif (ORCPT ); Tue, 17 Nov 2015 08:38:35 -0500 Subject: Re: spi: OF module autoloading is still broken To: Mark Brown References: <56104E88.3040807@gmail.com> <20151112185926.GC8456@google.com> <20151113194031.GI8456@google.com> <20151113221228.GT12392@sirena.org.uk> <20151113225113.GJ8456@google.com> <20151113231410.GV12392@sirena.org.uk> <20151113234857.GK8456@google.com> <564A101F.9090807@osg.samsung.com> <20151116192434.GO8456@google.com> <564A35EB.5080008@osg.samsung.com> <20151117133455.GQ31303@sirena.org.uk> Cc: Brian Norris , Heiner Kallweit , linux-mtd@lists.infradead.org, Dmitry Torokhov , linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org From: Javier Martinez Canillas Message-ID: <564B2DD5.2060502@osg.samsung.com> Date: Tue, 17 Nov 2015 10:38:29 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151117133455.GQ31303@sirena.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Mark, On 11/17/2015 10:34 AM, Mark Brown wrote: > On Mon, Nov 16, 2015 at 05:00:43PM -0300, Javier Martinez Canillas wrote: > >> Now that I think about it, there is another issue and is that today spi:foo >> defines a namespace while changing to of: will make the namespace flat so >> a platform driver that has the same vendor and model will have the same >> modalias. > >> IOW, for board files will be platform:bar and i2c:bar while for OF will be >> of:NfooTCfoo,bar in both cases. I wonder if we should reuse the type >> for that and store the subsystem prefix there. What do you think? > > I'm not sure that's a big issue - if we end up loading an extra module > with a second bus glue it'll waste a little memory but it's not going to > be a huge amount. Obviously it'd be nice to fix but it doesn't seem > super important compared to getting the modules loaded. > Agreed, it has indeed lower priority. That's why I added it to my TODO list so it can be fixed later as a follow up. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America