Re: [PATCH 0/3] Detect suspicious indentation after conditional

*friendly ping* Hi Andy, Joe, Any comments on this patch series? Are you guys the right point of contact for checkpatch changes? On Thu, Mar 25, 2021 at 8:50 PM Julius Werner wrote: > > This patch series is adding functionality to checkpatch.pl to test for > incorrect code indentat

[PATCH 3/3] checkpatch: Ignore labels when checking indentation

. The SUSPICIOUS_CODE_INDENT test also needs to explicitly ignore labels to make sure it doesn't get confused by them. Signed-off-by: Julius Werner --- scripts/checkpatch.pl | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index

[PATCH 2/3] Suspicious indentation detection after conditional statement

From: Ivo Sieben Raise a SUSPICIOUS_CODE_INDENT warning when unexpected indentation is found after a conditional statement. This can be used to find missing braces or wrong indentation in/after a conditional statement. For example the following error is caught; if (foo)

[PATCH 1/3] checkpatch: ctx_statement_block: Fix preprocessor guard tracking

is to not try to restore any previous state (which we don't have) at all, so we should just keep our current state if $#stack is already 0. Signed-off-by: Julius Werner --- scripts/checkpatch.pl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/scripts/checkpatch.pl b/scripts

[PATCH 0/3] Detect suspicious indentation after conditional

): Suspicious indentation detection after conditional statement Julius Werner (2): checkpatch: ctx_statement_block: Fix preprocessor guard tracking checkpatch: Ignore labels when checking indentation scripts/checkpatch.pl | 56 +++ 1 file changed, 52

[PATCH] dt-bindings: ddr: Add optional manufacturer and revision ID to LPDDR3

. This patch adds optional properties for this information to the existing "jedec,lpddr3" device tree binding to be used for that purpose. Signed-off-by: Julius Werner --- Documentation/devicetree/bindings/ddr/lpddr3.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/

Re: [SPECIFICATION RFC] The firmware and bootloader log specification

Standardizing in-memory logging sounds like an interesting idea, especially with regards to components that can run on top of different firmware stacks (things like GRUB or TF-A). But I would be a bit wary of creating a "new standard to rule them all" and then expecting all projects to switch what

Re: [PATCH v4 1/2] firmware: google: Expose CBMEM over sysfs

> Ok. Regardless of the concern of the physical address is there any usage > of this attribute by userspace? The description makes it sound like it's > a pure debug feature, which implies that it should be in debugfs and not > in sysfs. I'll leave that up to Patrick. I doubt we'd want to create a

Re: [PATCH v4 1/2] firmware: google: Expose CBMEM over sysfs

> > +What: /sys/bus/coreboot/devices/.../cbmem_attributes/address > > +Date: Apr 2020 > > +KernelVersion: 5.6 > > +Contact: Patrick Rudolph > > +Description: > > + coreboot device directory can contain a file named > > + cbmem_attributes/address

