From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756610AbcAYNZI (ORCPT <rfc822;w@1wt.eu>);
	Mon, 25 Jan 2016 08:25:08 -0500
Received: from mail-yk0-f195.google.com ([209.85.160.195]:35726 "EHLO
	mail-yk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753293AbcAYNZE (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Jan 2016 08:25:04 -0500
MIME-Version: 1.0
X-Originating-IP: [200.3.249.195]
In-Reply-To: <CABxcv=m32FLmLzuGC-KFmZ5q-8TmC1FrhdOw+WB-d_L53gg_tg@mail.gmail.com>
References: <1453718405-40815-1-git-send-email-blogic@openwrt.org>
	<1453718405-40815-2-git-send-email-blogic@openwrt.org>
	<CABxcv=kWnUwpCo=JJbnPAARRM226YfBJw_6yF7MiE8-7iqBD+Q@mail.gmail.com>
	<56A612E2.1010509@openwrt.org>
	<20160125123538.GO6588@sirena.org.uk>
	<56A61F78.6070703@openwrt.org>
	<CABxcv=m32FLmLzuGC-KFmZ5q-8TmC1FrhdOw+WB-d_L53gg_tg@mail.gmail.com>
Date: Mon, 25 Jan 2016 10:25:03 -0300
Message-ID: <CABxcv==AzZju5a3Na0OQf6PmsM_J8auPLzxffLsZ09at8DWXew@mail.gmail.com>
Subject: Re: [PATCH V2 2/2] regulator: mt6323: Add support for MT6323 regulator
From: Javier Martinez Canillas <javier@dowhile0.org>
To: John Crispin <blogic@openwrt.org>
Cc: Mark Brown <broonie@kernel.org>, Steven Liu <steven.liu@mediatek.com>,
        Linux Kernel <linux-kernel@vger.kernel.org>,
        Henry Chen <henryc.chen@mediatek.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        linux-mediatek@lists.infradead.org,
        Matthias Brugger <matthias.bgg@gmail.com>,
        Chen Zhong <chen.zhong@mediatek.com>,
        "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Jan 25, 2016 at 10:19 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:

[snip]

>
> In fact, the kernel is currently not matching the compatible, it is
> only matching because you provided a .of_compatible is provided in the
> mfd_cell.
>

Sorry my English was a bit off in this paragraph...

I tried to say that OF does not traverse MFD sub-devices and lookups a
device driver that matches the compatible automatically since a MFD
device is not a bus. Currently it is only trying to match a compatible
string because the mfd_cell has a .of_compatible set so an of_node is
assigned on mfd_add_device().

But it is failing to match because no OF device table is provided and
the platform bus match callback is falling back to the driver .name to
match so the compatible is not really used as Mark said.

Best regards,
Javier