Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1067039imj; Thu, 14 Feb 2019 00:19:00 -0800 (PST) X-Google-Smtp-Source: AHgI3IaylD2mRvJHAOuslcgSGOQD6DWwTHLBF2f7FqZ/5OagUm1QitQHXPFdh2eI6pVZaY58dKI0 X-Received: by 2002:a17:902:7604:: with SMTP id k4mr1903749pll.232.1550132340735; Thu, 14 Feb 2019 00:19:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550132340; cv=none; d=google.com; s=arc-20160816; b=q/qJV6/bYzcWXRiw0hhud77yhjFlSLpL2Mh/Fi9JwVf1XhOdQO/B9XAQYDTRqwGYyW 6LVMdx0VXsnRkdUnI2/e9dxNlNYXoJn4imb9UpbKGVs5Kr3/sCgew1B7Prhf9PPVE+M4 Z/BNndS8bHZk31bdZkLwsjFKRPZKV0XNfpHxKDxTiNfNw8sIDp0LtlnoDJTHB5WwVk8n 4XkNd1UJJCcyZKU8iPdaVkrXQWM5JgnyB/UNj3pQFYzS64WpBXZDHc6tiE5lmnZSqJRG iu8PHhdNgAMbIsXKlApIf4/aYJQdbJAsFU6Ub0MxlfRDQRfBrw9FZ0D4x5XMwXz6X6Gs qN6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=yfCznGFREcrxLNI76rm1tMXq/HLPuJCy2G/N6gMlQVI=; b=ix52TCUFlIQtpuxV7PSdwmNMr++K+CH4smtgSz8CEueHchJ0mf7EQLWhhKzomzyI7K eBmK8tpXCQ2p2rCl10HpcaMWxXUWS3kUMM+/3B+2Rls0JOfn1xfTBpj8MDyAyOR2r909 CAbyFWtskqCQA/UhhOFUZ2uTzZLwaE05KEJjNEBIYlNkaeWbArUUd88lMqbUKdQ6ZPP0 xzi+DOb5MyKGKOGGapSgElJFYBzd78WPEkWCtYwnLQ03Q+xnxBoyINDh/xeMmew1OycR 7xXx1j08/+7ToYj9WYmj8pf/vfboCwMY1Ti52VP8u3VvNHKSM0P19U6eH1ich5bbwjGo IVXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=n+xQX9Ff; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j10si1767401pll.179.2019.02.14.00.18.45; Thu, 14 Feb 2019 00:19:00 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=default header.b=n+xQX9Ff; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394617AbfBMUa6 (ORCPT + 99 others); Wed, 13 Feb 2019 15:30:58 -0500 Received: from mail.kernel.org ([198.145.29.99]:42400 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730402AbfBMUa5 (ORCPT ); Wed, 13 Feb 2019 15:30:57 -0500 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1B3C9222D0; Wed, 13 Feb 2019 20:30:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1550089856; bh=xj1LZ+jnKZlswnp3WoAydmXdhhBSefw3dKE1DZhjRBs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=n+xQX9FfiwEwV439VYH9f5NPgMzunKjdEuqzVsKnesfSr2IiQn7t56pjBDUy16zh6 z+13APQuvwwiKxq2AouTlMh8dDvNW5viwJ936rOAWx3PpGh/dfBAEDsbiKcDheukRe WJUbD86EGOeUczEFifcoZB4ME59G2MJfTy1+3Nns= Received: by mail-qt1-f171.google.com with SMTP id v10so4247114qtp.8; Wed, 13 Feb 2019 12:30:56 -0800 (PST) X-Gm-Message-State: AHQUAuYDthoRIPTP3G0KtMwx0tXU8y5aEf9RCLjOjc8YdpqgihBc5K1E YAa+WaT/N4BJ+2qGoIAJdagBbQUUYqr9KJcWsw== X-Received: by 2002:a0c:ecc5:: with SMTP id o5mr17703qvq.106.1550089855282; Wed, 13 Feb 2019 12:30:55 -0800 (PST) MIME-Version: 1.0 References: <1548245116-6360-1-git-send-email-liaoweixiong@allwinnertech.com> <1548245116-6360-3-git-send-email-liaoweixiong@allwinnertech.com> <20190130160707.GA31844@bogus> In-Reply-To: From: Rob Herring Date: Wed, 13 Feb 2019 14:30:44 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v7 2/5] dt-bindings: pstore-block: new support for blkoops To: liaoweixiong Cc: Kees Cook , Anton Vorontsov , Colin Cross , Tony Luck , Jonathan Corbet , Mark Rutland , Mauro Carvalho Chehab , Greg Kroah-Hartman , "David S. Miller" , Andrew Morton , Nicolas Ferre , Arnd Bergmann , Linux Doc Mailing List , "linux-kernel@vger.kernel.org" , devicetree@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 13, 2019 at 7:51 AM liaoweixiong wrote: > > > On 2019-01-31 00:07, Rob Herring wrote:> On Wed, Jan 23, 2019 at > 08:05:13PM +0800, liaoweixiong wrote: > >> Create DT binding document for blkoops. > >> > >> Signed-off-by: liaoweixiong > >> --- > >> .../devicetree/bindings/pstore-block/blkoops.txt | 32 ++++++++++++++++++++++ > > > > /bindings/pstore/... > > > > I wouldn't call it blkoops either. I believe ramoops is called that to > > maintain compatibility keeping the same kernel module name that > > preceeded pstore. > > > > Fixed. > > In addition, I don't known whether should we move > ramreserved-memory/ooos.txt to /bindings/pstore. This is for maintainer > to decide, and do it on other patch. > > >> MAINTAINERS | 1 + > >> 2 files changed, 33 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/pstore-block/blkoops.txt > >> > >> diff --git a/Documentation/devicetree/bindings/pstore-block/blkoops.txt b/Documentation/devicetree/bindings/pstore-block/blkoops.txt > >> new file mode 100644 > >> index 0000000..a25835b > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/pstore-block/blkoops.txt > >> @@ -0,0 +1,32 @@ > >> +Blkoops oops logger > >> +=================== > >> + > >> +Blkoops provides a block partition for oops, excluding panics now, so they can > >> +be recovered after a reboot. > >> + > >> +Any space of block partition will be used for a circular buffer of oops records. > >> +These records have a configurable size, with a size of 0 indicating that they > >> +should be disabled. > >> + > >> +"partition-size" and at least one of "dmesg-size" or "pmsg-size" must be set > >> +non-zero, but are otherwise optional as listed below. > >> + > >> +Blkoops will take value from Kconfig if device tree do not set, but settings > >> +from module parameters can also overwrite them. > > > > That's all kernel details not relevant to the binidng. > > > > Deleted. > > >> + > >> +Required properties: > >> + > >> +- compatible: must be "blkoops". > >> + > >> +- partition-size: size in kbytes, must be a multiple of 4. > > > > This seems unnecessary given a partition has a known size. > > > > partition-size is necessary for psotre/blk. User should tell pstore/blk > how large space can it use. The partition table says how big a partition is. If you only want to use part of it, then make the partition smaller or use a file system. This is a solved problem, so we don't need a new way in DT to handle this. > >> +Optional properties: > >> + > >> +- partition-path: strings must begin with "/dev", tell blkoops which partition > >> + it can used. If it is not set, blkoops will drop all data when reboot. > > > > No. '/dev/...' is a Linux thing and doesn't belong in DT. > > > > You should define a partition UUID and/or label and the kernel can find > > the right partition to use. > > > > pstore/blk do general read/write by filp_open/kernel_read/kernel_write, > which need device path. > In addition, i have no idea how to use UUID and/or label to do general > read/write on kernel layer, can you give me a tip? The kernel can mount a filesystem by label or UUID though I think those are filesystem UUID and label, not partition UUID and label. But certainly bootloaders find the EFI system partition by UUID. Rob