Re: [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER

Reviewed-by: Julius Werner

Re: [PATCH v6 2/2] watchdog: Add new arm_smc_wdt watchdog driver

Reviewed-by: Julius Werner

Re: [PATCH v5 2/2] watchdog: Add new arm_smc_wdt watchdog driver

> I think I have misunderstood the device tree json-schema spec. > My intention was for the device tree to fill in a default value in the dtb for > arm,smc-id if it was omitted in the dts. But now I see that does not seem to > happen, I cannot really find any documentation of `default`, so I will

Re: [PATCH 2/2] firmware: coreboot: Export active CBFS partition

> I don't know why we need to draw a line in the sand and say that if the > kernel doesn't need to know about it then it shouldn't parse it. I want > there to be a consistent userspace ABI that doesn't just move things > straight from memory to userspace in some binary format. I'd rather we > have

Re: [PATCH 2/2] firmware: coreboot: Export active CBFS partition

> > I'll expose the coreboot tables using a sysfs driver, which then can be > > used by coreboot tools instead of accessing /dev/mem. As it holds the > > FMAP and "boot media params" that's all I need for now. > > > > The downside is that the userspace tools need to be keep in sync with > > the

Re: [PATCH 2/2] firmware: coreboot: Export active CBFS partition

> Somehow we've gotten /sys/firmware/log to be the coreboot log, and quite > frankly that blows my mind that this path was accepted upstream. > Userspace has to know it's running on coreboot firmware to know that > /sys/firmware/log is actually the coreboot log. Not really sure I understand your

Re: [PATCH] usb: storage: Add ums-cros-aoa driver

FWIW, I found a suitable workaround now to get my use case working with existing kernels: I can do the mode switch from userspace, then after the device reenumerates I can manually disable any interfaces I don't like by writing 0 to their 'authorized' node, and then I write the VID/PID to

Re: [PATCH] usb: storage: Add ums-cros-aoa driver

> USB drivers only bind to interfaces, are you saying that your device has > multiple interfaces on it? Yes, I have a case where the device has two interfaces which both have interface class 0xff (although they do differ in subclass and protocol). I only want the usb-storage driver to bind to one

Re: [PATCH] usb: storage: Add ums-cros-aoa driver

(Thanks for the reviews... I'll get back to the kernel code details after double-checking if this can be done from userspace.) > > Besides, what's wrong with binding to devices that weren't switched > > into AOA mode? Would that just provoke a bunch of unnecessary error > > messages? It's not

Re: [PATCH 0/5] Misc Google coreboot driver fixes/cleanups

er() macro and use it > firmware: google: memconsole: Use devm_memremap() > firmware: google: memconsole: Drop __iomem on memremap memory > firmware: google: memconsole: Drop global func pointer > firmware: google: coreboot: Drop unnecessary headers Thanks, these all look good to me. Reviewed-by: Julius Werner

Re: [PATCH v4 0/6] firmware: coreboot: Fix probe and simplify code

Thanks for all the clean-up, looks great now! For the whole series: Reviewed-by: Julius Werner

Re: [PATCH v4 0/6] firmware: coreboot: Fix probe and simplify code

Thanks for all the clean-up, looks great now! For the whole series: Reviewed-by: Julius Werner

Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive access

when "Driver has marked this resource busy". So after you make the change to the other patch where we immediately unmap the coreboot table again at the end of the probe() function, shouldn't it become available to userspace again even with IO_STRICT_DEVMEM set? On Thu, Aug 9, 2018 at 4:37

Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive access

when "Driver has marked this resource busy". So after you make the change to the other patch where we immediately unmap the coreboot table again at the end of the probe() function, shouldn't it become available to userspace again even with IO_STRICT_DEVMEM set? On Thu, Aug 9, 2018 at 4:37

Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive access

> Furthermore, I see that my system RAM excludes this coreboot table so it > doesn't fall into the bucket that CONFIG_STRICT_DEVMEM would find. Yes, that is intentional. We don't want the kernel to try to use that memory for anything else (since we want those tables to survive), so we mark them

Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive access

> Furthermore, I see that my system RAM excludes this coreboot table so it > doesn't fall into the bucket that CONFIG_STRICT_DEVMEM would find. Yes, that is intentional. We don't want the kernel to try to use that memory for anything else (since we want those tables to survive), so we mark them

Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive access

On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd wrote: > > Call request_mem_region() on the entire coreboot table to make sure > other devices don't attempt to map the coreboot table in their drivers. > If drivers need that support, it would be better to provide bus APIs > they can use to do that

Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive access

On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd wrote: > > Call request_mem_region() on the entire coreboot table to make sure > other devices don't attempt to map the coreboot table in their drivers. > If drivers need that support, it would be better to provide bus APIs > they can use to do that

Re: [PATCH v3 6/7] firmware: coreboot: Only populate devices in coreboot_table_init()

n be repurposed for pure device creation and registration. We > can devm()ify the memory mapping at the same time to keep error paths > simpler. > > Cc: Wei-Ning Huang > Cc: Julius Werner > Cc: Brian Norris > Cc: Samuel Holland > Suggested-by: Julius Werner > Signed-off-b

Re: [PATCH v3 6/7] firmware: coreboot: Only populate devices in coreboot_table_init()

n be repurposed for pure device creation and registration. We > can devm()ify the memory mapping at the same time to keep error paths > simpler. > > Cc: Wei-Ning Huang > Cc: Julius Werner > Cc: Brian Norris > Cc: Samuel Holland > Suggested-by: Julius Werner > Signed-off-b

Re: [PATCH v3 5/7] firmware: coreboot: Remap RAM with memremap() instead of ioremap()

need to copy > anything around anymore. > > Cc: Wei-Ning Huang > Cc: Julius Werner > Cc: Brian Norris > Cc: Samuel Holland > Signed-off-by: Stephen Boyd > --- > drivers/firmware/google/coreboot_table.c | 42 +++- > 1 file changed, 20 insertions

Re: [PATCH v3 5/7] firmware: coreboot: Remap RAM with memremap() instead of ioremap()

need to copy > anything around anymore. > > Cc: Wei-Ning Huang > Cc: Julius Werner > Cc: Brian Norris > Cc: Samuel Holland > Signed-off-by: Stephen Boyd > --- > drivers/firmware/google/coreboot_table.c | 42 +++- > 1 file changed, 20 insertions

Re: [PATCH v3 3/7] firmware: coreboot: Make bus registration symmetric

> @@ -138,8 +136,10 @@ int coreboot_table_init(struct device *dev, void __iomem > *ptr) > ptr_entry += entry.size; > } > > - if (ret) > + if (ret) { > + bus_unregister(_bus_type); > iounmap(ptr); > + } nit: maybe cleaner to

Re: [PATCH v3 3/7] firmware: coreboot: Make bus registration symmetric

> @@ -138,8 +136,10 @@ int coreboot_table_init(struct device *dev, void __iomem > *ptr) > ptr_entry += entry.size; > } > > - if (ret) > + if (ret) { > + bus_unregister(_bus_type); > iounmap(ptr); > + } nit: maybe cleaner to

