Hi!
> >> I have problems with getting CNMA to work, so I'm exploring other
> >> possibilities. Apparently ofono should be able to work without
> >> that.. but is it working properly?
> >>
> >> ofonod[5218]: < \r\n+CIEV: 1,3\r\n
> >> ofonod[5218]: < \r\n+CIEV: 1,4\r\n
> >> ofonod[5218]: <
Hi!
> >I have problems with getting CNMA to work, so I'm exploring other
> >possibilities. Apparently ofono should be able to work without
> >that.. but is it working properly?
> >
> >ofonod[5218]: < \r\n+CIEV: 1,3\r\n
> >ofonod[5218]: < \r\n+CIEV: 1,4\r\n
> >ofonod[5218]: < \r\n+CMTI: "ME",2\r\n
Hi!
> > There's something very wrong with /dev/ttyUSB4 in recent kernels:
> > unsolicited incoming data from the modem are getting lost; I believe
> > it means also SMS notifications, but it is very easy to reproduce with
> > incoming call notifications.
> >
> > They just don't come.
> >
> >
ns/droid.c b/plugins/droid.c
new file mode 100644
index ..4e048dbb
--- /dev/null
+++ b/plugins/droid.c
@@ -0,0 +1,226 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2008-2011 Intel Corporation. All rights reserved.
+ * Copyright (C) 2009 Collabora Ltd. All rights reserved.
/null
+++ b/plugins/droid.c
@@ -0,0 +1,226 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2008-2011 Intel Corporation. All rights reserved.
+ * Copyright (C) 2009 Collabora Ltd. All rights reserved.
+ * Copyright (C) 2020 Pavel Machek. All rights reserved.
+ *
+ * This program i
On Fri 2020-07-31 12:07:50, Pavel Machek wrote:
> Hi!
>
> I have problems with getting CNMA to work, so I'm exploring other
> possibilities. Apparently ofono should be able to work without
> that.. but is it working properly?
>
> ofonod[5218]: < \r\n+CIEV: 1,3\r\n
>
Hi!
I have problems with getting CNMA to work, so I'm exploring other
possibilities. Apparently ofono should be able to work without
that.. but is it working properly?
ofonod[5218]: < \r\n+CIEV: 1,3\r\n
ofonod[5218]: < \r\n+CIEV: 1,4\r\n
ofonod[5218]: < \r\n+CMTI: "ME",2\r\n
ofonod[5218]:
Hi!
> There's something very wrong with /dev/ttyUSB4 in recent kernels:
> unsolicited incoming data from the modem are getting lost; I believe
> it means also SMS notifications, but it is very easy to reproduce with
> incoming call notifications.
>
> They just don't come.
>
> But if you keep
Hi!
There's something very wrong with /dev/ttyUSB4 in recent kernels:
unsolicited incoming data from the modem are getting lost; I believe
it means also SMS notifications, but it is very easy to reproduce with
incoming call notifications.
They just don't come.
But if you keep pasting "AT" into
Hi!
> +CPUs starting from Icelake use Total Memory Encryption (TME) in the place of
> +MEE. TME throws away the Merkle tree, which means losing integrity and
> +anti-replay protection but also enables variable size memory pools for EPC.
> +Using this attack for benefit would require an interposer
On Mon 2020-07-27 16:03:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.135 release.
> There are 86 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On Fri 2020-07-10 17:52:03, Will Deacon wrote:
> When building with LTO, there is an increased risk of the compiler
> converting an address dependency headed by a READ_ONCE() invocation
> into a control dependency and consequently allowing for harmful
> reordering by the CPU.
>
> Ensure that such
Hi!
> + This driver can also be built as a module. The module will be called
> + npreal2 by setting M.
Odd wording...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
Hi!
> Modern Intel Mobile platforms support power limit4 (PL4), which is
> the SoC package level maximum power limit (in Watts). It can be used
> to preemptively limits potential SoC power to prevent power spikes
> from tripping the power adapter and battery over-current protection.
> This patch
Hi!
> > No, please make it a "is rust available" automatic config option. The
> > exact same way we already do the compiler versions and check for
> > various availability of compiler flags at config time.
>
> That sounds even better, and will definitely allow for more testing.
>
> We just need
Hi!
> The following patch set provides a different approach to /dev/random which is
> called
> Linux Random Number Generator (LRNG) to collect entropy within the Linux
> kernel. The
> main improvements compared to the existing /dev/random is to provide
> sufficient entropy
> during boot
On Fri 2020-07-10 17:52:03, Will Deacon wrote:
> When building with LTO, there is an increased risk of the compiler
> converting an address dependency headed by a READ_ONCE() invocation
> into a control dependency and consequently allowing for harmful
> reordering by the CPU.
>
> Ensure that such
_data'
>
> These errors happened when I2C=m and LEDS_LP55XX_COMMON=y, so
> prevent that from being possible.
>
> Signed-off-by: Randy Dunlap
> Cc: Jacek Anaszewski
> Cc: Pavel Machek
> Cc: Dan Murphy
> Cc: linux-l...@vger.kernel.org
> Cc: Milo Kim
> Cc: Mathi
Hi!
> From: Derek Basehore
>
> [ Upstream commit 966334dfc472bdfa67bed864842943b19755d192 ]
>
> This moves the wakeup increment for elan devices to the touch report.
> This prevents the drivers from incorrectly reporting a wakeup when the
> resume callback resets then device, which causes an
Hi!
> [ Upstream commit c463bb2a8f8d7d97aa414bf7714fc77e9d3b10df ]
>
> This event code represents the state of a removable cover of a device.
> Value 0 means that the cover is open or removed, value 1 means that the
> cover is closed.
This is only needed for N900 cover changes. I don't see them
Hi!
> From: Mikulas Patocka
>
> commit 5df96f2b9f58a5d2dc1f30fe7de75e197f2c25f2 upstream.
>
> Commit adc0daad366b62ca1bce3e2958a40b0b71a8b8b3 ("dm: report suspended
> device during destroy") broke integrity recalculation.
>
> The problem is dm_suspended() returns true not only during suspend,
Hi!
> + pwmleds {
> + compatible = "pwm-leds";
> +
> + blue {
> + label = "blue:status";
> + max-brightness = <248>;
> + pwms = < 0 5>;
> + };
> +
> + green {
> +
On Wed 2020-07-22 07:39:37, Christoph Hellwig wrote:
> As this monster seesm to come back again and again let me re-iterate
> my statement:
>
> I do not think Linux should support a broken standards extensions that
> creates a huge share state between the Linux initator and the target
> device
Hi!
> > Here's the updated set of these patches fixed up for Johan's and
> > Pavel's earlier comments.
> >
> > This series does the following:
> >
> > 1. Adds functions to n_gsm.c for serdev-ngsm.c driver to use
> >
> > 2. Adds a generic serdev-ngsm.c driver that brings up the TS 27.010
> >
Use common error code for unclean filesystem, and warn when
incosistency is detected.
Signed-off-by: Pavel Machek (CIP)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index adaba8e8b326..8e74c7b5b8d0 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1395,7 +1395,10 @@ static int
Document rfkill allocation.
Signed-off-by: Pavel Machek (CIP)
diff --git a/Documentation/admin-guide/devices.txt
b/Documentation/admin-guide/devices.txt
index 2a97aaec8b12..763fedd94d7d 100644
--- a/Documentation/admin-guide/devices.txt
+++ b/Documentation/admin-guide/devices.txt
@@ -375,8
Hi!
While debugging something else I noticed this:
[ 335.627838] mot-mdm6600-codec 4806a000.serial:modem:audio-codec@2:
command U3559AT+DTSE=,1 error +DTSE:ERROR
[ 335.772064] mot-mdm6600-codec 4806a000.serial:modem:audio-codec@2:
motmdm_voice_get_state: ciev=1,7,0
Hi!
> The commands fdisk(8), sfdisk(8), cfdisk(8), mkswap(8) and wipefs(8) now
> support block devices locking by flock(2) to better behave with udevd or other
> tools. Ffor more details see https://systemd.io/BLOCK_DEVICE_LOCKING/. This
There's typo "ffor", but I guess it is too late to fix
Hi!
> As can be seen this divides llu by llu in few warnings and error.
> At the time of sending i didn't realize it but this fails on 32 bit
> architectures.
>
> So i would like to ask how would you like this fixed ?
> Using macro or some other way ?
+#include
- gain_q23 =
Hi!
> > > My main issue though is whether one "hw-control" trigger should be
> > > registered via LED API and the specific mode should be chosen via
> > > another sysfs file as in this RFC, or whether each HW control mode
> > > should have its own trigger. The second solution would either result
Hi!
> +static const struct marvell_led_mode_info marvell_led_mode_info[] = {
> + { "link", { 0x0, -1, 0x0, -1, -1, -1, }, 0 },
> + { "link/act", { 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, }, 0 },
> + { "1Gbps/100Mbps/10Mbps", { 0x2, -1, -1,
Hi!
> Many PHYs support various HW control modes for LEDs connected directly
> to them.
>
> This code adds a new private LED trigger called phydev-hw-mode. When
> this trigger is enabled for a LED, the various HW control modes which
> the PHY supports for given LED can be get/set via hw_mode
On Fri 2020-07-24 15:12:33, Marek Behún wrote:
> On Fri, 24 Jul 2020 12:29:01 +0200
> Pavel Machek wrote:
>
> > In future, would you expect having software "1000/100/10/nolink"
> > triggers I could activate on my scrollock LED (or on GPIO controlled
> &g
Hi!
> Is this for phone, btw? If so, which one?
>
> Yes it is. And it's for many many phones actually. I have done this
> mainly for SONY phones (Xperia 10, 10 Plus, XA2, XA2 Plus, XA2 Ultra).
> All of them use these drivers for generating the PWM and controlling the LEDs.
>
> P.S resending
Hi!
> > Dalsi cech co hackuje LEDky?
>
> Nie. Slovak.
Vitej do klubu :-).
> > Bindings should go first, they may need to be converted to yml
> > (devicetree people will know).
>
> OK
I'm not 100% sure, please double check.
> > Can generic pwm driver be used here?
>
> I have not tried to do
Hi!
Dalsi cech co hackuje LEDky?
> This series brings QCOM pwm-lpg and tri-led drivers from 4.14 that is
> required to support pmic-connected notification LED.
> This comes straight from downstream and I'm ready for your comments.
Yeah, so...
Bindings should go first, they may need to be
Simplify error handling; we already know mwq is NULL.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
index 743ee7b4e63f..3def0c782c7f 100644
--- a/drivers/slimbus/qcom-ngd-ctrl.c
+++ b/drivers/slimbus/qcom-ngd-ctrl.c
@@ -1396,17
Based on what fails, function can return with nfs_sync_rwlock either
locked or unlocked. That can not be right.
Always return with lock unlocked on error.
Signed-off-by: Pavel Machek (CIP)
diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 751bc4dc7466..8e3a369086db 100644
--- a/fs
On Thu 2020-07-23 20:13:18, Marek Behún wrote:
> Hi,
>
> this is v2 of my RFC adding support for LEDs connected to Marvell PHYs.
>
> The LED subsystem patches are not contained:
> - the patch adding support for LED private triggers is already accepted
> in Pavel Machek's for-next tree.
> If
Hi!
> > I expect some of this should be moved into the phylib core. We don't
> > want each PHY inventing its own way to do this. The core should
> > provide a framework and the PHY driver fills in the gaps.
> >
> > Take a look at for example mscc_main.c and its LED information. It has
> > pretty
Fix typo in comment.
Signed-off-by: Pavel Machek (CIP)
diff --git a/kernel/signal.c b/kernel/signal.c
index ee22ec78fd6d..6f16f7c5d375 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -719,7 +719,7 @@ static int dequeue_synchronous_signal(kernel_siginfo_t
*info)
* Return
This is user API, but likely noone uses it...? Fix it before it
becomes problem.
Signed-off-by: Pavel Machek (CIP)
diff --git a/include/uapi/rdma/mlx5_user_ioctl_cmds.h
b/include/uapi/rdma/mlx5_user_ioctl_cmds.h
index 8e316ef896b5..2d889df38df6 100644
--- a/include/uapi/rdma
Fix non-existing constant in documentation.
Signed-off-by: Pavel Machek (CIP)
diff --git a/Documentation/input/uinput.rst b/Documentation/input/uinput.rst
index b8e90b6a126c..10c62e62a0a6 100644
--- a/Documentation/input/uinput.rst
+++ b/Documentation/input/uinput.rst
@@ -99,7 +99,7 @@ the sake
Typo "destoy" made me wonder if correct patch is wrong; fix it. No
functional change.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 4ed21dad6a8e..1bb55b9532c9 100644
--- a/drivers/net/wireless
Simplify oxnas_nand_probe.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/mtd/nand/raw/oxnas_nand.c
b/drivers/mtd/nand/raw/oxnas_nand.c
index 8d0d76ad319d..f44947043e5a 100644
--- a/drivers/mtd/nand/raw/oxnas_nand.c
+++ b/drivers/mtd/nand/raw/oxnas_nand.c
@@ -144,8 +144,7 @@ static int
Hi!
> > +{
> > + struct phy_device *phydev = to_phy_device(cdev->dev->parent);
> > + struct marvell_phy_led *led = to_marvell_phy_led(cdev);
> > + u8 val;
> > +
> > + /* don't do anything if HW control is enabled */
> > + if (check_trigger && cdev->trigger == _hw_led_trigger)
> > +
> This patch adds support for "default-state" devicetree property, which
> allows to defer pwm init to first use of led.
>
> This allows to configure the PWM early in bootloader to let the LED
> blink until an application in Linux userspace sets something different.
>
> Signed-off-by: Denis
On Wed 2020-07-22 08:33:37, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 347b711870ab ("leds: multicolor: Fix camel case in documentation")
>
> Fixes tag
>
> Fixes: f5a6eb5c5e38 ("leds: multicolor: Introduce a multicolor class
> definition")
Thanks, I squashed the commits together
_voltage_pre_transition’:
> drivers/cpufreq/powernow-k8.c:285:14: warning: variable ‘lo’ set but not
> used [-Wunused-but-set-variable]
> 285 | u32 maxvid, lo, rvomult = 1;
> | ^~
>
> Cc: Andreas Herrmann
> Cc: Dominik Brodowski
Acked-by: Pavel Machek
--
(english) http:/
Hi!
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^#
Hi!
> > > > > + ret = fwnode_property_read_u32_array(child,
> > > > > + "reg",
> > > > > + led_banks,
> > > > > +
Hi!
> From: Douglas Anderson
>
> [ Upstream commit 299632e54b2e692d2830af84be51172480dc1e26 ]
>
> + err = kstrtobool_from_user(user_buf, count, _val);
> + /* Ignore malforned data like debugfs_write_file_bool() */
> + err = kstrtobool_from_user(user_buf, count, _val);
> + /*
Hi!
> [ Upstream commit 679b2ec8e060ca7a90441aff5e7d384720a41b76 ]
>
> This kernel configuration is basically enabling/disabling sr driver quirks
> detection. While these quirks are for fairly rare devices (very old CD
> burners, and a glucometer), the additional detection of these models is a
>
Hi!
> From: Jonathan Cameron
>
> commit 5c49056ad9f3c786f7716da2dd47e4488fc6bd25 upstream.
>
> One of a class of bugs pointed out by Lars in a recent review.
> iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
> to the size of the timestamp (8 bytes). This is not
Hi!
> From: Dinghao Liu
>
> commit 0187294d227dfc42889e1da8f8ce1e44fc25f147 upstream.
>
> When devm_regmap_init_i2c() returns an error code, a pairing
> runtime PM usage counter decrement is needed to keep the
> counter balanced. For error paths after ak8974_set_power(),
> ak8974_detect() and
Hi!
> > > commit e7b931bee739e8a77ae216e613d3b99342b6dec0 upstream.
> > >
> > > The driver would happily overwrite its write buffer with user data in
> > > 256 byte increments due to a removed buffer-space sanity check.
> >
> > > +++ b/drivers/usb/serial/iuu_phoenix.c
> > > @@ -697,14 +697,16
Hi!
> > > commit 371a3bc79c11b707d7a1b7a2c938dc3cc042fffb upstream.
> > >
> > > The function cpu_power_to_freq is used to find a frequency and set the
> > > cooling device to consume at most the power to be converted. For example,
> > > if the power to be converted is 80mW, and the em table is
Hi!
> >>+ ret = fwnode_property_read_u32_array(child,
> >>+"reg",
> >>+led_banks,
> >>+ret);
> >Move this to
Hi!
> Add multicolor framework support for the lp55xx family.
>
> Acked-by: Pavel Machek
> Acked-by: Jacek Anaszewski
> Signed-off-by: Dan Murphy
Applied 4,5,6 and 8,9.
> config LEDS_LP55XX_COMMON
> tristate "Common Driver for TI/National LP5521/5523/55231/
On Thu 2020-07-16 13:19:58, Dan Murphy wrote:
> Introduce the LP5036/30/24/18/12/9 RGB LED driver.
> The difference in these parts are the number of
> LED outputs where the:
>
> LP5036 can control 36 LEDs
> LP5030 can control 30 LEDs
> LP5024 can control 24 LEDs
> LP5018 can control 18 LEDs
>
Hi!
> The device has the ability to group LED output into control banks
> so that multiple LED banks can be controlled with the same mixing and
> brightness. Inversely the LEDs can also be controlled independently.
Inversely?
> --- /dev/null
> +++ b/drivers/leds/leds-lp50xx.c
> @@ -0,0 +1,784
Hi!
> >This adds support for registering such triggers.
> >
> >This code is based on work by Pavel Machek and
> >Ondřej Jirman .
> >
> >Signed-off-by: Marek Behún
> Acked-by: Jacek Anaszewski
Thanks, applied.
On Mon 2020-07-20 14:05:47, Dan Murphy wrote:
> Fix the camel case of MultiColor to Multicolor.
>
> Fixes: f5a6eb5c5e38 ("leds: multicolor: Introduce a multicolor class
> definition")
> Signed-off-by: Dan Murphy
Thanks, applied.
Pavel
--
Hi!
> This is the start of the stable review cycle for the 4.4.231 release.
> There are 58 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 22 Jul 2020 15:27:31
Hi!
> This is the start of the stable review cycle for the 4.19.134 release.
> There are 133 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 22 Jul 2020 15:27:31
Hi!
> From: Finley Xiao
>
> commit 371a3bc79c11b707d7a1b7a2c938dc3cc042fffb upstream.
>
> The function cpu_power_to_freq is used to find a frequency and set the
> cooling device to consume at most the power to be converted. For example,
> if the power to be converted is 80mW, and the em table
On Mon 2020-07-20 17:37:50, Greg Kroah-Hartman wrote:
> From: Finley Xiao
>
> commit 371a3bc79c11b707d7a1b7a2c938dc3cc042fffb upstream.
>
> The function cpu_power_to_freq is used to find a frequency and set the
> cooling device to consume at most the power to be converted. For example,
> if the
Hi!
> commit e7b931bee739e8a77ae216e613d3b99342b6dec0 upstream.
>
> The driver would happily overwrite its write buffer with user data in
> 256 byte increments due to a removed buffer-space sanity check.
> +++ b/drivers/usb/serial/iuu_phoenix.c
> @@ -697,14 +697,16 @@ static int
Hi!
> > > >After some investigations, we concluded the following:
> > > > - the issue does not exist in vanilla v5.8-rc4+
> > > > - [bisecting shows that] the panic on v4.14.186 is caused by the lack
> > > > of v5.6-rc1 commit 987351e1ea7772 ("phy: core: Add consumer device
> > > > link
Hi!
> On Mon, Jul 20, 2020 at 12:15:22PM +0200, Pavel Machek wrote:
> > This is queued for 4.19.134-stable, reverting 3 patches. But it seems
> > better alternative is available...
> >
> > commit f3e697b7b6f5e2c570226f8f8692fb7db57215ec
> > Author: Sasha Levin
Hi!
> From: Sergey Senozhatsky
>
> commit ab6f762f0f53162d41497708b33c9a3236d3609e upstream.
>
> printk_deferred(), similarly to printk_safe/printk_nmi, does not
> immediately attempt to print a new message on the consoles, avoiding
> calls into non-reentrant kernel paths, e.g. scheduler or
Hi!
On Mon 2020-07-20 17:36:28, Greg Kroah-Hartman wrote:
> This reverts commit c83258a757687ffccce37ed73dba56cc6d4b8a1b.
>
> Eugeniu Rosca writes:
>
> On Thu, Jul 09, 2020 at 09:00:23AM +0200, Eugeniu Rosca wrote:
> >After integrating v4.14.186 commit 5410d158ca2a50 ("usb/ehci-platform:
> >Set
Hi!
> > According to common LED bindings you should propose a new function
> > if none of the existing ones fits your needs.
> >
> > > This is normally used for motherboard lightning, right? I believe this
> > > is getting common on gaming boards, and we want common support for
> > > that.
> >
>
This adds support for registering such triggers.
>
> This code is based on work by Pavel Machek and
> Ondřej Jirman .
>
> Signed-off-by: Marek Behún
Looks good to me. I'll likely apply it soon...
Best regards,
Hi!
> Currently when the .activate() method fails and returns a negative error
> code while writing to the /sys/class/leds//trigger file, the write
> system call does not inform the user abouth this failure.
>
> This patch fixes this.
>
> Signed-off-by: Marek Behún
> ---
>
ne file that is not yet
present in 4.19.)
Eugeniu, can you verify this works for you?
Best regards,
Pavel
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 35fd38c5a4a1..600a4e554
Hi!
> Introduce a multicolor class that groups colored LEDs
> within a LED node.
>
> The multicolor class groups monochrome LEDs and allows controlling two
> aspects of the final combined color: hue and lightness. The former is
> controlled via the intensity file and the latter is controlled
>
On Thu 2020-07-16 17:03:03, Qinglang Miao wrote:
> From: Yongqiang Liu
>
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yongqiang Liu
> ---
> drivers/memory/emif.c | 22 ++
> drivers/memory/tegra/tegra124-emc.c | 14 +-
Hi!
Can we have node names consistent with other systems?
> + leds {
> + compatible = "gpio-leds";
> +
> + bt_active_led {
> + label = "blue:bt";
> + gpios = < 0 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger
On Wed 2020-07-08 11:14:27, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
Hi!
> Now that we have support for GPIO lines of the SMARC connector, enable
> LED support on the KBox A-230-LS. There are two LEDs without fixed
> functions, one is yellow and one is green. Unfortunately, it is just one
> multi-color LED, thus while it is possible to enable both at the same
>
Hi!
> This is a second version of "secret" mappings implementation backed by a
> file descriptor.
>
> The file descriptor is created using memfd_create() syscall with a new
> MFD_SECRET flag. The file descriptor should be configured using ioctl() to
> define the desired protection and then
Hi!
> +On the triviality of replacing words
> +
> +
> +The African slave trade was a brutal system of human misery deployed at
> +global scale. Some word choice decisions in a modern software project
> +does next to nothing to compensate for that legacy. So why
Hi!
> > >>> Add support for the LED feature of the NCT6795D chip found on some
> > >>> motherboards, notably MSI ones. The LEDs are typically used using a
> > >>> RGB connector so this driver creates one LED device for each color
> > >>> component.
> > >>
> > >> Ok, let me take a look. What
Hi!
First, let's substitute multi.color -> multicolor globally,
LEDS_CLASS_MULTI_COLOR is most visible example of this. Please also
decide whether it is MultiColor or multicolor, and make it consistent.
> Introduce a multicolor class that groups colored LEDs
> within a LED node.
>
> The multi
Hi!
> This is the start of the stable review cycle for the 4.19.133 release.
> There are 58 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 16 Jul 2020 18:40:38
On Wed 2020-07-15 15:20:56, Marek Behún wrote:
> On Mon, 13 Jul 2020 10:45:32 -0500
> Dan Murphy wrote:
>
> > Add a new color ID that is declared as MULTICOLOR as with the
> > multicolor framework declaring a definitive color is not accurate
> > as the node can contain multiple colors.
> >
> >
Hi!
> The Acer S1003 has proper DMI strings for sys-vendor and product-name,
> so we do not need to match by BIOS-date.
>
> This means that the Acer S1003 can use the generic lcd800x1280_rightside_up
> drm_dmi_panel_orientation_data struct which is also used by other quirks.
This is just a
Hi!
> Add support for the LED feature of the NCT6795D chip found on some
> motherboards, notably MSI ones. The LEDs are typically used using a
> RGB connector so this driver creates one LED device for each color
> component.
Ok, let me take a look. What entries does it present in /sys?
We'll
Hi!
>
> I'm pleased to announce the 4.19.132-rt59 stable release.
>
> This release is just an update to the new stable 4.19.132
> version and no RT specific changes have been made.
>
> You can get this release via the git tree at:
>
>
Hi!
> > At first, I thought that the proposed system call is capable of
> > reading *multiple* small files using a single system call - which
> > would help increase HDD/SSD queue utilization and increase IOPS (I/O
> > operations per second) - but that isn't the case and the proposed
> > system
On Mon 2020-07-13 01:18:41, Marek Behun wrote:
> On Mon, 13 Jul 2020 01:15:44 +0200
> Marek Behun wrote:
>
> > On Mon, 13 Jul 2020 00:38:21 +0200
> > Ondřej Jirman wrote:
> >
> > > So after trying to use this, this seems to disallow the use of multiple HW
> > > triggers per LED. That's fine by
Hi!
> /* Summary */
> This contains an annotation patch for a data race in copy_process() reported
> by
> KCSAN when reading and writing nr_threads. The data race is intentional and
Would "KCSAN fixes" be better subject of the pull request? fixes is a bit
too generic...
Hi!
> The board has a vibrator mottor. Hook it to the input subsystem.
motor, I believe.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
On Thu 2020-07-02 11:41:34, Eric W. Biederman wrote:
> Now that the last callser has been removed remove this code from exec.
Typo "caller".
> For anyone thinking of resurrecing do_execve_file please note that
resurrecting?
> the code was buggy in several fundamental ways.
>
> - It did not
Hi!
> > > This is the multi color LED framework. This framework presents clustered
> > > colored LEDs into an array and allows the user space to adjust the
> > > brightness
> > > of the cluster using a single file write. The individual colored LEDs
> > > intensities are controlled via a
On Thu 2020-07-09 13:24:21, Rob Herring wrote:
> On Mon, 22 Jun 2020 13:59:04 -0500, Dan Murphy wrote:
> > Add DT bindings for the LEDs multicolor class framework.
> > Add multicolor ID to the color ID list for device tree bindings.
> >
> > CC: Rob Herring
> >
Hi!
> > > > > Some LED controllers may come with an internal HW triggering mechanism
> > > > > for the LED and an ability to switch between user control of the LED,
> > > > > or the internal control. One such example is AXP20X PMIC, that allows
> > > > > wither for user control of the LED, or for
Hi!
GPS on the droid 4 does not really work out of the box.
gpsd is not in default installation, maybe it should be?
What is worse, there's something broken with gpsd. Try:
/usr/sbin/gpsd -N -D 5 /dev/gnss0
gpspipe -w
# this seems to work, but do ^C and restart
gpspipe -w
...and it hangs.
On Sun 2020-07-12 11:02:17, Greg Kroah-Hartman wrote:
> On Sun, Jul 12, 2020 at 10:50:59AM +0200, Pavel Machek wrote:
> > On Sun 2020-07-12 10:43:52, Greg Kroah-Hartman wrote:
> > > On Sun, Jul 12, 2020 at 10:24:53AM +0200, Pavel Machek wrote:
> > > > > +++ b/d
1001 - 1100 of 23435 matches
Mail list logo
