Why should we need pstore_block?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fast, there is already a sample for block device logger in driver
MTD (drivers/mtd/mtdoops.c).
2. Do not any equipment have b
To enable pmsg, just set pmsg_size when block device register blkzone.
Signed-off-by: liaoweixiong
---
fs/pstore/blkoops.c| 11 ++
fs/pstore/blkzone.c| 254 +
include/linux/pstore_blk.h | 1 +
3 files changed, 244 insertions(+), 22 d
blkoops is a sample for pstore/blk. It can only record oops, excluding
panics as no read/write apis for panic registered. It support settings
on Kconfg/device tree/module parameters. It can record oops log even
power failure if "PSTORE_BLKOOPS_PART_PATH" on Kconfig or
"partition-path" on dts or "pa
pstore_blk is similar to pstore_ram, but dump log to block devices
rather than persistent ram.
Why should we need pstore_blk?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fact, there is already a sample
The document, at Documentation/admin-guide/pstore-block.rst,
tells user how to use pstore_blk and the attentions about panic
read/write
Signed-off-by: liaoweixiong
---
Documentation/admin-guide/pstore-block.rst | 227 +
MAINTAINERS| 1
On 2019-01-18 08:17, Kees Cook wrote:
> On Mon, Jan 7, 2019 at 4:01 AM liaoweixiong
> wrote:
>>
>> To enable pmsg, just set pmsg_size when block device register blkzone.
>
> At first pass, this looks like a reasonable extension of blkzone. Is
> it possible to add console, ftrace, etc, too?
>
I
Resend this mail.
On 2019-01-18 08:17, Kees Cook wrote:
> On Mon, Jan 7, 2019 at 4:01 AM liaoweixiong
> wrote:
>>
>> To enable pmsg, just set pmsg_size when block device register blkzone.
>
> At first pass, this looks like a reasonable extension of blkzone. Is
> it possible to add console, ftrac
pstore_blk is similar to pstore_ram, but dump log to block devices
rather than persistent ram.
Why should we need pstore_blk?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fact, there is already a sample
Create DT binding document for blkoops.
Signed-off-by: liaoweixiong
---
.../devicetree/bindings/pstore-block/blkoops.txt | 32 ++
MAINTAINERS| 1 +
2 files changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindin
Why should we need pstore_block?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fast, there is already a sample for block device logger in driver
MTD (drivers/mtd/mtdoops.c).
2. Do not any equipment have b
blkoops is a sample for pstore/blk. It can only record oops, excluding
panics as no read/write apis for panic registered. It support settings
on Kconfg/device tree/module parameters. It can record oops log even
power failure if "PSTORE_BLKOOPS_PART_PATH" on Kconfig or
"partition-path" on dts or "pa
The document, at Documentation/admin-guide/pstore-block.rst,
tells user how to use pstore_blk and the attentions about panic
read/write
Signed-off-by: liaoweixiong
---
Documentation/admin-guide/pstore-block.rst | 227 +
MAINTAINERS| 1
To enable pmsg, just set pmsg_size when block device register blkzone.
Signed-off-by: liaoweixiong
---
fs/pstore/blkoops.c| 11 ++
fs/pstore/blkzone.c| 254 +
include/linux/pstore_blk.h | 1 +
3 files changed, 244 insertions(+), 22 d
On Wed, Dec 12, 2018 at 11:09 PM Paul Cercueil wrote:
>
> From: Maarten ter Huurne
>
> OST is the OS Timer, a 64-bit timer/counter with buffered reading.
>
> SoCs before the JZ4770 had (if any) a 32-bit OST; the JZ4770 and
> JZ4780 have a 64-bit OST.
>
> This driver will register both a clocksour
On 1/23/19 4:58 AM, Mathieu Malaterre wrote:
On Wed, Dec 12, 2018 at 11:09 PM Paul Cercueil wrote:
From: Maarten ter Huurne
OST is the OS Timer, a 64-bit timer/counter with buffered reading.
SoCs before the JZ4770 had (if any) a 32-bit OST; the JZ4770 and
JZ4780 have a 64-bit OST.
This dri
Hi Rob,
On Tue, Dec 11, 2018 at 9:24 PM Rob Herring wrote:
> This adds the build infrastructure for checking DT binding schema
> documents and validating dts files using the binding schema.
>
> Check DT binding schema documents:
> make dt_binding_check
>
> Build dts files and check using DT bindi
Hi,
Le mer. 23 janv. 2019 à 11:31, Guenter Roeck a
écrit :
On 1/23/19 4:58 AM, Mathieu Malaterre wrote:
On Wed, Dec 12, 2018 at 11:09 PM Paul Cercueil
wrote:
From: Maarten ter Huurne
OST is the OS Timer, a 64-bit timer/counter with buffered reading.
SoCs before the JZ4770 had (if any) a
(re-send, in plain text this time, sorry for those who got it twice)
Le mer. 23 janv. 2019 à 9:58, Mathieu Malaterre a
écrit :
On Wed, Dec 12, 2018 at 11:09 PM Paul Cercueil
wrote:
From: Maarten ter Huurne
OST is the OS Timer, a 64-bit timer/counter with buffered reading.
SoCs before
On Wed, Jan 23, 2019 at 02:25:53PM -0300, Paul Cercueil wrote:
> Hi,
>
> Le mer. 23 janv. 2019 à 11:31, Guenter Roeck a écrit :
> >On 1/23/19 4:58 AM, Mathieu Malaterre wrote:
> >>On Wed, Dec 12, 2018 at 11:09 PM Paul Cercueil
> >>wrote:
> >>>
> >>>From: Maarten ter Huurne
> >>>
> >>>OST is the
Hi,
On Wed, Jan 23, 2019 at 08:05:11PM +0800, liaoweixiong wrote:
> Why should we need pstore_block?
> 1. Most embedded intelligent equipment have no persistent ram, which
> increases costs. We perfer to cheaper solutions, like block devices.
> In fast, there is already a sample for block device l
Hi,
On Sat, Jan 19, 2019 at 04:53:48PM +0800, liaoweixiong wrote:
> On 2019-01-18 08:12, Kees Cook wrote:
> >> MTD (drivers/mtd/mtdoops.c).
> >
> > Would mtdoops get dropped in favor of pstore/blk, or do they not share
> > features?
>
> We can show them what pstore/blk do. I think they will be i
This patch translates in Italian the content of the following patch
7967656ffbfa coding-style: Clarify the expectations around bool
Signed-off-by: Federico Vaga
---
.../it_IT/process/coding-style.rst| 43 ---
1 file changed, 38 insertions(+), 5 deletions(-)
diff --g
On 1/22/19 2:39 PM, Joel Fernandes wrote:
[snip]
On Sun, Jan 20, 2019 at 06:49:56PM -0800, h...@zytor.com wrote:
[snip]
My point is that if we're going to actually solve a problem, we need to make it
so that the distro won't just disable it anyway, and it ought to be something
scalable; oth
On Wed, Jan 23, 2019 at 1:29 PM Karim Yaghmour
wrote:
> > By the way, we can easily write a script to just extract the .ko directly -
> > if the whole "load it as a module" thing bothers you. The kheaders.ko can
> > just be thought of as a tarball. There's already a script to extract
> > /proc/con
On Wed, Jan 23, 2019 at 02:37:47PM -0800, Daniel Colascione wrote:
> On Wed, Jan 23, 2019 at 1:29 PM Karim Yaghmour
> wrote:
[...]
> > Personally I advocated a more aggressive approach with Joel in private:
> > just put the darn headers straight into the kernel image, it's the
> > *only* artifact
On Thu, Jan 17, 2019 at 10:23 AM Masahiro Yamada
wrote:
>
> The symbol table in the final archive is unneeded; the linker does not
> require the symbol table after the --whole-archive option. Every object
> file in the archive is included in the link anyway.
>
> Pass thin archives from subdirector
26 matches
Mail list logo
