Please reply to me

[vanevans001]

How are you? I'm Vanina C. I picked interest in you and I would like to know 
more about you and establish relationship with you. i will wait for your 
response. thank you.

[PATCH 5.11 171/210] openvswitch: fix send of uninitialized stack memory in ct limit reply

[Greg Kroah-Hartman]

From: Ilya Maximets 

[ Upstream commit 4d51419d49930be2701c2633ae271b350397c3ca ]

'struct ovs_zone_limit' has more members than initialized in
ovs_ct_limit_get_default_limit().  The rest of the memory is a random
kernel stack content that ends up being sent to userspace.

Fix that by using designated initializer that will clear all
non-specified fields.

Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
Signed-off-by: Ilya Maximets 
Acked-by: Tonghao Zhang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/openvswitch/conntrack.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 5eddfe7bd391..2316efd6ace8 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -2032,10 +2032,10 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr 
*nla_zone_limit,
 static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
  struct sk_buff *reply)
 {
-   struct ovs_zone_limit zone_limit;
-
-   zone_limit.zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE;
-   zone_limit.limit = info->default_limit;
+   struct ovs_zone_limit zone_limit = {
+   .zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE,
+   .limit   = info->default_limit,
+   };
 
return nla_put_nohdr(reply, sizeof(zone_limit), _limit);
 }
-- 
2.30.2

[PATCH 5.11 121/210] geneve: do not modify the shared tunnel info when PMTU triggers an ICMP reply

[Greg Kroah-Hartman]

From: Antoine Tenart 

[ Upstream commit 68c1a943ef37bafde5ea2383e8ca224c7169ee31 ]

When the interface is part of a bridge or an Open vSwitch port and a
packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When
using the external mode (collect metadata) the source and destination
addresses are reversed, so that Open vSwitch can match the packet
against an existing (reverse) flow.

But inverting the source and destination addresses in the shared
ip_tunnel_info will make following packets of the flow to use a wrong
destination address (packets will be tunnelled to itself), if the flow
isn't updated. Which happens with Open vSwitch, until the flow times
out.

Fixes this by uncloning the skb's ip_tunnel_info before inverting its
source and destination addresses, so that the modification will only be
made for the PTMU packet, not the following ones.

Fixes: c1a800e88dbf ("geneve: Support for PMTU discovery on directly bridged 
links")
Tested-by: Eelco Chaudron 
Reviewed-by: Eelco Chaudron 
Signed-off-by: Antoine Tenart 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/geneve.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 5523f069b9a5..f35b0b83fe85 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -908,8 +908,16 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct 
net_device *dev,
 
info = skb_tunnel_info(skb);
if (info) {
-   info->key.u.ipv4.dst = fl4.saddr;
-   info->key.u.ipv4.src = fl4.daddr;
+   struct ip_tunnel_info *unclone;
+
+   unclone = skb_tunnel_info_unclone(skb);
+   if (unlikely(!unclone)) {
+   dst_release(>dst);
+   return -ENOMEM;
+   }
+
+   unclone->key.u.ipv4.dst = fl4.saddr;
+   unclone->key.u.ipv4.src = fl4.daddr;
}
 
if (!pskb_may_pull(skb, ETH_HLEN)) {
@@ -993,8 +1001,16 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct 
net_device *dev,
struct ip_tunnel_info *info = skb_tunnel_info(skb);
 
if (info) {
-   info->key.u.ipv6.dst = fl6.saddr;
-   info->key.u.ipv6.src = fl6.daddr;
+   struct ip_tunnel_info *unclone;
+
+   unclone = skb_tunnel_info_unclone(skb);
+   if (unlikely(!unclone)) {
+   dst_release(dst);
+   return -ENOMEM;
+   }
+
+   unclone->key.u.ipv6.dst = fl6.saddr;
+   unclone->key.u.ipv6.src = fl6.daddr;
}
 
if (!pskb_may_pull(skb, ETH_HLEN)) {
-- 
2.30.2

[PATCH 5.11 120/210] vxlan: do not modify the shared tunnel info when PMTU triggers an ICMP reply

[Greg Kroah-Hartman]

From: Antoine Tenart 

[ Upstream commit 30a93d2b7d5a7cbb53ac19c9364a256d1aa6c08a ]

When the interface is part of a bridge or an Open vSwitch port and a
packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When
using the external mode (collect metadata) the source and destination
addresses are reversed, so that Open vSwitch can match the packet
against an existing (reverse) flow.

But inverting the source and destination addresses in the shared
ip_tunnel_info will make following packets of the flow to use a wrong
destination address (packets will be tunnelled to itself), if the flow
isn't updated. Which happens with Open vSwitch, until the flow times
out.

Fixes this by uncloning the skb's ip_tunnel_info before inverting its
source and destination addresses, so that the modification will only be
made for the PTMU packet, not the following ones.

Fixes: fc68c99577cc ("vxlan: Support for PMTU discovery on directly bridged 
links")
Tested-by: Eelco Chaudron 
Reviewed-by: Eelco Chaudron 
Signed-off-by: Antoine Tenart 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/vxlan.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 0842371eca3d..4adfa6a01198 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2725,12 +2725,17 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct 
net_device *dev,
goto tx_error;
} else if (err) {
if (info) {
+   struct ip_tunnel_info *unclone;
struct in_addr src, dst;
 
+   unclone = skb_tunnel_info_unclone(skb);
+   if (unlikely(!unclone))
+   goto tx_error;
+
src = remote_ip.sin.sin_addr;
dst = local_ip.sin.sin_addr;
-   info->key.u.ipv4.src = src.s_addr;
-   info->key.u.ipv4.dst = dst.s_addr;
+   unclone->key.u.ipv4.src = src.s_addr;
+   unclone->key.u.ipv4.dst = dst.s_addr;
}
vxlan_encap_bypass(skb, vxlan, vxlan, vni, false);
dst_release(ndst);
@@ -2781,12 +2786,17 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct 
net_device *dev,
goto tx_error;
} else if (err) {
if (info) {
+   struct ip_tunnel_info *unclone;
struct in6_addr src, dst;
 
+   unclone = skb_tunnel_info_unclone(skb);
+   if (unlikely(!unclone))
+   goto tx_error;
+
src = remote_ip.sin6.sin6_addr;
dst = local_ip.sin6.sin6_addr;
-   info->key.u.ipv6.src = src;
-   info->key.u.ipv6.dst = dst;
+   unclone->key.u.ipv6.src = src;
+   unclone->key.u.ipv6.dst = dst;
}
 
vxlan_encap_bypass(skb, vxlan, vxlan, vni, false);
-- 
2.30.2

[PATCH 5.10 152/188] openvswitch: fix send of uninitialized stack memory in ct limit reply

[Greg Kroah-Hartman]

From: Ilya Maximets 

[ Upstream commit 4d51419d49930be2701c2633ae271b350397c3ca ]

'struct ovs_zone_limit' has more members than initialized in
ovs_ct_limit_get_default_limit().  The rest of the memory is a random
kernel stack content that ends up being sent to userspace.

Fix that by using designated initializer that will clear all
non-specified fields.

Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
Signed-off-by: Ilya Maximets 
Acked-by: Tonghao Zhang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/openvswitch/conntrack.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 96a49aa3a128..a11b558813c1 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -2024,10 +2024,10 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr 
*nla_zone_limit,
 static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
  struct sk_buff *reply)
 {
-   struct ovs_zone_limit zone_limit;
-
-   zone_limit.zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE;
-   zone_limit.limit = info->default_limit;
+   struct ovs_zone_limit zone_limit = {
+   .zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE,
+   .limit   = info->default_limit,
+   };
 
return nla_put_nohdr(reply, sizeof(zone_limit), _limit);
 }
-- 
2.30.2

[PATCH 5.10 111/188] geneve: do not modify the shared tunnel info when PMTU triggers an ICMP reply

[Greg Kroah-Hartman]

From: Antoine Tenart 

[ Upstream commit 68c1a943ef37bafde5ea2383e8ca224c7169ee31 ]

When the interface is part of a bridge or an Open vSwitch port and a
packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When
using the external mode (collect metadata) the source and destination
addresses are reversed, so that Open vSwitch can match the packet
against an existing (reverse) flow.

But inverting the source and destination addresses in the shared
ip_tunnel_info will make following packets of the flow to use a wrong
destination address (packets will be tunnelled to itself), if the flow
isn't updated. Which happens with Open vSwitch, until the flow times
out.

Fixes this by uncloning the skb's ip_tunnel_info before inverting its
source and destination addresses, so that the modification will only be
made for the PTMU packet, not the following ones.

Fixes: c1a800e88dbf ("geneve: Support for PMTU discovery on directly bridged 
links")
Tested-by: Eelco Chaudron 
Reviewed-by: Eelco Chaudron 
Signed-off-by: Antoine Tenart 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/geneve.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 1426bfc009bc..abd37f26af68 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -907,8 +907,16 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct 
net_device *dev,
 
info = skb_tunnel_info(skb);
if (info) {
-   info->key.u.ipv4.dst = fl4.saddr;
-   info->key.u.ipv4.src = fl4.daddr;
+   struct ip_tunnel_info *unclone;
+
+   unclone = skb_tunnel_info_unclone(skb);
+   if (unlikely(!unclone)) {
+   dst_release(>dst);
+   return -ENOMEM;
+   }
+
+   unclone->key.u.ipv4.dst = fl4.saddr;
+   unclone->key.u.ipv4.src = fl4.daddr;
}
 
if (!pskb_may_pull(skb, ETH_HLEN)) {
@@ -992,8 +1000,16 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct 
net_device *dev,
struct ip_tunnel_info *info = skb_tunnel_info(skb);
 
if (info) {
-   info->key.u.ipv6.dst = fl6.saddr;
-   info->key.u.ipv6.src = fl6.daddr;
+   struct ip_tunnel_info *unclone;
+
+   unclone = skb_tunnel_info_unclone(skb);
+   if (unlikely(!unclone)) {
+   dst_release(dst);
+   return -ENOMEM;
+   }
+
+   unclone->key.u.ipv6.dst = fl6.saddr;
+   unclone->key.u.ipv6.src = fl6.daddr;
}
 
if (!pskb_may_pull(skb, ETH_HLEN)) {
-- 
2.30.2

[PATCH 5.10 110/188] vxlan: do not modify the shared tunnel info when PMTU triggers an ICMP reply

[Greg Kroah-Hartman]

From: Antoine Tenart 

[ Upstream commit 30a93d2b7d5a7cbb53ac19c9364a256d1aa6c08a ]

When the interface is part of a bridge or an Open vSwitch port and a
packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When
using the external mode (collect metadata) the source and destination
addresses are reversed, so that Open vSwitch can match the packet
against an existing (reverse) flow.

But inverting the source and destination addresses in the shared
ip_tunnel_info will make following packets of the flow to use a wrong
destination address (packets will be tunnelled to itself), if the flow
isn't updated. Which happens with Open vSwitch, until the flow times
out.

Fixes this by uncloning the skb's ip_tunnel_info before inverting its
source and destination addresses, so that the modification will only be
made for the PTMU packet, not the following ones.

Fixes: fc68c99577cc ("vxlan: Support for PMTU discovery on directly bridged 
links")
Tested-by: Eelco Chaudron 
Reviewed-by: Eelco Chaudron 
Signed-off-by: Antoine Tenart 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/vxlan.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 50cb8f045a1e..d3b698d9e2e6 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2724,12 +2724,17 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct 
net_device *dev,
goto tx_error;
} else if (err) {
if (info) {
+   struct ip_tunnel_info *unclone;
struct in_addr src, dst;
 
+   unclone = skb_tunnel_info_unclone(skb);
+   if (unlikely(!unclone))
+   goto tx_error;
+
src = remote_ip.sin.sin_addr;
dst = local_ip.sin.sin_addr;
-   info->key.u.ipv4.src = src.s_addr;
-   info->key.u.ipv4.dst = dst.s_addr;
+   unclone->key.u.ipv4.src = src.s_addr;
+   unclone->key.u.ipv4.dst = dst.s_addr;
}
vxlan_encap_bypass(skb, vxlan, vxlan, vni, false);
dst_release(ndst);
@@ -2780,12 +2785,17 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct 
net_device *dev,
goto tx_error;
} else if (err) {
if (info) {
+   struct ip_tunnel_info *unclone;
struct in6_addr src, dst;
 
+   unclone = skb_tunnel_info_unclone(skb);
+   if (unlikely(!unclone))
+   goto tx_error;
+
src = remote_ip.sin6.sin6_addr;
dst = local_ip.sin6.sin6_addr;
-   info->key.u.ipv6.src = src;
-   info->key.u.ipv6.dst = dst;
+   unclone->key.u.ipv6.src = src;
+   unclone->key.u.ipv6.dst = dst;
}
 
vxlan_encap_bypass(skb, vxlan, vxlan, vni, false);
-- 
2.30.2

[PATCH 5.4 088/111] openvswitch: fix send of uninitialized stack memory in ct limit reply

[Greg Kroah-Hartman]

From: Ilya Maximets 

[ Upstream commit 4d51419d49930be2701c2633ae271b350397c3ca ]

'struct ovs_zone_limit' has more members than initialized in
ovs_ct_limit_get_default_limit().  The rest of the memory is a random
kernel stack content that ends up being sent to userspace.

Fix that by using designated initializer that will clear all
non-specified fields.

Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
Signed-off-by: Ilya Maximets 
Acked-by: Tonghao Zhang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/openvswitch/conntrack.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index e905248b11c2..b6f98eba71f1 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -2019,10 +2019,10 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr 
*nla_zone_limit,
 static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
  struct sk_buff *reply)
 {
-   struct ovs_zone_limit zone_limit;
-
-   zone_limit.zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE;
-   zone_limit.limit = info->default_limit;
+   struct ovs_zone_limit zone_limit = {
+   .zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE,
+   .limit   = info->default_limit,
+   };
 
return nla_put_nohdr(reply, sizeof(zone_limit), _limit);
 }
-- 
2.30.2

Re: [PATCH] kernel/time: Feedback reply for hr_sleep syscall, a fine-grained sleep service

[Thomas Gleixner]

Marco!

On Wed, Apr 07 2021 at 11:32, Marco Faltelli wrote:

> Current sleep services (nanosleep) provide sleep periods very far from
> the expectations when scheuling microsecond-scale timers. On our
> testbed, using rdtscp() before and after a nanosleep() syscall to
> measure the effective elapsed time with a 1us timer, we got ~59us.
> Even with larger timeout periods, the difference is still evident
> (e.g., with a 100us timer, we measured ~158us of elapsed time).

So the delta is a constant of ~50us, right?

> We believe that one of the reasons is the use of the timespec
> structure, that needs to be copied for user to kernel and then
> converted into a single-value representation.

Interesting.

> In our work Metronome
> (https://dl.acm.org/doi/pdf/10.1145/3386367.3432730) we had the need
> for a precise microsecond-granularity sleep service, as nanosleep()
> was far from our needs, so we developed hr_sleep(), a new sleep
> service.

The above 'interesting' assumption made me curious about the deeper
insight, so I went to read. Let me give you a few comments on that
paper.

> In current conventional implementations of the Linux kernel, the support
> for (fine-grain) sleep periods of threads is based on the nanosleep()
> system call, which has index 35 in the current specification of the
> x86-64/Linux system call table.

There is also clock_nanosleep(2) for completness sake...

> The actual execution path of this system call, particularly at kernel
> side, is shown in Figure 1a. When entering kernel mode the thread exploits 
> two main kernel
> level subsystems. One is the scheduling subsystem, which allows managing
> the run-queue of threads that can be rescheduled in CPU. The other one
> is the high-resolution timers subsystem, which allows posting
> timer-expiration requests to the Linux kernel timer wheel.

The timer wheel is not involved in this at all. If your timer would end
up on the timer wheel your observed latencies would be in the
milliseconds range not in the 50usec range.

> The latter is a data structure that keeps the ordered set of timer
> expiration requests, so that each time one of these timers expires the
> subsequent timer expiration request is activated.

Not exactly how the timer wheel in the kernel works, but that's
irrelevant because it is not involved in this.

> The expiration of a timer is associated with the interrupt coming from
> the High Precision Event Timer (HPET) on board of x86 processors.

You must have a really old and crappy machine to test on. HPET is
avoided on any CPU less than 10 years old and pretty much irrelevant or
a performace horror on any machine which has more than 4 cores.

> In any case, independently of whether preemption will occur, the CPU
> cycles spent for that preamble lead to a delay for the post of the
> timer- expiration request to the timer wheel, leading the thread to
> actually start its timed-sleep phase with a delay.

I would have expected a proper measurement of the delay which is caused
by that processing in the paper, but in absence of that I instrumented
it for you:

First of all I implemented the thing myself, because the crud you posted
fails to compile (see below) and for other reasons which I spare myself
to explain because of that.

The regular clock_nanosleep() over the hacked up nanosleep_u64(), which
just takes a u64 nanosecond value as argument instead of the timespec
pointer has an overhead of ~64 CPU clock cycles on average according to
'perf stat' which amounts to a whopping 32 nanoseconds per syscall on my
test machine running at 2 GHz.

That's _three_ orders of magnitude off from 50us. There goes the theory.

So now where are these 50 microseconds coming from?

There is no massive software/hardware induced overhead caused by the
timespec pointer handling at all, the 50 microseconds are simply the
default timer slack value which is added to the expiry value to allow
better batching of timer expiries. 

That slack is automatically zero for tasks in real time scheduling
classes and can also be modified by a system wide setting and per
process via prctl(PR_SET_TIMERSLACK, .) except a system policy
prevents that.

That prtcl has unfortunately a severe limitation: it does not allow to
set the slack value to 0, the mininum values is 1 nanosecond, and I'm
happy to discuss that when you come up with a proper scientific proof
that that _one_ nanosecond matters.

As a limited excuse I concede, that the timer slack is barely
documented, but i'm thorougly surprised that this has not been figured
out and instead of that weird theories about the syscall entry code
implications make up several pages of handwaving content of a published
and 'reviewed' academic paper.

So here is the comparison between the regular clock_nanosleep() with the
prctl() used and the u64 based variant which sets the slack to 0 with
1e6 samples each for a delay of 50us.

sys_clock_nanosleep(CLOCK_MONOTONIC, 0, , NULL)
 |
 |

[PATCH] kernel/time: Feedback reply for hr_sleep syscall, a fine-grained sleep service

[Marco Faltelli]

Current sleep services (nanosleep) provide sleep periods very far from the 
expectations when scheuling microsecond-scale timers. On our testbed, using 
rdtscp() before and after a nanosleep() syscall to measure the effective 
elapsed time with a 1us timer, we got ~59us.
Even with larger timeout periods, the difference is still evident (e.g., with a 
100us timer, we measured ~158us of elapsed time).
We believe that one of the reasons is the use of the timespec structure, that 
needs to be copied for user to kernel and then converted into a single-value 
representation.
In our work Metronome (https://dl.acm.org/doi/pdf/10.1145/3386367.3432730) we 
had the need for a precise microsecond-granularity sleep service, as 
nanosleep() was far from our needs, so we developed hr_sleep(), a new sleep 
service. Since the sleep periods needed in our case are small, we don't want 
our sleep service to re-schedule a timer in case of a signal interruption, so 
it just returns -EINTR to the user. The user must be aware that this is a 
best-effort sleep service, so the sleep period specified is an upper-bound of 
the effective elapsed time.
We believe this patch can be useful in applications where fine-grained 
granularity is requested for small sleep periods, and re-scheduling the timer 
in case of a signal is not mandatory.
In the paper previously linked, Section 3.1 provides more details about 
hr_sleep and Section 3.3 extensively evaluates hr_sleep() and compares it to 
nanosleep(). For a 1us timeout, hr_sleep() elapses ~3.8us in mean vs. the ~59us 
of nanosleep().
hr_sleep has been previously submitted at 
https://lore.kernel.org/lkml/20210115180733.5663-1-marco.falte...@uniroma2.it/.
This commit answers to the previous feedback in 
https://lore.kernel.org/lkml/CALCETrWfnL=3m3nmmhs-a3si5jptsctf6cethvtsdnwa5mh...@mail.gmail.com/
 and applies the requested changes.

Signed-off-by: Marco Faltelli 
---
 arch/x86/entry/syscalls/syscall_64.tbl |  1 +
 kernel/time/hrtimer.c  | 67 ++
 2 files changed, 68 insertions(+)

diff --git a/arch/x86/entry/syscalls/syscall_64.tbl 
b/arch/x86/entry/syscalls/syscall_64.tbl
index 7bf01cbe582f..85b14dfa40fb 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -364,6 +364,7 @@
 440common  process_madvise sys_process_madvise
 441common  epoll_pwait2sys_epoll_pwait2
 442common  mount_setattr   sys_mount_setattr
+443common  hr_sleepsys_hr_sleep
 
 #
 # Due to a historical design error, certain syscalls are numbered differently
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 4a66725b1d4a..887c01392e08 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -2006,6 +2006,73 @@ SYSCALL_DEFINE2(nanosleep_time32, struct old_timespec32 
__user *, rqtp,
 }
 #endif
 
+
+
+#ifdef CONFIG_64BIT
+
+
+struct control_record {
+   struct task_struct *task;
+   int awake;
+   struct hrtimer hr_timer;
+};
+
+
+static enum hrtimer_restart hr_sleep_callback(struct hrtimer *timer)
+{
+   struct control_record *control;
+   struct task_struct *the_task;
+
+   control = (control_record *)container_of(timer, control_record, 
hr_timer);
+   control->awake = 1;
+   the_task = control->task;
+   wake_up_process(the_task);
+
+   return HRTIMER_NORESTART;
+}
+
+
+
+/**
+ * hr_sleep - a high-resolution sleep service for fine-grained timeouts
+ * @nanoseconds:   the requested sleep period in nanoseconds
+ *
+ * Returns:
+ * 0 when the sleep request successfully terminated
+ * -EINVAL if a sleep period < 0 is requested
+ * -EINTR if a signal interrupted the calling thread
+ */
+SYSCALL_DEFINE1(hr_sleep, long, nanoseconds)
+{
+   DECLARE_WAIT_QUEUE_HEAD(the_queue);
+   struct control_record control;
+   ktime_t ktime_interval;
+   struct restart_block *restart;
+
+   if (nanoseconds < 0)
+   return -EINVAL;
+
+   if (nanoseconds == 0)
+   return 0;
+
+   ktime_interval = ktime_set(0, nanoseconds);
+   hrtimer_init(&(control.hr_timer), CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+   control.hr_timer.function = _sleep_callback;
+   control.task = current;
+   control.awake = 0;
+   hrtimer_start(&(control.hr_timer), ktime_interval, HRTIMER_MODE_REL);
+   wait_event_interruptible(the_queue, control.awake == 1);
+   hrtimer_cancel(&(control.hr_timer));
+   if (control.awake == 0)
+   //We have been interrupted by a signal
+   return -EINTR;
+   return 0;
+
+}
+
+#endif
+
+
 /*
  * Functions related to boot-time initialization:
  */
-- 
2.25.1

Re: [PATCH net] openvswitch: fix send of uninitialized stack memory in ct limit reply

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (refs/heads/master):

On Sun,  4 Apr 2021 19:50:31 +0200 you wrote:
> 'struct ovs_zone_limit' has more members than initialized in
> ovs_ct_limit_get_default_limit().  The rest of the memory is a random
> kernel stack content that ends up being sent to userspace.
> 
> Fix that by using designated initializer that will clear all
> non-specified fields.
> 
> [...]

Here is the summary with links:
  - [net] openvswitch: fix send of uninitialized stack memory in ct limit reply
https://git.kernel.org/netdev/net/c/4d51419d4993

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [ovs-dev] [PATCH net] openvswitch: fix send of uninitialized stack memory in ct limit reply

[Tonghao Zhang]

On Mon, Apr 5, 2021 at 2:01 AM Ilya Maximets  wrote:
>
> CC: ovs-dev
>
> On 4/4/21 7:50 PM, Ilya Maximets wrote:
> > 'struct ovs_zone_limit' has more members than initialized in
> > ovs_ct_limit_get_default_limit().  The rest of the memory is a random
> > kernel stack content that ends up being sent to userspace.
> >
> > Fix that by using designated initializer that will clear all
> > non-specified fields.
> >
> > Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
> > Signed-off-by: Ilya Maximets 
> > ---
> >  net/openvswitch/conntrack.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
> > index c29b0ef1fc27..cadb6a29b285 100644
> > --- a/net/openvswitch/conntrack.c
> > +++ b/net/openvswitch/conntrack.c
> > @@ -2032,10 +2032,10 @@ static int ovs_ct_limit_del_zone_limit(struct 
> > nlattr *nla_zone_limit,
> >  static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
> > struct sk_buff *reply)
> >  {
> > - struct ovs_zone_limit zone_limit;
> > -
> > - zone_limit.zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE;
> > - zone_limit.limit = info->default_limit;
> > + struct ovs_zone_limit zone_limit = {
> > + .zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE,
> > + .limit   = info->default_limit,
> > + };
I review the code, userspace don't use the count of ovs_zone_lime
struct, but this patch looks to to me.
Thanks Ilya.
Acked-by: Tonghao Zhang 
> >   return nla_put_nohdr(reply, sizeof(zone_limit), _limit);
> >  }
> >
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev



-- 
Best regards, Tonghao

Re: [PATCH net] openvswitch: fix send of uninitialized stack memory in ct limit reply

[Ilya Maximets]

CC: ovs-dev

On 4/4/21 7:50 PM, Ilya Maximets wrote:
> 'struct ovs_zone_limit' has more members than initialized in
> ovs_ct_limit_get_default_limit().  The rest of the memory is a random
> kernel stack content that ends up being sent to userspace.
> 
> Fix that by using designated initializer that will clear all
> non-specified fields.
> 
> Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
> Signed-off-by: Ilya Maximets 
> ---
>  net/openvswitch/conntrack.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
> index c29b0ef1fc27..cadb6a29b285 100644
> --- a/net/openvswitch/conntrack.c
> +++ b/net/openvswitch/conntrack.c
> @@ -2032,10 +2032,10 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr 
> *nla_zone_limit,
>  static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
> struct sk_buff *reply)
>  {
> - struct ovs_zone_limit zone_limit;
> -
> - zone_limit.zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE;
> - zone_limit.limit = info->default_limit;
> + struct ovs_zone_limit zone_limit = {
> + .zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE,
> + .limit   = info->default_limit,
> + };
>  
>   return nla_put_nohdr(reply, sizeof(zone_limit), _limit);
>  }
> 

[PATCH net] openvswitch: fix send of uninitialized stack memory in ct limit reply

[Ilya Maximets]

'struct ovs_zone_limit' has more members than initialized in
ovs_ct_limit_get_default_limit().  The rest of the memory is a random
kernel stack content that ends up being sent to userspace.

Fix that by using designated initializer that will clear all
non-specified fields.

Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
Signed-off-by: Ilya Maximets 
---
 net/openvswitch/conntrack.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index c29b0ef1fc27..cadb6a29b285 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -2032,10 +2032,10 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr 
*nla_zone_limit,
 static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
  struct sk_buff *reply)
 {
-   struct ovs_zone_limit zone_limit;
-
-   zone_limit.zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE;
-   zone_limit.limit = info->default_limit;
+   struct ovs_zone_limit zone_limit = {
+   .zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE,
+   .limit   = info->default_limit,
+   };
 
return nla_put_nohdr(reply, sizeof(zone_limit), _limit);
 }
-- 
2.26.2

REPLY ME URGENTLY

[Elizabeth Edward]

Greeting

Please forgive me for stressing you with my predicaments and I sorry
to approach you through this media it is because it serves the fastest
means of communication. I came across your E-mail from my personal
search and I decided to contact you believing you will be honest to
fulfill my final wish before I die.

I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.

Since my days are numbered, I’ve decided willingly to fulfill my
long-time promise to donate you the sum ($5.000.000.00) million
dollars I inherited from my late husband Mr. Edward Herbart, foreign
bank account over years. I need a very honest person who can assist in
transfer of this money to his or her account and use the funds for
charities work of God while you use 50% for yourself. I want you to
know there are no risk involved, it is 100% hitch free & safe. If you
will be interesting to assist in getting this fund into your account
for charity project to fulfill my promise before I die please let me
know immediately. I will appreciate your utmost confidentiality as I
wait for your reply.

Best Regards

Mrs. Elizabeth Edward

[PATCH 5.11 022/254] NFS: Correct size calculation for create reply length

[Greg Kroah-Hartman]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index ca10072644ff..ed1c83738c30 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -36,6 +36,7 @@
 #define NFS3_pagepad_sz(1) /* Page padding */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -73,7 +74,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1+NFS3_pagepad_sz)
 #define NFS3_readres_sz
(1+NFS3_post_op_attr_sz+3+NFS3_pagepad_sz)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2+NFS3_pagepad_sz)
-- 
2.30.1

[PATCH 4.19 12/72] NFS: Correct size calculation for create reply length

[Greg Kroah-Hartman]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index 9956453aa6ff..0ed419bb02b0 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -34,6 +34,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -71,7 +72,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2)
-- 
2.30.1

[PATCH 5.10 023/221] NFS: Correct size calculation for create reply length

[Greg Kroah-Hartman]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index 69971f6c840d..dff6b52d26a8 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -35,6 +35,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -72,7 +73,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3+1)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2+1)
-- 
2.30.1

[PATCH 5.4 017/111] NFS: Correct size calculation for create reply length

[Greg Kroah-Hartman]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index 1f60ab2535ee..23d75cddbb2e 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -35,6 +35,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -72,7 +73,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3+1)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2+1)
-- 
2.30.1

[PATCH 4.14 11/59] NFS: Correct size calculation for create reply length

[Greg Kroah-Hartman]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index f1cb0b7eb05f..be666aee28cc 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -34,6 +34,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -71,7 +72,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2)
-- 
2.30.1

