On Mon, Mar 8, 2021 at 4:51 AM Marco Elver wrote:
> If we do __initconst change we need to manually remove the duplicate
> lines because we're asking the compiler to create a large array (and
> there's no more auto-dedup). If we do not remove the duplicate lines,
> the __initconst-only approach
ters_warning; -1 is an empty line. */
> + const int lines[] = { 0, 1, -1, 2, 3, 4, -1, 5, 6, 7, -1, 1, 0 };
You can save a few more bytes by making this an array of s8.
I agree with the __initconst. The rest seems overkill to me, but I
won't reject it.
Acked-by: Timur Tabi
On 2/14/21 10:13 AM, Timur Tabi wrote:
Although hashing addresses printed via printk does make the
kernel more secure, it interferes with debugging, especially
with some functions like print_hex_dump() which always uses
hashed addresses.
I believe that this version addresses all outstanding
Instead of defining the total/failed test counters manually,
test drivers that are clients of kselftest should use the
macro created for this purpose.
Signed-off-by: Timur Tabi
Reviewed-by: Petr Mladek
Acked-by: Marco Elver
---
lib/test_bitmap.c | 3 +--
lib/test_printf.c | 4 ++--
2 files
displayed if this option is enabled.
Unhashed pointers expose kernel addresses, which can be a security
risk.
Also update test_printf to skip the hashed pointer tests if the
command-line option is set.
Signed-off-by: Timur Tabi
Acked-by: Petr Mladek
Acked-by: Randy Dunlap
Acked-by: Sergey Senozhat
Update the kselftest framework to allow client drivers to
specify that some tests were skipped.
Signed-off-by: Timur Tabi
Reviewed-by: Petr Mladek
Tested-by: Petr Mladek
Acked-by: Marco Elver
---
tools/testing/selftests/kselftest_module.h | 18 --
1 file changed, 12
is disabled.
Patch #2 upgrades the printf library to check the command
line. It also updates test_printf().
Timur Tabi (3):
[v4] lib: use KSTM_MODULE_GLOBALS macro in kselftest drivers
[v4] kselftest: add support for skipped tests
[v4] lib/vsprintf: debug_never_hash_pointers prints all
On 2/12/21 4:01 AM, Petr Mladek wrote:
no_hash_pointers ?
I am fine with this.
I am still a bit scared of a bikeshedng. But AFAIK, Mathew was most
active on proposing clear names. So, when he is fine with this...
Anyway, we should use the same name also for the variable.
Ok, unless there
On 2/11/21 11:23 AM, Petr Mladek wrote:
There was some pushback against this feature in general.
It should be used deliberately and people must be aware
of the consequences. This is why it is only boot option
and why it prints such a huge warning. The long clear
name helps as well.
This is my
On 2/11/21 11:53 AM, Petr Mladek wrote:
I would really like to make it clear here that it is not only about
consoles. Most people will see only this message. Only few people read
documentation. Many people will learn the parameter name from another
context by googling.
I know that it is not
On 2/11/21 6:31 AM, Pavel Machek wrote:
Can we make this something shorter? Clearly you don't want people
placing this in their grub config, so they'll be most likely typing
this a lot...
debug_pointers or debug_ptrs would be better.
dbg_unhash_ptrs? "debug_ptrs" is too vague IMHO, and I
displayed if this option is enabled.
Unhashed pointers expose kernel addresses, which can be a security
risk.
Also update test_printf to skip the hashed pointer tests if the
command-line option is set.
Signed-off-by: Timur Tabi
Acked-by: Petr Mladek
Acked-by: Randy Dunlap
Acked-by: Sergey Senozhat
Instead of defining the total/failed test counters manually,
test drivers that are clients of kselftest should use the
macro created for this purpose.
Signed-off-by: Timur Tabi
Reviewed-by: Petr Mladek
---
lib/test_bitmap.c | 3 +--
lib/test_printf.c | 4 ++--
2 files changed, 3 insertions
outright. This
is needed for the test_printf module which will now skip
%p hashing tests if hashing is disabled.
Patch #2 upgrades the printf library to check the command
line. It also updates test_printf().
Full series:
Acked-by: Marco Elver
Timur Tabi (3):
[v3] lib: use KSTM_MODULE_GLOBALS
Update the kselftest framework to allow client drivers to
specify that some tests were skipped.
Signed-off-by: Timur Tabi
---
tools/testing/selftests/kselftest_module.h | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests
On 2/10/21 5:11 AM, Marco Elver wrote:
I wanted to test this for deciding if we can show sensitive info in
KFENCE reports, which works just fine now that debug_never_hash_pointers
is non-static. FWIW,
Acked-by: Marco Elver
Thank you.
But unfortunately this series broke some other
On 2/10/21 7:41 AM, Petr Mladek wrote:
The option causes that vsprintf() will not hash pointers. Yes, it is
primary used by printk(). But it is used also in some other
interfaces, especially trace_printk(), seq_buf() API. The naked
pointers might appear more or less anywhere, including
On 2/10/21 10:46 AM, Steven Rostedt wrote:
Now the question is, why do you need the unhashed pointer?
Currently, the instruction pointer is what is fine right? You get the
a function and its offset. If there's something that is needed, perhaps we
should look at how to fix that, instead of
On 2/10/21 5:47 AM, Andy Shevchenko wrote:
It's a bit hard in some mailers (like Gmail) to see the different
versions of your patches.
Can you use in the future
- either `git format-patch -v ...`, where is a version
- or `git format-patch --subject-prefix="PATCH vX / RESEND / etc" ...`
?
On 2/9/21 11:18 PM, Timur Tabi wrote:
Instead of defining the total/failed test counters manually,
test_printf should use the kselftest macro created for this
purpose.
Signed-off-by: Timur Tabi
Ugh, I really need to stop sending patches late at night. This is again
the wrong email address
which can be a security risk.
Also update test_printf to skip the hashed pointer tests if the
command-line option is set.
Signed-off-by: Timur Tabi
Acked-by: Petr Mladek
Acked-by: Randy Dunlap
Acked-by: Sergey Senozhatsky
---
.../admin-guide/kernel-parameters.txt | 15 +++
Update the kselftest framework to all testing clients to
specify that some tests were skipped.
Signed-off-by: Timur Tabi
---
tools/testing/selftests/kselftest_module.h | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests
Instead of defining the total/failed test counters manually,
test_printf should use the kselftest macro created for this
purpose.
Signed-off-by: Timur Tabi
---
lib/test_printf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/test_printf.c b/lib/test_printf.c
index
the kselftest framework so that
it can report on tests that were skipped outright. This
is needed for the test_printf module which will now skip
%p hashing tests if hashing is disabled.
Patch #2 upgrades the printf library to check the command
line. It also updates test_printf().
Timur Tabi (3):
lib
From: Timur Tabi
If the make-printk-non-secret command line parameter is set, then
printk("%p") will print pointers as unhashed. This is useful for
debugging purposes.
A large warning message is displayed if this option is enabled.
Unhashed pointers, while useful for debugging, exp
Update the kselftest framework to all testing clients to
specify that some tests were skipped.
Signed-off-by: Timur Tabi
---
tools/testing/selftests/kselftest_module.h | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests
Instead of defining the total/failed test counters manually,
test_printf should use the kselftest macro created for this
purpose.
Signed-off-by: Timur Tabi
---
lib/test_printf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/test_printf.c b/lib/test_printf.c
index
outright. This
is needed for the test_printf module which will now skip
%p hashing tests if hashing is disabled.
Patch #2 upgrades the printf library to check the command
line. It also updates test_printf().
Timur Tabi (3):
lib/test_printf: use KSTM_MODULE_GLOBALS macro
kselftest: add support
On 2/9/21 3:59 PM, Marco Elver wrote:
Would it be reasonable to make this non-static? Or somehow make it
possible to get this flag from other subsystems?
There are other places in the kernel that dump sensitive data such as
registers. We'd like to be able to use 'debug_never_hash_pointers'
On 2/5/21 4:59 AM, Vlastimil Babka wrote:
Thanks a lot. Should this also affect %pK though? IIUC, there's currently no way
to achieve non-mangled %pK in all cases, even with the most permissive
kptr_restrict=1 setting:
- in IRQ, there's "pK-error" instead
- in a context of non-CAP_SYSLOG
On 2/4/21 4:17 PM, Kees Cook wrote:
It's just semantics. Printing addresses DOES weaken the security of a
system, especially when we know attackers have and do use stuff from dmesg
to tune their attacks. How about "reduces the security of your system"?
I think we're bikeshedding now, but I
On 2/4/21 3:49 PM, Pavel Machek wrote:
This machine is insecure. Yet I don't see ascii-art *** all around..
"Kernel memory addresses are exposed, which is bad for security."
I'll use whatever wording everyone can agree on, but I really don't see
much difference between "which may compromise
On 2/3/21 2:47 PM, Steven Rostedt wrote:
static void __init
plain(void)
{
int err;
+ if (debug_never_hash_pointers)
+ return;
So, I have a stupid question. What's the best way for test_printf.c to
read the command line parameter? Should I just do this in
On 2/3/21 7:31 AM, Petr Mladek wrote:
Also please make sure that lib/test_printf.c will work with
the new option.
As you suspected, it doesn't work:
[ 206.966478] test_printf: loaded.
[ 206.966528] test_printf: plain 'p' does not appear to be hashed
[ 206.966740] test_printf: failed 1 out
On 2/2/21 3:52 PM, Kees Cook wrote:
A large warning message is displayed if this option is enabled,
because unhashed addresses, while useful for debugging, exposes
kernel addresses which can be a security risk.
Linus has expressly said "no" to things like this in the past:
addresses which can be a security risk.
Signed-off-by: Timur Tabi
---
lib/vsprintf.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3b53c73580c5..b9f87084afb0 100644
--- a/lib/vsprintf.c
+++ b/lib/
addresses which can be a security risk.
Signed-off-by: Timur Tabi
---
lib/vsprintf.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3b53c73580c5..b9f87084afb0 100644
--- a/lib/vsprintf.c
+++ b/lib/
On 1/26/21 10:47 AM, Vlastimil Babka wrote:
Given Linus' current stance later in this thread, could we revive the idea of a
boot time option, or at least a CONFIG (I assume a runtime toggle would be too
much, even if limited to !kernel_lockdown:) , that would disable all hashing?
It would be
On 1/26/21 8:11 PM, Sergey Senozhatsky wrote:
+1 for boot param with a scary name and dmesg WARNING WARNING WARNING that
should look even scarier.
Timur, do you have time to take a look and submit a patch?
Yes, I'll submit a patch.
On 1/26/21 11:14 AM, Vlastimil Babka wrote:
If it was a boot option, I would personally be for leaving hashing enabled by
default, with opt-in boot option to disable it.
A boot option would solve all my problems. I wouldn't need to recompile
the kernel, and it would apply to all variations
On 1/19/21 3:15 PM, Steven Rostedt wrote:
When it's not related to any symbol, doesn't it still produce an offset
with something close by, that could still give you information that's
better than a hashed number.
No. I often need the actual unhashed address in the hex dump so that I
can see
On 1/19/21 2:10 PM, Steven Rostedt wrote:
I'm curious, what is the result if you replaced %p with %pS?
That way you get a kallsyms offset version of the output, which could still
be very useful depending on what you are dumping.
%pS versatile_init+0x0/0x110
The address is
On 1/19/21 1:45 PM, Kees Cook wrote:
How about this so the base address is hashed once, with the offset added
to it for each line instead of each line having a "new" hash that makes
no sense:
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 9301578f98e8..20264828752d 100644
--- a/lib/hexdump.c
On 1/18/21 6:53 PM, Sergey Senozhatsky wrote:
I like the idea of a more radical name, e.g. DUMP_PREFIX_RAW_POINTERS or
something similar.
Is "raw pointer" the common term for unhashed pointers?
On 1/18/21 12:26 PM, Matthew Wilcox wrote:
Don't make it easy. And don't make it look like they're doing
something innocent. DUMP_PREFIX_SECURITY_HOLE would be OK
by me. DUMP_PREFIX_LEAK_INFORMATION would work fine too.
DUMP_PREFIX_MAKE_ATTACKERS_LIFE_EASY might be a bit too far.
It's
On 1/18/21 11:14 AM, Andy Shevchenko wrote:
But isn't it good to expose those issues (and fix them)?
I suppose.
Perhaps even add _ADDRESS to DUMP_PREFIX_UNHASHED, but this maybe too
long.
I think DUMP_PREFIX_ADDRESS_UNHASHED is too long.
What about introducing new two like these:
On 1/18/21 4:03 AM, Andy Shevchenko wrote:
On Sun, Jan 17, 2021 at 12:12 AM Timur Tabi wrote:
(Hint: -v to the git format-patch will create a versioned subject
prefix for you automatically)
I like to keep the version in the git repo itself so that I don't need
to keep track
Hashed addresses are useless in hexdumps unless you're comparing
with other hashed addresses, which is unlikely. However, there's
no need to break existing code, so introduce a new prefix type
that prints unhashed addresses.
Signed-off-by: Timur Tabi
Reviewed-by: Petr Mladek
Cc: Roman Fietze
Now that print_hex_dump() is capable of printing unhashed addresses,
use that feature in the code that reports memory errors. Hashed
addresses don't tell you where the corrupted page actually is.
Signed-off-by: Timur Tabi
---
mm/page_poison.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
if the addresses are hashed. I expect most developers to
want to replace their usage of DUMP_PREFIX_ADDRESS with
DUMP_PREFIX_UNHASHED, now that they have the opportunity.
Timur Tabi (2):
[v2] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed
addresses
mm/page_poison: use unhashed address
On Fri, Jan 15, 2021 at 3:24 AM Petr Mladek wrote:
> By other words, every print_hex_dump() used need to be reviewed in
> which context might be called.
I did a rough analysis of all current usage of DUMP_PREFIX_ADDRESS in
the kernel, compared to the introduction of %px and hashed addresses,
On 1/11/21 7:30 PM, Andrew Morton wrote:
I doubt if Kees (or I or anyone else) can review this change because
there are no callers which actually use the new DUMP_PREFIX_UNHASHED.
Is it intended that some other places in the kernel be changed to use
this? If so, please describe where and why,
Hashed addresses are useless in hexdumps unless you're comparing
with other hashed addresses, which is unlikely. However, there's
no need to break existing code, so introduce a new prefix type
that prints unhashed addresses.
Signed-off-by: Timur Tabi
Cc: Roman Fietze
---
include/linux
On 9/18/20 9:21 AM, Viorel Suman (OSS) wrote:
+static const u32 fsl_xcvr_earc_channels[] = { 1, 2, 8, 16, 32, }; /*
+one bit 6, 12 ? */
What's the meaning of the comments?
Just a thought noted as comment. HDMI2.1 spec defines 6- and 12-channels layout
when
one bit audio stream is transmitted
On Wed, Jun 24, 2020 at 7:23 AM Roman Fietze wrote:
>
> This function is mainly used for debugging. But for that purpose the
> hashed memory address of the dumped data provides no useful
> information at all.
>
> Note: There are only very few locations in the kernel, where
> print_hex_dump is not
On 8/6/20 8:54 PM, wanghai (M) wrote:
Thanks for your suggestion. May I fix it like this?
Yes, this is what I had in mind. Thanks.
Acked-by: Timur Tabi
On 8/6/20 9:06 AM, Wang Hai wrote:
In emac_clks_phase1_init() of emac_probe(), there may be a situation
in which some clk_prepare_enable() succeed and others fail.
If emac_clks_phase1_init() fails, goto err_undo_clocks to clean up
the clk that was successfully clk_prepare_enable().
Good catch,
On 12/3/18 12:43 AM, Wen Yang wrote:
The null check on >cmap is redundant since cmap is a struct
inside fb_info and can never be null, so the check is always true.
we may remove it.
Signed-off-by: Wen Yang
Acked-by: Timur Tabi
On 12/3/18 12:43 AM, Wen Yang wrote:
The null check on >cmap is redundant since cmap is a struct
inside fb_info and can never be null, so the check is always true.
we may remove it.
Signed-off-by: Wen Yang
Acked-by: Timur Tabi
Is there a way to enable ftrace tracing only for one specific function
and all the functions it calls? Then when the function returns,
disable tracing until the next time?
When I pass the function name only to set_ftrace_filter, it literally
only traces that function, which doesn't help me. I
Is there a way to enable ftrace tracing only for one specific function
and all the functions it calls? Then when the function returns,
disable tracing until the next time?
When I pass the function name only to set_ftrace_filter, it literally
only traces that function, which doesn't help me. I
On 10/5/18 1:52 AM, Ricardo Ribalda Delgado wrote:
The current code produces XPU violation if get_direction is called just
after the initialization.
Signed-off-by: Ricardo Ribalda Delgado
I'm not the maintainer of pinctrl-msm, but this looks okay to me.
Acked-by: Timur Tabi
On 10/5/18 1:52 AM, Ricardo Ribalda Delgado wrote:
The current code produces XPU violation if get_direction is called just
after the initialization.
Signed-off-by: Ricardo Ribalda Delgado
I'm not the maintainer of pinctrl-msm, but this looks okay to me.
Acked-by: Timur Tabi
On Fri, Oct 5, 2018 at 11:54 AM Timur Tabi wrote:
> If you want, just put a printk(... offset) in msm_gpio_get() and read
> from a GPIO that you know you have access to, and make sure the
> 'offset' is correct.
>
> Then try reading from a GPIO that you don't have access to, and
On Fri, Oct 5, 2018 at 11:54 AM Timur Tabi wrote:
> If you want, just put a printk(... offset) in msm_gpio_get() and read
> from a GPIO that you know you have access to, and make sure the
> 'offset' is correct.
>
> Then try reading from a GPIO that you don't have access to, and
On 10/05/2018 11:17 AM, Jeffrey Hugo wrote:>
> Looks like the driver is initing just fine to me. Is setting up the
> jumpers and running gpio-test warranted?
Well, that test only makes sure that input/output is actually working
on the hardware level, but it also makes sure that the GPIOs are
On 10/05/2018 11:17 AM, Jeffrey Hugo wrote:>
> Looks like the driver is initing just fine to me. Is setting up the
> jumpers and running gpio-test warranted?
Well, that test only makes sure that input/output is actually working
on the hardware level, but it also makes sure that the GPIOs are
On 10/2/18 3:27 AM, Ricardo Ribalda Delgado wrote:
+ /* REVISIT: most hardware initializes GPIOs as inputs (often
+* with pullups enabled) so power usage is minimized. Linux
+* code should set the gpio direction first thing; but until
+
On 10/2/18 3:27 AM, Ricardo Ribalda Delgado wrote:
+ /* REVISIT: most hardware initializes GPIOs as inputs (often
+* with pullups enabled) so power usage is minimized. Linux
+* code should set the gpio direction first thing; but until
+
On 10/2/18 2:38 AM, Linus Walleij wrote:
But as today the only driver that seems to be using valid_mask is msm,
so perhaps a hack is something better and then when we have a second
driver that requires it we figure out the real requirements. But it is
definately your decision;)
Please note
On 10/2/18 2:38 AM, Linus Walleij wrote:
But as today the only driver that seems to be using valid_mask is msm,
so perhaps a hack is something better and then when we have a second
driver that requires it we figure out the real requirements. But it is
definately your decision;)
Please note
On 9/29/18 8:21 AM, Timur Tabi wrote:
Is it possible to access the hardware?
Linaro and some Linux OSVs should still have systems, but I usually just
ask Jeff to test code for me.
Alternatively, you can just add valid_mask support to your driver, and
add a check to your get_direction
On 9/29/18 8:21 AM, Timur Tabi wrote:
Is it possible to access the hardware?
Linaro and some Linux OSVs should still have systems, but I usually just
ask Jeff to test code for me.
Alternatively, you can just add valid_mask support to your driver, and
add a check to your get_direction
On 9/29/18 1:23 AM, Ricardo Ribalda Delgado wrote:
In fact gpiochip_init_valid_mask is called some lines after in the
same function. We could reorder the function. Would that work for you?
It might. It might break something else, though.
The driver breaking is upstream?
Yes.
Is it
On 9/29/18 1:23 AM, Ricardo Ribalda Delgado wrote:
In fact gpiochip_init_valid_mask is called some lines after in the
same function. We could reorder the function. Would that work for you?
It might. It might break something else, though.
The driver breaking is upstream?
Yes.
Is it
On Fri, Sep 28, 2018 at 2:14 PM Jeffrey Hugo wrote:
> Nack. Causes a XPU violation to the GPIO config registers.
That doesn't surprise me at all.
I believe that the problem is that gpiochip_line_is_valid() is being
called before gpiochip_irqchip_init_valid_mask() is called, which
means that
On Fri, Sep 28, 2018 at 2:14 PM Jeffrey Hugo wrote:
> Nack. Causes a XPU violation to the GPIO config registers.
That doesn't surprise me at all.
I believe that the problem is that gpiochip_line_is_valid() is being
called before gpiochip_irqchip_init_valid_mask() is called, which
means that
On 9/27/18 9:04 AM, Jeffrey Hugo wrote:
I guess its lucky I saw this then.
Did you not get this email:
https://lore.kernel.org/patchwork/patch/989545/#1173771
On 9/27/18 9:04 AM, Jeffrey Hugo wrote:
I guess its lucky I saw this then.
Did you not get this email:
https://lore.kernel.org/patchwork/patch/989545/#1173771
On 9/27/18 1:51 AM, Stephen Boyd wrote:
Looks OK to me visually. I haven't tested it because I don't have access
to the locked down hardware anymore.
Same here. Please wait for Jeff Hugo to test it before applying. Thanks.
On 9/27/18 1:51 AM, Stephen Boyd wrote:
Looks OK to me visually. I haven't tested it because I don't have access
to the locked down hardware anymore.
Same here. Please wait for Jeff Hugo to test it before applying. Thanks.
Jeff, can you test these two patches on Amberwing to make sure that they
don't cause an XPU violation on boot?
The call to gpiochip_line_is_valid() should return false on any GPIOs
that aren't listed in the ACPI table.
My concern is that this patch might be calling gpiochip_line_is_valid()
Jeff, can you test these two patches on Amberwing to make sure that they
don't cause an XPU violation on boot?
The call to gpiochip_line_is_valid() should return false on any GPIOs
that aren't listed in the ACPI table.
My concern is that this patch might be calling gpiochip_line_is_valid()
On 9/20/18 5:36 PM, Linus Walleij wrote:
What I mean is that $SUBJECT patch might not hurt Qualcomms
GPIOs (not crash the platform) if and only if it is augmented to not
try to get the initial direction from lines masked off in .valid_mask
if .need_valid_mask is true.
Whether it makes sense
On 9/20/18 5:36 PM, Linus Walleij wrote:
What I mean is that $SUBJECT patch might not hurt Qualcomms
GPIOs (not crash the platform) if and only if it is augmented to not
try to get the initial direction from lines masked off in .valid_mask
if .need_valid_mask is true.
Whether it makes sense
On 9/20/18 12:23 AM, Linus Walleij wrote:
I think most gpiochips easily survives calling the .get_direction()
early, Qualcomm's stand out here.
Now that we have .valid_mask in the gpiochip could we simply just
add this back, resepecting valid_mask and avoid checking the
direction of precisely
On 9/20/18 12:23 AM, Linus Walleij wrote:
I think most gpiochips easily survives calling the .get_direction()
early, Qualcomm's stand out here.
Now that we have .valid_mask in the gpiochip could we simply just
add this back, resepecting valid_mask and avoid checking the
direction of precisely
On 9/19/18 10:27 AM, Ricardo Ribalda Delgado wrote:
"The get_direction callback normally triggers
a read/write to hardware, but we shouldn't be touching the hardware
for an individual GPIO until after it's been properly claimed." is
an statement specific for your platform
That is
On 9/19/18 10:27 AM, Ricardo Ribalda Delgado wrote:
"The get_direction callback normally triggers
a read/write to hardware, but we shouldn't be touching the hardware
for an individual GPIO until after it's been properly claimed." is
an statement specific for your platform
That is
On 09/19/2018 10:27 AM, Ricardo Ribalda Delgado wrote:
Let me explain my current setup
I have a board with input and output gpios, the direction is defined
via pdata. When I run gpioinfo all the gpios are shown as input,
regardless if they are input or outputs: Eg:
root@qt5022:/tmp#
On 09/19/2018 10:27 AM, Ricardo Ribalda Delgado wrote:
Let me explain my current setup
I have a board with input and output gpios, the direction is defined
via pdata. When I run gpioinfo all the gpios are shown as input,
regardless if they are input or outputs: Eg:
root@qt5022:/tmp#
On 9/18/18 11:04 PM, Ricardo Ribalda Delgado wrote:
And should't that be tacked in qcom hardware with something like:
if (!priv->initialized)
return INPUT;
if you or Timur point me to the harware that was crashing I would not
mind looking into that, but the current situations seems to me
On 9/18/18 11:04 PM, Ricardo Ribalda Delgado wrote:
And should't that be tacked in qcom hardware with something like:
if (!priv->initialized)
return INPUT;
if you or Timur point me to the harware that was crashing I would not
mind looking into that, but the current situations seems to me
Timur Tabi no longer works for Qualcomm, and he now has a kernel.org
email address, so update MAINTAINERS accordingly.
Signed-off-by: Timur Tabi
---
MAINTAINERS | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e19ec6d90a44
Timur Tabi no longer works for Qualcomm, and he now has a kernel.org
email address, so update MAINTAINERS accordingly.
Signed-off-by: Timur Tabi
---
MAINTAINERS | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e19ec6d90a44
On 6/19/18 9:14 PM, Sinan Kaya wrote:
+ if (!(cap & PCI_EXP_DEVCAP2_E2ETLP))
+ return;
+
+ dev->eetlp_prefix = 1;
How about:
if (cap & PCI_EXP_DEVCAP2_E2ETLP)
dev->eetlp_prefix = 1;
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of
On 6/19/18 9:14 PM, Sinan Kaya wrote:
+ if (!(cap & PCI_EXP_DEVCAP2_E2ETLP))
+ return;
+
+ dev->eetlp_prefix = 1;
How about:
if (cap & PCI_EXP_DEVCAP2_E2ETLP)
dev->eetlp_prefix = 1;
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of
On 5/31/18 11:57 AM, Bjorn Andersson wrote:
(Although
that would probably break if Timur's customers move their user space to
the new platform as "the first instance" isn't deterministic).
Users of platforms that have multiple TLMMs should be required to use
gpiolib instead of sysfs. I've
On 5/31/18 11:57 AM, Bjorn Andersson wrote:
(Although
that would probably break if Timur's customers move their user space to
the new platform as "the first instance" isn't deterministic).
Users of platforms that have multiple TLMMs should be required to use
gpiolib instead of sysfs. I've
On 5/31/18 7:12 AM, Greg Kroah-Hartman wrote:
Why is it somehow ok for "future" kernels? You can't break the api in
the future for no reason.
So this needs to be the same everywhere. If it is broken in 4.17-rc, it
needs to be reverted.
This was discussed here:
1 - 100 of 1429 matches
Mail list logo