Re: [PATCH v2 2/2] firmware: coreboot: Collapse platform drivers into bus core

> +config GOOGLE_COREBOOT_TABLE_ACPI > + tristate > + default GOOGLE_COREBOOT_TABLE I don't think this helps in upgrading (as your commit message says) unless you also keep the 'select GOOGLE_COREBOOT_TABLE' here, right? > -int coreboot_table_init(struct device *dev, void __iomem

Re: [PATCH v2 2/2] firmware: coreboot: Collapse platform drivers into bus core

> +config GOOGLE_COREBOOT_TABLE_ACPI > + tristate > + default GOOGLE_COREBOOT_TABLE I don't think this helps in upgrading (as your commit message says) unless you also keep the 'select GOOGLE_COREBOOT_TABLE' here, right? > -int coreboot_table_init(struct device *dev, void __iomem

Re: [PATCH] firmware: coreboot: Let OF core populate platform device

Thanks for the quick fix! Reviewed-by: Julius Werner

Re: [PATCH] firmware: coreboot: Let OF core populate platform device

Thanks for the quick fix! Reviewed-by: Julius Werner

Re: [PATCH v2] firmware: Update Kconfig help text for Google firmware

LGTM Reviewed-by: Julius Werner On Mon, Jun 18, 2018 at 3:55 PM Ben Hutchings wrote: > > The help text for GOOGLE_FIRMWARE states that it should only be > enabled when building a kernel for Google's own servers. However, > many of the drivers dependent on it are also useful on

Re: [PATCH v2] firmware: Update Kconfig help text for Google firmware

