On Fri, 26 Jan 2024 15:24:17 -0500
Mathieu Desnoyers wrote:
> On 2024-01-26 15:12, Steven Rostedt wrote:
> [...]
> > diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
> > index e1b172c0e091..2187be6d7b23 100644
> > --- a/fs/tracefs/inode.c
> > +++ b/fs/tracefs/inode.c
> > @@ -223,13 +223,41
On 2024-01-26 15:12, Steven Rostedt wrote:
[...]
diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index e1b172c0e091..2187be6d7b23 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -223,13 +223,41 @@ static const struct inode_operations
tracefs_file_inode_operations = {
From: "Steven Rostedt (Google)"
Linus suggested to use the same inode numbers to make it easier to
implement getdents(), as it was creating inodes just for generating a
unique and consistent inode number. Linus suggested to just use the same
inode for all files and directori
On Tue, Apr 20, 2021 at 12:32:18AM -0700, Drew Fustini wrote:
> On Thu, Apr 15, 2021 at 04:03:56PM +0300, Andy Shevchenko wrote:
> > The commit f1b206cf7c57 ("pinctrl: core: print gpio in pins debugfs file")
> > enabled GPIO pin number and label in debugfs for pin controller. However,
> > it
On Thu, Apr 15, 2021 at 04:03:56PM +0300, Andy Shevchenko wrote:
> The commit f1b206cf7c57 ("pinctrl: core: print gpio in pins debugfs file")
> enabled GPIO pin number and label in debugfs for pin controller. However,
> it limited that feature to the chips where base is positive number. This,
> in
On Mon, Apr 19, 2021 at 3:04 AM Andy Shevchenko
wrote:
>
> On Thu, Apr 15, 2021 at 4:07 PM Andy Shevchenko
> wrote:
> >
> > The commit f1b206cf7c57 ("pinctrl: core: print gpio in pins debugfs file")
> > enabled GPIO pin number and label in debugfs for pin controller. However,
> > it limited that
On Thu, Apr 15, 2021 at 4:07 PM Andy Shevchenko
wrote:
>
> The commit f1b206cf7c57 ("pinctrl: core: print gpio in pins debugfs file")
> enabled GPIO pin number and label in debugfs for pin controller. However,
> it limited that feature to the chips where the base is a positive number.
> This,
>
The commit f1b206cf7c57 ("pinctrl: core: print gpio in pins debugfs file")
enabled GPIO pin number and label in debugfs for pin controller. However,
it limited that feature to the chips where base is positive number. This,
in particular, excluded chips where base is 0 for the historical or
From: Eli Cohen
[ Upstream commit 4b454a82418dd76d8c0590bb3f7a99a63ea57dc5 ]
VIRTIO_F_VERSION_1 is a bit number. Use BIT_ULL() with mask
conditionals.
Also, in mlx5_vdpa_is_little_endian() use BIT_ULL for consistency with
the rest of the code.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver
From: Eli Cohen
[ Upstream commit 4b454a82418dd76d8c0590bb3f7a99a63ea57dc5 ]
VIRTIO_F_VERSION_1 is a bit number. Use BIT_ULL() with mask
conditionals.
Also, in mlx5_vdpa_is_little_endian() use BIT_ULL for consistency with
the rest of the code.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver
Kernel has supported COMETLAKE/COMETLAKE_L to use the SKYLAKE
events and supported TIGERLAKE_L/TIGERLAKE/ROCKETLAKE to use
the ICELAKE events. But pmu-events mapfile.csv is missing
these model numbers.
Now add the missing model numbers to mapfile.csv.
Signed-off-by: Jin Yao
---
tools/perf/pmu
These were untouched since 2.3.99-pre3, and the explanatory comment for
HID_DG_TIPPRESSURE is TipPressure in other places
Signed-off-by: Ahelenia Ziemiańska
---
drivers/hid/hid-input.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-input.c
On Tue, Mar 02, 2021 at 07:23:06AM +0200, Eli Cohen wrote:
> On Mon, Mar 01, 2021 at 10:33:14AM -0500, Michael S. Tsirkin wrote:
> > On Mon, Mar 01, 2021 at 03:52:45PM +0800, Jason Wang wrote:
> > >
> > > On 2021/3/1 2:28 下午, Eli Cohen wrote:
> > > > VIRTIO_F_VERSION_1 is a bit number. Use
On Mon, Mar 01, 2021 at 10:33:14AM -0500, Michael S. Tsirkin wrote:
> On Mon, Mar 01, 2021 at 03:52:45PM +0800, Jason Wang wrote:
> >
> > On 2021/3/1 2:28 下午, Eli Cohen wrote:
> > > VIRTIO_F_VERSION_1 is a bit number. Use BIT_ULL() with mask
> > > conditionals.
> > >
> > > Also, in
On Mon, Mar 01, 2021 at 03:52:45PM +0800, Jason Wang wrote:
>
> On 2021/3/1 2:28 下午, Eli Cohen wrote:
> > VIRTIO_F_VERSION_1 is a bit number. Use BIT_ULL() with mask
> > conditionals.
> >
> > Also, in mlx5_vdpa_is_little_endian() use BIT_ULL for consistency with
> > the rest of the code.
> >
>
On 2021/3/1 2:28 下午, Eli Cohen wrote:
VIRTIO_F_VERSION_1 is a bit number. Use BIT_ULL() with mask
conditionals.
Also, in mlx5_vdpa_is_little_endian() use BIT_ULL for consistency with
the rest of the code.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
VIRTIO_F_VERSION_1 is a bit number. Use BIT_ULL() with mask
conditionals.
Also, in mlx5_vdpa_is_little_endian() use BIT_ULL for consistency with
the rest of the code.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Eli Cohen
---
These were untouched since 2.3.99-pre3, and the explanatory comment for
HID_DG_TIPPRESSURE is TipPressure on other places
Signed-off-by: Ahelenia Ziemiańska
---
drivers/hid/hid-input.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-input.c
oot: Total of 256 processors activated (1147449.34
> > BogoMIPS)
>
> Yes, the intention is clear, but it’s not working perfectly in all
> situations. Any ideas, how to improve that? After reading John’s response,
> I’d go with `pr_cont(KERN_INFO "message part");`.
>
&
perfectly in all
situations. Any ideas, how to improve that? After reading John’s
response, I’d go with `pr_cont(KERN_INFO "message part");`.
By the way, what are these CPU numbers useful for? Isn’t
smp: Brought up 2 nodes, 256 CPUs
enough information, and nothing else needed for th
But it is supported.
Sounds ok to me. I leave it up to you guys to decide whether we wanna
change that there.
But I don't care that much about the CPU numbers ending up getting
issued at warning level so we can just as well do nothing and leave it
as is.
Thx.
--
Regards/Gruss,
Boris.
ht
On 2021-02-16, Borislav Petkov wrote:
>> Also you should add '\n' into the previous string to make the behavior
>> clear. It will always be printed on a new line when pr_info()
>> is used.
>
> This was made to use pr_cont() on purpose so that the output is
> compact,
It is supported to provide
Dear Petr,
Thank you for the quick reply.
Am 16.02.21 um 10:49 schrieb Petr Mladek:
On Mon 2021-02-15 20:22:34, Paul Menzel wrote:
Using Linux 5.10.13 (and before), looking at the Linux kernel warnings, the
CPU numbers show up. For example with 12 cpus/threads:
```
$ sudo dmesg --level
On Tue, Feb 16, 2021 at 10:49:04AM +0100, Petr Mladek wrote:
> Also you should add '\n' into the previous string to make the behavior
> clear. It will always be printed on a new line when pr_info()
> is used.
This was made to use pr_cont() on purpose so that the output is compact,
for example:
[
On Mon 2021-02-15 20:22:34, Paul Menzel wrote:
> Dear Linux folks,
>
>
> Using Linux 5.10.13 (and before), looking at the Linux kernel warnings, the
> CPU numbers show up. For example with 12 cpus/threads:
>
> ```
> $ sudo dmesg --level=warn
> [0.216103]
Dear Linux folks,
Using Linux 5.10.13 (and before), looking at the Linux kernel warnings,
the CPU numbers show up. For example with 12 cpus/threads:
```
$ sudo dmesg --level=warn
[0.216103] #2
[0.220105] #3
[0.224103] #4
[0.228104] #5
[0.232110] #6
[0.236101
Il 11/02/21 21:19, Stephen Boyd ha scritto:
Quoting AngeloGioacchino Del Regno (2021-01-13 10:38:13)
The function clk_gfx3d_determine_rate is selecting different PLLs
to manage the GFX3D clock source in a special way: this one needs
to be ping-pong'ed on different PLLs to ensure stability
Quoting AngeloGioacchino Del Regno (2021-01-13 10:38:13)
> The function clk_gfx3d_determine_rate is selecting different PLLs
> to manage the GFX3D clock source in a special way: this one needs
> to be ping-pong'ed on different PLLs to ensure stability during
> frequency switching (set a PLL rate,
Port F IRQ's should be statically mapped to EP93XX_GPIO_F_IRQ_BASE.
So we need to specify girq->first otherwise:
"If device tree is used, then first_irq will be 0 and
IRQ's get mapped dynamically on the fly"
And that's not the thing we want.
Reviewed-by: Linus Walleij
Acked-by: Alexander
Port F IRQ's should be statically mapped to EP93XX_GPIO_F_IRQ_BASE.
So we need to specify girq->first otherwise:
"If device tree is used, then first_irq will be 0 and
IRQ's get mapped dynamically on the fly"
And that's not the thing we want.
Reviewed-by: Linus Walleij
Acked-by: Alexander
Em Sat, 6 Feb 2021 11:18:15 +0100
Hans Verkuil escreveu:
> >> Yes, driver "version" means nothing, so functionality is the correct way
> >> to handle this.
> >>
> >> Any chance you all can just drop the kernel version stuff and just
> >> report a static number that never goes up to allow people
On 06/02/2021 10:48, Mauro Carvalho Chehab wrote:
> Em Sat, 6 Feb 2021 10:29:10 +0100
> Greg Kroah-Hartman escreveu:
>
>> On Sat, Feb 06, 2021 at 10:24:02AM +0100, Mauro Carvalho Chehab wrote:
>>> Em Sat, 6 Feb 2021 08:20:45 +0100
>>> Greg Kroah-Hartman escreveu:
>>>
On Fri, Feb 05,
Em Sat, 6 Feb 2021 10:29:10 +0100
Greg Kroah-Hartman escreveu:
> On Sat, Feb 06, 2021 at 10:24:02AM +0100, Mauro Carvalho Chehab wrote:
> > Em Sat, 6 Feb 2021 08:20:45 +0100
> > Greg Kroah-Hartman escreveu:
> >
> > > On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
>
On Sat, Feb 06, 2021 at 10:24:02AM +0100, Mauro Carvalho Chehab wrote:
> Em Sat, 6 Feb 2021 08:20:45 +0100
> Greg Kroah-Hartman escreveu:
>
> > On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
> > > Em Fri, 5 Feb 2021 12:31:05 -0500
> > > Tony Battersby escreveu:
> > >
Em Sat, 6 Feb 2021 08:20:45 +0100
Greg Kroah-Hartman escreveu:
> On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
> > Em Fri, 5 Feb 2021 12:31:05 -0500
> > Tony Battersby escreveu:
> >
> > > On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > > > Agreed. But currently, sublevel
On Fri, Feb 05, 2021 at 07:44:12PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Ugh, I thought this was an internal representation, not an external one
> > > > :(
> > > >
> > > > > It might work somewhere, but there are a lot of (X * 65536 + Y * 256
> > > > > + Z)
> > > > > assumptions all around
On Fri, Feb 05, 2021 at 12:31:05PM -0500, Tony Battersby wrote:
> On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> > patchlevel. And that might be a problem. So we might need to update the
> > header generation using e.g. "sublevel &
On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
> Em Fri, 5 Feb 2021 12:31:05 -0500
> Tony Battersby escreveu:
>
> > On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > > Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> > > patchlevel. And that might be a
Em Fri, 5 Feb 2021 12:31:05 -0500
Tony Battersby escreveu:
> On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> > patchlevel. And that might be a problem. So we might need to update the
> > header generation using e.g. "sublevel &
Hi!
> > > Ugh, I thought this was an internal representation, not an external one
> > > :(
> > >
> > > > It might work somewhere, but there are a lot of (X * 65536 + Y * 256 +
> > > > Z)
> > > > assumptions all around the world. So this doesn't look like a good idea.
> > >
> > > Ok, so what
On 2/4/21 6:00 AM, Jiri Slaby wrote:
> Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> patchlevel. And that might be a problem. So we might need to update the
> header generation using e.g. "sublevel & 0xff" (wrap around) or
> "sublevel > 255 : 255 : sublevel" (be
t 05:59:42AM +, Jari Ruusu wrote:
> > > > > Greg,
> > > > > I hope that your linux kernel release scripts are
> > > > > implemented in a way that understands that PATCHLEVEL= and
> > > > > SUBLEVEL= numbers in top-level linux Makefile
> I hope that your linux kernel release scripts are
> > > > implemented in a way that understands that PATCHLEVEL= and
> > > > SUBLEVEL= numbers in top-level linux Makefile are encoded
> > > > as 8-bit numbers for LINUX_VERSION_CODE and
> > > > KERNEL_
Port F irq's should be statically mapped to EP93XX_GPIO_F_IRQ_BASE.
So we need to specify girq->first otherwise:
"If device tree is used, then first_irq will be 0 and
irqs get mapped dynamically on the fly"
And that's not the thing we want.
Signed-off-by: Nikita Shubin
---
be better.
>
> Hitting such version checks still might happen, though.
By who? For what?
> Also, any wrapping introduces a real risk package managers will see
> version numbers running backwards and therefore will refrain from
> installing an actually newer version.
packag
ntroduces a real risk package managers will see
version numbers running backwards and therefore will refrain from
installing an actually newer version.
For scripts/package/builddeb (I don't use that, though), you could work
around by setting an epoch, i.e. (untested)
-$sourcename ($packa
On Thu, Feb 04, 2021 at 04:28:19PM +, David Laight wrote:
> From: Jiri Slaby
> > Sent: 04 February 2021 11:01
> >
> > On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
> > >> It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> > >> assumptions all around the world. So
From: Jiri Slaby
> Sent: 04 February 2021 11:01
>
> On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
> >> It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> >> assumptions all around the world. So this doesn't look like a good idea.
> >
> > Ok, so what happens if we "wrap"?
On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
assumptions all around the world. So this doesn't look like a good idea.
Ok, so what happens if we "wrap"? What will break with that? At first
glance, I can't see anything
mplemented in a way that understands that PATCHLEVEL= and
> > > SUBLEVEL= numbers in top-level linux Makefile are encoded
> > > as 8-bit numbers for LINUX_VERSION_CODE and
> > > KERNEL_VERSION() macros, and must stay in range 0...255.
> > > These 8-bit limits are hardcoded i
On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote:
Greg,
I hope that your linux kernel release scripts are
implemented in a way that understands that PATCHLEVEL= and
SUBLEVEL= numbers in top-level linux Makefile are encoded
as 8-bit
On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote:
> Greg,
> I hope that your linux kernel release scripts are
> implemented in a way that understands that PATCHLEVEL= and
> SUBLEVEL= numbers in top-level linux Makefile are encoded
> as 8-bit numbers for LIN
Greg,
I hope that your linux kernel release scripts are
implemented in a way that understands that PATCHLEVEL= and
SUBLEVEL= numbers in top-level linux Makefile are encoded
as 8-bit numbers for LINUX_VERSION_CODE and
KERNEL_VERSION() macros, and must stay in range 0...255.
These 8-bit limits
; > must know to which revision of the spec each conforms.
> > >
> > > This series adds individual version numbers for the partner and the cable,
> > > and exposes them in the appropriate sysfs in /sys/class/typec.
> > >
> > > I provide as a first implementation of t
ther Revision 2 or
> > Revision 3 signaling and protocol. In order for userspace and the kernel
> > to properly process the data objects received from a particular SOP*, we
> > must know to which revision of the spec each conforms.
> >
> > This series adds individual
t;> Revision 3 signaling and protocol. In order for userspace and the kernel
>> to properly process the data objects received from a particular SOP*, we
>> must know to which revision of the spec each conforms.
>>
>> This series adds individual version numbers for the partner an
erly process the data objects received from a particular SOP*, we
> must know to which revision of the spec each conforms.
>
> This series adds individual version numbers for the partner and the cable,
> and exposes them in the appropriate sysfs in /sys/class/typec.
>
> I pro
he kernel
> to properly process the data objects received from a particular SOP*, we
> must know to which revision of the spec each conforms.
>
> This series adds individual version numbers for the partner and the cable,
> and exposes them in the appropriate sysfs in /sys/class/typec.
&
must know to which revision of the spec each conforms.
This series adds individual version numbers for the partner and the cable,
and exposes them in the appropriate sysfs in /sys/class/typec.
I provide as a first implementation of this, platform/chrome's cros_ec_typec
driver, whose underlying
Hi!
On Thu, 2021-01-28 at 15:21 +0300, Nikita Shubin wrote:
> Port F irq's should be statically mapped to EP93XX_GPIO_F_IRQ_BASE.
>
> So we need to specify girq->first otherwise:
>
> "If device tree is used, then first_irq will be 0 and
> irqs get mapped dynamically on the fly"
>
> And that's
Port F irq's should be statically mapped to EP93XX_GPIO_F_IRQ_BASE.
So we need to specify girq->first otherwise:
"If device tree is used, then first_irq will be 0 and
irqs get mapped dynamically on the fly"
And that's not the thing we want.
Signed-off-by: Nikita Shubin
---
Hi!
On Wed, 2021-01-27 at 13:46 +0300, Nikita Shubin wrote:
> Port F irq's should be statically mapped to EP93XX_GPIO_F_IRQ_BASE.
>
> So we need to specify girq->first otherwise:
>
> "If device tree is used, then first_irq will be 0 and
> irqs get mapped dynamically on the fly"
>
> And that's
On Wed, Jan 27, 2021 at 11:46 AM Nikita Shubin
wrote:
> Port F irq's should be statically mapped to EP93XX_GPIO_F_IRQ_BASE.
>
> So we need to specify girq->first otherwise:
>
> "If device tree is used, then first_irq will be 0 and
> irqs get mapped dynamically on the fly"
>
> And that's not the
On Wed, Jan 27, 2021 at 07:58:26AM +, Chaitanya Kulkarni wrote:
> > On Jan 26, 2021, at 11:41 PM, Chaitanya Kulkarni
> > wrote:
> > On 1/26/21 14:14, Bjorn Helgaas wrote:
> >> From: Bjorn Helgaas
> >>
> >> Use PCI #defines for PCIe Device Control register values instead of
> >>
Port F irq's should be statically mapped to EP93XX_GPIO_F_IRQ_BASE.
So we need to specify girq->first otherwise:
"If device tree is used, then first_irq will be 0 and
irqs get mapped dynamically on the fly"
And that's not the thing we want.
Signed-off-by: Nikita Shubin
---
> On Jan 26, 2021, at 11:41 PM, Chaitanya Kulkarni
> wrote:
>
> On 1/26/21 14:14, Bjorn Helgaas wrote:
>> From: Bjorn Helgaas
>>
>> Use PCI #defines for PCIe Device Control register values instead of
>> hard-coding bit positions. No functional change intended.
>>
>> Signed-off-by: Bjorn
On 1/26/21 14:14, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Use PCI #defines for PCIe Device Control register values instead of
> hard-coding bit positions. No functional change intended.
>
> Signed-off-by: Bjorn Helgaas
I've verified the values present in the
From: Bjorn Helgaas
Use PCI #defines for PCIe Device Control register values instead of
hard-coding bit positions. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/block/mtip32xx/mtip32xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
The function clk_gfx3d_determine_rate is selecting different PLLs
to manage the GFX3D clock source in a special way: this one needs
to be ping-pong'ed on different PLLs to ensure stability during
frequency switching (set a PLL rate, let it stabilize, switch the
RCG to the new PLL) and fast
In function dsi_pll_calc_dec_frac we are calculating the decimal
div start parameter by dividing the decimal multiple by the
fractional multiplier: the remainder of that operation is stored
to then get programmed to the fractional divider registers of
the PLL.
It's useless to call div_u64_rem to
From: Krzysztof Kozlowski
[ Upstream commit d8f0a86795c69f5b697f7d9e5274c124da93c92d ]
GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
signed integers, where negative number indicates error. The return
value of of_get_named_gpio() should not be assigned to an unsigned
From: Krzysztof Kozlowski
[ Upstream commit d8f0a86795c69f5b697f7d9e5274c124da93c92d ]
GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
signed integers, where negative number indicates error. The return
value of of_get_named_gpio() should not be assigned to an unsigned
From: Krzysztof Kozlowski
[ Upstream commit d8f0a86795c69f5b697f7d9e5274c124da93c92d ]
GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
signed integers, where negative number indicates error. The return
value of of_get_named_gpio() should not be assigned to an unsigned
From: Krzysztof Kozlowski
[ Upstream commit d8f0a86795c69f5b697f7d9e5274c124da93c92d ]
GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
signed integers, where negative number indicates error. The return
value of of_get_named_gpio() should not be assigned to an unsigned
From: Krzysztof Kozlowski
[ Upstream commit d8f0a86795c69f5b697f7d9e5274c124da93c92d ]
GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
signed integers, where negative number indicates error. The return
value of of_get_named_gpio() should not be assigned to an unsigned
From: Krzysztof Kozlowski
[ Upstream commit d8f0a86795c69f5b697f7d9e5274c124da93c92d ]
GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
signed integers, where negative number indicates error. The return
value of of_get_named_gpio() should not be assigned to an unsigned
On 11/27/20, Bongsu Jeon wrote:
> On Fri, Nov 27, 2020 at 2:06 AM Krzysztof Kozlowski
> wrote:
>>
>> On Fri, Nov 27, 2020 at 12:33:37AM +0900, bongsu.je...@gmail.com wrote:
>> > From: Krzysztof Kozlowski
>> >
>> > GPIOs - as returned by of_get_named_gpio() and used by the gpiolib -
>> > are
>>
On Fri, Nov 27, 2020 at 2:06 AM Krzysztof Kozlowski wrote:
>
> On Fri, Nov 27, 2020 at 12:33:37AM +0900, bongsu.je...@gmail.com wrote:
> > From: Krzysztof Kozlowski
> >
> > GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
> > signed integers, where negative number
On Fri, Nov 27, 2020 at 12:33:37AM +0900, bongsu.je...@gmail.com wrote:
> From: Krzysztof Kozlowski
>
> GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
> signed integers, where negative number indicates error. The return
> value of of_get_named_gpio() should not be
From: Krzysztof Kozlowski
GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
signed integers, where negative number indicates error. The return
value of of_get_named_gpio() should not be assigned to an unsigned int
because in case of !CONFIG_GPIOLIB such number would be a
GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
signed integers, where negative number indicates error. The return
value of of_get_named_gpio() should not be assigned to an unsigned int
because in case of !CONFIG_GPIOLIB such number would be a valid GPIO.
Fixes:
This makes it consistent with other debug logs that already are using
decimal number for adapters (ports).
Signed-off-by: Mika Westerberg
---
drivers/thunderbolt/path.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thunderbolt/path.c
From: Gene Chen
Remove redundant brackets around raw numbers.
Signed-off-by: Gene Chen
Acked-for-MFD-by: Lee Jones
---
drivers/mfd/mt6360-core.c | 172 +--
include/linux/mfd/mt6360.h | 410 ++---
2 files changed, 291 insertions(+), 291
f eMMC and SD are both used they have consistent numbers across boots
> and kernel changes.
>
> Picking numbers can be tricky. Do we call these "1" and "2" to match
> the name in documentation or "0" and "1" with the assertion that we
> shou
After many years of struggle, commit fa2d0aa96941 ("mmc: core: Allow
setting slot index via device tree alias") finally allows the use of
aliases to number SD/MMC slots. Let's do that for sc7180 SoCs so that
if eMMC and SD are both used they have consistent numbers across boots
and kern
From: Mukesh Ojha
commit b29336c0e1785a28bc40a9fd47c2321671e9792e upstream.
Fixes: 8034f715f ("powernv/opal-dump: Convert to irq domain")
Converts all the return explicit number to a more proper IRQ_HANDLED,
which looks proper incase of interrupt handler returning case.
Here, It also removes
From: Mukesh Ojha
commit b29336c0e1785a28bc40a9fd47c2321671e9792e upstream.
Fixes: 8034f715f ("powernv/opal-dump: Convert to irq domain")
Converts all the return explicit number to a more proper IRQ_HANDLED,
which looks proper incase of interrupt handler returning case.
Here, It also removes
Instead of 10, 13 use \n, \r respectively.
Signed-off-by: Andy Shevchenko
Acked-by: Jiri Slaby
---
v2: added Ack (Jiri)
drivers/tty/vt/keyboard.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index
On 06. 11. 20, 15:35, Andy Shevchenko wrote:
Instead of 10, 13 use \n, \r respectively.
Signed-off-by: Andy Shevchenko
Acked-by: Jiri Slaby
---
drivers/tty/vt/keyboard.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/vt/keyboard.c
To save the interested reader some time, add examples of AT25 part
numbers that correspond to EEPROMs rather than flashes.
Signed-off-by: Jonathan Neuschäfer
---
drivers/misc/eeprom/at25.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/misc/eeprom/at25.c b/drivers/misc/eeprom
Instead of 10, 13 use \n, \r respectively.
Signed-off-by: Andy Shevchenko
---
drivers/tty/vt/keyboard.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index bfe54b9822af..647c343f61fb 100644
---
From: Gene Chen
Remove redundant brackets around raw numbers.
Signed-off-by: Gene Chen
Acked-for-MFD-by: Lee Jones
---
drivers/mfd/mt6360-core.c | 172 +--
include/linux/mfd/mt6360.h | 410 ++---
2 files changed, 291 insertions(+), 291
Some numbers are replaced by macros to avoid incomprehension.
Signed-off-by: Weili Qian
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/qm.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon
These flag is meant the bit numbers, they are
used like '(type & SLOTS_CACHE)' and so on.
Define these flags using bit numbers instead of
hardcoding powers of 2, which maybe better.
No change in the actual values.
Signed-off-by: Hui Su
---
mm/swap_slots.c | 4 ++--
mm/swapfile.c
On Sun 2020-10-25 22:48:42, Rasmus Villemoes wrote:
> The printf test suite does each test with a few different buffer sizes
> to ensure vsnprintf() behaves correctly with respect to truncation and
> size reporting. It calls vsnprintf() with a buffer size that is
> guaranteed to be big enough, a
The printf test suite does each test with a few different buffer sizes
to ensure vsnprintf() behaves correctly with respect to truncation and
size reporting. It calls vsnprintf() with a buffer size that is
guaranteed to be big enough, a buffer size of 0 to ensure that nothing
gets written to the
To view the statistics with "breakdown" mode, it's good to show the
summary numbers for the total records, all stores and all loads, then
the sequential conlumns can be used to break into more detailed items.
To achieve this purpose, this patch displays the summary numbers for
reco
To view the statistics with "breakdown" mode, it's good to show the
summary numbers for the total records, all stores and all loads, then
the sequential conlumns can be used to break into more detailed items.
To achieve this purpose, this patch displays the summary numbers for
reco
Committer: Paul E. McKenney
CommitterDate: Mon, 24 Aug 2020 18:36:04 -07:00
rcu/trace: Print negative GP numbers correctly
GP numbers start from -300 and gp_seq numbers start of -1200 (for a
shift of 2). These negative numbers are printed as unsigned long which
not only takes up more text
On Thu, Sep 17, 2020 at 04:01:17PM +0200, Ondřej Jirman wrote:
> Hello Maxime,
>
> On Thu, Sep 17, 2020 at 03:19:04PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Sat, Sep 12, 2020 at 01:22:00PM +0200, Ondrej Jirman wrote:
> > > mfd: sun4i-gpadc: I
1 - 100 of 3539 matches
Mail list logo
