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 wo
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
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
ed 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 Senozhatsky
shing 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 print
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 t
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 e
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 w
splayed 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
re 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().
Full series:
Acked-by: Marco Elver
Timur Tabi (3):
[v3] lib: use KSTM_MODU
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 procfs
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 jus
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" ...`
?
Y
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
pgrade 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
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
re 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/test_printf: use KSTM_MODULE_GLOBALS macro
kselftest: a
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' to
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 proce
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 c
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 s
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 vs
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 o
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:
https://lore.kernel.
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 rea
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 of
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 i
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 question
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 alread
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: Ro
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 del
be done
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 unha
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,
usi
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, so
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
---
inc
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 &info->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 tr
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
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
numb
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 that
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 possi
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 gpi
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.
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()
t
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 sema
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 th
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 definitely
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# ./gpioin
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 li
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 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 alr
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:
https://www.spinics.net/lists/
On 5/31/18 6:53 AM, Sebastian Gottschall wrote:
i checked initially 4.9 with latest patches and 4.14 and reverted this
line to get back to the old behaviour but a which view in the current
4.17 tree shows
that the same patch has been included in 4.17. it was introduced in the
kernel mainline
On 5/25/18 7:22 PM, Timur Tabi wrote:
-phy->open = emac_sgmii_open;
-phy->close = emac_sgmii_close;
-phy->link_up = emac_sgmii_link_up;
-phy->link_down = emac_sgmii_link_down;
I'll take it look at it next week when I'm back in the office.
I posted a
On 5/25/18 4:37 PM, Arnd Bergmann wrote:
+#ifdef CONFIG_ACPI
static int emac_sgmii_irq_clear(struct emac_adapter *adpt, u8 irq_bits)
{
struct emac_sgmii *phy = &adpt->phy;
@@ -288,6 +289,7 @@ static struct sgmii_ops qdf2400_ops = {
.link_change = emac_sgmii_common_link_change,
On 5/17/18 3:28 AM, Hemanth Puranik wrote:
Currently we use non-NUMA aware allocation for TPD and RRD buffers,
this patch modifies to use NUMA friendly allocation.
Signed-off-by: Hemanth Puranik
Acked-by: Timur Tabi
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
On 05/16/2018 01:23 PM, Sinan Kaya wrote:
+ win_start = window->res->start - window->offset;
Can you guarantee that window->res->start is always >= window->offset?
+ win_size = window->res->end - window->res->start + 1;
Use resource_size() instead.
--
Qualcomm D
On 5/15/18 8:10 PM, Hemanth Puranik wrote:
This patch introduces ops structure for sgmii, This by ensures that
we do not need dummy functions in case of emulation platforms.
Signed-off-by: Hemanth Puranik
Acked-by: Timur Tabi
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of
ctrl: qcom: Don't allow protected pins to be requested
ACPI parts:
Tested-by: Timur Tabi
I posted a pair of patches that should be applied on top of yours. The
first one fixed pinctrl-msm when there is more than one TLMM device.
The second adds support for my SOC.
--
Qualcomm Datacent
On 03/23/2018 11:21 AM, Stephen Boyd wrote:
I'll send the updated patches now.
Thanks.
BTW, I just discovered that the static globals in pinctrl-msm are
breaking the ability to support more than one TLMM:
static struct pinctrl_desc msm_pinctrl_desc = {
static struct irq_chip msm_gpio_irq_c
On 3/23/18 6:34 AM, Andy Shevchenko wrote:
No, it seems you missed %p vs. %px discussion.
The pointers printed by %p nowadays are hashed values, not the original
ones.
I totally forgot about that, thanks.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
On 03/22/2018 07:23 PM, Timur Tabi wrote:
Also, you don't allocate chip->valid_mask anywhere.
So I see now where it's allocated, but something is fishy. I have three
TLMMs on my chip:
[ 67.107018] gpiochip_init_valid_mask:351 gpiochip->need_valid_mask
On 03/22/2018 07:16 PM, Timur Tabi wrote:
This needs to be ret <= max_gpios, otherwise it will fail if every GPIO
is available.
And it should print an error message and return an error code if ret >
max_gpios.
Also, you don't allocate chip->valid_mask anywhere.
--
Qualc
On 03/21/2018 11:58 AM, Stephen Boyd wrote:
+static int msm_gpio_init_valid_mask(struct gpio_chip *chip,
+ struct msm_pinctrl *pctrl)
+{
+ int ret;
+ unsigned int len, i;
+ unsigned int max_gpios = pctrl->soc->ngpios;
+
+ /* The number of
On 3/19/18 10:36 PM, Linus Walleij wrote:
This looks fine except Andy's note to rename this ranges
to gpio-reserved-ranges for namespacing.
Are you reposting this series as v3 with this fixed or does someone
else need to pick it up?
I will pick this up if Stephen wants me to.
--
Qualcomm Data
On Fri, Mar 16, 2018 at 11:25 PM, Sinan Kaya wrote:
> @@ -477,15 +477,16 @@ static inline void t4_ring_sq_db(struct t4_wq *wq, u16
> inc, union t4_wr *wqe)
> (u64 *)wqe);
> } else {
> pr_debug("DB wq->sq.pidx = %d\n", wq->sq
On 3/16/18 6:04 PM, Steve Wise wrote:
Anybody understand why the PPC implementation of writeX_relaxed() isn't
relaxed?
You probably should ask that on the linuxppc-...@lists.ozlabs.org
mailing list.
I've always wondered why PowerPC has non-standard I/O accessors.
--
Qualcomm Datacenter Tech
On 3/13/18 10:20 PM, Sinan Kaya wrote:
+/* Assumes caller has executed a write barrier to order memory and device
+ * requests.
+ */
static inline void ixgbevf_write_tail(struct ixgbevf_ring *ring, u32 value)
{
- writel(value, ring->tail);
+ writel_relaxed(value, ring->tail);
}
ge in all the places and
dma_unmap_page while freeing the buffers.
Signed-off-by: Hemanth Puranik
Acked-by: Timur Tabi
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Found
On Fri, Mar 2, 2018 at 3:50 PM, Shanker Donthineni
wrote:
> diff --git a/arch/arm64/include/asm/cpucaps.h
> b/arch/arm64/include/asm/cpucaps.h
> index bb26382..6ecc249 100644
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@ -43,7 +43,7 @@
> #define ARM64_SVE
On 02/23/2018 10:54 AM, Bjorn Andersson wrote:
I haven't found the time to review the reuse of the irq valid mask or
the effort needed to replace this, other than that I think the series
looks good.
So is that an ACK?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Techno
On 01/25/2018 07:13 PM, Stephen Boyd wrote:
This patchset proposes a solution to describing the valid
pins for a pin controller in a semi-generic way so that qcom
platforms can expose the pins that are really available.
Typically, this has been done by having drivers and firmware
descriptions on
On 02/07/2018 07:52 AM, Linus Walleij wrote:
OK I put this in devel for v4.17, let's see if something explodes
in linux-next else we can go with this.
Otherwise we need something that conserves base 0 for singular
TLMM drivers and make it -1 for newer platforms with several
instances.
I don't
1 - 100 of 754 matches
Mail list logo
