al stuff is
sorted out".
The relicensing is complete so this patch can be dropped entirely (everything is
now GPLv2+)
Regards,
Werner Sembach
Link:
https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427
Signed-off-by: Uw
Hi,
Am 15.11.24 um 19:50 schrieb Werner Sembach:
From: Uwe Kleine-König
TUXEDO has not yet relicensed a module for GPLv2+ as a reply from former
contributers the committed code under GPLv3+ is awaited.
Teach the module loader that this module is not GPLv2 compatible despite
the declaration
Hello Uwe,
Am 16.11.24 um 18:49 schrieb Uwe Kleine-König:
Hello,
On Thu, Nov 14, 2024 at 12:14:16PM +0100, Uwe Kleine-König wrote:
On 11/14/24 11:49, Werner Sembach wrote:
Am 14.11.24 um 11:31 schrieb Uwe Kleine-König:
the kernel modules provided by Tuxedo on
https://gitlab.com
The situation was less severe then I feared. I'm awaiting replys regarding
this:
https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/merge_requests/17
and this: https://github.com/tuxedocomputers/tuxedo-keyboard/pull/155 (via
mail as the GitHub repo is archived).
This is t
complete.
Signed-off-by: Uwe Kleine-König
[Remove relicensed modules and accusatory language]
Signed-off-by: Werner Sembach
---
kernel/module/main.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 905d7b60dd709..df2549352ca8a 100644
--- a
: Werner Sembach
---
kernel/module/main.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 49b9bca9de12f..905d7b60dd709 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2023,11 +2023,20
.
Signed-off-by: Werner Sembach
---
kernel/module/main.c | 24
1 file changed, 24 insertions(+)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 905d7b60dd709..5df995ff0a9d3 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2029,6 +2029,30
Hello,
Am 15.11.24 um 17:40 schrieb Uwe Kleine-König:
Hello Werner,
On Fri, Nov 15, 2024 at 02:03:27PM +0100, Werner Sembach wrote:
Am 15.11.24 um 13:58 schrieb Werner Sembach:
Following the meeting I wrote about yesterday, I now changed the license
of what we could change spontaniously to
Following the meeting I wrote about yesterday, I now changed the license
of what we could change spontaniously to prove good faith.
I still hope that the rest can be sorted out before anything gets merged.
We are working on it. A clear time window would still be helpfull.
At Uwe. I don't know how
: Werner Sembach
---
kernel/module/main.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 49b9bca9de12f..905d7b60dd709 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2023,11 +2023,20
Am 15.11.24 um 13:58 schrieb Werner Sembach:
Following the meeting I wrote about yesterday, I now changed the license
of what we could change spontaniously to prove good faith.
I still hope that the rest can be sorted out before anything gets merged.
We are working on it. A clear time window
.
Signed-off-by: Werner Sembach
---
kernel/module/main.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 905d7b60dd709..3f391183aaf97 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2029,6 +2029,29
Following the meeting I wrote about yesterday, I now changed the license
of what we could change spontaniously to prove good faith.
I still hope that the rest can be sorted out before anything gets merged.
We are working on it. A clear time window would still be helpfull.
At Uwe. I don't know how
: Werner Sembach
---
kernel/module/main.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 49b9bca9de12f..905d7b60dd709 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2023,11 +2023,20
.
Signed-off-by: Werner Sembach
---
kernel/module/main.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 905d7b60dd709..3f391183aaf97 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2029,6 +2029,29
Following the meeting I wrote about yesterday, I now changed the license
of what we could change spontaniously to prove good faith.
I still hope that the rest can be sorted out before anything gets merged.
We are working on it. A clear time window would still be helpfull.
At Uwe. I don't know how
: Werner Sembach
---
kernel/module/main.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 49b9bca9de12f..905d7b60dd709 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2023,11 +2023,20
Am 15.11.24 um 11:51 schrieb Uwe Kleine-König:
Hello Werner,
On Fri, Nov 15, 2024 at 10:40:56AM +0100, Werner Sembach wrote:
Then why does the proprietary NVIDIA driver exist?
Please don't use NVIDIA's behaviour as a blueprint for your actions.
INAL, but I would not recommend to d
Am 15.11.24 um 11:22 schrieb Greg KH:
On Fri, Nov 15, 2024 at 10:40:56AM +0100, Werner Sembach wrote:
Am 15.11.24 um 10:18 schrieb Greg KH:
On Fri, Nov 15, 2024 at 10:00:23AM +0100, Werner Sembach wrote:
I guess what I try to convince you and others is that we _are_ taking Open
Source
Am 15.11.24 um 10:18 schrieb Greg KH:
On Fri, Nov 15, 2024 at 10:00:23AM +0100, Werner Sembach wrote:
I guess what I try to convince you and others is that we _are_ taking Open
Source licenses seriously, but still there are mistakes to be made,
especially with complex projects like the Linux
Hello Uwe,
Am 15.11.24 um 08:29 schrieb Uwe Kleine-König:
Hello Werner,
On Fri, Nov 15, 2024 at 07:09:49AM +0100, Werner Sembach wrote:
Am 15.11.24 um 05:43 schrieb Greg KH:
On Thu, Nov 14, 2024 at 11:49:04AM +0100, Werner Sembach wrote:
Am 14.11.24 um 11:31 schrieb Uwe Kleine-König:
the
Hi,
Am 15.11.24 um 05:43 schrieb Greg KH:
On Thu, Nov 14, 2024 at 11:49:04AM +0100, Werner Sembach wrote:
Hello,
Am 14.11.24 um 11:31 schrieb Uwe Kleine-König:
Hello,
the kernel modules provided by Tuxedo on
https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers
are licensed
Hello,
Am 14.11.24 um 12:14 schrieb Uwe Kleine-König:
Hello,
On 11/14/24 11:49, Werner Sembach wrote:
Am 14.11.24 um 11:31 schrieb Uwe Kleine-König:
the kernel modules provided by Tuxedo on
https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers
are licensed under GPLv3 or
PL") on its own does not hint
at GPL v2, if one is not aware of the license definition table in the documentation.
It was and is never our intention to violate neither GPL v2 nor GPL v3 and we
are working on it.
Kind regards,
Werner Sembach
Best regards
Uwe
Uwe Kleine-König (2):
*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 indentatio
space. 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/chec
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)
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/sc
Sieben (1):
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 c
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/
so forgot that in my 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 with
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 fo
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 is
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
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
ace_boot_add_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-
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 a
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 j
> 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 bin
> 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 c
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-stora
> 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 ab
at 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/j
ot_driver() 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
18 at 4:37 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
> m
> 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 as
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 thr
an 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-
s the sparse warnings in this code and reduces the 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 ++
> @@ -138,8 +136,10 @@ int coreboot_table_init(struct device *dev, void __iomem
> *ptr)
> ptr_entry += entry.size;
> }
>
> - if (ret)
> + if (ret) {
> + bus_unregister(&coreboot_bus_type);
> iounmap(ptr);
> + }
nit: maybe cle
> +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 *ptr
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
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 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 t
[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 for
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 (c
Sorry. Resent.
ll 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-coreboo
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:
ll 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/
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
lized. 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
).
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.
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
>&g
by default. It also adds a new /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 insertio
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
lized. 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
).
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
---
drivers/firmware/google/memconsole-coreboot.
> 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 wrote:
>> > Devicetree bindings should be in vendor,prefix format. This doesn't
>> > represent every aspect of coreboot, so it needs a more descriptive
>> > string.
&g
mode. This way, 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 ch
On Thu, Aug 11, 2016 at 10:45:00AM +0200, Oliver Hartkopp wrote:
> On 08/11/2016 09:14 AM, Andreas Werner wrote:
> >On Wed, Aug 10, 2016 at 10:28:45PM +0200, Oliver Hartkopp wrote:
>
> >>Just check 'git grep IFF_ECHO'. Even grcan.c and janz-ican3.c have IFF_ECHO
On Wed, Aug 10, 2016 at 10:28:45PM +0200, Oliver Hartkopp wrote:
> Hi Andreas,
>
> On 08/09/2016 08:10 AM, Andreas Werner wrote:
> >On Mon, Aug 08, 2016 at 04:35:34PM +0200, Wolfgang Grandegger wrote:
>
> >>>>>>You specify here one echo_skb but
On Mon, Aug 08, 2016 at 08:23:55PM -0700, Benjamin Poirier wrote:
> On 2016/08/08 09:26, Andreas Werner wrote:
> [...]
> > > > +
> > > > + if (cf->can_dlc > 0)
> > > > + data[0] = be32_to_cpup((__be32 *)
On Mon, Aug 08, 2016 at 04:35:34PM +0200, Wolfgang Grandegger wrote:
> Am 08.08.2016 um 16:05 schrieb Andreas Werner:
> >On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote:
> >>Hello,
> >>
> >>Am 08.08.2016 um 13:39 schrieb Andreas Werner:
>
On Mon, Aug 08, 2016 at 03:06:33PM +0200, Kurt Van Dijck wrote:
>
> --- Original message ---
> > Date: Mon, 8 Aug 2016 14:28:39 +0200
> > From: Wolfgang Grandegger
> >
> [...]
> > >>>+
> > >>>+if (!(cf->can_id & CAN_RTR_FLAG)) {
> > >>>+writel(data[0], &cf_buf->data
On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote:
> Hello,
>
> Am 08.08.2016 um 13:39 schrieb Andreas Werner:
> >On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote:
> >>Hello Andreas,
> >>
> >>a first quick review..
On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote:
> Hello Andreas,
>
> a first quick review
>
> Am 26.07.2016 um 11:16 schrieb Andreas Werner:
> >This CAN Controller is found on MEN Chameleon FPGAs.
> >
> >The driver/device supports the C
On Sun, Aug 07, 2016 at 08:58:14PM -0700, Benjamin Poirier wrote:
> On 2016/07/26 11:16, Andreas Werner wrote:
> [...]
> > +
> > + /* Lock for CTL_BTR register access.
> > +* This register combines bittiming bits
> > +* and the operation mode bits.
> >
parameters to configure the
buffer level interrupt for RX/TX as well as a RX timeout
interrupt.
With this configuration options, the driver/device
provides flexibility for different types of usecases.
Signed-off-by: Andreas Werner
---
drivers/net/can/Kconfig| 10 +
drivers/net/can/Makefile
ides flexibility for different types of usecases.
>
> Signed-off-by: Andreas Werner
> ---
> drivers/net/can/Kconfig| 10 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/men_z192_can.c | 990
> +
> 3 files ch
1 - 100 of 550 matches
Mail list logo