LGTM Reviewed-by: Julius Werner On Mon, Jun 18, 2018 at 3:55 PM Ben Hutchings wrote: > > The help text for GOOGLE_FIRMWARE states that it should only be > enabled when building a kernel for Google's own servers. However, > many of the drivers dependent on it are also useful on

Re: [PATCH] firmware: Update Kconfig help text for Google firmware

On Sat, Jun 16, 2018 at 3:05 PM Ben Hutchings wrote: > > The help text for GOOGLE_FIRMWARE states that it should only be > enabled when building a kernel for Google's own servers. However, it > is now also a dependency for various Chromebook firmware drivers. > > Update the help text to reflect

Re: [PATCH] firmware: Update Kconfig help text for Google firmware

On Sat, Jun 16, 2018 at 3:05 PM Ben Hutchings wrote: > > The help text for GOOGLE_FIRMWARE states that it should only be > enabled when building a kernel for Google's own servers. However, it > is now also a dependency for various Chromebook firmware drivers. > > Update the help text to reflect

Re: [PATCH 0/5] coreboot table bus and framebuffer driver

[resend in plain text] > It would be great to get some of the google developers to ack these, as > this touches their code... From the coreboot point of view I guess we're fine with it since it claims to maintain all of the existing functionality. It's just changing the kernel-level plumbing

Re: [PATCH 0/5] coreboot table bus and framebuffer driver

[resend in plain text] > It would be great to get some of the google developers to ack these, as > this touches their code... From the coreboot point of view I guess we're fine with it since it claims to maintain all of the existing functionality. It's just changing the kernel-level plumbing

[PATCH] drivers: char: mem: Fix wraparound check to allow mappings up to the end

fixes it by checking the last mapped address (instead of the first address behind that) for overflow. Fixes: b299cde245 ("drivers: char: mem: Check for address space wraparound with mmap()") Cc: <sta...@vger.kernel.org> Reported-by: Nico Huber <nic...@gmx.de> Signed-off-b

[PATCH] drivers: char: mem: Fix wraparound check to allow mappings up to the end

fixes it by checking the last mapped address (instead of the first address behind that) for overflow. Fixes: b299cde245 ("drivers: char: mem: Check for address space wraparound with mmap()") Cc: Reported-by: Nico Huber Signed-off-by: Julius Werner --- drivers/char/mem.c | 2 +- 1 file

Re: [PATCH 7/8] firmware: vpd: remove platform driver

I'm not a kernel expert so maybe I don't understand this right, but... I think this might have been done this way to ensure that the driver can get initialized correctly regardless of probe ordering. coreboot_table_find() may fail with -EPROBE_DEFER if the coreboot_table driver and its dependent

Re: [PATCH 7/8] firmware: vpd: remove platform driver

I'm not a kernel expert so maybe I don't understand this right, but... I think this might have been done this way to ensure that the driver can get initialized correctly regardless of probe ordering. coreboot_table_find() may fail with -EPROBE_DEFER if the coreboot_table driver and its dependent

Re: [PATCH] firmware: google: memconsole: Prevent overrun attack on coreboot console

Sorry. Resent.

Re: [PATCH] firmware: google: memconsole: Prevent overrun attack on coreboot console

Sorry. Resent.

[PATCH v2] firmware: google: memconsole: Prevent overrun attack on coreboot console

be modified at runtime, but the driver's bounds checks make sure that it will never read outside the buffer. Fixes: a5061d028 ("firmware: google: memconsole: Adapt to new coreboot ring buffer format") Signed-off-by: Julius Werner <jwer...@chromium.org> --- drivers/firmware/g

[PATCH v2] firmware: google: memconsole: Prevent overrun attack on coreboot console

be modified at runtime, but the driver's bounds checks make sure that it will never read outside the buffer. Fixes: a5061d028 ("firmware: google: memconsole: Adapt to new coreboot ring buffer format") Signed-off-by: Julius Werner --- drivers/firmware/google/memconsole-coreboot.c | 9 ++

