On Fri 2024-04-26 04:25:40, Matthew Wilcox wrote:
> On Thu, Apr 25, 2024 at 08:58:34PM -0400, Kent Overstreet wrote:
> > On Thu, Apr 25, 2024 at 05:43:33PM -0700, Kees Cook wrote:
> > > All this said, I'm still not excited about any of these files living
> > > in /proc at all -- we were supposed
Hi!
> > > > > The /proc/allocinfo file exposes a tremendous about of information
> > > > > about
> > > > > kernel build details, memory allocations (obviously), and potentially
> > > > > even image layout (due to ordering). As this is intended to be
> > > > > consumed
> > > > > by system owners
Hi!
> The tag is there in the repository:
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v5.10.214-rt106-rebase
>
> When I released 5.10.215-rt107 (and its -rebase counterpart),
> 5.10.214-rt106-rebase
> was no longer pointing to a commit inside
Hi!
> I'm pleased to announce the 5.10.214-rt106 stable release.
>
> This release is simply an update to the new stable 5.10.214 version and no
> RT-specific changes have been performed.
>
> You can get this release via the git tree at:
>
>
Hi!
> I'm pleased to announce the 5.10.213-rt105 stable release.
>
> This release is an update to the new stable 5.10.213 version and no extra
> changes have been performed.
Thanks for release.
I see v5.10.214-rt106-rc1 is out there and now v5.10.215-rt107-rc1,
but I don't see v5.10.214-rt106
basic support
> > in mainline is needed to be able to work on the other stuff
> > (networking, cameras, power management).
> >
> > Signed-off-by: Ondrej Jirman
> > Co-developed-by: Martijn Braam
> > Co-developed-by: Samuel Holland
> > Signed-off-by: Pave
Hi!
> > Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
> > but I did best I could.
> >
> > Signed-off-by: Pavel Machek
>
> ...
>
> > + cabledet-gpios:
> > +maxItems: 1
> > +description: GPIO control
is needed to be able to work on the other stuff
(networking, cameras, power management).
Signed-off-by: Ondrej Jirman
Co-developed-by: Martijn Braam
Co-developed-by: Samuel Holland
Signed-off-by: Pavel Machek
---
v2: Fix checkpatch stuff. Some cleanups, adapt to dts format in 1/2.
v3: Turn down
Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
but I did best I could.
Signed-off-by: Pavel Machek
---
v2: implement review feedback
v3: fix single character pointed by robot
diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
b/Documentation
On Thu 2024-04-04 16:29:11, Luigi311 wrote:
> On 4/3/24 12:48, Pavel Machek wrote:
> > Hi!
> >
> >> The sensor supports the clock lane either remaining in HS mode
> >> during frame blanking, or dropping to LP11.
> >>
> >> Add configuration
Hi!
Thanks for doing this. I had some comments on 5, 9, 10, 11, 12, 21
and 22. You can add "Reviewed-by: Pavel Machek " to the
rest.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine
Hi!
> From: Luis Garcia
>
> Add powerdown-gpio binding as it is required for some boards
"." at end of sentence.
> Signed-off-by: Ondrej Jirman
> Signed-off-by: Luis Garcia
If the patch is from Ondrej, he should be in From:, I believe.
Best regards,
Hi!
> The sensor supports the clock lane either remaining in HS mode
> during frame blanking, or dropping to LP11.
>
> Add configuration of the mode via V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK.
> + ret = imx258_write_reg(imx258, IMX258_CLK_BLANK_STOP,
> +
Hi!
> Libcamera requires the cropping information for each mode, so
> add this information to the driver.
> @@ -116,6 +124,9 @@ struct imx258_mode {
> u32 link_freq_index;
> /* Default register values */
> struct imx258_reg_list reg_list;
> +
> + /* Analog crop rectangle.
On Wed 2024-04-03 09:03:39, g...@luigi311.com wrote:
> From: Dave Stevenson
>
> V4L2 sensor drivers are expected are expected to clip the supported
Remove one copy of "are expected".
Best regards,
Pavel
--
People of Russia, stop
Hi!
> +/*
> + * 4208x3120 @ 30 fps needs 1267Mbps/lane, 4 lanes.
> + * To avoid further computation of clock settings, adopt the same per
> + * lane data rate when using 2 lanes, thus allowing a maximum of 15fps.
> + */
> +static const struct imx258_reg mipi_1267mbps_19_2mhz_2l[] = {
> + {
Hi!
> The device tree bindings define the relevant regulators for the
> sensor, so update the driver to request the regulators and control
> them at the appropriate times.
> @@ -995,9 +1007,19 @@ static int imx258_power_on(struct device *dev)
> struct imx258 *imx258 = to_imx258(sd);
>
Hi!
> I'm sorry to keep you waiting.
Thanks for comments.
> > + struct gpio_desc *gpio_reset;
> > + struct gpio_desc *gpio_cabledet;
> > +
> > + uint32_t src_caps[8];
>
> Use u32 instead of uint32_t.
Will replace globally.
> > +static int anx7688_reg_read(struct anx7688 *anx7688, u8
Hi!
> In preparation for temporarily marking pages not present during a
> transition between encrypted and decrypted, use slow_virt_to_phys()
> in the hypervisor callback. As long as the PFN is correct,
This seems to be preparation for something we don't plan to do in
-stable. Please drop.
Best
having basic support
> in mainline is needed to be able to work on the other stuff
> (networking, cameras, power management).
>
> Signed-off-by: Ondrej Jirman
> Co-developed-by: Martijn Braam
> Co-developed-by: Samuel Holland
> Signed-off-by: Pavel
Hi!
> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
> but I did best I could.
>
> Signed-off-by: Pavel Machek
Any more comments here? Automatic system told me I need to replace one
character...
Hi!
> From: Kees Cook
>
> [ Upstream commit 40b9385dd8e6a0515e1c9cd06a277483556b7286 ]
>
> FORTIFY_SOURCE has been ignoring 0-sized destinations while the kernel
> code base has been converted to flexible arrays. In order to enforce
> the 0-sized destinations (e.g. with __counted_by), the
is needed to be able to work on the other stuff
(networking, cameras, power management).
Signed-off-by: Ondrej Jirman
Co-developed-by: Martijn Braam
Co-developed-by: Samuel Holland
Signed-off-by: Pavel Machek
---
v2: Fix checkpatch stuff. Some cleanups, adapt to dts format in 1/2.
diff --git
Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
but I did best I could.
Signed-off-by: Pavel Machek
---
v2: implement review feedback
diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
Hi!
> For all these reasons the display analogy really is a bit fit for these
> keyboards
> we tried to come up with a universal coordinate system for these at the
> beginning
> of the thread and we failed ...
I quite liked the coordinate system proposal. I can propose this:
Vendor maps the
Hi!
> > To be honest, I think the kernel shouldn't include too much high-level
> > complexity. If there is a desire to implement a generic display device on
> > top of the RGB device, this should be a configurable service running in
> > user space. The kernel should provide an interface to
Hi!
> > > so after more feedback from the OpenRGB maintainers I came up with an even
> > > more generic proposal:
> > > https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
> >
> > > >evaluate-set-command ioctl taking:
> > > >{
> > > > enum command /* one
Hi!
> > Yeah, so ... this is not a interface. This is a backdoor to pass
> > arbitrary data. That's not going to fly.
>
> Pavel, Note the data will be interpreted by a kernel driver and
> not passed directly to the hw.
Yes, still not flying :-).
> With that said I tend to agree that this seems
Hi!
> > + reset-gpios:
> > +maxItems: 1
>
> blank line
>
> > + avdd10-supply:
> > +description:
> > + 1.0V power supply
>
> Keep description in one line and add a blank line. This code is not that
> readable.
>
> > + i2c-supply:
> > +description:
> > + Power supply
>
Hi!
> so after more feedback from the OpenRGB maintainers I came up with an even
> more generic proposal:
> https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
> >evaluate-set-command ioctl taking:
> >{
> > enum command /* one of supported_commands */
> >
Hi!
> > Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
> > but I did best I could.
> >
> > Signed-off-by: Pavel Machek
> >
>
> You miss proper diffstat which makes reviewing difficult.
> Actually entire patch is corrupte
Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
but I did best I could.
Signed-off-by: Pavel Machek
diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
new file mode 100644
index
Hi!
> > From: Ondrej Jirman
> >
> > This is driver for ANX7688 USB-C HDMI, with flashing and debugging
> > features removed. ANX7688 is rather criticial piece on PinePhone,
> > there's no display and no battery charging without it.
>
> Don't remove the flashing part. Some Pinephones come
Hi!
> > Using sizeof(dst) is the overwhelmingly common case for strscpy().
> > Instead of requiring this everywhere, allow a 2-argument version to be
> > used that will use the sizeof() internally.
>
> Yeah, this is definitely the case. I have a ton of patches replacing
> strncpy with strscpy
Hi!
> > --- /dev/null
> > +++ b/drivers/usb/typec/anx7688.c
> > @@ -0,0 +1,1866 @@
> > +/*
> > + * ANX7688 USB-C HDMI bridge/PD driver
> > + *
>
>
>
> Did this pass checkpatch? I need a spdx line for new files please,
> don't force us to go back and guess in the future, that isn't nice.
is needed to be able to work on the other stuff
(networking, cameras, power management).
Signed-off-by: Ondrej Jirman
Signed-off-by: Martijn Braam
Signed-off-by: Samuel Holland
Signed-off-by: Pavel Machek
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 2f80c2792dbd
Hi!
> > We (as in cip project), are trying to do -cip-rt releases
> > once a month. Are there any plans for 5.10-rt release any time soon?
> > That would help us ;-).
>
> I already pushed v5.10-rt-next (containing v5.10.209-rt101-rc1) to
> kernel.org and kernelci should pick that up for
Hi!
We (as in cip project), are trying to do -cip-rt releases
once a month. Are there any plans for 5.10-rt release any time soon?
That would help us ;-).
Best regards,
Pavel
--
DENX Software Engineering GmbH,Managing
Hi!
> Isn't this simply the case of picking the gc2145 bits from Megis tree?
>
> https://megous.com/git/linux/tree/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi?h=orange-pi-5.10#n410
Well, that, adjusting dts bits to the new driver, testing and
submitting the patch. And it looks
Hi!
> > And while I would personally hate it, you can imagine a use case where
> > you'd like a keypress to have a visual effect around the key you
> > pressed. A kind of force feedback, if you will. I don't actually know,
> > and correct me if I'm wrong, but feels like implementing that outside
Hi!
> > > And then storing RGB in separate bytes, so userspace will then
> > > always send a buffer of 192 bytes per line (64x3) x 14 rows
> > > = 3072 bytes. With the kernel driver ignoring parts of
> > > the buffer where there are no actual keys.
> > That's really really weird interface. If you
Hi!
> >> 2. Implement per-key keyboards as auxdisplay
> >>
> >> - Pro:
> >>
> >> - Already has a concept for led positions
> >>
> >> - Is conceptually closer to "multiple leds forming a singular
> >> entity"
> >>
> >> - Con:
> >>
> >> - No preexisting UPower
Hi!
> We have an upcoming device that has a per-key keyboard backlight, but does
> the control completely via a wmi/acpi interface. So no usable hidraw here
> for a potential userspace driver implementation ...
>
> So a quick summary for the ideas floating in this thread so far:
>
> 1. Expand
Hi!
> > > From: Ziqi Zhao
> > >
> > > [ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]
> > >
> > > The connector_set contains uninitialized values when allocated with
> > > kmalloc_array. However, in the "out" branch, the logic assumes that any
> > > element in connector_set would
Hi!
In 6.8-rc0, driver for gc2145 (front camera on pinephone) was merged,
but we don't have corresponding dts entries. Does anyone have setup
where they can fix it easily?
[If you have hints how to set-up pinephone for kernel development,
that would be welcome. Currently I have mobian with
Hi!
> [ Upstream commit 66e92e23a72761f5b53f970aeb1badc5fd92fc74 ]
>
> Some ThinkPad systems ECFW use non-standard addresses for fan control
> and reporting. This patch adds support for such ECFW so that it can report
> the correct fan values.
> Tested on Thinkpads L13 Yoga Gen 2 and X13 Yoga
On Mon 2023-10-23 13:44:46, Miguel Ojeda wrote:
> On Mon, Oct 23, 2023 at 1:40 PM Jani Nikula
> wrote:
> >
> > One could also reasonably make the argument that controlling the
> > individual keyboard key backlights should be part of the input
> > subsystem. It's not a display per se. (Unless you
Hi!
> >> So... a bit of rationale. The keyboard does not really fit into the
> >> LED subsystem; LEDs are expected to be independent ("hdd led") and not
> >> a matrix of them.
> >
> > Makes sense.
> >
> >> We do see various strange displays these days -- they commonly have
> >> rounded corners
Hi!
> > > > > > diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
> > > > > > index 5a5d07b9a7..0232fa84de 100644
> > > > > > --- a/drivers/led/led-uclass.c
> > > > > > +++ b/drivers/led/led-uclass.c
> > > > > > @@ -71,7 +71,9 @@ static int led_post_bind(struct udevice *dev)
> > >
Hi!
> > > From: Alex Deucher
> > >
> > > [ Upstream commit 49afe91370b86566857a3c2c39612cf098110885 ]
> > >
> > > For pptable structs that use flexible array sizes, use flexible arrays.
> > >
> > > Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039926
> > > Reviewed-by: Mario
Hi!
> > > From: Alex Deucher
> > >
> > > [ Upstream commit 49afe91370b86566857a3c2c39612cf098110885 ]
> > >
> > > For pptable structs that use flexible array sizes, use flexible arrays.
> > >
> > > Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039926
> > > Reviewed-by: Mario
Hi!
> This patchset adds three secure heaps:
> 1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path).
>The buffer is reserved for the secure world after bootup and it is used
>for vcodec's ES/working buffer;
> 2) secure_mtk_cma: secure CMA memory for MediaTek SVP.
Hi!
> This serie adds support for the GalaxyCore GC2145 sensor.
> Initialization is based on scripts provided by GalaxyCore,
> allowing 3 fixed configurations supported for the time being.
There is another version of the driver, from Ondrej Jirman, floating
around. See mail "gc2145 camera driver
Hi!
> I'm pleased to announce the 5.10.199-rt97 stable release.
>
> This release is an update to the new stable 5.10.199 version and no
> RT-specific changes were made, with the exception of a fix to a build
> failure due to upstream changes affecting only the PREEMPT_RT code.
Thanks for the
Hi!
> Some replacement displays include third-party touch ICs which are
> devoid of register descriptors. Create a fake data register descriptor
> for such ICs and provide hardcoded default values.
>
> It isn't possible to reliably determine if the touch IC is original or
> not, so these
Hi!
> With the driver for ktd2026 recently applied to linux-leds[1], the LED
> can be enabled on longcheer l8910 and l9100.
Please make sure sysfs name is consistent with notification LED on
other phones, as documented by well-known-leds.txt.
Best regards,
Hi!
> + led-1 {
> + function = LED_FUNCTION_FLASH;
> + color = ;
That's warm white, not yellow. We should likely create a define for
that.
BR,
Pavel
--
Hi!
> > An orthogonal issue is labeling all of those regions. I think we should
> > start with fully obscured areas and maybe less readable ones like the
> > waterfall edges. Still, different features should live on different
> > masks – even if we don't attach meaningfull labels (like 'notch' or
Hi!
> > Initial support for Xiaomi Pad 6 tablet, that have sm8250 soc.
> >
> > Signed-off-by: Luka Panio
> > +++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-pipa.dts
> > @@ -0,0 +1,625 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
>
> If there are no other copyrights here, why did you use
On Thu 2023-09-28 18:57:18, Paolo Bonzini wrote:
> On 9/28/23 09:50, Mikulas Patocka wrote:
> > > > Fix the bugs and then change the definition of MAX_ORDER to be
> > > > inclusive: the range of orders user can ask from buddy allocator is
> > > > 0..MAX_ORDER now.
> > I think that exclusive
Hi!
> coming from the leds mailing list I'm writing with Pavel how to best handle
> per-key RGB keyboards.
>
> His suggestion was that it could be implemented as an aux display, but he
> also suggested that I ask first if this fits.
Thanks for doing this.
> The specific keyboard RGB controller
Hi!
> > The specific keyboard RGB controller I want to implement takes 6*21 rgb
> > values. However not every one is actually mapped to a physical key. e.g. the
> > bottom row needs less entries because of the space bar. Additionally the
> > keys are ofc not in a straight line from top to bottom.
Hi!
> > I'm having some fun with usb host. Good news is it works with
> > externally powered hub... after a while. I get some error messages
> > about inability to go host mode, but with enough patience it
> > eventually does enter host mode and I see my keyboard/mouse.
> >
> > And usually in
Hi!
I'm having some fun with usb host. Good news is it works with
externally powered hub... after a while. I get some error messages
about inability to go host mode, but with enough patience it
eventually does enter host mode and I see my keyboard/mouse.
And usually in that process, one of my
Hi!
> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ]
>
> When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following
> warning appears:
>
> In function ‘fortify_memcpy_chk’,
> inlined from ‘size_entry_mwt’ at net/bridge/netfilter/ebtables.c:2118:2:
>
Hi!
> From: AngeloGioacchino Del Regno
>
> [ Upstream commit fd70e2019bfbcb0ed90c5e23839bf510ce6acf8f ]
>
> Change logging from drm_{err,info}() to dev_{err,info}() in functions
> mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be
> essential to avoid getting NULL pointer kernel
On Thu 2023-09-07 11:44:57, Jan Kara wrote:
> On Wed 06-09-23 18:52:39, Mikulas Patocka wrote:
> > On Wed, 6 Sep 2023, Christian Brauner wrote:
> > > On Wed, Sep 06, 2023 at 06:01:06PM +0200, Mikulas Patocka wrote:
> > > > > > BTW. what do you think that unmount of a frozen filesystem should
> >
Hi!
> What I wanted to suggest is that we should provide means how to make sure
> block device is not being modified and educate admins and tool authors
> about them. Because just doing "umount /dev/sda1" and thinking this means
> that /dev/sda1 is unused now simply is not enough in today's world
Hi!
> From: hackyzh002
>
> [ Upstream commit f828b681d0cd566f86351c0b913e6cb6ed8c7b9c ]
>
> The type of size is unsigned, if size is 0x4000, there will be an
> integer overflow, size will be zero after size *= sizeof(uint32_t),
> will cause uninitialized memory to be referenced later
I
Hi!
> From: hackyzh002
>
> [ Upstream commit f828b681d0cd566f86351c0b913e6cb6ed8c7b9c ]
>
> The type of size is unsigned, if size is 0x4000, there will be an
> integer overflow, size will be zero after size *= sizeof(uint32_t),
> will cause uninitialized memory to be referenced later
I
Hi!
> From: Helge Deller
>
> [ Upstream commit 5cf9a090a39c97f4506b7b53739d469b1c05a7e9 ]
>
> Add missing cleanups in error path.
If we insist this is important enough for -stable, it will need
tweaking. The function returns void, so we can't return a value.
Best regards,
Hi!
> > Am 04.04.23 um 06:01 schrieb Sui Jingfeng:
> >> EFI FB, VESA FB or VGA FB etc are belong to firmware based framebuffer
> >> driver.
> >
>
...
> I fixed that before applying, also removed the "are" in the sentence
> above, since it sounded off and repharsed subject line as "Fix typos
On Wed 2023-03-22 10:05:13, Rodrigo Siqueira wrote:
> Cc: Anthony Koo
> Cc: Iswara Negulendran
> Cc: Felipe Clark
> Cc: Harry Wentland
> Signed-off-by: Rodrigo Siqueira
Some changelog would be useful.
> +++ b/include/drm/display/drm_dp.h
> @@ -977,6 +977,8 @@
> # define
On Wed 2023-03-22 10:05:13, Rodrigo Siqueira wrote:
> Cc: Anthony Koo
> Cc: Iswara Negulendran
> Cc: Felipe Clark
> Cc: Harry Wentland
> Signed-off-by: Rodrigo Siqueira
Some changelog would be useful.
> +++ b/include/drm/display/drm_dp.h
> @@ -977,6 +977,8 @@
> # define
Hi!
> > +config LEDS_AW200XX
> > + tristate "LED support for Awinic AW20036/AW20054/AW20072"
> > + depends on LEDS_CLASS
> > + depends on I2C
> > + help
> > + This option enables support for the AW20036/AW20054/AW20072 LED
> > driver.
> > + It is a 3x12/6x9/6x12 matrix LED driver
Hi!
> This series add support for the display present in the PinePhone Pro.
>
> Patch #1 adds a driver for panels using the Himax HX8394 panel controller,
> such as the HSD060BHW4 720x1440 TFT LCD panel present in the PinePhone Pro.
>
> Patch #2 adds a devicetree binding schema for this driver
On Tue 2022-12-20 13:45:19, Steven Rostedt wrote:
> [
> Linus,
>
> I ran the script against your latest master branch:
> commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
>
> As the timer_shutdown*() code is now in your tree, I figured
> we can start doing the conversions. At
On Tue 2022-12-20 13:45:19, Steven Rostedt wrote:
> [
> Linus,
>
> I ran the script against your latest master branch:
> commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
>
> As the timer_shutdown*() code is now in your tree, I figured
> we can start doing the conversions. At
On Tue 2022-12-20 13:45:19, Steven Rostedt wrote:
> [
> Linus,
>
> I ran the script against your latest master branch:
> commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
>
> As the timer_shutdown*() code is now in your tree, I figured
> we can start doing the conversions. At
o for now all drivers return success unconditionally. They are adapted
> in the following patches to make the changes easier reviewable.
>
> Signed-off-by: Uwe Kleine-König
LED part:
Acked-by: Pavel Machek
Best regards,
Pavel
> sta
Hi!
> > I used to be able to do:
> >
> > pavel@duo:~$ xrandr --output HDMI1 --mode 1920x1080 --primary
> > warning: output HDMI1 not found; ignoring
> > pavel@duo:~$ xrandr --output VGA1 --mode 1280x1024 --below HDMI1
> > warning: output VGA1 not found; ignoring
> >
> > ...but now I
Hi!
I used to be able to do:
pavel@duo:~$ xrandr --output HDMI1 --mode 1920x1080 --primary
warning: output HDMI1 not found; ignoring
pavel@duo:~$ xrandr --output VGA1 --mode 1280x1024 --below HDMI1
warning: output VGA1 not found; ignoring
...but now I have to do:
pavel@duo:~$
Hi!
> From: Kees Cook
>
> [ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
>
> Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
> and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
> offset. Work around this by using a direct assignment of
Hi!
> From: Wen Gong
>
> [ Upstream commit 1e1cb8e0b73e6f39a9d4a7a15d940b1265387eb5 ]
>
> When running suspend test, kernel crash happened in ath10k, and it is
> fixed by commit b72a4aff947b ("ath10k: skip ath10k_halt during suspend
> for driver state RESTARTING").
>
> Currently the crash is
Hi!
> From: Marco Elver
>
> [ Upstream commit f95e5a3d59011eec1257d0e76de1e1f8969d426f ]
>
> Internal data structures (cpu_bps, task_bps) of powerpc's hw_breakpoint
> implementation have relied on nr_bp_mutex serializing access to them.
>
> Before overhauling synchronization of
Hi!
> From: Kees Cook
>
> [ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
>
> Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
> and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
> offset. Work around this by using a direct assignment of
Hi!
> From: Alyssa Rosenzweig
>
> [ Upstream commit 382435709516c1a7dc3843872792abf95e786c83 ]
>
> Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
> from kbase. kbase lists this workaround as used on Mali-G57.
AFAICT this quirk is not used anywhere in 5.10, and its users
Hi!
In this series, I only received patches up-to 42/46. Is problem at sender or
receiver?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
Hi!
> From: Alice Chen
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual Flash
> LED current sources, a RGB LED driver, a backlight WLED
Hi!
> From: ChiYuan Huang
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current sources, a RGB LED driver, a backlight WLED
On Fri 2022-07-22 18:23:58, ChiaEn Wu wrote:
> From: Alice Chen
>
> Add MediaTek MT6370 flashlight binding documentation.
>
> Signed-off-by: Alice Chen
> Reviewed-by: Krzysztof Kozlowski
You'll need to get sign-offs right... And review from dt people before
this can be applied.
Best
> way driver authors are not tempted to assume that passing an error to
> the upper layer is a good idea. All drivers are adapted accordingly.
> There is no intended change of behaviour, all callbacks were prepared to
> return 0 before.
>
> Signed-off-by: Uwe Kleine-König
2-4
> way driver authors are not tempted to assume that passing an error to
> the upper layer is a good idea. All drivers are adapted accordingly.
> There is no intended change of behaviour, all callbacks were prepared to
> return 0 before.
>
> Signed-off-by: Uwe Kleine-König
2-4
> way driver authors are not tempted to assume that passing an error to
> the upper layer is a good idea. All drivers are adapted accordingly.
> There is no intended change of behaviour, all callbacks were prepared to
> return 0 before.
>
> Signed-off-by: Uwe Kleine-König
2-4
Hi!
> Going forward, I'll be using my kernel.org for upstream work.
>
Acked-by: Pavel Machek
Let me know if you want to take it through the LED tree.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on U
Hi!
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current sources, a RGB LED driver, a backlight WLED driver,
> a display bias
Hi!
> [ Upstream commit 5491424d17bdeb7b7852a59367858251783f8398 ]
>
> clk_put() already checks the clk ptr using !clk and IS_ERR()
> so there is no need to check it again before calling it.
Nice cleanup, but not a bugfix; we don't need it in -stable.
Best regards,
Hi!
> From: Xiang wangx
>
> [ Upstream commit fc378794a2f7a19cf26010dc33b89ba608d4c70f ]
>
> Delete the redundant word 'its'.
Calling typo in comment "syntax error" is ... interesting. Anyway, we
don't need this in stable.
Best regards,
Hi!
> From: Maxime Ripard
>
> [ Upstream commit 2523e9dcc3be91bf9fdc0d1e542557ca00bbef42 ]
>
> We'll need to extend the vc4_async_flip_state structure to rely on
> another callback implementation, so let's move the current one into a
> union.
This and [04/22] drm/vc4: crtc: Use an union to
Hi!
> > > AFAICS, the read-unfair rwsem code is created to resolve a potential
> > > lock starvation problem that they found on linux-5.10.y stable tree. I
> > > believe I have fixed that in the v5.11 kernel, see commit 2f06f702925
> > > ("locking/rwsem: Prevent potential lock starvation").
> >
1 - 100 of 23434 matches
Mail list logo
