Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751246AbdFBKNX (ORCPT ); Fri, 2 Jun 2017 06:13:23 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:37289 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751040AbdFBKNW (ORCPT ); Fri, 2 Jun 2017 06:13:22 -0400 Subject: Re: [GIT PULL] MMC fixes for v.4.12 rc3 - take 2/2 To: Olof Johansson Cc: Ulf Hansson , Linus , linux-mmc , "linux-kernel@vger.kernel.org" , "arm@kernel.org" , Arnd Bergmann References: <20170529102236.GB2192@mai> <20170602000522.GH13314@localhost> From: Daniel Lezcano Message-ID: Date: Fri, 2 Jun 2017 12:13:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170602000522.GH13314@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1572 Lines: 44 On 02/06/2017 02:05, Olof Johansson wrote: [ ... ] >> For the story, this mmc/sdio is for the WiFi and this one was working for some >> version of the bootloader which initialized the clock and set the enable line >> for the chip. That is bad because the WiFi is working as a side effect from the >> boot loader. >> >> In order to properly make support for the WiFi in the kernel, we need to sort >> out this by: >> >> - Reset the mmc >> - Implement the clock at the pmic level >> - Add the mfd clock cell >> - Add the DT definition > > Ok, that's all fine but it's not really what we would call a fix. Hardware > bringup and enabling of major drivers is usually done through the release > cycle and merged in the merge window, not as "fixes" after it's closed. Yes, I second you on that. That is the reason why I was not really convinced about this series for -rc. > It's not causing problems in this case, but if it happens often it runs > the risk of causing a mess due to conflicting contributions from different > subsystem maintainers (i.e. in particular the DT contents updates), > and in general circumvents the development model we're keeping where > things are tested in -next before merge, etc. > > Anyway, water under the bridge but it's stuff to think about for next time > around. Copy that. Thanks! -- Daniel -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog