From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Sat, 26 Aug 2017 15:12:34 -0400 Subject: [U-Boot] [PATCH v3 0/8] sf: improve support of (Q)SPI flash memories In-Reply-To: References: <20170725070102.1344-1-wenyou.yang@microchip.com> <0576ef1a-1681-a2dc-6a2b-c30bb71d4737@Microchip.com> <7f5f8a98-7b8b-f16e-58a1-324e06980b5a@denx.de> <53a2419c-a85c-82ba-a4ee-059b2e6a1626@denx.de> Message-ID: <20170826191234.GR2827@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sat, Aug 26, 2017 at 10:36:57AM +0200, Marek Vasut wrote: > On 08/26/2017 08:14 AM, Jagan Teki wrote: > > On Sat, Aug 26, 2017 at 4:35 AM, Bin Meng wrote: > >> On Sat, Aug 26, 2017 at 12:45 AM, Marek Vasut wrote: > >>> On 08/25/2017 06:28 PM, Jagan Teki wrote: > >>>> On Fri, Aug 25, 2017 at 9:43 PM, Marek Vasut wrote: > >>>>> On 08/25/2017 06:07 PM, Jagan Teki wrote: > >>>>>> On Fri, Aug 25, 2017 at 6:47 AM, Yang, Wenyou wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> This patch set has been here for a long time, could you have a look and take > >>>>>>> it? > >>>>>> > >>>>>> Yeah, I'm holding this because of my current spi-nor work. But anyway > >>>>>> I will try to merge on coming MW If all OK. > >>>>> > >>>>> Is your work posted somewhere or available in some git repository ? > >>> > >>> You did not answer this question. > >>> > >>>>> I don't see any reason why you should not perform your maintainer duties > >>>>> by reviewing/replying to an incoming patch, no matter what work you do > >>>>> to the subsystem though ... > >>>> > >>>> I didn't write "this series holding spi-nor work" since it has some > >>>> new features I'm taking time to review. > >>> > >>> I never implied this. Rather the opposite, you claim you do some work on > >>> the SPI NOR core, yet you let this patchset rot in the list for over a > >>> month now and gave the author zero feedback. > >>> > >>> Notifying the author about the core changes early could've prevented a > >>> lot of wasted effort on his side. Reviewing early could've prevented a > >>> lot of frustration from patches being ignored. > >>> > >>>> There is nothing wrong with > >>>> maintainer duties here, you must need to understand. > >>> > >>> I disagree. > >>> > >> > >> I agree with Marek here. I found it's really hard to get feedback for > >> SF patches in time and what I have to do is to ping again and again. > > > > I agree that the SF side patches have got some delay recently, but ie > > something not intentional. SF stack is not stable as of now, so I'm > > working on SPI-NOR (v10)[1] the new patches for SF need to wait - > > please be patient. > > What are the problems with the stack causing this instability ? > > How do you plan to stabilize the stack for the current release ? > > Given how complex and incomplete this patch(set) [1] is and that it's > already in v10, it seems it will take a while to get it into shape in > which it can be included in mainline. Blocking all other contributions > because of this patchset seems wrong and hurtful to the contributors to me. Yes. We cannot let a new framework block progress enabling things on our current framework. We are not at the point with spi-nor that we can say nothing else is allowed to move forward. Thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: