Please reply to me

2021-04-14 Thread 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

2021-04-12 Thread Greg Kroah-Hartman
_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; - zon

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

2021-04-12 Thread 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

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

2021-04-12 Thread 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

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

2021-04-12 Thread Greg Kroah-Hartman
_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; - zon

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

2021-04-12 Thread 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

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

2021-04-12 Thread 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

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

2021-04-12 Thread Greg Kroah-Hartman
_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; - zon

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

2021-04-07 Thread 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 elapse

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

2021-04-07 Thread 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 pe

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

2021-04-05 Thread patchwork-bot+netdevbpf
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/n

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

2021-04-04 Thread Tonghao Zhang
itch/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, > >

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

2021-04-04 Thread Ilya Maximets
tr > *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

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

2021-04-04 Thread Ilya Maximets
285 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 *repl

REPLY ME URGENTLY

2021-04-01 Thread Elizabeth Edward
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

2021-03-29 Thread 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.

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

2021-03-29 Thread 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.

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

2021-03-29 Thread 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.

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

2021-03-29 Thread 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.

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

2021-03-29 Thread 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.

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

2021-03-29 Thread 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.

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

2021-03-29 Thread 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.

REPLY ME URGENTLY

2021-03-20 Thread Mrs. Elizabeth Edward
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"

2021-03-17 Thread Sargun Dhillon
ags; /* 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_a

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

2021-03-16 Thread 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.

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

2021-03-16 Thread 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.

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

2021-03-16 Thread 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.

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

2021-03-16 Thread 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.

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

2021-03-16 Thread 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.

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

2021-03-16 Thread 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.

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

2021-03-16 Thread 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.

TREAT AND REPLY URGENTLY.

2021-03-13 Thread 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 s

TREAT AND REPLY URGENTLY.

2021-03-12 Thread 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 cam

TREAT AND REPLY URGENTLY.

2021-03-07 Thread 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 s

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

2021-03-05 Thread 李晨阳
> > +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); > > +} >

TREAT AND REPLY URGENTLY.

2021-02-26 Thread 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 s

REPLY ME URGENTLY

2021-02-13 Thread Mrs. Elizabeth Edward
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

2021-02-12 Thread 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 questi

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

2021-02-12 Thread 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 checke

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

2021-02-11 Thread 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

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

2021-02-11 Thread 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: WARNI

REPLY ME URGENTLY

2021-02-08 Thread Elizabeth Edward
y. 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

2021-02-02 Thread 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

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

2021-01-30 Thread 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

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

2021-01-30 Thread 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

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

2021-01-29 Thread 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

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

2021-01-18 Thread 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

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

2021-01-17 Thread 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

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

2021-01-17 Thread 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 id

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

2021-01-16 Thread 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

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

2021-01-16 Thread 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 applie

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

2021-01-11 Thread 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

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

2021-01-11 Thread 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 th

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

2021-01-10 Thread 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 u

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

2021-01-09 Thread 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 accor

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

2021-01-06 Thread 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_IN

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

2021-01-06 Thread 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: > > > > > > >

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

2021-01-06 Thread 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 com

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

2021-01-06 Thread 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 cal

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

2021-01-06 Thread 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 (

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

2021-01-05 Thread 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 m

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

2020-12-28 Thread Greg Kroah-Hartman
hdr.replen + op_decode_hdr_maxsz; + encode_getdeviceinfo(xdr, args, &hdr); - /* 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 +* page

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

2020-12-28 Thread Greg Kroah-Hartman
hdr.replen + op_decode_hdr_maxsz; + encode_getdeviceinfo(xdr, args, &hdr); - /* 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 +* page

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

2020-12-28 Thread 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

REPLY ME URGENTLY

2020-12-22 Thread Mrs. Elizabeth Edward
will appreciate your utmost confidentiality as I wait for your reply. Best Regards Mrs. Elizabeth Edward

URGENT REPLY IS NEEDED FROM YOU

2020-12-15 Thread 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 Ban

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

2020-12-14 Thread John Galvan
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

2020-12-10 Thread 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

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

2020-12-10 Thread 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

TREAT AND REPLY URGENTLY.

2020-12-07 Thread 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

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

2020-12-04 Thread Finn Thain
ning 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 co

Greetings please Reply asap

2020-12-04 Thread 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 forei

REPLY ME URGENTLY

2020-12-04 Thread Elizabeth Edward
y. 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

2020-12-04 Thread 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 d

URGENT REPLY.

2020-12-03 Thread 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 (BO

REPLY ME URGENTLY

2020-11-26 Thread Mrs. Elizabeth Edward
will appreciate your utmost confidentiality as I wait for your reply. Best Regards Mrs. Elizabeth Edward

Please reply to me

2020-11-25 Thread 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.

2020-11-23 Thread 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

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

2020-11-19 Thread 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

REPLY ME URGENTLY

2020-11-14 Thread Elizabeth Edward
y. 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

2020-11-12 Thread 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

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

2020-11-09 Thread 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

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

2020-11-02 Thread 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

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

2020-11-02 Thread 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 error

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

2020-10-29 Thread 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

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

2020-10-29 Thread 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&qu

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

2020-10-29 Thread 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

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

2020-10-28 Thread 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

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

2020-10-24 Thread 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

Reply

2020-10-20 Thread 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

TREAT AS URGENT/ REPLY FOR MORE DETAILS

2020-10-19 Thread 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

REPLY ME IMMEDIATELY

2020-10-06 Thread 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 he

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

2020-10-04 Thread 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 st

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

2020-10-03 Thread 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: >>

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

2020-10-03 Thread 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

Please Check this out and reply urgently

2020-10-03 Thread MacDonald
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

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

2020-10-01 Thread 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

KINDLY REPLY....

2020-09-24 Thread 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

2020-09-19 Thread 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

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

2020-09-17 Thread David Miller
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.

  1   2   3   4   5   6   7   >