Re: [PATCH] firmware: google: memconsole: Prevent overrun attack on coreboot console

Fixes: a5061d028 ("firmware: google: memconsole: Adapt to new coreboot ring buffer format") On Sat, May 20, 2017 at 1:32 AM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Fri, May 19, 2017 at 02:44:38PM -0700, Julius Werner wrote: >> The recent coreb

Re: [PATCH] firmware: google: memconsole: Prevent overrun attack on coreboot console

Fixes: a5061d028 ("firmware: google: memconsole: Adapt to new coreboot ring buffer format") On Sat, May 20, 2017 at 1:32 AM, Greg Kroah-Hartman wrote: > On Fri, May 19, 2017 at 02:44:38PM -0700, Julius Werner wrote: >> The recent coreboot memory console update (firmware:

[PATCH] firmware: google: memconsole: Prevent overrun attack on coreboot console

be modified at runtime, but the driver's bounds checks make sure that it will never read outside the buffer. Signed-off-by: Julius Werner <jwer...@chromium.org> --- drivers/firmware/google/memconsole-coreboot.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/d

[PATCH] firmware: google: memconsole: Prevent overrun attack on coreboot console

be modified at runtime, but the driver's bounds checks make sure that it will never read outside the buffer. Signed-off-by: Julius Werner --- drivers/firmware/google/memconsole-coreboot.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/firmware/google/memconsole

[PATCH] drivers: char: mem: Check for address space wraparound with mmap()

). On the x86_64 architecture it will then cause a panic (from the BUG(start >= end) in arch/x86/mm/pat.c:reserve_memtype()). This patch adds an explicit check to make sure offset + size will not wrap around in the physical address type. Signed-off-by: Julius Werner <jwer...@chromium.org> ---

[PATCH] drivers: char: mem: Check for address space wraparound with mmap()

). On the x86_64 architecture it will then cause a panic (from the BUG(start >= end) in arch/x86/mm/pat.c:reserve_memtype()). This patch adds an explicit check to make sure offset + size will not wrap around in the physical address type. Signed-off-by: Julius Werner --- drivers/char/mem.c | 5 +

[PATCH 2/2] firmware: google: memconsole: Adapt to new coreboot ring buffer format

The upstream coreboot implementation of memconsole was enhanced from a single-boot console to a persistent ring buffer (https://review.coreboot.org/#/c/18301). This patch changes the kernel memconsole driver to be able to read the new format in all cases. Signed-off-by: Julius Werner <j

[PATCH 2/2] firmware: google: memconsole: Adapt to new coreboot ring buffer format

The upstream coreboot implementation of memconsole was enhanced from a single-boot console to a persistent ring buffer (https://review.coreboot.org/#/c/18301). This patch changes the kernel memconsole driver to be able to read the new format in all cases. Signed-off-by: Julius Werner

[PATCH 1/2] firmware: google: memconsole: Make memconsole interface more flexible

. Since the console log size is thus no longer static, this means that the /sys/firmware/log file has to become unseekable. Signed-off-by: Julius Werner <jwer...@chromium.org> --- drivers/firmware/google/memconsole-coreboot.c | 12 +--- drivers/firmware/google/memconsole-x86-legacy.

[PATCH v3 0/2] Memconsole changes for new coreboot format

). Julius Werner (2): firmware: google: memconsole: Make memconsole interface more flexible firmware: google: memconsole: Adapt to new coreboot ring buffer format drivers/firmware/google/memconsole-coreboot.c | 51 + drivers/firmware/google/memconsole-x86-legacy.c | 18

[PATCH 1/2] firmware: google: memconsole: Make memconsole interface more flexible

. Since the console log size is thus no longer static, this means that the /sys/firmware/log file has to become unseekable. Signed-off-by: Julius Werner --- drivers/firmware/google/memconsole-coreboot.c | 12 +--- drivers/firmware/google/memconsole-x86-legacy.c | 18

[PATCH v3 0/2] Memconsole changes for new coreboot format

). Julius Werner (2): firmware: google: memconsole: Make memconsole interface more flexible firmware: google: memconsole: Adapt to new coreboot ring buffer format drivers/firmware/google/memconsole-coreboot.c | 51 + drivers/firmware/google/memconsole-x86-legacy.c | 18

Re: [PATCH v2 2/3] firmware: google: memconsole: Escape unprintable characters

> Binary sysfs files are supposed to be "pass through" only, the kernel > should not be touching the data at all, it's up to userspace to do what > it wants to do with things. So don't escape anything at all, that's not > the kernel's job here. Okay, I'll drop this patch.

Re: [PATCH v2 2/3] firmware: google: memconsole: Escape unprintable characters

> Binary sysfs files are supposed to be "pass through" only, the kernel > should not be touching the data at all, it's up to userspace to do what > it wants to do with things. So don't escape anything at all, that's not > the kernel's job here. Okay, I'll drop this patch.

Re: [PATCH v2 2/3] firmware: google: memconsole: Escape unprintable characters

On Fri, Apr 28, 2017 at 10:37 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Fri, Apr 28, 2017 at 01:42:24PM -0700, Julius Werner wrote: >> Recent improvements in coreboot's memory console allow it to contain >> logs from more than one boot as long as the

Re: [PATCH v2 2/3] firmware: google: memconsole: Escape unprintable characters

On Fri, Apr 28, 2017 at 10:37 PM, Greg Kroah-Hartman wrote: > On Fri, Apr 28, 2017 at 01:42:24PM -0700, Julius Werner wrote: >> Recent improvements in coreboot's memory console allow it to contain >> logs from more than one boot as long as the information persists in >>

[PATCH v2 2/3] firmware: google: memconsole: Escape unprintable characters

/sys/firmware/rawlog node next to the existing /sys/firmware/log for use cases where it's desired to read the raw characters. Signed-off-by: Julius Werner <jwer...@chromium.org> --- drivers/firmware/google/memconsole.c | 32 +++- 1 file changed, 27 insertions

[PATCH v2 2/3] firmware: google: memconsole: Escape unprintable characters

/sys/firmware/rawlog node next to the existing /sys/firmware/log for use cases where it's desired to read the raw characters. Signed-off-by: Julius Werner --- drivers/firmware/google/memconsole.c | 32 +++- 1 file changed, 27 insertions(+), 5 deletions(-) diff --git

[PATCH v2 3/3] firmware: google: memconsole: Adapt to new coreboot ring buffer format

The upstream coreboot implementation of memconsole was enhanced from a single-boot console to a persistent ring buffer (https://review.coreboot.org/#/c/18301). This patch changes the kernel memconsole driver to be able to read the new format in all cases. Signed-off-by: Julius Werner <j

[PATCH v2 1/3] firmware: google: memconsole: Make memconsole interface more flexible

. Since the console log size is thus no longer static, this means that the /sys/firmware/log file has to become unseekable. Signed-off-by: Julius Werner <jwer...@chromium.org> --- drivers/firmware/google/memconsole-coreboot.c | 12 +--- drivers/firmware/google/memconsole-x86-legacy.

[PATCH v2 3/3] firmware: google: memconsole: Adapt to new coreboot ring buffer format

The upstream coreboot implementation of memconsole was enhanced from a single-boot console to a persistent ring buffer (https://review.coreboot.org/#/c/18301). This patch changes the kernel memconsole driver to be able to read the new format in all cases. Signed-off-by: Julius Werner

[PATCH v2 1/3] firmware: google: memconsole: Make memconsole interface more flexible

. Since the console log size is thus no longer static, this means that the /sys/firmware/log file has to become unseekable. Signed-off-by: Julius Werner --- drivers/firmware/google/memconsole-coreboot.c | 12 +--- drivers/firmware/google/memconsole-x86-legacy.c | 18

[PATCH v2 0/3] Memconsole changes for new coreboot format

). Julius Werner (3): firmware: google: memconsole: Make memconsole interface more flexible firmware: google: memconsole: Escape unprintable characters firmware: google: memconsole: Adapt to new coreboot ring buffer format drivers/firmware/google/memconsole-coreboot.c | 51

[PATCH v2 0/3] Memconsole changes for new coreboot format

). Julius Werner (3): firmware: google: memconsole: Make memconsole interface more flexible firmware: google: memconsole: Escape unprintable characters firmware: google: memconsole: Adapt to new coreboot ring buffer format drivers/firmware/google/memconsole-coreboot.c | 51