[PATCH 4.9 09/53] NFS: Correct size calculation for create reply length

[Greg Kroah-Hartman]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index 267126d32ec0..4a68837e92ea 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -33,6 +33,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -70,7 +71,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2)
-- 
2.30.1

[PATCH 4.4 08/33] NFS: Correct size calculation for create reply length

[Greg Kroah-Hartman]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index 267126d32ec0..4a68837e92ea 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -33,6 +33,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -70,7 +71,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2)
-- 
2.30.1

REPLY ME URGENTLY

[Mrs. Elizabeth Edward]

Greeting

Please forgive me for stressing you with my predicaments and I sorry
to approach you through this media it is because it serves the fastest
means of communication. I came across your E-mail from my personal
search and I decided to contact you believing you will be honest to
fulfill my final wish before I die.

I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.

Since my days are numbered, I’ve decided willingly to fulfill my
long-time promise to donate you the sum ($5.000.000.00) million
dollars I inherited from my late husband Mr. Edward Herbart, foreign
bank account over years. I need a very honest person who can assist in
transfer of this money to his or her account and use the funds for
charities work of God while you use 50% for yourself. I want you to
know there are no risk involved, it is 100% hitch free & safe. If you
will be interesting to assist in getting this fund into your account
for charity project to fulfill my promise before I die please let me
know immediately. I will appreciate your utmost confidentiality as I
wait for your reply.

Best Regards

Mrs. Elizabeth Edward

[PATCH 4/5] seccomp: Support atomic "addfd + send reply"

[Sargun Dhillon]

From: Rodrigo Campos 

Alban Crequy reported a race condition userspace faces when we want to
add some fds and make the syscall return them[1] using seccomp notify.

The problem is that currently two different ioctl() calls are needed by
the process handling the syscalls (agent) for another userspace process
(target): SECCOMP_IOCTL_NOTIF_ADDFD to allocate the fd and
SECCOMP_IOCTL_NOTIF_SEND to return that value. Therefore, it is possible
for the agent to do the first ioctl to add a file descriptor but the
target is interrupted (EINTR) before the agent does the second ioctl()
call.

Other patches in this series add a way to block signals when a syscall
is put to wait by seccomp. However, that might be a big hammer for some
cases, as the golang runtime uses SIGURG to interrupt threads for GC
collection.  Sometimes we just don't want to interfere with the GC, for
example, and just either add the fd and return it or fail the syscall.
With no leaking fds added inadvertly to the target process.

This patch adds a flag to the ADDFD ioctl() so it adds the fd and
returns that value atomically to the target program, as suggested by
Kees Cook[2]. This is done by simply allowing
seccomp_do_user_notification() to add the fd and return it in this case.
Therefore, in this case the target wakes up from the wait in
seccomp_do_user_notification() either to interrupt the syscall or to add
the fd and return it.

This "allocate an fd and return" functionality is useful for syscalls
that return a file descriptor only, like connect(2). Other syscalls that
return a file descriptor but not as return value (or return more than
one fd), like socketpair(), pipe(), recvmsg with SCM_RIGHTs, will not
work with this flag. The way to go to emulate those in cases where a
signal might interrupt is to use the functionality to block signals.

The struct seccomp_notif_resp, used when doing SECCOMP_IOCTL_NOTIF_SEND
ioctl() to send a response to the target, has three more fields that we
don't allow to set when doing the addfd ioctl() to also return. The
reasons to disallow each field are:
 * val: This will be set to the new allocated fd. No point taking it
   from userspace in this case.
 * error: If this is non-zero, the value is ignored. Therefore,
   it is pointless in this case as we want to return the value.
 * flags: The only flag is to let userspace continue to execute the
   syscall. This seems pointless, as we want the syscall to return the
   allocated fd.

This is why those fields are not possible to set when using this new
flag.

[1]: 
https://lore.kernel.org/lkml/cadzs7q4sw71inhmv8eooxhukjmorpzf7thraxzyddtzsxta...@mail.gmail.com/
[2]: https://lore.kernel.org/lkml/202012011322.26DCBC64F2@keescook/

Signed-off-by: Rodrigo Campos 
Signed-off-by: Sargun Dhillon 
---
 include/uapi/linux/seccomp.h |  1 +
 kernel/seccomp.c | 49 +---
 2 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
index bc7fc8b04749..95dd9bab73c6 100644
--- a/include/uapi/linux/seccomp.h
+++ b/include/uapi/linux/seccomp.h
@@ -118,6 +118,7 @@ struct seccomp_notif_resp {
 
 /* valid flags for seccomp_notif_addfd */
 #define SECCOMP_ADDFD_FLAG_SETFD   (1UL << 0) /* Specify remote fd */
+#define SECCOMP_ADDFD_FLAG_SEND(1UL << 1) /* Addfd and return 
it, atomically */
 
 /**
  * struct seccomp_notif_addfd
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 1a38fb1de053..66b3ff58469a 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -109,6 +109,7 @@ struct seccomp_knotif {
  *  installing process should allocate the fd as normal.
  * @flags: The flags for the new file descriptor. At the moment, only O_CLOEXEC
  * is allowed.
+ * @ioctl_flags: The flags used for the seccomp_addfd ioctl.
  * @ret: The return value of the installing process. It is set to the fd num
  *   upon success (>= 0).
  * @completion: Indicates that the installing process has completed fd
@@ -120,6 +121,7 @@ struct seccomp_kaddfd {
struct file *file;
int fd;
unsigned int flags;
+   __u32 ioctl_flags;
 
/* To only be set on reply */
int ret;
@@ -1064,14 +1066,35 @@ static u64 seccomp_next_notify_id(struct seccomp_filter 
*filter)
return filter->notif->next_id++;
 }
 
-static void seccomp_handle_addfd(struct seccomp_kaddfd *addfd)
+static void seccomp_handle_addfd(struct seccomp_kaddfd *addfd, struct 
seccomp_knotif *n)
 {
+   int fd;
+
/*
 * Remove the notification, and reset the list pointers, indicating
 * that it has been handled.
 */
list_del_init(>list);
-   addfd->ret = receive_fd_replace(addfd->fd, addfd->file, addfd->flags);
+   fd = receive_fd_replace(addfd->fd, addfd->file, addfd->flags);
+
+   addfd->ret = fd;
+
+   if (addfd->ioctl_flags & SECCOMP_ADDFD_FLA

[PATCH AUTOSEL 4.9 09/16] NFS: Correct size calculation for create reply length

[Sasha Levin]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index 267126d32ec0..4a68837e92ea 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -33,6 +33,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -70,7 +71,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2)
-- 
2.30.1

[PATCH AUTOSEL 4.4 08/14] NFS: Correct size calculation for create reply length

[Sasha Levin]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index 267126d32ec0..4a68837e92ea 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -33,6 +33,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -70,7 +71,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2)
-- 
2.30.1

[PATCH AUTOSEL 4.14 11/21] NFS: Correct size calculation for create reply length

[Sasha Levin]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index f1cb0b7eb05f..be666aee28cc 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -34,6 +34,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -71,7 +72,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2)
-- 
2.30.1

[PATCH AUTOSEL 5.4 16/37] NFS: Correct size calculation for create reply length

[Sasha Levin]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index 1f60ab2535ee..23d75cddbb2e 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -35,6 +35,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -72,7 +73,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3+1)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2+1)
-- 
2.30.1

[PATCH AUTOSEL 4.19 12/23] NFS: Correct size calculation for create reply length

[Sasha Levin]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index 9956453aa6ff..0ed419bb02b0 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -34,6 +34,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -71,7 +72,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2)
-- 
2.30.1

[PATCH AUTOSEL 5.10 21/54] NFS: Correct size calculation for create reply length

[Sasha Levin]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index 69971f6c840d..dff6b52d26a8 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -35,6 +35,7 @@
  */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -72,7 +73,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1+1)
 #define NFS3_readres_sz(1+NFS3_post_op_attr_sz+3+1)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2+1)
-- 
2.30.1

[PATCH AUTOSEL 5.11 22/61] NFS: Correct size calculation for create reply length

[Sasha Levin]

From: Frank Sorenson 

[ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.

Signed-off-by: Frank Sorenson 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs3xdr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index ca10072644ff..ed1c83738c30 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -36,6 +36,7 @@
 #define NFS3_pagepad_sz(1) /* Page padding */
 #define NFS3_fhandle_sz(1+16)
 #define NFS3_fh_sz (NFS3_fhandle_sz)   /* shorthand */
+#define NFS3_post_op_fh_sz (1+NFS3_fh_sz)
 #define NFS3_sattr_sz  (15)
 #define NFS3_filename_sz   (1+(NFS3_MAXNAMLEN>>2))
 #define NFS3_path_sz   (1+(NFS3_MAXPATHLEN>>2))
@@ -73,7 +74,7 @@
 #define NFS3_readlinkres_sz(1+NFS3_post_op_attr_sz+1+NFS3_pagepad_sz)
 #define NFS3_readres_sz
(1+NFS3_post_op_attr_sz+3+NFS3_pagepad_sz)
 #define NFS3_writeres_sz   (1+NFS3_wcc_data_sz+4)
-#define NFS3_createres_sz  
(1+NFS3_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
+#define NFS3_createres_sz  
(1+NFS3_post_op_fh_sz+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_renameres_sz  (1+(2 * NFS3_wcc_data_sz))
 #define NFS3_linkres_sz
(1+NFS3_post_op_attr_sz+NFS3_wcc_data_sz)
 #define NFS3_readdirres_sz (1+NFS3_post_op_attr_sz+2+NFS3_pagepad_sz)
-- 
2.30.1

TREAT AND REPLY URGENTLY.

[Mr. Dabire Basole]

Dear Friend,

Greetings!

How are you with your family today? I hope both of you are in good
health decently, I know that this message might meet you in utmost
surprise as we never know each other before. I am Mr. Dabire Basole a
banker by profession, I need your urgent assist in transferring the
sum of $10.5 Million U.S Dollars into your account. It is 100% risk
free and under this achievement you are entitled to receive 40% of the
total cash. More details will be sent to you on confirmation of your interest.
Please if you are real interest on my proposer, just providing me your
following information details such as:

(1)NAME..
(2)AGE:
(3)SEX:.
(4)PHONE NUMBER:.
(5)OCCUPATION: .
(6)YOUR COUNTRY:.

Yours sincerely,

Mr.  Dabire Basole.

TREAT AND REPLY URGENTLY.

[Mr. Dabire Basole]

FROM MR. DABIRE BASOLE
AUDIT & ACCOUNT MANAGER
BANK OF AFRICA (B.O.A)
OUAGADOUGOU BURKINA FASO
WEST AFRICA.

Dear Friend,

With due respect, I have decided to contact you on a business
transaction that will be beneficial to both of us. At the bank last
account and auditing evaluation, my staffs came across an old account
which was being maintained by a foreign client who we learn was among
the deceased passengers of motor accident on November.2003, the
deceased was unable to run this account since his death. The account
has remained dormant without the knowledge of his family since it was
put in a safe deposit account in the bank for future investment by the
client.

Since his demise, even the members of his family haven't applied for
claims over this fund and it has been in the safe deposit account
until I discovered that it cannot be claimed since our client is a
foreign national and we are sure that he has no next of kin here to
file claims over the money. As the director of the department, this
discovery was brought to my office so as to decide what is to be done.
I decided to seek ways through which to transfer this money out of the
bank and out of the country too.

The total amount in the account is $10.5 millions with my positions as
staffs of the bank, I am handicapped because I cannot operate foreign
accounts and cannot lay bonafide claim over this money. The client was
a foreign national and you will only be asked to act as his next of
kin and I will supply you with all the necessary information and bank
data to assist you in being able to transfer this money to any bank of
your choice where this money could be transferred into.

The total sum will be shared as follows: 50% for me, 40% for you,
while 10% will map aside for any expenses incidental occur during the
transfering of this fund into your bank account. and the expenses
should be the first thing to be remove before sharing of this fund
according to our percentages . The transfer is risk free on both sides
hence you are going to follow my instruction till the fund transfer to
your account. Since I work in this bank that is why you should be
confident in the success of this transaction because you will be
updated with information as at when desired.

I will wish you to keep this transaction secret and confidential as I
am hoping to retire with my share of this money at the end of
transaction which will be when this money is safety in your account. I
will then come over to your country for sharing according to the
previously agreed percentages. You might even have to advise me on
possibilities of investment in your country or elsewhere of our
choice. May God help you to help me to a restive retirement, Amen,

Please for further information and inquires feel free to contact me
back immediately for more explanation and better understanding I want
you to assure me your capability of handling this project with trust
by providing me your following information details such as:

(1)NAME..
(2)AGE:
(3)SEX:.
(4)PHONE NUMBER:.
(5)OCCUPATION: .
(6)YOUR COUNTRY:.

Yours sincerely,

Mr. Dabire Basole.

TREAT AND REPLY URGENTLY.

[Mr. Dabire Basole]

Dear Friend,

Greetings!

How are you with your family today? I hope both of you are in good
health decently, I know that this message might meet you in utmost
surprise as we never know each other before. I am Mr. Dabire Basole a
banker by profession, I need your urgent assist in transferring the
sum of $10.5 Million U.S Dollars into your account. It is 100% risk
free and under this achievement you are entitled to receive 40% of the
total cash. More details will be sent to you on confirmation of your interest.
Please if you are real interest on my proposer, just providing me your
following information details such as:

(1)NAME..
(2)AGE:
(3)SEX:.
(4)PHONE NUMBER:.
(5)OCCUPATION: .
(6)YOUR COUNTRY:.

Yours sincerely,

Mr.  Dabire Basole.

Reply: Re: [PATCH v5] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip

[李晨阳]

  +void ls7a_mm_wreg_locked(struct loongson_device *ldev, u32 offset, 
u32 val)
  +{
  +   unsigned long flags;
  +
  +   spin_lock_irqsave(ldev-mmio_lock, flags);
  +   writel(val, ldev-mmio + offset);
  +   spin_unlock_irqrestore(ldev-mmio_lock, flags);
  +}
 Why lock and disable irq? To workaround the hw issue from the first
 revision of LS7A? If so, I suggest to remove the workaround. Because:
 1, mmio r/w will be used in irq context; 2, newer revision of LS7A
 doesn't need workaround.
Yes,the lock is to workaround the hw issue,I have decided to remove the lock.
 
  +
  +   /* DC IO */
  +   ldev-io = (void *)TO_UNCAC(LS7A_CHIPCFG_REG_BASE);
 TO_UNCAC() is a MIPS-specific macro, I think ioremap() is better.
OK.I have switched to ioremap, and the test passed.
 
  +#define LS7A_CHIPCFG_REG_BASE (0x1001)
  +#define PCI_DEVICE_ID_LOONGSON_DC 0x7a06
  +#define PCI_DEVICE_ID_LOONGSON_GPU 0x7a15
 They are already defined in include/linux/pci_ids.h.
In include/linux/pci_ids.h only defined PCI_VENDOR_ID_LOONGSON.

--
Loongson LiChenyang

TREAT AND REPLY URGENTLY.

[Mr. Dabire Basole]

Dear Friend,

Greetings!

How are you with your family today? I hope both of you are in good
health decently, I know that this message might meet you in utmost
surprise as we never know each other before. I am Mr. Dabire Basole a
banker by profession, I need your urgent assist in transferring the
sum of $10.5 Million U.S Dollars into your account. It is 100% risk
free and under this achievement you are entitled to receive 40% of the
total cash. More details will be sent to you on confirmation of your interest.
Please if you are real interest on my proposer, just providing me your
following information details such as:

(1)NAME..
(2)AGE:
(3)SEX:.
(4)PHONE NUMBER:.
(5)OCCUPATION: .
(6)YOUR COUNTRY:.

Yours sincerely,

Mr.  Dabire Basole.

REPLY ME URGENTLY

[Mrs. Elizabeth Edward]

Greeting

Please forgive me for stressing you with my predicaments and I sorry
to approach you through this media it is because it serves the fastest
means of communication. I came across your E-mail from my personal
search and I decided to contact you believing you will be honest to
fulfill my final wish before I die.

I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.

Since my days are numbered, I’ve decided willingly to fulfill my
long-time promise to donate you the sum ($5.000.000.00) million
dollars I inherited from my late husband Mr. Edward Herbart, foreign
bank account over years. I need a very honest person who can assist in
transfer of this money to his or her account and use the funds for
charities work of God while you use 50% for yourself. I want you to
know there are no risk involved, it is 100% hitch free & safe. If you
will be interesting to assist in getting this fund into your account
for charity project to fulfill my promise before I die please let me
know immediately. I will appreciate your utmost confidentiality as I
wait for your reply.

Best Regards

Mrs. Elizabeth Edward

Re: This reply comments on the patch to fixes the missing a blank line warning

[David Hildenbrand]

On 12.02.21 11:14, David Hildenbrand wrote:

On 11.02.21 19:20, Adithya Chandrakasan wrote:

On 2/11/21 2:36 AM, David Hildenbrand wrote:

^

Please create proper patch subjects. Nobody has a glue what you are doing when 
looking at the subject.

"mm/util: fix ??? warning"

Which raises the question, what is ???

Compiler? static code checker? ... ?







Thanks

On 11.02.21 08:29, Adithya Chandrakasan wrote:

FILE: mm/util.c:930: WARNING: Missing a blank line after declarations

Signed-off-by: Adithya Chandrakasan 
---
     mm/util.c | 1 +
     1 file changed, 1 insertion(+)

diff --git a/mm/util.c b/mm/util.c
index 8c9b7d1e7c49..60286876636d 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -927,6 +927,7 @@ int get_cmdline(struct task_struct *task, char *buffer, int 
buflen)
     unsigned int len;
     struct mm_struct *mm = get_task_mm(task);
     unsigned long arg_start, arg_end, env_start, env_end;
+
     if (!mm)
     goto out;
     if (!mm->arg_end)





Hi David,

Thanks for feedback. I have fixed the issues in the patch thread with
change in subject and also log message.


Hi,

Please always send patches via proper mails and versioned.

E.g.,

rm *.patch
git format-patch -1 -v2
git send-email --to ... *.patch


The introducing patch is from 2014. So I wonder how you even get a
checkpatch warning?

a90902531a06a ("proc read mm's {arg,env}_{start,end} with mmap semaphore
taken.")


Sorry wrong pointer, it's from 2014

a90902531a06 ("mm: Create utility function for accessing a tasks 
commandline value")



--
Thanks,

David / dhildenb

Re: This reply comments on the patch to fixes the missing a blank line warning

[David Hildenbrand]

On 11.02.21 19:20, Adithya Chandrakasan wrote:

On 2/11/21 2:36 AM, David Hildenbrand wrote:

^

Please create proper patch subjects. Nobody has a glue what you are doing when 
looking at the subject.

"mm/util: fix ??? warning"

Which raises the question, what is ???

Compiler? static code checker? ... ?







Thanks

On 11.02.21 08:29, Adithya Chandrakasan wrote:

FILE: mm/util.c:930: WARNING: Missing a blank line after declarations

Signed-off-by: Adithya Chandrakasan 
---
    mm/util.c | 1 +
    1 file changed, 1 insertion(+)

diff --git a/mm/util.c b/mm/util.c
index 8c9b7d1e7c49..60286876636d 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -927,6 +927,7 @@ int get_cmdline(struct task_struct *task, char *buffer, int 
buflen)
    unsigned int len;
    struct mm_struct *mm = get_task_mm(task);
    unsigned long arg_start, arg_end, env_start, env_end;
+
    if (!mm)
    goto out;
    if (!mm->arg_end)





Hi David,

Thanks for feedback. I have fixed the issues in the patch thread with
change in subject and also log message.


Hi,

Please always send patches via proper mails and versioned.

E.g.,

rm *.patch
git format-patch -1 -v2
git send-email --to ... *.patch


The introducing patch is from 2014. So I wonder how you even get a 
checkpatch warning?


a90902531a06a ("proc read mm's {arg,env}_{start,end} with mmap semaphore 
taken.")


Anyhow, maybe just call this patch "mm: util.c: minor coding style fix", 
that makes it clearer that this is really minor and has been in the code 
for a while.


Thanks!

--
Thanks,

David / dhildenb

Re: This reply comments on the patch to fixes the missing a blank line warning

[Adithya Chandrakasan]

On 2/11/21 2:36 AM, David Hildenbrand wrote:
> ^
>
> Please create proper patch subjects. Nobody has a glue what you are doing 
> when looking at the subject.
>
> "mm/util: fix ??? warning"
>
> Which raises the question, what is ???
>
> Compiler? static code checker? ... ?
>
>
> Thanks
>
> On 11.02.21 08:29, Adithya Chandrakasan wrote:
>> FILE: mm/util.c:930: WARNING: Missing a blank line after declarations
>>
>> Signed-off-by: Adithya Chandrakasan 
>> ---
>>   mm/util.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/mm/util.c b/mm/util.c
>> index 8c9b7d1e7c49..60286876636d 100644
>> --- a/mm/util.c
>> +++ b/mm/util.c
>> @@ -927,6 +927,7 @@ int get_cmdline(struct task_struct *task, char *buffer, 
>> int buflen)
>>   unsigned int len;
>>   struct mm_struct *mm = get_task_mm(task);
>>   unsigned long arg_start, arg_end, env_start, env_end;
>> +
>>   if (!mm)
>>   goto out;
>>   if (!mm->arg_end)
>>
>
>
Hi David,

Thanks for feedback. I have fixed the issues in the patch thread with
change in subject and also log message.

with regards,
Adithya Chandrakasan

--- Begin Message ---
FILE: mm/util.c:930:
checkpatch.pl scripts basic coding style issues as below
WARNING: Missing a blank line after declarations

Signed-off-by: Adithya Chandrakasan 
---
 mm/util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/util.c b/mm/util.c
index 8c9b7d1e7c49..60286876636d 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -927,6 +927,7 @@ int get_cmdline(struct task_struct *task, char *buffer, int 
buflen)
unsigned int len;
struct mm_struct *mm = get_task_mm(task);
unsigned long arg_start, arg_end, env_start, env_end;
+
if (!mm)
goto out;
if (!mm->arg_end)
-- 
2.25.1

--- End Message ---

This reply comments on the patch to fixes the missing a blank line warning

[David Hildenbrand]

^

Please create proper patch subjects. Nobody has a glue what you are 
doing when looking at the subject.


"mm/util: fix ??? warning"

Which raises the question, what is ???

Compiler? static code checker? ... ?


Thanks

On 11.02.21 08:29, Adithya Chandrakasan wrote:

FILE: mm/util.c:930: WARNING: Missing a blank line after declarations

Signed-off-by: Adithya Chandrakasan 
---
  mm/util.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/mm/util.c b/mm/util.c
index 8c9b7d1e7c49..60286876636d 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -927,6 +927,7 @@ int get_cmdline(struct task_struct *task, char *buffer, int 
buflen)
unsigned int len;
struct mm_struct *mm = get_task_mm(task);
unsigned long arg_start, arg_end, env_start, env_end;
+
if (!mm)
goto out;
if (!mm->arg_end)




--
Thanks,

David / dhildenb

REPLY ME URGENTLY

[Elizabeth Edward]

Greeting

Please forgive me for stressing you with my predicaments and I sorry
to approach you through this media it is because it serves the fastest
means of communication. I came across your E-mail from my personal
search and I decided to contact you believing you will be honest to
fulfill my final wish before I die.

I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.

Since my days are numbered, I have decided willingly to fulfill my
long-time promise to donate you the sum ($5.000.000.00) million
dollars I inherited from my late husband Mr. Edward Herbart, foreign
bank account over years. I need a very honest person who can assist in
transfer of this money to his or her account and use the funds for
charities work of God while you use 50% for yourself. I want you to
know there are no risks involved; it is 100% hitch free & safe. If you
will be interesting to assist in getting this fund into your account
for charity project to fulfill my promise before I die please let me
know immediately. I will appreciate your utmost confidentiality as I
wait for your reply.


Best Regard,


Mrs. Elizabeth Edward

[PATCH 5.4 02/61] IPv6: reply ICMP error if the first fragment dont include all headers

[Greg Kroah-Hartman]

From: Hangbin Liu 

commit 2efdaaaf883a143061296467913c01aa1ff4b3ce upstream.

Based on RFC 8200, Section 4.5 Fragment Header:

  -  If the first fragment does not include all headers through an
 Upper-Layer header, then that fragment should be discarded and
 an ICMP Parameter Problem, Code 3, message should be sent to
 the source of the fragment, with the Pointer field set to zero.

Checking each packet header in IPv6 fast path will have performance impact,
so I put the checking in ipv6_frag_rcv().

As the packet may be any kind of L4 protocol, I only checked some common
protocols' header length and handle others by (offset + 1) > skb->len.
Also use !(frag_off & htons(IP6_OFFSET)) to catch atomic fragments
(fragmented packet with only one fragment).

When send ICMP error message, if the 1st truncated fragment is ICMP message,
icmp6_send() will break as is_ineligible() return true. So I added a check
in is_ineligible() to let fragment packet with nexthdr ICMP but no ICMP header
return false.

Signed-off-by: Hangbin Liu 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Aviraj CJ 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/icmp.c   |8 +++-
 net/ipv6/reassembly.c |   33 -
 2 files changed, 39 insertions(+), 2 deletions(-)

--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -158,7 +158,13 @@ static bool is_ineligible(const struct s
tp = skb_header_pointer(skb,
ptr+offsetof(struct icmp6hdr, icmp6_type),
sizeof(_type), &_type);
-   if (!tp || !(*tp & ICMPV6_INFOMSG_MASK))
+
+   /* Based on RFC 8200, Section 4.5 Fragment Header, return
+* false if this is a fragment packet with no icmp header info.
+*/
+   if (!tp && frag_off != 0)
+   return false;
+   else if (!tp || !(*tp & ICMPV6_INFOMSG_MASK))
return true;
}
return false;
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -42,6 +42,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -322,7 +324,9 @@ static int ipv6_frag_rcv(struct sk_buff
struct frag_queue *fq;
const struct ipv6hdr *hdr = ipv6_hdr(skb);
struct net *net = dev_net(skb_dst(skb)->dev);
-   int iif;
+   __be16 frag_off;
+   int iif, offset;
+   u8 nexthdr;
 
if (IP6CB(skb)->flags & IP6SKB_FRAGMENTED)
goto fail_hdr;
@@ -351,6 +355,33 @@ static int ipv6_frag_rcv(struct sk_buff
return 1;
}
 
+   /* RFC 8200, Section 4.5 Fragment Header:
+* If the first fragment does not include all headers through an
+* Upper-Layer header, then that fragment should be discarded and
+* an ICMP Parameter Problem, Code 3, message should be sent to
+* the source of the fragment, with the Pointer field set to zero.
+*/
+   nexthdr = hdr->nexthdr;
+   offset = ipv6_skip_exthdr(skb, skb_transport_offset(skb), , 
_off);
+   if (offset >= 0) {
+   /* Check some common protocols' header */
+   if (nexthdr == IPPROTO_TCP)
+   offset += sizeof(struct tcphdr);
+   else if (nexthdr == IPPROTO_UDP)
+   offset += sizeof(struct udphdr);
+   else if (nexthdr == IPPROTO_ICMPV6)
+   offset += sizeof(struct icmp6hdr);
+   else
+   offset += 1;
+
+   if (!(frag_off & htons(IP6_OFFSET)) && offset > skb->len) {
+   __IP6_INC_STATS(net, __in6_dev_get_safely(skb->dev),
+   IPSTATS_MIB_INHDRERRORS);
+   icmpv6_param_prob(skb, ICMPV6_HDR_INCOMP, 0);
+   return -1;
+   }
+   }
+
iif = skb->dev ? skb->dev->ifindex : 0;
fq = fq_find(net, fhdr->identification, hdr, iif);
if (fq) {

Re: [PATCH stable v5.4 2/2] IPv6: reply ICMP error if the first fragment don't include all headers

[Greg KH]

On Sat, Jan 30, 2021 at 05:24:52PM +0530, Aviraj CJ wrote:
> From: Hangbin Liu 
> 
> commit 2efdaaaf883a143061296467913c01aa1ff4b3ce upstream.
> 
> Based on RFC 8200, Section 4.5 Fragment Header:
> 
>   -  If the first fragment does not include all headers through an
>  Upper-Layer header, then that fragment should be discarded and
>  an ICMP Parameter Problem, Code 3, message should be sent to
>  the source of the fragment, with the Pointer field set to zero.
> 
> Checking each packet header in IPv6 fast path will have performance impact,
> so I put the checking in ipv6_frag_rcv().
> 
> As the packet may be any kind of L4 protocol, I only checked some common
> protocols' header length and handle others by (offset + 1) > skb->len.
> Also use !(frag_off & htons(IP6_OFFSET)) to catch atomic fragments
> (fragmented packet with only one fragment).
> 
> When send ICMP error message, if the 1st truncated fragment is ICMP message,
> icmp6_send() will break as is_ineligible() return true. So I added a check
> in is_ineligible() to let fragment packet with nexthdr ICMP but no ICMP header
> return false.
> 
> Signed-off-by: Hangbin Liu 
> Signed-off-by: Jakub Kicinski 
> Signed-off-by: Aviraj CJ 
> ---
>  net/ipv6/icmp.c   |  8 +++-
>  net/ipv6/reassembly.c | 33 -
>  2 files changed, 39 insertions(+), 2 deletions(-)

Both now queued up, thanks.

greg k-h

[PATCH stable v5.4 2/2] IPv6: reply ICMP error if the first fragment don't include all headers

[Aviraj CJ]

From: Hangbin Liu 

commit 2efdaaaf883a143061296467913c01aa1ff4b3ce upstream.

Based on RFC 8200, Section 4.5 Fragment Header:

  -  If the first fragment does not include all headers through an
 Upper-Layer header, then that fragment should be discarded and
 an ICMP Parameter Problem, Code 3, message should be sent to
 the source of the fragment, with the Pointer field set to zero.

Checking each packet header in IPv6 fast path will have performance impact,
so I put the checking in ipv6_frag_rcv().

As the packet may be any kind of L4 protocol, I only checked some common
protocols' header length and handle others by (offset + 1) > skb->len.
Also use !(frag_off & htons(IP6_OFFSET)) to catch atomic fragments
(fragmented packet with only one fragment).

When send ICMP error message, if the 1st truncated fragment is ICMP message,
icmp6_send() will break as is_ineligible() return true. So I added a check
in is_ineligible() to let fragment packet with nexthdr ICMP but no ICMP header
return false.

Signed-off-by: Hangbin Liu 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Aviraj CJ 
---
 net/ipv6/icmp.c   |  8 +++-
 net/ipv6/reassembly.c | 33 -
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 7d3a3894f785..e9bb89131e02 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -158,7 +158,13 @@ static bool is_ineligible(const struct sk_buff *skb)
tp = skb_header_pointer(skb,
ptr+offsetof(struct icmp6hdr, icmp6_type),
sizeof(_type), &_type);
-   if (!tp || !(*tp & ICMPV6_INFOMSG_MASK))
+
+   /* Based on RFC 8200, Section 4.5 Fragment Header, return
+* false if this is a fragment packet with no icmp header info.
+*/
+   if (!tp && frag_off != 0)
+   return false;
+   else if (!tp || !(*tp & ICMPV6_INFOMSG_MASK))
return true;
}
return false;
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 1f5d4d196dcc..c8cf1bbad74a 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -42,6 +42,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -322,7 +324,9 @@ static int ipv6_frag_rcv(struct sk_buff *skb)
struct frag_queue *fq;
const struct ipv6hdr *hdr = ipv6_hdr(skb);
struct net *net = dev_net(skb_dst(skb)->dev);
-   int iif;
+   __be16 frag_off;
+   int iif, offset;
+   u8 nexthdr;
 
if (IP6CB(skb)->flags & IP6SKB_FRAGMENTED)
goto fail_hdr;
@@ -351,6 +355,33 @@ static int ipv6_frag_rcv(struct sk_buff *skb)
return 1;
}
 
+   /* RFC 8200, Section 4.5 Fragment Header:
+* If the first fragment does not include all headers through an
+* Upper-Layer header, then that fragment should be discarded and
+* an ICMP Parameter Problem, Code 3, message should be sent to
+* the source of the fragment, with the Pointer field set to zero.
+*/
+   nexthdr = hdr->nexthdr;
+   offset = ipv6_skip_exthdr(skb, skb_transport_offset(skb), , 
_off);
+   if (offset >= 0) {
+   /* Check some common protocols' header */
+   if (nexthdr == IPPROTO_TCP)
+   offset += sizeof(struct tcphdr);
+   else if (nexthdr == IPPROTO_UDP)
+   offset += sizeof(struct udphdr);
+   else if (nexthdr == IPPROTO_ICMPV6)
+   offset += sizeof(struct icmp6hdr);
+   else
+   offset += 1;
+
+   if (!(frag_off & htons(IP6_OFFSET)) && offset > skb->len) {
+   __IP6_INC_STATS(net, __in6_dev_get_safely(skb->dev),
+   IPSTATS_MIB_INHDRERRORS);
+   icmpv6_param_prob(skb, ICMPV6_HDR_INCOMP, 0);
+   return -1;
+   }
+   }
+
iif = skb->dev ? skb->dev->ifindex : 0;
fq = fq_find(net, fhdr->identification, hdr, iif);
if (fq) {
-- 
2.26.2.Cisco

[Internal review][PATCH stable v5.4 2/2] IPv6: reply ICMP error if the first fragment don't include all headers

[Aviraj CJ]

From: Hangbin Liu 

commit 2efdaaaf883a143061296467913c01aa1ff4b3ce upstream.

Based on RFC 8200, Section 4.5 Fragment Header:

  -  If the first fragment does not include all headers through an
 Upper-Layer header, then that fragment should be discarded and
 an ICMP Parameter Problem, Code 3, message should be sent to
 the source of the fragment, with the Pointer field set to zero.

Checking each packet header in IPv6 fast path will have performance impact,
so I put the checking in ipv6_frag_rcv().

As the packet may be any kind of L4 protocol, I only checked some common
protocols' header length and handle others by (offset + 1) > skb->len.
Also use !(frag_off & htons(IP6_OFFSET)) to catch atomic fragments
(fragmented packet with only one fragment).

When send ICMP error message, if the 1st truncated fragment is ICMP message,
icmp6_send() will break as is_ineligible() return true. So I added a check
in is_ineligible() to let fragment packet with nexthdr ICMP but no ICMP header
return false.

Signed-off-by: Hangbin Liu 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Aviraj CJ 
---
 net/ipv6/icmp.c   |  8 +++-
 net/ipv6/reassembly.c | 33 -
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 7d3a3894f785..e9bb89131e02 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -158,7 +158,13 @@ static bool is_ineligible(const struct sk_buff *skb)
tp = skb_header_pointer(skb,
ptr+offsetof(struct icmp6hdr, icmp6_type),
sizeof(_type), &_type);
-   if (!tp || !(*tp & ICMPV6_INFOMSG_MASK))
+
+   /* Based on RFC 8200, Section 4.5 Fragment Header, return
+* false if this is a fragment packet with no icmp header info.
+*/
+   if (!tp && frag_off != 0)
+   return false;
+   else if (!tp || !(*tp & ICMPV6_INFOMSG_MASK))
return true;
}
return false;
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 1f5d4d196dcc..c8cf1bbad74a 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -42,6 +42,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -322,7 +324,9 @@ static int ipv6_frag_rcv(struct sk_buff *skb)
struct frag_queue *fq;
const struct ipv6hdr *hdr = ipv6_hdr(skb);
struct net *net = dev_net(skb_dst(skb)->dev);
-   int iif;
+   __be16 frag_off;
+   int iif, offset;
+   u8 nexthdr;
 
if (IP6CB(skb)->flags & IP6SKB_FRAGMENTED)
goto fail_hdr;
@@ -351,6 +355,33 @@ static int ipv6_frag_rcv(struct sk_buff *skb)
return 1;
}
 
+   /* RFC 8200, Section 4.5 Fragment Header:
+* If the first fragment does not include all headers through an
+* Upper-Layer header, then that fragment should be discarded and
+* an ICMP Parameter Problem, Code 3, message should be sent to
+* the source of the fragment, with the Pointer field set to zero.
+*/
+   nexthdr = hdr->nexthdr;
+   offset = ipv6_skip_exthdr(skb, skb_transport_offset(skb), , 
_off);
+   if (offset >= 0) {
+   /* Check some common protocols' header */
+   if (nexthdr == IPPROTO_TCP)
+   offset += sizeof(struct tcphdr);
+   else if (nexthdr == IPPROTO_UDP)
+   offset += sizeof(struct udphdr);
+   else if (nexthdr == IPPROTO_ICMPV6)
+   offset += sizeof(struct icmp6hdr);
+   else
+   offset += 1;
+
+   if (!(frag_off & htons(IP6_OFFSET)) && offset > skb->len) {
+   __IP6_INC_STATS(net, __in6_dev_get_safely(skb->dev),
+   IPSTATS_MIB_INHDRERRORS);
+   icmpv6_param_prob(skb, ICMPV6_HDR_INCOMP, 0);
+   return -1;
+   }
+   }
+
iif = skb->dev ? skb->dev->ifindex : 0;
fq = fq_find(net, fhdr->identification, hdr, iif);
if (fq) {
-- 
2.26.2.Cisco

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jonathan Cameron]

On Sun, 17 Jan 2021 13:02:31 -0800
Jyoti Bhayana  wrote:

> Hi Jonathan,
> 
> Instead of IIO_VAL_INT_PLUS_MICRO, we can also use IIO_VAL_FRACTIONAL
> right for the raw values for min/max range and resolution? But, to

Sure on IIO_VAL_FRACTIONAL, that should be fine.

> keep things simple though, it will be nice if the IIO driver uses
> IIO_VAL_INT and throws an error if there is a negative exponent in the
> following  calculation for the resolution which means the res_exponent
> is always the same or greater than the scale_exponent.

If that tends to be true, then indeed that should work fine.

> 
>  [res] x 10^(res_exponent - exponent)
> 
> so the IIO driver will use IIO_AVAIL_RANGE and IIO_VAL_INT and throw
> error and not support that sensor if the following conditions happen:
> 1) min/max range is using H32 bits
> 2) resolution exponent is greater than the scale exponent.

Sounds good though I've not thought through whether we can in general
expect 2 to be true.  Feels like it should be though!

Jonathan
> 
> 
> Thanks,
> Jyoti
> 
> 
> On Sun, Jan 17, 2021 at 3:56 AM Jonathan Cameron  wrote:
> >
> > On Sat, 16 Jan 2021 23:15:56 -0800
> > Jyoti Bhayana  wrote:
> >  
> > > Hi Jonathan,
> > >
> > > Can you clarify one thing ? If we go with option 2 which is using
> > > IIO_AVAIL_RANGE for min,step,high using IIO_VAL_INT then how will it
> > > ensure the possible floating value for step as we are using int type?  
> > As you've identified we can't go with IIO_VAL_INT if we are doing that
> > approach, would need to be IIO_VAL_INT_PLUS_MICRO (possibly NANO)
> >
> > That is why it comes unstuck if we need to use both val and val2 to
> > do 64 bit integers...
> >
> > For the  min and max we just set the val2 value to 0.
> >
> > Jonathan
> >
> >  
> > >
> > > Thanks,
> > > Jyoti
> > >
> > > On Sat, Jan 16, 2021 at 11:33 AM Jonathan Cameron  
> > > wrote:  
> > > >
> > > > On Mon, 11 Jan 2021 13:17:51 -0800
> > > > Jyoti Bhayana  wrote:
> > > >  
> > > > > Hi Jonathan,
> > > > >
> > > > > I know it is a bit confusing. Let me try to explain it with some
> > > > > examples to hopefully clarify some things here.
> > > > > SCMI Platform talks to the native/actual sensor, gets the raw values
> > > > > from the native sensor and applies the scale and then sends those
> > > > > values to the SCMI agent and the SCMI IIO driver.
> > > > > Since the sensor readings which SCMI IIO driver gets are integer, to
> > > > > convert them to float , we need to apply scale to these sensor values
> > > > > which is the unit_exponent(power-of-10 multiplier in two’s-complement
> > > > > format) specified in the SCMI specification
> > > > >
> > > > > Native Sensor -> SCMI platform->SCMI Agent->SCMI IIO Driver
> > > > >
> > > > > So if Native Sensor gets the sensor value
> > > > > 32767 and the scale the SCMI Platform is using is 0.002392.
> > > > > SCMI platform does the calculation of 32767 * 0.002392 = 78.378664
> > > > > and send the sensor value as 78378664 and the scale as .01 to the
> > > > > SCMI agent and SCMI IIO driver
> > > > >
> > > > > so for SCMI IIO driver the sensor reading = 78378664 and scale = 
> > > > > .01
> > > > > and  the sensor value is sensor_reading * scale = 78378664 *  .01
> > > > > =  78.378664
> > > > > and the resolution which the SCMI Platform sends to the SCMI agent is 
> > > > > 0.002392.
> > > > > In the SCMI IIO driver, scale which is .01 is applied to the min
> > > > > range/max range and the actual sensor values.
> > > > > sensor resolution which is  0.002392 is just passed to the userspace
> > > > > layer so that they know the Native sensor resolution/scale
> > > > > being applied by the SCMI platform.  
> > > >
> > > > That was pretty much where I'd gotten to.
> > > > Whilst the reasoning might be different it is equivalent to a sensor
> > > > providing info on expected noise by giving a 'valid resolution'.
> > > > In that case as well you have a sensor providing a number that looks to 
> > > > have
> > > > more precision than it actually does.
> > > >
> > > > Anyhow, that similarity doesn't really matter here.
> > > >
> > > > I'll also add that a design that applies scale in two places is 
> > > > inherently
> > > > less than ideal.   A cleaner design would have maintained the separation
> > > > between scale and raw value all the way up the stack.  That would result
> > > > in 0 loss of information and also be a cleaner interface.
> > > > Ah well, we live with what we have :)
> > > >  
> > > > >
> > > > > Regarding your comments in the previous email, when you mentioned
> > > > > "what we actually
> > > > > need is non standard ABI for resolution"? Does that mean that it is ok
> > > > > to have sensor resolution
> > > > > as the IIO attribute shown below?
> > > > >
> > > > > static IIO_DEVICE_ATTR(sensor_resolution, 0444, 
> > > > > scmi_iio_get_sensor_resolution,
> > > > >  NULL, 0);  
> > > >
> > > > We could do something new (see later for why I don't 

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jyoti Bhayana]

Hi Jonathan,

Instead of IIO_VAL_INT_PLUS_MICRO, we can also use IIO_VAL_FRACTIONAL
right for the raw values for min/max range and resolution? But, to
keep things simple though, it will be nice if the IIO driver uses
IIO_VAL_INT and throws an error if there is a negative exponent in the
following  calculation for the resolution which means the res_exponent
is always the same or greater than the scale_exponent.

 [res] x 10^(res_exponent - exponent)

so the IIO driver will use IIO_AVAIL_RANGE and IIO_VAL_INT and throw
error and not support that sensor if the following conditions happen:
1) min/max range is using H32 bits
2) resolution exponent is greater than the scale exponent.


Thanks,
Jyoti


On Sun, Jan 17, 2021 at 3:56 AM Jonathan Cameron  wrote:
>
> On Sat, 16 Jan 2021 23:15:56 -0800
> Jyoti Bhayana  wrote:
>
> > Hi Jonathan,
> >
> > Can you clarify one thing ? If we go with option 2 which is using
> > IIO_AVAIL_RANGE for min,step,high using IIO_VAL_INT then how will it
> > ensure the possible floating value for step as we are using int type?
> As you've identified we can't go with IIO_VAL_INT if we are doing that
> approach, would need to be IIO_VAL_INT_PLUS_MICRO (possibly NANO)
>
> That is why it comes unstuck if we need to use both val and val2 to
> do 64 bit integers...
>
> For the  min and max we just set the val2 value to 0.
>
> Jonathan
>
>
> >
> > Thanks,
> > Jyoti
> >
> > On Sat, Jan 16, 2021 at 11:33 AM Jonathan Cameron  wrote:
> > >
> > > On Mon, 11 Jan 2021 13:17:51 -0800
> > > Jyoti Bhayana  wrote:
> > >
> > > > Hi Jonathan,
> > > >
> > > > I know it is a bit confusing. Let me try to explain it with some
> > > > examples to hopefully clarify some things here.
> > > > SCMI Platform talks to the native/actual sensor, gets the raw values
> > > > from the native sensor and applies the scale and then sends those
> > > > values to the SCMI agent and the SCMI IIO driver.
> > > > Since the sensor readings which SCMI IIO driver gets are integer, to
> > > > convert them to float , we need to apply scale to these sensor values
> > > > which is the unit_exponent(power-of-10 multiplier in two’s-complement
> > > > format) specified in the SCMI specification
> > > >
> > > > Native Sensor -> SCMI platform->SCMI Agent->SCMI IIO Driver
> > > >
> > > > So if Native Sensor gets the sensor value
> > > > 32767 and the scale the SCMI Platform is using is 0.002392.
> > > > SCMI platform does the calculation of 32767 * 0.002392 = 78.378664
> > > > and send the sensor value as 78378664 and the scale as .01 to the
> > > > SCMI agent and SCMI IIO driver
> > > >
> > > > so for SCMI IIO driver the sensor reading = 78378664 and scale = .01
> > > > and  the sensor value is sensor_reading * scale = 78378664 *  .01
> > > > =  78.378664
> > > > and the resolution which the SCMI Platform sends to the SCMI agent is 
> > > > 0.002392.
> > > > In the SCMI IIO driver, scale which is .01 is applied to the min
> > > > range/max range and the actual sensor values.
> > > > sensor resolution which is  0.002392 is just passed to the userspace
> > > > layer so that they know the Native sensor resolution/scale
> > > > being applied by the SCMI platform.
> > >
> > > That was pretty much where I'd gotten to.
> > > Whilst the reasoning might be different it is equivalent to a sensor
> > > providing info on expected noise by giving a 'valid resolution'.
> > > In that case as well you have a sensor providing a number that looks to 
> > > have
> > > more precision than it actually does.
> > >
> > > Anyhow, that similarity doesn't really matter here.
> > >
> > > I'll also add that a design that applies scale in two places is inherently
> > > less than ideal.   A cleaner design would have maintained the separation
> > > between scale and raw value all the way up the stack.  That would result
> > > in 0 loss of information and also be a cleaner interface.
> > > Ah well, we live with what we have :)
> > >
> > > >
> > > > Regarding your comments in the previous email, when you mentioned
> > > > "what we actually
> > > > need is non standard ABI for resolution"? Does that mean that it is ok
> > > > to have sensor resolution
> > > > as the IIO attribute shown below?
> > > >
> > > > static IIO_DEVICE_ATTR(sensor_resolution, 0444, 
> > > > scmi_iio_get_sensor_resolution,
> > > >  NULL, 0);
> > >
> > > We could do something new (see later for why I don't think we need to)
> > > Would need to clearly reflect what it applies to and I'm not sure 
> > > resolution
> > > is even an unambiguous name given sensor resolution is often described as 
> > > 8bit
> > > 10bit etc.  E.g. this selection table from Maxim for ADCs.
> > > https://www.maximintegrated.com/en/products/parametric/search.html?fam=prec_adc=master=Precision%20ADCs%20(%20%205Msps)=270
> > > Of course sometimes it's also used for what you want here.
> > >
> > > Hohum.  So we might be still be able to do this with standard ABI but we
> > > are going to need 

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jonathan Cameron]

