*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
: Andreas Werner
---
drivers/mcb/mcb-internal.h | 9
drivers/mcb/mcb-parse.c| 125 -
2 files changed, 120 insertions(+), 14 deletions(-)
diff --git a/drivers/mcb/mcb-internal.h b/drivers/mcb/mcb-internal.h
index 5254e02..d6e6933 100644
--- a
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
Add support for MCB bases FPGAs connected to the LPC or
non PCI Bus.
This driver currently supports the SC24 board. The FPGA
is connected to the LPC bus and is identified using the BIOS
DMI string.
Signed-off-by: Andreas Werner
---
drivers/mcb/Kconfig | 9 +++
drivers/mcb/Makefile | 1
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 fr
>> 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 check
otherwise 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
The num_cells variable is only used in the dev_dbg print,
but we can directly use the ret variable which also includes the same
value.
Signed-off-by: Andreas Werner
---
drivers/mcb/mcb-pci.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mcb/mcb-pci.c b/drivers
Replaced ioremap with devm_ioremap and request_mem_region with
devm_request_mem_region. This makes the code much more cleaner.
Signed-off-by: Andreas Werner
---
drivers/mcb/mcb-pci.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/mcb/mcb-pci.c b
The first patch replace the ioremap an request_mem_region function
with the corresponding devm function to have a more cleaner code
and a better error handling.
The sencoder patch just delete a unused variable.
Andreas Werner (2):
mcb: Replace ioremap and request_region with the devm version
The bar number is found in reg2 within the gdd. Therefore
we need to change the assigment from reg1 to reg2 which
is the correct location.
Signed-off-by: Andreas Werner
---
drivers/mcb/mcb-parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mcb/mcb-parse.c b
e tested this on the MEN SC24 with
a MCB FPGA.
Reviewed-by: Andreas Werner
Tested-by: Andreas Werner
on the MEN SC24 AMD Board
with a MCB FPGA.
Reviewed-by: Andreas Werner
Tested-by: Andreas Werner
On Tue, Apr 05, 2016 at 05:18:21PM +0530, Laxman Dewangan wrote:
> Use devm_mfd_add_devices() for mfd devices registration and get
> rid of .remove callback to remove mfd devices. This is done
> by managed device framework.
>
> Signed-off-by: Laxman Dewangan
> CC: Andreas Wer
The 16Z127 is a 32bit GPIO controller on a MCB FPGA.
Every single line can be configured as input and output.
Push pull and open drain are supported as well as setting
a debounce value for the input lines.
Signed-off-by: Andreas Werner
---
drivers/gpio/Kconfig| 7 ++
drivers/gpio
This patch adds the MEN 16Z127 GPIO Controller driver, which
is 32bit wide and located within a MCB FPGA.
changes in v2:
- ported driver to use the generic MMIO library
- added open drain support
- added debounce support
Andreas Werner (1):
gpio: add driver for MEN
Hi,
any comments for this patches?
Regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> 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 s
On Thu, Dec 17, 2015 at 06:57:51AM -0800, Guenter Roeck wrote:
> On Thu, Dec 17, 2015 at 12:48:08PM +0100, Jean Delvare wrote:
> > Hi Andreas,
> >
> > On Tue, 15 Dec 2015 16:11:24 +0100, Andreas Werner wrote:
> > > here is the register dump of the tmp461.
> &g
On Thu, Dec 17, 2015 at 12:48:08PM +0100, Jean Delvare wrote:
> Hi Andreas,
>
> On Tue, 15 Dec 2015 16:11:24 +0100, Andreas Werner wrote:
> > here is the register dump of the tmp461.
>
> Thanks.
>
> > It seemse that we really cannot detect if it is a tmp461 or a
Signed-off-by: Andreas Werner
---
.../ABI/testing/sysfs-bus-i2c-devices-menf21bmc| 26 ++
1 file changed, 26 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-menf21bmc
b/Documentation/ABI/testing/sysfs-bus-i2c-devices-menf21bmc
index 28d1fa2
This patch adds additional sysfs entries to provide status
information to the userland.
The following informations are now provided:
- Get operation hours counter
- Get board slot address
- Get powercycle counter
- Set/get Hw Variant
Signed-off-by: Andreas Werner
mechanism and add a sysfs interface to manually
exiting the production e.g. during the EOL test of the board.
Signed-off-by: Andreas Werner
---
drivers/mfd/menf21bmc.c | 65 +
1 file changed, 44 insertions(+), 21 deletions(-)
diff --git a/drive
This patch add the description of the "mode" sysfs interface
for the menf21bmc MFD driver.
Signed-off-by: Andreas Werner
---
Documentation/ABI/testing/sysfs-bus-i2c-devices-menf21bmc | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/ABI/testing
1 - 100 of 526 matches
Mail list logo