[PATCH] firmware: google: memconsole: Adapt to new coreboot ring buffer format

ore likely that bytes might get slightly corrupted (due to DRAM degradation during a reboot), and it's usually undesirable to get stray control characters in the console dump because a bit in a letter flipped. Signed-off-by: Julius Werner <jwer...@chromium.org> --- drivers/firmware/google/m

[PATCH] firmware: google: memconsole: Adapt to new coreboot ring buffer format

ore likely that bytes might get slightly corrupted (due to DRAM degradation during a reboot), and it's usually undesirable to get stray control characters in the console dump because a bit in a letter flipped. Signed-off-by: Julius Werner --- drivers/firmware/google/memconsole-coreboot.c |

Re: [PATCH 5/5] firmware: google memconsole: Add ARM/ARM64 support

> What exactly is the "memory console"? Is it a log that coreboot writes into? Yes. It contains log messages, like coreboot's equivalent of dmesg.

Re: [PATCH 5/5] firmware: google memconsole: Add ARM/ARM64 support

> What exactly is the "memory console"? Is it a log that coreboot writes into? Yes. It contains log messages, like coreboot's equivalent of dmesg.

Re: [PATCH 4/5] firmware: Add coreboot device tree binding documentation

...and again in plaintext, sorry about that. On Fri, Mar 24, 2017 at 12:32 PM, Julius Werner <jwer...@chromium.org> wrote: >> > Devicetree bindings should be in vendor,prefix format. This doesn't >> > represent every aspect of coreboot, so it needs a more descriptiv

Re: [PATCH 4/5] firmware: Add coreboot device tree binding documentation

...and again in plaintext, sorry about that. On Fri, Mar 24, 2017 at 12:32 PM, Julius Werner wrote: >> > Devicetree bindings should be in vendor,prefix format. This doesn't >> > represent every aspect of coreboot, so it needs a more descriptive >> > string. >>

[PATCH] clk: rockchip: Ignore frac divisor for PLL equivalence when it's unused

, we won't reinitialize the PLL in cases where there's absolutely no reason for that, which may avoid glitching child clocks that should better not be glitched (e.g. PWM regulators). Signed-off-by: Julius Werner <jwer...@chromium.org> --- drivers/clk/rockchip/clk-pll.c | 3 ++- 1 file chan

[PATCH] clk: rockchip: Ignore frac divisor for PLL equivalence when it's unused

, we won't reinitialize the PLL in cases where there's absolutely no reason for that, which may avoid glitching child clocks that should better not be glitched (e.g. PWM regulators). Signed-off-by: Julius Werner --- drivers/clk/rockchip/clk-pll.c | 3 ++- 1 file changed, 2 insertions(+), 1

Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak wrote: > On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote: >> Julius and I were looking at the code when we spotted the issue. >> >> As Julius said, "just pass a boot param", is not easy on certain >> machines, like phone.

Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak wrote: > On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote: >> Julius and I were looking at the code when we spotted the issue. >> >> As Julius said, "just pass a boot param", is not easy on certain >> machines, like phone. It is not user

Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

>> I guess "force_gpt" (and "gpt" on kernel command line) exists to force >> users to think and care about a reason why the device has unreadable >> (broken) primary GPT header. > > > Yes, from find_valid_gpt(): > > * If the Primary GPT header is not valid, the Alternate GPT header > * is not

Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

>> I guess "force_gpt" (and "gpt" on kernel command line) exists to force >> users to think and care about a reason why the device has unreadable >> (broken) primary GPT header. > > > Yes, from find_valid_gpt(): > > * If the Primary GPT header is not valid, the Alternate GPT header > * is not

[PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

be what happens next). Signed-off-by: Julius Werner <jwer...@chromium.org> --- block/partitions/efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/partitions/efi.c b/block/partitions/efi.c index 26cb624..0d4ca8e 100644 --- a/block/partitions/efi.c +++ b/block/

[PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

be what happens next). Signed-off-by: Julius Werner --- block/partitions/efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/partitions/efi.c b/block/partitions/efi.c index 26cb624..0d4ca8e 100644 --- a/block/partitions/efi.c +++ b/block/partitions/efi.c @@ -625,7

Re: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

> There's actually a real world case that's pretty common where we want > to work with dates before 2016. When I power cycle my device and it > totally loses battery, I notice that the firmware seems to start as: > > 2013-01-21 00:50:02 > > It's possible we could need to run for a while in this

Re: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

> There's actually a real world case that's pretty common where we want > to work with dates before 2016. When I power cycle my device and it > totally loses battery, I notice that the firmware seems to start as: > > 2013-01-21 00:50:02 > > It's possible we could need to run for a while in this

Re: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

Okay, wrote up and tested the anchor date version. I think once you get over the initial weirdness of the approach this one is really much cleaner and safer. I tested this with the older rtc_tm_to_time() API and only ported it over to rtc_tm_to_time64() for submission, since my 3.14 kernel didn't

[PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

nchor date) to be able to read and write correct timestamps from/to the RTC. Signed-off-by: Julius Werner --- drivers/rtc/rtc-rk808.c | 48 1 file changed, 44 insertions(+), 4 deletions(-) diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk8

Re: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

Okay, wrote up and tested the anchor date version. I think once you get over the initial weirdness of the approach this one is really much cleaner and safer. I tested this with the older rtc_tm_to_time() API and only ported it over to rtc_tm_to_time64() for submission, since my 3.14 kernel didn't

[PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

nchor date) to be able to read and write correct timestamps from/to the RTC. Signed-off-by: Julius Werner <jwer...@chromium.org> --- drivers/rtc/rtc-rk808.c | 48 1 file changed, 44 insertions(+), 4 deletions(-) diff --git a/drivers/rtc/rtc-r

Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st

> I'll try to review and evaluate both solution by the end of the week (no > guarantee though). To summarize, it's a pretty simple trade-off. Do you: a) try to detect every time the RTC deviated from the real-world time and correct it instantly? This can be done most of the time but there are

Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st

> I'll try to review and evaluate both solution by the end of the week (no > guarantee though). To summarize, it's a pretty simple trade-off. Do you: a) try to detect every time the RTC deviated from the real-world time and correct it instantly? This can be done most of the time but there are

Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st

> Thinking about all this: these's actually a totally different > alternative approach we could take if you wanted. It would fix S5 and > avoid all the anchor stuff, unless I'm crazy. > > Basically totally give up on the RTC time reflecting reality. Add a > "real time to rk808" and "rk808 time

Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st

> Thinking about all this: these's actually a totally different > alternative approach we could take if you wanted. It would fix S5 and > avoid all the anchor stuff, unless I'm crazy. > > Basically totally give up on the RTC time reflecting reality. Add a > "real time to rk808" and "rk808 time

[PATCH v2] RTC: RK808: Work around hardware bug on November 31st

point), we read out the (adjusted) alarm time beforehand and write it (newly adjusted) back afterwards. This way, system time and alarm time will always stay on the same calendar (as long as we're able to keep track of our anchor point, at least). Signed-off-by: Julius Werner --- drive

  1   2   3   4   5   >