On Sat, 16 Jan 2021 23:15:56 -0800
Jyoti Bhayana  wrote:

> Hi Jonathan,
> 
> Can you clarify one thing ? If we go with option 2 which is using
> IIO_AVAIL_RANGE for min,step,high using IIO_VAL_INT then how will it
> ensure the possible floating value for step as we are using int type?
As you've identified we can't go with IIO_VAL_INT if we are doing that
approach, would need to be IIO_VAL_INT_PLUS_MICRO (possibly NANO)

That is why it comes unstuck if we need to use both val and val2 to
do 64 bit integers...

For the  min and max we just set the val2 value to 0.

Jonathan


> 
> Thanks,
> Jyoti
> 
> On Sat, Jan 16, 2021 at 11:33 AM Jonathan Cameron  wrote:
> >
> > On Mon, 11 Jan 2021 13:17:51 -0800
> > Jyoti Bhayana  wrote:
> >  
> > > Hi Jonathan,
> > >
> > > I know it is a bit confusing. Let me try to explain it with some
> > > examples to hopefully clarify some things here.
> > > SCMI Platform talks to the native/actual sensor, gets the raw values
> > > from the native sensor and applies the scale and then sends those
> > > values to the SCMI agent and the SCMI IIO driver.
> > > Since the sensor readings which SCMI IIO driver gets are integer, to
> > > convert them to float , we need to apply scale to these sensor values
> > > which is the unit_exponent(power-of-10 multiplier in two’s-complement
> > > format) specified in the SCMI specification
> > >
> > > Native Sensor -> SCMI platform->SCMI Agent->SCMI IIO Driver
> > >
> > > So if Native Sensor gets the sensor value
> > > 32767 and the scale the SCMI Platform is using is 0.002392.
> > > SCMI platform does the calculation of 32767 * 0.002392 = 78.378664
> > > and send the sensor value as 78378664 and the scale as .01 to the
> > > SCMI agent and SCMI IIO driver
> > >
> > > so for SCMI IIO driver the sensor reading = 78378664 and scale = .01
> > > and  the sensor value is sensor_reading * scale = 78378664 *  .01
> > > =  78.378664
> > > and the resolution which the SCMI Platform sends to the SCMI agent is 
> > > 0.002392.
> > > In the SCMI IIO driver, scale which is .01 is applied to the min
> > > range/max range and the actual sensor values.
> > > sensor resolution which is  0.002392 is just passed to the userspace
> > > layer so that they know the Native sensor resolution/scale
> > > being applied by the SCMI platform.  
> >
> > That was pretty much where I'd gotten to.
> > Whilst the reasoning might be different it is equivalent to a sensor
> > providing info on expected noise by giving a 'valid resolution'.
> > In that case as well you have a sensor providing a number that looks to have
> > more precision than it actually does.
> >
> > Anyhow, that similarity doesn't really matter here.
> >
> > I'll also add that a design that applies scale in two places is inherently
> > less than ideal.   A cleaner design would have maintained the separation
> > between scale and raw value all the way up the stack.  That would result
> > in 0 loss of information and also be a cleaner interface.
> > Ah well, we live with what we have :)
> >  
> > >
> > > Regarding your comments in the previous email, when you mentioned
> > > "what we actually
> > > need is non standard ABI for resolution"? Does that mean that it is ok
> > > to have sensor resolution
> > > as the IIO attribute shown below?
> > >
> > > static IIO_DEVICE_ATTR(sensor_resolution, 0444, 
> > > scmi_iio_get_sensor_resolution,
> > >  NULL, 0);  
> >
> > We could do something new (see later for why I don't think we need to)
> > Would need to clearly reflect what it applies to and I'm not sure resolution
> > is even an unambiguous name given sensor resolution is often described as 
> > 8bit
> > 10bit etc.  E.g. this selection table from Maxim for ADCs.
> > https://www.maximintegrated.com/en/products/parametric/search.html?fam=prec_adc=master=Precision%20ADCs%20(%20%205Msps)=270
> > Of course sometimes it's also used for what you want here.
> >
> > Hohum.  So we might be still be able to do this with standard ABI but we
> > are going to need to do some maths in the driver.
> > So if we were to express it via
> >
> > in_accel_raw_avail for example we could use the [low step high] form.
> >
> > low and high are straight forward as those are expressed directly from
> > axis_min_range and axis_max_range which I think are in the same units
> > as the _raw channel itself.
> >
> > For resolution, we have it expressed as [res] x 10^res_exponent
> > and if we just put that in as the 'step' above it would have the wrong
> > exponent (as we'd expect to still have to apply your 0.1 from above
> > example).
> >
> > Hence we express it as [res] x 10^(res_exponent - exponent)
> >
> > I'm going to slightly modify your example above because the two exponents
> > are the same so it's hard to tell if I have them right way around.
> > Hence let res = 0.00293 = 293 x 10^(-5)  (I just dropped the trailing 2)
> >
> > scale = 10^(-6) exponent = -6
> >
> > So step = 2392 x 10^(-5 + 6) = 2390
> 

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jyoti Bhayana]

Hi Jonathan,

Can you clarify one thing ? If we go with option 2 which is using
IIO_AVAIL_RANGE for min,step,high using IIO_VAL_INT then how will it
ensure the possible floating value for step as we are using int type?

Thanks,
Jyoti

On Sat, Jan 16, 2021 at 11:33 AM Jonathan Cameron  wrote:
>
> On Mon, 11 Jan 2021 13:17:51 -0800
> Jyoti Bhayana  wrote:
>
> > Hi Jonathan,
> >
> > I know it is a bit confusing. Let me try to explain it with some
> > examples to hopefully clarify some things here.
> > SCMI Platform talks to the native/actual sensor, gets the raw values
> > from the native sensor and applies the scale and then sends those
> > values to the SCMI agent and the SCMI IIO driver.
> > Since the sensor readings which SCMI IIO driver gets are integer, to
> > convert them to float , we need to apply scale to these sensor values
> > which is the unit_exponent(power-of-10 multiplier in two’s-complement
> > format) specified in the SCMI specification
> >
> > Native Sensor -> SCMI platform->SCMI Agent->SCMI IIO Driver
> >
> > So if Native Sensor gets the sensor value
> > 32767 and the scale the SCMI Platform is using is 0.002392.
> > SCMI platform does the calculation of 32767 * 0.002392 = 78.378664
> > and send the sensor value as 78378664 and the scale as .01 to the
> > SCMI agent and SCMI IIO driver
> >
> > so for SCMI IIO driver the sensor reading = 78378664 and scale = .01
> > and  the sensor value is sensor_reading * scale = 78378664 *  .01
> > =  78.378664
> > and the resolution which the SCMI Platform sends to the SCMI agent is 
> > 0.002392.
> > In the SCMI IIO driver, scale which is .01 is applied to the min
> > range/max range and the actual sensor values.
> > sensor resolution which is  0.002392 is just passed to the userspace
> > layer so that they know the Native sensor resolution/scale
> > being applied by the SCMI platform.
>
> That was pretty much where I'd gotten to.
> Whilst the reasoning might be different it is equivalent to a sensor
> providing info on expected noise by giving a 'valid resolution'.
> In that case as well you have a sensor providing a number that looks to have
> more precision than it actually does.
>
> Anyhow, that similarity doesn't really matter here.
>
> I'll also add that a design that applies scale in two places is inherently
> less than ideal.   A cleaner design would have maintained the separation
> between scale and raw value all the way up the stack.  That would result
> in 0 loss of information and also be a cleaner interface.
> Ah well, we live with what we have :)
>
> >
> > Regarding your comments in the previous email, when you mentioned
> > "what we actually
> > need is non standard ABI for resolution"? Does that mean that it is ok
> > to have sensor resolution
> > as the IIO attribute shown below?
> >
> > static IIO_DEVICE_ATTR(sensor_resolution, 0444, 
> > scmi_iio_get_sensor_resolution,
> >  NULL, 0);
>
> We could do something new (see later for why I don't think we need to)
> Would need to clearly reflect what it applies to and I'm not sure resolution
> is even an unambiguous name given sensor resolution is often described as 8bit
> 10bit etc.  E.g. this selection table from Maxim for ADCs.
> https://www.maximintegrated.com/en/products/parametric/search.html?fam=prec_adc=master=Precision%20ADCs%20(%20%205Msps)=270
> Of course sometimes it's also used for what you want here.
>
> Hohum.  So we might be still be able to do this with standard ABI but we
> are going to need to do some maths in the driver.
> So if we were to express it via
>
> in_accel_raw_avail for example we could use the [low step high] form.
>
> low and high are straight forward as those are expressed directly from
> axis_min_range and axis_max_range which I think are in the same units
> as the _raw channel itself.
>
> For resolution, we have it expressed as [res] x 10^res_exponent
> and if we just put that in as the 'step' above it would have the wrong
> exponent (as we'd expect to still have to apply your 0.1 from above
> example).
>
> Hence we express it as [res] x 10^(res_exponent - exponent)
>
> I'm going to slightly modify your example above because the two exponents
> are the same so it's hard to tell if I have them right way around.
> Hence let res = 0.00293 = 293 x 10^(-5)  (I just dropped the trailing 2)
>
> scale = 10^(-6) exponent = -6
>
> So step = 2392 x 10^(-5 + 6) = 2390
> giving us
>
> [min 2390 max] for _raw_available
>
> Hence when userspace comes along and wants this in relevant base units (here
> m/sec^2) it applies the x10^(-6) mutliplier from _scale we get out expected 
> value
> of 0.00239 m/sec^2
>
> That should work for any case we see but the maths done in the driver will 
> have
> to cope with potential negative exponents for step.
>
> One catch will be the 64 bit potential values for min and max :(
>
> >
> > static struct attribute *scmi_iio_attributes[] = {
> >_dev_attr_sensor_resolution.dev_attr.attr,
> >   

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jonathan Cameron]

On Mon, 11 Jan 2021 13:17:51 -0800
Jyoti Bhayana  wrote:

> Hi Jonathan,
> 
> I know it is a bit confusing. Let me try to explain it with some
> examples to hopefully clarify some things here.
> SCMI Platform talks to the native/actual sensor, gets the raw values
> from the native sensor and applies the scale and then sends those
> values to the SCMI agent and the SCMI IIO driver.
> Since the sensor readings which SCMI IIO driver gets are integer, to
> convert them to float , we need to apply scale to these sensor values
> which is the unit_exponent(power-of-10 multiplier in two’s-complement
> format) specified in the SCMI specification
> 
> Native Sensor -> SCMI platform->SCMI Agent->SCMI IIO Driver
> 
> So if Native Sensor gets the sensor value
> 32767 and the scale the SCMI Platform is using is 0.002392.
> SCMI platform does the calculation of 32767 * 0.002392 = 78.378664
> and send the sensor value as 78378664 and the scale as .01 to the
> SCMI agent and SCMI IIO driver
> 
> so for SCMI IIO driver the sensor reading = 78378664 and scale = .01
> and  the sensor value is sensor_reading * scale = 78378664 *  .01
> =  78.378664
> and the resolution which the SCMI Platform sends to the SCMI agent is 
> 0.002392.
> In the SCMI IIO driver, scale which is .01 is applied to the min
> range/max range and the actual sensor values.
> sensor resolution which is  0.002392 is just passed to the userspace
> layer so that they know the Native sensor resolution/scale
> being applied by the SCMI platform.

That was pretty much where I'd gotten to.  
Whilst the reasoning might be different it is equivalent to a sensor
providing info on expected noise by giving a 'valid resolution'.
In that case as well you have a sensor providing a number that looks to have
more precision than it actually does.

Anyhow, that similarity doesn't really matter here.

I'll also add that a design that applies scale in two places is inherently
less than ideal.   A cleaner design would have maintained the separation
between scale and raw value all the way up the stack.  That would result
in 0 loss of information and also be a cleaner interface.
Ah well, we live with what we have :)

> 
> Regarding your comments in the previous email, when you mentioned
> "what we actually
> need is non standard ABI for resolution"? Does that mean that it is ok
> to have sensor resolution
> as the IIO attribute shown below?
> 
> static IIO_DEVICE_ATTR(sensor_resolution, 0444, 
> scmi_iio_get_sensor_resolution,
>  NULL, 0);

We could do something new (see later for why I don't think we need to)
Would need to clearly reflect what it applies to and I'm not sure resolution
is even an unambiguous name given sensor resolution is often described as 8bit
10bit etc.  E.g. this selection table from Maxim for ADCs.
https://www.maximintegrated.com/en/products/parametric/search.html?fam=prec_adc=master=Precision%20ADCs%20(%20%205Msps)=270
Of course sometimes it's also used for what you want here.

Hohum.  So we might be still be able to do this with standard ABI but we
are going to need to do some maths in the driver.
So if we were to express it via 

in_accel_raw_avail for example we could use the [low step high] form.

low and high are straight forward as those are expressed directly from
axis_min_range and axis_max_range which I think are in the same units
as the _raw channel itself.

For resolution, we have it expressed as [res] x 10^res_exponent
and if we just put that in as the 'step' above it would have the wrong
exponent (as we'd expect to still have to apply your 0.1 from above
example).  

Hence we express it as [res] x 10^(res_exponent - exponent)

I'm going to slightly modify your example above because the two exponents
are the same so it's hard to tell if I have them right way around.
Hence let res = 0.00293 = 293 x 10^(-5)  (I just dropped the trailing 2)

scale = 10^(-6) exponent = -6

So step = 2392 x 10^(-5 + 6) = 2390
giving us

[min 2390 max] for _raw_available

Hence when userspace comes along and wants this in relevant base units (here
m/sec^2) it applies the x10^(-6) mutliplier from _scale we get out expected 
value
of 0.00239 m/sec^2

That should work for any case we see but the maths done in the driver will have
to cope with potential negative exponents for step.

One catch will be the 64 bit potential values for min and max :(

> 
> static struct attribute *scmi_iio_attributes[] = {
>_dev_attr_sensor_resolution.dev_attr.attr,
>NULL,
> };
> 
> and for the min/max range, I can use the read_avail callback?

I would have said yes normally but if we are going to cope with
a potential floating point value for step as touched on above we
may have to do it by hand in the driver.  Not ideal but may
be only option :(

> 
> Also, for the min/max range, there were two options discussed in the
> email thread:
> option 1)  Add new IIO val Type IIO_VAL_INT_H32_L32, and modify the
> iio_format_value to format 

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jyoti Bhayana]

Hi Jonathan,

I know it is a bit confusing. Let me try to explain it with some
examples to hopefully clarify some things here.
SCMI Platform talks to the native/actual sensor, gets the raw values
from the native sensor and applies the scale and then sends those
values to the SCMI agent and the SCMI IIO driver.
Since the sensor readings which SCMI IIO driver gets are integer, to
convert them to float , we need to apply scale to these sensor values
which is the unit_exponent(power-of-10 multiplier in two’s-complement
format) specified in the SCMI specification

Native Sensor -> SCMI platform->SCMI Agent->SCMI IIO Driver

So if Native Sensor gets the sensor value
32767 and the scale the SCMI Platform is using is 0.002392.
SCMI platform does the calculation of 32767 * 0.002392 = 78.378664
and send the sensor value as 78378664 and the scale as .01 to the
SCMI agent and SCMI IIO driver

so for SCMI IIO driver the sensor reading = 78378664 and scale = .01
and  the sensor value is sensor_reading * scale = 78378664 *  .01
=  78.378664
and the resolution which the SCMI Platform sends to the SCMI agent is 0.002392.
In the SCMI IIO driver, scale which is .01 is applied to the min
range/max range and the actual sensor values.
sensor resolution which is  0.002392 is just passed to the userspace
layer so that they know the Native sensor resolution/scale
being applied by the SCMI platform.

Regarding your comments in the previous email, when you mentioned
"what we actually
need is non standard ABI for resolution"? Does that mean that it is ok
to have sensor resolution
as the IIO attribute shown below?

static IIO_DEVICE_ATTR(sensor_resolution, 0444, scmi_iio_get_sensor_resolution,
 NULL, 0);

static struct attribute *scmi_iio_attributes[] = {
   _dev_attr_sensor_resolution.dev_attr.attr,
   NULL,
};

and for the min/max range, I can use the read_avail callback?

Also, for the min/max range, there were two options discussed in the
email thread:
option 1)  Add new IIO val Type IIO_VAL_INT_H32_L32, and modify the
iio_format_value to format the 64 bit int properly for the userspace
option 2) Ignore the H32 bits and use the existing IIO_VAL_INT as just
L32 bits should be sufficient for current sensor values.

Let me know which option you prefer for min/max range. and also please
confirm if it is ok to have an IIO attribute for resolution like
mentioned above.


Thanks,
Jyoti

Thank you so much

Jyoti



On Mon, Jan 11, 2021 at 4:34 AM Jonathan Cameron
 wrote:
>
> On Sun, 10 Jan 2021 22:44:44 -0800
> Jyoti Bhayana  wrote:
>
> > Hi Jonathan,
> >
> > In section 4.7.2.5.1 of the specification, the following exponent is
> > the scale value
> >
> > uint32 axis_attributes_high
> > Bits[15:11] Exponent: The power-of-10 multiplier in two’s-complement
> > format that is applied to the sensor unit
> > specified by the SensorType field.
> >
> > and the resolution is
> >
> > uint32 axis_resolution
> > Bits[31:27] Exponent: The power-of-10 multiplier in two’s-complement format
> > that is applied to the Res field. Bits[26:0] Res: The resolution of
> > the sensor axis.
> >
> > From code in scmi_protocol.h
> > /**
> >  * scmi_sensor_axis_info  - describes one sensor axes
> >  * @id: The axes ID.
> >  * @type: Axes type. Chosen amongst one of @enum scmi_sensor_class.
> >  * @scale: Power-of-10 multiplier applied to the axis unit.
> >  * @name: NULL-terminated string representing axes name as advertised by
> >  *  SCMI platform.
> >  * @extended_attrs: Flag to indicate the presence of additional extended
> >  *attributes for this axes.
> >  * @resolution: Extended attribute representing the resolution of the axes.
> >  * Set to 0 if not reported by this axes.
> >  * @exponent: Extended attribute representing the power-of-10 multiplier 
> > that
> >  *  is applied to the resolution field. Set to 0 if not reported by
> >  *  this axes.
> >  * @attrs: Extended attributes representing minimum and maximum values
> >  *   measurable by this axes. Set to 0 if not reported by this sensor.
> >  */
> >
> > struct scmi_sensor_axis_info {
> > unsigned int id;
> > unsigned int type;
> > int scale; //This is the scale used for min/max range
> > char name[SCMI_MAX_STR_SIZE];
> > bool extended_attrs;
> > unsigned int resolution;
> > int exponent; // This is the scale used in resolution
> > struct scmi_range_attrs attrs;
> > };
> >
> > The scale above  is the Power-of-10 multiplier which is applied to the min 
> > range
> > and the max range value
> > but the resolution is equal to resolution and multiplied by
> > Power-of-10 multiplier
> > of exponent in the above struct.
> > So as can be seen above the value of the power of 10 multiplier used
> > for min/max range
> > can be different than the value of the power of 10 multiplier used for
> > the resolution.
> > Hence, if I have to use IIO_AVAIL_RANGE to specify min/max range and as well
> > as resolution, then I have to use the float format with the 

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jonathan Cameron]

On Sun, 10 Jan 2021 22:44:44 -0800
Jyoti Bhayana  wrote:

> Hi Jonathan,
> 
> In section 4.7.2.5.1 of the specification, the following exponent is
> the scale value
> 
> uint32 axis_attributes_high
> Bits[15:11] Exponent: The power-of-10 multiplier in two’s-complement
> format that is applied to the sensor unit
> specified by the SensorType field.
> 
> and the resolution is
> 
> uint32 axis_resolution
> Bits[31:27] Exponent: The power-of-10 multiplier in two’s-complement format
> that is applied to the Res field. Bits[26:0] Res: The resolution of
> the sensor axis.
> 
> From code in scmi_protocol.h
> /**
>  * scmi_sensor_axis_info  - describes one sensor axes
>  * @id: The axes ID.
>  * @type: Axes type. Chosen amongst one of @enum scmi_sensor_class.
>  * @scale: Power-of-10 multiplier applied to the axis unit.
>  * @name: NULL-terminated string representing axes name as advertised by
>  *  SCMI platform.
>  * @extended_attrs: Flag to indicate the presence of additional extended
>  *attributes for this axes.
>  * @resolution: Extended attribute representing the resolution of the axes.
>  * Set to 0 if not reported by this axes.
>  * @exponent: Extended attribute representing the power-of-10 multiplier that
>  *  is applied to the resolution field. Set to 0 if not reported by
>  *  this axes.
>  * @attrs: Extended attributes representing minimum and maximum values
>  *   measurable by this axes. Set to 0 if not reported by this sensor.
>  */
> 
> struct scmi_sensor_axis_info {
> unsigned int id;
> unsigned int type;
> int scale; //This is the scale used for min/max range
> char name[SCMI_MAX_STR_SIZE];
> bool extended_attrs;
> unsigned int resolution;
> int exponent; // This is the scale used in resolution
> struct scmi_range_attrs attrs;
> };
> 
> The scale above  is the Power-of-10 multiplier which is applied to the min 
> range
> and the max range value
> but the resolution is equal to resolution and multiplied by
> Power-of-10 multiplier
> of exponent in the above struct.
> So as can be seen above the value of the power of 10 multiplier used
> for min/max range
> can be different than the value of the power of 10 multiplier used for
> the resolution.
> Hence, if I have to use IIO_AVAIL_RANGE to specify min/max range and as well
> as resolution, then I have to use the float format with the scale applied.
> 
> If there is another way which you know of and prefer, please let me know.
I'll confess I've gotten a bit lost here.

So I think where we are is how to describe the range of the sensor and why we 
can't
use in_accel_x_raw_available to provide the 

Understood that the resolution can have different scaling.  That is presumably
to allow for the case where a device is reporting values at a finer scale than
it's real resolution.  Resolution might take into account expected noise for
example.  So it should be decoupled from the scaling of both the actual 
measurements
and the axis high / low limits.

However, I'd read that as saying the axis high / low limits and the actual 
sensor
readings should be scaled by the exponent in axis_attributes_high.
So I think we are fine for the range, but my earlier assumption that resolution
was equivalent to scale in IIO (real world value for 1LSB) may be completely 
wrong
as resolution may be unconnected to how you convert to a real world value?

If nothing else I'd like to suggest the spec needs to be tightened a bit here
to say exactly how we convert a value coming in to real world units (maybe
I'm just missing it).

Anyhow, I suspect we've been looking at this the wrong way and what we actually
need is non standard ABI for resolution.

Jonathan




> 
> Thanks,
> Jyoti
> 
> 
> 
> 
> Thanks,
> Jyoti
> 
> On Sat, Jan 9, 2021 at 11:01 AM Jonathan Cameron  wrote:
> >
> > On Wed,  6 Jan 2021 21:23:53 +
> > Jyoti Bhayana  wrote:
> >  
> > > Hi Jonathan,
> > >
> > > Instead of adding IIO_VAL_INT_H32_L32, I am thinking of adding 
> > > IIO_VAL_FRACTIONAL_LONG
> > > or IIO_VAL_FRACTIONAL_64 as the scale/exponent used for min/max range can 
> > > be different
> > > than the one used in resolution according to specification.  
> >
> > That's somewhat 'odd'.  Given min/max are inherently values the sensor is 
> > supposed to
> > be able to return why give them different resolutions?  Can you point me at 
> > a specific
> > section of the spec?  The axis_min_range_low etc fields don't seem to have 
> > units specified
> > but I assumed they were in sensor units and so same scale factors?
> >  
> > >
> > > I am planning to use read_avail for IIO_CHAN_INFO_PROCESSED using 
> > > IIO_AVAIL_RANGE
> > > and this new IIO_VAL_FRACTIONAL_64 for min range,max range and resolution.
> > > Instead of two values used in IIO_VAL_FRACTIONAL, IIO_VAL_FRACTIONAL_64 
> > > will use 4 values
> > > val_high,val_low,and val2_high and val2_low.  
> >
> > I'm not keen on the changing that internal kernel interface unless we 
> > absolutely
> > have to.  read_avail() is called from 

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jyoti Bhayana]

Hi Jonathan,

In section 4.7.2.5.1 of the specification, the following exponent is
the scale value

uint32 axis_attributes_high
Bits[15:11] Exponent: The power-of-10 multiplier in two’s-complement
format that is applied to the sensor unit
specified by the SensorType field.

and the resolution is

uint32 axis_resolution
Bits[31:27] Exponent: The power-of-10 multiplier in two’s-complement format
that is applied to the Res field. Bits[26:0] Res: The resolution of
the sensor axis.

>From code in scmi_protocol.h
/**
 * scmi_sensor_axis_info  - describes one sensor axes
 * @id: The axes ID.
 * @type: Axes type. Chosen amongst one of @enum scmi_sensor_class.
 * @scale: Power-of-10 multiplier applied to the axis unit.
 * @name: NULL-terminated string representing axes name as advertised by
 *  SCMI platform.
 * @extended_attrs: Flag to indicate the presence of additional extended
 *attributes for this axes.
 * @resolution: Extended attribute representing the resolution of the axes.
 * Set to 0 if not reported by this axes.
 * @exponent: Extended attribute representing the power-of-10 multiplier that
 *  is applied to the resolution field. Set to 0 if not reported by
 *  this axes.
 * @attrs: Extended attributes representing minimum and maximum values
 *   measurable by this axes. Set to 0 if not reported by this sensor.
 */

struct scmi_sensor_axis_info {
unsigned int id;
unsigned int type;
int scale; //This is the scale used for min/max range
char name[SCMI_MAX_STR_SIZE];
bool extended_attrs;
unsigned int resolution;
int exponent; // This is the scale used in resolution
struct scmi_range_attrs attrs;
};

The scale above  is the Power-of-10 multiplier which is applied to the min range
and the max range value
but the resolution is equal to resolution and multiplied by
Power-of-10 multiplier
of exponent in the above struct.
So as can be seen above the value of the power of 10 multiplier used
for min/max range
can be different than the value of the power of 10 multiplier used for
the resolution.
Hence, if I have to use IIO_AVAIL_RANGE to specify min/max range and as well
as resolution, then I have to use the float format with the scale applied.

If there is another way which you know of and prefer, please let me know.

Thanks,
Jyoti




Thanks,
Jyoti

On Sat, Jan 9, 2021 at 11:01 AM Jonathan Cameron  wrote:
>
> On Wed,  6 Jan 2021 21:23:53 +
> Jyoti Bhayana  wrote:
>
> > Hi Jonathan,
> >
> > Instead of adding IIO_VAL_INT_H32_L32, I am thinking of adding 
> > IIO_VAL_FRACTIONAL_LONG
> > or IIO_VAL_FRACTIONAL_64 as the scale/exponent used for min/max range can 
> > be different
> > than the one used in resolution according to specification.
>
> That's somewhat 'odd'.  Given min/max are inherently values the sensor is 
> supposed to
> be able to return why give them different resolutions?  Can you point me at a 
> specific
> section of the spec?  The axis_min_range_low etc fields don't seem to have 
> units specified
> but I assumed they were in sensor units and so same scale factors?
>
> >
> > I am planning to use read_avail for IIO_CHAN_INFO_PROCESSED using 
> > IIO_AVAIL_RANGE
> > and this new IIO_VAL_FRACTIONAL_64 for min range,max range and resolution.
> > Instead of two values used in IIO_VAL_FRACTIONAL, IIO_VAL_FRACTIONAL_64 
> > will use 4 values
> > val_high,val_low,and val2_high and val2_low.
>
> I'm not keen on the changing that internal kernel interface unless we 
> absolutely
> have to.  read_avail() is called from consumer drivers and they won't know 
> anything
> about this new variant.
>
> >
> > Let me know if that is an acceptable solution.
>
> Hmm. It isn't a standard use of the ABI given the value in the buffer is (I 
> assume)
> raw (needs scale applied).  However, it isn't excluded by the ABI docs.  
> Whether
> a standard userspace is going to expect it is not clear to me.
>
> I don't want to end up in a position where we end up with available being 
> generally
> added for processed when what most people care about is what the value range 
> they
> might get from a polled read is (rather than via a buffer).
>
> So I'm not that keen on this solution but if we can find a way to avoid it.
>
> Jonathan
>
>
> >
> >
> > Thanks,
> > Jyoti
> >
>

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jonathan Cameron]

On Wed,  6 Jan 2021 21:23:53 +
Jyoti Bhayana  wrote:

> Hi Jonathan,
> 
> Instead of adding IIO_VAL_INT_H32_L32, I am thinking of adding 
> IIO_VAL_FRACTIONAL_LONG
> or IIO_VAL_FRACTIONAL_64 as the scale/exponent used for min/max range can be 
> different
> than the one used in resolution according to specification. 

That's somewhat 'odd'.  Given min/max are inherently values the sensor is 
supposed to
be able to return why give them different resolutions?  Can you point me at a 
specific
section of the spec?  The axis_min_range_low etc fields don't seem to have 
units specified
but I assumed they were in sensor units and so same scale factors?

> 
> I am planning to use read_avail for IIO_CHAN_INFO_PROCESSED using 
> IIO_AVAIL_RANGE 
> and this new IIO_VAL_FRACTIONAL_64 for min range,max range and resolution.
> Instead of two values used in IIO_VAL_FRACTIONAL, IIO_VAL_FRACTIONAL_64 will 
> use 4 values
> val_high,val_low,and val2_high and val2_low.

I'm not keen on the changing that internal kernel interface unless we absolutely
have to.  read_avail() is called from consumer drivers and they won't know 
anything
about this new variant.

> 
> Let me know if that is an acceptable solution.

Hmm. It isn't a standard use of the ABI given the value in the buffer is (I 
assume)
raw (needs scale applied).  However, it isn't excluded by the ABI docs.  Whether
a standard userspace is going to expect it is not clear to me.

I don't want to end up in a position where we end up with available being 
generally
added for processed when what most people care about is what the value range 
they
might get from a polled read is (rather than via a buffer).

So I'm not that keen on this solution but if we can find a way to avoid it.

Jonathan


> 
> 
> Thanks,
> Jyoti
> 

Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jyoti Bhayana]

Hi Jonathan,

Instead of adding IIO_VAL_INT_H32_L32, I am thinking of adding 
IIO_VAL_FRACTIONAL_LONG
or IIO_VAL_FRACTIONAL_64 as the scale/exponent used for min/max range can be 
different
than the one used in resolution according to specification. 

I am planning to use read_avail for IIO_CHAN_INFO_PROCESSED using 
IIO_AVAIL_RANGE 
and this new IIO_VAL_FRACTIONAL_64 for min range,max range and resolution.
Instead of two values used in IIO_VAL_FRACTIONAL, IIO_VAL_FRACTIONAL_64 will 
use 4 values
val_high,val_low,and val2_high and val2_low.

Let me know if that is an acceptable solution.


Thanks,
Jyoti

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Cristian Marussi]

On Wed, Jan 06, 2021 at 02:36:45PM +, Jonathan Cameron wrote:
> On Wed, 6 Jan 2021 11:26:59 +
> Cristian Marussi  wrote:
> 
> > Hi
> > 
> > On Wed, Jan 06, 2021 at 10:29:17AM +, Jonathan Cameron wrote:
> > > On Tue, 5 Jan 2021 23:09:20 +
> > > Jyoti Bhayana  wrote:
> > >   
> > > > Hi Jonathan,
> > > >   
> > > > > So, sensor_max_range can effectively be exposed as a combination of
> > > > > scale and the *_raw_avail for a raw read (via the read_avail callback 
> > > > > in IIO).
> > > > > We'll ignore the fact the interface assumes a single value (so I 
> > > > > assume symmetric?)
> > > > 
> > > > Based on the SCMI specification the sensor min range and max range are 
> > > > 64 bits signed number.
> > > > 
> > > > looks like IIO_AVAIL_RANGE can only take the following
> > > > types of data which all looks like 32 bit. IIO_VAL_FRACTIONAL
> > > > also takes two int type numbers.
> > > > How can I send 64 bit sensor range using this and read_avail callback?
> > > > 
> > > > #define IIO_VAL_INT 1
> > > > #define IIO_VAL_INT_PLUS_MICRO 2
> > > > #define IIO_VAL_INT_PLUS_NANO 3
> > > > #define IIO_VAL_INT_PLUS_MICRO_DB 4
> > > > #define IIO_VAL_INT_MULTIPLE 5
> > > > #define IIO_VAL_FRACTIONAL 10
> > > > #define IIO_VAL_FRACTIONAL_LOG2 11
> > > > #define IIO_VAL_CHAR 12  
> > > 
> > > Hmm It is a bit unfortunate that SCMI decided to pretend that real sensor 
> > > resolutions were
> > > greater than 32 bits. I doubt they will ever actually be any (as such 
> > > accurate measurements
> > > are completely pointless) and they aren't anywhere near that today.  Only 
> > > way it might end
> > > up looking a bit like that would be result of a highly non linear sensor 
> > > being shoved through
> > > an interface that pretends it isn't (goody).
> > >   
> > 
> > We shared this info internally to involve our architects about this.
> > 
> > > Having said that, specifications are what they are and we have to cope 
> > > with that.
> > > 
> > > There is no real problem with defining a new value type except for the 
> > > fact that any
> > > legacy userspace won't necessarily expect to see values that large. Given 
> > > we need the full
> > > 64 bits it would have to be something like
> > > IIO_VAL_INT_H32_L32 with the 64 bit values split up appropriately and put 
> > > back together
> > > at time of formatting.   Not particularly pretty but I'm not keep to put 
> > > that much effort
> > > in to support something like this for one driver (so not interesting in 
> > > changing that
> > > the read_raw_* interfaces)
> > >   
> > 
> > Regarding the current spec and this IIODEV limit to 32bit, I was thinking 
> > about
> > the following horrid thing (:D) as a solution: given that as of now no 
> > sensor
> > exist in real life reporting bigger than 32bits values, instead of adding 
> > new
> > defines in IIODEV framework to support 64bit that no userspace is expecting 
> > and
> > no sensor will really emit ever in the foreseable future, couldn't this SCMI
> > IIODEV driver simply:
> > 
> > - truncate silently straight away 64bit vals into 32bit when detects
> >   that he upper MSB 32bit are unused (zeros or sign-extension) and in
> >   fact the values fits into 32bits
> > 
> > - WARN and do not truncate if the upper MSB 32bit are in fact valid because
> >   such a 64bit capable sensor was indeed used finally (at that point in time
> >   IIODEV driver and framework will need a 64bit update)
> > 
> > Or I am missing something ?
> > 
> > Feel free to insult me about this hack ... :D 
> 
> I had a similar thought :)  But every time we do something like this someone
> does something crazy like right shifting the value by 24 bits or similar.
> Warning should make it obvious if we need to paper over this though.

Not sure to have understood where this right shift could be done...on
sysfs output values you mean ?

It is pretty similar (only conceptually) to what happened with SCMIv3.0
Voltage and SCMI regulator: Voltage protocol supports negative voltages
representation to be generic enough to handle any kind of regulators
while regulator framework does NOT support negatives as of now (being mostly
used in a digital context AFAICU), so the SCMI regulator driver refuses to
handle any SCMI exposed voltage domain which declares itself as supporting
negative voltages. (and emit a pr_warn)

I was thinking around the same lines here, given that each SCMI sensor/axis
is exposed and described also by a descriptor containing scmi_range_attrs
(a min/max_range 64bit values), the SCMI IIODEV driver could simply skip them
at initialization time when it see an unsupported range and just do not expose
such an iiodev, but warn: this way nothing potentially representing something
greater than 32bit would even appear in sysfs.
(But I'm far from having a decent knowledge of IIO so I could be missing
something ovious here).

Thanks

Cristian

> 
> But I'm not sure it matters in reality as this is mostly hidden away inside
> 

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jonathan Cameron]

On Wed, 6 Jan 2021 11:26:59 +
Cristian Marussi  wrote:

> Hi
> 
> On Wed, Jan 06, 2021 at 10:29:17AM +, Jonathan Cameron wrote:
> > On Tue, 5 Jan 2021 23:09:20 +
> > Jyoti Bhayana  wrote:
> >   
> > > Hi Jonathan,
> > >   
> > > > So, sensor_max_range can effectively be exposed as a combination of
> > > > scale and the *_raw_avail for a raw read (via the read_avail callback 
> > > > in IIO).
> > > > We'll ignore the fact the interface assumes a single value (so I assume 
> > > > symmetric?)
> > > 
> > > Based on the SCMI specification the sensor min range and max range are 64 
> > > bits signed number.
> > > 
> > > looks like IIO_AVAIL_RANGE can only take the following
> > > types of data which all looks like 32 bit. IIO_VAL_FRACTIONAL
> > > also takes two int type numbers.
> > > How can I send 64 bit sensor range using this and read_avail callback?
> > > 
> > > #define IIO_VAL_INT 1
> > > #define IIO_VAL_INT_PLUS_MICRO 2
> > > #define IIO_VAL_INT_PLUS_NANO 3
> > > #define IIO_VAL_INT_PLUS_MICRO_DB 4
> > > #define IIO_VAL_INT_MULTIPLE 5
> > > #define IIO_VAL_FRACTIONAL 10
> > > #define IIO_VAL_FRACTIONAL_LOG2 11
> > > #define IIO_VAL_CHAR 12  
> > 
> > Hmm It is a bit unfortunate that SCMI decided to pretend that real sensor 
> > resolutions were
> > greater than 32 bits. I doubt they will ever actually be any (as such 
> > accurate measurements
> > are completely pointless) and they aren't anywhere near that today.  Only 
> > way it might end
> > up looking a bit like that would be result of a highly non linear sensor 
> > being shoved through
> > an interface that pretends it isn't (goody).
> >   
> 
> We shared this info internally to involve our architects about this.
> 
> > Having said that, specifications are what they are and we have to cope with 
> > that.
> > 
> > There is no real problem with defining a new value type except for the fact 
> > that any
> > legacy userspace won't necessarily expect to see values that large. Given 
> > we need the full
> > 64 bits it would have to be something like
> > IIO_VAL_INT_H32_L32 with the 64 bit values split up appropriately and put 
> > back together
> > at time of formatting.   Not particularly pretty but I'm not keep to put 
> > that much effort
> > in to support something like this for one driver (so not interesting in 
> > changing that
> > the read_raw_* interfaces)
> >   
> 
> Regarding the current spec and this IIODEV limit to 32bit, I was thinking 
> about
> the following horrid thing (:D) as a solution: given that as of now no sensor
> exist in real life reporting bigger than 32bits values, instead of adding new
> defines in IIODEV framework to support 64bit that no userspace is expecting 
> and
> no sensor will really emit ever in the foreseable future, couldn't this SCMI
> IIODEV driver simply:
> 
> - truncate silently straight away 64bit vals into 32bit when detects
>   that he upper MSB 32bit are unused (zeros or sign-extension) and in
>   fact the values fits into 32bits
> 
> - WARN and do not truncate if the upper MSB 32bit are in fact valid because
>   such a 64bit capable sensor was indeed used finally (at that point in time
>   IIODEV driver and framework will need a 64bit update)
> 
> Or I am missing something ?
> 
> Feel free to insult me about this hack ... :D 

I had a similar thought :)  But every time we do something like this someone
does something crazy like right shifting the value by 24 bits or similar.
Warning should make it obvious if we need to paper over this though.

But I'm not sure it matters in reality as this is mostly hidden away inside
the kernel.   The exposure of these values is limited to:
1) In kernel users - probably aren't any current ones for these sensors.
2) Passing to the pretty print functions that produce sysfs values.
   The risk here is existing userspace may fail to parse a number that needs
   more than 32 bits as it's never seen one before.
   However, if the numbers happen to be smaller it will be fine.  So we are 
storing
   up potential esoteric bugs for a long time in the future.  Hopefully any such
   userspace will report an error though!

If we do support this, I would ask that we also add a channel to the
dummy driver to allow us to easily exercise relevant code paths without having
to emulate everything needed to fake devices behind SCMI (docs on how to do that
would be good as well if there are any (assuming there is public code that does
this by now!) :)

Jonathan

> 
> Thanks
> 
> Cristian
> 
> > Jonathan
> >  
> >   
> > > 
> > > 
> > > 
> > > Thanks,
> > > Jyoti
> > >   
> >   

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Cristian Marussi]

Hi

On Wed, Jan 06, 2021 at 10:29:17AM +, Jonathan Cameron wrote:
> On Tue, 5 Jan 2021 23:09:20 +
> Jyoti Bhayana  wrote:
> 
> > Hi Jonathan,
> > 
> > > So, sensor_max_range can effectively be exposed as a combination of
> > > scale and the *_raw_avail for a raw read (via the read_avail callback in 
> > > IIO).
> > > We'll ignore the fact the interface assumes a single value (so I assume 
> > > symmetric?)  
> > 
> > Based on the SCMI specification the sensor min range and max range are 64 
> > bits signed number.
> > 
> > looks like IIO_AVAIL_RANGE can only take the following
> > types of data which all looks like 32 bit. IIO_VAL_FRACTIONAL
> > also takes two int type numbers.
> > How can I send 64 bit sensor range using this and read_avail callback?
> > 
> > #define IIO_VAL_INT 1
> > #define IIO_VAL_INT_PLUS_MICRO 2
> > #define IIO_VAL_INT_PLUS_NANO 3
> > #define IIO_VAL_INT_PLUS_MICRO_DB 4
> > #define IIO_VAL_INT_MULTIPLE 5
> > #define IIO_VAL_FRACTIONAL 10
> > #define IIO_VAL_FRACTIONAL_LOG2 11
> > #define IIO_VAL_CHAR 12
> 
> Hmm It is a bit unfortunate that SCMI decided to pretend that real sensor 
> resolutions were
> greater than 32 bits. I doubt they will ever actually be any (as such 
> accurate measurements
> are completely pointless) and they aren't anywhere near that today.  Only way 
> it might end
> up looking a bit like that would be result of a highly non linear sensor 
> being shoved through
> an interface that pretends it isn't (goody).
> 

We shared this info internally to involve our architects about this.

> Having said that, specifications are what they are and we have to cope with 
> that.
> 
> There is no real problem with defining a new value type except for the fact 
> that any
> legacy userspace won't necessarily expect to see values that large. Given we 
> need the full
> 64 bits it would have to be something like
> IIO_VAL_INT_H32_L32 with the 64 bit values split up appropriately and put 
> back together
> at time of formatting.   Not particularly pretty but I'm not keep to put that 
> much effort
> in to support something like this for one driver (so not interesting in 
> changing that
> the read_raw_* interfaces)
> 

Regarding the current spec and this IIODEV limit to 32bit, I was thinking about
the following horrid thing (:D) as a solution: given that as of now no sensor
exist in real life reporting bigger than 32bits values, instead of adding new
defines in IIODEV framework to support 64bit that no userspace is expecting and
no sensor will really emit ever in the foreseable future, couldn't this SCMI
IIODEV driver simply:

- truncate silently straight away 64bit vals into 32bit when detects
  that he upper MSB 32bit are unused (zeros or sign-extension) and in
  fact the values fits into 32bits

- WARN and do not truncate if the upper MSB 32bit are in fact valid because
  such a 64bit capable sensor was indeed used finally (at that point in time
  IIODEV driver and framework will need a 64bit update)

Or I am missing something ?

Feel free to insult me about this hack ... :D 

Thanks

Cristian

> Jonathan
>  
> 
> > 
> > 
> > 
> > Thanks,
> > Jyoti
> > 
> 

Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jonathan Cameron]

On Tue, 5 Jan 2021 23:09:20 +
Jyoti Bhayana  wrote:

> Hi Jonathan,
> 
> > So, sensor_max_range can effectively be exposed as a combination of
> > scale and the *_raw_avail for a raw read (via the read_avail callback in 
> > IIO).
> > We'll ignore the fact the interface assumes a single value (so I assume 
> > symmetric?)  
> 
> Based on the SCMI specification the sensor min range and max range are 64 
> bits signed number.
> 
> looks like IIO_AVAIL_RANGE can only take the following
> types of data which all looks like 32 bit. IIO_VAL_FRACTIONAL
> also takes two int type numbers.
> How can I send 64 bit sensor range using this and read_avail callback?
> 
> #define IIO_VAL_INT 1
> #define IIO_VAL_INT_PLUS_MICRO 2
> #define IIO_VAL_INT_PLUS_NANO 3
> #define IIO_VAL_INT_PLUS_MICRO_DB 4
> #define IIO_VAL_INT_MULTIPLE 5
> #define IIO_VAL_FRACTIONAL 10
> #define IIO_VAL_FRACTIONAL_LOG2 11
> #define IIO_VAL_CHAR 12

Hmm It is a bit unfortunate that SCMI decided to pretend that real sensor 
resolutions were
greater than 32 bits. I doubt they will ever actually be any (as such accurate 
measurements
are completely pointless) and they aren't anywhere near that today.  Only way 
it might end
up looking a bit like that would be result of a highly non linear sensor being 
shoved through
an interface that pretends it isn't (goody).

Having said that, specifications are what they are and we have to cope with 
that.

There is no real problem with defining a new value type except for the fact 
that any
legacy userspace won't necessarily expect to see values that large. Given we 
need the full
64 bits it would have to be something like
IIO_VAL_INT_H32_L32 with the 64 bit values split up appropriately and put back 
together
at time of formatting.   Not particularly pretty but I'm not keep to put that 
much effort
in to support something like this for one driver (so not interesting in 
changing that
the read_raw_* interfaces)

Jonathan
 

> 
> 
> 
> Thanks,
> Jyoti
> 

Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

[Jyoti Bhayana]

Hi Jonathan,

> So, sensor_max_range can effectively be exposed as a combination of
> scale and the *_raw_avail for a raw read (via the read_avail callback in IIO).
> We'll ignore the fact the interface assumes a single value (so I assume 
> symmetric?)

Based on the SCMI specification the sensor min range and max range are 64 bits 
signed number.

looks like IIO_AVAIL_RANGE can only take the following
types of data which all looks like 32 bit. IIO_VAL_FRACTIONAL
also takes two int type numbers.
How can I send 64 bit sensor range using this and read_avail callback?

#define IIO_VAL_INT 1
#define IIO_VAL_INT_PLUS_MICRO 2
#define IIO_VAL_INT_PLUS_NANO 3
#define IIO_VAL_INT_PLUS_MICRO_DB 4
#define IIO_VAL_INT_MULTIPLE 5
#define IIO_VAL_FRACTIONAL 10
#define IIO_VAL_FRACTIONAL_LOG2 11
#define IIO_VAL_CHAR 12



Thanks,
Jyoti

[PATCH 5.4 202/453] NFSv4: Fix the alignment of page data in the getdeviceinfo reply

[Greg Kroah-Hartman]

From: Trond Myklebust 

[ Upstream commit 046e5ccb4198b990190e11fb52fd9cfd264402eb ]

We can fit the device_addr4 opaque data padding in the pages.

Fixes: cf500bac8fd4 ("SUNRPC: Introduce rpc_prepare_reply_pages()")
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs4xdr.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
index 677751bc3a334..9a022a4fb9643 100644
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -3012,15 +3012,19 @@ static void nfs4_xdr_enc_getdeviceinfo(struct rpc_rqst 
*req,
struct compound_hdr hdr = {
.minorversion = nfs4_xdr_minorversion(>seq_args),
};
+   uint32_t replen;
 
encode_compound_hdr(xdr, req, );
encode_sequence(xdr, >seq_args, );
+
+   replen = hdr.replen + op_decode_hdr_maxsz;
+
encode_getdeviceinfo(xdr, args, );
 
-   /* set up reply kvec. Subtract notification bitmap max size (2)
-* so that notification bitmap is put in xdr_buf tail */
+   /* set up reply kvec. device_addr4 opaque data is read into the
+* pages */
rpc_prepare_reply_pages(req, args->pdev->pages, args->pdev->pgbase,
-   args->pdev->pglen, hdr.replen - 2);
+   args->pdev->pglen, replen + 2 + 1);
encode_nops();
 }
 
-- 
2.27.0

[PATCH 5.10 269/717] NFSv4: Fix the alignment of page data in the getdeviceinfo reply

[Greg Kroah-Hartman]

From: Trond Myklebust 

[ Upstream commit 046e5ccb4198b990190e11fb52fd9cfd264402eb ]

We can fit the device_addr4 opaque data padding in the pages.

Fixes: cf500bac8fd4 ("SUNRPC: Introduce rpc_prepare_reply_pages()")
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs4xdr.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
index c6dbfcae75171..c16b93df1bc14 100644
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -3009,15 +3009,19 @@ static void nfs4_xdr_enc_getdeviceinfo(struct rpc_rqst 
*req,
struct compound_hdr hdr = {
.minorversion = nfs4_xdr_minorversion(>seq_args),
};
+   uint32_t replen;
 
encode_compound_hdr(xdr, req, );
encode_sequence(xdr, >seq_args, );
+
+   replen = hdr.replen + op_decode_hdr_maxsz;
+
encode_getdeviceinfo(xdr, args, );
 
-   /* set up reply kvec. Subtract notification bitmap max size (2)
-* so that notification bitmap is put in xdr_buf tail */
+   /* set up reply kvec. device_addr4 opaque data is read into the
+* pages */
rpc_prepare_reply_pages(req, args->pdev->pages, args->pdev->pgbase,
-   args->pdev->pglen, hdr.replen - 2);
+   args->pdev->pglen, replen + 2 + 1);
encode_nops();
 }
 
-- 
2.27.0

[PATCH 5.10 333/717] macintosh/adb-iop: Always wait for reply message from IOP

[Greg Kroah-Hartman]

From: Finn Thain 

[ Upstream commit 2c9cfbadfa234b03473f1ef54e6f4772cc07a371 ]

A recent patch incorrectly altered the adb-iop state machine behaviour
and introduced a regression that can appear intermittently as a
malfunctioning ADB input device. This seems to be caused when reply
packets from different ADB commands become mixed up, especially during
the adb bus scan. Fix this by unconditionally entering the awaiting_reply
state after sending an explicit command, even when the ADB command won't
generate a reply from the ADB device.

It turns out that the IOP always generates reply messages, even when the
ADB command does not produce a reply packet (e.g. ADB Listen command).
So it's not really the ADB reply packets that are being mixed up, it's the
IOP messages that enclose them. The bug goes like this:

  1. CPU sends a message to the IOP, expecting no response because this
 message contains an ADB Listen command. The ADB command is now
 considered complete.

  2. CPU sends a second message to the IOP, this time expecting a
 response because this message contains an ADB Talk command. This
 ADB command needs a reply before it can be completed.

  3. adb-iop driver receives an IOP message and assumes that it relates
 to the Talk command. It's actually an empty one (with flags ==
 ADB_IOP_EXPLICIT|ADB_IOP_TIMEOUT) for the previous command. The
 Talk command is now considered complete but it gets the wrong reply
 data.

  4. adb-iop driver gets another IOP response message, which contains
 the actual reply data for the Talk command, but this is dropped
 (the driver is no longer in awaiting_reply state).

Cc: Joshua Thompson 
Fixes: e2954e5f727f ("macintosh/adb-iop: Implement sending -> idle state 
transition")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
Link: 
https://lore.kernel.org/r/0f0a25855391e7eaa53a50f651aea0124e8525dd.1605847196.git.fth...@telegraphics.com.au
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Sasha Levin 
---
 drivers/macintosh/adb-iop.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/macintosh/adb-iop.c b/drivers/macintosh/adb-iop.c
index f3d1a460fbce1..422abd1d48e18 100644
--- a/drivers/macintosh/adb-iop.c
+++ b/drivers/macintosh/adb-iop.c
@@ -78,10 +78,7 @@ static void adb_iop_complete(struct iop_msg *msg)
 
local_irq_save(flags);
 
-   if (current_req->reply_expected)
-   adb_iop_state = awaiting_reply;
-   else
-   adb_iop_done();
+   adb_iop_state = awaiting_reply;
 
local_irq_restore(flags);
 }
@@ -89,8 +86,9 @@ static void adb_iop_complete(struct iop_msg *msg)
 /*
  * Listen for ADB messages from the IOP.
  *
- * This will be called when unsolicited messages (usually replies to TALK
- * commands or autopoll packets) are received.
+ * This will be called when unsolicited IOP messages are received.
+ * These IOP messages can carry ADB autopoll responses and also occur
+ * after explicit ADB commands.
  */
 
 static void adb_iop_listen(struct iop_msg *msg)
@@ -110,8 +108,10 @@ static void adb_iop_listen(struct iop_msg *msg)
if (adb_iop_state == awaiting_reply) {
struct adb_request *req = current_req;
 
-   req->reply_len = amsg->count + 1;
-   memcpy(req->reply, >cmd, req->reply_len);
+   if (req->reply_expected) {
+   req->reply_len = amsg->count + 1;
+       memcpy(req->reply, >cmd, req->reply_len);
+   }
 
req_done = true;
}
-- 
2.27.0

REPLY ME URGENTLY

[Mrs. Elizabeth Edward]

Greeting

Please forgive me for stressing you with my predicaments and I sorry
to approach you through this media it is because it serves the fastest
means of communication. I came across your E-mail from my personal
search and I decided to contact you believing you will be honest to
fulfill my final wish before I die.

I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.

Since my days are numbered, I’ve decided willingly to fulfill my
long-time promise to donate you the sum ($5.000.000.00) million
dollars I inherited from my late husband Mr. Edward Herbart, foreign
bank account over years. I need a very honest person who can assist in
transfer of this money to his or her account and use the funds for
charities work of God while you use 50% for yourself. I want you to
know there are no risk involved, it is 100% hitch free & safe. If you
will be interesting to assist in getting this fund into your account
for charity project to fulfill my promise before I die please let me
know immediately. I will appreciate your utmost confidentiality as I
wait for your reply.

Best Regards

Mrs. Elizabeth Edward

URGENT REPLY IS NEEDED FROM YOU

[CHARLES GOODMAN]

Attn: Beneficiary:

Congratulations!! Your payment has been approved and endorsed, with the
instruction and approvals are given from the Authorities Due to the
incessant scam activities going around the globe, the Authorities has
instructed our Financial Institution to use high Performance in
Banking System to set up a Personal Online Banking Account.

The sum of US$15,500,000.00 was deposited in our bank, The Management
has resolved to open Personal On-line Banking Account for you with our
bank and then give you the on-line access which will enable you to
check and make electronics wire transfer out to any part of the world
of your choice.

Kindly send the below information to enable us to set the account open for you.

Full Name:.. 
Full Address:.
Direct Cellphone Number:..
PASSPORT AND ID CARDS:.
YOUR OCCUPATION.
POSITION. 
DATE OF BIRTH..

Looking forward to your next letter


Regards

Thanks for banking with us,

Mr.Charles Goodman.
A/C Online Payment Officer,
US Capital Bank Branch North Carolina,
United States of America

紧急回复此邮件 / Urgent Reply To This Mail

[John Galvan]

先生/女士，

我可以获取有关一项合法业务交易建议的非常重要的信息，该提议将使我们双方受益，£15,500,000.00 百万磅。 
如果我可以独自完成任务，那么我就不会麻烦与您联系。

最终，我需要一个诚实的外国人在完成这项业务交易中发挥重要作用。

回复此邮件以获取有关此业务交易的更多信息：galvan.joh...@outlook.com

问候，
约翰·加尔文先生
---
Sir/Madam,

I have access to very vital information for a Legit business transaction 
proposal that will benefits both of us with the sum of £15,500,000.00 Million 
Pounds. If it was possible for me to do it alone, I would not have bothered 
contacting you.

Ultimately, I need an honest foreigner to play an important role in the 
completion of this business transaction.

Reply to this mail for more information about this business transaction: 
galvan.joh...@outlook.com

Regards,
Mr. John Galvan

Re: [PATCH RESEND v8 4/4] input: elants: support 0x66 reply opcode for reporting touches

[Dmitry Torokhov]

