Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp3725685ybi; Tue, 18 Jun 2019 05:40:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqwnGRCOL4w4jS4gndrneBYkNYv/MvsvnFRTFJgOuTNb1LDG73KTPxUmojg8DDQihvv2X5kc X-Received: by 2002:a63:894a:: with SMTP id v71mr2276575pgd.302.1560861606621; Tue, 18 Jun 2019 05:40:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560861606; cv=none; d=google.com; s=arc-20160816; b=KQH8rgOuIKOK1QPcuOfLH/yWYgyo8AI2ooxGZ7gSDMDFgrJ4cTfeZWgf/aK3Xh20wN vRvtE8VFy9ZDBqCz7e/FZcALasZFtKvWt55WM6I7wNx4R+3XRcVUI/o03blcIhi3j8ZH ddq3KUQmvu9kqU5HTH+H1+3HQh77lhsldE+iXGn6/tvSYOO4d8XghVyVsPvweWgREGgF UsYDL0KydWRpAFm1Po7yorEjzWtPoseFvfKWBioQeLdepK1HdbqojvxdH+0CvrFvPbNv QkdxYKJ/2a0Os7Uy13lL4GN4zUNYSNq/ue4m92qprBJBo6astXv6rkcWuLNKvnVrsGs7 yOCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=qS9dl2sLUzcZ09GVjTSlypdDZmYtSYmQ8/Uk8MSOG1Q=; b=SXsXblgJLitFQt+fEhbk9h9tjXw+GVYXmI82+mouAUqghTvmJAjXfE7FCF2p9DYDPV vAuJEiO6BpNXhqnpdVCf/HW3S28rR5jCiTjXr+N9aiAaIOhYM9L3egPgVwb1xXuLclCA 1JGz6xnwZSZ/wMB/pX/+pMf/Hy13b0F8zGxpuwTsuMtia2hTkn3DLwPPs6fhuD4jWc/h 9m7iS3MQs/TRXhzbMnipGwfpym6SsnblpnetBIGv8qDqrR+FdQFVT1BVCXekAoZ2l1v7 u08hnPkDaxJflYkZADXcu3XOWMQ34fGiFNeR4jNZe9eO39Rf28MVEdA/axAfdUTcKqes OyHw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d34si3059850pla.283.2019.06.18.05.39.51; Tue, 18 Jun 2019 05:40:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728572AbfFRMjk (ORCPT + 99 others); Tue, 18 Jun 2019 08:39:40 -0400 Received: from bilbo.ozlabs.org ([203.11.71.1]:44139 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725913AbfFRMjk (ORCPT ); Tue, 18 Jun 2019 08:39:40 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 45Snhl0Bsrz9sCJ; Tue, 18 Jun 2019 22:39:34 +1000 (AEST) From: Michael Ellerman To: Jonathan Corbet , Mauro Carvalho Chehab Cc: Linux Doc Mailing List , Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Linas Vepstas , Russell Currey , Sam Bobroff , Oliver O'Halloran , Bjorn Helgaas , Benjamin Herrenschmidt , Paul Mackerras , Frederic Barrat , Andrew Donnellan , "Manoj N. Kumar" , "Matthew R. Ochs" , Uma Krishnan , Qiang Zhao , Li Yang , Greg Kroah-Hartman , Jiri Slaby , linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-scsi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Andrew Donnellan Subject: Re: [PATCH v4 19/28] docs: powerpc: convert docs to ReST and rename to *.rst In-Reply-To: <20190614143635.3aff154d@lwn.net> References: <63560c1ee7174952e148a353840a17969fe0be2d.1560361364.git.mchehab+samsung@kernel.org> <20190614143635.3aff154d@lwn.net> Date: Tue, 18 Jun 2019 22:39:32 +1000 Message-ID: <87blyvoynv.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jonathan Corbet writes: > On Wed, 12 Jun 2019 14:52:55 -0300 > Mauro Carvalho Chehab wrote: > >> Convert docs to ReST and add them to the arch-specific >> book. >> >> The conversion here was trivial, as almost every file there >> was already using an elegant format close to ReST standard. >> >> The changes were mostly to mark literal blocks and add a few >> missing section title identifiers. >> >> One note with regards to "--": on Sphinx, this can't be used >> to identify a list, as it will format it badly. This can be >> used, however, to identify a long hyphen - and "---" is an >> even longer one. >> >> At its new index.rst, let's add a :orphan: while this is not linked to >> the main index.rst file, in order to avoid build warnings. >> >> Signed-off-by: Mauro Carvalho Chehab >> Acked-by: Andrew Donnellan # cxl > > This one fails to apply because ... > > [...] > >> diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst >> index 83db42092935..acc21ecca322 100644 >> --- a/Documentation/PCI/pci-error-recovery.rst >> +++ b/Documentation/PCI/pci-error-recovery.rst >> @@ -422,3 +422,24 @@ That is, the recovery API only requires that: >> - drivers/net/cxgb3 >> - drivers/net/s2io.c >> - drivers/net/qlge >> + >> +>>> As of this writing, there is a growing list of device drivers with >> +>>> patches implementing error recovery. Not all of these patches are in >> +>>> mainline yet. These may be used as "examples": >> +>>> >> +>>> drivers/scsi/ipr >> +>>> drivers/scsi/sym53c8xx_2 >> +>>> drivers/scsi/qla2xxx >> +>>> drivers/scsi/lpfc >> +>>> drivers/next/bnx2.c >> +>>> drivers/next/e100.c >> +>>> drivers/net/e1000 >> +>>> drivers/net/e1000e >> +>>> drivers/net/ixgb >> +>>> drivers/net/ixgbe >> +>>> drivers/net/cxgb3 >> +>>> drivers/net/s2io.c >> +>>> drivers/net/qlge > > ...of this, which has the look of a set of conflict markers that managed > to get committed...? I don't think so. There's some other uses of >>> in that file, eg about line 162: >>> The current powerpc implementation assumes that a device driver will >>> *not* schedule or semaphore in this routine; the current powerpc >>> implementation uses one kernel thread to notify all devices; >>> thus, if one device sleeps/schedules, all devices are affected. >>> Doing better requires complex multi-threaded logic in the error >>> recovery implementation (e.g. waiting for all notification threads >>> to "join" before proceeding with recovery.) This seems excessively >>> complex and not worth implementing. So it's just an odd choice of emphasis device I think. cheers