Hi!
I don't have XFS enabled, yet I'm asked if I want to support its old
format:
+config XFS_SUPPORT_V4
+ bool "Support deprecated V4 (crc=0) format"
+ default y
This needs to have dependence on XFS_FS.
+ This option will become default N in September 2025. Support for the
Hi!
> >> [ Upstream commit b867eef4cf548cd9541225aadcdcee644669b9e1 ]
> >>
> >> The SPIE register contains counts for the TX FIFO so any time the irq
> >> handler was invoked we would attempt to process the RX/TX fifos. Use the
> >> SPIM value to mask the events so that we only process interrupts
On Fri 2020-10-09 15:51:35, Gabriel David wrote:
> The mentioned struct, lm3697_led, was renamed to lm3697_bank since the
> structure is representing the control banks. This name, in my opinion,
> is more semantically correct. The pointers referring to it were also
> renamed.
> Signed-off-by:
Hi!
> Thank you for the review.
Note I'm LED maintainer.
> > > + leds {
> > > + compatible = "gpio-leds";
> > > +
> > > + sdhi2_led {
> > > + label = "sdio-led";
> >
> > This should use appropriate label... probably mmc1:green:activity.
> >
> $
On Fri 2020-10-09 09:21:41, Greg KH wrote:
> On Fri, Oct 09, 2020 at 09:10:45AM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > new file mode 100644
> > > > index ..f54da5f19c2b
> > > > --- /dev/null
> > > >
Hi!
> index ..c62ddb9b2ba5
> --- /dev/null
> +++
> b/arch/arm64/boot/dts/renesas/hihope-rzg2-ex-aistarvision-mipi-adapter-2.1.dtsi
> @@ -0,0 +1,109 @@
> +// SPDX-License-Identifier: GPL-2.0
dts files are normally dual-licensed...?
Best regards,
Hi!
> +++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> @@ -63,6 +63,16 @@
> enable-gpios = < 11 GPIO_ACTIVE_HIGH>;
> };
>
> + leds {
> + compatible = "gpio-leds";
> +
> + sdhi2_led {
> + label = "sdio-led";
This should use
Hi!
> --- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> +++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> @@ -63,6 +63,16 @@
> enable-gpios = < 11 GPIO_ACTIVE_HIGH>;
> };
>
> + leds {
> + compatible = "gpio-leds";
> +
> + sdhi2_led {
> +
Hi!
> + {
> + /* SW2[6] determines which connector is activated
> + * ON = PCIe X4 (connector-J7)
> + * OFF = mini-PCIe (connector-J26)
> + */
> + status = "okay";
> +};
Note this is wrong comment style for non-network parts of kernel.
Best regards,
Hi!
> > new file mode 100644
> > index ..f54da5f19c2b
> > --- /dev/null
> > +++ b/arch/x86/kernel/cpu/sgx/driver.c
> > @@ -0,0 +1,173 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
>
> You use gpl-only header files in this file, so how in the world can it
> be bsd-3
t; Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: b994718760fa ("scsi: qla2xxx: Use constant when it is known")
> Signed-off-by: Colin Ian King
Acked-by: Pavel Machek (CIP)
And sorry, I did patch against mainline, and this got added in -next
in the meant
Hi!
> > I believe probability someone uses that with more than 4 CPUs is <
> > 5%.
>
> So you even didn't bother to check:
>
> $ git grep "default-trigger = \"cpu[4-9]"
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi: linux,default-trigger = "cpu4";
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi:
Hi!
> +int main(void)
> +{
> +struct pollfd pfd = { .events = POLLIN };
> +struct counter_event event_data[2];
> +
> +pfd.fd = open("/dev/counter0", O_RDWR);
> +
> +ioctl(pfd.fd, COUNTER_SET_WATCH_IOCTL, watches);
> +
Hi!
> > > The node names for devices using the pwm-leds driver follow a certain
> > > naming scheme (now). Parent node name is not enforced, but recommended
> > > by DT project.
> > >
> > > DTC Documentation/devicetree/bindings/mfd/iqs62x.example.dt.yaml
> > > CHECK
Hi!
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: c85fb28b6f999db9928b841f63f1beeb3074eeca
> commit: 92a81562e695628086acb92f95090ab09d9b9ec0 leds: lp55xx: Add multicolor
> framework support to lp55xx
> date: 3 months ago
> config:
Hi!
> Add support for the iEi WT61P803 PUZZLE LED driver.
> Currently only the front panel power LED is supported.
>
> This driver depends on the iEi WT61P803 PUZZLE MFD driver.
> +static int iei_wt61p803_puzzle_led_brightness_set_blocking(struct
> led_classdev *cdev,
> +
Hi!
> The node names for devices using the pwm-leds driver follow a certain
> naming scheme (now). Parent node name is not enforced, but recommended
> by DT project.
>
> DTC Documentation/devicetree/bindings/mfd/iqs62x.example.dt.yaml
> CHECK
On Mon 2020-10-05 22:34:40, Alexander Dahl wrote:
> Since commit 141f15c66d94 ("leds: pwm: remove header") that platform
> interface is not usable from outside and there seems to be no in tree
> user anymore. All in-tree users of the leds-pwm driver seem to use DT
> currently. Getting rid of the
On Mon 2020-10-05 22:34:41, Alexander Dahl wrote:
> The example was adapted in the following ways:
>
> - make use of the now supported 'function' and 'color' properties
> - remove pwm nodes, those are documented elsewhere
> - align node names to new dt schema rules and dt recommendations
>
>
Hi!
> From: Yu Kuai
>
> [ Upstream commit 1a26044954a6d1f4d375d5e62392446af663be7a ]
>
> if of_find_device_by_node() succeed, exynos_iommu_of_xlate() doesn't have
> a corresponding put_device(). Thus add put_device() to fix the exception
> handling for this function implementation.
Okay, this
Hi!
> [ Upstream commit b867eef4cf548cd9541225aadcdcee644669b9e1 ]
>
> The SPIE register contains counts for the TX FIFO so any time the irq
> handler was invoked we would attempt to process the RX/TX fifos. Use the
> SPIM value to mask the events so that we only process interrupts that
> were
Hi!
> [ Upstream commit 17dd1367389cfe7f150790c83247b68e0c19d106 ]
>
> Before to call vdev->config->reset(vdev) we need to be sure that
> no one is accessing the device, for this reason, we add new variables
> in the struct virtio_vsock to stop the workers during the .remove().
>
> This patch
Hi!
> > >> By the way I just realized that the DT binding in this driver seems
> > >> incorrect to me.
> > >>
> > >> The controller logically supports 3 LED strings, each having
> > >> configurable control bank.
> >
> > There are two control banks. You can connect the HVLED outputs to either
Hi!
> Another round of wack-a-mole. The json-schema default is additional
> unknown properties are allowed, but for DT all properties should be
> defined.
for leds:
Acked-by: Pavel Machek
I assume you apply it..?
Hi!
> From: Will McVicker
>
> commit 1cc5ef91d2ff94d2bf2de3b3585423e8a1051cb6 upstream.
>
> The indexes to the nf_nat_l[34]protos arrays come from userspace. So
> check the tuple's family, e.g. l3num, when creating the conntrack in
> order to prevent an OOB memory access during setup. Here is
t sure EINVAL is right error return. EBUSY?
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 9ea3d8e61100..01c36f3dd87f 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2606,8 +2606,10 @@ static int nvme_dev_op
On Mon 2020-10-05 20:31:16, ultracool...@tutanota.com wrote:
> Otherwise everything works great :)
>
> (And sorry for sending two emails)
No problem, sorry for breaking your patch. I moved it near other
initializers.
Question: is it likely that someone will want to use your device with
-stable
Hi!
> Agh. I added the Signed-off-by in an earlier non-published version of the
> commit, but forgot to add it back. But that doesn't really excuses me.
>
> I attached the (hopefully) final version of this patch. Pavel, I'll send the
> struct rename separately after I submit this.
>
Thanks,
Hi!
> Well, the major benefit I see is that it makes the driver slightly more
> readable. However I'm fine with whatever you guys decide.
>
> I'll attach the patch with the struct renaming removed just in case.
Thanks for the patches. Content is pretty good, but I'd really need
From +
Hi!
> On 10/5/20 8:57 AM, ultracool...@tutanota.com wrote:
> > I agree with you.
> >
> > Attached patch with changes.
>
> Nack to the patch.
No need to do that, without matching From: and Signed-off, I can't
really apply it...
> The subject says it does one thing but you also unnecessarily
Hi!
> Another round of wack-a-mole. The json-schema default is additional
> unknown properties are allowed, but for DT all properties should be
> defined.
for leds:
Acked-by: Pavel Machek
I assume you apply it..?
Hi!
> Another round of wack-a-mole. The json-schema default is additional
> unknown properties are allowed, but for DT all properties should be
> defined.
for leds:
Acked-by: Pavel Machek
I assume you apply it..?
Hi!
> > if (ret)
> > dev_err(>client->dev, "Cannot write OUTPUT config\n");
> >
> > - for (i = 0; i < LM3697_MAX_CONTROL_BANKS; i++) {
> > + for (i = 0; i < priv->num_leds; i++) {
>
> Ultracoolguy is correct that this for cycle should not iterate
> LM3697_MAX_CONTROL_BANKS.
Hi!
> > > > > I believe the kernel makes a questionable assumption on how clang
> > > > > uses registers (gs will not be used if stack protection is disabled).
> > > > > Both kernel and clang behaves unfortunate here.
> > > >
> > > > If the kernel is at fault here and this same thing happens with
Hi!
> > In particular, using this functionality, user is able to push out
> > "hot" files on any high-performance device (e.g. proxy device) and pin
> > them there.
What permissions are normally required for file migration?
> > COMMENT. After ioctl successful completion the file is not
, thus while it is possible to enable both at the same
> time it is hard to tell the difference between "yellow only" and "yellow
> and green".
>
> Signed-off-by: Michael Walle
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky
Hi!
> Many an ethernet PHY supports various HW control modes for LEDs
> connected directly to the PHY chip.
>
> This patch adds code for registering such LEDs when described in device
> tree and also adds a new private LED trigger called phydev-hw-mode.
> When this trigger is enabled for a LED,
Hi!
> Signed-off-by: Ultracoolguy
I'll need your real name to apply a patch.
> Hi, all. This is a patch fixing an out-of-bounds error due to lm3697_init
> expecting the device tree to use both control banks. This fixes it by adding
> a new variable that will hold the number of used banks.
>
Hi!
>
> Just in case someone is interested: As a Proof-of-Concept I started 100
> thousand processes on a big machine (72 cores). It worked!
> However starting those too more than 30 minutes, and top needs more than 30
> minutes to refresh ist display. Still, interactive input via SSH works
Hi!
> From: Lars Poeschel
>
> This driver allows to use a lcd2s 20x4 character display from modtronix
> engineering as an auxdisplay charlcd device.
Is there userland interface documenteted somewhere? I tried to grep
through Documentation and did not find anything useful :-(.
Hi!
> From: Raviteja Narayanam
>
> [ Upstream commit 42e11948ddf68b9f799cad8c0ddeab0a39da33e8 ]
>
> On some platforms, the log is corrupted while console is being
> registered. It is observed that when set_termios is called, there
> are still some bytes in the FIFO to be transmitted.
>
> So,
Hi!
> +static int iei_wt61p803_puzzle_led_brightness_set_blocking(struct
> led_classdev *cdev,
> + enum led_brightness brightness)
> +{
> + struct iei_wt61p803_puzzle_led *priv =
> cdev_to_iei_wt61p803_puzzle_led(cdev);
> + unsigned char *resp_buf = priv->response_buffer;
>
Hi!
> > > +__attribute__((nonnull))
> > >
> > > static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
> > >
> > > struct led_pwm *led, struct fwnode_handle *fwnode)
> > >
> > > {
> >
> > This normally goes elsewhere -- right? I'd expect:
> >
> >
> >
Hi!
> > In one of the error paths of the for_each_child_of_node loop in
> > tlc591xx_probe, add missing call to of_node_put.
> >
> > Fixes: 1ab4531ad132 ("leds: tlc591xx: simplify driver by using the
> > managed led API")
> >
> > Signed-off-by: Tobias Jordan
>
> Reviewed-by: Marek Behún
Hi!
> In the error path of the for_each_available_child_of_node loop in
> aw2013_probe_dt, add missing call to of_node_put to avoid leaking the
> iterator.
>
> Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
> Signed-off-by: Tobias Jordan
This failed to apply to my -for-next tree.
Best
Hi!
> [ Upstream commit 3b4b19721ec652ad2c4fe51dfbe5124212b5f581 ]
>
> Revert fab7772bfbcf ("nvme-multipath: revalidate nvme_ns_head gendisk
> in nvme_validate_ns")
>
> When adding a new namespace to the head disk (via nvme_mpath_set_live)
> we will see partition scan which triggers I/O on the
Hi!
> From: Bart Van Assche
>
> [ Upstream commit e4d2add7fd5bc64ee3e388eabe6b9e081cb42e11 ]
>
> Since the lrbp->cmd expression occurs multiple times, introduce a new local
> variable to hold that pointer. This patch does not change any
> functionality.
This is just a cleanup, AFAICT, and
On Sat 2020-09-26 17:46:35, Greg Kroah-Hartman wrote:
> On Fri, Sep 25, 2020 at 06:51:34PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > [ Upstream commit 2fbc6e89b2f1403189e624cabaf73e189c5e50c6 ]
> > >
> > > Kfir reported that pmtu exceptions are not cr
Hi!
> This is the start of the stable review cycle for the 4.19.149 release.
> There are 245 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, 01 Oct 2020 10:59:03
Hi!
> This is the start of the stable review cycle for the 4.4.238 release.
> There are 85 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, 01 Oct 2020 10:59:03
Hi!
> get_gendisk grabs a reference on the disk and file operation, so this
> code will leak both of them while having absolutely no use for the
> gendisk itself.
>
> This effectively reverts commit 2df83fa4bce421f
> ("PM / Hibernate: Use get_gendisk to verify partition if resume_file is
>
Hi!
> This is the start of the stable review cycle for the 4.19.148 release.
> There are 37 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.
CIP testing did not detect any problems.
lete the assignment, too.
Best regards,
Pavel
Signed-off-by: Pavel Machek (CIP)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index f60e28418ece..84de87b7eedc 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -777,7 +777,7 @@ static void __i
Hi!
In linux-next, I published TODO list for LED subsystem. Is that
something linux-kernel-mentees could help with?
Best regards,
Pavel
+++ b/drivers/leds/TODO
@@ -0,0 +1,58 @@
+-*- org -*-
+
+* On/off LEDs should have max_brightness of 1
Hi!
> >>So.. no, it is not causing kernel crashes or something. But it is
> >>example of bad interface, and _that_ is causing problems. (And yes, if
> >>I realized it is simply possible to limit it, maybe the BIN_ATTR
> >>conversion would not be neccessary...)
> >
> >The limitation you proposed
Hi!
> PC-relative data referencing
>
>
> I agree that the current PC value can be loaded in a GPR using the trick
> of call, pop on i386.
>
> Perhaps, on other architectures, we can do similar things. For instance,
> in architectures that load the return address in
Hi!
> >>> I believe you should simply delete confusing "introduction" and
> >>> provide details of super-secure system where your patches would be
> >>> useful, instead.
> >>
> >> This RFC talks about converting dynamic code (which cannot be
> >> authenticated)
> >> to static code that can be
On Wed 2020-09-23 15:14:43, Marek Behun wrote:
> Wrong subject, it says
> lm3552
> but driver is called
> lm3532
>
> Besides this:
>
> Reviewed-by: Marek Behún
Thanks for review!
Best regards,
Pavel
--
(english)
On Tue 2020-09-22 14:06:38, Dan Murphy wrote:
> Fix warnings for undefined parameters when building with W=1.
>
It also adds of_match_table. I guess that's okay.
I'll remove the fixes tags as I don't believe these need to go to
stable.
Best regards,
On Sun 2020-09-06 22:51:02, Dmitry Osipenko wrote:
> Acer Iconia Tab A500 is an Android tablet device which has two LEDs
> embedded into the Power Button. Orange LED indicates "battery charging"
> status and white LED indicates "wake-up/charge-done" status. The new LED
> driver provides control
stashing it away in the pinctrl mapping entries.
Cc: Linus Walleij
Reported-by: Elena Petrova
Tested-by: Elena Petrova
Signed-off-by: Will Deacon
Link: https://lore.kernel.org/r/20191002124206.22928-1-w...@kernel.org
Signed-off-by: Linus Walleij
Signed-off-by: Pavel Machek (CIP)
diff --git
Hi!
> >> Scenario 2
> >> --
> >>
> >> We know what code we need in advance. User trampolines are a good example
> >> of
> >> this. It is possible to define such code statically with some help from the
> >> kernel.
> >>
> >> This RFC addresses (2). (1) needs a general purpose trusted code
Hi!
> > > > The W^X implementation today is not complete. There exist many user
> > > > level
> > > > tricks that can be used to load and execute dynamic code. E.g.,
> > > >
> > > > - Load the code into a file and map the file with R-X.
> > > >
> > > > - Load the code in an RW- page. Change
Hi!
> > The one thing that does show up in the diffstat is the softscroll
> > removal (both fbcon and vgacon), and there are people who want to save
> > that, but we'll see if some maintainer steps up. I'm not willing to
> > resurrect it in the broken form it was in, so I doubt that will happen
>
Hi!
> The one thing that does show up in the diffstat is the softscroll
> removal (both fbcon and vgacon), and there are people who want to save
> that, but we'll see if some maintainer steps up. I'm not willing to
> resurrect it in the broken form it was in, so I doubt that will happen
> in 5.9,
Hi!
> > I believe it will need to be reverted in Linus' tree, too. In fact,
> > the patch seems to be a way for Linus to find a maintainer for the
> > code, and I already stated I can do it. Patch is so new it was not
> > even in -rc released by Linus.
>
> I can honestly see how it can be missed
Hi!
> Solution proposed in this RFC
> =
>
> >From this RFC's perspective, there are two scenarios for dynamic code:
>
> Scenario 1
> --
>
> We know what code we need only at runtime. For instance, JIT code generated
> for frequently executed Java methods.
Hi!
> Introduction
>
>
> Dynamic code is used in many different user applications. Dynamic code is
> often generated at runtime. Dynamic code can also just be a pre-defined
> sequence of machine instructions in a data buffer. Examples of dynamic
> code are trampolines, JIT code, DBT
On Tue 2020-09-22 18:16:42, Greg Kroah-Hartman wrote:
> On Tue, Sep 22, 2020 at 05:39:57PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > From: Vincent Huang
> > >
> > > commit 6c77545af100a72bf5e28142b510ba042a17648d upstream.
> > >
> >
On Tue 2020-09-22 12:54:20, Saeed Mahameed wrote:
> On Mon, 2020-09-21 at 22:54 -0700, Saeed Mahameed wrote:
> > On Mon, 2020-09-21 at 13:41 +0200, Pavel Machek wrote:
> > > The last return statement is unreachable code. I'm not sure if it
> > > will
> > > pro
Hi!
> From: Vincent Huang
>
> commit 6c77545af100a72bf5e28142b510ba042a17648d upstream.
>
> Add trackpoint variant IDs to allow supported control on Synaptics
> trackpoints.
This just adds unused definitions. I don't think it is needed in
stable.
Best regards,
Hi!
> From: Dinghao Liu
>
> [ Upstream commit ea403fde7552bd61bad6ea45e3feb99db77cb31e ]
>
> When pm8001_tag_alloc() fails, task should be freed just like it is done in
> the subsequent error paths.
Does the timer also need to be deleted, as in the next error return?
Or better, can we move
Hi!
> > +config X86_INTEL_BRANCH_TRACKING_USER
> > +prompt "Intel Indirect Branch Tracking for user-mode"
>
> Take the "Intel " and "INTEL_" out, please. It will only cause us all
> pain later if some of our x86 compatriots decide to implement this.
Are other x86 manufacturers legally
Hi!
> >Can I get details of your setup?
>
> I don't use this trigger, but I can imagine that someone does.
Well, if someone exists, we can increase the limit, or convince them
to change their setup.
> >What CPU type that is, and how are you mapping CPU activity to LEDs?
>
> The type of CPU is
On Mon 2020-09-21 09:19:55, Christoph Hellwig wrote:
> Just check the dev_t to help simplifying the code.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Rafael J. Wysocki
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pic
Hi!
> Milo Kim's email in TI bounces with permanent error (550: Invalid
> recipient). Last email from him on LKML was in 2017. Move Milo Kim to
> credits and remove the separate driver entries for:
>
> - TI LP855x backlight driver,
> - TI LP8727 charger driver,
> - TI LP8788 MFD (ADC, LEDs,
Hi!
> Milo Kim's email in TI bounces with permanent error (550: Invalid
> recipient). Last email from him on LKML was in 2017. Move Milo Kim to
> credits and remove the separate driver entries for:
>
> - TI LP855x backlight driver,
> - TI LP8727 charger driver,
> - TI LP8788 MFD (ADC, LEDs,
Hi!
> > Move prepare to wait around, so that normal GFP_KERNEL allocation can
> > be used.
> >
> > Signed-off-by: Pavel Machek (CIP)
> > Acked-by: Alan Stern
>
> Ehm. Please recheck.
Sorry about that.
> > +++ b/drivers/usb/misc/yurex.c
> >
On Mon 2020-09-21 13:38:00, Greg KH wrote:
> On Mon, Sep 21, 2020 at 01:30:39PM +0200, Pavel Machek wrote:
> > Simplify quirk handling.
>
> In what way?
>
> Please be more descriptive in your changelog and resend.
Have you looked at the patch below? Please apply the patch.
The last return statement is unreachable code. I'm not sure if it will
provoke any warnings, but it looks ugly.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
index 2d55b7c22c03
Fix resource leak in error handling.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index bd270e66185e..40869ea1ed20 100644
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
@@ -1744,7 +1744,7 @@ ccp_run_sha_cmd
Simplify quirk handling.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index f232914de5fd..167b6ac428a3 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -56,18 +56,13 @@ static int quirks_param_set(const char *value
Directly return constant when it is known, to make code easier to
understand.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/scsi/qla2xxx/qla_nvme.c b/drivers/scsi/qla2xxx/qla_nvme.c
index 90bbc61f361b..248197e9e8ea 100644
--- a/drivers/scsi/qla2xxx/qla_nvme.c
+++ b/drivers/scsi/qla2xxx
Hi!
> > > The leds-regulator driver only supports the old platform data binding
> > > and no in-tree code uses it. It also seems that no OpenWRT board uses
> > > it.
> > >
> > > Remove this driver.
> >
> > Lets keep this one.
>
> Very well.
>
> > Connecting LED directly to regulator simply
On Sun 2020-09-20 22:42:03, Marek Behún wrote:
> The leds-regulator driver only supports the old platform data binding
> and no in-tree code uses it. It also seems that no OpenWRT board uses
> it.
>
> Remove this driver.
Lets keep this one. Connecting LED directly to regulator simply makes
Hi!
> 258a8388d0ec ("leds: ns2: use struct led_init_data when registering")
> d444232bbbdd ("leds: ns2: remove unneeded variable")
> 29c44f2b51a8 ("leds: ns2: register LED immediately after parsing DT
> properties")
> 925533c5a040 ("leds: ns2: cosmetic change: use helper variable")
>
On Sun 2020-09-20 16:14:22, Markus Elfring wrote:
> > I believe set_lock should be taken in exit function, too.
>
> * Would an imperative wording become helpful for the change description?
>
> * How do you think about to add the tag “Fixes” to the commit message?
Hi,
This is the semi-friendly
Hi!
> >*
> >* It can be bound to any LED just like other triggers using either a
> >* board file or via sysfs interface.
> >*
> >* An API named ledtrig_cpu is exported for any user, who want to add CPU
> > - * activity indication in their code
> > + * activity indication in
I believe set_lock should be taken in exit function, too.
Signed-off-by: Pavel Machek (CIP)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index cff4944d5b66..1420734394e9 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -1301,10 +1301,12 @@ static void
Fix memory leak in node_probe.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/media/firewire/firedtv-fw.c
b/drivers/media/firewire/firedtv-fw.c
index 3f1ca40b9b98..8a8585261bb8 100644
--- a/drivers/media/firewire/firedtv-fw.c
+++ b/drivers/media/firewire/firedtv-fw.c
@@ -272,8
Move prepare to wait around, so that normal GFP_KERNEL allocation can
be used.
Signed-off-by: Pavel Machek (CIP)
Acked-by: Alan Stern
diff --git a/drivers/usb/misc/yurex.c b/drivers/usb/misc/yurex.c
index b2e09883c7e2..071f1debebba 100644
--- a/drivers/usb/misc/yurex.c
+++ b/drivers/usb/misc
Fix memory leak in error path.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6798addabd5a..785270ee337c 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -994,8 +994,10 @@ static int
This fixes memory leak in at_hdmac. Mainline does not have the same
problem.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 86427f6ba78c..0847b2055857 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -1714,8 +1714,10
Hi!
> > Because I'm willing to
> > bet a lot of cash that no one runs bleeding egde 5.9-rcX in production
> > over there right now :-)
>
> I guess you're paying for beers then. "Android Common Kernels" run
> mainline. (They're a bit esoteric in terms of "production" but
> cuttlefish virtual
On Sat 2020-09-19 18:08:53, Liu Shixin wrote:
> Simplify the return expression.
Thanks, applied.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
Hi!
> Parse `led-max-current` property of child nodes and compute aggregated
> value in a separate function. The controller cannot set this value
> separately for every LED, so there is no need to store this value for
> every LED.
>
> Signed-off-by: Marek Behún
> Cc: H. Nikolaus Schaller
Hi!
> Do parsing of `linux,default-trigger` DT property to LED core. Currently
> it is done in many different drivers and the code is repeated.
>
> This patch removes the parsing from 21 drivers:
> an30259a, aw2013, bcm6328, bcm6358, cr0014114, el15203000, gpio,
> is31fl319x, is31fl32xx,
On Fri 2020-09-18 00:33:36, Marek Behún wrote:
> Reorder #includes alphabetically.
No.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> By using devres version of LED registering function we can remove the
> .remove method from this driver.
Please see a0972fff09479dd09b731360a3a0b09e4fb4d415.
And yes, Johan should have added a comment instead of placing it in
changelog. Feel free to add the comment. There was more than
On Fri 2020-09-18 00:32:51, Marek Behún wrote:
> This driver can be compiled on other platforms with small change if
> COMPILE_TEST=y.
>
> Signed-off-by: Marek Behún
> +++ b/drivers/leds/leds-fsg.c
> @@ -16,7 +16,13 @@
> #include
> #include
> #include
> +
> +#if IS_ENABLED(MACH_FSG)
>
701 - 800 of 23450 matches
Mail list logo