On Fri, Dec 11, 2020 at 07:53:57AM +0100, Michał Mirosław wrote:
> From: Dmitry Osipenko 
> 
> eKTF3624 touchscreen firmware uses two variants of the reply opcodes for
> reporting touch events: one is 0x63 (used by older firmware) and other is
> 0x66 (used by newer firmware). The 0x66 variant is equal to 0x63 of
> eKTH3500, while 0x63 needs small adjustment of the touch pressure value.
> 
> Nexus 7 tablet device has eKTF3624 touchscreen and it uses 0x66 opcode for
> reporting touch events, let's support it now. Other devices, eg. ASUS TF300T,
> use 0x63.
> 
> Note: CMD_HEADER_REK is used for replying to calibration requests, it has
> the same 0x66 opcode number which eKTF3624 uses for reporting touches.
> The calibration replies are handled separately from the the rest of the
> commands in the driver by entering into ELAN_WAIT_RECALIBRATION state
> and thus this change shouldn't change the old behavior.
> 
> Signed-off-by: Dmitry Osipenko 
> Tested-by: Michał Mirosław 
> Signed-off-by: Michał Mirosław 
> ---
>  drivers/input/touchscreen/elants_i2c.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/elants_i2c.c 
> b/drivers/input/touchscreen/elants_i2c.c
> index c24d8cdc4251..1cbda6f20d07 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -61,6 +61,15 @@
>  #define QUEUE_HEADER_NORMAL  0X63
>  #define QUEUE_HEADER_WAIT0x64
>  
> +/*
> + * Depending on firmware version, eKTF3624 touchscreens may utilize one of
> + * these opcodes for the touch events: 0x63 and 0x66. The 0x63 is used by
> + * older firmware version and differs from 0x66 such that touch pressure
> + * value needs to be adjusted. The 0x66 opcode of newer firmware is equal
> + * to 0x63 of eKTH3500.
> + */
> +#define QUEUE_HEADER_NORMAL2 0x66
> +
>  /* Command header definition */
>  #define CMD_HEADER_WRITE 0x54
>  #define CMD_HEADER_READ  0x53
> @@ -1052,7 +1061,6 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
>   switch (ts->buf[FW_HDR_TYPE]) {
>   case CMD_HEADER_HELLO:
>   case CMD_HEADER_RESP:
> - case CMD_HEADER_REK:
>   break;
>  
>   case QUEUE_HEADER_WAIT:
> @@ -1072,6 +1080,7 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
>   break;
>  
>   case QUEUE_HEADER_NORMAL:
> + case QUEUE_HEADER_NORMAL2:

I think here I would also prefer that we only accepted this for the
devices where we expect to see such packets:

case CMD_HEADER_REK:
/* comment from above why this is done ... */
if (ts->chip_id != EKTF3624)
break;
fallthrough;
case QUEUE_HEADER_NORMAL2:

...

Given this comments I wonder if it would not make sense to combine the 3
patches into one adding support for EKTF3624...


>   report_count = ts->buf[FW_HDR_COUNT];
>   if (report_count == 0 || report_count > 3) {
>   dev_err(>dev,
> -- 
> 2.20.1
> 

Thanks.

-- 
Dmitry

[PATCH RESEND v8 4/4] input: elants: support 0x66 reply opcode for reporting touches

[Michał Mirosław]

From: Dmitry Osipenko 

eKTF3624 touchscreen firmware uses two variants of the reply opcodes for
reporting touch events: one is 0x63 (used by older firmware) and other is
0x66 (used by newer firmware). The 0x66 variant is equal to 0x63 of
eKTH3500, while 0x63 needs small adjustment of the touch pressure value.

Nexus 7 tablet device has eKTF3624 touchscreen and it uses 0x66 opcode for
reporting touch events, let's support it now. Other devices, eg. ASUS TF300T,
use 0x63.

Note: CMD_HEADER_REK is used for replying to calibration requests, it has
the same 0x66 opcode number which eKTF3624 uses for reporting touches.
The calibration replies are handled separately from the the rest of the
commands in the driver by entering into ELAN_WAIT_RECALIBRATION state
and thus this change shouldn't change the old behavior.

Signed-off-by: Dmitry Osipenko 
Tested-by: Michał Mirosław 
Signed-off-by: Michał Mirosław 
---
 drivers/input/touchscreen/elants_i2c.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index c24d8cdc4251..1cbda6f20d07 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -61,6 +61,15 @@
 #define QUEUE_HEADER_NORMAL0X63
 #define QUEUE_HEADER_WAIT  0x64
 
+/*
+ * Depending on firmware version, eKTF3624 touchscreens may utilize one of
+ * these opcodes for the touch events: 0x63 and 0x66. The 0x63 is used by
+ * older firmware version and differs from 0x66 such that touch pressure
+ * value needs to be adjusted. The 0x66 opcode of newer firmware is equal
+ * to 0x63 of eKTH3500.
+ */
+#define QUEUE_HEADER_NORMAL2   0x66
+
 /* Command header definition */
 #define CMD_HEADER_WRITE   0x54
 #define CMD_HEADER_READ0x53
@@ -1052,7 +1061,6 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
switch (ts->buf[FW_HDR_TYPE]) {
case CMD_HEADER_HELLO:
case CMD_HEADER_RESP:
-   case CMD_HEADER_REK:
break;
 
case QUEUE_HEADER_WAIT:
@@ -1072,6 +1080,7 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
break;
 
case QUEUE_HEADER_NORMAL:
+   case QUEUE_HEADER_NORMAL2:
report_count = ts->buf[FW_HDR_COUNT];
if (report_count == 0 || report_count > 3) {
dev_err(>dev,
-- 
2.20.1

TREAT AND REPLY URGENTLY.

[abdul karim]

FROM MR. ABDUL KARIM
AUDIT & ACCOUNT MANAGER
BANK OF AFRICA (B.O.A)
OUAGADOUGOU BURKINA FASO
WEST AFRICA.

Greeting My Dear Friend,

With due respect, I have decided to contact you on a business
transaction that will be beneficial to both of us. At the bank last
account and auditing evaluation, my staffs came across an old account
which was being maintained by a foreign client who we learn was among
the deceased passengers of motor accident on November.2003, the
deceased was unable to run this account since his death. The account
has remained dormant without the knowledge of his family since it was
put in a safe deposit account in the bank for future investment by the
client.

Since his demise, even the members of his family haven't applied for
claims over this fund and it has been in the safe deposit account
until I discovered that it cannot be claimed since our client is a
foreign national and we are sure that he has no next of kin here to
file claims over the money. As the director of the department, this
discovery was brought to my office so as to decide what is to be done.
I decided to seek ways through which to transfer this money out of the
bank and out of the country too.

The total amount in the account is $10.5 millions with my positions as
staffs of the bank, I am handicapped because I cannot operate foreign
accounts and cannot lay bonafide claim over this money. The client was
a foreign national and you will only be asked to act as his next of
kin and I will supply you with all the necessary information and bank
data to assist you in being able to transfer this money to any bank of
your choice where this money could be transferred into.

The total sum will be shared as follows: 50% for me, 40% for you,
while 10% will map aside for any expenses incidental occur during the
transfering of this fund into your bank account. and the expenses
should be the first thing to be remove before sharing of this fund
according to our percentages . The transfer is risk free on both sides
hence you are going to follow my instruction till the fund transfer to
your account. Since I work in this bank that is why you should be
confident in the success of this transaction because you will be
updated with information as at when desired.

I will wish you to keep this transaction secret and confidential as I
am hoping to retire with my share of this money at the end of
transaction which will be when this money is safety in your account. I
will then come over to your country for sharing according to the
previously agreed percentages. You might even have to advise me on
possibilities of investment in your country or elsewhere of our
choice. May God help you to help me to a restive retirement, Amen,

Please for further information and inquires feel free to contact me
back immediately for more explanation and better understanding I want
you to assure me your capability of handling this project with trust
by providing me your following information details such as:

(1)NAME..
(2)AGE:
(3)SEX:.
(4)PHONE NUMBER:.
(5)OCCUPATION: .
(6)YOUR COUNTRY:.

Yours sincerely,

Mr. Abdul Karim.

Re: [PATCH] macintosh/adb-iop: Always wait for reply message from IOP

[Finn Thain]

On Fri, 4 Dec 2020, Geert Uytterhoeven wrote:

> Hi Finn,
> 
> On Fri, Nov 20, 2020 at 5:54 AM Finn Thain  wrote:
> > A recent patch incorrectly altered the adb-iop state machine behaviour
> > and introduced a regression that can appear intermittently as a
> > malfunctioning ADB input device. This seems to be caused when reply
> > packets from different ADB commands become mixed up, especially during
> > the adb bus scan. Fix this by unconditionally entering the awaiting_reply
> > state after sending an explicit command, even when the ADB command won't
> > generate a reply from the ADB device.
> >
> > Cc: Joshua Thompson 
> > Fixes: e2954e5f727f ("macintosh/adb-iop: Implement sending -> idle state 
> > transition")
> > Tested-by: Stan Johnson 
> > Signed-off-by: Finn Thain 
> 
> Thanks for your patch!
> 
> > --- a/drivers/macintosh/adb-iop.c
> > +++ b/drivers/macintosh/adb-iop.c
> > @@ -84,10 +84,7 @@ static void adb_iop_complete(struct iop_msg *msg)
> >
> > local_irq_save(flags);
> >
> > -   if (current_req->reply_expected)
> > -   adb_iop_state = awaiting_reply;
> > -   else
> > -   adb_iop_done();
> > +   adb_iop_state = awaiting_reply;
> >
> > local_irq_restore(flags);
> >  }
> > @@ -95,8 +92,9 @@ static void adb_iop_complete(struct iop_msg *msg)
> >  /*
> >   * Listen for ADB messages from the IOP.
> >   *
> > - * This will be called when unsolicited messages (usually replies to TALK
> > - * commands or autopoll packets) are received.
> > + * This will be called when unsolicited IOP messages are received.
> > + * These IOP messages can carry ADB autopoll responses and also occur
> > + * after explicit ADB commands.
> >   */
> >
> >  static void adb_iop_listen(struct iop_msg *msg)
> > @@ -123,8 +121,10 @@ static void adb_iop_listen(struct iop_msg *msg)
> > if (adb_iop_state == awaiting_reply) {
> > struct adb_request *req = current_req;
> >
> > -   req->reply_len = amsg->count + 1;
> > -   memcpy(req->reply, >cmd, req->reply_len);
> > +   if (req->reply_expected) {
> > +   req->reply_len = amsg->count + 1;
> > +   memcpy(req->reply, >cmd, 
> > req->reply_len);
> > +   }
> 
> So if we're not expecting a reply. It's ignored.
> Just wondering: what kind of messages are being dropped?

I believe they were empty, with flags == ADB_IOP_EXPLICIT|ADB_IOP_TIMEOUT.

> If reply packets from different ADB commands become mixed up, they are 
> still (expected?) replies to messages we sent before. Why shouldn't we 
> depend on receiving the replies?
> 

It turns out that the IOP always generates reply messages, even when the 
ADB command does not produce a reply packet (e.g. ADB Listen command). 

The commit being fixed got that wrong.

So it's not really the ADB reply packets that are being mixed up, it's the 
IOP messages that enclose them. The bug goes like this:

1. CPU sends a message to the IOP, expecting no response because this 
message contains an ADB Listen command. The ADB command is now considered 
complete.

2. CPU sends a second message to the IOP, this time expecting a response 
because this message contains an ADB Talk command. This ADB command needs 
a reply before it can be completed.

3. adb-iop driver receives an IOP message and assumes that it relates to 
the Talk command. It's actually for the previous command. The Talk command 
is now considered complete but it gets the wrong reply data.

4. adb-iop driver gets another IOP response message, which contains the 
actual reply data for the Talk command, but this is dropped (the driver is 
no longer in awaiting_reply state).

Please go ahead and add this analysis to the commit log if you think it 
would help.

> >
> > req_done = true;
> > }
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> 

Greetings please Reply asap

[Mohamad Azzam]

-- 


 Greetings and best compliment of the day, am contacting you
independently of my investigation in my bank and no one is informed of
this communication. I need your urgent assistance in transferring the
sum of $13.5million dollars to your private account,  that belongs to
one of our late foreign customer who died a longtime with his supposed
NEXT OF KIN since the year 2008.

The money has been here in our Bank lying dormant for years now
without anybody coming for the claim of it as the deceased relation. I
want to release the money to you as the relative to our deceased
customer, the Banking laws here does not allow such money to stay more
than 15years, because the money will be recalled to the Bank Treasury
account as unclaimed fund.

I am ready to share with you 40% for you and 60% for me, by indicating
your interest I will send you the full details on how the business
will be executed without any hitch.

I will be waiting for your urgent response including your mobile that
is in what sap for easy communication. Here is my Private Email
address (hasamuhamma...@gmail.com)

Thanks.
Here is my mobile number and whatsApp +22669813005

Best Regards,
Mr. Mohamad Azzam

REPLY ME URGENTLY

[Elizabeth Edward]

Greeting

Please forgive me for stressing you with my predicaments and I sorry
to approach you through this media it is because it serves the fastest
means of communication. I came across your E-mail from my personal
search and I decided to contact you believing you will be honest to
fulfill my final wish before I die.


I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.


Since my days are numbered, I have decided willingly to fulfill my
long-time promise to donate you the sum ($5.000.000.00) million
dollars I inherited from my late husband Mr. Edward Herbart, foreign
bank account over years. I need a very honest person who can assist in
transfer of this money to his or her account and use the funds for
charities work of God while you use 50% for yourself. I want you to
know there are no risk involved, it is 100% hitch free & safe. If you
will be interesting to assist in getting this fund into your account
for charity project to fulfill my promise before I die please let me
know immediately. I will appreciate your utmost confidentiality as I
wait for your reply.


Best Regard,


Mrs. Elizabeth Edward

Re: [PATCH] macintosh/adb-iop: Always wait for reply message from IOP

[Geert Uytterhoeven]

Hi Finn,

On Fri, Nov 20, 2020 at 5:54 AM Finn Thain  wrote:
> A recent patch incorrectly altered the adb-iop state machine behaviour
> and introduced a regression that can appear intermittently as a
> malfunctioning ADB input device. This seems to be caused when reply
> packets from different ADB commands become mixed up, especially during
> the adb bus scan. Fix this by unconditionally entering the awaiting_reply
> state after sending an explicit command, even when the ADB command won't
> generate a reply from the ADB device.
>
> Cc: Joshua Thompson 
> Fixes: e2954e5f727f ("macintosh/adb-iop: Implement sending -> idle state 
> transition")
> Tested-by: Stan Johnson 
> Signed-off-by: Finn Thain 

Thanks for your patch!

> --- a/drivers/macintosh/adb-iop.c
> +++ b/drivers/macintosh/adb-iop.c
> @@ -84,10 +84,7 @@ static void adb_iop_complete(struct iop_msg *msg)
>
> local_irq_save(flags);
>
> -   if (current_req->reply_expected)
> -   adb_iop_state = awaiting_reply;
> -   else
> -   adb_iop_done();
> +   adb_iop_state = awaiting_reply;
>
> local_irq_restore(flags);
>  }
> @@ -95,8 +92,9 @@ static void adb_iop_complete(struct iop_msg *msg)
>  /*
>   * Listen for ADB messages from the IOP.
>   *
> - * This will be called when unsolicited messages (usually replies to TALK
> - * commands or autopoll packets) are received.
> + * This will be called when unsolicited IOP messages are received.
> + * These IOP messages can carry ADB autopoll responses and also occur
> + * after explicit ADB commands.
>   */
>
>  static void adb_iop_listen(struct iop_msg *msg)
> @@ -123,8 +121,10 @@ static void adb_iop_listen(struct iop_msg *msg)
> if (adb_iop_state == awaiting_reply) {
>     struct adb_request *req = current_req;
>
> -   req->reply_len = amsg->count + 1;
> -   memcpy(req->reply, >cmd, req->reply_len);
> +   if (req->reply_expected) {
> +   req->reply_len = amsg->count + 1;
> +   memcpy(req->reply, >cmd, 
> req->reply_len);
> +   }

So if we're not expecting a reply. It's ignored.
Just wondering: what kind of messages are being dropped?
If reply packets from different ADB commands become mixed up,
they are still (expected?) replies to messages we sent before. Why
shouldn't we depend on receiving the replies?

>
> req_done = true;
> }

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

URGENT REPLY.

[Karim Zakari]

-- 
Good-Day Friend,

  I know that this letter will come to you as surprise, I got your
contact address while am searching for foreign partner to assist me in
this business transaction that is present in our favor, My name is Mr.
KARIM ZAKARI, I am the Bill and Exchange (assistant) Manager (BOA)
BANK OF AFRICA. I'm proposing to lift in your name (US$16.5 Million
Dollars) that belong to our later customer, MR. GORPUN VLADIMIR From
Russia who died in Siber airline that crashed into sea at Israel on
4th October 2001.

I want to present you to my bank here as the beneficiary to this fund
and Am waiting for your response for more details, As you are willing
to execute this business opportunity with me.

Yours Sincerely,
Mr. Karim Zakari.

REPLY ME URGENTLY

[Mrs. Elizabeth Edward]

Greeting

Please forgive me for stressing you with my predicaments and I sorry
to approach you through this media it is because it serves the fastest
means of communication. I came across your E-mail from my personal
search and I decided to contact you believing you will be honest to
fulfill my final wish before I die.

I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.

Since my days are numbered, I’ve decided willingly to fulfill my
long-time promise to donate you the sum ($5.000.000.00) million
dollars I inherited from my late husband Mr. Edward Herbart, foreign
bank account over years. I need a very honest person who can assist in
transfer of this money to his or her account and use the funds for
charities work of God while you use 50% for yourself. I want you to
know there are no risk involved, it is 100% hitch free & safe. If you
will be interesting to assist in getting this fund into your account
for charity project to fulfill my promise before I die please let me
know immediately. I will appreciate your utmost confidentiality as I
wait for your reply.

Best Regards

Mrs. Elizabeth Edward

Please reply to me

[Dailborh R.]

I'm Dailborh R. from US. I picked interest in you and I would like to know
more about you and establish relationship with you. i will wait for
your response. thank you.

TREAT AND REPLY URGENTLY.

[abdul karim]

FROM MR. ABDUL KARIM
AUDIT & ACCOUNT MANAGER
BANK OF AFRICA (B.O.A)
OUAGADOUGOU BURKINA FASO
WEST AFRICA.

Greeting My Dear Friend,

With due respect, I have decided to contact you on a business
transaction that will be beneficial to both of us. At the bank last
account and auditing evaluation, my staffs came across an old account
which was being maintained by a foreign client who we learn was among
the deceased passengers of motor accident on November.2003, the
deceased was unable to run this account since his death. The account
has remained dormant without the knowledge of his family since it was
put in a safe deposit account in the bank for future investment by the
client.

Since his demise, even the members of his family haven't applied for
claims over this fund and it has been in the safe deposit account
until I discovered that it cannot be claimed since our client is a
foreign national and we are sure that he has no next of kin here to
file claims over the money. As the director of the department, this
discovery was brought to my office so as to decide what is to be done.
I decided to seek ways through which to transfer this money out of the
bank and out of the country too.

The total amount in the account is $10.5 millions with my positions as
staffs of the bank, I am handicapped because I cannot operate foreign
accounts and cannot lay bonafide claim over this money. The client was
a foreign national and you will only be asked to act as his next of
kin and I will supply you with all the necessary information and bank
data to assist you in being able to transfer this money to any bank of
your choice where this money could be transferred into.

The total sum will be shared as follows: 50% for me, 40% for you,
while 10% will map aside for any expenses incidental occur during the
transfering of this fund into your bank account. and the expenses
should be the first thing to be remove before sharing of this fund
according to our percentages . The transfer is risk free on both sides
hence you are going to follow my instruction till the fund transfer to
your account. Since I work in this bank that is why you should be
confident in the success of this transaction because you will be
updated with information as at when desired.

I will wish you to keep this transaction secret and confidential as I
am hoping to retire with my share of this money at the end of
transaction which will be when this money is safety in your account. I
will then come over to your country for sharing according to the
previously agreed percentages. You might even have to advise me on
possibilities of investment in your country or elsewhere of our
choice. May God help you to help me to a restive retirement, Amen,

Please for further information and inquires feel free to contact me
back immediately for more explanation and better understanding I want
you to assure me your capability of handling this project with trust
by providing me your following information details such as:

(1)NAME..
(2)AGE:
(3)SEX:.
(4)PHONE NUMBER:.
(5)OCCUPATION: .
(6)YOUR COUNTRY:.

Yours sincerely,

Mr. Abdul Karim.

[PATCH] macintosh/adb-iop: Always wait for reply message from IOP

[Finn Thain]

A recent patch incorrectly altered the adb-iop state machine behaviour
and introduced a regression that can appear intermittently as a
malfunctioning ADB input device. This seems to be caused when reply
packets from different ADB commands become mixed up, especially during
the adb bus scan. Fix this by unconditionally entering the awaiting_reply
state after sending an explicit command, even when the ADB command won't
generate a reply from the ADB device.

Cc: Joshua Thompson 
Fixes: e2954e5f727f ("macintosh/adb-iop: Implement sending -> idle state 
transition")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/macintosh/adb-iop.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/macintosh/adb-iop.c b/drivers/macintosh/adb-iop.c
index 6b26b6a2c463..0ee327249150 100644
--- a/drivers/macintosh/adb-iop.c
+++ b/drivers/macintosh/adb-iop.c
@@ -84,10 +84,7 @@ static void adb_iop_complete(struct iop_msg *msg)
 
local_irq_save(flags);
 
-   if (current_req->reply_expected)
-   adb_iop_state = awaiting_reply;
-   else
-   adb_iop_done();
+   adb_iop_state = awaiting_reply;
 
local_irq_restore(flags);
 }
@@ -95,8 +92,9 @@ static void adb_iop_complete(struct iop_msg *msg)
 /*
  * Listen for ADB messages from the IOP.
  *
- * This will be called when unsolicited messages (usually replies to TALK
- * commands or autopoll packets) are received.
+ * This will be called when unsolicited IOP messages are received.
+ * These IOP messages can carry ADB autopoll responses and also occur
+ * after explicit ADB commands.
  */
 
 static void adb_iop_listen(struct iop_msg *msg)
@@ -123,8 +121,10 @@ static void adb_iop_listen(struct iop_msg *msg)
if (adb_iop_state == awaiting_reply) {
struct adb_request *req = current_req;
 
-   req->reply_len = amsg->count + 1;
-   memcpy(req->reply, >cmd, req->reply_len);
+   if (req->reply_expected) {
+   req->reply_len = amsg->count + 1;
+       memcpy(req->reply, >cmd, req->reply_len);
+   }
 
req_done = true;
}
-- 
2.26.2

REPLY ME URGENTLY

[Elizabeth Edward]

Greeting

Please forgive me for stressing you with my predicaments and I sorry
to approach you through this media it is because it serves the fastest
means of communication. I came across your E-mail from my personal
search and I decided to contact you believing you will be honest to
fulfill my final wish before I die.


I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.


Since my days are numbered, I have decided willingly to fulfill my
long-time promise to donate you the sum ($5.000.000.00) million
dollars I inherited from my late husband Mr. Edward Herbart, foreign
bank account over years. I need a very honest person who can assist in
transfer of this money to his or her account and use the funds for
charities work of God while you use 50% for yourself. I want you to
know there are no risk involved, it is 100% hitch free & safe. If you
will be interesting to assist in getting this fund into your account
for charity project to fulfill my promise before I die please let me
know immediately. I will appreciate your utmost confidentiality as I
wait for your reply.


Best Regard,


Mrs. Elizabeth Edward

[RFC PATCH v2 24/26] docs: reporting-bugs: explain why users might get neither reply nor fix

[Thorsten Leemhuis]

Not even getting a reply after one invested quite a bit of time with
preparing and writing a report can be quite devastating. But when it
comes to Linux, this can easily happen for good or bad reasons. Hence,
use this opportunity to explain why this might happen. Hopefully some
people will then be less disappointed if it happens to them.

Signed-off-by: Thorsten Leemhuis 
---
 Documentation/admin-guide/reporting-bugs.rst | 57 
 1 file changed, 57 insertions(+)

diff --git a/Documentation/admin-guide/reporting-bugs.rst 
b/Documentation/admin-guide/reporting-bugs.rst
index ad9a5d896728..446c02e94c93 100644
--- a/Documentation/admin-guide/reporting-bugs.rst
+++ b/Documentation/admin-guide/reporting-bugs.rst
@@ -1467,6 +1467,63 @@ for the subsystem as well as the stable mailing list the 
:ref:`MAINTAINERS
 ` file mention in the section "STABLE BRANCH".
 
 
+Why some issues won't get any reaction or remain unfixed after being reported
+=
+
+When reporting a problem to the Linux developers, be aware only 'issues of high
+priority' (regressions, security issues, severe problems) are definitely going
+to get resolved. The maintainers or if all else fails Linus Torvalds himself
+will make sure of that. They and the other kernel developers will fix a lot of
+other issues as well. But be aware that sometimes they can't or won't help; and
+sometimes there isn't even anyone to send a report to.
+
+This is best explained with kernel developers that contribute to the Linux
+kernel in their spare time. Quite a few of the drivers in the kernel were
+written by such programmers, often because they simply wanted to make their
+hardware usable on their favorite operating system.
+
+These programmers most of the time will happily fix problems other people
+report. But nobody can force them to do, as they are contributing voluntarily.
+
+Then there are situations where such developers really want to fix an issue,
+but can't: sometimes they lack hardware programming documentation to do so.
+This often happens when the publicly available docs are superficial or the
+driver was written with the help of reverse engineering.
+
+Sooner or later spare time developers will also stop caring for the driver.
+Maybe their test hardware broke, got replaced by something more fancy, or is so
+old that it's something you don't find much outside of computer museums
+anymore. Sometimes developer stops caring for their code and Linux at all, as
+something different in their life became way more important. In some cases
+nobody is willing to take over the job as maintainer ??? and nobody can be 
forced
+to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned
+drivers nevertheless remain in the kernel: they are still useful for people and
+removing would be a regression.
+
+The situation is not that different with developers that are paid for their
+work on the Linux kernel. Those contribute most changes these days. But their
+employers sooner or later also stop caring for their code or make its
+programmer focus on other things. Hardware vendors for example earn their money
+mainly by selling new hardware; quite a few of them hence are not investing
+much time and energy in maintaining a Linux kernel driver for something they
+stopped selling years ago. Enterprise Linux distributors often care for a
+longer time period, but in new versions often leave support for old and rare
+hardware aside to limit the scope. Often spare time contributors take over once
+a company orphans some code, but as mentioned above: sooner or later they will
+leave the code behind, too.
+
+Priorities are another reason why some issues are not fixed, as maintainers
+quite often are forced to set those, as time to work on Linux is limited.
+That's true for spare time or the time employers grant their developers to
+spend on maintenance work on the upstream kernel. Sometimes maintainers also
+get overwhelmed with reports, even if a driver is working nearly perfectly. To
+not get completely stuck, the programmer thus might have no other choice than
+to prioritize issue reports and reject some of them.
+
+But don't worry too much about all of this, a lot of drivers have active
+maintainers who are quite interested in fixing as many issues as possible.
+
+
 .. 
 .. Temporary marker added while this document is rewritten. Sections above
 .. are new and dual-licensed under GPLv2+ and CC-BY 4.0, those below are old.
-- 
2.28.0

[PATCH RESEND v8 4/4] input: elants: support 0x66 reply opcode for reporting touches

[Michał Mirosław]

From: Dmitry Osipenko 

eKTF3624 touchscreen firmware uses two variants of the reply opcodes for
reporting touch events: one is 0x63 (used by older firmware) and other is
0x66 (used by newer firmware). The 0x66 variant is equal to 0x63 of
eKTH3500, while 0x63 needs small adjustment of the touch pressure value.

Nexus 7 tablet device has eKTF3624 touchscreen and it uses 0x66 opcode for
reporting touch events, let's support it now. Other devices, eg. ASUS TF300T,
use 0x63.

Note: CMD_HEADER_REK is used for replying to calibration requests, it has
the same 0x66 opcode number which eKTF3624 uses for reporting touches.
The calibration replies are handled separately from the the rest of the
commands in the driver by entering into ELAN_WAIT_RECALIBRATION state
and thus this change shouldn't change the old behavior.

Signed-off-by: Dmitry Osipenko 
Tested-by: Michał Mirosław 
Signed-off-by: Michał Mirosław 
---
 drivers/input/touchscreen/elants_i2c.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index c24d8cdc4251..1cbda6f20d07 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -61,6 +61,15 @@
 #define QUEUE_HEADER_NORMAL0X63
 #define QUEUE_HEADER_WAIT  0x64
 
+/*
+ * Depending on firmware version, eKTF3624 touchscreens may utilize one of
+ * these opcodes for the touch events: 0x63 and 0x66. The 0x63 is used by
+ * older firmware version and differs from 0x66 such that touch pressure
+ * value needs to be adjusted. The 0x66 opcode of newer firmware is equal
+ * to 0x63 of eKTH3500.
+ */
+#define QUEUE_HEADER_NORMAL2   0x66
+
 /* Command header definition */
 #define CMD_HEADER_WRITE   0x54
 #define CMD_HEADER_READ0x53
@@ -1052,7 +1061,6 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
switch (ts->buf[FW_HDR_TYPE]) {
case CMD_HEADER_HELLO:
case CMD_HEADER_RESP:
-   case CMD_HEADER_REK:
break;
 
case QUEUE_HEADER_WAIT:
@@ -1072,6 +1080,7 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
break;
 
case QUEUE_HEADER_NORMAL:
+   case QUEUE_HEADER_NORMAL2:
report_count = ts->buf[FW_HDR_COUNT];
if (report_count == 0 || report_count > 3) {
dev_err(>dev,
-- 
2.20.1

[PATCH v3 4/4] drm/bridge: ti-sn65dsi86: Update reply on aux failures

[Stephen Boyd]

We should be setting the drm_dp_aux_msg::reply field if a NACK or a
SHORT reply happens. Update the error bit handling logic in
ti_sn_aux_transfer() to handle these cases and notify upper layers that
such errors have happened. This helps the retry logic understand that a
timeout has happened, or to shorten the read length if the panel isn't
able to handle the longest read possible.

Note: I don't have any hardware that exhibits these code paths so this
is written based on reading the datasheet for this bridge and inspecting
the code and how this is called.

Changes in v2:
 - Move WRITE_STATUS_UPDATE check from case to assignment

Changes in v2:
 - Handle WRITE_STATUS_UPDATE properly

Reviewed-by: Douglas Anderson 
Cc: Laurent Pinchart 
Cc: Jonas Karlman 
Cc: Jernej Skrabec 
Cc: Sean Paul 
Acked-by: Sam Ravnborg 
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 35 +++
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 6b6e98ca2881..3a758c706b70 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -861,7 +861,7 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
  struct drm_dp_aux_msg *msg)
 {
struct ti_sn_bridge *pdata = aux_to_ti_sn_bridge(aux);
-   u32 request = msg->request & ~DP_AUX_I2C_MOT;
+   u32 request = msg->request & ~(DP_AUX_I2C_MOT | 
DP_AUX_I2C_WRITE_STATUS_UPDATE);
u32 request_val = AUX_CMD_REQ(msg->request);
u8 *buf = msg->buffer;
unsigned int len = msg->size;
@@ -878,6 +878,8 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
case DP_AUX_NATIVE_READ:
case DP_AUX_I2C_READ:
regmap_write(pdata->regmap, SN_AUX_CMD_REG, request_val);
+   /* Assume it's good */
+   msg->reply = 0;
break;
default:
return -EINVAL;
@@ -909,10 +911,33 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
ret = regmap_read(pdata->regmap, SN_AUX_CMD_STATUS_REG, );
if (ret)
return ret;
-   else if ((val & AUX_IRQ_STATUS_NAT_I2C_FAIL)
-|| (val & AUX_IRQ_STATUS_AUX_RPLY_TOUT)
-|| (val & AUX_IRQ_STATUS_AUX_SHORT))
-   return -ENXIO;
+
+   if (val & AUX_IRQ_STATUS_AUX_RPLY_TOUT) {
+   /*
+* The hardware tried the message seven times per the DP spec
+* but it hit a timeout. We ignore defers here because they're
+* handled in hardware.
+*/
+   return -ETIMEDOUT;
+   }
+
+   if (val & AUX_IRQ_STATUS_AUX_SHORT) {
+   ret = regmap_read(pdata->regmap, SN_AUX_LENGTH_REG, );
+   if (ret)
+   return ret;
+   } else if (val & AUX_IRQ_STATUS_NAT_I2C_FAIL) {
+   switch (request) {
+   case DP_AUX_I2C_WRITE:
+       case DP_AUX_I2C_READ:
+   msg->reply |= DP_AUX_I2C_REPLY_NACK;
+   break;
+   case DP_AUX_NATIVE_READ:
+   case DP_AUX_NATIVE_WRITE:
+   msg->reply |= DP_AUX_NATIVE_REPLY_NACK;
+   break;
+   }
+   return 0;
+   }
 
if (request == DP_AUX_NATIVE_WRITE || request == DP_AUX_I2C_WRITE ||
len == 0)
-- 
Sent by a computer, using git, on the internet

Re: [PATCH v2 4/4] drm/bridge: ti-sn65dsi86: Update reply on aux failures

[Doug Anderson]

Hi,

On Thu, Oct 29, 2020 at 6:17 PM Stephen Boyd  wrote:
>
> We should be setting the drm_dp_aux_msg::reply field if a NACK or a
> SHORT reply happens. Update the error bit handling logic in
> ti_sn_aux_transfer() to handle these cases and notify upper layers that
> such errors have happened. This helps the retry logic understand that a
> timeout has happened, or to shorten the read length if the panel isn't
> able to handle the longest read possible.
>
> Note: I don't have any hardware that exhibits these code paths so this
> is written based on reading the datasheet for this bridge and inspecting
> the code and how this is called.
>
> Changes in v2:
>  - Handle WRITE_STATUS_UPDATE properly
>
> Cc: Douglas Anderson 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Jernej Skrabec 
> Cc: Sean Paul 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 36 ---
>  1 file changed, 32 insertions(+), 4 deletions(-)

This looks right to me, now.  Hopefully if/when someone ends up with
hardware that exercises these codepaths they'll at least be in a
better state and maybe they will all just work!  :-)

Reviewed-by: Douglas Anderson 

[PATCH v2 4/4] drm/bridge: ti-sn65dsi86: Update reply on aux failures

[Stephen Boyd]

We should be setting the drm_dp_aux_msg::reply field if a NACK or a
SHORT reply happens. Update the error bit handling logic in
ti_sn_aux_transfer() to handle these cases and notify upper layers that
such errors have happened. This helps the retry logic understand that a
timeout has happened, or to shorten the read length if the panel isn't
able to handle the longest read possible.

Note: I don't have any hardware that exhibits these code paths so this
is written based on reading the datasheet for this bridge and inspecting
the code and how this is called.

Changes in v2:
 - Handle WRITE_STATUS_UPDATE properly

Cc: Douglas Anderson 
Cc: Laurent Pinchart 
Cc: Jonas Karlman 
Cc: Jernej Skrabec 
Cc: Sean Paul 
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 36 ---
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index f86934fd6cc8..984ea41deca8 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -873,10 +873,16 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
return -EINVAL;
 
switch (request) {
+   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
+   /* WRITE_STATUS_UPDATE only matters for request_val */
+   request &= ~DP_AUX_I2C_WRITE_STATUS_UPDATE;
+   fallthrough;
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
case DP_AUX_NATIVE_READ:
case DP_AUX_I2C_READ:
+   /* Assume it's good */
+   msg->reply = 0;
break;
default:
return -EINVAL;
@@ -909,10 +915,32 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
ret = regmap_read(pdata->regmap, SN_AUX_CMD_STATUS_REG, );
if (ret)
return ret;
-   else if ((val & AUX_IRQ_STATUS_NAT_I2C_FAIL)
-|| (val & AUX_IRQ_STATUS_AUX_RPLY_TOUT)
-|| (val & AUX_IRQ_STATUS_AUX_SHORT))
-   return -ENXIO;
+
+   if (val & AUX_IRQ_STATUS_AUX_RPLY_TOUT) {
+   /*
+* The hardware tried the message seven times per the DP spec
+* but it hit a timeout. We ignore defers here because they're
+* handled in hardware.
+*/
+   return -ETIMEDOUT;
+   }
+   if (val & AUX_IRQ_STATUS_AUX_SHORT) {
+   ret = regmap_read(pdata->regmap, SN_AUX_LENGTH_REG, );
+   if (ret)
+   return ret;
+   } else if (val & AUX_IRQ_STATUS_NAT_I2C_FAIL) {
+   switch (request) {
+   case DP_AUX_I2C_WRITE:
+   case DP_AUX_I2C_READ:
+   msg->reply |= DP_AUX_I2C_REPLY_NACK;
+   break;
+   case DP_AUX_NATIVE_READ:
+   case DP_AUX_NATIVE_WRITE:
+   msg->reply |= DP_AUX_NATIVE_REPLY_NACK;
+   break;
+   }
+   return 0;
+   }
 
if (request == DP_AUX_NATIVE_WRITE || request == DP_AUX_I2C_WRITE ||
len == 0)
-- 
Sent by a computer, using git, on the internet

Re: [PATCH 4/4] drm/bridge: ti-sn65dsi86: Update reply on aux failures

[Stephen Boyd]

Quoting Doug Anderson (2020-10-29 09:22:55)
> Hi,
> 
> On Wed, Oct 28, 2020 at 6:12 PM Stephen Boyd  wrote:
> >
> > We should be setting the drm_dp_aux_msg::reply field if a NACK or a
> > SHORT reply happens.
> 
> I don't think you update the "reply" field for SHORT, right?  You just
> return a different size?

Correct.

> 
> 
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index 6b6e98ca2881..19737bc01b8f 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -909,10 +910,32 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux 
> > *aux,
> > ret = regmap_read(pdata->regmap, SN_AUX_CMD_STATUS_REG, );
> > if (ret)
> > return ret;
> > -   else if ((val & AUX_IRQ_STATUS_NAT_I2C_FAIL)
> > -|| (val & AUX_IRQ_STATUS_AUX_RPLY_TOUT)
> > -|| (val & AUX_IRQ_STATUS_AUX_SHORT))
> > -   return -ENXIO;
> > +
> > +   if (val & AUX_IRQ_STATUS_AUX_RPLY_TOUT) {
> > +   /*
> > +* The hardware tried the message seven times per the DP 
> > spec
> > +* but it hit a timeout. We ignore defers here because 
> > they're
> > +* handled in hardware.
> > +*/
> > +   return -ETIMEDOUT;
> > +   }
> > +   if (val & AUX_IRQ_STATUS_AUX_SHORT) {
> > +   ret = regmap_read(pdata->regmap, SN_AUX_LENGTH_REG, );
> > +   if (ret)
> > +   return ret;
> 
> IIUC, your digging through the code showed that in order to fully
> handle the "SHORT" case you also needed to add support for
> "DP_AUX_I2C_WRITE_STATUS_UPDATE", right?

Oh yeah. If a short reply happens and it is aux over i2c then
drm_dp_i2c_msg_write_status_update() is called and
DP_AUX_I2C_WRITE_STATUS_UPDATE is set and then we try a transfer again.
We need to handle that type of request in this ti_sn_aux_transfer()
function.

> 
> Even without handling "DP_AUX_I2C_WRITE_STATUS_UPDATE" though, this
> patch seems to be an improvement and I'd support landing it.
> 
> Oh, I guess one other thing: I think this is all from code inspection,
> right?  You didn't manage to reproduce anything that would tickle one
> of these code paths?  Might be worth mentioning, even if "after the
> cut"?
> 

Yes, just code inspection. I can add that detail to the commit text.

Re: [PATCH 4/4] drm/bridge: ti-sn65dsi86: Update reply on aux failures

[Doug Anderson]

Hi,

On Wed, Oct 28, 2020 at 6:12 PM Stephen Boyd  wrote:
>
> We should be setting the drm_dp_aux_msg::reply field if a NACK or a
> SHORT reply happens.

I don't think you update the "reply" field for SHORT, right?  You just
return a different size?


> Update the error bit handling logic in
> ti_sn_aux_transfer() to handle these cases and notify upper layers that
> such errors have happened. This helps the retry logic understand that a
> timeout has happened, or to shorten the read length if the panel isn't
> able to handle the longest read possible.
>
> Cc: Douglas Anderson 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Jernej Skrabec 
> Cc: Sean Paul 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 31 +++
>  1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 6b6e98ca2881..19737bc01b8f 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -878,6 +878,7 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
> case DP_AUX_NATIVE_READ:
> case DP_AUX_I2C_READ:
> regmap_write(pdata->regmap, SN_AUX_CMD_REG, request_val);
> +   msg->reply = 0; /* Assume it's good */
> break;
> default:
> return -EINVAL;
> @@ -909,10 +910,32 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux 
> *aux,
> ret = regmap_read(pdata->regmap, SN_AUX_CMD_STATUS_REG, );
> if (ret)
> return ret;
> -   else if ((val & AUX_IRQ_STATUS_NAT_I2C_FAIL)
> -|| (val & AUX_IRQ_STATUS_AUX_RPLY_TOUT)
> -|| (val & AUX_IRQ_STATUS_AUX_SHORT))
> -   return -ENXIO;
> +
> +   if (val & AUX_IRQ_STATUS_AUX_RPLY_TOUT) {
> +   /*
> +* The hardware tried the message seven times per the DP spec
> +* but it hit a timeout. We ignore defers here because they're
> +* handled in hardware.
> +*/
> +   return -ETIMEDOUT;
> +   }
> +   if (val & AUX_IRQ_STATUS_AUX_SHORT) {
> +   ret = regmap_read(pdata->regmap, SN_AUX_LENGTH_REG, );
> +   if (ret)
> +   return ret;

IIUC, your digging through the code showed that in order to fully
handle the "SHORT" case you also needed to add support for
"DP_AUX_I2C_WRITE_STATUS_UPDATE", right?

Even without handling "DP_AUX_I2C_WRITE_STATUS_UPDATE" though, this
patch seems to be an improvement and I'd support landing it.

Oh, I guess one other thing: I think this is all from code inspection,
right?  You didn't manage to reproduce anything that would tickle one
of these code paths?  Might be worth mentioning, even if "after the
cut"?

-Doug

[PATCH 4/4] drm/bridge: ti-sn65dsi86: Update reply on aux failures

[Stephen Boyd]

We should be setting the drm_dp_aux_msg::reply field if a NACK or a
SHORT reply happens. Update the error bit handling logic in
ti_sn_aux_transfer() to handle these cases and notify upper layers that
such errors have happened. This helps the retry logic understand that a
timeout has happened, or to shorten the read length if the panel isn't
able to handle the longest read possible.

Cc: Douglas Anderson 
Cc: Laurent Pinchart 
Cc: Jonas Karlman 
Cc: Jernej Skrabec 
Cc: Sean Paul 
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 6b6e98ca2881..19737bc01b8f 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -878,6 +878,7 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
case DP_AUX_NATIVE_READ:
case DP_AUX_I2C_READ:
regmap_write(pdata->regmap, SN_AUX_CMD_REG, request_val);
+   msg->reply = 0; /* Assume it's good */
break;
default:
return -EINVAL;
@@ -909,10 +910,32 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
ret = regmap_read(pdata->regmap, SN_AUX_CMD_STATUS_REG, );
if (ret)
return ret;
-   else if ((val & AUX_IRQ_STATUS_NAT_I2C_FAIL)
-|| (val & AUX_IRQ_STATUS_AUX_RPLY_TOUT)
-|| (val & AUX_IRQ_STATUS_AUX_SHORT))
-   return -ENXIO;
+
+   if (val & AUX_IRQ_STATUS_AUX_RPLY_TOUT) {
+   /*
+* The hardware tried the message seven times per the DP spec
+* but it hit a timeout. We ignore defers here because they're
+* handled in hardware.
+*/
+   return -ETIMEDOUT;
+   }
+   if (val & AUX_IRQ_STATUS_AUX_SHORT) {
+   ret = regmap_read(pdata->regmap, SN_AUX_LENGTH_REG, );
+   if (ret)
+   return ret;
+   } else if (val & AUX_IRQ_STATUS_NAT_I2C_FAIL) {
+   switch (request) {
+   case DP_AUX_I2C_WRITE:
+   case DP_AUX_I2C_READ:
+   msg->reply |= DP_AUX_I2C_REPLY_NACK;
+   break;
+   case DP_AUX_NATIVE_READ:
+   case DP_AUX_NATIVE_WRITE:
+   msg->reply |= DP_AUX_NATIVE_REPLY_NACK;
+   break;
+   }
+   return 0;
+   }
 
if (request == DP_AUX_NATIVE_WRITE || request == DP_AUX_I2C_WRITE ||
len == 0)
-- 
Sent by a computer, using git, on the internet

[PATCH v8 4/4] input: elants: support 0x66 reply opcode for reporting touches

[Michał Mirosław]

From: Dmitry Osipenko 

eKTF3624 touchscreen firmware uses two variants of the reply opcodes for
reporting touch events: one is 0x63 (used by older firmware) and other is
0x66 (used by newer firmware). The 0x66 variant is equal to 0x63 of
eKTH3500, while 0x63 needs small adjustment of the touch pressure value.

Nexus 7 tablet device has eKTF3624 touchscreen and it uses 0x66 opcode for
reporting touch events, let's support it now. Other devices, eg. ASUS TF300T,
use 0x63.

Note: CMD_HEADER_REK is used for replying to calibration requests, it has
the same 0x66 opcode number which eKTF3624 uses for reporting touches.
The calibration replies are handled separately from the the rest of the
commands in the driver by entering into ELAN_WAIT_RECALIBRATION state
and thus this change shouldn't change the old behavior.

Signed-off-by: Dmitry Osipenko 
Tested-by: Michał Mirosław 
Signed-off-by: Michał Mirosław 
---
 drivers/input/touchscreen/elants_i2c.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index c24d8cdc4251..1cbda6f20d07 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -61,6 +61,15 @@
 #define QUEUE_HEADER_NORMAL0X63
 #define QUEUE_HEADER_WAIT  0x64
 
+/*
+ * Depending on firmware version, eKTF3624 touchscreens may utilize one of
+ * these opcodes for the touch events: 0x63 and 0x66. The 0x63 is used by
+ * older firmware version and differs from 0x66 such that touch pressure
+ * value needs to be adjusted. The 0x66 opcode of newer firmware is equal
+ * to 0x63 of eKTH3500.
+ */
+#define QUEUE_HEADER_NORMAL2   0x66
+
 /* Command header definition */
 #define CMD_HEADER_WRITE   0x54
 #define CMD_HEADER_READ0x53
@@ -1052,7 +1061,6 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
switch (ts->buf[FW_HDR_TYPE]) {
case CMD_HEADER_HELLO:
case CMD_HEADER_RESP:
-   case CMD_HEADER_REK:
break;
 
case QUEUE_HEADER_WAIT:
@@ -1072,6 +1080,7 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
break;
 
case QUEUE_HEADER_NORMAL:
+   case QUEUE_HEADER_NORMAL2:
report_count = ts->buf[FW_HDR_COUNT];
if (report_count == 0 || report_count > 3) {
dev_err(>dev,
-- 
2.20.1

Reply

[OSMAN]

Hello,

I hope this email meets you in good health, My names are Osman Jalloh and I am 
from Sierra Leone, I
have some kilos of gold which I inherited from my late parents and I will like 
to
ship it out to overseas for investment, I need a partner
who can receive the gold and make
arrangement for me to leave my country and meet you after you receive the gold.
Please note that, the gold is not a stolen gold but my family treasure
left behind by my late parents who were
local miners. If you are sincere and can handle this, provide your particulars 
as stated below:

FULL NAME:
ADDRESS:
TELEPHONE:
DATE OF BIRTH:
COUNTRY:
SEX:
OCCUPATION:
IDENTIFICATION:

Please write me back on my secure email addresses: (osmasj1...@gmail.com) and 
(osmasj1...@yahoo.com).

Thanks,
Osman Jalloh.

TREAT AS URGENT/ REPLY FOR MORE DETAILS

[Salif Musa]

-- 
Hi friend



I am a banker in ADB BANK. I want to transfer an abandoned sum of
USD15.6Million to your Bank account. 40/percent will be your share.

No risk involved but keeps it as secret. Contact me for more details.
Please reply me through my alternative email id only (salif.musa...@gmail.com)
for confidential reasons.


Yours
Dr Salif Musa

REPLY ME IMMEDIATELY

[Mr Mohamed Musa]

Assalamu alaikum

My name is Mr. Mohamed Musa, I am a staff working with the Bank Of
Africa here in Ouagadougou,Burkina Faso.

I want you to help me in receiving the sum of Twenty Seven Million Two
Hundred thousand Dollars ($27,200,000) into your Bank Account. This
fund was deposited in the bank here by a foreign customer who died
accidentally alongside with his entire family members many years ago.
Nobody had asked for this fund till now Please Contact me with my
Email: mrmohamedmu...@gmail.com for more details.

Mr. Mohamed Musa

[PATCH v6] ipvs: inspect reply packets from DR/TUN real servers

[longguang.yue]

Just like for MASQ, inspect the reply packets coming from DR/TUN
real servers and alter the connection's state and timeout
according to the protocol.

It's ipvs's duty to do traffic statistic if packets get hit,
no matter what mode it is.

---
Changes in v1: support DR/TUN mode statistic
Changes in v2: ip_vs_conn_out_get handles DR/TUN mode's conn
Changes in v3: fix checkpatch
Changes in v4, v5: restructure and optimise this feature
Changes in v6: rewrite subject and patch description

Signed-off-by: longguang.yue 
---
 net/netfilter/ipvs/ip_vs_conn.c | 18 +++---
 net/netfilter/ipvs/ip_vs_core.c | 17 ++---
 2 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index a90b8eac16ac..af08ca2d9174 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -401,6 +401,8 @@ struct ip_vs_conn *ip_vs_ct_in_get(const struct 
ip_vs_conn_param *p)
 struct ip_vs_conn *ip_vs_conn_out_get(const struct ip_vs_conn_param *p)
 {
unsigned int hash;
+   __be16 sport;
+   const union nf_inet_addr *saddr;
struct ip_vs_conn *cp, *ret=NULL;
 
/*
@@ -411,10 +413,20 @@ struct ip_vs_conn *ip_vs_conn_out_get(const struct 
ip_vs_conn_param *p)
rcu_read_lock();
 
hlist_for_each_entry_rcu(cp, _vs_conn_tab[hash], c_list) {
-   if (p->vport == cp->cport && p->cport == cp->dport &&
-   cp->af == p->af &&
+   if (p->vport != cp->cport)
+   continue;
+
+   if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ) {
+   sport = cp->vport;
+   saddr = >vaddr;
+   } else {
+   sport = cp->dport;
+   saddr = >daddr;
+   }
+
+   if (p->cport == sport && cp->af == p->af &&
ip_vs_addr_equal(p->af, p->vaddr, >caddr) &&
-   ip_vs_addr_equal(p->af, p->caddr, >daddr) &&
+   ip_vs_addr_equal(p->af, p->caddr, saddr) &&
p->protocol == cp->protocol &&
cp->ipvs == p->ipvs) {
if (!__ip_vs_conn_get(cp))
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index e3668a6e54e4..494ea1fcf4d8 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -875,7 +875,7 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
unsigned int verdict = NF_DROP;
 
if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
-   goto ignore_cp;
+   goto after_nat;
 
/* Ensure the checksum is correct */
if (!skb_csum_unnecessary(skb) && ip_vs_checksum_complete(skb, ihl)) {
@@ -900,7 +900,7 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
 
if (ip_vs_route_me_harder(cp->ipvs, af, skb, hooknum))
goto out;
-
+after_nat:
/* do the statistics and put it back */
ip_vs_out_stats(cp, skb);
 
@@ -909,8 +909,6 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
ip_vs_notrack(skb);
else
ip_vs_update_conntrack(skb, cp, 0);
-
-ignore_cp:
verdict = NF_ACCEPT;
 
 out:
@@ -1276,6 +1274,9 @@ handle_response(int af, struct sk_buff *skb, struct 
ip_vs_proto_data *pd,
 {
struct ip_vs_protocol *pp = pd->pp;
 
+   if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
+   goto after_nat;
+
IP_VS_DBG_PKT(11, af, pp, skb, iph->off, "Outgoing packet");
 
if (skb_ensure_writable(skb, iph->len))
@@ -1316,6 +1317,7 @@ handle_response(int af, struct sk_buff *skb, struct 
ip_vs_proto_data *pd,
 
IP_VS_DBG_PKT(10, af, pp, skb, iph->off, "After SNAT");
 
+after_nat:
ip_vs_out_stats(cp, skb);
ip_vs_set_state(cp, IP_VS_DIR_OUTPUT, skb, pd);
skb->ipvs_property = 1;
@@ -1413,8 +1415,6 @@ ip_vs_out(struct netns_ipvs *ipvs, unsigned int hooknum, 
struct sk_buff *skb, in
 ipvs, af, skb, );
 
if (likely(cp)) {
-   if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
-   goto ignore_cp;
return handle_response(af, skb, pd, cp, , hooknum);
}
 
@@ -1475,14 +1475,9 @@ ip_vs_out(struct netns_ipvs *ipvs, unsigned int hooknum, 
struct sk_buff *skb, in
}
}
 
-out:
IP_VS_DBG_PKT(12, af, pp, skb, iph.off,
  "ip_vs_out: packet continues traversal as normal");
return NF_ACCEPT;
-
-ignore_cp:
-   __ip_vs_conn_put(cp);
-   goto out;
 }
 
 /*
-- 
2.20.1 (Apple Git-117)

Re: [RFC PATCH v1 24/26] docs: reporting-bugs: explain why users might get neither reply nor fix

[Thorsten Leemhuis]

Many thx for you comments. Consider all the obvious spelling and

grammatical mistakes you pointed out fixed, I won't mention all of them

in this reply to keep things easier to follow.



Am 04.10.20 um 06:03 schrieb Randy Dunlap:
> On 10/1/20 1:50 AM, Thorsten Leemhuis wrote:

>> +selling new hardware; quite a few of them hence are not investing much time 
>> and
>> +energy in maintaining a Linux kernel driver for something they sold years 
>> ago.
>> +Enterprise Linux distributors often care for a longer time period, but in 
>> new
>> +version often leave support for old and rare hardware aside to limit the 
>> scope.
>> +Often spare time contributors take over once a company leaves some orphan 
>> some
>   drop last: 
> some
>> +code, 

/me looks closer

Changed to (that's what it was supposed to be):

Often spare time contributors take over once a company orphans some
code, […]

Ciao, Thorsten

Re: [RFC PATCH v1 24/26] docs: reporting-bugs: explain why users might get neither reply nor fix

[Randy Dunlap]

On 10/1/20 1:50 AM, Thorsten Leemhuis wrote:
> Not even getting a reply after one invested quite a bit of time with
> preparing and writing a report can be quite devastating. But when it
> comes to Linux, this can easily happen for good or bad reasons. Hence,
> use this opportunity to explain why this might happen, hopefully some
> people then will be less disappointed if it happens.
> 
> Signed-off-by: Thorsten Leemhuis 
> ---
>  Documentation/admin-guide/reporting-bugs.rst | 56 
>  1 file changed, 56 insertions(+)
> 
> diff --git a/Documentation/admin-guide/reporting-bugs.rst 
> b/Documentation/admin-guide/reporting-bugs.rst
> index 340fa44b352c..8f60af27635b 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -1402,6 +1402,62 @@ for the subsystem as well as the stable mailing list 
> the `MAINTAINERS file
>  mention in the section "STABLE BRANCH".
>  
>  
> +Why some issues won't get any reaction or remain unfixed after being reported
> +=
> +
> +When reporting a problem to the Linux developers, be aware only 'issues of 
> high
> +priority' (regression, security issue, severe problems) are definitely going 
> to
> +get resolved. The maintainers or if all else fails Linus Torvalds himself 
> will
> +make sure of that. They and the other kernel developers will fix a lot of 
> other
> +issues as well. But be aware that sometimes they can't or won't help; and
> +sometimes there isn't even anyone to send a report to.
> +
> +This is best explained with kernel developers that contribute to the Linux
> +kernel in their spare time. Quite a few of the drivers in the kernel were
> +written by such programmers, often because they simply wanted to make their
> +hardware usable on their favorite operating system.
> +
> +These programmers most of the time will happily fix problems other people
> +report. But nobody can force them to do, as they are contributing 
> voluntarily.
> +
> +Then there are situations where such developers really want to fix an issue,
> +but can't: they lack hardware programming documentation to do so. This often
> +happens when the publicly available docs are superficial or the driver was
> +written with the help of reverse engineering.
> +
> +Sooner or later spare time developers will also stop caring for the driver.
> +Maybe their test hardware broke, got replaced by something more fancy, or is 
> so
> +old that it's something you don't find much outside of computer museums
> +anymore. Or the developer stops caring for their code and Linux at all, as
> +something different in their life became way more important. Sometimes nobody
> +is willing to take over the job as maintainer – and nobody can be forced to, 
> as
> +contributing to the Linux kernel is done on a voluntary basis. Abandoned
> +drivers nevertheless remain in the kernel: they are still useful for people 
> and
> +removing would be a regression.
> +
> +The situation is not that different with developers that are paid for their
> +work on the Linux kernel. Those contribute most changes these days. But their
> +employers sooner or later also stop caring for some code and make its 
> programmer
> +focus on other thing. Hardware vendors for example earn their money mainly by

 on other things.

> +selling new hardware; quite a few of them hence are not investing much time 
> and
> +energy in maintaining a Linux kernel driver for something they sold years 
> ago.
> +Enterprise Linux distributors often care for a longer time period, but in new
> +version often leave support for old and rare hardware aside to limit the 
> scope.
> +Often spare time contributors take over once a company leaves some orphan 
> some

  drop last: 
some

> +code, but as mentioned above: sooner or later will leave the code behind, 
> too.

   later they will leave the code 
behind, too.

> +
> +Priorities are another reason why some issues are not fixed, as maintainers
> +quite often are forced to set those, as time to work on Linux is limited. 
> That's
> +true for spare time or the time employers grant their developers to spend on
> +maintenance work on the upstream kernel. Sometimes maintainers also get
> +overwhelmed with reports, even if a driver is working nearly perfectly. To 
> not
> +get completely stuck, the programmer thus might have no other choice then to

than to

> +prioritize issue reports and reject some of them.
> +
> 

Please Check this out and reply urgently

[MacDonald]

Attention please!

I am the Chief Financial Officer of Rockhopper and Gas company London UK, and 
by the virtue, as the Chief Financial Officer. I got your contact through a 
directory search and decided to propose this business. I am seeking your 
assistance in remitting of some funds,  Ninety five million  to your account 
for private investment purpose, hence my request for your assistance.
 
  
 SOURCE OF THE FUND:

The fund to be transferred into your account is accrued from an over-invoiced 
contract amount awarded for the completion of the last phase of our refinery, 
valves and depot for storage of product all over our branches here in the UK 
which include laying of  distribution pipelines. The contract which was 
originally valued for One Hundred and Twenty Seven Million was manipulated to 
read, Two Hundred and Twenty Two Million.  The extra, Ninety Five Million, is 
what I want to move to your account, the original contractors who executed the 
job has been paid all their contract bills remaining this Ninety Five Million.
  
 DISBURSEMENT:

I have resolved that you take Forty percent  of the total amount for your 
assistance. that is, fronting you as a sub contractor to claim the remaining 
balance of Ninety Five Million  which is left now in our bank from the over 
invoice contract because it is impossible for me to claim the over invoiced 
amount without your assistance as a Foreign Contractor. In addition Ten percent 
has been mapped out for any miscellaneous expenses that   might be incurred by 
both of us during this business while Fifty percent  will be my own share.

SECURITY:

All modalities to effect the payment and subsequent transfer of this money has 
been worked out, so this transaction is Hundred percent risk free, though you 
are required to treat it with strictest confidence, on our acceptance please 
send to me your personal details and your direct mobile phone number for speedy 
correspondence.
  
I am looking forward to doing business with you. Your prompt reply will be 
highly appreciated. Do kindly furnish me with your contact details if you are 
interested in partnering with me on this transaction.
 
  
Yours Faithfully,

Stewart MacDonald
Chief Financial Officer
Rockhopper Exploration PLC

[RFC PATCH v1 24/26] docs: reporting-bugs: explain why users might get neither reply nor fix

[Thorsten Leemhuis]

Not even getting a reply after one invested quite a bit of time with
preparing and writing a report can be quite devastating. But when it
comes to Linux, this can easily happen for good or bad reasons. Hence,
use this opportunity to explain why this might happen, hopefully some
people then will be less disappointed if it happens.

Signed-off-by: Thorsten Leemhuis 
---
 Documentation/admin-guide/reporting-bugs.rst | 56 
 1 file changed, 56 insertions(+)

diff --git a/Documentation/admin-guide/reporting-bugs.rst 
b/Documentation/admin-guide/reporting-bugs.rst
index 340fa44b352c..8f60af27635b 100644
--- a/Documentation/admin-guide/reporting-bugs.rst
+++ b/Documentation/admin-guide/reporting-bugs.rst
@@ -1402,6 +1402,62 @@ for the subsystem as well as the stable mailing list the 
`MAINTAINERS file
 mention in the section "STABLE BRANCH".
 
 
+Why some issues won't get any reaction or remain unfixed after being reported
+=
+
+When reporting a problem to the Linux developers, be aware only 'issues of high
+priority' (regression, security issue, severe problems) are definitely going to
+get resolved. The maintainers or if all else fails Linus Torvalds himself will
+make sure of that. They and the other kernel developers will fix a lot of other
+issues as well. But be aware that sometimes they can't or won't help; and
+sometimes there isn't even anyone to send a report to.
+
+This is best explained with kernel developers that contribute to the Linux
+kernel in their spare time. Quite a few of the drivers in the kernel were
+written by such programmers, often because they simply wanted to make their
+hardware usable on their favorite operating system.
+
+These programmers most of the time will happily fix problems other people
+report. But nobody can force them to do, as they are contributing voluntarily.
+
+Then there are situations where such developers really want to fix an issue,
+but can't: they lack hardware programming documentation to do so. This often
+happens when the publicly available docs are superficial or the driver was
+written with the help of reverse engineering.
+
+Sooner or later spare time developers will also stop caring for the driver.
+Maybe their test hardware broke, got replaced by something more fancy, or is so
+old that it's something you don't find much outside of computer museums
+anymore. Or the developer stops caring for their code and Linux at all, as
+something different in their life became way more important. Sometimes nobody
+is willing to take over the job as maintainer ??? and nobody can be forced to, 
as
+contributing to the Linux kernel is done on a voluntary basis. Abandoned
+drivers nevertheless remain in the kernel: they are still useful for people and
+removing would be a regression.
+
+The situation is not that different with developers that are paid for their
+work on the Linux kernel. Those contribute most changes these days. But their
+employers sooner or later also stop caring for some code and make its 
programmer
+focus on other thing. Hardware vendors for example earn their money mainly by
+selling new hardware; quite a few of them hence are not investing much time and
+energy in maintaining a Linux kernel driver for something they sold years ago.
+Enterprise Linux distributors often care for a longer time period, but in new
+version often leave support for old and rare hardware aside to limit the scope.
+Often spare time contributors take over once a company leaves some orphan some
+code, but as mentioned above: sooner or later will leave the code behind, too.
+
+Priorities are another reason why some issues are not fixed, as maintainers
+quite often are forced to set those, as time to work on Linux is limited. 
That's
+true for spare time or the time employers grant their developers to spend on
+maintenance work on the upstream kernel. Sometimes maintainers also get
+overwhelmed with reports, even if a driver is working nearly perfectly. To not
+get completely stuck, the programmer thus might have no other choice then to
+prioritize issue reports and reject some of them.
+
+But don't worry too much about all of this, a lot of drivers have active
+maintainers who are quite interested in fixing as many issues as possible.
+
+
 .. 
 .. Temporary marker added while this document is rewritten. Sections above
 .. are new and dual-licensed under GPLv2+ and CC-BY 4.0, those below are old.
-- 
2.26.2

KINDLY REPLY....

[patriciagarrido]

I am very happy to contact you for this business transaction.Please
kindly get back to me via this email: mrchenhk...@gmail.com for us to achieve 
success and secure a good future for our families.

[PATCH v7 4/4] input: elants: support 0x66 reply opcode for reporting touches

[Michał Mirosław]

From: Dmitry Osipenko 

eKTF3624 touchscreen firmware uses two variants of the reply opcodes for
reporting touch events: one is 0x63 (used by older firmware) and other is
0x66 (used by newer firmware). The 0x66 variant is equal to 0x63 of
eKTH3500, while 0x63 needs small adjustment of the touch pressure value.

Nexus 7 tablet device has eKTF3624 touchscreen and it uses 0x66 opcode for
reporting touch events, let's support it now. Other devices, eg. ASUS TF300T,
use 0x63.

Note: CMD_HEADER_REK is used for replying to calibration requests, it has
the same 0x66 opcode number which eKTF3624 uses for reporting touches.
The calibration replies are handled separately from the the rest of the
commands in the driver by entering into ELAN_WAIT_RECALIBRATION state
and thus this change shouldn't change the old behavior.

Signed-off-by: Dmitry Osipenko 
Tested-by: Michał Mirosław 
Signed-off-by: Michał Mirosław 
---
 drivers/input/touchscreen/elants_i2c.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index c24d8cdc4251..1cbda6f20d07 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -61,6 +61,15 @@
 #define QUEUE_HEADER_NORMAL0X63
 #define QUEUE_HEADER_WAIT  0x64
 
+/*
+ * Depending on firmware version, eKTF3624 touchscreens may utilize one of
+ * these opcodes for the touch events: 0x63 and 0x66. The 0x63 is used by
+ * older firmware version and differs from 0x66 such that touch pressure
+ * value needs to be adjusted. The 0x66 opcode of newer firmware is equal
+ * to 0x63 of eKTH3500.
+ */
+#define QUEUE_HEADER_NORMAL2   0x66
+
 /* Command header definition */
 #define CMD_HEADER_WRITE   0x54
 #define CMD_HEADER_READ0x53
@@ -1052,7 +1061,6 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
switch (ts->buf[FW_HDR_TYPE]) {
case CMD_HEADER_HELLO:
case CMD_HEADER_RESP:
-   case CMD_HEADER_REK:
break;
 
case QUEUE_HEADER_WAIT:
@@ -1072,6 +1080,7 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
break;
 
case QUEUE_HEADER_NORMAL:
+   case QUEUE_HEADER_NORMAL2:
report_count = ts->buf[FW_HDR_COUNT];
if (report_count == 0 || report_count > 3) {
dev_err(>dev,
-- 
2.20.1

Re: [PATCH net] ethtool: add and use message type for tunnel info reply

[David Miller]

From: Michal Kubecek 
Date: Thu, 17 Sep 2020 01:04:10 +0200 (CEST)

> Tunnel offload info code uses ETHTOOL_MSG_TUNNEL_INFO_GET message type (cmd
> field in genetlink header) for replies to tunnel info netlink request, i.e.
> the same value as the request have. This is a problem because we are using
> two separate enums for userspace to kernel and kernel to userspace message
> types so that this ETHTOOL_MSG_TUNNEL_INFO_GET (28) collides with
> ETHTOOL_MSG_CABLE_TEST_TDR_NTF which is what message type 28 means for
> kernel to userspace messages.
> 
> As the tunnel info request reached mainline in 5.9 merge window, we should
> still be able to fix the reply message type without breaking backward
> compatibility.
> 
> Fixes: c7d759eb7b12 ("ethtool: add tunnel info interface")
> Signed-off-by: Michal Kubecek 

Applied, thank you.