* Re: [Intel-gfx] [PATCH 2/2] drm/i915: fix documentation build warnings
From: Mika Kuoppala @ 2019-06-05 12:35 UTC (permalink / raw)
To: Jani Nikula, intel-gfx; +Cc: jani.nikula, linux-doc
In-Reply-To: <20190605095657.23601-2-jani.nikula@intel.com>
Jani Nikula <jani.nikula@intel.com> writes:
> Just a straightforward bag of fixes for a clean htmldocs build.
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v4 1/2] fTPM: firmware TPM running in TEE
From: Sumit Garg @ 2019-06-05 11:09 UTC (permalink / raw)
To: Sasha Levin
Cc: peterhuewe, Jarkko Sakkinen, jgg, corbet,
Linux Kernel Mailing List, linux-doc, linux-integrity,
Microsoft Linux Kernel List, Thirupathaiah Annapureddy,
Bryan Kelly (CSI), tee-dev
In-Reply-To: <20190604200951.GB29739@sasha-vm>
On Wed, 5 Jun 2019 at 01:39, Sasha Levin <sashal@kernel.org> wrote:
>
> On Tue, Jun 04, 2019 at 11:45:52AM +0530, Sumit Garg wrote:
> >On Thu, 30 May 2019 at 20:58, Sasha Levin <sashal@kernel.org> wrote:
> >> + /* Open context with TEE driver */
> >> + pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
> >> + NULL);
> >> + if (IS_ERR(pvt_data->ctx)) {
> >> + dev_err(dev, "%s:tee_client_open_context failed\n", __func__);
> >
> >Is this well tested? I see this misleading error multiple times as
> >follows although TEE driver works pretty well.
>
> Yes, this was all functionally tested.
Can you share your build instructions and testing approach?
>
> Why is this error message misleading? I'd be happy to fix it.
IIUC, here you are trying to resolve dependency with OP-TEE driver
using "-EPROBE_DEFER". So user shouldn't be prompted with error
messages until OP-TEE driver comes up.
BTW, for me this OP-TEE driver dependency seems not to work, boot is
simply stuck waiting for device. Probably the reason being this fTPM
driver is a platform driver and OP-TEE NOT a platform driver.
>
> >Module built with "CONFIG_TCG_FTPM_TEE=y"
> >
> >[ 1.436878] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
> >[ 1.509471] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
> >[ 1.517268] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
> >[ 1.525596] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
>
> Does the TEE have the fTPM implementation and such? Could you provide
> details about your testing environment (hardware, fTPM verions, etc)?
>
I just did a sanity check on my arm64 machine (Developerbox), just
adding following DT node and enabled CONFIG_TCG_FTPM_TEE=y:
+ tpm@0 {
+ compatible = "microsoft,ftpm";
+ };
Basically with no fTPM TA, I expected the driver to fail during
"tee_client_open_session()" call with TA not found error and boot
should continue. But it fails during "tee_client_open_context()" which
opens a context with OP-TEE driver and has nothing to do with fTPM TA.
-Sumit
> --
> Thanks,
> Sasha
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/i915: Fix kernel-doc references to moved gem files
From: Mika Kuoppala @ 2019-06-05 10:29 UTC (permalink / raw)
To: Jani Nikula, intel-gfx; +Cc: linux-doc, jani.nikula, Chris Wilson
In-Reply-To: <20190605095657.23601-1-jani.nikula@intel.com>
Jani Nikula <jani.nikula@intel.com> writes:
> The error messages could be more descriptive, but fix these caused by
> file moves:
>
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
> ./drivers/gpu/drm/i915/i915_gem_shrinker.c' failed with return code 2
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> User command execution ./drivers/gpu/drm/i915/i915_gem_execbuffer.c'
> failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
> ./drivers/gpu/drm/i915/i915_gem_tiling.c' failed with return code 2
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> buffer object tiling ./drivers/gpu/drm/i915/i915_gem_tiling.c'
> failed with return code 1
>
> Fixes: 10be98a77c55 ("drm/i915: Move more GEM objects under gem/")
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
/o\
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> ---
> Documentation/gpu/i915.rst | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 6c75380b2928..f98ee95da90f 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -349,7 +349,7 @@ of buffer object caches. Shrinking is used to make main memory
> available. Note that this is mostly orthogonal to evicting buffer
> objects, which has the goal to make space in gpu virtual address spaces.
>
> -.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_shrinker.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> :internal:
>
> Batchbuffer Parsing
> @@ -373,7 +373,7 @@ Batchbuffer Pools
> User Batchbuffer Execution
> --------------------------
>
> -.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> :doc: User command execution
>
> Logical Rings, Logical Ring Contexts and Execlists
> @@ -382,9 +382,6 @@ Logical Rings, Logical Ring Contexts and Execlists
> .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
> :doc: Logical Rings, Logical Ring Contexts and Execlists
>
> -.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
> - :internal:
> -
> Global GTT views
> ----------------
>
> @@ -415,10 +412,10 @@ Hardware Tiling and Swizzling Details
> Object Tiling IOCTLs
> --------------------
>
> -.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_tiling.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> :internal:
>
> -.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_tiling.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> :doc: buffer object tiling
>
> WOPCM
> --
> 2.20.1
^ permalink raw reply
* Re: [PATCH v2 15/22] docs: security: core.rst: Fix several warnings
From: Mauro Carvalho Chehab @ 2019-06-05 10:19 UTC (permalink / raw)
To: David Howells
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, keyrings
In-Reply-To: <26617.1559728436@warthog.procyon.org.uk>
Em Wed, 05 Jun 2019 10:53:56 +0100
David Howells <dhowells@redhat.com> escreveu:
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > + * ``asym_eds_op`` and ``asym_verify_signature``::
> > +
> > + int (*asym_eds_op)(struct kernel_pkey_params *params,
> > + const void *in, void *out);
> > + int (*asym_verify_signature)(struct kernel_pkey_params *params,
> > + const void *in, const void *in2);
>
> That's redundant and shouldn't be necessary.
This should equally fix it:
* ::
int (*asym_eds_op)(struct kernel_pkey_params *params,
const void *in, void *out);
int (*asym_verify_signature)(struct kernel_pkey_params *params,
const void *in, const void *in2);
The thing is that we need to teach Sphinx somehow that it should not
try to interpret '*' (with is used there to identify bold/italy blocks)
Using a '::' seems better than escaping all asterisks with a backslash.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v2 15/22] docs: security: core.rst: Fix several warnings
From: David Howells @ 2019-06-05 9:53 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: dhowells, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, Jonathan Corbet, keyrings
In-Reply-To: <21350864823e07cc951e1dc7f0601baa09920ac4.1559656538.git.mchehab+samsung@kernel.org>
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> + * ``asym_eds_op`` and ``asym_verify_signature``::
> +
> + int (*asym_eds_op)(struct kernel_pkey_params *params,
> + const void *in, void *out);
> + int (*asym_verify_signature)(struct kernel_pkey_params *params,
> + const void *in, const void *in2);
That's redundant and shouldn't be necessary.
David
^ permalink raw reply
* [PATCH 2/2] drm/i915: fix documentation build warnings
From: Jani Nikula @ 2019-06-05 9:56 UTC (permalink / raw)
To: intel-gfx; +Cc: linux-doc, jani.nikula
In-Reply-To: <20190605095657.23601-1-jani.nikula@intel.com>
Just a straightforward bag of fixes for a clean htmldocs build.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
Documentation/gpu/i915.rst | 6 ------
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/i915_vma.h | 2 ++
drivers/gpu/drm/i915/intel_guc_fwif.h | 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 --
5 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index f98ee95da90f..300220c4b498 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -475,12 +475,6 @@ i915_context_create and i915_context_free
.. kernel-doc:: drivers/gpu/drm/i915/i915_trace.h
:doc: i915_context_create and i915_context_free tracepoints
-switch_mm
----------
-
-.. kernel-doc:: drivers/gpu/drm/i915/i915_trace.h
- :doc: switch_mm tracepoint
-
Perf
====
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 07e3f861a92e..b7c13d5deb15 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -153,7 +153,7 @@
* REG_FIELD_PREP() - Prepare a u32 bitfield value
* @__mask: shifted mask defining the field's length and position
* @__val: value to put in the field
-
+ *
* Local copy of FIELD_PREP() to generate an integer constant expression, force
* u32 and for consistency with REG_FIELD_GET(), REG_BIT() and REG_GENMASK().
*
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 2657c99fe187..bc15083bd479 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -40,6 +40,8 @@
enum i915_cache_level;
/**
+ * DOC: Virtual Memory Address
+ *
* A VMA represents a GEM BO that is bound into an address space. Therefore, a
* VMA's presence cannot be guaranteed before binding, or after unbinding the
* object into/from the address space.
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 3d1de288d96c..f55f3bc8524d 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -500,6 +500,8 @@ enum guc_log_buffer_type {
};
/**
+ * struct guc_log_buffer_state - GuC log buffer state
+ *
* Below state structure is used for coordination of retrieval of GuC firmware
* logs. Separate state is maintained for each log buffer type.
* read_ptr points to the location where i915 read last in log buffer and
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 3bdeea596ad5..af3c1ada1b2e 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -391,8 +391,6 @@ static intel_wakeref_t __intel_runtime_pm_get(struct drm_i915_private *i915,
* asynchronous PM management from display code) and ensures that it is powered
* up. Raw references are not considered during wakelock assert checks.
*
- * Returns:
- * True when the power domain is enabled, false otherwise.
* Any runtime pm reference obtained by this function must have a symmetric
* call to intel_runtime_pm_put_raw() to release the reference again.
*
--
2.20.1
^ permalink raw reply related
* [PATCH 1/2] Documentation/i915: Fix kernel-doc references to moved gem files
From: Jani Nikula @ 2019-06-05 9:56 UTC (permalink / raw)
To: intel-gfx; +Cc: linux-doc, jani.nikula, Chris Wilson, Mika Kuoppala
The error messages could be more descriptive, but fix these caused by
file moves:
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
./drivers/gpu/drm/i915/i915_gem_shrinker.c' failed with return code 2
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
User command execution ./drivers/gpu/drm/i915/i915_gem_execbuffer.c'
failed with return code 1
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
./drivers/gpu/drm/i915/i915_gem_tiling.c' failed with return code 2
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
buffer object tiling ./drivers/gpu/drm/i915/i915_gem_tiling.c'
failed with return code 1
Fixes: 10be98a77c55 ("drm/i915: Move more GEM objects under gem/")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
Documentation/gpu/i915.rst | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 6c75380b2928..f98ee95da90f 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -349,7 +349,7 @@ of buffer object caches. Shrinking is used to make main memory
available. Note that this is mostly orthogonal to evicting buffer
objects, which has the goal to make space in gpu virtual address spaces.
-.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_shrinker.c
+.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
:internal:
Batchbuffer Parsing
@@ -373,7 +373,7 @@ Batchbuffer Pools
User Batchbuffer Execution
--------------------------
-.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_execbuffer.c
+.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
:doc: User command execution
Logical Rings, Logical Ring Contexts and Execlists
@@ -382,9 +382,6 @@ Logical Rings, Logical Ring Contexts and Execlists
.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
:doc: Logical Rings, Logical Ring Contexts and Execlists
-.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
- :internal:
-
Global GTT views
----------------
@@ -415,10 +412,10 @@ Hardware Tiling and Swizzling Details
Object Tiling IOCTLs
--------------------
-.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_tiling.c
+.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c
:internal:
-.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_tiling.c
+.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c
:doc: buffer object tiling
WOPCM
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] Documentation/stackprotector: powerpc supports stack protector
From: Bhupesh Sharma @ 2019-06-05 9:41 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jonathan Corbet, linuxppc-dev, Arnd Bergmann, Bhupesh SHARMA,
Benjamin Herrenschmidt, Paul Mackerras, Linux Kernel Mailing List,
Linux Doc Mailing List
In-Reply-To: <87ef4eodwf.fsf@concordia.ellerman.id.au>
Hi Jonathan,
On Fri, May 31, 2019 at 8:44 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Jonathan Corbet <corbet@lwn.net> writes:
> > On Thu, 30 May 2019 18:37:46 +0530
> > Bhupesh Sharma <bhsharma@redhat.com> wrote:
> >
> >> > This should probably go via the documentation tree?
> >> >
> >> > Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> >>
> >> Thanks for the review Michael.
> >> I am ok with this going through the documentation tree as well.
> >
> > Works for me too, but I don't seem to find the actual patch anywhere I
> > look. Can you send me a copy?
>
> You can get it from lore:
>
> https://lore.kernel.org/linuxppc-dev/1559212177-7072-1-git-send-email-bhsharma@redhat.com/raw
>
> Or patchwork (automatically adds my ack):
>
> https://patchwork.ozlabs.org/patch/1107706/mbox/
>
> Or Bhupesh can send it to you :)
Please let me know if I should send out the patch again, this time
Cc'ing you and the doc-list.
Thanks,
Bhupesh
^ permalink raw reply
* Re: [PATCH v2 08/22] gpu: i915.rst: Fix references to renamed files
From: Jani Nikula @ 2019-06-05 9:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Joonas Lahtinen, Rodrigo Vivi, Maarten Lankhorst,
Maxime Ripard, Sean Paul, David Airlie, Daniel Vetter, intel-gfx,
dri-devel
In-Reply-To: <bd7dd29b9fb2101c954c8cfb2c3b4efc7d277045.1559656538.git.mchehab+samsung@kernel.org>
On Tue, 04 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2
>
> Fixes: 112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Thanks for the patch, I picked this via drm-intel because the commit
being fixed is not in Linus' tree yet.
BR,
Jani.
> ---
> Documentation/gpu/i915.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 055df45596c1..6c75380b2928 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -61,7 +61,7 @@ Intel GVT-g Host Support(vGPU device model)
> Workarounds
> -----------
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c
> :doc: Hardware workarounds
>
> Display Hardware Handling
> @@ -379,10 +379,10 @@ User Batchbuffer Execution
> Logical Rings, Logical Ring Contexts and Execlists
> --------------------------------------------------
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
> :doc: Logical Rings, Logical Ring Contexts and Execlists
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
> :internal:
>
> Global GTT views
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Lee Jones @ 2019-06-05 9:21 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Guenter Roeck, Ezequiel Garcia, Enric Balletbo i Serra,
linux-kernel, Gwendal Grignou, Guenter Roeck, Benson Leung,
kernel, Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190605084813.GA26984@kroah.com>
On Wed, 05 Jun 2019, Greg Kroah-Hartman wrote:
> On Wed, Jun 05, 2019 at 09:40:02AM +0100, Lee Jones wrote:
> > On Wed, 05 Jun 2019, Greg Kroah-Hartman wrote:
> >
> > > On Wed, Jun 05, 2019 at 07:48:39AM +0100, Lee Jones wrote:
> > > > On Tue, 04 Jun 2019, Greg Kroah-Hartman wrote:
> > > > > On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> > > > > > On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> > > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > > > > > > Hey Greg,
> > > > > > > >
> > > > > > > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > > > > > > + data->misc.name);
> > > > > > > > >
> > > > > > > > > No need to be noisy, if all goes well, your code should be quiet.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I sometimes wonder about this being noise or not, so I will slightly
> > > > > > > > hijack this thread for this discussion.
> > > > > > > >
> > > > > > > > >From a kernel developer point-of-view, or even from a platform
> > > > > > > > developer or user with a debugging hat point-of-view, having
> > > > > > > > a "device created" or "device registered" message is often very useful.
> > > > > > >
> > > > > > > For you, yes. For someone with 30000 devices attached to their system,
> > > > > > > it is not, and causes booting to take longer than it should be.
> > > >
> > > > Who has 30,000 devices attached to their systems?
> > >
> > > More than you might imagine.
> > >
> > > > I would argue that
> > > > in these special corner-cases, they should knock the log-level *down*
> > > > a notch. For the rest of us who run normal platforms, an extra second
> > > > of boot time renders a more forthcoming/useful system than if each of
> > > > our devices initialised silently.
> > > >
> > > > Personally I like to know what devices I have on my system, and the
> > > > kernel log is the first place I look. As far as I'm concerned, for
> > > > the most part, if it's not in the kernel log, I don't have it.
> > >
> > > Then you "do not have" lots of devices, as we have been removing these
> > > messages for a number of years now :)
> > >
> > > > "Oh wow, I didn't know I had XXX functionality on this platform."
> > > >
> > > > In my real job, I am currently enabling some newly released AArch64
> > > > based laptops for booting with ACPI. I must have wasted a day whilst
> > > > enabling some of the devices the system relies upon, just to find
> > > > out that 90% of them were actually probing semi-fine (at least probe()
> > > > was succeeding), just silently. *grumble*
> > >
> > > Yup, that's normal. If you want to see what devices are in the system,
> > > look in /sys/devices/ as that is what it is for, not the kernel log.
> >
> > My guess is that less than 1% of Linux users use /sys/devices in this
> > way. It's a very unfriendly interface. Besides, when enabling a new
> > platform, access to sysfs comes too far down the line to be useful in
> > the majority of cases.
>
> `lshw` is your friend :)
Provided you have a command line (with `lshw` installed) and a
working keyboard. ;)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Greg Kroah-Hartman @ 2019-06-05 8:48 UTC (permalink / raw)
To: Lee Jones
Cc: Guenter Roeck, Ezequiel Garcia, Enric Balletbo i Serra,
linux-kernel, Gwendal Grignou, Guenter Roeck, Benson Leung,
kernel, Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190605084002.GP4797@dell>
On Wed, Jun 05, 2019 at 09:40:02AM +0100, Lee Jones wrote:
> On Wed, 05 Jun 2019, Greg Kroah-Hartman wrote:
>
> > On Wed, Jun 05, 2019 at 07:48:39AM +0100, Lee Jones wrote:
> > > On Tue, 04 Jun 2019, Greg Kroah-Hartman wrote:
> > > > On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> > > > > On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > > > > > Hey Greg,
> > > > > > >
> > > > > > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > > > > > + data->misc.name);
> > > > > > > >
> > > > > > > > No need to be noisy, if all goes well, your code should be quiet.
> > > > > > > >
> > > > > > >
> > > > > > > I sometimes wonder about this being noise or not, so I will slightly
> > > > > > > hijack this thread for this discussion.
> > > > > > >
> > > > > > > >From a kernel developer point-of-view, or even from a platform
> > > > > > > developer or user with a debugging hat point-of-view, having
> > > > > > > a "device created" or "device registered" message is often very useful.
> > > > > >
> > > > > > For you, yes. For someone with 30000 devices attached to their system,
> > > > > > it is not, and causes booting to take longer than it should be.
> > >
> > > Who has 30,000 devices attached to their systems?
> >
> > More than you might imagine.
> >
> > > I would argue that
> > > in these special corner-cases, they should knock the log-level *down*
> > > a notch. For the rest of us who run normal platforms, an extra second
> > > of boot time renders a more forthcoming/useful system than if each of
> > > our devices initialised silently.
> > >
> > > Personally I like to know what devices I have on my system, and the
> > > kernel log is the first place I look. As far as I'm concerned, for
> > > the most part, if it's not in the kernel log, I don't have it.
> >
> > Then you "do not have" lots of devices, as we have been removing these
> > messages for a number of years now :)
> >
> > > "Oh wow, I didn't know I had XXX functionality on this platform."
> > >
> > > In my real job, I am currently enabling some newly released AArch64
> > > based laptops for booting with ACPI. I must have wasted a day whilst
> > > enabling some of the devices the system relies upon, just to find
> > > out that 90% of them were actually probing semi-fine (at least probe()
> > > was succeeding), just silently. *grumble*
> >
> > Yup, that's normal. If you want to see what devices are in the system,
> > look in /sys/devices/ as that is what it is for, not the kernel log.
>
> My guess is that less than 1% of Linux users use /sys/devices in this
> way. It's a very unfriendly interface. Besides, when enabling a new
> platform, access to sysfs comes too far down the line to be useful in
> the majority of cases.
`lshw` is your friend :)
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Lee Jones @ 2019-06-05 8:40 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Guenter Roeck, Ezequiel Garcia, Enric Balletbo i Serra,
linux-kernel, Gwendal Grignou, Guenter Roeck, Benson Leung,
kernel, Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190605080241.GC9693@kroah.com>
On Wed, 05 Jun 2019, Greg Kroah-Hartman wrote:
> On Wed, Jun 05, 2019 at 07:48:39AM +0100, Lee Jones wrote:
> > On Tue, 04 Jun 2019, Greg Kroah-Hartman wrote:
> > > On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> > > > On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > > > > Hey Greg,
> > > > > >
> > > > > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > > > > + data->misc.name);
> > > > > > >
> > > > > > > No need to be noisy, if all goes well, your code should be quiet.
> > > > > > >
> > > > > >
> > > > > > I sometimes wonder about this being noise or not, so I will slightly
> > > > > > hijack this thread for this discussion.
> > > > > >
> > > > > > >From a kernel developer point-of-view, or even from a platform
> > > > > > developer or user with a debugging hat point-of-view, having
> > > > > > a "device created" or "device registered" message is often very useful.
> > > > >
> > > > > For you, yes. For someone with 30000 devices attached to their system,
> > > > > it is not, and causes booting to take longer than it should be.
> >
> > Who has 30,000 devices attached to their systems?
>
> More than you might imagine.
>
> > I would argue that
> > in these special corner-cases, they should knock the log-level *down*
> > a notch. For the rest of us who run normal platforms, an extra second
> > of boot time renders a more forthcoming/useful system than if each of
> > our devices initialised silently.
> >
> > Personally I like to know what devices I have on my system, and the
> > kernel log is the first place I look. As far as I'm concerned, for
> > the most part, if it's not in the kernel log, I don't have it.
>
> Then you "do not have" lots of devices, as we have been removing these
> messages for a number of years now :)
>
> > "Oh wow, I didn't know I had XXX functionality on this platform."
> >
> > In my real job, I am currently enabling some newly released AArch64
> > based laptops for booting with ACPI. I must have wasted a day whilst
> > enabling some of the devices the system relies upon, just to find
> > out that 90% of them were actually probing semi-fine (at least probe()
> > was succeeding), just silently. *grumble*
>
> Yup, that's normal. If you want to see what devices are in the system,
> look in /sys/devices/ as that is what it is for, not the kernel log.
My guess is that less than 1% of Linux users use /sys/devices in this
way. It's a very unfriendly interface. Besides, when enabling a new
platform, access to sysfs comes too far down the line to be useful in
the majority of cases.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [dm-devel] [PATCH v12] dm: add support to directly boot to a mapped device
From: Zdenek Kabelac @ 2019-06-05 8:35 UTC (permalink / raw)
To: Stephen Boyd, Helen Koike, dm-devel
Cc: wad, keescook, snitzer, linux-doc, richard.weinberger,
linux-kernel, linux-lvm, enric.balletbo, kernel, agk
In-Reply-To: <5cf6c7e6.1c69fb81.e1551.8ac4@mx.google.com>
Dne 04. 06. 19 v 21:35 Stephen Boyd napsal(a):
> Quoting Helen Koike (2019-06-04 10:38:59)
>> On 6/3/19 8:02 PM, Stephen Boyd wrote:
>>>
>>> I'm trying to boot a mainline linux kernel on a chromeos device with dm
>>> verity and a USB stick but it's not working for me even with this patch.
>>> I've had to hack around two problems:
>>>
>>> 1) rootwait isn't considered
>>>
>>> 2) verity doesn't seem to accept UUID for <hash_dev> or <dev>
>>>
>>> For the first problem, it happens every boot for me because I'm trying
>>> to boot off of a USB stick and it's behind a hub that takes a few
>>> seconds to enumerate. If I hack up the code to call dm_init_init() after
>>> the 'rootdelay' cmdline parameter is used then I can make this work. It
>>> would be much nicer if the whole mechanism didn't use a late initcall
>>> though. If it used a hook from prepare_namespace() and then looped
>>> waiting for devices to create when rootwait was specified it would work.
>>
>> The patch was implemented with late initcall partially to be contained
>> in drivers/md/*, but to support rootwait, adding a hook from
>> prepare_namespace seems the way to go indeed.
>
> Alright, great.
>
>>
>>>
>>> The second problem is that in chromeos we have the bootloader fill out
>>> the UUID of the kernel partition (%U) and then we have another parameter
>>> that indicates the offset from that kernel partition to add to the
>>> kernel partition (typically 1, i.e. PARTNROFF=1) to find the root
>>> filesystem partition. The way verity seems to work here is that we need
>>> to specify a path like /dev/sda3 or the major:minor number of the device
Hi
As not a direct dm developer - isn't this going a bit too far ? -
This way you will need to soon move halve of the userspace functionality into
kernel space.
IMHO would be way more progressive to start using initramdisk and let
userspace resolve all the issue.
Clearly once you start to wait for some 'devices' to appear - then you will
need to way for CORRECT device as well - since sda,sdb... goes in random
order, so you would need to parse disk headers and so on.
What you are effectively doing at this moment is you are shifting/ballooning
'ramdisk' code into kernel image - just to be named a kernel.
So why it is so big deal to start to use ramdisk on ChromeOS?
That would have solved most of problems you have or you will have instantly.
Regards
Zdenek
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Greg Kroah-Hartman @ 2019-06-05 8:02 UTC (permalink / raw)
To: Lee Jones
Cc: Guenter Roeck, Ezequiel Garcia, Enric Balletbo i Serra,
linux-kernel, Gwendal Grignou, Guenter Roeck, Benson Leung,
kernel, Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190605064839.GH4797@dell>
On Wed, Jun 05, 2019 at 07:48:39AM +0100, Lee Jones wrote:
> On Tue, 04 Jun 2019, Greg Kroah-Hartman wrote:
> > On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> > > On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > > > Hey Greg,
> > > > >
> > > > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > > > + data->misc.name);
> > > > > >
> > > > > > No need to be noisy, if all goes well, your code should be quiet.
> > > > > >
> > > > >
> > > > > I sometimes wonder about this being noise or not, so I will slightly
> > > > > hijack this thread for this discussion.
> > > > >
> > > > > >From a kernel developer point-of-view, or even from a platform
> > > > > developer or user with a debugging hat point-of-view, having
> > > > > a "device created" or "device registered" message is often very useful.
> > > >
> > > > For you, yes. For someone with 30000 devices attached to their system,
> > > > it is not, and causes booting to take longer than it should be.
>
> Who has 30,000 devices attached to their systems?
More than you might imagine.
> I would argue that
> in these special corner-cases, they should knock the log-level *down*
> a notch. For the rest of us who run normal platforms, an extra second
> of boot time renders a more forthcoming/useful system than if each of
> our devices initialised silently.
>
> Personally I like to know what devices I have on my system, and the
> kernel log is the first place I look. As far as I'm concerned, for
> the most part, if it's not in the kernel log, I don't have it.
Then you "do not have" lots of devices, as we have been removing these
messages for a number of years now :)
> "Oh wow, I didn't know I had XXX functionality on this platform."
>
> In my real job, I am currently enabling some newly released AArch64
> based laptops for booting with ACPI. I must have wasted a day whilst
> enabling some of the devices the system relies upon, just to find
> out that 90% of them were actually probing semi-fine (at least probe()
> was succeeding), just silently. *grumble*
Yup, that's normal. If you want to see what devices are in the system,
look in /sys/devices/ as that is what it is for, not the kernel log.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 09/22] docs: zh_CN: avoid duplicate citation references
From: Alex Shi @ 2019-06-05 7:56 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet, Harry Wei
In-Reply-To: <caf96b7ac3c4a3db66b6d6d2651849d2a70e3e76.1559656538.git.mchehab+samsung@kernel.org>
On 2019/6/4 10:17 下午, Mauro Carvalho Chehab wrote:
> -内核是用C语言 [c-language]_ 编写的。更准确地说，内核通常是用 ``gcc`` [gcc]_
> -在 ``-std=gnu89`` [gcc-c-dialect-options]_ 下编译的：ISO C90的 GNU 方言（
> +内核是用C语言 :ref:`c-language <cn_c-language>` 编写的。更准确地说，内核通常是用 ``gcc`` :ref:`gcc <cn_gcc>`
It looks better to remove ``gcc`` here. otherwise 2 'gcc' words show here is weird.
> +在 ``-std=gnu89`` :ref:`gcc-c-dialect-options <cn_gcc-c-dialect-options>` 下编译的：ISO C90的 GNU 方言（
> 包括一些C99特性）
>
> -这种方言包含对语言 [gnu-extensions]_ 的许多扩展，当然，它们许多都在内核中使用。
> +这种方言包含对语言 :ref:`gnu-extensions <cn_gnu-extensions>` 的许多扩展，当然，它们许多都在内核中使用。
>
> -对于一些体系结构，有一些使用 ``clang`` [clang]_ 和 ``icc`` [icc]_ 编译内核
> +对于一些体系结构，有一些使用 ``clang`` :ref:`clang <cn_clang>` 和 ``icc`` :ref:`icc <cn_icc>` 编译内核
and remove ``clang``, ``icc`` too.
> 的支持，尽管在编写此文档时还没有完成，仍需要第三方补丁。
>
Thanks
Alex
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Lee Jones @ 2019-06-05 6:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Guenter Roeck, Ezequiel Garcia, Enric Balletbo i Serra,
linux-kernel, Gwendal Grignou, Guenter Roeck, Benson Leung,
kernel, Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190604185953.GA2061@kroah.com>
On Tue, 04 Jun 2019, Greg Kroah-Hartman wrote:
> On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> > On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > > Hey Greg,
> > > >
> > > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > > + data->misc.name);
> > > > >
> > > > > No need to be noisy, if all goes well, your code should be quiet.
> > > > >
> > > >
> > > > I sometimes wonder about this being noise or not, so I will slightly
> > > > hijack this thread for this discussion.
> > > >
> > > > >From a kernel developer point-of-view, or even from a platform
> > > > developer or user with a debugging hat point-of-view, having
> > > > a "device created" or "device registered" message is often very useful.
> > >
> > > For you, yes. For someone with 30000 devices attached to their system,
> > > it is not, and causes booting to take longer than it should be.
Who has 30,000 devices attached to their systems? I would argue that
in these special corner-cases, they should knock the log-level *down*
a notch. For the rest of us who run normal platforms, an extra second
of boot time renders a more forthcoming/useful system than if each of
our devices initialised silently.
Personally I like to know what devices I have on my system, and the
kernel log is the first place I look. As far as I'm concerned, for
the most part, if it's not in the kernel log, I don't have it.
"Oh wow, I didn't know I had XXX functionality on this platform."
In my real job, I am currently enabling some newly released AArch64
based laptops for booting with ACPI. I must have wasted a day whilst
enabling some of the devices the system relies upon, just to find
out that 90% of them were actually probing semi-fine (at least probe()
was succeeding), just silently. *grumble*
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 06/22] docs: mark orphan documents as such
From: Andrew Donnellan @ 2019-06-05 6:16 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
Frederic Barrat, Maxime Coquelin, Alexandre Torgue,
Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, Georgi Djakov, Matan Ziv-Av,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
linuxppc-dev, linux-stm32, linux-arm-kernel, dri-devel, linux-pm,
platform-driver-x86
In-Reply-To: <4afa83787acec906c383978dc01f286940e28616.1559656538.git.mchehab+samsung@kernel.org>
On 5/6/19 12:17 am, Mauro Carvalho Chehab wrote:
> Sphinx doesn't like orphan documents:
>
> Documentation/accelerators/ocxl.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/overview.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/stm32f429-overview.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/stm32f746-overview.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/stm32f769-overview.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/stm32h743-overview.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/stm32mp157-overview.rst: WARNING: document isn't included in any toctree
> Documentation/gpu/msm-crash-dump.rst: WARNING: document isn't included in any toctree
> Documentation/interconnect/interconnect.rst: WARNING: document isn't included in any toctree
> Documentation/laptops/lg-laptop.rst: WARNING: document isn't included in any toctree
> Documentation/powerpc/isa-versions.rst: WARNING: document isn't included in any toctree
> Documentation/virtual/kvm/amd-memory-encryption.rst: WARNING: document isn't included in any toctree
> Documentation/virtual/kvm/vcpu-requests.rst: WARNING: document isn't included in any toctree
>
> So, while they aren't on any toctree, add :orphan: to them, in order
> to silent this warning.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
ocxl:
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
We should find somewhere to put it...
> ---
> Documentation/accelerators/ocxl.rst | 2 ++
> Documentation/arm/stm32/overview.rst | 2 ++
> Documentation/arm/stm32/stm32f429-overview.rst | 2 ++
> Documentation/arm/stm32/stm32f746-overview.rst | 2 ++
> Documentation/arm/stm32/stm32f769-overview.rst | 2 ++
> Documentation/arm/stm32/stm32h743-overview.rst | 2 ++
> Documentation/arm/stm32/stm32mp157-overview.rst | 2 ++
> Documentation/gpu/msm-crash-dump.rst | 2 ++
> Documentation/interconnect/interconnect.rst | 2 ++
> Documentation/laptops/lg-laptop.rst | 2 ++
> Documentation/powerpc/isa-versions.rst | 2 ++
> 11 files changed, 22 insertions(+)
>
> diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst
> index 14cefc020e2d..b1cea19a90f5 100644
> --- a/Documentation/accelerators/ocxl.rst
> +++ b/Documentation/accelerators/ocxl.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> ========================================================
> OpenCAPI (Open Coherent Accelerator Processor Interface)
> ========================================================
> diff --git a/Documentation/arm/stm32/overview.rst b/Documentation/arm/stm32/overview.rst
> index 85cfc8410798..f7e734153860 100644
> --- a/Documentation/arm/stm32/overview.rst
> +++ b/Documentation/arm/stm32/overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> ========================
> STM32 ARM Linux Overview
> ========================
> diff --git a/Documentation/arm/stm32/stm32f429-overview.rst b/Documentation/arm/stm32/stm32f429-overview.rst
> index 18feda97f483..65bbb1c3b423 100644
> --- a/Documentation/arm/stm32/stm32f429-overview.rst
> +++ b/Documentation/arm/stm32/stm32f429-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> STM32F429 Overview
> ==================
>
> diff --git a/Documentation/arm/stm32/stm32f746-overview.rst b/Documentation/arm/stm32/stm32f746-overview.rst
> index b5f4b6ce7656..42d593085015 100644
> --- a/Documentation/arm/stm32/stm32f746-overview.rst
> +++ b/Documentation/arm/stm32/stm32f746-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> STM32F746 Overview
> ==================
>
> diff --git a/Documentation/arm/stm32/stm32f769-overview.rst b/Documentation/arm/stm32/stm32f769-overview.rst
> index 228656ced2fe..f6adac862b17 100644
> --- a/Documentation/arm/stm32/stm32f769-overview.rst
> +++ b/Documentation/arm/stm32/stm32f769-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> STM32F769 Overview
> ==================
>
> diff --git a/Documentation/arm/stm32/stm32h743-overview.rst b/Documentation/arm/stm32/stm32h743-overview.rst
> index 3458dc00095d..c525835e7473 100644
> --- a/Documentation/arm/stm32/stm32h743-overview.rst
> +++ b/Documentation/arm/stm32/stm32h743-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> STM32H743 Overview
> ==================
>
> diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst
> index 62e176d47ca7..2c52cd020601 100644
> --- a/Documentation/arm/stm32/stm32mp157-overview.rst
> +++ b/Documentation/arm/stm32/stm32mp157-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> STM32MP157 Overview
> ===================
>
> diff --git a/Documentation/gpu/msm-crash-dump.rst b/Documentation/gpu/msm-crash-dump.rst
> index 757cd257e0d8..240ef200f76c 100644
> --- a/Documentation/gpu/msm-crash-dump.rst
> +++ b/Documentation/gpu/msm-crash-dump.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> =====================
> MSM Crash Dump Format
> =====================
> diff --git a/Documentation/interconnect/interconnect.rst b/Documentation/interconnect/interconnect.rst
> index c3e004893796..56e331dab70e 100644
> --- a/Documentation/interconnect/interconnect.rst
> +++ b/Documentation/interconnect/interconnect.rst
> @@ -1,5 +1,7 @@
> .. SPDX-License-Identifier: GPL-2.0
>
> +:orphan:
> +
> =====================================
> GENERIC SYSTEM INTERCONNECT SUBSYSTEM
> =====================================
> diff --git a/Documentation/laptops/lg-laptop.rst b/Documentation/laptops/lg-laptop.rst
> index aa503ee9b3bc..f2c2ffe31101 100644
> --- a/Documentation/laptops/lg-laptop.rst
> +++ b/Documentation/laptops/lg-laptop.rst
> @@ -1,5 +1,7 @@
> .. SPDX-License-Identifier: GPL-2.0+
>
> +:orphan:
> +
> LG Gram laptop extra features
> =============================
>
> diff --git a/Documentation/powerpc/isa-versions.rst b/Documentation/powerpc/isa-versions.rst
> index 812e20cc898c..66c24140ebf1 100644
> --- a/Documentation/powerpc/isa-versions.rst
> +++ b/Documentation/powerpc/isa-versions.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> CPU to ISA Version Mapping
> ==========================
>
>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH 00/15] kbuild: refactor headers_install and support compile-test of UAPI headers
From: Masahiro Yamada @ 2019-06-05 2:37 UTC (permalink / raw)
To: Linux Kbuild mailing list
Cc: Song Liu, open list:DOCUMENTATION, Benjamin Herrenschmidt,
Palmer Dabbelt, Heiko Carstens, Alexei Starovoitov, David Howells,
Paul Mackerras, linux-riscv, Vincent Chen, Sam Ravnborg,
linux-s390, Vasily Gorbik, Daniel Borkmann, Jonathan Corbet,
Michael Ellerman, Helge Deller, Christian Borntraeger,
Yonghong Song, arcml, Albert Ou, Arnd Bergmann, Jani Nikula,
Greentime Hu, James E.J. Bottomley, Michal Marek, linux-parisc,
Vineet Gupta, Randy Dunlap, Linux Kernel Mailing List, Networking,
bpf, linuxppc-dev, Martin KaFai Lau
In-Reply-To: <20190604101409.2078-1-yamada.masahiro@socionext.com>
On Tue, Jun 4, 2019 at 7:15 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
>
> Multiple people have suggested to compile-test UAPI headers.
>
> Currently, Kbuild provides simple sanity checks by headers_check
> but they are not enough to catch bugs.
>
> The most recent patch I know is David Howells' work:
> https://patchwork.kernel.org/patch/10590203/
>
> I agree that we need better tests for UAPI headers,
> but I want to integrate it in a clean way.
>
> The idea that has been in my mind is to compile each header
> to make sure the selfcontainedness.
For convenience, I pushed this series at
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
uapi-header-test-v1
(13/15 was replaced with v2)
If you want to test it quickly, please check-out it, then
$ make -j8 allmodconfig usr/
(As I noted in the commit log, you need to use
a compiler that provides <stdlib.h>, <sys/time.h>, etc.)
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v2] Add a document on rebasing and merging
From: Theodore Ts'o @ 2019-06-05 1:54 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, LKML, Linus Torvalds, Geert Uytterhoeven,
David Rientjes
In-Reply-To: <20190604134835.16fc6bfa@lwn.net>
On Tue, Jun 04, 2019 at 01:48:35PM -0600, Jonathan Corbet wrote:
> +
> +Maintaining a subsystem, as a general rule, requires a familiarity with
> the +Git source-code management system. Git is a powerful tool with a lot
> of +features; as is often the case with such tools, there are right and
> wrong +ways to use those features. This document looks in particular at
> the use +of rebasing and merging. Maintainers often get in trouble when
> they use +those tools incorrectly, but avoiding problems is not actually
> all that +hard.
FYI, it looks like your patch somehow got hit by your text editor (or
MUA's) line wrapping...
> +
> + - Realize that the rebasing a patch series changes the environment in
> + which it was developed and, likely, invalidates much of the testing
> that
> + was done. A rebased patch series should, as a general rule, be treated
> + like new code and retested from the beginning.
Shouldn't "reparenting" be used in this paragraph?
I suppose if a patch is getting dropped or modified that can
invalidate some of the testing (although it really depends on the
nature of what's being dropped or modified). And if it's just adding
a Tested-by tag or a CVE number in the commit description, it's not
going to invalidate any testing.
As an aside, I wonder if git could pass down some kind of hint at "git
fetch" time that a particular branch is one that is subject to
frequent history rewriting, so it shouldn't be used as the basis for
further work (unless the developer is someone who is really good at
the "git rebase --onto ..." syntax).
> +Even in the absence of known conflicts, doing a test merge before sending
> a +pull request is a good idea. It may alert you to problems that you
> somehow +didn't see from linux-next and helps to understand exactly what
> you are +asking upstream to do.
Some maintainers will actually do a test merge and then run regression
tests on the result --- more than just a "it builds, ship it!" :-)
> +
> +Another reason for doing merges of upstream or another subsystem tree is
> to +resolve dependencies. These dependency issues do happen at times, and
> +sometimes a cross-merge with another tree is the best way to resolve them;
> +as always, in such situations, the merge commit should explain why the
> +merge has been done. Take a momehnt to do it right; people will read those
> +changelogs.
It might also be useful to mention it might be useful to put the
commits which are needed to solve the dependency problem on its own
separate branch, based off of something like -rc2, and then each of
the trees which need the prerequisite commits can merge in that
branch.
BTW, this is another example where, if we couldn't figure this out in
advance, I might consider it worthwhile to separate out prerequisite
patches, and reparent them on top of -rc2, so that other trees don't
have to do a cross-merge which pulls in half of some other subsystem's
branch. Rewriting history on one branch and reparenting the changes
so they are on their own branch might be a good tradeoff if it avoids
messy cross-merges on multiple other trees. It also avoids this
problem:
> .... If that subsystem tree fails to be pulled
> +upstream, whatever problems it had will block the merging of your tree as
> +well.
- Ted
^ permalink raw reply
* Re: [PATCH v4 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Brendan Higgins @ 2019-06-05 0:47 UTC (permalink / raw)
To: Stephen Boyd
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Luis Chamberlain, Peter Zijlstra, Rob Herring, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190517175841.F3396216FD@mail.kernel.org>
On Fri, May 17, 2019 at 10:58 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Brendan Higgins (2019-05-14 15:16:57)
> > diff --git a/kunit/kunit-stream.c b/kunit/kunit-stream.c
> > new file mode 100644
> > index 0000000000000..1884f1b550888
> > --- /dev/null
> > +++ b/kunit/kunit-stream.c
> > @@ -0,0 +1,152 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * C++ stream style string formatter and printer used in KUnit for outputting
> > + * KUnit messages.
> > + *
> > + * Copyright (C) 2019, Google LLC.
> > + * Author: Brendan Higgins <brendanhiggins@google.com>
> > + */
> > +
> > +#include <kunit/test.h>
> > +#include <kunit/kunit-stream.h>
> > +#include <kunit/string-stream.h>
> > +
> > +static const char *kunit_stream_get_level(struct kunit_stream *this)
> > +{
> > + unsigned long flags;
> > + const char *level;
> > +
> > + spin_lock_irqsave(&this->lock, flags);
> > + level = this->level;
> > + spin_unlock_irqrestore(&this->lock, flags);
> > +
> > + return level;
>
> Please remove this whole function and inline it to the one call-site.
>
> > +}
> > +
> > +void kunit_stream_set_level(struct kunit_stream *this, const char *level)
> > +{
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&this->lock, flags);
> > + this->level = level;
> > + spin_unlock_irqrestore(&this->lock, flags);
>
> I don't get the locking here. What are we protecting against? Are tests
> running in parallel using the same kunit_stream? If so, why is the level
> changeable in one call and then adding strings is done in a different
> function call? It would make sense to combine the level setting and
> string adding so that it's one atomic operation if it's truly a parallel
> operation, or remove the locking entirely.
I think you are right. I am not sure it makes sense for two separate
threads to share a kunit_stream; even if locked properly, it would end
up printing out corrupted text.
In anycase, I think it makes sense to decide the level when the stream
is allocated which would sidestep this issue entirely.
> > +}
> > +
> > +void kunit_stream_add(struct kunit_stream *this, const char *fmt, ...)
> > +{
> > + va_list args;
> > + struct string_stream *stream = this->internal_stream;
> > +
> > + va_start(args, fmt);
> > +
> > + if (string_stream_vadd(stream, fmt, args) < 0)
> > + kunit_err(this->test, "Failed to allocate fragment: %s\n", fmt);
> > +
> > + va_end(args);
> > +}
> > +
> > +void kunit_stream_append(struct kunit_stream *this,
> > + struct kunit_stream *other)
> > +{
> > + struct string_stream *other_stream = other->internal_stream;
> > + const char *other_content;
> > +
> > + other_content = string_stream_get_string(other_stream);
> > +
> > + if (!other_content) {
> > + kunit_err(this->test,
> > + "Failed to get string from second argument for appending.\n");
> > + return;
> > + }
> > +
> > + kunit_stream_add(this, other_content);
> > +}
> > +
> > +void kunit_stream_clear(struct kunit_stream *this)
> > +{
> > + string_stream_clear(this->internal_stream);
> > +}
> > +
> > +void kunit_stream_commit(struct kunit_stream *this)
>
> Should this be rather called kunit_stream_flush()?
So the intention is that the string in the buffer will not get printed
out until commit is called. In this way, you can build up a message
and then decide not to print it. This is useful when you are parsing
through a lot of data that would be useful in debugging a failing or
broken test, but are not yet sure if it is going to pass or not.
I think flush has the connotation, that you are just forcing the
buffer to get written out now, but that it will happen regardless
eventually, where commit has the correct connotation that you *must*
call it in order to write out the data stored in the buffer.
Seems as though I should probably add this distinction to the
kernel-doc comment.
> > +{
> > + struct string_stream *stream = this->internal_stream;
> > + struct string_stream_fragment *fragment;
> > + const char *level;
> > + char *buf;
> > +
> > + level = kunit_stream_get_level(this);
> > + if (!level) {
> > + kunit_err(this->test,
> > + "Stream was committed without a specified log level.\n");
>
> Drop the full-stop?
Whoops, nice catch. Will fix in next revision.
> > + level = KERN_ERR;
> > + kunit_stream_set_level(this, level);
> > + }
> > +
> > + buf = string_stream_get_string(stream);
> > + if (!buf) {
> > + kunit_err(this->test,
>
> Can you grow a local variable for 'this->test'? It's used many times.
Sure, will fix in next revision.
> Also, 'this' is not very kernel idiomatic. We usually name variables by
> their type instead of 'this' which is a keyword in other languages.
> Perhaps it could be named 'kstream'?
Seems reasonable. Will fix in next revision.
> > + "Could not allocate buffer, dumping stream:\n");
> > + list_for_each_entry(fragment, &stream->fragments, node) {
> > + kunit_err(this->test, fragment->fragment);
> > + }
> > + kunit_err(this->test, "\n");
> > + goto cleanup;
> > + }
> > +
> > + kunit_printk(level, this->test, buf);
> > + kfree(buf);
> > +
> > +cleanup:
> > + kunit_stream_clear(this);
> > +}
> > +
> > +static int kunit_stream_init(struct kunit_resource *res, void *context)
> > +{
> > + struct kunit *test = context;
> > + struct kunit_stream *stream;
> > +
> > + stream = kzalloc(sizeof(*stream), GFP_KERNEL);
>
> Of course, here it's called 'stream', so maybe it should be 'kstream'
> here too.
Will do.
>
> > + if (!stream)
> > + return -ENOMEM;
> > +
> > + res->allocation = stream;
> > + stream->test = test;
> > + spin_lock_init(&stream->lock);
> > + stream->internal_stream = new_string_stream();
>
> Can new_string_stream() be renamed to alloc_string_stream()? Sorry, I
> just see so much C++ isms in here it's hard to read from the kernel
> developer perspective.
No problem. WIll fix in next revision.
> > +
> > + if (!stream->internal_stream) {
>
> Nitpick: Please join this to the "allocation" event above instead of
> keeping it separated.
Yeah, that's a lot cleaner. Will do.
> > + kfree(stream);
> > + return -ENOMEM;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void kunit_stream_free(struct kunit_resource *res)
> > +{
> > + struct kunit_stream *stream = res->allocation;
> > +
> > + if (!string_stream_is_empty(stream->internal_stream)) {
> > + kunit_err(stream->test,
> > + "End of test case reached with uncommitted stream entries.\n");
> > + kunit_stream_commit(stream);
> > + }
> > +
> > + destroy_string_stream(stream->internal_stream);
> > + kfree(stream);
> > +}
> > +
> > +struct kunit_stream *kunit_new_stream(struct kunit *test)
> > +{
> > + struct kunit_resource *res;
> > +
> > + res = kunit_alloc_resource(test,
> > + kunit_stream_init,
> > + kunit_stream_free,
> > + test);
> > +
> > + if (res)
> > + return res->allocation;
> > + else
> > + return NULL;
>
> Don't have if (...) return ...; else return ..., just return instead of
> else.
Sorry. Will fix.
Thanks!
^ permalink raw reply
* Re: [PATCH v4 03/18] kunit: test: add string_stream a std::stream like string builder
From: Brendan Higgins @ 2019-06-05 0:19 UTC (permalink / raw)
To: Stephen Boyd
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Luis Chamberlain, Peter Zijlstra, Rob Herring, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190517174300.7949F20848@mail.kernel.org>
On Fri, May 17, 2019 at 10:43 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Brendan Higgins (2019-05-14 15:16:56)
> > A number of test features need to do pretty complicated string printing
> > where it may not be possible to rely on a single preallocated string
> > with parameters.
> >
> > So provide a library for constructing the string as you go similar to
> > C++'s std::string.
> >
> > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
>
> Is there any reason why we can't use the seqfile API for this? These
> both share a similar goal, formatting strings into a buffer to be read
> later. Maybe some new APIs would be needed to extract the buffer
> differently, but I hope we could share the code.
I can see why you are asking. It seems as though they are trying to do
*similar* things, and it seems possible that we might be able to
extract some common functionality out of seq_file that could replace
this; however, it looks like it would be require a significant
refactoring of seq_file to separate out the file system specific bits
from the more general stringbuilder functionality.
In my opinion, a refactoring like this makes no sense in this
patchset; it probably belongs in its own patchset (preferably as a
follow on). I also am not sure if the FS people would appreciate
indirection that serves them no benefit, but I can ask if you like.
> If it can't be used, can you please add the reasoning to the commit text
> here?
Will do.
Thanks!
^ permalink raw reply
* Re: [PATCH v4 02/18] kunit: test: add test resource management API
From: Brendan Higgins @ 2019-06-04 23:34 UTC (permalink / raw)
To: Stephen Boyd
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Luis Chamberlain, Peter Zijlstra, Rob Herring, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190517003847.0962F2082E@mail.kernel.org>
On Thu, May 16, 2019 at 5:38 PM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Brendan Higgins (2019-05-14 15:16:55)
> > diff --git a/kunit/test.c b/kunit/test.c
> > index 86f65ba2bcf92..a15e6f8c41582 100644
> > --- a/kunit/test.c
> > +++ b/kunit/test.c
> [..]
> > +
> > +void *kunit_kmalloc(struct kunit *test, size_t size, gfp_t gfp)
> > +{
> > + struct kunit_kmalloc_params params;
> > + struct kunit_resource *res;
> > +
> > + params.size = size;
> > + params.gfp = gfp;
> > +
> > + res = kunit_alloc_resource(test,
> > + kunit_kmalloc_init,
> > + kunit_kmalloc_free,
> > + ¶ms);
> > +
> > + if (res)
> > + return res->allocation;
> > + else
> > + return NULL;
>
> Can be written as
>
> if (res)
> return ....
> return
>
> and some static analysis tools prefer this.
Sounds reasonable, will fix in next revision.
> > +}
> > +
> > +void kunit_cleanup(struct kunit *test)
> > +{
> > + struct kunit_resource *resource, *resource_safe;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&test->lock, flags);
>
> Ah ok, test->lock is protecting everything now? Does it need to be a
> spinlock, or can it be a mutex?
No it needs to be a spin lock. There are some conceivable
circumstances where the test object can be accessed by code in which
it isn't safe to sleep.
> > + list_for_each_entry_safe(resource,
> > + resource_safe,
> > + &test->resources,
> > + node) {
> > + kunit_free_resource(test, resource);
> > + }
> > + spin_unlock_irqrestore(&test->lock, flags);
> > +}
> > +
^ permalink raw reply
* Re: [PATCH v2 11/22] docs: it: license-rules.rst: get rid of warnings
From: Federico Vaga @ 2019-06-04 21:53 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <6a7cfac6d9a2f14475c8b9baef0f55e4996b9210.1559656538.git.mchehab+samsung@kernel.org>
On Tuesday, June 4, 2019 4:17:45 PM CEST Mauro Carvalho Chehab wrote:
> There's a wrong identation on a code block, and it tries to use
> a reference that was not defined at the Italian translation.
>
> Documentation/translations/it_IT/process/license-rules.rst:329: WARNING:
> Literal block expected; none found.
> Documentation/translations/it_IT/process/license-rules.rst:332: WARNING:
> Unexpected indentation.
> Documentation/translations/it_IT/process/license-rules.rst:339: WARNING:
> Block quote ends without a blank line; unexpected unindent.
> Documentation/translations/it_IT/process/license-rules.rst:341: WARNING:
> Unexpected indentation.
> Documentation/translations/it_IT/process/license-rules.rst:305: WARNING:
> Unknown target name: "metatags".
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Reviewed-by: Federico Vaga <federico.vaga@vaga.pv.it>
> ---
> .../it_IT/process/license-rules.rst | 28 +++++++++----------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/translations/it_IT/process/license-rules.rst
> b/Documentation/translations/it_IT/process/license-rules.rst index
> f058e06996dc..4cd87a3a7bf9 100644
> --- a/Documentation/translations/it_IT/process/license-rules.rst
> +++ b/Documentation/translations/it_IT/process/license-rules.rst
> @@ -303,7 +303,7 @@ essere categorizzate in:
> LICENSES/dual
>
> I file in questa cartella contengono il testo completo della rispettiva
> - licenza e i suoi `Metatags`_. I nomi dei file sono identici agli
> + licenza e i suoi `Metatag`_. I nomi dei file sono identici agli
> identificatori di licenza SPDX che dovrebbero essere usati nei file
> sorgenti.
>
> @@ -326,19 +326,19 @@ essere categorizzate in:
>
> Esempio del formato del file::
>
> - Valid-License-Identifier: MPL-1.1
> - SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
> - Usage-Guide:
> - Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used
> for - dual-licensed files where the other license is GPL2 compatible. -
> If you end up using this it MUST be used together with a GPL2
> compatible - license using "OR".
> - To use the Mozilla Public License version 1.1 put the following SPDX
> - tag/value pair into a comment according to the placement guidelines in
> - the licensing rules documentation:
> - SPDX-License-Identifier: MPL-1.1
> - License-Text:
> - Full license text
> + Valid-License-Identifier: MPL-1.1
> + SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
> + Usage-Guide:
> + Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used
> for + dual-licensed files where the other license is GPL2 compatible.
> + If you end up using this it MUST be used together with a GPL2
> compatible + license using "OR".
> + To use the Mozilla Public License version 1.1 put the following SPDX
> + tag/value pair into a comment according to the placement guidelines
> in + the licensing rules documentation:
> + SPDX-License-Identifier: MPL-1.1
> + License-Text:
> + Full license text
^ permalink raw reply
* Re: [PATCH RFC] Rough draft document on merging and rebasing
From: Theodore Ts'o @ 2019-06-04 20:43 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Linus Torvalds, LKML, linux-doc
In-Reply-To: <20190604130837.24ea1d7b@lwn.net>
On Tue, Jun 04, 2019 at 01:08:37PM -0600, Jonathan Corbet wrote:
> On Sat, 1 Jun 2019 11:42:48 -0400
> "Theodore Ts'o" <tytso@mit.edu> wrote:
>
> > Finally, I'm bit concerned about anything which states absolutes,
> > because there are people who tend to be real stickler for the rules,
> > and if they see something stated in absolute terms, they fail to
> > understand that there are exceptions that are well understood, and in
> > use for years before the existence of the document which is trying to
> > codify best practices.
>
> Hence the "there are exceptions" text at the bottom of the document :)
>
> Anyway, I'll rework it to try to take your comments into account. Maybe
> we should consistently say "rebasing" for changing the parent commit of a
> patch set, and "history modification" for the other tricks...?
Those names sound good to me. Thanks!!
- Ted
^ permalink raw reply
* Re: [PATCH v4 1/2] fTPM: firmware TPM running in TEE
From: Sasha Levin @ 2019-06-04 20:09 UTC (permalink / raw)
To: Sumit Garg
Cc: peterhuewe, Jarkko Sakkinen, jgg, corbet,
Linux Kernel Mailing List, linux-doc, linux-integrity,
Microsoft Linux Kernel List, Thirupathaiah Annapureddy,
Bryan Kelly (CSI), tee-dev
In-Reply-To: <CAFA6WYM1NrghG9qxUhrm76kopvBx9nmCL9XnRs11ysb2Yr0+Qw@mail.gmail.com>
On Tue, Jun 04, 2019 at 11:45:52AM +0530, Sumit Garg wrote:
>On Thu, 30 May 2019 at 20:58, Sasha Levin <sashal@kernel.org> wrote:
>> + /* Open context with TEE driver */
>> + pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
>> + NULL);
>> + if (IS_ERR(pvt_data->ctx)) {
>> + dev_err(dev, "%s:tee_client_open_context failed\n", __func__);
>
>Is this well tested? I see this misleading error multiple times as
>follows although TEE driver works pretty well.
Yes, this was all functionally tested.
Why is this error message misleading? I'd be happy to fix it.
>Module built with "CONFIG_TCG_FTPM_TEE=y"
>
>[ 1.436878] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
>[ 1.509471] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
>[ 1.517268] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
>[ 1.525596] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
Does the TEE have the fTPM implementation and such? Could you provide
details about your testing environment (hardware, fTPM verions, etc)?
--
Thanks,
Sasha
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox