*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
. 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
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)
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
):
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
. 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/
resend patch)
Kind regards,
Werner Sembach
was inspired by the quirk for the Intel NUC 8 devices, but
it turned out that the NUC 10 uses another pin. This information was
acquired by black box testing likely pins.
Co-developed-by: Eckhart Mohr
Signed-off-by: Eckhart Mohr
Signed-off-by: Werner Sembach
Cc:
---
Forgot to add the "
> Thanks, now I could apply it.
Missed your reply: I have now sent it a third time using git send-email.
One change: I added Cc: stable this time.
> Could you resubmit the NUC10 patch as well? Takashi
Done.
Hope everything is correct now.
was inspired by the quirk for the Intel NUC 8 devices, but
it turned out that the NUC 10 uses another pin. This information was
acquired by black box testing likely pins.
Co-developed-by: Eckhart Mohr
Signed-off-by: Eckhart Mohr
Signed-off-by: Werner Sembach
Cc:
---
Resend of this patch
. The combo jack already works. The microphone-only jack does
not recognize when a device is pluged in without this patch.
Signed-off-by: Eckhart Mohr
Co-developed-by: Werner Sembach
Signed-off-by: Werner Sembach
Cc:
---
Third time's the charm, now using git send-email, I'm really sorry for the spam
. The combo jack already works. The microphone-only jack does
not recognize when a device is pluged in without this patch.
Signed-off-by: Eckhart Mohr
Co-developed-by: Werner Sembach
Signed-off-by: Werner Sembach
---
This is a resend of the patch because I missed that the editor I used to write
. The combo jack already works. The microphone-only jack does
not recognize when a device is pluged in without this patch.
Signed-off-by: Eckhart Mohr
Co-developed-by: Werner Sembach
Signed-off-by: Werner Sembach
---
Hi,
this is my first ever submitted kernel patch, feel free to criticise me if I
From: Werner Sembach
ALSA: hda/realtek: Add quirk for Intel NUC 10
This adds a new SND_PCI_QUIRK(...) and applies it to the Intel NUC 10
devices. This fixes the issue of the devices not having audio input and
output on the headset jack because the kernel does not recognize when
something
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
a
non-valid HID instead (something like as proposed by Andy).
I will clarify in the meantime when the next coreboot release will happen and
prevent this wrong ID from getting part of the release.
Werner
-Ursprüngliche Nachricht-
Von: Henning Schild
Gesendet: Mittwoch, 18. November
> 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
> > +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
dd_kprobe_event now continues even when
one of the multiple events fails. Each failure is now reported
individually. Since the function can only return one result to the
caller, the function returns now the last failure (or none, if
nothing fails).
Cc: linux-ker...@i4.cs.fau.de
Signed-off-by: Maximi
This patch fixes a "WARNING: Missing a blank line after declarations" issue
found by checkpatch.pl
Signed-off-by: Frank Werner-Krippendorf
---
security/keys/dh.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/security/keys/dh.c b/security/keys/dh.c
index c4c629bb1c03..5515f51e6
Fixes an error condition reported by checkpatch.pl which caused by
assigning a variable in an if condition in
wg_noise_handshake_consume_initiation().
Signed-off-by: Frank Werner-Krippendorf
---
drivers/net/wireguard/noise.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Reviewed-by: Julius Werner
Reviewed-by: Julius Werner
> 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
> 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
> > 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
> 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
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
> 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
(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
that it
should phase out.
Best regards
Werner
> [resending, rebased on top of today's net-next]
>
> The following changes since commit
> 7b3ed2a137b077bc0967352088b0adb6049eed20:
>
> Merge branch '100GbE' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
&
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
Thanks for all the clean-up, looks great now!
For the whole series:
Reviewed-by: Julius Werner
Thanks for all the clean-up, looks great now!
For the whole series:
Reviewed-by: Julius Werner
PM Julius Werner wrote:
>
> > 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 anythin
PM Julius Werner wrote:
>
> > 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 anythin
> 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
> 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
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
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
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
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
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
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
> @@ -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
> @@ -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
> +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
> +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
Thanks for the quick fix!
Reviewed-by: Julius Werner
Thanks for the quick fix!
Reviewed-by: Julius Werner
Removed 5 inline comments "/*volatile*/" rtl87x_event.h, to fix
a coding style issue "Statements should start on a tabstop"
detected by checkpatch.pl script.
Signed-off-by: Frank Werner-Krippendorf
---
drivers/staging/rtl8712/rtl871x_event.h | 10 +-
1 file changed
Removed 5 inline comments "/*volatile*/" rtl87x_event.h, to fix
a coding style issue "Statements should start on a tabstop"
detected by checkpatch.pl script.
Signed-off-by: Frank Werner-Krippendorf
---
drivers/staging/rtl8712/rtl871x_event.h | 10 +-
1 file changed
Fixed a coding style issue.
Signed-off-by: Frank Werner-Krippendorf
---
drivers/staging/rtl8712/rtl871x_event.h | 10 +-
drivers/staging/rtl8712/rtl871x_io.h | 2 +-
drivers/staging/rtl8712/rtl871x_pwrctrl.h | 10 +-
drivers/staging/rtl8712/rtl871x_xmit.h| 14
Fixed a coding style issue.
Signed-off-by: Frank Werner-Krippendorf
---
drivers/staging/rtl8712/rtl871x_event.h | 10 +-
drivers/staging/rtl8712/rtl871x_io.h | 2 +-
drivers/staging/rtl8712/rtl871x_pwrctrl.h | 10 +-
drivers/staging/rtl8712/rtl871x_xmit.h| 14
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
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
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
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
[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
[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
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
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
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
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
Sorry. Resent.
Sorry. Resent.
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
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 ++
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
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:
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
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
). 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>
---
). 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 +
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
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
. 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.
).
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
. 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
).
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
> 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.
> 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.
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
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
>>
/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
/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
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
. 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.
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
. 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
).
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
).
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
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
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 |
> 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.
> 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.
...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
...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.
>>
, 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
, 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
1 - 100 of 1003 matches
Mail list logo
