ort for
> Exynos7885 SoC")
> Signed-off-by: David Virag
> ---
Reviewed-by: Sam Protsenko
> arch/arm64/boot/dts/exynos/exynos7885-jackpotlte.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7885-jackpotlte.dts
>
OF: graph: no port node found in /phy@1234abcd
Avoid printing that message by checking if the port node exists in PHY
node before calling of_graph_get_remote_node(). While at it, add the
comment from mentioned code block, explaining how checking the port
availability helps to avoid the misleading e
The previous change ("usb: dwc3: drd: Avoid error when extcon is
missing") changed the code flow in dwc3_get_extcon() function, leading
to unnecessary if-branch. This patch does housekeeping by reworking the
code for obtaining an extcon device from the "port" node.
Signed-o
But in offline discussion with
Andy Shevchenko it was decided it's better to split it into two patches
in order to provide the minimal change for further possible backporting,
and then do all style related changes on top of it in the second patch.
Sam Protsenko (2):
usb: dwc3: drd: Avoid erro
gle patch. But in offline
discussion with Andy Shevchenko it was decided it's better to split it
into two patches in order to provide the minimal change for further
possible backporting, and do all style related changes on top of it in
second patch.
Sam Protsenko (2):
usb: dwc3: drd: Avoid erro
graph: no port node found in /phy@1234abcd
Avoid printing that message by checking if port node exists in PHY node
before calling of_graph_get_remote_node().
Signed-off-by: Sam Protsenko
Cc: Andy Shevchenko
---
Changes in v3:
- Split patch into two patches: logic diff and style diff
d
dd
the comment from mentioned code block, explaining how checking the port
availability helps to avoid the misleading error.
Signed-off-by: Sam Protsenko
Cc: Andy Shevchenko
---
Changes in v3:
- Split patch into two patches: logic diff and style diff
drivers/usb/dwc3/drd.c | 28 +++
On Fri, 11 Dec 2020 at 16:48, Andy Shevchenko
wrote:
>
> On Fri, Dec 11, 2020 at 04:24:21PM +0200, Sam Protsenko wrote:
> > If "port" node is missing in PHY controller node, dwc3_get_extcon()
> > isn't able to find extcon device. This is perfectly fine in case whe
graph: no port node found in /phy@1234abcd
Avoid printing that message by checking if port node exists in PHY node
before calling of_graph_get_remote_node().
Signed-off-by: Sam Protsenko
---
drivers/usb/dwc3/drd.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
Hi Andy,
On Fri, 11 Dec 2020 at 16:15, Andy Shevchenko
wrote:
>
> On Thu, Dec 10, 2020 at 10:33:18PM +0200, Sam Protsenko wrote:
> > If "port" node is missing in PHY controller node, dwc3_get_extcon()
> > isn't able to find extcon device. This is perfectly fine
Hi,
On Thu, 10 Dec 2020 at 22:59, Dmitry Osipenko wrote:
>
> 10.12.2020 23:29, Sam Protsenko пишет:
> > Both of_graph_is_present() and of_graph_get_next_endpoint() functions
> > share common piece of code for obtaining the graph port. Extract it into
> > separate stati
graph: no port node found in /phy@1234abcd
Avoid printing that message by checking if port node exists in PHY node
before calling of_graph_get_remote_node().
Signed-off-by: Sam Protsenko
---
drivers/usb/dwc3/drd.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
: add of_graph_is_present()")
Signed-off-by: Sam Protsenko
---
drivers/of/property.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 408a7b5f06a9..da111fcf37ac 100644
--- a/drivers/of/property.c
+++ b/
wrote:
>
> That actually makes a lot of sense.
>
> Jan
>
> On November 21, 2018 2:39:03 PM EST, Sam Protsenko
> wrote:
> >+ Jan Harkes back to "To:" list, slipped away somehow...
> >
> >On Wed, Nov 21, 2018 at 9:36 PM Sam Protsenko
> > wrote:
&g
Hi Guillaume,
On Wed, Dec 19, 2018 at 4:38 PM Guillaume Nault wrote:
>
> On Wed, Dec 19, 2018 at 02:08:08AM +0200, Sam Protsenko wrote:
> > Extract "Protocol" field decompression code from transport protocols to
> > PPP generic layer, where it actually belongs. As a
omments instead.
Signed-off-by: Sam Protsenko
---
Changes in v2:
- Fix the order of checking skb data room and proto decompression
- Remove "inline" keyword from ppp_decompress_proto()
- Don't split line before function name
- Prefix ppp_decompress_proto() function with &qu
omments instead.
Signed-off-by: Sam Protsenko
---
drivers/net/ppp/ppp_async.c | 14 +++---
drivers/net/ppp/ppp_generic.c | 21 +++--
drivers/net/ppp/ppp_synctty.c | 9 -
drivers/net/ppp/pptp.c| 5 -
net/l2tp/l2tp_ppp.c | 4
5 fi
Hi Guillaume,
On Sun, Dec 16, 2018 at 6:30 PM Guillaume Nault wrote:
>
> On Fri, Dec 14, 2018 at 11:12:42PM +0200, Sam Protsenko wrote:
> > When Protocol Field Compression (PFC) is enabled, the "Protocol" field
> > in PPP packet should be transmitted without leading
Hi Guillaume,
On Sun, Dec 16, 2018 at 6:29 PM Guillaume Nault wrote:
>
> On Fri, Dec 14, 2018 at 07:59:21PM +0200, Sam Protsenko wrote:
> > When Protocol Field Compression (PFC) is enabled, the "Protocol" field
> > in PPP packet will be received without leading 0x00
Flags field will be used in further commits (e.g. for keeping
SC_COMP_PROT), so let's bring those back. This commit effectively
reverts commit 1998b5ed9c9b ("l2tp: drop ->flags from struct
pppol2tp_session"), with some cosmetic changes.
Signed-off-by: Sam Protsenko
---
net/l2
Of course, we don't compress Protocol field when sending LCP packets. As
stated in RFC 1661, section 6.5:
The Protocol field is never compressed when sending any LCP
packet. This rule guarantees unambiguous recognition of LCP
packets.
Signed-off-by: Sam Protsenko
---
net/l2tp/l2t
x0021 in PPP packet there will be
Protocol=0x21. This patch unwraps it back to 0x0021, which fixes the
issue.
Sending the compressed Protocol field will be implemented in subsequent
patch, this one is self-sufficient.
Signed-off-by: Sam Protsenko
---
net/l2tp/l2tp_ppp.c | 4
1 file changed,
commit 25528213fe9f ("tags: Fix
DEFINE_PER_CPU expansions"), but this one probably wasn't noticed.
Fixes: 9c80172b902d ("kernel/SRCU: provide a static initializer")
Cc: Andy Shevchenko
Signed-off-by: Sam Protsenko
---
include/linux/notifier.h | 3 +--
1 file changed,
On Mon, Oct 29, 2018 at 10:11 PM, Andy Shevchenko
wrote:
> On Mon, Oct 29, 2018 at 10:09 PM Sam Protsenko
> wrote:
>>
>> ctags indexing ("make tags" command) throws this warning:
>>
>> ctags: Warning: include/linux/notifier.h:125:
>> null ex
Hi Greg,
On Mon, Oct 29, 2018 at 10:09 PM, Sam Protsenko
wrote:
> ctags indexing ("make tags" command) throws this warning:
>
> ctags: Warning: include/linux/notifier.h:125:
> null expansion of name pattern "\1"
>
> This is the result of DEFINE_P
commit 25528213fe9f ("tags: Fix
DEFINE_PER_CPU expansions"), but this one probably wasn't noticed.
Signed-off-by: Sam Protsenko
---
include/linux/notifier.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier
Hi guys,
It's been a while since I sent this one. Can we please merge it if
there is no objections?
Thanks.
On Tue, Aug 28, 2018 at 6:44 PM, Sam Protsenko
wrote:
> ctags indexing ("make tags" command) throws this warning:
>
> ctags: Warning: include/linux/no
commit 25528213fe9f ("tags: Fix
DEFINE_PER_CPU expansions"), but this one probably wasn't noticed.
Signed-off-by: Sam Protsenko
---
include/linux/notifier.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier
On 20 March 2018 at 15:42, Greg Kroah-Hartman
wrote:
> On Tue, Mar 20, 2018 at 07:52:51AM +0800, Dan Rue wrote:
>> On Mon, Mar 19, 2018 at 07:05:21PM +0100, Greg Kroah-Hartman wrote:
>> > 4.4-stable review patch. If anyone has any objections, please let me know.
>> >
>> > --
>> >
On 19 October 2017 at 23:09, Ard Biesheuvel wrote:
> On 19 October 2017 at 20:40, Sam Protsenko wrote:
>> HugePages support is enabled on ARM64 and x86. On ARM32 we have support
>> for HugePages since kernel 3.11 [1]. Let's enable it on ARM32 too, as
>> it's needed
http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html
[3]
https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/mem/hugetlb
Signed-off-by: Sam Protsenko
---
arch/arm/configs/multi_v7_defconfig | 319 +++-
1 file changed, 132 insertions(+), 187 deleti
From: Sam Protsenko
When SUBARCH is "omap1" or "omap2", plat-omap/ directory must be
indexed. Handle this special case properly.
While at it, check if mach- directory exists at all.
Signed-off-by: Sam Protsenko
---
scripts/tags.sh | 19 +--
1 file changed,
+ Lokesh Vutla
+ linux-o...@vger.kernel.org
On Thu, Dec 10, 2015 at 6:06 PM, Semen Protsenko
wrote:
>
> From: Sam Protsenko
>
> When using DES module the next bug appears:
>
> BUG: scheduling while atomic: kworker/0:1/63/0x0102
>
> W
Thanks for your reply, Tom!
> How is the tunnel/session being created on the server side?
My server is xl2tpd. If I understand correctly, session and tunnel are
being created in start_pppd() function, see [1].
Judging from xl2tpd logs (see [2]), start_pppd() function is executed,
in turn, from co
Hi,
I'm having issues running user-space code, which uses net/l2tp/l2tp_ppp.c.
The code is supposed to be running in LAC mode (which is I believe is default).
My server configuration described here: https://wiki.linaro.org/LMG/Kernel/PPP
I was trying to use next code snippets as user-space part:
On Tue, May 12, 2015 at 10:34 AM, Linus Walleij
wrote:
> OK yeah, maybe we could provide a list of "usual suspects", what do you
> say about "my" expanders:
>
> drivers/gpio/gpio-stmpe.c
> drivers/gpio/gpio-tc3589x.c
>
> I can surely patch and test these.
This issue seems to be pretty common for
On Wed, May 6, 2015 at 4:07 PM, Linus Walleij wrote:
> Since you're doing these patches I assume my conversion to
> GPIOLIB_IRQCHIP in the last merge window just worked.
Actually I've only verified those patches on k3.14, and tested that mainline
kernel builds successfully (with patches applied)
On Mon, May 4, 2015 at 4:32 PM, Linus Walleij wrote:
> Are these real, observed issues?
The issue was observed for PCF857x expander (not by me), and it's described in
this commit: b80eef95beb04760629822fa130aeed54cdfafca .
It seems to me that the issue is real. But we need some really particula
v2 of this patch was sent (rebased on top of recent sources).
On Thu, Apr 30, 2015 at 6:28 PM, Semen Protsenko
wrote:
> There is pm_qos_add_request() being executed on serial_omap_probe(),
> which stores "&up->pm_qos_request" from omap-serial driver to
> "pm_qos_array[PM_QOS_CPU_DMA_LATENCY]->con
ice can release interrupt line. In my case
acknowledge is happening automatically on I2C read operation. Also it's
important to provide IRQF_ONESHOT flag when requesting threaded irq:
this way irq line will be disabled before running threaded handler.
Hope it answers your question.
Best regar
On Wed, Apr 22, 2015 at 10:42 AM, grygorii.stras...@linaro.org
wrote:
> Wouldn't handle_simple_irq() be a better choice here?
You are right, thanks! I sent the new version of patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
On Tue, Apr 21, 2015 at 5:40 PM, Thomas Gleixner wrote:
> No, it's not missing by chance. It's missing on purpose. The edge
> handler is designed to deal with edge type interrupt chips and those
> have an ACK by definition.
>
> You are fixing the wrong place. That GPIO expander is using the wrong
On Mon, Jan 26, 2015 at 11:50 AM, Roger Quadros wrote:
> Hi,
>
> On 24/01/15 22:28, Semen Protsenko wrote:
>> New OMAP-based architectures (like OMAP5, DRA7XX, AM572X) don't have
>> LIMITEDADDRESS bit in GPMC_CONFIG register (this bit marked as
>> RESERVED). Seems like these SoCs have new revision
> That's news for me. I thought they are silently ignored. Do you have an
> example of such a warning?
Not really. It was just assumption. It seems you are right, they are just
ignored silently. But item 2 is still relevant and it was actually confused
me when I tried to figure out MTD configurati
<<<<<<<<<<<<<<<<<<<<<<< cut here >>>>>>>>>>>>>>>>>>>>>
I'm planning to use your API for our UpdateCapsule test module so
it would be really helpful if you can include
ld you please quote the part of the patch you're
>> commenting on inline? That would have saved me searching through the
>> original email.
>
> Sure, my bad. I know it's general approach in mailing lists to review
> patch, just forgot it.
>
>
> On 13 October 2014
the
> original email.
Sure, my bad. I know it's general approach in mailing lists to review
patch, just forgot it.
On 13 October 2014 12:53, Matt Fleming wrote:
> On Fri, 10 Oct, at 06:55:49PM, Sam Protsenko wrote:
>> Hi Matt,
>>
>> 1. Why x86 code isn't se
Hi Matt,
1. Why x86 code isn't separated to another patch?
2. drivers/firmware/efi/reboot.c: efi_reboot():
One shouldn't use "printk()" with no KERN_* stuff passed into it.
I'd recommend to use "pr_info()" macro or something like that.
--
To unsubscribe from this list: send the line "unsubscri
> This is not a mainline kernel problem, surely?
Correct, this warning is just example of possible issue that can be
occurred because of missing "const" qualifier. Actually I saw this
warning in Linaro ACPI kernel (intended for ARMv8 AArch64
architecture).
But I believe that this issue should be
49 matches
Mail list logo
