Please respond urgently

[Ahmed Hassan]

Greetings,

With due respect to your person, I make this contact with you as I
believe that you can be of great assistance to me. I need your urgent
assistance in transferring the sum of $11.3 million USD to your
private account Where this money can be shared between us.

The money has been here in our Bank lying dormant for years now
without anybody coming for the claim. I want to release the money to
you as the relative to our deceased customer (the account owner) who
died in a plane crash with his family on 16th October 2005.

By indicating your interest I will send you the full details on how
the business will be executed.

Best Regards,
Ahmed Hassan

Re: [PATCH v2] hwmon: (sbtsi) Don't read sensor more than once if it doesn't respond

[Guenter Roeck]

On 4/6/21 3:25 PM, Konstantin Aladyshev wrote:
> What I'm trying to say, shouldn't the call
> "i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG)" be
> surrounded with the "mutex_lock/mutex_unlock" like it is done for the
> others "i2c_smbus_read_byte_data" calls?
> Something like:
> ```
> mutex_lock(>lock);
> err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
> if (err < 0)
> return err;
> mutex_unlock(>lock);
> ```
> Because it is not surrounded with the mutex lock/unlock in the original 
> driver.
> 

Why would that be necessary ? My understanding is that the returned value
is read-only and won't change. FWIW, I don't even understand why it is
read more than once to start with.

On a side note, the above code would leave the mutex locked on error.

Guenter

> Best regards,
> Konstantin Aladyshev
> 
> 
> On Wed, Apr 7, 2021 at 12:34 AM Guenter Roeck  wrote:
>>
>> On 4/6/21 2:09 PM, Konstantin Aladyshev wrote:
>>> Thanks for the answer!
>>> Sorry for the confusion, by the "CPU is off" I meant "CPU is present,
>>> but currently it is in the powered off state".
>>> Therefore it is not possible to put these checks only in a probe
>>> function. And I don't know either if it is a good idea to cache
>>> config/min/max values.
>>>
>>> I use this driver on an OpenBMC system, which uses other software
>>> rather than lm-sensors utility. I guess that is why my priorities are
>>> shifted.
>>>
>>> By the way, I've noticed that the mutex check is absent in a
>>> SBTSI_REG_CONFIG read call both in the original driver version and in
>>> my patch, is this an error?
>>>
>>
>> What do you mean with "mutex check" ?
>>
>> Thanks,
>> Guenter
>>
>>
>>> Best regards,
>>> Konstantin Aladyshev
>>>
>>>
>>> On Tue, Apr 6, 2021 at 11:09 PM Guenter Roeck  wrote:

 On 4/6/21 12:20 PM, Konstantin Aladyshev wrote:
> Thanks for the comment.
> Yes, you are correct, this patch adds an extra 'i2c_smbus_read_byte_data' 
> call for the temp_max/temp_min reads.
> I guess I did that intentionally because I just wanted to keep the 
> restructured code concise. After all I thought, 'temp_input' generally is 
> read more often than 'temp_max/temp_min'.
> As I understand now, it seems like it is not acceptable. Therefore could 
> you point me in the right direction about what I should do?
> Should I just stick with the original driver version and simply add two 
> more i2c call checks for the first operations for min/max?
>

 Correct, it is not acceptable. A normal use case for hwmon devices is to 
 use the "sensors"
 command which _will_ read all attributes. i2c reads are expensive, and 
 unnecessary read
 operations should be avoided.

 There are several ways to solve the problem. Checking return values after 
 each
 read is the simple option. There are other possibilities, such as reading 
 the limits
 and the read order only once during probe, but I don't know enough about 
 the
 hardware to suggest a more sophisticated solution. For example, I don't 
 know
 what "CPU is off" means. Offline ? Not present ? If it means "not present",
 or if the status is permanent, the condition should be handled in the 
 is_visible
 function (or the driver should not be instantiated in the first place).
 Otherwise, the code should possibly return -ENODATA instead of -ETIMEDOUT
 on error. But, again, I can not really suggest a better solution since
 I don't know enough (nothing, actually) about the hardware (and the public
 part of the SBTSI specification doesn't say anything about expected 
 behavior
 for offline CPUs or CPU cores).

 What I did find, though, is that the driver does not implement temperature
 offset support, and it that doesn't support reporting alerts. I'd have 
 assumed
 this to be more important than optimizing error handling, but that is just
 my personal opinion.

 Thanks,
 Guenter

> Best regards,
> Konstantin Aladyshev
>
>
> On Tue, Apr 6, 2021 at 9:42 PM Guenter Roeck  > wrote:
>
> On 4/6/21 11:16 AM, Konstantin Aladyshev wrote:
> > SBTSI sensors don't work when the CPU is off.
> > In this case every 'i2c_smbus_read_byte_data' function would fail
> > by a timeout.
> > Currently temp1_max/temp1_min file reads can cause two such timeouts
> > for every read.
> > Restructure code so there will be no more than one timeout for every
> > read operation.
> >
> > Signed-off-by: Konstantin Aladyshev  >
> > ---
> > Changes in v2:
> >   - Fix typo in a commit message
> >   - Don't swap temp_int/temp_dec checks at the end of the 
> 'sbtsi_read' function
> >
>
> This doesn't explain the reason for the extra read 

Re: [PATCH v2] hwmon: (sbtsi) Don't read sensor more than once if it doesn't respond

[Konstantin Aladyshev]

What I'm trying to say, shouldn't the call
"i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG)" be
surrounded with the "mutex_lock/mutex_unlock" like it is done for the
others "i2c_smbus_read_byte_data" calls?
Something like:
```
mutex_lock(>lock);
err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
if (err < 0)
return err;
mutex_unlock(>lock);
```
Because it is not surrounded with the mutex lock/unlock in the original driver.

Best regards,
Konstantin Aladyshev


On Wed, Apr 7, 2021 at 12:34 AM Guenter Roeck  wrote:
>
> On 4/6/21 2:09 PM, Konstantin Aladyshev wrote:
> > Thanks for the answer!
> > Sorry for the confusion, by the "CPU is off" I meant "CPU is present,
> > but currently it is in the powered off state".
> > Therefore it is not possible to put these checks only in a probe
> > function. And I don't know either if it is a good idea to cache
> > config/min/max values.
> >
> > I use this driver on an OpenBMC system, which uses other software
> > rather than lm-sensors utility. I guess that is why my priorities are
> > shifted.
> >
> > By the way, I've noticed that the mutex check is absent in a
> > SBTSI_REG_CONFIG read call both in the original driver version and in
> > my patch, is this an error?
> >
>
> What do you mean with "mutex check" ?
>
> Thanks,
> Guenter
>
>
> > Best regards,
> > Konstantin Aladyshev
> >
> >
> > On Tue, Apr 6, 2021 at 11:09 PM Guenter Roeck  wrote:
> >>
> >> On 4/6/21 12:20 PM, Konstantin Aladyshev wrote:
> >>> Thanks for the comment.
> >>> Yes, you are correct, this patch adds an extra 'i2c_smbus_read_byte_data' 
> >>> call for the temp_max/temp_min reads.
> >>> I guess I did that intentionally because I just wanted to keep the 
> >>> restructured code concise. After all I thought, 'temp_input' generally is 
> >>> read more often than 'temp_max/temp_min'.
> >>> As I understand now, it seems like it is not acceptable. Therefore could 
> >>> you point me in the right direction about what I should do?
> >>> Should I just stick with the original driver version and simply add two 
> >>> more i2c call checks for the first operations for min/max?
> >>>
> >>
> >> Correct, it is not acceptable. A normal use case for hwmon devices is to 
> >> use the "sensors"
> >> command which _will_ read all attributes. i2c reads are expensive, and 
> >> unnecessary read
> >> operations should be avoided.
> >>
> >> There are several ways to solve the problem. Checking return values after 
> >> each
> >> read is the simple option. There are other possibilities, such as reading 
> >> the limits
> >> and the read order only once during probe, but I don't know enough about 
> >> the
> >> hardware to suggest a more sophisticated solution. For example, I don't 
> >> know
> >> what "CPU is off" means. Offline ? Not present ? If it means "not present",
> >> or if the status is permanent, the condition should be handled in the 
> >> is_visible
> >> function (or the driver should not be instantiated in the first place).
> >> Otherwise, the code should possibly return -ENODATA instead of -ETIMEDOUT
> >> on error. But, again, I can not really suggest a better solution since
> >> I don't know enough (nothing, actually) about the hardware (and the public
> >> part of the SBTSI specification doesn't say anything about expected 
> >> behavior
> >> for offline CPUs or CPU cores).
> >>
> >> What I did find, though, is that the driver does not implement temperature
> >> offset support, and it that doesn't support reporting alerts. I'd have 
> >> assumed
> >> this to be more important than optimizing error handling, but that is just
> >> my personal opinion.
> >>
> >> Thanks,
> >> Guenter
> >>
> >>> Best regards,
> >>> Konstantin Aladyshev
> >>>
> >>>
> >>> On Tue, Apr 6, 2021 at 9:42 PM Guenter Roeck  >>> > wrote:
> >>>
> >>> On 4/6/21 11:16 AM, Konstantin Aladyshev wrote:
> >>> > SBTSI sensors don't work when the CPU is off.
> >>> > In this case every 'i2c_smbus_read_byte_data' function would fail
> >>> > by a timeout.
> >>> > Currently temp1_max/temp1_min file reads can cause two such timeouts
> >>> > for every read.
> >>> > Restructure code so there will be no more than one timeout for every
> >>> > read operation.
> >>> >
> >>> > Signed-off-by: Konstantin Aladyshev  >>> >
> >>> > ---
> >>> > Changes in v2:
> >>> >   - Fix typo in a commit message
> >>> >   - Don't swap temp_int/temp_dec checks at the end of the 
> >>> 'sbtsi_read' function
> >>> >
> >>>
> >>> This doesn't explain the reason for the extra read operation for
> >>> limits. Preventing a second read in error cases is not an argument
> >>> for adding an extra read for non-error cases.
> >>>
> >>> Guenter
> >>>
> >>> >  drivers/hwmon/sbtsi_temp.c | 55 
> >>> +++---
> >>> >  1 file changed, 27 insertions(+), 28 deletions(-)
> >>> >
> >>> > diff 

Re: [PATCH v2] hwmon: (sbtsi) Don't read sensor more than once if it doesn't respond

[Guenter Roeck]

On 4/6/21 2:09 PM, Konstantin Aladyshev wrote:
> Thanks for the answer!
> Sorry for the confusion, by the "CPU is off" I meant "CPU is present,
> but currently it is in the powered off state".
> Therefore it is not possible to put these checks only in a probe
> function. And I don't know either if it is a good idea to cache
> config/min/max values.
> 
> I use this driver on an OpenBMC system, which uses other software
> rather than lm-sensors utility. I guess that is why my priorities are
> shifted.
> 
> By the way, I've noticed that the mutex check is absent in a
> SBTSI_REG_CONFIG read call both in the original driver version and in
> my patch, is this an error?
> 

What do you mean with "mutex check" ?

Thanks,
Guenter


> Best regards,
> Konstantin Aladyshev
> 
> 
> On Tue, Apr 6, 2021 at 11:09 PM Guenter Roeck  wrote:
>>
>> On 4/6/21 12:20 PM, Konstantin Aladyshev wrote:
>>> Thanks for the comment.
>>> Yes, you are correct, this patch adds an extra 'i2c_smbus_read_byte_data' 
>>> call for the temp_max/temp_min reads.
>>> I guess I did that intentionally because I just wanted to keep the 
>>> restructured code concise. After all I thought, 'temp_input' generally is 
>>> read more often than 'temp_max/temp_min'.
>>> As I understand now, it seems like it is not acceptable. Therefore could 
>>> you point me in the right direction about what I should do?
>>> Should I just stick with the original driver version and simply add two 
>>> more i2c call checks for the first operations for min/max?
>>>
>>
>> Correct, it is not acceptable. A normal use case for hwmon devices is to use 
>> the "sensors"
>> command which _will_ read all attributes. i2c reads are expensive, and 
>> unnecessary read
>> operations should be avoided.
>>
>> There are several ways to solve the problem. Checking return values after 
>> each
>> read is the simple option. There are other possibilities, such as reading 
>> the limits
>> and the read order only once during probe, but I don't know enough about the
>> hardware to suggest a more sophisticated solution. For example, I don't know
>> what "CPU is off" means. Offline ? Not present ? If it means "not present",
>> or if the status is permanent, the condition should be handled in the 
>> is_visible
>> function (or the driver should not be instantiated in the first place).
>> Otherwise, the code should possibly return -ENODATA instead of -ETIMEDOUT
>> on error. But, again, I can not really suggest a better solution since
>> I don't know enough (nothing, actually) about the hardware (and the public
>> part of the SBTSI specification doesn't say anything about expected behavior
>> for offline CPUs or CPU cores).
>>
>> What I did find, though, is that the driver does not implement temperature
>> offset support, and it that doesn't support reporting alerts. I'd have 
>> assumed
>> this to be more important than optimizing error handling, but that is just
>> my personal opinion.
>>
>> Thanks,
>> Guenter
>>
>>> Best regards,
>>> Konstantin Aladyshev
>>>
>>>
>>> On Tue, Apr 6, 2021 at 9:42 PM Guenter Roeck >> > wrote:
>>>
>>> On 4/6/21 11:16 AM, Konstantin Aladyshev wrote:
>>> > SBTSI sensors don't work when the CPU is off.
>>> > In this case every 'i2c_smbus_read_byte_data' function would fail
>>> > by a timeout.
>>> > Currently temp1_max/temp1_min file reads can cause two such timeouts
>>> > for every read.
>>> > Restructure code so there will be no more than one timeout for every
>>> > read operation.
>>> >
>>> > Signed-off-by: Konstantin Aladyshev >> >
>>> > ---
>>> > Changes in v2:
>>> >   - Fix typo in a commit message
>>> >   - Don't swap temp_int/temp_dec checks at the end of the 
>>> 'sbtsi_read' function
>>> >
>>>
>>> This doesn't explain the reason for the extra read operation for
>>> limits. Preventing a second read in error cases is not an argument
>>> for adding an extra read for non-error cases.
>>>
>>> Guenter
>>>
>>> >  drivers/hwmon/sbtsi_temp.c | 55 
>>> +++---
>>> >  1 file changed, 27 insertions(+), 28 deletions(-)
>>> >
>>> > diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
>>> > index e35357c48b8e..4ae48635bb31 100644
>>> > --- a/drivers/hwmon/sbtsi_temp.c
>>> > +++ b/drivers/hwmon/sbtsi_temp.c
>>> > @@ -74,48 +74,47 @@ static int sbtsi_read(struct device *dev, enum 
>>> hwmon_sensor_types type,
>>> > u32 attr, int channel, long *val)
>>> >  {
>>> >   struct sbtsi_data *data = dev_get_drvdata(dev);
>>> > + u8 temp_int_reg, temp_dec_reg;
>>> >   s32 temp_int, temp_dec;
>>> >   int err;
>>> >
>>> >   switch (attr) {
>>> >   case hwmon_temp_input:
>>> > - /*
>>> > -  * ReadOrder bit specifies the reading order of integer 
>>> and
>>> > -   

Re: [PATCH v2] hwmon: (sbtsi) Don't read sensor more than once if it doesn't respond

[Konstantin Aladyshev]

Thanks for the answer!
Sorry for the confusion, by the "CPU is off" I meant "CPU is present,
but currently it is in the powered off state".
Therefore it is not possible to put these checks only in a probe
function. And I don't know either if it is a good idea to cache
config/min/max values.

I use this driver on an OpenBMC system, which uses other software
rather than lm-sensors utility. I guess that is why my priorities are
shifted.

By the way, I've noticed that the mutex check is absent in a
SBTSI_REG_CONFIG read call both in the original driver version and in
my patch, is this an error?

Best regards,
Konstantin Aladyshev


On Tue, Apr 6, 2021 at 11:09 PM Guenter Roeck  wrote:
>
> On 4/6/21 12:20 PM, Konstantin Aladyshev wrote:
> > Thanks for the comment.
> > Yes, you are correct, this patch adds an extra 'i2c_smbus_read_byte_data' 
> > call for the temp_max/temp_min reads.
> > I guess I did that intentionally because I just wanted to keep the 
> > restructured code concise. After all I thought, 'temp_input' generally is 
> > read more often than 'temp_max/temp_min'.
> > As I understand now, it seems like it is not acceptable. Therefore could 
> > you point me in the right direction about what I should do?
> > Should I just stick with the original driver version and simply add two 
> > more i2c call checks for the first operations for min/max?
> >
>
> Correct, it is not acceptable. A normal use case for hwmon devices is to use 
> the "sensors"
> command which _will_ read all attributes. i2c reads are expensive, and 
> unnecessary read
> operations should be avoided.
>
> There are several ways to solve the problem. Checking return values after each
> read is the simple option. There are other possibilities, such as reading the 
> limits
> and the read order only once during probe, but I don't know enough about the
> hardware to suggest a more sophisticated solution. For example, I don't know
> what "CPU is off" means. Offline ? Not present ? If it means "not present",
> or if the status is permanent, the condition should be handled in the 
> is_visible
> function (or the driver should not be instantiated in the first place).
> Otherwise, the code should possibly return -ENODATA instead of -ETIMEDOUT
> on error. But, again, I can not really suggest a better solution since
> I don't know enough (nothing, actually) about the hardware (and the public
> part of the SBTSI specification doesn't say anything about expected behavior
> for offline CPUs or CPU cores).
>
> What I did find, though, is that the driver does not implement temperature
> offset support, and it that doesn't support reporting alerts. I'd have assumed
> this to be more important than optimizing error handling, but that is just
> my personal opinion.
>
> Thanks,
> Guenter
>
> > Best regards,
> > Konstantin Aladyshev
> >
> >
> > On Tue, Apr 6, 2021 at 9:42 PM Guenter Roeck  > > wrote:
> >
> > On 4/6/21 11:16 AM, Konstantin Aladyshev wrote:
> > > SBTSI sensors don't work when the CPU is off.
> > > In this case every 'i2c_smbus_read_byte_data' function would fail
> > > by a timeout.
> > > Currently temp1_max/temp1_min file reads can cause two such timeouts
> > > for every read.
> > > Restructure code so there will be no more than one timeout for every
> > > read operation.
> > >
> > > Signed-off-by: Konstantin Aladyshev  > >
> > > ---
> > > Changes in v2:
> > >   - Fix typo in a commit message
> > >   - Don't swap temp_int/temp_dec checks at the end of the 
> > 'sbtsi_read' function
> > >
> >
> > This doesn't explain the reason for the extra read operation for
> > limits. Preventing a second read in error cases is not an argument
> > for adding an extra read for non-error cases.
> >
> > Guenter
> >
> > >  drivers/hwmon/sbtsi_temp.c | 55 
> > +++---
> > >  1 file changed, 27 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
> > > index e35357c48b8e..4ae48635bb31 100644
> > > --- a/drivers/hwmon/sbtsi_temp.c
> > > +++ b/drivers/hwmon/sbtsi_temp.c
> > > @@ -74,48 +74,47 @@ static int sbtsi_read(struct device *dev, enum 
> > hwmon_sensor_types type,
> > > u32 attr, int channel, long *val)
> > >  {
> > >   struct sbtsi_data *data = dev_get_drvdata(dev);
> > > + u8 temp_int_reg, temp_dec_reg;
> > >   s32 temp_int, temp_dec;
> > >   int err;
> > >
> > >   switch (attr) {
> > >   case hwmon_temp_input:
> > > - /*
> > > -  * ReadOrder bit specifies the reading order of integer 
> > and
> > > -  * decimal part of CPU temp for atomic reads. If bit == 
> > 0,
> > > -  * reading integer part triggers latching of the 
> > decimal part,
> > > -  * 

Re: [PATCH v2] hwmon: (sbtsi) Don't read sensor more than once if it doesn't respond

[Guenter Roeck]

On 4/6/21 12:20 PM, Konstantin Aladyshev wrote:
> Thanks for the comment.
> Yes, you are correct, this patch adds an extra 'i2c_smbus_read_byte_data' 
> call for the temp_max/temp_min reads.
> I guess I did that intentionally because I just wanted to keep the 
> restructured code concise. After all I thought, 'temp_input' generally is 
> read more often than 'temp_max/temp_min'.
> As I understand now, it seems like it is not acceptable. Therefore could you 
> point me in the right direction about what I should do?
> Should I just stick with the original driver version and simply add two more 
> i2c call checks for the first operations for min/max?
> 

Correct, it is not acceptable. A normal use case for hwmon devices is to use 
the "sensors"
command which _will_ read all attributes. i2c reads are expensive, and 
unnecessary read
operations should be avoided.

There are several ways to solve the problem. Checking return values after each
read is the simple option. There are other possibilities, such as reading the 
limits
and the read order only once during probe, but I don't know enough about the
hardware to suggest a more sophisticated solution. For example, I don't know
what "CPU is off" means. Offline ? Not present ? If it means "not present",
or if the status is permanent, the condition should be handled in the is_visible
function (or the driver should not be instantiated in the first place).
Otherwise, the code should possibly return -ENODATA instead of -ETIMEDOUT
on error. But, again, I can not really suggest a better solution since
I don't know enough (nothing, actually) about the hardware (and the public
part of the SBTSI specification doesn't say anything about expected behavior
for offline CPUs or CPU cores).

What I did find, though, is that the driver does not implement temperature
offset support, and it that doesn't support reporting alerts. I'd have assumed
this to be more important than optimizing error handling, but that is just
my personal opinion.

Thanks,
Guenter

> Best regards,
> Konstantin Aladyshev
> 
> 
> On Tue, Apr 6, 2021 at 9:42 PM Guenter Roeck  > wrote:
> 
> On 4/6/21 11:16 AM, Konstantin Aladyshev wrote:
> > SBTSI sensors don't work when the CPU is off.
> > In this case every 'i2c_smbus_read_byte_data' function would fail
> > by a timeout.
> > Currently temp1_max/temp1_min file reads can cause two such timeouts
> > for every read.
> > Restructure code so there will be no more than one timeout for every
> > read operation.
> >
> > Signed-off-by: Konstantin Aladyshev  >
> > ---
> > Changes in v2:
> >   - Fix typo in a commit message
> >   - Don't swap temp_int/temp_dec checks at the end of the 'sbtsi_read' 
> function
> >
> 
> This doesn't explain the reason for the extra read operation for
> limits. Preventing a second read in error cases is not an argument
> for adding an extra read for non-error cases.
> 
> Guenter
> 
> >  drivers/hwmon/sbtsi_temp.c | 55 +++---
> >  1 file changed, 27 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
> > index e35357c48b8e..4ae48635bb31 100644
> > --- a/drivers/hwmon/sbtsi_temp.c
> > +++ b/drivers/hwmon/sbtsi_temp.c
> > @@ -74,48 +74,47 @@ static int sbtsi_read(struct device *dev, enum 
> hwmon_sensor_types type,
> >                     u32 attr, int channel, long *val)
> >  {
> >       struct sbtsi_data *data = dev_get_drvdata(dev);
> > +     u8 temp_int_reg, temp_dec_reg;
> >       s32 temp_int, temp_dec;
> >       int err;
> > 
> >       switch (attr) {
> >       case hwmon_temp_input:
> > -             /*
> > -              * ReadOrder bit specifies the reading order of integer 
> and
> > -              * decimal part of CPU temp for atomic reads. If bit == 0,
> > -              * reading integer part triggers latching of the decimal 
> part,
> > -              * so integer part should be read first. If bit == 1, read
> > -              * order should be reversed.
> > -              */
> > -             err = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_CONFIG);
> > -             if (err < 0)
> > -                     return err;
> > -
> > -             mutex_lock(>lock);
> > -             if (err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT)) {
> > -                     temp_dec = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_DEC);
> > -                     temp_int = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_INT);
> > -             } else {
> > -                     temp_int = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_INT);
> > -                     temp_dec = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_DEC);
> > -          

Re: [PATCH v2] hwmon: (sbtsi) Don't read sensor more than once if it doesn't respond

[Guenter Roeck]

On 4/6/21 11:16 AM, Konstantin Aladyshev wrote:
> SBTSI sensors don't work when the CPU is off.
> In this case every 'i2c_smbus_read_byte_data' function would fail
> by a timeout.
> Currently temp1_max/temp1_min file reads can cause two such timeouts
> for every read.
> Restructure code so there will be no more than one timeout for every
> read operation.
> 
> Signed-off-by: Konstantin Aladyshev 
> ---
> Changes in v2:
>   - Fix typo in a commit message
>   - Don't swap temp_int/temp_dec checks at the end of the 'sbtsi_read' 
> function
> 

This doesn't explain the reason for the extra read operation for
limits. Preventing a second read in error cases is not an argument
for adding an extra read for non-error cases.

Guenter

>  drivers/hwmon/sbtsi_temp.c | 55 +++---
>  1 file changed, 27 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
> index e35357c48b8e..4ae48635bb31 100644
> --- a/drivers/hwmon/sbtsi_temp.c
> +++ b/drivers/hwmon/sbtsi_temp.c
> @@ -74,48 +74,47 @@ static int sbtsi_read(struct device *dev, enum 
> hwmon_sensor_types type,
> u32 attr, int channel, long *val)
>  {
>   struct sbtsi_data *data = dev_get_drvdata(dev);
> + u8 temp_int_reg, temp_dec_reg;
>   s32 temp_int, temp_dec;
>   int err;
>  
>   switch (attr) {
>   case hwmon_temp_input:
> - /*
> -  * ReadOrder bit specifies the reading order of integer and
> -  * decimal part of CPU temp for atomic reads. If bit == 0,
> -  * reading integer part triggers latching of the decimal part,
> -  * so integer part should be read first. If bit == 1, read
> -  * order should be reversed.
> -  */
> - err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
> - if (err < 0)
> - return err;
> -
> - mutex_lock(>lock);
> - if (err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT)) {
> - temp_dec = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_DEC);
> - temp_int = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_INT);
> - } else {
> - temp_int = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_INT);
> - temp_dec = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_DEC);
> - }
> - mutex_unlock(>lock);
> + temp_int_reg = SBTSI_REG_TEMP_INT;
> + temp_dec_reg = SBTSI_REG_TEMP_DEC;
>   break;
>   case hwmon_temp_max:
> - mutex_lock(>lock);
> - temp_int = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_HIGH_INT);
> - temp_dec = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_HIGH_DEC);
> - mutex_unlock(>lock);
> + temp_int_reg = SBTSI_REG_TEMP_HIGH_INT;
> + temp_dec_reg = SBTSI_REG_TEMP_HIGH_DEC;
>   break;
>   case hwmon_temp_min:
> - mutex_lock(>lock);
> - temp_int = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_LOW_INT);
> - temp_dec = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_LOW_DEC);
> - mutex_unlock(>lock);
> + temp_int_reg = SBTSI_REG_TEMP_LOW_INT;
> + temp_dec_reg = SBTSI_REG_TEMP_LOW_DEC;
>   break;
>   default:
>   return -EINVAL;
>   }
>  
> + /*
> +  * ReadOrder bit specifies the reading order of integer and
> +  * decimal part of CPU temp for atomic reads. If bit == 0,
> +  * reading integer part triggers latching of the decimal part,
> +  * so integer part should be read first. If bit == 1, read
> +  * order should be reversed.
> +  */
> + err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
> + if (err < 0)
> + return err;
> +
> + mutex_lock(>lock);
> + if (err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT)) {
> + temp_dec = i2c_smbus_read_byte_data(data->client, temp_dec_reg);
> + temp_int = i2c_smbus_read_byte_data(data->client, temp_int_reg);
> + } else {
> + temp_int = i2c_smbus_read_byte_data(data->client, temp_int_reg);
> + temp_dec = i2c_smbus_read_byte_data(data->client, temp_dec_reg);
> + }
> + mutex_unlock(>lock);
>  
>   if (temp_int < 0)
>   return temp_int;
> 

[PATCH v2] hwmon: (sbtsi) Don't read sensor more than once if it doesn't respond

[Konstantin Aladyshev]

SBTSI sensors don't work when the CPU is off.
In this case every 'i2c_smbus_read_byte_data' function would fail
by a timeout.
Currently temp1_max/temp1_min file reads can cause two such timeouts
for every read.
Restructure code so there will be no more than one timeout for every
read operation.

Signed-off-by: Konstantin Aladyshev 
---
Changes in v2:
  - Fix typo in a commit message
  - Don't swap temp_int/temp_dec checks at the end of the 'sbtsi_read' function

 drivers/hwmon/sbtsi_temp.c | 55 +++---
 1 file changed, 27 insertions(+), 28 deletions(-)

diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
index e35357c48b8e..4ae48635bb31 100644
--- a/drivers/hwmon/sbtsi_temp.c
+++ b/drivers/hwmon/sbtsi_temp.c
@@ -74,48 +74,47 @@ static int sbtsi_read(struct device *dev, enum 
hwmon_sensor_types type,
  u32 attr, int channel, long *val)
 {
struct sbtsi_data *data = dev_get_drvdata(dev);
+   u8 temp_int_reg, temp_dec_reg;
s32 temp_int, temp_dec;
int err;
 
switch (attr) {
case hwmon_temp_input:
-   /*
-* ReadOrder bit specifies the reading order of integer and
-* decimal part of CPU temp for atomic reads. If bit == 0,
-* reading integer part triggers latching of the decimal part,
-* so integer part should be read first. If bit == 1, read
-* order should be reversed.
-*/
-   err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
-   if (err < 0)
-   return err;
-
-   mutex_lock(>lock);
-   if (err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT)) {
-   temp_dec = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_DEC);
-   temp_int = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_INT);
-   } else {
-   temp_int = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_INT);
-   temp_dec = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_DEC);
-   }
-   mutex_unlock(>lock);
+   temp_int_reg = SBTSI_REG_TEMP_INT;
+   temp_dec_reg = SBTSI_REG_TEMP_DEC;
break;
case hwmon_temp_max:
-   mutex_lock(>lock);
-   temp_int = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_HIGH_INT);
-   temp_dec = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_HIGH_DEC);
-   mutex_unlock(>lock);
+   temp_int_reg = SBTSI_REG_TEMP_HIGH_INT;
+   temp_dec_reg = SBTSI_REG_TEMP_HIGH_DEC;
break;
case hwmon_temp_min:
-   mutex_lock(>lock);
-   temp_int = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_LOW_INT);
-   temp_dec = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_LOW_DEC);
-   mutex_unlock(>lock);
+   temp_int_reg = SBTSI_REG_TEMP_LOW_INT;
+   temp_dec_reg = SBTSI_REG_TEMP_LOW_DEC;
break;
default:
return -EINVAL;
}
 
+   /*
+* ReadOrder bit specifies the reading order of integer and
+* decimal part of CPU temp for atomic reads. If bit == 0,
+* reading integer part triggers latching of the decimal part,
+* so integer part should be read first. If bit == 1, read
+* order should be reversed.
+*/
+   err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
+   if (err < 0)
+   return err;
+
+   mutex_lock(>lock);
+   if (err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT)) {
+   temp_dec = i2c_smbus_read_byte_data(data->client, temp_dec_reg);
+   temp_int = i2c_smbus_read_byte_data(data->client, temp_int_reg);
+   } else {
+   temp_int = i2c_smbus_read_byte_data(data->client, temp_int_reg);
+   temp_dec = i2c_smbus_read_byte_data(data->client, temp_dec_reg);
+   }
+   mutex_unlock(>lock);
 
if (temp_int < 0)
return temp_int;
-- 
2.25.1

Re: [PATCH] hwmon: (sbtsi) Don't read sensor more than once if it doesn't respond

[Guenter Roeck]

On 4/1/21 2:45 PM, Konstantin Aladyshev wrote:
> From: Konstantin Aladyshev 
> 
> SBTSI sensors don't work when the CPU is off.
> In this case every 'i2c_smbus_read_byte_data' function would fail
> by a timeout.
> Currently temp1_max/temp1_min file reads can cause two such timeouts
> for every read.
> Restructure code so there will be no more than one timeout for every
> read opeartion.
> 

operation

> Signed-off-by: Konstantin Aladyshev 
> ---
>  drivers/hwmon/sbtsi_temp.c | 59 +++---
>  1 file changed, 29 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
> index e35357c48b8e..e09a8cf6de45 100644
> --- a/drivers/hwmon/sbtsi_temp.c
> +++ b/drivers/hwmon/sbtsi_temp.c
> @@ -74,53 +74,52 @@ static int sbtsi_read(struct device *dev, enum 
> hwmon_sensor_types type,
> u32 attr, int channel, long *val)
>  {
>   struct sbtsi_data *data = dev_get_drvdata(dev);
> + u8 temp_int_reg, temp_dec_reg;
>   s32 temp_int, temp_dec;
>   int err;
>  
>   switch (attr) {
>   case hwmon_temp_input:
> - /*
> -  * ReadOrder bit specifies the reading order of integer and
> -  * decimal part of CPU temp for atomic reads. If bit == 0,
> -  * reading integer part triggers latching of the decimal part,
> -  * so integer part should be read first. If bit == 1, read
> -  * order should be reversed.
> -  */
> - err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
> - if (err < 0)
> - return err;
> -
> - mutex_lock(>lock);
> - if (err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT)) {
> - temp_dec = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_DEC);
> - temp_int = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_INT);
> - } else {
> - temp_int = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_INT);
> - temp_dec = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_DEC);
> - }
> - mutex_unlock(>lock);
> + temp_int_reg = SBTSI_REG_TEMP_INT;
> + temp_dec_reg = SBTSI_REG_TEMP_DEC;
>   break;
>   case hwmon_temp_max:
> - mutex_lock(>lock);
> - temp_int = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_HIGH_INT);
> - temp_dec = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_HIGH_DEC);
> - mutex_unlock(>lock);
> + temp_int_reg = SBTSI_REG_TEMP_HIGH_INT;
> + temp_dec_reg = SBTSI_REG_TEMP_HIGH_DEC;
>   break;
>   case hwmon_temp_min:
> - mutex_lock(>lock);
> - temp_int = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_LOW_INT);
> - temp_dec = i2c_smbus_read_byte_data(data->client, 
> SBTSI_REG_TEMP_LOW_DEC);
> - mutex_unlock(>lock);
> + temp_int_reg = SBTSI_REG_TEMP_LOW_INT;
> + temp_dec_reg = SBTSI_REG_TEMP_LOW_DEC;
>   break;
>   default:
>   return -EINVAL;
>   }
>  
> + /*
> +  * ReadOrder bit specifies the reading order of integer and
> +  * decimal part of CPU temp for atomic reads. If bit == 0,
> +  * reading integer part triggers latching of the decimal part,
> +  * so integer part should be read first. If bit == 1, read
> +  * order should be reversed.
> +  */
> + err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
> + if (err < 0)
> + return err;
> +

It seems the "fix" is to always execute above code, which presumably
fails if the CPU is off. The downside of this approach is that it forces
an unnecessary extra and unnecessary i2c operation when reading
the limits.

The real fix would be to check for error after each i2c operation,
not only after both operations are complete.

> + mutex_lock(>lock);
> + if (err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT)) {
> + temp_dec = i2c_smbus_read_byte_data(data->client, temp_dec_reg);
> + temp_int = i2c_smbus_read_byte_data(data->client, temp_int_reg);
> + } else {
> + temp_int = i2c_smbus_read_byte_data(data->client, temp_int_reg);
> + temp_dec = i2c_smbus_read_byte_data(data->client, temp_dec_reg);
> + }
> + mutex_unlock(>lock);
>  
> - if (temp_int < 0)
> - return temp_int;
>   if (temp_dec < 0)
>   return temp_dec;
> + if (temp_int < 0)
> + return temp_int;

I don't see a value in swapping the checks.

Guenter

>  
>   *val = sbtsi_reg_to_mc(temp_int, temp_dec);
>  
> 

[PATCH] hwmon: (sbtsi) Don't read sensor more than once if it doesn't respond

[Konstantin Aladyshev]

From: Konstantin Aladyshev 

SBTSI sensors don't work when the CPU is off.
In this case every 'i2c_smbus_read_byte_data' function would fail
by a timeout.
Currently temp1_max/temp1_min file reads can cause two such timeouts
for every read.
Restructure code so there will be no more than one timeout for every
read opeartion.

Signed-off-by: Konstantin Aladyshev 
---
 drivers/hwmon/sbtsi_temp.c | 59 +++---
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
index e35357c48b8e..e09a8cf6de45 100644
--- a/drivers/hwmon/sbtsi_temp.c
+++ b/drivers/hwmon/sbtsi_temp.c
@@ -74,53 +74,52 @@ static int sbtsi_read(struct device *dev, enum 
hwmon_sensor_types type,
  u32 attr, int channel, long *val)
 {
struct sbtsi_data *data = dev_get_drvdata(dev);
+   u8 temp_int_reg, temp_dec_reg;
s32 temp_int, temp_dec;
int err;
 
switch (attr) {
case hwmon_temp_input:
-   /*
-* ReadOrder bit specifies the reading order of integer and
-* decimal part of CPU temp for atomic reads. If bit == 0,
-* reading integer part triggers latching of the decimal part,
-* so integer part should be read first. If bit == 1, read
-* order should be reversed.
-*/
-   err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
-   if (err < 0)
-   return err;
-
-   mutex_lock(>lock);
-   if (err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT)) {
-   temp_dec = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_DEC);
-   temp_int = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_INT);
-   } else {
-   temp_int = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_INT);
-   temp_dec = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_DEC);
-   }
-   mutex_unlock(>lock);
+   temp_int_reg = SBTSI_REG_TEMP_INT;
+   temp_dec_reg = SBTSI_REG_TEMP_DEC;
break;
case hwmon_temp_max:
-   mutex_lock(>lock);
-   temp_int = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_HIGH_INT);
-   temp_dec = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_HIGH_DEC);
-   mutex_unlock(>lock);
+   temp_int_reg = SBTSI_REG_TEMP_HIGH_INT;
+   temp_dec_reg = SBTSI_REG_TEMP_HIGH_DEC;
break;
case hwmon_temp_min:
-   mutex_lock(>lock);
-   temp_int = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_LOW_INT);
-   temp_dec = i2c_smbus_read_byte_data(data->client, 
SBTSI_REG_TEMP_LOW_DEC);
-   mutex_unlock(>lock);
+   temp_int_reg = SBTSI_REG_TEMP_LOW_INT;
+   temp_dec_reg = SBTSI_REG_TEMP_LOW_DEC;
break;
default:
return -EINVAL;
}
 
+   /*
+* ReadOrder bit specifies the reading order of integer and
+* decimal part of CPU temp for atomic reads. If bit == 0,
+* reading integer part triggers latching of the decimal part,
+* so integer part should be read first. If bit == 1, read
+* order should be reversed.
+*/
+   err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
+   if (err < 0)
+   return err;
+
+   mutex_lock(>lock);
+   if (err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT)) {
+   temp_dec = i2c_smbus_read_byte_data(data->client, temp_dec_reg);
+   temp_int = i2c_smbus_read_byte_data(data->client, temp_int_reg);
+   } else {
+   temp_int = i2c_smbus_read_byte_data(data->client, temp_int_reg);
+   temp_dec = i2c_smbus_read_byte_data(data->client, temp_dec_reg);
+   }
+   mutex_unlock(>lock);
 
-   if (temp_int < 0)
-   return temp_int;
if (temp_dec < 0)
return temp_dec;
+   if (temp_int < 0)
+   return temp_int;
 
*val = sbtsi_reg_to_mc(temp_int, temp_dec);
 
-- 
2.17.1

Please respond back

[Adrien Saif]

--


Hello,

This is attorney Adrien Saif, the legal practitioner to Qatif Oil And Gas Group 
of Companies,
Did you receive the proposal we sent to you via email days ago? 



Best Regards,
Adrien Saif

[PATCH v6 3/3] usb: typec: tcpm: Respond Wait if VDM state machine is running

[Kyle Tso]

Port partner could send PR_SWAP/DR_SWAP/VCONN_SWAP/Request just after it
enters Ready states. This will cause conficts if the port is going to
send DISC_IDENT in the Ready states of TCPM. Set a flag indicating that
the state machine is processing VDM and respond Wait messages until the
VDM state machine stops.

Signed-off-by: Kyle Tso 
---
Changelog since v5:
 - no change

 drivers/usb/typec/tcpm/tcpm.c | 80 ---
 1 file changed, 73 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 70922723da4b..0dd932fe08d0 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -352,6 +352,7 @@ struct tcpm_port {
struct hrtimer enable_frs_timer;
struct kthread_work enable_frs;
bool state_machine_running;
+   bool vdm_sm_running;
 
struct completion tx_complete;
enum tcpm_transmit_status tx_status;
@@ -1526,6 +1527,7 @@ static int tcpm_pd_svdm(struct tcpm_port *port, struct 
typec_altmode *adev,
rlen = 1;
} else {
tcpm_register_partner_altmodes(port);
+   port->vdm_sm_running = false;
}
break;
case CMD_ENTER_MODE:
@@ -1569,10 +1571,12 @@ static int tcpm_pd_svdm(struct tcpm_port *port, struct 
typec_altmode *adev,
rlen = 1;
break;
}
+   port->vdm_sm_running = false;
break;
default:
response[0] = p[0] | VDO_CMDT(CMDT_RSP_NAK);
rlen = 1;
+   port->vdm_sm_running = false;
break;
}
 
@@ -1739,6 +1743,8 @@ static void vdm_run_state_machine(struct tcpm_port *port)
switch (PD_VDO_CMD(vdo_hdr)) {
case CMD_DISCOVER_IDENT:
res = tcpm_ams_start(port, DISCOVER_IDENTITY);
+   if (res == 0)
+   port->send_discover = false;
break;
case CMD_DISCOVER_SVID:
res = tcpm_ams_start(port, DISCOVER_SVIDS);
@@ -1763,8 +1769,10 @@ static void vdm_run_state_machine(struct tcpm_port *port)
break;
}
 
-   if (res < 0)
+   if (res < 0) {
+   port->vdm_sm_running = false;
return;
+   }
}
 
port->vdm_state = VDM_STATE_SEND_MESSAGE;
@@ -1843,6 +1851,9 @@ static void vdm_state_machine_work(struct kthread_work 
*work)
 port->vdm_state != VDM_STATE_BUSY &&
 port->vdm_state != VDM_STATE_SEND_MESSAGE);
 
+   if (port->vdm_state == VDM_STATE_ERR_TMOUT)
+   port->vdm_sm_running = false;
+
mutex_unlock(>lock);
 }
 
@@ -2226,6 +2237,12 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
}
 
port->sink_request = le32_to_cpu(msg->payload[0]);
+
+   if (port->vdm_sm_running && port->explicit_contract) {
+   tcpm_pd_handle_msg(port, PD_MSG_CTRL_WAIT, port->ams);
+   break;
+   }
+
if (port->state == SRC_SEND_CAPABILITIES)
tcpm_set_state(port, SRC_NEGOTIATE_CAPABILITIES, 0);
else
@@ -2328,6 +2345,10 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
   
TYPEC_PWR_MODE_PD,
   
port->pps_data.active,
   
port->supply_voltage);
+   /* Set VDM running flag ASAP */
+   if (port->data_role == TYPEC_HOST &&
+   port->send_discover)
+   port->vdm_sm_running = true;
tcpm_set_state(port, SNK_READY, 0);
} else {
/*
@@ -2365,10 +2386,14 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
switch (port->state) {
case SNK_NEGOTIATE_CAPABILITIES:
/* USB PD specification, Figure 8-43 */
-   if (port->explicit_contract)
+   if (port->explicit_contract) {
next_state = SNK_READY;
-   else
+   if (port->data_role == TYPEC_HOST &&
+

[PATCH v5 3/3] usb: typec: tcpm: Respond Wait if VDM state machine is running

[Kyle Tso]

Port partner could send PR_SWAP/DR_SWAP/VCONN_SWAP/Request just after it
enters Ready states. This will cause conficts if the port is going to
send DISC_IDENT in the Ready states of TCPM. Set a flag indicating that
the state machine is processing VDM and respond Wait messages until the
VDM state machine stops.

Signed-off-by: Kyle Tso 
Signed-off-by: Will McVicker 
---
 drivers/usb/typec/tcpm/tcpm.c | 80 ---
 1 file changed, 73 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index a951307d669d..9aa0e36f87e9 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -352,6 +352,7 @@ struct tcpm_port {
struct hrtimer enable_frs_timer;
struct kthread_work enable_frs;
bool state_machine_running;
+   bool vdm_sm_running;
 
struct completion tx_complete;
enum tcpm_transmit_status tx_status;
@@ -1527,6 +1528,7 @@ static int tcpm_pd_svdm(struct tcpm_port *port, struct 
typec_altmode *adev,
rlen = 1;
} else {
tcpm_register_partner_altmodes(port);
+   port->vdm_sm_running = false;
}
break;
case CMD_ENTER_MODE:
@@ -1570,10 +1572,12 @@ static int tcpm_pd_svdm(struct tcpm_port *port, struct 
typec_altmode *adev,
rlen = 1;
break;
}
+   port->vdm_sm_running = false;
break;
default:
response[0] = p[0] | VDO_CMDT(CMDT_RSP_NAK);
rlen = 1;
+   port->vdm_sm_running = false;
break;
}
 
@@ -1740,6 +1744,8 @@ static void vdm_run_state_machine(struct tcpm_port *port)
switch (PD_VDO_CMD(vdo_hdr)) {
case CMD_DISCOVER_IDENT:
res = tcpm_ams_start(port, DISCOVER_IDENTITY);
+   if (res == 0)
+   port->send_discover = false;
break;
case CMD_DISCOVER_SVID:
res = tcpm_ams_start(port, DISCOVER_SVIDS);
@@ -1766,8 +1772,10 @@ static void vdm_run_state_machine(struct tcpm_port *port)
break;
}
 
-   if (res < 0)
+   if (res < 0) {
+   port->vdm_sm_running = false;
return;
+   }
}
 
port->vdm_state = VDM_STATE_SEND_MESSAGE;
@@ -1846,6 +1854,9 @@ static void vdm_state_machine_work(struct kthread_work 
*work)
 port->vdm_state != VDM_STATE_BUSY &&
 port->vdm_state != VDM_STATE_SEND_MESSAGE);
 
+   if (port->vdm_state == VDM_STATE_ERR_TMOUT)
+   port->vdm_sm_running = false;
+
mutex_unlock(>lock);
 }
 
@@ -2230,6 +2241,12 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
}
 
port->sink_request = le32_to_cpu(msg->payload[0]);
+
+   if (port->vdm_sm_running && port->explicit_contract) {
+   tcpm_pd_handle_msg(port, PD_MSG_CTRL_WAIT, port->ams);
+   break;
+   }
+
if (port->state == SRC_SEND_CAPABILITIES)
tcpm_set_state(port, SRC_NEGOTIATE_CAPABILITIES, 0);
else
@@ -2335,6 +2352,10 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
   
TYPEC_PWR_MODE_PD,
   
port->pps_data.active,
   
port->supply_voltage);
+   /* Set VDM running flag ASAP */
+   if (port->data_role == TYPEC_HOST &&
+   port->send_discover)
+   port->vdm_sm_running = true;
tcpm_set_state(port, SNK_READY, 0);
} else {
/*
@@ -2372,10 +2393,14 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
switch (port->state) {
case SNK_NEGOTIATE_CAPABILITIES:
/* USB PD specification, Figure 8-43 */
-   if (port->explicit_contract)
+   if (port->explicit_contract) {
next_state = SNK_READY;
-   else
+   if (port->data_role == TYPEC_HOST &&
+

I NEED YOUR URGENT RESPOND.

[omra musa]

>From Mr Omra Musa
Bank Of Africa (B.O.A)
Burkina Faso Ouagadougou

My Dear Friend,

Please I want you to read this letter very carefully and I must
apologize for barging this message into your mail box without any
formal introduction due to the urgency and confidential of this issue
and I know that this message will come to you as a surprise. Please
this is not a joke and I will not like you to joke with it.

I am Mr Omra Musa Manager in Bank Of Africa (B.O.A) Ouagadougou,
Burkina Faso. I Hoped that you will not expose or betray this trust
and confident that I am about to establish with you for the mutual
benefit of you and I. This fund was deposited in our bank by Mr.
Kattan Azmal from Jordan who died in a plane crash in 2000 Tbm 700
aircraft on 31st July with his wife and the whole crew on board.

I need your urgent assistance in transferring the sum of ($15) million
USD into your account within 14 working banking days. This money has
been deposited for years in our Bank without claim due to the owner of
this fund died along with his entire family in an air crash since July
31st 2000.

The reason why i contacted you is that after the bank audit in 24th of
November, we found out that this fund has remained unclaimed since the
death of the deceased costumer.

I want our bank to release this fund to you as the nearest person to
our deceased customer while i come over to your country to share this
fund with you as soon as you confirm this fund into your account and
ask me to come over. I don't want the money to go into our Bank
treasure as an abandoned fund. So this is the reason why i contacted
you so that our bank will release this money to you as the next of kin
to the deceased customer. Please I would like you to keep this
proposal as a top secret and delete it if you are not interesting.

Upon the receipt of your reply and indication of your capability, i
will give you full details on how the business will be executed and
also note that you will have 50% of the above mentioned sum if you
agree to handle this business with me while 50% will be for me, And i
don't want anyone here in our bank to know my involvement until you
confirm this fund into your account and ask me to come over for the
sharing as I indicated.

I am looking forward to hear from you immediately for further information

THE REQUESTED INFORMATIONS BELOW
==
1. FULL NAME..
2. TELEPHONE NUMBERS/MOBILE/FAX...
3. YOUR AGE..
4. YOUR SEX.
5. YOUR OCCUPATION
6. YOUR COUNTRY AND CITY..
7. YOUR HOME ADDRESS
8. MARITAL STATUS

Sincerely,
Mr Omra Musa

You can reply to my private email address at mussaomra2...@gmail.com

RESPOND FOR DETAILS

[LEO NATHAN]

Dear,I am in the UK and very sick due to cancer, will die.want to distribute 
$10,000,000.00 via you my name is LEO NATHAN

Dear. beloved one I need Your Urgent respond,

[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: STRICTLY CONFIDENTIAL (Respond Immediately)

[From: Steve Odonkon]

Esteem Complement,Tuesday October 6th 2020

Hello, my name is Steve Odonkon, Audit Accounting Officer of Standard Chartered 
Bank, Basinghall Ave, London, United Kingdom. I got your information when I was 
searching for an oversea partner among other names, I ask for your pardon if my 
approach is offensive as I never meant to invade your privacy through this 
means, and also i believe this is the best and secured means I can pass my 
message across to you in clear terms. I have sent you this proposal before now; 
I do hope this will get to you in good health.


As the Audit Accounting Officer of the bank, I have access to lots of documents 
because I handle some of the bank's sensitive files. On the course of the last 
year 2019 business report, I discovered that my branch in which I am the Audit 
Accounting Officer made (Ј5,720,000.00). Million British pounds from some past 
government contractors in which my head office are not aware of and will never 
be aware of. I have placed this funds on what we call escrow call account with 
no beneficiary.


As an officer of this bank I cannot be directly connected to this money, so my 
aim of contacting you is to assist me receive this money in your bank account 
and get 40% of the total funds as commission. There are practically no risks 
involved, it will be a bank-to-bank transfer, and all I need from you is to 
stand claim as the Original depositor of these funds who made the deposit with 
my branch so that my head office can order the transfer to your designated bank 
account.

Send me your contact details below to enable me furnish you with more relevant 
details that will help you understand the transaction.

Full Name...

Telephone Number...


Thank you in advance and May God bless you and your family.

Yours truly,
Steve Odonkon
E-mail:  steveko...@rediffmail.com
Call: +44 7926062919

-- 
This email has been checked for viruses by AVG.
https://www.avg.com

RE: STRICTLY CONFIDENTIAL (Respond Immediately)

[From: Steve Odonkon]

Esteem Complement,Tuesday October 6th 2020

Hello, my name is Steve Odonkon, Audit Accounting Officer of Standard Chartered 
Bank, Basinghall Ave, London, United Kingdom. I got your information when I was 
searching for an oversea partner among other names, I ask for your pardon if my 
approach is offensive as I never meant to invade your privacy through this 
means, and also i believe this is the best and secured means I can pass my 
message across to you in clear terms. I have sent you this proposal before now; 
I do hope this will get to you in good health.


As the Audit Accounting Officer of the bank, I have access to lots of documents 
because I handle some of the bank's sensitive files. On the course of the last 
year 2019 business report, I discovered that my branch in which I am the Audit 
Accounting Officer made (Ј5,720,000.00). Million British pounds from some past 
government contractors in which my head office are not aware of and will never 
be aware of. I have placed this funds on what we call escrow call account with 
no beneficiary.


As an officer of this bank I cannot be directly connected to this money, so my 
aim of contacting you is to assist me receive this money in your bank account 
and get 40% of the total funds as commission. There are practically no risks 
involved, it will be a bank-to-bank transfer, and all I need from you is to 
stand claim as the Original depositor of these funds who made the deposit with 
my branch so that my head office can order the transfer to your designated bank 
account.

Send me your contact details below to enable me furnish you with more relevant 
details that will help you understand the transaction.

Full Name...

Telephone Number...


Thank you in advance and May God bless you and your family.

Yours truly,
Steve Odonkon
E-mail:  steveko...@rediffmail.com
Call: +44 7926062919

-- 
This email has been checked for viruses by AVG.
https://www.avg.com

I am expecting your urgent respond.

[Mohammad ouattara]

Dear Friend,

I know that this message will come to you as a surprise. I am the
Auditing and Accounting section manager in (BOA BANK) Ouagadougou
Burkina Faso.

I Hope that you will not expose or betray this trust and confident
that I am about to repose on you for the mutual benefit of our both
families.

I need your assistance in transferring the sum of ($12.5M) Twelve
Million, Five Hundred Thousand United Dollars into your account within
7 to 10 banking days,as one of my Bank foriegn clients who died few
years ago without indicating his next of kin to the fund.

If you are really interested in my proposal further details of the
Transfer will be forwarded unto you as soon as I receive your
willingness mail for a successful transfer.

I am expecting your urgent respond.

Have a great day,
Mr mohammad ouattara.

kindly respond to my mail

[Sgt Vivian Robert]

Good Day, I am glad to contact you through this medium I’m Sgt Vivian Robert am 
from united state, 28 years old single I am the only surviving child of my late 
parents, I am America female soldier presently in Afghanistan for the training, 
advising the Afghan forces and also helping in stabilizing the country against 
security challenges, am Actually seeking your assistance to evacuate the sum of 
$3.5 million, This money I got it as my reward in service by Afghanistan 
government to support me for my Good job in their land. Right now, I want you 
to stand as my beneficiary and receive the fund my certificate of deposit from 
the Bank where this fund deposited and my authorization letter is with me 
now.My contact with you is not by my power but it is divinely made for God's 
purpose to be fulfilled in our lives. I want you to be rest assured that this 
transaction is legitimate and a 100% risk free involvement, all you have to do 
is to keep it secret and confidential to yourself , this transaction will not 
take more than 7 working banking days for the money to get into your account 
based on your sincerity and cooperation. i want you to take 40% Percent of the 
total money for your personal use While 20% Percent of the money will go to 
charity, people in the street and helping the orphanage the remaining 40% 
percent of the total money .you will assist me to invest it in a good 
profitable Venture or you keep it for me until I arrive your country. If you’re 
willing to assist me contact me through my email address 
“sgtvivianrobe...@gmail.com.

Sgt Vivian Robert

I NEED YOUR URGENT RESPOND PLEASE

[Mr. Tapsoba Ahmed]

Hello Dear Friend,

My name is Mr.Tapsoba Ahmed. I have decided to seek a confidential
co-operation  with you in the execution of the deal described
here-under for our both  mutual benefit and I hope you will keep it a
top secret because of the nature  of the transaction, During the
course of our bank year auditing, I discovered  an unclaimed/abandoned
fund, sum total of {US$19.3 Million United State  Dollars} in the bank
account that belongs to a Saudi Arabia businessman Who unfortunately
lost his life and entire family in a Motor Accident.

Now our bank has been waiting for any of the relatives to come-up for
the claim but nobody has done that. I personally has been unsuccessful
in locating any of the relatives, now, I sincerely seek your consent
to present you as the next of kin / Will Beneficiary to the deceased
so that the proceeds of this account valued at {US$19.3 Million United
State Dollars} can be paid to you, which we will share in these
percentages ratio, 60% to me and 40% to you. All I request is your
utmost sincere co-operation; trust and maximum confidentiality to
achieve this project successfully. I have carefully mapped out the
moralities for execution of this transaction under a legitimate
arrangement to protect you from any breach of the law both in your
country and here in Burkina Faso when the fund is being transferred to
your bank account.

I will have to provide all the relevant document that will be
requested to indicate that you are the rightful beneficiary of this
legacy and our bank will release the fund to you without any further
delay, upon your consideration and acceptance of this offer, please
send me the following information as stated below so we can proceed
and get this fund transferred to your designated bank account
immediately.

-Your Full Name:
-Your Contact Address:
-Your direct Mobile telephone Number:
-Your Date of Birth:
-Your occupation:

I await your swift response and re-assurance.

Best regards,
Mr.Tapsoba Ahmed.

Re: [PATCH 2/9] macintosh/via-macii: Poll the device most likely to respond

[Guenter Roeck]

Hi,

On 8/9/20 3:58 PM, Finn Thain wrote:
> On Sun, 9 Aug 2020, Guenter Roeck wrote:
> 
>> Hi,
>>
>> On Sun, Jun 28, 2020 at 02:23:12PM +1000, Finn Thain wrote:
>>> Poll the most recently polled device by default, rather than the lowest
>>> device address that happens to be enabled in autopoll_devs. This improves
>>> input latency. Re-use macii_queue_poll() rather than duplicate that logic.
>>> This eliminates a static struct and function.
>>>
>>> Fixes: d95fd5fce88f0 ("m68k: Mac II ADB fixes") # v5.0+
>>> Tested-by: Stan Johnson 
>>> Signed-off-by: Finn Thain 
>>
>> With this patch applied, the qemu "q800" emulation no longer works and 
>> is stuck in early boot. Any idea why that might be the case, and/or how 
>> to debug it ?
>>
> 
> The problem you're seeing was mentioned in the cover letter,
> https://lore.kernel.org/linux-m68k/cover.1593318192.git.fth...@telegraphics.com.au/
> 
> Since this series was merged, Linus' tree is no longer compatible with 
> long-standing QEMU bugs.
> 
> The best way to fix this is to upgrade QEMU (latest is 5.1.0-rc3). Or use 
> the serial console instead of the framebuffer console.
> 

I have no problem with that. Actually, I had checked the qemu commit log,
 but somehow I had missed missed the commits there.

> I regret the inconvenience but the alternative was worse: adding code to 
> Linux to get compatibility with QEMU bugs (which were added to QEMU due to 
> Linux bugs).
> 
> My main concern is correct operation on actual hardware, as always. But 
> some QEMU developers are working on support for operating systems besides 
> Linux.
> 
> Therefore, I believe that both QEMU and Linux should aim for compatibility 
> with actual hardware and not bug compatibility with each other.
> 
I absolutely agree.

I repeated the test on the mainline kernel with qemu v5.1-rc3, and it works.
I also made sure that older versions of Linux still work with the qemu
v5.1.0-rc3. So everything is good, and sorry for the noise.

Thanks,
Guenter

Re: [PATCH 2/9] macintosh/via-macii: Poll the device most likely to respond

[Finn Thain]

On Sun, 9 Aug 2020, Guenter Roeck wrote:

> Hi,
> 
> On Sun, Jun 28, 2020 at 02:23:12PM +1000, Finn Thain wrote:
> > Poll the most recently polled device by default, rather than the lowest
> > device address that happens to be enabled in autopoll_devs. This improves
> > input latency. Re-use macii_queue_poll() rather than duplicate that logic.
> > This eliminates a static struct and function.
> > 
> > Fixes: d95fd5fce88f0 ("m68k: Mac II ADB fixes") # v5.0+
> > Tested-by: Stan Johnson 
> > Signed-off-by: Finn Thain 
> 
> With this patch applied, the qemu "q800" emulation no longer works and 
> is stuck in early boot. Any idea why that might be the case, and/or how 
> to debug it ?
> 

The problem you're seeing was mentioned in the cover letter,
https://lore.kernel.org/linux-m68k/cover.1593318192.git.fth...@telegraphics.com.au/

Since this series was merged, Linus' tree is no longer compatible with 
long-standing QEMU bugs.

The best way to fix this is to upgrade QEMU (latest is 5.1.0-rc3). Or use 
the serial console instead of the framebuffer console.

I regret the inconvenience but the alternative was worse: adding code to 
Linux to get compatibility with QEMU bugs (which were added to QEMU due to 
Linux bugs).

My main concern is correct operation on actual hardware, as always. But 
some QEMU developers are working on support for operating systems besides 
Linux.

Therefore, I believe that both QEMU and Linux should aim for compatibility 
with actual hardware and not bug compatibility with each other.

Re: [PATCH 2/9] macintosh/via-macii: Poll the device most likely to respond

[Guenter Roeck]

Hi,

On Sun, Jun 28, 2020 at 02:23:12PM +1000, Finn Thain wrote:
> Poll the most recently polled device by default, rather than the lowest
> device address that happens to be enabled in autopoll_devs. This improves
> input latency. Re-use macii_queue_poll() rather than duplicate that logic.
> This eliminates a static struct and function.
> 
> Fixes: d95fd5fce88f0 ("m68k: Mac II ADB fixes") # v5.0+
> Tested-by: Stan Johnson 
> Signed-off-by: Finn Thain 

With this patch applied, the qemu "q800" emulation no longer works and is stuck
in early boot. Any idea why that might be the case, and/or how to debug it ?

Thanks,
Guenter

> ---
>  drivers/macintosh/via-macii.c | 99 +++
>  1 file changed, 53 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/macintosh/via-macii.c b/drivers/macintosh/via-macii.c
> index 6aa903529570d..d4f1a65c5f1fd 100644
> --- a/drivers/macintosh/via-macii.c
> +++ b/drivers/macintosh/via-macii.c
> @@ -77,6 +77,10 @@ static volatile unsigned char *via;
>  #define ST_ODD   0x20/* ADB state: odd data byte */
>  #define ST_IDLE  0x30/* ADB state: idle, nothing to 
> send */
>  
> +/* ADB command byte structure */
> +#define ADDR_MASK0xF0
> +#define CMD_MASK 0x0F
> +
>  static int macii_init_via(void);
>  static void macii_start(void);
>  static irqreturn_t macii_interrupt(int irq, void *arg);
> @@ -117,7 +121,8 @@ static int reply_len; /* number of bytes received in 
> reply_buf or req->reply */
>  static int status;  /* VIA's ADB status bits captured upon interrupt 
> */
>  static int last_status;  /* status bits as at previous interrupt 
> */
>  static int srq_asserted; /* have to poll for the device that asserted it 
> */
> -static int command_byte; /* the most recent command byte transmitted 
> */
> +static u8 last_cmd;  /* the most recent command byte transmitted 
> */
> +static u8 last_poll_cmd; /* the most recent Talk R0 command byte transmitted 
> */
>  static int autopoll_devs;  /* bits set are device addresses to be polled 
> */
>  
>  /* Check for MacII style ADB */
> @@ -179,35 +184,49 @@ static int macii_init_via(void)
>  /* Send an ADB poll (Talk Register 0 command prepended to the request queue) 
> */
>  static void macii_queue_poll(void)
>  {
> - /* No point polling the active device as it will never assert SRQ, so
> -  * poll the next device in the autopoll list. This could leave us
> -  * stuck in a polling loop if an unprobed device is asserting SRQ.
> -  * In theory, that could only happen if a device was plugged in after
> -  * probing started. Unplugging it again will break the cycle.
> -  * (Simply polling the next higher device often ends up polling almost
> -  * every device (after wrapping around), which takes too long.)
> -  */
> - int device_mask;
> - int next_device;
>   static struct adb_request req;
> + unsigned char poll_command;
> + unsigned int poll_addr;
>  
> + /* This only polls devices in the autopoll list, which assumes that
> +  * unprobed devices never assert SRQ. That could happen if a device was
> +  * plugged in after the adb bus scan. Unplugging it again will resolve
> +  * the problem. This behaviour is similar to MacOS.
> +  */
>   if (!autopoll_devs)
>   return;
>  
> - device_mask = (1 << (((command_byte & 0xF0) >> 4) + 1)) - 1;
> - if (autopoll_devs & ~device_mask)
> - next_device = ffs(autopoll_devs & ~device_mask) - 1;
> - else
> - next_device = ffs(autopoll_devs) - 1;
> + /* The device most recently polled may not be the best device to poll
> +  * right now. Some other device(s) may have signalled SRQ (the active
> +  * device won't do that). Or the autopoll list may have been changed.
> +  * Try polling the next higher address.
> +  */
> + poll_addr = (last_poll_cmd & ADDR_MASK) >> 4;
> + if ((srq_asserted && last_cmd == last_poll_cmd) ||
> + !(autopoll_devs & (1 << poll_addr))) {
> + unsigned int higher_devs;
> +
> + higher_devs = autopoll_devs & -(1 << (poll_addr + 1));
> + poll_addr = ffs(higher_devs ? higher_devs : autopoll_devs) - 1;
> + }
>  
> - adb_request(, NULL, ADBREQ_NOSEND, 1, ADB_READREG(next_device, 0));
> + /* Send a Talk Register 0 command */
> + poll_command = ADB_READREG(poll_addr, 0);
> +
> + /* No need to repeat this Talk command. The transceiver will do that
> +  * as long as it is idle.
> +  */
> + if (poll_command == last_cmd)
> + return;
> +
> + adb_request(, NULL, ADBREQ_NOSEND, 1, poll_command);
>  
>   req.sent = 0;
>   req.complete = 0;
>   req.reply_len = 0;
>   req.next = current_req;
>  
> - if (current_req != NULL) {
> + if (WARN_ON(current_req)) {
>   current_req = 
>   } else {
>   

PLEASE RESPOND VERY URGENTLY

[Dr. Allison Neher]

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 (18.6 million) with my positions as
a staff of this bank, i am handicapped because i cannot operate
foreign accounts and cannot lay benefice 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, 50% for you, and
expenses incidental occur during the transfer will be incur by both of
us. 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’s 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?

(1) Your full name..
(2) Your age:
(3) Sex:.
(4) Your telephone number:.
(5) Your occupation:.
(6) Your country:.

Yours sincerely,
Dr. Allison Neher
+226 58779013

[PATCH 2/9] macintosh/via-macii: Poll the device most likely to respond

[Finn Thain]

Poll the most recently polled device by default, rather than the lowest
device address that happens to be enabled in autopoll_devs. This improves
input latency. Re-use macii_queue_poll() rather than duplicate that logic.
This eliminates a static struct and function.

Fixes: d95fd5fce88f0 ("m68k: Mac II ADB fixes") # v5.0+
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/macintosh/via-macii.c | 99 +++
 1 file changed, 53 insertions(+), 46 deletions(-)

diff --git a/drivers/macintosh/via-macii.c b/drivers/macintosh/via-macii.c
index 6aa903529570d..d4f1a65c5f1fd 100644
--- a/drivers/macintosh/via-macii.c
+++ b/drivers/macintosh/via-macii.c
@@ -77,6 +77,10 @@ static volatile unsigned char *via;
 #define ST_ODD 0x20/* ADB state: odd data byte */
 #define ST_IDLE0x30/* ADB state: idle, nothing to 
send */
 
+/* ADB command byte structure */
+#define ADDR_MASK  0xF0
+#define CMD_MASK   0x0F
+
 static int macii_init_via(void);
 static void macii_start(void);
 static irqreturn_t macii_interrupt(int irq, void *arg);
@@ -117,7 +121,8 @@ static int reply_len; /* number of bytes received in 
reply_buf or req->reply */
 static int status;  /* VIA's ADB status bits captured upon interrupt */
 static int last_status;  /* status bits as at previous interrupt */
 static int srq_asserted; /* have to poll for the device that asserted it */
-static int command_byte; /* the most recent command byte transmitted */
+static u8 last_cmd;  /* the most recent command byte transmitted */
+static u8 last_poll_cmd; /* the most recent Talk R0 command byte transmitted */
 static int autopoll_devs;  /* bits set are device addresses to be polled */
 
 /* Check for MacII style ADB */
@@ -179,35 +184,49 @@ static int macii_init_via(void)
 /* Send an ADB poll (Talk Register 0 command prepended to the request queue) */
 static void macii_queue_poll(void)
 {
-   /* No point polling the active device as it will never assert SRQ, so
-* poll the next device in the autopoll list. This could leave us
-* stuck in a polling loop if an unprobed device is asserting SRQ.
-* In theory, that could only happen if a device was plugged in after
-* probing started. Unplugging it again will break the cycle.
-* (Simply polling the next higher device often ends up polling almost
-* every device (after wrapping around), which takes too long.)
-*/
-   int device_mask;
-   int next_device;
static struct adb_request req;
+   unsigned char poll_command;
+   unsigned int poll_addr;
 
+   /* This only polls devices in the autopoll list, which assumes that
+* unprobed devices never assert SRQ. That could happen if a device was
+* plugged in after the adb bus scan. Unplugging it again will resolve
+* the problem. This behaviour is similar to MacOS.
+*/
if (!autopoll_devs)
return;
 
-   device_mask = (1 << (((command_byte & 0xF0) >> 4) + 1)) - 1;
-   if (autopoll_devs & ~device_mask)
-   next_device = ffs(autopoll_devs & ~device_mask) - 1;
-   else
-   next_device = ffs(autopoll_devs) - 1;
+   /* The device most recently polled may not be the best device to poll
+* right now. Some other device(s) may have signalled SRQ (the active
+* device won't do that). Or the autopoll list may have been changed.
+* Try polling the next higher address.
+*/
+   poll_addr = (last_poll_cmd & ADDR_MASK) >> 4;
+   if ((srq_asserted && last_cmd == last_poll_cmd) ||
+   !(autopoll_devs & (1 << poll_addr))) {
+   unsigned int higher_devs;
+
+   higher_devs = autopoll_devs & -(1 << (poll_addr + 1));
+   poll_addr = ffs(higher_devs ? higher_devs : autopoll_devs) - 1;
+   }
 
-   adb_request(, NULL, ADBREQ_NOSEND, 1, ADB_READREG(next_device, 0));
+   /* Send a Talk Register 0 command */
+   poll_command = ADB_READREG(poll_addr, 0);
+
+   /* No need to repeat this Talk command. The transceiver will do that
+* as long as it is idle.
+*/
+   if (poll_command == last_cmd)
+   return;
+
+   adb_request(, NULL, ADBREQ_NOSEND, 1, poll_command);
 
req.sent = 0;
req.complete = 0;
req.reply_len = 0;
req.next = current_req;
 
-   if (current_req != NULL) {
+   if (WARN_ON(current_req)) {
current_req = 
} else {
current_req = 
@@ -266,37 +285,22 @@ static int macii_write(struct adb_request *req)
 /* Start auto-polling */
 static int macii_autopoll(int devs)
 {
-   static struct adb_request req;
unsigned long flags;
-   int err = 0;
 
local_irq_save(flags);
 
/* bit 1 == device 1, and so on. */
autopoll_devs = devs & 0xFFFE;
 

I'm being accused of "killing foss", how do I respond?

[nipponmail]

Dear RMS, a commentator is now accusing me of being the executioner of 
"foss" :


oh it's you, the schizo who killed foss by trying to defend it and 
thinks he's a lawyer


Later the commentator clarifies :

You went on a mailing list for some foss project with the intention of 
exposing a patent violation by some
other project using the code, but instead of talking about that, you 
just ranted for a few days about how much

you want to fuck little girls.
Then RMS got labeled a pedophile and eaten up by cancel culture.
I'm flabbergasted you're honestly too stupid to see the connection.



The issue is copyright, not patent, and there was nothing wrong with 
your past statements.


I would think that the fact that the GPL is effectively toothless is 
what would "kill free and opensource software" by causing would-be 
contributors to now lack faith in the "share and share alike" promise of 
the GPL. The FSF won't enforce it's GCC copyrights, nor will the linux 
kernel contributors (both regarding GRSecurity linux kernel patches and 
GCC plugins (and their no-redistribution attached clauses))


I also wonder about this

for a few days

invective.
Are days suddenly a euphemism such as is imagined regarding various 
creation stories?


How should I respond and set the record straight? And when did "FOSS" 
die? I remember when that term was coined, early 2000s, has it now 
fallen out of favor? Why is it my fault? I never really liked that term 
to begin with: it's a corporate conflation of two specific idea sets: A 
gloss. If said term is gone what is the injury?

I am expecting your urgent respond.

[Mohammad Ouattara]

Dear Friend!!!

I know that this message will come to you as a surprise.
I am the Auditing and Accounting section manager in (BOA BANK)
Ouagadougou Burkina Faso. I Hope that you
will not expose or betray
this trust and confident that I am about to repose on you for the
mutual benefit of our both families. I need your assistance in
transferring the sum of ($12.5M) Ten million, five hundred thousand
united dollars into your account within 7 to 10 banking days. Of one
of my Bank clients who died at the collapsing of the world trade
center at the United States on September 11th 2001.

If you are really interested in my proposal further details of the
Transfer will be forwarded unto you as soon as I receive your
willingness mail for a successful transfer.

I am expecting your urgent respond.

Mr mohammad ouattara.

[PATCH 4.19 110/190] usb: typec: tcpm: Try PD-2.0 if sink does not respond to 3.0 source-caps

[Greg Kroah-Hartman]

[ Upstream commit 976daf9d1199932df80e7b04546d1a1bd4ed5ece ]

PD 2.0 sinks are supposed to accept src-capabilities with a 3.0 header and
simply ignore any src PDOs which the sink does not understand such as PPS
but some 2.0 sinks instead ignore the entire PD_DATA_SOURCE_CAP message,
causing contract negotiation to fail.

This commit fixes such sinks not working by re-trying the contract
negotiation with PD-2.0 source-caps messages if we don't have a contract
after PD_N_HARD_RESET_COUNT hard-reset attempts.

The problem fixed by this commit was noticed with a Type-C to VGA dongle.

Signed-off-by: Hans de Goede 
Reviewed-by: Guenter Roeck 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/typec/tcpm.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index fb20aa974ae12..819ae3b2bd7e8 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -37,6 +37,7 @@
S(SRC_ATTACHED),\
S(SRC_STARTUP), \
S(SRC_SEND_CAPABILITIES),   \
+   S(SRC_SEND_CAPABILITIES_TIMEOUT),   \
S(SRC_NEGOTIATE_CAPABILITIES),  \
S(SRC_TRANSITION_SUPPLY),   \
S(SRC_READY),   \
@@ -2987,10 +2988,34 @@ static void run_state_machine(struct tcpm_port *port)
/* port->hard_reset_count = 0; */
port->caps_count = 0;
port->pd_capable = true;
-   tcpm_set_state_cond(port, hard_reset_state(port),
+   tcpm_set_state_cond(port, SRC_SEND_CAPABILITIES_TIMEOUT,
PD_T_SEND_SOURCE_CAP);
}
break;
+   case SRC_SEND_CAPABILITIES_TIMEOUT:
+   /*
+* Error recovery for a PD_DATA_SOURCE_CAP reply timeout.
+*
+* PD 2.0 sinks are supposed to accept src-capabilities with a
+* 3.0 header and simply ignore any src PDOs which the sink does
+* not understand such as PPS but some 2.0 sinks instead ignore
+* the entire PD_DATA_SOURCE_CAP message, causing contract
+* negotiation to fail.
+*
+* After PD_N_HARD_RESET_COUNT hard-reset attempts, we try
+* sending src-capabilities with a lower PD revision to
+* make these broken sinks work.
+*/
+   if (port->hard_reset_count < PD_N_HARD_RESET_COUNT) {
+   tcpm_set_state(port, HARD_RESET_SEND, 0);
+   } else if (port->negotiated_rev > PD_REV20) {
+   port->negotiated_rev--;
+   port->hard_reset_count = 0;
+   tcpm_set_state(port, SRC_SEND_CAPABILITIES, 0);
+   } else {
+   tcpm_set_state(port, hard_reset_state(port), 0);
+   }
+   break;
case SRC_NEGOTIATE_CAPABILITIES:
ret = tcpm_pd_check_request(port);
if (ret < 0) {
-- 
2.20.1

[PATCH AUTOSEL 4.19 089/167] usb: typec: tcpm: Try PD-2.0 if sink does not respond to 3.0 source-caps

[Sasha Levin]

From: Hans de Goede 

[ Upstream commit 976daf9d1199932df80e7b04546d1a1bd4ed5ece ]

PD 2.0 sinks are supposed to accept src-capabilities with a 3.0 header and
simply ignore any src PDOs which the sink does not understand such as PPS
but some 2.0 sinks instead ignore the entire PD_DATA_SOURCE_CAP message,
causing contract negotiation to fail.

This commit fixes such sinks not working by re-trying the contract
negotiation with PD-2.0 source-caps messages if we don't have a contract
after PD_N_HARD_RESET_COUNT hard-reset attempts.

The problem fixed by this commit was noticed with a Type-C to VGA dongle.

Signed-off-by: Hans de Goede 
Reviewed-by: Guenter Roeck 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/typec/tcpm.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 5f29ce8d6c3f9..e8524ad5a4c0a 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -37,6 +37,7 @@
S(SRC_ATTACHED),\
S(SRC_STARTUP), \
S(SRC_SEND_CAPABILITIES),   \
+   S(SRC_SEND_CAPABILITIES_TIMEOUT),   \
S(SRC_NEGOTIATE_CAPABILITIES),  \
S(SRC_TRANSITION_SUPPLY),   \
S(SRC_READY),   \
@@ -2987,10 +2988,34 @@ static void run_state_machine(struct tcpm_port *port)
/* port->hard_reset_count = 0; */
port->caps_count = 0;
port->pd_capable = true;
-   tcpm_set_state_cond(port, hard_reset_state(port),
+   tcpm_set_state_cond(port, SRC_SEND_CAPABILITIES_TIMEOUT,
PD_T_SEND_SOURCE_CAP);
}
break;
+   case SRC_SEND_CAPABILITIES_TIMEOUT:
+   /*
+* Error recovery for a PD_DATA_SOURCE_CAP reply timeout.
+*
+* PD 2.0 sinks are supposed to accept src-capabilities with a
+* 3.0 header and simply ignore any src PDOs which the sink does
+* not understand such as PPS but some 2.0 sinks instead ignore
+* the entire PD_DATA_SOURCE_CAP message, causing contract
+* negotiation to fail.
+*
+* After PD_N_HARD_RESET_COUNT hard-reset attempts, we try
+* sending src-capabilities with a lower PD revision to
+* make these broken sinks work.
+*/
+   if (port->hard_reset_count < PD_N_HARD_RESET_COUNT) {
+   tcpm_set_state(port, HARD_RESET_SEND, 0);
+   } else if (port->negotiated_rev > PD_REV20) {
+   port->negotiated_rev--;
+   port->hard_reset_count = 0;
+   tcpm_set_state(port, SRC_SEND_CAPABILITIES, 0);
+   } else {
+   tcpm_set_state(port, hard_reset_state(port), 0);
+   }
+   break;
case SRC_NEGOTIATE_CAPABILITIES:
ret = tcpm_pd_check_request(port);
if (ret < 0) {
-- 
2.20.1

HELLO! PLEASE TRY AND RESPOND SOONEST

[Abdoul Moussa]

My Dear Friend,

Before I introduce myself, I wish to inform you that this letter is not a hoax 
mail and I urge you to treat it 

serious. This letter must come to you as a big surprise, but I believe it is 
only a day that people meet and 

become great friends and business partners. Please I want you to read this 
letter very carefully and I must 

apologize for barging this message into your mailbox without any formal 
introduction due to the urgency and 

confidentiality of this business and I know that this message will come to you 
as a surprise. Please this is 

not a joke and I will not like you to joke with it ok, with due respect to your 
person and much sincerity of 

purpose, I make this contact with you as I believe that you can be of great 
assistance to me. My name is 

Mr.Abdoul Moussa, from Burkina Faso, West Africa. I work in United Bank for 
Africa (UBA) as telex manager, 

please see this as a confidential message and do not reveal it to another 
person and let me know whether you 

can be of assistance regarding my proposal below because it is top secret.

I am about to retire from active Banking service to start a new life but I am 
sceptical to reveal this 

particular secret to a stranger. You must assure me that everything will be 
handled confidentially because we 

are not going to suffer again in life. It has been 10 years now that most of 
the greedy African Politicians 

used our bank to launder money overseas through the help of their Political 
advisers. Most of the funds which 

they transferred out of the shores of Africa were gold and oil money that was 
supposed to have been used to 

develop the continent. Their Political advisers always inflated the amounts 
before transferring to foreign 

accounts, so I also used the opportunity to divert part of the funds hence I am 
aware that there is no official 

trace of how much was transferred as all the accounts used for such transfers 
were being closed after transfer. 

I acted as the Bank Officer to most of the politicians and when I discovered 
that they were using me to succeed 

in their greedy act; I also cleaned some of their banking records from the Bank 
files and no one cared to ask 

me because the money was too much for them to control. They laundered over 
$5billion Dollars during the 

process.

Before I send this message to you, I have already diverted ($10.5million 
Dollars) to an escrow account 

belonging to no one in the bank. The bank is anxious now to know who the 
beneficiary to the funds is because 

they have made a lot of profits with the funds. It is more than eight years now 
and most of the politicians are 

no longer using our bank to transfer funds overseas. The ($10.5million Dollars) 
has been laying waste in our 

bank and I don’t want to retire from the bank without transferring the funds to 
a foreign account to enable me 

to share the proceeds with the receiver (a foreigner). The money will be shared 
60% for me and 40% for you. 

There is no one coming to ask you about the funds because I secured everything. 
I only want you to assist me by 

providing a reliable bank account where the funds can be transferred.

You are not to face any difficulties or legal implications as I am going to 
handle the transfer personally. If 

you are capable of receiving the funds, do let me know immediately to enable me 
to give you detailed 

information on what to do. For me, I have not stolen the money from anyone 
because the other people that took 

the whole money did not face any problems. This is my chance to grab my own 
life opportunity but you must keep 

the details of the funds secret to avoid any leakages as no one in the bank 
knows about my plans. Please get 

back to me if you are interested and capable to handle this project, I shall 
intimate you on what to do when I 

hear from your confirmation and acceptance. If you are capable of being my 
trusted associate, do declare your 

consent to me I am looking forward to hearing from you immediately for further 
information. Make Sure You Reply 

To My private email: mabdoul...@gmail.com 

Thanks with my best regards.

HELLO! PLEASE TRY AND RESPOND SOONEST

[Abdoul Moussa]

My Dear Friend,

Before I introduce myself, I wish to inform you that this letter is not a hoax 
mail and I urge you to treat it serious. This letter must come to you as a big 
surprise, but I believe it is only a day that people meet and become great 
friends and business partners. Please I want you to read this letter very 
carefully and I must apologize for barging this message into your mailbox 
without any formal introduction due to the urgency and confidentiality of this 
business and I know that this message will come to you as a surprise. Please 
this is not a joke and I will not like you to joke with it ok, with due respect 
to your person and much sincerity of purpose, I make this contact with you as I 
believe that you can be of great assistance to me. My name is Mr.Abdoul Moussa, 
from Burkina Faso, West Africa. I work in United Bank for Africa (UBA) as telex 
manager, please see this as a confidential message and do not reveal it to 
another person and let me know whether you can be of assistance regarding my 
proposal below because it is top secret.

I am about to retire from active Banking service to start a new life but I am 
sceptical to reveal this particular secret to a stranger. You must assure me 
that everything will be handled confidentially because we are not going to 
suffer again in life. It has been 10 years now that most of the greedy African 
Politicians used our bank to launder money overseas through the help of their 
Political advisers. Most of the funds which they transferred out of the shores 
of Africa were gold and oil money that was supposed to have been used to 
develop the continent. Their Political advisers always inflated the amounts 
before transferring to foreign accounts, so I also used the opportunity to 
divert part of the funds hence I am aware that there is no official trace of 
how much was transferred as all the accounts used for such transfers were being 
closed after transfer. I acted as the Bank Officer to most of the politicians 
and when I discovered that they were using me to succeed in their greedy act; I 
also cleaned some of their banking records from the Bank files and no one cared 
to ask me because the money was too much for them to control. They laundered 
over $5billion Dollars during the process.

Before I send this message to you, I have already diverted ($10.5million 
Dollars) to an escrow account belonging to no one in the bank. The bank is 
anxious now to know who the beneficiary to the funds is because they have made 
a lot of profits with the funds. It is more than Eight years now and most of 
the politicians are no longer using our bank to transfer funds overseas. The 
($10.5million Dollars) has been laying waste in our bank and I don’t want to 
retire from the bank without transferring the funds to a foreign account to 
enable me to share the proceeds with the receiver (a foreigner). The money will 
be shared 60% for me and 40% for you. There is no one coming to ask you about 
the funds because I secured everything. I only want you to assist me by 
providing a reliable bank account where the funds can be transferred.

You are not to face any difficulties or legal implications as I am going to 
handle the transfer personally. If you are capable of receiving the funds, do 
let me know immediately to enable me to give you detailed information on what 
to do. For me, I have not stolen the money from anyone because the other people 
that took the whole money did not face any problems. This is my chance to grab 
my own life opportunity but you must keep the details of the funds secret to 
avoid any leakages as no one in the bank knows about my plans. Please get back 
to me if you are interested and capable to handle this project, I shall 
intimate you on what to do when I hear from your confirmation and acceptance. 
If you are capable of being my trusted associate, do declare your consent to me 
I am looking forward to hearing from you immediately for further information. 
Make Sure You Reply To My private email: mabdoul...@gmail.com 

Thanks with my best regards.

Kindly Respond

[Donald Douglas]

Hello,
I am Barr Fredrick Mbogo a business consultant i have a lucrative
business to discuss with you from the Eastern part of Africa Uganda to
be precise aimed at agreed percentage upon your acceptance of my hand
in business and friendship. Kindly respond to me if you are interested
to partner with me for an update. Very important.

Yours Sincerely,
Donald Douglas,
For,
Barr Frederick Mbogo
Legal Consultant.
Reply to: barrfredmb...@consultant.com

HELLO! PLEASE TRY AND RESPOND SOONEST

[Wilson Smith]

My Dear Friend,

Before I introduce myself, I wish to inform you that this letter is not a hoax 
mail and I urge you to treat it serious. This letter must come to you as a big 
surprise, but I believe it is only a day that people meet and become great 
friends and business partners. Please I want you to read this letter very 
carefully and I must apologize for barging this message into your mailbox 
without any formal introduction due to the urgency and confidentiality of this 
business and I know that this message will come to you as a surprise. Please 
this is not a joke and I will not like you to joke with it ok, with due respect 
to your person and much sincerity of purpose, I make this contact with you as I 
believe that you can be of great assistance to me. My name is Mr.Wilson Smith, 
from London, UK. I work in Kas Bank UK branch as telex manager, please see this 
as a confidential message and do not reveal it to another person and let me 
know whether you can be of assistance regarding my proposal below because it is 
top secret.

I am about to retire from active Banking service to start a new life but I am 
sceptical to reveal this particular secret to a stranger. You must assure me 
that everything will be handled confidentially because we are not going to 
suffer again in life. It has been 10 years now that most of the greedy African 
Politicians used our bank to launder money overseas through the help of their 
Political advisers. Most of the funds which they transferred out of the shores 
of Africa were gold and oil money that was supposed to have been used to 
develop the continent. Their Political advisers always inflated the amounts 
before transferring to foreign accounts, so I also used the opportunity to 
divert part of the funds hence I am aware that there is no official trace of 
how much was transferred as all the accounts used for such transfers were being 
closed after transfer. I acted as the Bank Officer to most of the politicians 
and when I discovered that they were using me to succeed in their greedy act; I 
also cleaned some of their banking records from the Bank files and no one cared 
to ask me because the money was too much for them to control. They laundered 
over £5billion pounds during the process.

Before I send this message to you, I have already diverted (£3.5million pounds) 
to an escrow account belonging to no one in the bank. The bank is anxious now 
to know who the beneficiary to the funds is because they have made a lot of 
profits with the funds. It is more than Eight years now and most of the 
politicians are no longer using our bank to transfer funds overseas. The 
(£3.5million pounds) has been laying waste in our bank and I don’t want to 
retire from the bank without transferring the funds to a foreign account to 
enable me to share the proceeds with the receiver (a foreigner). The money will 
be shared 60% for me and 40% for you. There is no one coming to ask you about 
the funds because I secured everything. I only want you to assist me by 
providing a reliable bank account where the funds can be transferred. Make Sure 
You Reply To My private email: wilsn...@gmail.com

I NEED YOUR URGENT RESPOND PLEASE

[Mohamed Allyson]

Hello Dear Friend,

My name is Mr. Mohamed Allyson. I have decided to seek a confidential
co-operation  with you in the execution of the deal described
here-under for our both  mutual benefit and I hope you will keep it a
top secret because of the nature  of the transaction, During the
course of our bank year auditing, I discovered  an unclaimed/abandoned
fund, sum total of {US$19.3 Million United State  Dollars} in the bank
account that belongs to a Saudi Arabia businessman Who unfortunately
lost his life and entire family in a Motor Accident.

Now our bank has been waiting for any of the relatives to come-up for
the claim but nobody has done that. I personally has been unsuccessful
in locating any of the relatives, now, I sincerely seek your consent
to present you as the next of kin / Will Beneficiary to the deceased
so that the proceeds of this account valued at {US$19.3 Million United
State Dollars} can be paid to you, which we will share in these
percentages ratio, 60% to me and 40% to you. All I request is your
utmost sincere co-operation; trust and maximum confidentiality to
achieve this project successfully. I have carefully mapped out the
moralities for execution of this transaction under a legitimate
arrangement to protect you from any breach of the law both in your
country and here in Burkina Faso when the fund is being transferred to
your bank account.

I will have to provide all the relevant document that will be
requested to indicate that you are the rightful beneficiary of this
legacy and our bank will release the fund to you without any further
delay, upon your consideration and acceptance of this offer, please
send me the following information as stated below so we can proceed
and get this fund transferred to your designated bank account
immediately.

-Your Full Name:
-Your Contact Address:
-Your direct Mobile telephone Number:
-Your Date of Birth:
-Your occupation:

I await your swift response and re-assurance through my Private email
address: mohamedallyson2...@gmail.com

Best regards,
Mr. Mohamed Allyson

PLEASE RESPOND VERY URGENTLY

[Mr Sahila Wanal]

FROM MR SAHILA WANAL
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 (18.6 million) with my positions as
staffs of the bank, i am handicapped because i cannot operate foreign
accounts and cannot lay benefice 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, 50% for you, and expenses
incidental occur during the transfer will be incur by both of us. 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 like you to keep this transaction as top 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?

Please for further information and inquires feel free to contact me
back through this my private e-mails as follows
(mrsahil...@yandex.com) 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) Your full name..
(2) Your age:
(3) Sex:.
(4) Your telephone number:.
(5) Your occupation:.
(6) Your country:.

Yours sincerely,
Mr Sahila Wanal
+226 689 650 34

Please Respond Urgently.

[Ahmed]

With due respect, I am inviting you for a business deal of Eleven Million Three 
hundred thousand united states dollars where this money can be shared between 
us.

By indicating your interest I will send you the full details on how the 
business will be executed.

Please send your reply to my private email --- ouedraogoah...@outlook.com

Please Respond Urgently.

[Michel]

With due respect, I am inviting you for a business deal of Eleven Million Three 
hundred thousand united states dollars where this money can be shared between 
us.

By indicating your interest I will send you the full details on how the 
business will be executed.

Please send your reply to my private email ---  mrmicheld...@outlook.com

I NEED YOUR RESPOND

[Dr. Ahmed Nuru]

-- 
I NEED YOUR ASSISTANT FOR AN URGENT BUSINESS PROPOSAL OF $135 MILLION
AND 767KG OF GOLD FOR INVESTMENT PLEASE KINDLY GET BACK TO ME IF YOU
CAN HANDLE IT FOR MORE DETAILS.

Respond

[Ella Golan]

My name is Ms Ella Golan, I'm the Chief Executive Officer (C.P.A) of the First 
International Bank of Israel (FIBI).
I'm getting in touch with you in regards to a very important and urgent matter.
Kindly respond back at your earliest convenience so
I can provide you the details.

Faithfully,
Ms Ella Golan

[PATCH 5.0 123/146] usb: typec: tcpm: Try PD-2.0 if sink does not respond to 3.0 source-caps

[Greg Kroah-Hartman]

5.0-stable review patch.  If anyone has any objections, please let me know.

--

From: Hans de Goede 

commit 976daf9d1199932df80e7b04546d1a1bd4ed5ece upstream.

PD 2.0 sinks are supposed to accept src-capabilities with a 3.0 header and
simply ignore any src PDOs which the sink does not understand such as PPS
but some 2.0 sinks instead ignore the entire PD_DATA_SOURCE_CAP message,
causing contract negotiation to fail.

This commit fixes such sinks not working by re-trying the contract
negotiation with PD-2.0 source-caps messages if we don't have a contract
after PD_N_HARD_RESET_COUNT hard-reset attempts.

The problem fixed by this commit was noticed with a Type-C to VGA dongle.

Signed-off-by: Hans de Goede 
Reviewed-by: Guenter Roeck 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/typec/tcpm/tcpm.c |   27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -37,6 +37,7 @@
S(SRC_ATTACHED),\
S(SRC_STARTUP), \
S(SRC_SEND_CAPABILITIES),   \
+   S(SRC_SEND_CAPABILITIES_TIMEOUT),   \
S(SRC_NEGOTIATE_CAPABILITIES),  \
S(SRC_TRANSITION_SUPPLY),   \
S(SRC_READY),   \
@@ -2966,10 +2967,34 @@ static void run_state_machine(struct tcp
/* port->hard_reset_count = 0; */
port->caps_count = 0;
port->pd_capable = true;
-   tcpm_set_state_cond(port, hard_reset_state(port),
+   tcpm_set_state_cond(port, SRC_SEND_CAPABILITIES_TIMEOUT,
PD_T_SEND_SOURCE_CAP);
}
break;
+   case SRC_SEND_CAPABILITIES_TIMEOUT:
+   /*
+* Error recovery for a PD_DATA_SOURCE_CAP reply timeout.
+*
+* PD 2.0 sinks are supposed to accept src-capabilities with a
+* 3.0 header and simply ignore any src PDOs which the sink does
+* not understand such as PPS but some 2.0 sinks instead ignore
+* the entire PD_DATA_SOURCE_CAP message, causing contract
+* negotiation to fail.
+*
+* After PD_N_HARD_RESET_COUNT hard-reset attempts, we try
+* sending src-capabilities with a lower PD revision to
+* make these broken sinks work.
+*/
+   if (port->hard_reset_count < PD_N_HARD_RESET_COUNT) {
+   tcpm_set_state(port, HARD_RESET_SEND, 0);
+   } else if (port->negotiated_rev > PD_REV20) {
+   port->negotiated_rev--;
+   port->hard_reset_count = 0;
+   tcpm_set_state(port, SRC_SEND_CAPABILITIES, 0);
+   } else {
+   tcpm_set_state(port, hard_reset_state(port), 0);
+   }
+   break;
case SRC_NEGOTIATE_CAPABILITIES:
ret = tcpm_pd_check_request(port);
if (ret < 0) {

Am Waiting For Your Urgent Respond!

[Message From Kabiru.W]

I have a business proposal for you which involves a huge amount that
run into millions of US dollars for safe keeping and investment,
please this is not a spam, its a real business that will benefit both
of us try as much as possible to get back to me on this i will explain
to you on how the business will be executed as soon as i receive your
return mail!this mail:(kabiruwahid...@gmail.com)+226 07 43 46 80.

Your Full Name………
Your Country………..
Your Personal Mobile Number………
Your Age…….
Your Sex…….
Occupation...
Best Regard
Kabiru Wahid

Your payment. Respond ASAP

[Accountant General Of Federation]

-- 
 Your payment. Respond ASAP  $5,500,000.00



DEAR SIR/MADAM,



This is to notify you that the sum of Five Million Five Hundred
Thousand United States Dollars has been approved today 6th
february,2019 as part payment. As a matter of fact, you have to adhere
to my instructions discretely to avoid distractions from intruders.
For instance, dissociate yourself completely from any person or
persons who may claim to have custody of your fund in his or her
control, be it a bank staff or government official.



Secondly, on no account should you be compelled to disclose details of
your transaction to anyone without my consent or permission. Majority
of intruders or hackers use any information they receive from you
either to cause confusion in communication or attempts to divert your
fund into their offshore accounts on the pretext that they are trying
to assist you. Such people impose distractions so that you will be
totally confused and this may hinder the success of the release of
your fund.



Be assured with all manner of humility and concern , that you will
receive the approved
sum of  $5,500,000.00 as far as you are ready to follow my
instructions without objections.



Do not hesitate to send your contact address, contact phone#  and Bank
Details so that I can in turn forward to the assigned paying bank for
verification and processing of your payment respectively.Due to my
position in the office, my reputation is my priority, therefore I do
not ask for percentage , but any token as a reward from you would be
appreciated at the end of the transaction.



You can easily call or text me on my U.S roaming phone # (424)327-5803
for further details. get back to me on my private email:
acctantdeneralde...@gmail.com



Yours sincerely,



Mr.Idris Ahmed.


Accountant General Of
Federation(-Anti Fraud Unit)
NDIC Building (1st Floor)
Plot 447/448 Constitution Avenue
Central Business District
Visit us at www.dmo.gov.ng

Dear Friend Please Respond.

[james kabore]

From:MR.JAMES KABORE.
Bill and Exchange Manager
Micro Finance Bank Plc
Burkina Faso

Dear Friend,

I know that this mail will come to you as a surprise. I am MR.JAMES
KABORE. and I am  the bill and Exchange manager in a Bank here in my
country .I Hope that you will not expose or betray this trust and
confident that i am about to Repose on you for the mutual benefit of
our both families.

I need your urgent assistance in transferring the sum of $15 million
Immediately to your account. The money has been dormant for years in
our Bank here without any body coming for it.

I want my bank to release the money to you as the nearest person to
our deceased customer the owner Of the account who died a long with
his supposed next of kin in an air Crash since July 2000.I don't want
the money to go into our Bank treasury as an abandoned fund. So this
is the reason why i contacted you, so that the bank can release the
money to you as the nearest person to the deceased customer.

Please i will like you to keep this proposal as a top secret . Upon
receipt of your reply, I will send you full details on how the
transfer will be executed and also note that you will have 40% of the
Above mentioned sum. Acknowledge receipt of this message in acceptance
of my mutual business endeavour by furnishing me with the following
information;

1. Your Full Names and Address...

2. Country... ..

3. Direct Telephone .

4. Occupation ..

Please send me your  information as soon as you reply   I will give
you full details on how you and me can claim the money from our bank.

I am waiting to receive your reply. please replied me with this email address,
james.kabor...@gmail.com


MR.JAMES KABORE
Micro Finance Bank ,
Burkina Faso

Respond for details

[Mr. Allen]

I can help you secure a private loan , should you be interested please respond 
for more details .

Thanks 
Allen 

[PATCH 4.19 104/110] rcu: Make need_resched() respond to urgent RCU-QS needs

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul E. McKenney 

commit 92aa39e9dc77481b90cbef25e547d66cab901496 upstream.

The per-CPU rcu_dynticks.rcu_urgent_qs variable communicates an urgent
need for an RCU quiescent state from the force-quiescent-state processing
within the grace-period kthread to context switches and to cond_resched().
Unfortunately, such urgent needs are not communicated to need_resched(),
which is sometimes used to decide when to invoke cond_resched(), for
but one example, within the KVM vcpu_run() function.  As of v4.15, this
can result in synchronize_sched() being delayed by up to ten seconds,
which can be problematic, to say nothing of annoying.

This commit therefore checks rcu_dynticks.rcu_urgent_qs from within
rcu_check_callbacks(), which is invoked from the scheduling-clock
interrupt handler.  If the current task is not an idle task and is
not executing in usermode, a context switch is forced, and either way,
the rcu_dynticks.rcu_urgent_qs variable is set to false.  If the current
task is an idle task, then RCU's dyntick-idle code will detect the
quiescent state, so no further action is required.  Similarly, if the
task is executing in usermode, other code in rcu_check_callbacks() and
its called functions will report the corresponding quiescent state.

Reported-by: Marius Hillenbrand 
Reported-by: David Woodhouse 
Suggested-by: Peter Zijlstra 
Signed-off-by: Paul E. McKenney 
[ paulmck: Backported to make patch apply cleanly on older versions. ]
Tested-by: Marius Hillenbrand 
Cc:  # 4.12.x - 4.19.x
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/rcu/tree.c |9 +
 1 file changed, 9 insertions(+)

--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2662,6 +2662,15 @@ void rcu_check_callbacks(int user)
rcu_bh_qs();
}
rcu_preempt_check_callbacks();
+   /* The load-acquire pairs with the store-release setting to true. */
+   if (smp_load_acquire(this_cpu_ptr(_dynticks.rcu_urgent_qs))) {
+   /* Idle and userspace execution already are quiescent states. */
+   if (!rcu_is_cpu_rrupt_from_idle() && !user) {
+   set_tsk_need_resched(current);
+   set_preempt_need_resched();
+   }
+   __this_cpu_write(rcu_dynticks.rcu_urgent_qs, false);
+   }
if (rcu_pending())
invoke_rcu_core();
 

[PATCH 4.19 104/110] rcu: Make need_resched() respond to urgent RCU-QS needs

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul E. McKenney 

commit 92aa39e9dc77481b90cbef25e547d66cab901496 upstream.

The per-CPU rcu_dynticks.rcu_urgent_qs variable communicates an urgent
need for an RCU quiescent state from the force-quiescent-state processing
within the grace-period kthread to context switches and to cond_resched().
Unfortunately, such urgent needs are not communicated to need_resched(),
which is sometimes used to decide when to invoke cond_resched(), for
but one example, within the KVM vcpu_run() function.  As of v4.15, this
can result in synchronize_sched() being delayed by up to ten seconds,
which can be problematic, to say nothing of annoying.

This commit therefore checks rcu_dynticks.rcu_urgent_qs from within
rcu_check_callbacks(), which is invoked from the scheduling-clock
interrupt handler.  If the current task is not an idle task and is
not executing in usermode, a context switch is forced, and either way,
the rcu_dynticks.rcu_urgent_qs variable is set to false.  If the current
task is an idle task, then RCU's dyntick-idle code will detect the
quiescent state, so no further action is required.  Similarly, if the
task is executing in usermode, other code in rcu_check_callbacks() and
its called functions will report the corresponding quiescent state.

Reported-by: Marius Hillenbrand 
Reported-by: David Woodhouse 
Suggested-by: Peter Zijlstra 
Signed-off-by: Paul E. McKenney 
[ paulmck: Backported to make patch apply cleanly on older versions. ]
Tested-by: Marius Hillenbrand 
Cc:  # 4.12.x - 4.19.x
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/rcu/tree.c |9 +
 1 file changed, 9 insertions(+)

--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2662,6 +2662,15 @@ void rcu_check_callbacks(int user)
rcu_bh_qs();
}
rcu_preempt_check_callbacks();
+   /* The load-acquire pairs with the store-release setting to true. */
+   if (smp_load_acquire(this_cpu_ptr(_dynticks.rcu_urgent_qs))) {
+   /* Idle and userspace execution already are quiescent states. */
+   if (!rcu_is_cpu_rrupt_from_idle() && !user) {
+   set_tsk_need_resched(current);
+   set_preempt_need_resched();
+   }
+   __this_cpu_write(rcu_dynticks.rcu_urgent_qs, false);
+   }
if (rcu_pending())
invoke_rcu_core();
 

[PATCH 4.14 095/100] rcu: Make need_resched() respond to urgent RCU-QS needs

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul E. McKenney 

commit 92aa39e9dc77481b90cbef25e547d66cab901496 upstream.

The per-CPU rcu_dynticks.rcu_urgent_qs variable communicates an urgent
need for an RCU quiescent state from the force-quiescent-state processing
within the grace-period kthread to context switches and to cond_resched().
Unfortunately, such urgent needs are not communicated to need_resched(),
which is sometimes used to decide when to invoke cond_resched(), for
but one example, within the KVM vcpu_run() function.  As of v4.15, this
can result in synchronize_sched() being delayed by up to ten seconds,
which can be problematic, to say nothing of annoying.

This commit therefore checks rcu_dynticks.rcu_urgent_qs from within
rcu_check_callbacks(), which is invoked from the scheduling-clock
interrupt handler.  If the current task is not an idle task and is
not executing in usermode, a context switch is forced, and either way,
the rcu_dynticks.rcu_urgent_qs variable is set to false.  If the current
task is an idle task, then RCU's dyntick-idle code will detect the
quiescent state, so no further action is required.  Similarly, if the
task is executing in usermode, other code in rcu_check_callbacks() and
its called functions will report the corresponding quiescent state.

Reported-by: Marius Hillenbrand 
Reported-by: David Woodhouse 
Suggested-by: Peter Zijlstra 
Signed-off-by: Paul E. McKenney 
[ paulmck: Backported to make patch apply cleanly on older versions. ]
Tested-by: Marius Hillenbrand 
Cc:  # 4.12.x - 4.19.x
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/rcu/tree.c |9 +
 1 file changed, 9 insertions(+)

--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2772,6 +2772,15 @@ void rcu_check_callbacks(int user)
rcu_bh_qs();
}
rcu_preempt_check_callbacks();
+   /* The load-acquire pairs with the store-release setting to true. */
+   if (smp_load_acquire(this_cpu_ptr(_dynticks.rcu_urgent_qs))) {
+   /* Idle and userspace execution already are quiescent states. */
+   if (!rcu_is_cpu_rrupt_from_idle() && !user) {
+   set_tsk_need_resched(current);
+   set_preempt_need_resched();
+   }
+   __this_cpu_write(rcu_dynticks.rcu_urgent_qs, false);
+   }
if (rcu_pending())
invoke_rcu_core();
if (user)

[PATCH 4.14 095/100] rcu: Make need_resched() respond to urgent RCU-QS needs

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul E. McKenney 

commit 92aa39e9dc77481b90cbef25e547d66cab901496 upstream.

The per-CPU rcu_dynticks.rcu_urgent_qs variable communicates an urgent
need for an RCU quiescent state from the force-quiescent-state processing
within the grace-period kthread to context switches and to cond_resched().
Unfortunately, such urgent needs are not communicated to need_resched(),
which is sometimes used to decide when to invoke cond_resched(), for
but one example, within the KVM vcpu_run() function.  As of v4.15, this
can result in synchronize_sched() being delayed by up to ten seconds,
which can be problematic, to say nothing of annoying.

This commit therefore checks rcu_dynticks.rcu_urgent_qs from within
rcu_check_callbacks(), which is invoked from the scheduling-clock
interrupt handler.  If the current task is not an idle task and is
not executing in usermode, a context switch is forced, and either way,
the rcu_dynticks.rcu_urgent_qs variable is set to false.  If the current
task is an idle task, then RCU's dyntick-idle code will detect the
quiescent state, so no further action is required.  Similarly, if the
task is executing in usermode, other code in rcu_check_callbacks() and
its called functions will report the corresponding quiescent state.

Reported-by: Marius Hillenbrand 
Reported-by: David Woodhouse 
Suggested-by: Peter Zijlstra 
Signed-off-by: Paul E. McKenney 
[ paulmck: Backported to make patch apply cleanly on older versions. ]
Tested-by: Marius Hillenbrand 
Cc:  # 4.12.x - 4.19.x
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/rcu/tree.c |9 +
 1 file changed, 9 insertions(+)

--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2772,6 +2772,15 @@ void rcu_check_callbacks(int user)
rcu_bh_qs();
}
rcu_preempt_check_callbacks();
+   /* The load-acquire pairs with the store-release setting to true. */
+   if (smp_load_acquire(this_cpu_ptr(_dynticks.rcu_urgent_qs))) {
+   /* Idle and userspace execution already are quiescent states. */
+   if (!rcu_is_cpu_rrupt_from_idle() && !user) {
+   set_tsk_need_resched(current);
+   set_preempt_need_resched();
+   }
+   __this_cpu_write(rcu_dynticks.rcu_urgent_qs, false);
+   }
if (rcu_pending())
invoke_rcu_core();
if (user)

Re: [PATCH RCU -stable] Make need_resched() respond to urgent RCU-QS needs

[Greg KH]

On Sun, Nov 04, 2018 at 06:34:34PM -0800, Paul E. McKenney wrote:
> commit 92aa39e9dc77 upstream.
> 
> The per-CPU rcu_dynticks.rcu_urgent_qs variable communicates an urgent
> need for an RCU quiescent state from the force-quiescent-state processing
> within the grace-period kthread to context switches and to cond_resched().
> Unfortunately, such urgent needs are not communicated to need_resched(),
> which is sometimes used to decide when to invoke cond_resched(), for
> but one example, within the KVM vcpu_run() function.  As of v4.15, this
> can result in synchronize_sched() being delayed by up to ten seconds,
> which can be problematic, to say nothing of annoying.
> 
> This commit therefore checks rcu_dynticks.rcu_urgent_qs from within
> rcu_check_callbacks(), which is invoked from the scheduling-clock
> interrupt handler.  If the current task is not an idle task and is
> not executing in usermode, a context switch is forced, and either way,
> the rcu_dynticks.rcu_urgent_qs variable is set to false.  If the current
> task is an idle task, then RCU's dyntick-idle code will detect the
> quiescent state, so no further action is required.  Similarly, if the
> task is executing in usermode, other code in rcu_check_callbacks() and
> its called functions will report the corresponding quiescent state.
> 
> Reported-by: Marius Hillenbrand 
> Reported-by: David Woodhouse 
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Paul E. McKenney 
> [ paulmck: Backported to make patch apply cleanly on older versions. ]
> Tested-by: Marius Hillenbrand 
> Cc:  # 4.12.x - 4.19.x
> 

Now queued up, thanks.

greg k-h

Re: [PATCH RCU -stable] Make need_resched() respond to urgent RCU-QS needs

[Greg KH]

On Sun, Nov 04, 2018 at 06:34:34PM -0800, Paul E. McKenney wrote:
> commit 92aa39e9dc77 upstream.
> 
> The per-CPU rcu_dynticks.rcu_urgent_qs variable communicates an urgent
> need for an RCU quiescent state from the force-quiescent-state processing
> within the grace-period kthread to context switches and to cond_resched().
> Unfortunately, such urgent needs are not communicated to need_resched(),
> which is sometimes used to decide when to invoke cond_resched(), for
> but one example, within the KVM vcpu_run() function.  As of v4.15, this
> can result in synchronize_sched() being delayed by up to ten seconds,
> which can be problematic, to say nothing of annoying.
> 
> This commit therefore checks rcu_dynticks.rcu_urgent_qs from within
> rcu_check_callbacks(), which is invoked from the scheduling-clock
> interrupt handler.  If the current task is not an idle task and is
> not executing in usermode, a context switch is forced, and either way,
> the rcu_dynticks.rcu_urgent_qs variable is set to false.  If the current
> task is an idle task, then RCU's dyntick-idle code will detect the
> quiescent state, so no further action is required.  Similarly, if the
> task is executing in usermode, other code in rcu_check_callbacks() and
> its called functions will report the corresponding quiescent state.
> 
> Reported-by: Marius Hillenbrand 
> Reported-by: David Woodhouse 
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Paul E. McKenney 
> [ paulmck: Backported to make patch apply cleanly on older versions. ]
> Tested-by: Marius Hillenbrand 
> Cc:  # 4.12.x - 4.19.x
> 

Now queued up, thanks.

greg k-h

Dear Urgent Respond,

[David Cooper]

Sorry to have contacted you through this medium without a 
previous notice; I had to use the email because it is the easiest 
and more confidential way of making contact with people around 
the world.

This communication is to inform you that we have programmed your 
payment of the $10,000.000.00 USD to be received by you in person 
, you are further not expected to pay a dime for the receiving of 
your funds and anybody who asks you to pay money must be lying to 
you. We have worked out all the modality for you to receive your 
funds without any further lapses.

The $10,000.000.00 USD funds is currently in our corresponding 
vault in Holland now, and for security purpose we have to moved 
the documentation to our corresponding vault in South America 
where you need to come in person to sign your transfer 
legalization paper work.

We have further arranged to pay your flight cost and hotel 
reservation for the trip, so that as soon as your funds are 
received by you then you can reimburse me of all the expenses 
that i made for your trip to South America where the legalization 
materials will be sign and giving to you in person to bring along 
to the paying Bank in Holland.

You should also note that the mode of sharing ratio is 60% for 
you and 30% for me while I will take 10% for all expenses.

Thank you for your cooperation and understanding as I look 
forward to helping you receive your funds without any hitches.

Expect your valued response.

Regards
Mr David Cooper

Dear Urgent Respond,

[David Cooper]

Sorry to have contacted you through this medium without a 
previous notice; I had to use the email because it is the easiest 
and more confidential way of making contact with people around 
the world.

This communication is to inform you that we have programmed your 
payment of the $10,000.000.00 USD to be received by you in person 
, you are further not expected to pay a dime for the receiving of 
your funds and anybody who asks you to pay money must be lying to 
you. We have worked out all the modality for you to receive your 
funds without any further lapses.

The $10,000.000.00 USD funds is currently in our corresponding 
vault in Holland now, and for security purpose we have to moved 
the documentation to our corresponding vault in South America 
where you need to come in person to sign your transfer 
legalization paper work.

We have further arranged to pay your flight cost and hotel 
reservation for the trip, so that as soon as your funds are 
received by you then you can reimburse me of all the expenses 
that i made for your trip to South America where the legalization 
materials will be sign and giving to you in person to bring along 
to the paying Bank in Holland.

You should also note that the mode of sharing ratio is 60% for 
you and 30% for me while I will take 10% for all expenses.

Thank you for your cooperation and understanding as I look 
forward to helping you receive your funds without any hitches.

Expect your valued response.

Regards
Mr David Cooper

Dear Urgent Respond,

[David Cooper]

Sorry to have contacted you through this medium without a 
previous notice; I had to use the email because it is the easiest 
and more confidential way of making contact with people around 
the world.

This communication is to inform you that we have programmed your 
payment of the $10,000.000.00 USD to be received by you in person 
, you are further not expected to pay a dime for the receiving of 
your funds and anybody who asks you to pay money must be lying to 
you. We have worked out all the modality for you to receive your 
funds without any further lapses.

The $10,000.000.00 USD funds is currently in our corresponding 
vault in Holland now, and for security purpose we have to moved 
the documentation to our corresponding vault in South America 
where you need to come in person to sign your transfer 
legalization paper work.

We have further arranged to pay your flight cost and hotel 
reservation for the trip, so that as soon as your funds are 
received by you then you can reimburse me of all the expenses 
that i made for your trip to South America where the legalization 
materials will be sign and giving to you in person to bring along 
to the paying Bank in Holland.

You should also note that the mode of sharing ratio is 60% for 
you and 30% for me while I will take 10% for all expenses.

Thank you for your cooperation and understanding as I look 
forward to helping you receive your funds without any hitches.

Expect your valued response.

Regards
Mr David Cooper

Dear Urgent Respond,

[David Cooper]

Sorry to have contacted you through this medium without a 
previous notice; I had to use the email because it is the easiest 
and more confidential way of making contact with people around 
the world.

This communication is to inform you that we have programmed your 
payment of the $10,000.000.00 USD to be received by you in person 
, you are further not expected to pay a dime for the receiving of 
your funds and anybody who asks you to pay money must be lying to 
you. We have worked out all the modality for you to receive your 
funds without any further lapses.

The $10,000.000.00 USD funds is currently in our corresponding 
vault in Holland now, and for security purpose we have to moved 
the documentation to our corresponding vault in South America 
where you need to come in person to sign your transfer 
legalization paper work.

We have further arranged to pay your flight cost and hotel 
reservation for the trip, so that as soon as your funds are 
received by you then you can reimburse me of all the expenses 
that i made for your trip to South America where the legalization 
materials will be sign and giving to you in person to bring along 
to the paying Bank in Holland.

You should also note that the mode of sharing ratio is 60% for 
you and 30% for me while I will take 10% for all expenses.

Thank you for your cooperation and understanding as I look 
forward to helping you receive your funds without any hitches.

Expect your valued response.

Regards
Mr David Cooper

Dear Urgent Respond,

[David Cooper]

Sorry to have contacted you through this medium without a 
previous notice; I had to use the email because it is the easiest 
and more confidential way of making contact with people around 
the world.

This communication is to inform you that we have programmed your 
payment of the $10,000.000.00 USD to be received by you in person 
, you are further not expected to pay a dime for the receiving of 
your funds and anybody who asks you to pay money must be lying to 
you. We have worked out all the modality for you to receive your 
funds without any further lapses.

The $10,000.000.00 USD funds is currently in our corresponding 
vault in Holland now, and for security purpose we have to moved 
the documentation to our corresponding vault in South America 
where you need to come in person to sign your transfer 
legalization paper work.

We have further arranged to pay your flight cost and hotel 
reservation for the trip, so that as soon as your funds are 
received by you then you can reimburse me of all the expenses 
that i made for your trip to South America where the legalization 
materials will be sign and giving to you in person to bring along 
to the paying Bank in Holland.

You should also note that the mode of sharing ratio is 60% for 
you and 30% for me while I will take 10% for all expenses.

Thank you for your cooperation and understanding as I look 
forward to helping you receive your funds without any hitches.

Expect your valued response.

Regards
Mr David Cooper

Dear Urgent Respond,

[David Cooper]

Sorry to have contacted you through this medium without a 
previous notice; I had to use the email because it is the easiest 
and more confidential way of making contact with people around 
the world.

This communication is to inform you that we have programmed your 
payment of the $10,000.000.00 USD to be received by you in person 
, you are further not expected to pay a dime for the receiving of 
your funds and anybody who asks you to pay money must be lying to 
you. We have worked out all the modality for you to receive your 
funds without any further lapses.

The $10,000.000.00 USD funds is currently in our corresponding 
vault in Holland now, and for security purpose we have to moved 
the documentation to our corresponding vault in South America 
where you need to come in person to sign your transfer 
legalization paper work.

We have further arranged to pay your flight cost and hotel 
reservation for the trip, so that as soon as your funds are 
received by you then you can reimburse me of all the expenses 
that i made for your trip to South America where the legalization 
materials will be sign and giving to you in person to bring along 
to the paying Bank in Holland.

You should also note that the mode of sharing ratio is 60% for 
you and 30% for me while I will take 10% for all expenses.

Thank you for your cooperation and understanding as I look 
forward to helping you receive your funds without any hitches.

Expect your valued response.

Regards
Mr David Cooper

Urgent Respond Needed

[Ibrahim Mohammed]

I need am Honest Person to support and your cooperation with me in business of 
$26,700,000.00 thanks.

Urgent Respond Needed

[Ibrahim Mohammed]

I need am Honest Person to support and your cooperation with me in business of 
$26,700,000.00 thanks.

Please kindly respond

[Mrs. Nadesh]

--
Greetings,

I am Mrs. Nadesh aging widow of 64 years old suffering from long time 
illness.I have some funds I inherited from my late husband, the sum of 
($15,500,000.00 Million Dollars) and I needed a very honest and God 
fearing who can withdraw this money this funds use it for Charity works.
I found your email address from the internet after honest prayers to 
the LORD to bring me a helper and i decided to contact you if you may 
be willing and interested to handle these trust funds in good faith. 
More detail will be giving after recievig your reply.

Warmest Regards,
Mrs. Nadesh
--

Please kindly respond

[Mrs. Nadesh]

--
Greetings,

I am Mrs. Nadesh aging widow of 64 years old suffering from long time 
illness.I have some funds I inherited from my late husband, the sum of 
($15,500,000.00 Million Dollars) and I needed a very honest and God 
fearing who can withdraw this money this funds use it for Charity works.
I found your email address from the internet after honest prayers to 
the LORD to bring me a helper and i decided to contact you if you may 
be willing and interested to handle these trust funds in good faith. 
More detail will be giving after recievig your reply.

Warmest Regards,
Mrs. Nadesh
--

[PATCH RCU -stable] Make need_resched() respond to urgent RCU-QS needs

[Paul E. McKenney]

commit 92aa39e9dc77 upstream.

The per-CPU rcu_dynticks.rcu_urgent_qs variable communicates an urgent
need for an RCU quiescent state from the force-quiescent-state processing
within the grace-period kthread to context switches and to cond_resched().
Unfortunately, such urgent needs are not communicated to need_resched(),
which is sometimes used to decide when to invoke cond_resched(), for
but one example, within the KVM vcpu_run() function.  As of v4.15, this
can result in synchronize_sched() being delayed by up to ten seconds,
which can be problematic, to say nothing of annoying.

This commit therefore checks rcu_dynticks.rcu_urgent_qs from within
rcu_check_callbacks(), which is invoked from the scheduling-clock
interrupt handler.  If the current task is not an idle task and is
not executing in usermode, a context switch is forced, and either way,
the rcu_dynticks.rcu_urgent_qs variable is set to false.  If the current
task is an idle task, then RCU's dyntick-idle code will detect the
quiescent state, so no further action is required.  Similarly, if the
task is executing in usermode, other code in rcu_check_callbacks() and
its called functions will report the corresponding quiescent state.

Reported-by: Marius Hillenbrand 
Reported-by: David Woodhouse 
Suggested-by: Peter Zijlstra 
Signed-off-by: Paul E. McKenney 
[ paulmck: Backported to make patch apply cleanly on older versions. ]
Tested-by: Marius Hillenbrand 
Cc:  # 4.12.x - 4.19.x

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0b760c1369f7..15301ed19da6 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2662,6 +2662,15 @@ void rcu_check_callbacks(int user)
rcu_bh_qs();
}
rcu_preempt_check_callbacks();
+   /* The load-acquire pairs with the store-release setting to true. */
+   if (smp_load_acquire(this_cpu_ptr(_dynticks.rcu_urgent_qs))) {
+   /* Idle and userspace execution already are quiescent states. */
+   if (!rcu_is_cpu_rrupt_from_idle() && !user) {
+   set_tsk_need_resched(current);
+   set_preempt_need_resched();
+   }
+   __this_cpu_write(rcu_dynticks.rcu_urgent_qs, false);
+   }
if (rcu_pending())
invoke_rcu_core();
 

[PATCH RCU -stable] Make need_resched() respond to urgent RCU-QS needs

[Paul E. McKenney]

commit 92aa39e9dc77 upstream.

The per-CPU rcu_dynticks.rcu_urgent_qs variable communicates an urgent
need for an RCU quiescent state from the force-quiescent-state processing
within the grace-period kthread to context switches and to cond_resched().
Unfortunately, such urgent needs are not communicated to need_resched(),
which is sometimes used to decide when to invoke cond_resched(), for
but one example, within the KVM vcpu_run() function.  As of v4.15, this
can result in synchronize_sched() being delayed by up to ten seconds,
which can be problematic, to say nothing of annoying.

This commit therefore checks rcu_dynticks.rcu_urgent_qs from within
rcu_check_callbacks(), which is invoked from the scheduling-clock
interrupt handler.  If the current task is not an idle task and is
not executing in usermode, a context switch is forced, and either way,
the rcu_dynticks.rcu_urgent_qs variable is set to false.  If the current
task is an idle task, then RCU's dyntick-idle code will detect the
quiescent state, so no further action is required.  Similarly, if the
task is executing in usermode, other code in rcu_check_callbacks() and
its called functions will report the corresponding quiescent state.

Reported-by: Marius Hillenbrand 
Reported-by: David Woodhouse 
Suggested-by: Peter Zijlstra 
Signed-off-by: Paul E. McKenney 
[ paulmck: Backported to make patch apply cleanly on older versions. ]
Tested-by: Marius Hillenbrand 
Cc:  # 4.12.x - 4.19.x

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0b760c1369f7..15301ed19da6 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2662,6 +2662,15 @@ void rcu_check_callbacks(int user)
rcu_bh_qs();
}
rcu_preempt_check_callbacks();
+   /* The load-acquire pairs with the store-release setting to true. */
+   if (smp_load_acquire(this_cpu_ptr(_dynticks.rcu_urgent_qs))) {
+   /* Idle and userspace execution already are quiescent states. */
+   if (!rcu_is_cpu_rrupt_from_idle() && !user) {
+   set_tsk_need_resched(current);
+   set_preempt_need_resched();
+   }
+   __this_cpu_write(rcu_dynticks.rcu_urgent_qs, false);
+   }
if (rcu_pending())
invoke_rcu_core();
 

Please kindly respond

[Mrs. Nadesh]

--
Greetings,

I am Mrs. Nadesh aging widow of 64 years old suffering from long time 
illness.I have some funds I inherited from my late husband, the sum of 
($15,500,000.00 Million Dollars) and I needed a very honest and God 
fearing who can withdraw this money this funds use it for Charity works.
I found your email address from the internet after honest prayers to 
the LORD to bring me a helper and i decided to contact you if you may 
be willing and interested to handle these trust funds in good faith. 
More detail will be giving after recievig your reply.

Warmest Regards,
Mrs. Nadesh
--

Please kindly respond

[Mrs. Nadesh]

--
Greetings,

I am Mrs. Nadesh aging widow of 64 years old suffering from long time 
illness.I have some funds I inherited from my late husband, the sum of 
($15,500,000.00 Million Dollars) and I needed a very honest and God 
fearing who can withdraw this money this funds use it for Charity works.
I found your email address from the internet after honest prayers to 
the LORD to bring me a helper and i decided to contact you if you may 
be willing and interested to handle these trust funds in good faith. 
More detail will be giving after recievig your reply.

Warmest Regards,
Mrs. Nadesh
--

Please kindly respond quickly for further details through my private e_mail address:(adama...@yahoo.com)

[Mrs.Fatim Adama]

--
Greetings,

I am Mrs.Fatim Adama aging widow of 62 years old suffering from long 
time
illness.I have some funds I inherited from my late husband, the sum of
($18,500,000.00 Million Dollars) and I needed a very honest and God
fearing who can withdraw this money this funds use it for Charity
works.I found your email address from the internet after honest
prayers to the LORD to bring me a helper and i decided to contact you
if you may be willing and interested to handle these trust funds in
good faith. More detail will be giving after receiving your reply.

Warmest Regards,
Mrs.Fatim Adama.
--

Please kindly respond quickly for further details through my private e_mail address:(adama...@yahoo.com)

[Mrs.Fatim Adama]

--
Greetings,

I am Mrs.Fatim Adama aging widow of 62 years old suffering from long 
time
illness.I have some funds I inherited from my late husband, the sum of
($18,500,000.00 Million Dollars) and I needed a very honest and God
fearing who can withdraw this money this funds use it for Charity
works.I found your email address from the internet after honest
prayers to the LORD to bring me a helper and i decided to contact you
if you may be willing and interested to handle these trust funds in
good faith. More detail will be giving after receiving your reply.

Warmest Regards,
Mrs.Fatim Adama.
--

Please Respond to me................

[Mr Moris Ortega]

-- 
Good day,

I am Mr.Moris Ortega, a bank Manager with the Bank Of Africa Burkina
Faso West Africa. I have a transaction of $10.5 Million US dollars
only i need  your assistance. I would like to discuss with you in
details once i get your response.

Waiting for your urgent response.

Yours Faithfully,
Thanks and best regards,

Mr Moris Ortega
+226 66 610 480.

Please Respond to me................

[Mr Moris Ortega]

-- 
Good day,

I am Mr.Moris Ortega, a bank Manager with the Bank Of Africa Burkina
Faso West Africa. I have a transaction of $10.5 Million US dollars
only i need  your assistance. I would like to discuss with you in
details once i get your response.

Waiting for your urgent response.

Yours Faithfully,
Thanks and best regards,

Mr Moris Ortega
+226 66 610 480.

Please kindly respond quickly for further details through my private e_mail address:(adama...@yahoo.com)

[Mrs.Fatim Adama]

Greetings,

I am Mrs.Fatim Adama. aging widow of 62 years old suffering from long 
time illness.I have some funds I inherited from my late husband, the 
sum of ($18,500,000.00 Million Dollars) and I needed a very honest and 
God fearing who can withdraw this money the funds use it for Charity 
works.I found your email address from the internet after honest prayers 
to the LORD to bring me a helper and i decided to contact you if you 
may be willing and interested to handle these trust funds in good 
faith. More detail will be giving after recidivism your reply.

Warmest Regards,
Mrs.Fatim Adama.

Please kindly respond quickly for further details through my private e_mail address:(adama...@yahoo.com)

[Mrs.Fatim Adama]

Greetings,

I am Mrs.Fatim Adama. aging widow of 62 years old suffering from long 
time illness.I have some funds I inherited from my late husband, the 
sum of ($18,500,000.00 Million Dollars) and I needed a very honest and 
God fearing who can withdraw this money the funds use it for Charity 
works.I found your email address from the internet after honest prayers 
to the LORD to bring me a helper and i decided to contact you if you 
may be willing and interested to handle these trust funds in good 
faith. More detail will be giving after recidivism your reply.

Warmest Regards,
Mrs.Fatim Adama.

Please kindly respond

[Mrs. Nadesh]

--
Greetings,

I am Mrs. Nadesh aging widow of 64 years old suffering from long time 
illness.I have some funds I inherited from my late husband, the sum of 
($15,500,000.00 Million Dollars) and I needed a very honest and God 
fearing who can withdraw this money ths funds use it for Charity works.
I found your email address from the internet after honest prayers to 
the LORD to bring me a helper and i decided to contact you if you may 
be willing and interested to handle these trust funds in good faith. 
More detail will be giving after recievig your reply.

Warmest Regards,
Mrs. Nadesh
--

Please kindly respond

[Mrs. Nadesh]

--
Greetings,

I am Mrs. Nadesh aging widow of 64 years old suffering from long time 
illness.I have some funds I inherited from my late husband, the sum of 
($15,500,000.00 Million Dollars) and I needed a very honest and God 
fearing who can withdraw this money ths funds use it for Charity works.
I found your email address from the internet after honest prayers to 
the LORD to bring me a helper and i decided to contact you if you may 
be willing and interested to handle these trust funds in good faith. 
More detail will be giving after recievig your reply.

Warmest Regards,
Mrs. Nadesh
--

Please Respond to me................

[Mr Moris Ortega]

-- 
Greetings to you and your families,

I never want to disturb you at all but will like you give me your
attention. I need a matured and capable hand in a business deal of
$10.5 million US dollars.(Ten Million Five Hundred Thousand USA
Dollars) I belief you are suitable to handle such project perfectly
.Please answer me.For more details.All details shall be sent to you
once I hear from you. Sorry if you received this letter in your spam,
Due to recent connection error here in my country.

Thanks and best regards,

Mr.Moris Ortega
+226 66 610 480.

Please Respond to me................

[Mr Moris Ortega]

-- 
Greetings to you and your families,

I never want to disturb you at all but will like you give me your
attention. I need a matured and capable hand in a business deal of
$10.5 million US dollars.(Ten Million Five Hundred Thousand USA
Dollars) I belief you are suitable to handle such project perfectly
.Please answer me.For more details.All details shall be sent to you
once I hear from you. Sorry if you received this letter in your spam,
Due to recent connection error here in my country.

Thanks and best regards,

Mr.Moris Ortega
+226 66 610 480.

Please respond urgently!

[Ahmed Hassan]

Dear Friend,

I know that this mail will come to you as a surprise as we have never met 
before, but need not to worry as I am contacting you independently of my 
investigation and no one is informed of this communication. I need your urgent 
assistance in transferring the sum of $11.3million immediately to your private 
account.The money has been here in our Bank lying dormant for years now without 
anybody coming for the claim of it.

I want to release the money to you as the relative to our deceased customer 
(the account owner) who died a long with his supposed NEXT OF KIN since 16th 
October 2005. The Banking laws here does not allow such money to stay more than 
13 years, because the money will be recalled to the Bank treasury account as 
unclaimed fund.

By indicating your interest I will send you the full details on how the 
business will be executed.

Please respond urgently and delete if you are not interested.

Best Regards,
Mr. Ahmed Hassan.

Please respond urgently!

[Ahmed Hassan]

Dear Friend,

I know that this mail will come to you as a surprise as we have never met 
before, but need not to worry as I am contacting you independently of my 
investigation and no one is informed of this communication. I need your urgent 
assistance in transferring the sum of $11.3million immediately to your private 
account.The money has been here in our Bank lying dormant for years now without 
anybody coming for the claim of it.

I want to release the money to you as the relative to our deceased customer 
(the account owner) who died a long with his supposed NEXT OF KIN since 16th 
October 2005. The Banking laws here does not allow such money to stay more than 
13 years, because the money will be recalled to the Bank treasury account as 
unclaimed fund.

By indicating your interest I will send you the full details on how the 
business will be executed.

Please respond urgently and delete if you are not interested.

Best Regards,
Mr. Ahmed Hassan.

[PATCH 3.18 08/85] scsi: iscsi: respond to netlink with unicast when appropriate

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Chris Leech 

[ Upstream commit af17092810a887178195276255b7b31f8fbe7dbe ]

Instead of always multicasting responses, send a unicast netlink message
directed at the correct pid.  This will be needed if we ever want to
support multiple userspace processes interacting with the kernel over
iSCSI netlink simultaneously.  Limitations can currently be seen if you
attempt to run multiple iscsistart commands in parallel.

We've fixed up the userspace issues in iscsistart that prevented
multiple instances from running, so now attempts to speed up booting by
bringing up multiple iscsi sessions at once in the initramfs are just
running into misrouted responses that this fixes.

Signed-off-by: Chris Leech 
Reviewed-by: Lee Duncan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/scsi/scsi_transport_iscsi.c |   29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2343,6 +2343,12 @@ iscsi_multicast_skb(struct sk_buff *skb,
return nlmsg_multicast(nls, skb, 0, group, gfp);
 }
 
+static int
+iscsi_unicast_skb(struct sk_buff *skb, u32 portid)
+{
+   return nlmsg_unicast(nls, skb, portid);
+}
+
 int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct iscsi_hdr *hdr,
   char *data, uint32_t data_size)
 {
@@ -2545,14 +2551,11 @@ void iscsi_ping_comp_event(uint32_t host
 EXPORT_SYMBOL_GPL(iscsi_ping_comp_event);
 
 static int
-iscsi_if_send_reply(uint32_t group, int seq, int type, int done, int multi,
-   void *payload, int size)
+iscsi_if_send_reply(u32 portid, int type, void *payload, int size)
 {
struct sk_buff  *skb;
struct nlmsghdr *nlh;
int len = nlmsg_total_size(size);
-   int flags = multi ? NLM_F_MULTI : 0;
-   int t = done ? NLMSG_DONE : type;
 
skb = alloc_skb(len, GFP_ATOMIC);
if (!skb) {
@@ -2560,10 +2563,9 @@ iscsi_if_send_reply(uint32_t group, int
return -ENOMEM;
}
 
-   nlh = __nlmsg_put(skb, 0, 0, t, (len - sizeof(*nlh)), 0);
-   nlh->nlmsg_flags = flags;
+   nlh = __nlmsg_put(skb, 0, 0, type, (len - sizeof(*nlh)), 0);
memcpy(nlmsg_data(nlh), payload, size);
-   return iscsi_multicast_skb(skb, group, GFP_ATOMIC);
+   return iscsi_unicast_skb(skb, portid);
 }
 
 static int
@@ -3490,6 +3492,7 @@ static int
 iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
 {
int err = 0;
+   u32 portid;
struct iscsi_uevent *ev = nlmsg_data(nlh);
struct iscsi_transport *transport = NULL;
struct iscsi_internal *priv;
@@ -3510,10 +3513,12 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
if (!try_module_get(transport->owner))
return -EINVAL;
 
+   portid = NETLINK_CB(skb).portid;
+
switch (nlh->nlmsg_type) {
case ISCSI_UEVENT_CREATE_SESSION:
err = iscsi_if_create_session(priv, ep, ev,
- NETLINK_CB(skb).portid,
+ portid,
  ev->u.c_session.initial_cmdsn,
  ev->u.c_session.cmds_max,
  ev->u.c_session.queue_depth);
@@ -3526,7 +3531,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
}
 
err = iscsi_if_create_session(priv, ep, ev,
-   NETLINK_CB(skb).portid,
+   portid,
ev->u.c_bound_session.initial_cmdsn,
ev->u.c_bound_session.cmds_max,
ev->u.c_bound_session.queue_depth);
@@ -3684,6 +3689,8 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
 static void
 iscsi_if_rx(struct sk_buff *skb)
 {
+   u32 portid = NETLINK_CB(skb).portid;
+
mutex_lock(_queue_mutex);
while (skb->len >= NLMSG_HDRLEN) {
int err;
@@ -3719,8 +3726,8 @@ iscsi_if_rx(struct sk_buff *skb)
break;
if (ev->type == ISCSI_UEVENT_GET_CHAP && !err)
break;
-   err = iscsi_if_send_reply(group, nlh->nlmsg_seq,
-   nlh->nlmsg_type, 0, 0, ev, sizeof(*ev));
+   err = iscsi_if_send_reply(portid, nlh->nlmsg_type,
+ ev, sizeof(*ev));
} while (err < 0 && err != -ECONNREFUSED && err != -ESRCH);
skb_pull(skb, rlen);
}

[PATCH 3.18 08/85] scsi: iscsi: respond to netlink with unicast when appropriate

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Chris Leech 

[ Upstream commit af17092810a887178195276255b7b31f8fbe7dbe ]

Instead of always multicasting responses, send a unicast netlink message
directed at the correct pid.  This will be needed if we ever want to
support multiple userspace processes interacting with the kernel over
iSCSI netlink simultaneously.  Limitations can currently be seen if you
attempt to run multiple iscsistart commands in parallel.

We've fixed up the userspace issues in iscsistart that prevented
multiple instances from running, so now attempts to speed up booting by
bringing up multiple iscsi sessions at once in the initramfs are just
running into misrouted responses that this fixes.

Signed-off-by: Chris Leech 
Reviewed-by: Lee Duncan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/scsi/scsi_transport_iscsi.c |   29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2343,6 +2343,12 @@ iscsi_multicast_skb(struct sk_buff *skb,
return nlmsg_multicast(nls, skb, 0, group, gfp);
 }
 
+static int
+iscsi_unicast_skb(struct sk_buff *skb, u32 portid)
+{
+   return nlmsg_unicast(nls, skb, portid);
+}
+
 int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct iscsi_hdr *hdr,
   char *data, uint32_t data_size)
 {
@@ -2545,14 +2551,11 @@ void iscsi_ping_comp_event(uint32_t host
 EXPORT_SYMBOL_GPL(iscsi_ping_comp_event);
 
 static int
-iscsi_if_send_reply(uint32_t group, int seq, int type, int done, int multi,
-   void *payload, int size)
+iscsi_if_send_reply(u32 portid, int type, void *payload, int size)
 {
struct sk_buff  *skb;
struct nlmsghdr *nlh;
int len = nlmsg_total_size(size);
-   int flags = multi ? NLM_F_MULTI : 0;
-   int t = done ? NLMSG_DONE : type;
 
skb = alloc_skb(len, GFP_ATOMIC);
if (!skb) {
@@ -2560,10 +2563,9 @@ iscsi_if_send_reply(uint32_t group, int
return -ENOMEM;
}
 
-   nlh = __nlmsg_put(skb, 0, 0, t, (len - sizeof(*nlh)), 0);
-   nlh->nlmsg_flags = flags;
+   nlh = __nlmsg_put(skb, 0, 0, type, (len - sizeof(*nlh)), 0);
memcpy(nlmsg_data(nlh), payload, size);
-   return iscsi_multicast_skb(skb, group, GFP_ATOMIC);
+   return iscsi_unicast_skb(skb, portid);
 }
 
 static int
@@ -3490,6 +3492,7 @@ static int
 iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
 {
int err = 0;
+   u32 portid;
struct iscsi_uevent *ev = nlmsg_data(nlh);
struct iscsi_transport *transport = NULL;
struct iscsi_internal *priv;
@@ -3510,10 +3513,12 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
if (!try_module_get(transport->owner))
return -EINVAL;
 
+   portid = NETLINK_CB(skb).portid;
+
switch (nlh->nlmsg_type) {
case ISCSI_UEVENT_CREATE_SESSION:
err = iscsi_if_create_session(priv, ep, ev,
- NETLINK_CB(skb).portid,
+ portid,
  ev->u.c_session.initial_cmdsn,
  ev->u.c_session.cmds_max,
  ev->u.c_session.queue_depth);
@@ -3526,7 +3531,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
}
 
err = iscsi_if_create_session(priv, ep, ev,
-   NETLINK_CB(skb).portid,
+   portid,
ev->u.c_bound_session.initial_cmdsn,
ev->u.c_bound_session.cmds_max,
ev->u.c_bound_session.queue_depth);
@@ -3684,6 +3689,8 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
 static void
 iscsi_if_rx(struct sk_buff *skb)
 {
+   u32 portid = NETLINK_CB(skb).portid;
+
mutex_lock(_queue_mutex);
while (skb->len >= NLMSG_HDRLEN) {
int err;
@@ -3719,8 +3726,8 @@ iscsi_if_rx(struct sk_buff *skb)
break;
if (ev->type == ISCSI_UEVENT_GET_CHAP && !err)
break;
-   err = iscsi_if_send_reply(group, nlh->nlmsg_seq,
-   nlh->nlmsg_type, 0, 0, ev, sizeof(*ev));
+   err = iscsi_if_send_reply(portid, nlh->nlmsg_type,
+ ev, sizeof(*ev));
} while (err < 0 && err != -ECONNREFUSED && err != -ESRCH);
skb_pull(skb, rlen);
}

[PATCH 4.16 051/279] scsi: iscsi: respond to netlink with unicast when appropriate

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Chris Leech 

[ Upstream commit af17092810a887178195276255b7b31f8fbe7dbe ]

Instead of always multicasting responses, send a unicast netlink message
directed at the correct pid.  This will be needed if we ever want to
support multiple userspace processes interacting with the kernel over
iSCSI netlink simultaneously.  Limitations can currently be seen if you
attempt to run multiple iscsistart commands in parallel.

We've fixed up the userspace issues in iscsistart that prevented
multiple instances from running, so now attempts to speed up booting by
bringing up multiple iscsi sessions at once in the initramfs are just
running into misrouted responses that this fixes.

Signed-off-by: Chris Leech 
Reviewed-by: Lee Duncan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/scsi/scsi_transport_iscsi.c |   29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2322,6 +2322,12 @@ iscsi_multicast_skb(struct sk_buff *skb,
return nlmsg_multicast(nls, skb, 0, group, gfp);
 }
 
+static int
+iscsi_unicast_skb(struct sk_buff *skb, u32 portid)
+{
+   return nlmsg_unicast(nls, skb, portid);
+}
+
 int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct iscsi_hdr *hdr,
   char *data, uint32_t data_size)
 {
@@ -2524,14 +2530,11 @@ void iscsi_ping_comp_event(uint32_t host
 EXPORT_SYMBOL_GPL(iscsi_ping_comp_event);
 
 static int
-iscsi_if_send_reply(uint32_t group, int seq, int type, int done, int multi,
-   void *payload, int size)
+iscsi_if_send_reply(u32 portid, int type, void *payload, int size)
 {
struct sk_buff  *skb;
struct nlmsghdr *nlh;
int len = nlmsg_total_size(size);
-   int flags = multi ? NLM_F_MULTI : 0;
-   int t = done ? NLMSG_DONE : type;
 
skb = alloc_skb(len, GFP_ATOMIC);
if (!skb) {
@@ -2539,10 +2542,9 @@ iscsi_if_send_reply(uint32_t group, int
return -ENOMEM;
}
 
-   nlh = __nlmsg_put(skb, 0, 0, t, (len - sizeof(*nlh)), 0);
-   nlh->nlmsg_flags = flags;
+   nlh = __nlmsg_put(skb, 0, 0, type, (len - sizeof(*nlh)), 0);
memcpy(nlmsg_data(nlh), payload, size);
-   return iscsi_multicast_skb(skb, group, GFP_ATOMIC);
+   return iscsi_unicast_skb(skb, portid);
 }
 
 static int
@@ -3470,6 +3472,7 @@ static int
 iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
 {
int err = 0;
+   u32 portid;
struct iscsi_uevent *ev = nlmsg_data(nlh);
struct iscsi_transport *transport = NULL;
struct iscsi_internal *priv;
@@ -3490,10 +3493,12 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
if (!try_module_get(transport->owner))
return -EINVAL;
 
+   portid = NETLINK_CB(skb).portid;
+
switch (nlh->nlmsg_type) {
case ISCSI_UEVENT_CREATE_SESSION:
err = iscsi_if_create_session(priv, ep, ev,
- NETLINK_CB(skb).portid,
+ portid,
  ev->u.c_session.initial_cmdsn,
  ev->u.c_session.cmds_max,
  ev->u.c_session.queue_depth);
@@ -3506,7 +3511,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
}
 
err = iscsi_if_create_session(priv, ep, ev,
-   NETLINK_CB(skb).portid,
+   portid,
ev->u.c_bound_session.initial_cmdsn,
ev->u.c_bound_session.cmds_max,
ev->u.c_bound_session.queue_depth);
@@ -3664,6 +3669,8 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
 static void
 iscsi_if_rx(struct sk_buff *skb)
 {
+   u32 portid = NETLINK_CB(skb).portid;
+
mutex_lock(_queue_mutex);
while (skb->len >= NLMSG_HDRLEN) {
int err;
@@ -3699,8 +3706,8 @@ iscsi_if_rx(struct sk_buff *skb)
break;
if (ev->type == ISCSI_UEVENT_GET_CHAP && !err)
break;
-   err = iscsi_if_send_reply(group, nlh->nlmsg_seq,
-   nlh->nlmsg_type, 0, 0, ev, sizeof(*ev));
+   err = iscsi_if_send_reply(portid, nlh->nlmsg_type,
+ ev, sizeof(*ev));
} while (err < 0 && err != -ECONNREFUSED && err != -ESRCH);
skb_pull(skb, rlen);
}

[PATCH 4.16 051/279] scsi: iscsi: respond to netlink with unicast when appropriate

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Chris Leech 

[ Upstream commit af17092810a887178195276255b7b31f8fbe7dbe ]

Instead of always multicasting responses, send a unicast netlink message
directed at the correct pid.  This will be needed if we ever want to
support multiple userspace processes interacting with the kernel over
iSCSI netlink simultaneously.  Limitations can currently be seen if you
attempt to run multiple iscsistart commands in parallel.

We've fixed up the userspace issues in iscsistart that prevented
multiple instances from running, so now attempts to speed up booting by
bringing up multiple iscsi sessions at once in the initramfs are just
running into misrouted responses that this fixes.

Signed-off-by: Chris Leech 
Reviewed-by: Lee Duncan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/scsi/scsi_transport_iscsi.c |   29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2322,6 +2322,12 @@ iscsi_multicast_skb(struct sk_buff *skb,
return nlmsg_multicast(nls, skb, 0, group, gfp);
 }
 
+static int
+iscsi_unicast_skb(struct sk_buff *skb, u32 portid)
+{
+   return nlmsg_unicast(nls, skb, portid);
+}
+
 int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct iscsi_hdr *hdr,
   char *data, uint32_t data_size)
 {
@@ -2524,14 +2530,11 @@ void iscsi_ping_comp_event(uint32_t host
 EXPORT_SYMBOL_GPL(iscsi_ping_comp_event);
 
 static int
-iscsi_if_send_reply(uint32_t group, int seq, int type, int done, int multi,
-   void *payload, int size)
+iscsi_if_send_reply(u32 portid, int type, void *payload, int size)
 {
struct sk_buff  *skb;
struct nlmsghdr *nlh;
int len = nlmsg_total_size(size);
-   int flags = multi ? NLM_F_MULTI : 0;
-   int t = done ? NLMSG_DONE : type;
 
skb = alloc_skb(len, GFP_ATOMIC);
if (!skb) {
@@ -2539,10 +2542,9 @@ iscsi_if_send_reply(uint32_t group, int
return -ENOMEM;
}
 
-   nlh = __nlmsg_put(skb, 0, 0, t, (len - sizeof(*nlh)), 0);
-   nlh->nlmsg_flags = flags;
+   nlh = __nlmsg_put(skb, 0, 0, type, (len - sizeof(*nlh)), 0);
memcpy(nlmsg_data(nlh), payload, size);
-   return iscsi_multicast_skb(skb, group, GFP_ATOMIC);
+   return iscsi_unicast_skb(skb, portid);
 }
 
 static int
@@ -3470,6 +3472,7 @@ static int
 iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
 {
int err = 0;
+   u32 portid;
struct iscsi_uevent *ev = nlmsg_data(nlh);
struct iscsi_transport *transport = NULL;
struct iscsi_internal *priv;
@@ -3490,10 +3493,12 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
if (!try_module_get(transport->owner))
return -EINVAL;
 
+   portid = NETLINK_CB(skb).portid;
+
switch (nlh->nlmsg_type) {
case ISCSI_UEVENT_CREATE_SESSION:
err = iscsi_if_create_session(priv, ep, ev,
- NETLINK_CB(skb).portid,
+ portid,
  ev->u.c_session.initial_cmdsn,
  ev->u.c_session.cmds_max,
  ev->u.c_session.queue_depth);
@@ -3506,7 +3511,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
}
 
err = iscsi_if_create_session(priv, ep, ev,
-   NETLINK_CB(skb).portid,
+   portid,
ev->u.c_bound_session.initial_cmdsn,
ev->u.c_bound_session.cmds_max,
ev->u.c_bound_session.queue_depth);
@@ -3664,6 +3669,8 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
 static void
 iscsi_if_rx(struct sk_buff *skb)
 {
+   u32 portid = NETLINK_CB(skb).portid;
+
mutex_lock(_queue_mutex);
while (skb->len >= NLMSG_HDRLEN) {
int err;
@@ -3699,8 +3706,8 @@ iscsi_if_rx(struct sk_buff *skb)
break;
if (ev->type == ISCSI_UEVENT_GET_CHAP && !err)
break;
-   err = iscsi_if_send_reply(group, nlh->nlmsg_seq,
-   nlh->nlmsg_type, 0, 0, ev, sizeof(*ev));
+   err = iscsi_if_send_reply(portid, nlh->nlmsg_type,
+ ev, sizeof(*ev));
} while (err < 0 && err != -ECONNREFUSED && err != -ESRCH);
skb_pull(skb, rlen);
}

[PATCH 4.14 030/189] scsi: iscsi: respond to netlink with unicast when appropriate

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Chris Leech 

[ Upstream commit af17092810a887178195276255b7b31f8fbe7dbe ]

Instead of always multicasting responses, send a unicast netlink message
directed at the correct pid.  This will be needed if we ever want to
support multiple userspace processes interacting with the kernel over
iSCSI netlink simultaneously.  Limitations can currently be seen if you
attempt to run multiple iscsistart commands in parallel.

We've fixed up the userspace issues in iscsistart that prevented
multiple instances from running, so now attempts to speed up booting by
bringing up multiple iscsi sessions at once in the initramfs are just
running into misrouted responses that this fixes.

Signed-off-by: Chris Leech 
Reviewed-by: Lee Duncan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/scsi/scsi_transport_iscsi.c |   29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2322,6 +2322,12 @@ iscsi_multicast_skb(struct sk_buff *skb,
return nlmsg_multicast(nls, skb, 0, group, gfp);
 }
 
+static int
+iscsi_unicast_skb(struct sk_buff *skb, u32 portid)
+{
+   return nlmsg_unicast(nls, skb, portid);
+}
+
 int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct iscsi_hdr *hdr,
   char *data, uint32_t data_size)
 {
@@ -2524,14 +2530,11 @@ void iscsi_ping_comp_event(uint32_t host
 EXPORT_SYMBOL_GPL(iscsi_ping_comp_event);
 
 static int
-iscsi_if_send_reply(uint32_t group, int seq, int type, int done, int multi,
-   void *payload, int size)
+iscsi_if_send_reply(u32 portid, int type, void *payload, int size)
 {
struct sk_buff  *skb;
struct nlmsghdr *nlh;
int len = nlmsg_total_size(size);
-   int flags = multi ? NLM_F_MULTI : 0;
-   int t = done ? NLMSG_DONE : type;
 
skb = alloc_skb(len, GFP_ATOMIC);
if (!skb) {
@@ -2539,10 +2542,9 @@ iscsi_if_send_reply(uint32_t group, int
return -ENOMEM;
}
 
-   nlh = __nlmsg_put(skb, 0, 0, t, (len - sizeof(*nlh)), 0);
-   nlh->nlmsg_flags = flags;
+   nlh = __nlmsg_put(skb, 0, 0, type, (len - sizeof(*nlh)), 0);
memcpy(nlmsg_data(nlh), payload, size);
-   return iscsi_multicast_skb(skb, group, GFP_ATOMIC);
+   return iscsi_unicast_skb(skb, portid);
 }
 
 static int
@@ -3470,6 +3472,7 @@ static int
 iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
 {
int err = 0;
+   u32 portid;
struct iscsi_uevent *ev = nlmsg_data(nlh);
struct iscsi_transport *transport = NULL;
struct iscsi_internal *priv;
@@ -3490,10 +3493,12 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
if (!try_module_get(transport->owner))
return -EINVAL;
 
+   portid = NETLINK_CB(skb).portid;
+
switch (nlh->nlmsg_type) {
case ISCSI_UEVENT_CREATE_SESSION:
err = iscsi_if_create_session(priv, ep, ev,
- NETLINK_CB(skb).portid,
+ portid,
  ev->u.c_session.initial_cmdsn,
  ev->u.c_session.cmds_max,
  ev->u.c_session.queue_depth);
@@ -3506,7 +3511,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
}
 
err = iscsi_if_create_session(priv, ep, ev,
-   NETLINK_CB(skb).portid,
+   portid,
ev->u.c_bound_session.initial_cmdsn,
ev->u.c_bound_session.cmds_max,
ev->u.c_bound_session.queue_depth);
@@ -3664,6 +3669,8 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
 static void
 iscsi_if_rx(struct sk_buff *skb)
 {
+   u32 portid = NETLINK_CB(skb).portid;
+
mutex_lock(_queue_mutex);
while (skb->len >= NLMSG_HDRLEN) {
int err;
@@ -3699,8 +3706,8 @@ iscsi_if_rx(struct sk_buff *skb)
break;
if (ev->type == ISCSI_UEVENT_GET_CHAP && !err)
break;
-   err = iscsi_if_send_reply(group, nlh->nlmsg_seq,
-   nlh->nlmsg_type, 0, 0, ev, sizeof(*ev));
+   err = iscsi_if_send_reply(portid, nlh->nlmsg_type,
+ ev, sizeof(*ev));
} while (err < 0 && err != -ECONNREFUSED && err != -ESRCH);
skb_pull(skb, rlen);
}

[PATCH 4.14 030/189] scsi: iscsi: respond to netlink with unicast when appropriate

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Chris Leech 

[ Upstream commit af17092810a887178195276255b7b31f8fbe7dbe ]

Instead of always multicasting responses, send a unicast netlink message
directed at the correct pid.  This will be needed if we ever want to
support multiple userspace processes interacting with the kernel over
iSCSI netlink simultaneously.  Limitations can currently be seen if you
attempt to run multiple iscsistart commands in parallel.

We've fixed up the userspace issues in iscsistart that prevented
multiple instances from running, so now attempts to speed up booting by
bringing up multiple iscsi sessions at once in the initramfs are just
running into misrouted responses that this fixes.

Signed-off-by: Chris Leech 
Reviewed-by: Lee Duncan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/scsi/scsi_transport_iscsi.c |   29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2322,6 +2322,12 @@ iscsi_multicast_skb(struct sk_buff *skb,
return nlmsg_multicast(nls, skb, 0, group, gfp);
 }
 
+static int
+iscsi_unicast_skb(struct sk_buff *skb, u32 portid)
+{
+   return nlmsg_unicast(nls, skb, portid);
+}
+
 int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct iscsi_hdr *hdr,
   char *data, uint32_t data_size)
 {
@@ -2524,14 +2530,11 @@ void iscsi_ping_comp_event(uint32_t host
 EXPORT_SYMBOL_GPL(iscsi_ping_comp_event);
 
 static int
-iscsi_if_send_reply(uint32_t group, int seq, int type, int done, int multi,
-   void *payload, int size)
+iscsi_if_send_reply(u32 portid, int type, void *payload, int size)
 {
struct sk_buff  *skb;
struct nlmsghdr *nlh;
int len = nlmsg_total_size(size);
-   int flags = multi ? NLM_F_MULTI : 0;
-   int t = done ? NLMSG_DONE : type;
 
skb = alloc_skb(len, GFP_ATOMIC);
if (!skb) {
@@ -2539,10 +2542,9 @@ iscsi_if_send_reply(uint32_t group, int
return -ENOMEM;
}
 
-   nlh = __nlmsg_put(skb, 0, 0, t, (len - sizeof(*nlh)), 0);
-   nlh->nlmsg_flags = flags;
+   nlh = __nlmsg_put(skb, 0, 0, type, (len - sizeof(*nlh)), 0);
memcpy(nlmsg_data(nlh), payload, size);
-   return iscsi_multicast_skb(skb, group, GFP_ATOMIC);
+   return iscsi_unicast_skb(skb, portid);
 }
 
 static int
@@ -3470,6 +3472,7 @@ static int
 iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
 {
int err = 0;
+   u32 portid;
struct iscsi_uevent *ev = nlmsg_data(nlh);
struct iscsi_transport *transport = NULL;
struct iscsi_internal *priv;
@@ -3490,10 +3493,12 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
if (!try_module_get(transport->owner))
return -EINVAL;
 
+   portid = NETLINK_CB(skb).portid;
+
switch (nlh->nlmsg_type) {
case ISCSI_UEVENT_CREATE_SESSION:
err = iscsi_if_create_session(priv, ep, ev,
- NETLINK_CB(skb).portid,
+ portid,
  ev->u.c_session.initial_cmdsn,
  ev->u.c_session.cmds_max,
  ev->u.c_session.queue_depth);
@@ -3506,7 +3511,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
}
 
err = iscsi_if_create_session(priv, ep, ev,
-   NETLINK_CB(skb).portid,
+   portid,
ev->u.c_bound_session.initial_cmdsn,
ev->u.c_bound_session.cmds_max,
ev->u.c_bound_session.queue_depth);
@@ -3664,6 +3669,8 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
 static void
 iscsi_if_rx(struct sk_buff *skb)
 {
+   u32 portid = NETLINK_CB(skb).portid;
+
mutex_lock(_queue_mutex);
while (skb->len >= NLMSG_HDRLEN) {
int err;
@@ -3699,8 +3706,8 @@ iscsi_if_rx(struct sk_buff *skb)
break;
if (ev->type == ISCSI_UEVENT_GET_CHAP && !err)
break;
-   err = iscsi_if_send_reply(group, nlh->nlmsg_seq,
-   nlh->nlmsg_type, 0, 0, ev, sizeof(*ev));
+   err = iscsi_if_send_reply(portid, nlh->nlmsg_type,
+ ev, sizeof(*ev));
} while (err < 0 && err != -ECONNREFUSED && err != -ESRCH);
skb_pull(skb, rlen);
}

Respond for Comfirmation.

[Mr Mikhail Fridman]

Charitable Donation for you, Respond for further directives.

Mr. Mikhail Fridman

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Respond for Comfirmation.

[Mr Mikhail Fridman]

Charitable Donation for you, Respond for further directives.

Mr. Mikhail Fridman

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Read and Respond Quickly

[Astou Eva]

I am a banker and am writing you today in full confidence, i want to know if 
you have a valid bank account that can accept millions of US Dollars. If you 
do, respond quickly so that i can intimate you on this deal that is absolutely 
risk-free but highly secret. It is only between me and you. No third party 
involved.

reply at my personal email   evaastou...@gmail.com

Regards
Miss Eva Astou

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Read and Respond Quickly

[Astou Eva]

I am a banker and am writing you today in full confidence, i want to know if 
you have a valid bank account that can accept millions of US Dollars. If you 
do, respond quickly so that i can intimate you on this deal that is absolutely 
risk-free but highly secret. It is only between me and you. No third party 
involved.

reply at my personal email   evaastou...@gmail.com

Regards
Miss Eva Astou

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Respond for details

[Mr. Allen]

Good day.

Do you need a loan to pay off bills ? To pay off your mortgage quickly ? To set 
up a new business or to Re- finance your existing business ? I can help you 
secure a private loan should you be interested please respond for more details 


Thanks 

Allen

Respond for details

[Mr. Allen]

Good day.

Do you need a loan to pay off bills ? To pay off your mortgage quickly ? To set 
up a new business or to Re- finance your existing business ? I can help you 
secure a private loan should you be interested please respond for more details 


Thanks 

Allen

Respond for details

[Mr. Allen]

Good day.

Do you need a loan to pay off bills ? To pay off your mortgage quickly ? To set 
up a new business or to Re- finance your existing business ? I can help you 
secure a private loan should you be interested please respond for more details 


Thanks 

Allen

Respond for details

[Mr. Allen]

Good day.

Do you need a loan to pay off bills ? To pay off your mortgage quickly ? To set 
up a new business or to Re- finance your existing business ? I can help you 
secure a private loan should you be interested please respond for more details 


Thanks 

Allen

i wait your respond

[1770...@ono.com]

--
Greetings,

I wonder why you continue neglecting my emails. Please, acknowledge the 
receipt of this message in reference to the subject above as I intend 
to send to you the details of the project. Sometimes, try to check 
your  spam box because most of these correspondences fall out sometimes 
in SPAM folder.

Best regards,
Mr. Aziz Ibrahim
--

i wait your respond

[1770...@ono.com]

--
Greetings,

I wonder why you continue neglecting my emails. Please, acknowledge the 
receipt of this message in reference to the subject above as I intend 
to send to you the details of the project. Sometimes, try to check 
your  spam box because most of these correspondences fall out sometimes 
in SPAM folder.

Best regards,
Mr. Aziz Ibrahim
--

Respond for details

[Mr. Allen]

Dear sir/ madam


Do you need a loan to pay off bills ? To pay off your mortgage quickly ? To set 
up a new business or to Re- finance your existing business ? I can help you 
secure a private loan at 3% interest rate please respond for more details



Thanks


Allen

Respond for details

[Mr. Allen]

Dear sir/ madam


Do you need a loan to pay off bills ? To pay off your mortgage quickly ? To set 
up a new business or to Re- finance your existing business ? I can help you 
secure a private loan at 3% interest rate please respond for more details



Thanks


Allen

Respond

[Mavis Wanc]

I am giving out my donation to you.
Reply

Respond

[Mavis Wanc]

I am giving out my donation to you.
Reply

[PATCH 4.13 42/85] media: cec: Respond to unregistered initiators, when applicable

[Greg Kroah-Hartman]

4.13-stable review patch.  If anyone has any objections, please let me know.

--

From: Jose Abreu <jose.ab...@synopsys.com>

commit 845d6524d69b40bd6abd61dc1264a8657159aa55 upstream.

Running CEC 1.4 compliance test we get the following error on test
11.1.6.2: "ERROR: The DUT did not broadcast a
 message to the unregistered device."

Fix this by letting GIVE_PHYSICAL_ADDR message respond to unregistered
device. Also, GIVE_DEVICE_VENDOR_ID and GIVE_FEATURES fall in the
same category so, respond also to these messages.

With this fix we pass CEC 1.4 official compliance.

Signed-off-by: Jose Abreu <joab...@synopsys.com>
Cc: Joao Pinto <jpi...@synopsys.com>
Signed-off-by: Hans Verkuil <hans.verk...@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/media/cec/cec-adap.c |   13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -1726,12 +1726,19 @@ static int cec_receive_notify(struct cec
 */
switch (msg->msg[1]) {
case CEC_MSG_GET_CEC_VERSION:
-   case CEC_MSG_GIVE_DEVICE_VENDOR_ID:
case CEC_MSG_ABORT:
case CEC_MSG_GIVE_DEVICE_POWER_STATUS:
-   case CEC_MSG_GIVE_PHYSICAL_ADDR:
case CEC_MSG_GIVE_OSD_NAME:
+   /*
+* These messages reply with a directed message, so ignore if
+* the initiator is Unregistered.
+*/
+   if (!adap->passthrough && from_unregistered)
+   return 0;
+   /* Fall through */
+   case CEC_MSG_GIVE_DEVICE_VENDOR_ID:
case CEC_MSG_GIVE_FEATURES:
+   case CEC_MSG_GIVE_PHYSICAL_ADDR:
/*
 * Skip processing these messages if the passthrough mode
 * is on.
@@ -1739,7 +1746,7 @@ static int cec_receive_notify(struct cec
if (adap->passthrough)
goto skip_processing;
/* Ignore if addressing is wrong */
-   if (is_broadcast || from_unregistered)
+   if (is_broadcast)
return 0;
break;
 

[PATCH 4.13 42/85] media: cec: Respond to unregistered initiators, when applicable

[Greg Kroah-Hartman]

4.13-stable review patch.  If anyone has any objections, please let me know.

--

From: Jose Abreu 

commit 845d6524d69b40bd6abd61dc1264a8657159aa55 upstream.

Running CEC 1.4 compliance test we get the following error on test
11.1.6.2: "ERROR: The DUT did not broadcast a
 message to the unregistered device."

Fix this by letting GIVE_PHYSICAL_ADDR message respond to unregistered
device. Also, GIVE_DEVICE_VENDOR_ID and GIVE_FEATURES fall in the
same category so, respond also to these messages.

With this fix we pass CEC 1.4 official compliance.

Signed-off-by: Jose Abreu 
Cc: Joao Pinto 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/cec/cec-adap.c |   13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -1726,12 +1726,19 @@ static int cec_receive_notify(struct cec
 */
switch (msg->msg[1]) {
case CEC_MSG_GET_CEC_VERSION:
-   case CEC_MSG_GIVE_DEVICE_VENDOR_ID:
case CEC_MSG_ABORT:
case CEC_MSG_GIVE_DEVICE_POWER_STATUS:
-   case CEC_MSG_GIVE_PHYSICAL_ADDR:
case CEC_MSG_GIVE_OSD_NAME:
+   /*
+* These messages reply with a directed message, so ignore if
+* the initiator is Unregistered.
+*/
+   if (!adap->passthrough && from_unregistered)
+   return 0;
+   /* Fall through */
+   case CEC_MSG_GIVE_DEVICE_VENDOR_ID:
case CEC_MSG_GIVE_FEATURES:
+   case CEC_MSG_GIVE_PHYSICAL_ADDR:
/*
 * Skip processing these messages if the passthrough mode
 * is on.
@@ -1739,7 +1746,7 @@ static int cec_receive_notify(struct cec
if (adap->passthrough)
goto skip_processing;
/* Ignore if addressing is wrong */
-   if (is_broadcast || from_unregistered)
+   if (is_broadcast)
return 0;
break;
 

Waiting for your urgent respond

[Bank of America]

Attention:

This is to alert you that we received your fund worth the sum $27m from the 
Bank of America. We are alerting you to send your information and banking 
details where you desire to receive the fund. The Information’s such as the 
following:

1 Your Full Name:
2.Your Current Address:
3.Your Occupation:
4.Your telephone numbers:
5.Banking details:
6 Account Name:
7 Account Number:
8.Scan copy of your valid ID card

With out your id card your fund can not be transfer into your bank account. 
Your ID card is very vital

Waiting for your urgent respond. Thanks for the patronage
Bank of America
Micheal Ziemann,

Executive director. E-mail: bankofamerica2...@barid.com
Tell: (518) 882 0458