Re: [PATCH V7 09/12] thermal: tegra: add thermtrip function

[Wei Ni]

On 2016年03月16日 03:49, Eduardo Valentin wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Mar 15, 2016 at 05:12:12PM +0800, Wei Ni wrote:
>>
>>
>> On 2016年03月15日 03:16, Eduardo Valentin wrote:
 Old Signed by an unknown key
>>>
>>> On Fri, Mar 11, 2016 at 11:11:12AM +0800, Wei Ni wrote:
 Add support for hardware critical thermal limits to the
 SOC_THERM driver. It use the Linux thermal framework to
 create critical trip temp, and set it to SOC_THERM hardware.
 If these limits are breached, the chip will reset, and if
 appropriately configured, will turn off the PMIC.

 This support is critical for safe usage of the chip.

 Signed-off-by: Wei Ni 
 ---
  drivers/thermal/tegra/soctherm.c  | 166 
 +-
  drivers/thermal/tegra/soctherm.h  |   7 ++
  drivers/thermal/tegra/tegra124-soctherm.c |  24 +
  drivers/thermal/tegra/tegra210-soctherm.c |  24 +
  4 files changed, 216 insertions(+), 5 deletions(-)

 diff --git a/drivers/thermal/tegra/soctherm.c 
 b/drivers/thermal/tegra/soctherm.c
 index 02ac6d2e5a20..dbaab160baba 100644
 --- a/drivers/thermal/tegra/soctherm.c
 +++ b/drivers/thermal/tegra/soctherm.c
 @@ -73,9 +73,14 @@
  #define REG_SET_MASK(r, m, v) (((r) & ~(m)) | \
 (((v) & (m >> (ffs(m) - 1))) << (ffs(m) - 1)))
  
 +static const int min_low_temp = -127000;
 +static const int max_high_temp = 127000;
 +
  struct tegra_thermctl_zone {
void __iomem *reg;
 -  u32 mask;
 +  struct device *dev;
 +  struct thermal_zone_device *tz;
>>>
>>>
>>> Why not using tz->dev for the *dev above?
>>
>> The tz is thermal_zone_device, this structure doesn't have *dev.
>> It only have the member "struct device device;", but this device is created 
>> for
>> the thermal class, not this tegra_soctherm device.
>>
>>>
 +  const struct tegra_tsensor_group *sg;
  };
  
  struct tegra_soctherm {
 @@ -145,22 +150,158 @@ static int tegra_thermctl_get_temp(void *data, int 
 *out_temp)
u32 val;
  
val = readl(zone->reg);
 -  val = REG_GET_MASK(val, zone->mask);
 +  val = REG_GET_MASK(val, zone->sg->sensor_temp_mask);
*out_temp = translate_temp(val);
  
return 0;
  }
  
 +static int
 +thermtrip_program(struct device *dev, const struct tegra_tsensor_group 
 *sg,
 +int trip_temp);
 +
 +static int tegra_thermctl_set_trip_temp(void *data, int trip, int temp)
 +{
 +  struct tegra_thermctl_zone *zone = data;
 +  struct thermal_zone_device *tz = zone->tz;
 +  const struct tegra_tsensor_group *sg = zone->sg;
 +  struct device *dev = zone->dev;
 +  enum thermal_trip_type type;
 +  int ret;
 +
 +  if (!tz)
 +  return -EINVAL;
>>>
>>>
>>> Is the above check needed? If you saw a case in which your function is
>>> called without tz, would it be the case we have a but in the probe (or
>>> even worse, in thermal-core)?
>>
>> This tz isn't from thermal-core, it's from the "void *data".
>> This *data is the private structure "struct tegra_thermctl_zone *zone = 
>> data;".
>> It is registered in devm_thermal_zone_of_sensor_register(*dev, sensor_id, 
>> *data,
>> *ops). And when it register successful, I will set zone->tz = z, in here, the
>> zone is the private data.
>> Let's consider a special case, once the thermal_zone_of_sensor_register
>> successful and didn't run to "zone->tz = z" yet, then the thermal_core 
>> implement
>> .set_trip(), then it may cause problems in here, although it's difficult to 
>> hit
>> this case. So I think we need to do this check.
> 
> 
> Can you be more specific? I don't recall a case that core would call any
> driver callbacks before setting up the data structures properly.

Sorry for the confusion, I mean this data structure is the private data pointer,
it doesn't handled by thermal_core. Let me explain more:
In this tegra soctherm driver, I run following steps in probe routine:
step1:
z = devm_thermal_zone_of_sensor_register(*dev, sensor_id, zone, ops);
register thermal zone device, in here, the parameter "zone" is the private data
pointer "structure tegra_thermctl_zone".
step 2:
After register, it return the "z", and I set it to the private data:
zone->tz = z;

In the .set_trip() callback, it will pass back this private data pointer.
So if the callback was called between step1 and step2, at that time the zone->tz
didn't be set yet, it will cause problems, although I didn't hit this case.

This check doesn't relate with core driver, it is used to check my private data
pointer.

Wei.

> 
>>>
> 
> * Unknown Key
> * 0x7DA4E256
> 

Re: [PATCH V7 09/12] thermal: tegra: add thermtrip function

[Wei Ni]

On 2016年03月16日 03:49, Eduardo Valentin wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Mar 15, 2016 at 05:12:12PM +0800, Wei Ni wrote:
>>
>>
>> On 2016年03月15日 03:16, Eduardo Valentin wrote:
 Old Signed by an unknown key
>>>
>>> On Fri, Mar 11, 2016 at 11:11:12AM +0800, Wei Ni wrote:
 Add support for hardware critical thermal limits to the
 SOC_THERM driver. It use the Linux thermal framework to
 create critical trip temp, and set it to SOC_THERM hardware.
 If these limits are breached, the chip will reset, and if
 appropriately configured, will turn off the PMIC.

 This support is critical for safe usage of the chip.

 Signed-off-by: Wei Ni 
 ---
  drivers/thermal/tegra/soctherm.c  | 166 
 +-
  drivers/thermal/tegra/soctherm.h  |   7 ++
  drivers/thermal/tegra/tegra124-soctherm.c |  24 +
  drivers/thermal/tegra/tegra210-soctherm.c |  24 +
  4 files changed, 216 insertions(+), 5 deletions(-)

 diff --git a/drivers/thermal/tegra/soctherm.c 
 b/drivers/thermal/tegra/soctherm.c
 index 02ac6d2e5a20..dbaab160baba 100644
 --- a/drivers/thermal/tegra/soctherm.c
 +++ b/drivers/thermal/tegra/soctherm.c
 @@ -73,9 +73,14 @@
  #define REG_SET_MASK(r, m, v) (((r) & ~(m)) | \
 (((v) & (m >> (ffs(m) - 1))) << (ffs(m) - 1)))
  
 +static const int min_low_temp = -127000;
 +static const int max_high_temp = 127000;
 +
  struct tegra_thermctl_zone {
void __iomem *reg;
 -  u32 mask;
 +  struct device *dev;
 +  struct thermal_zone_device *tz;
>>>
>>>
>>> Why not using tz->dev for the *dev above?
>>
>> The tz is thermal_zone_device, this structure doesn't have *dev.
>> It only have the member "struct device device;", but this device is created 
>> for
>> the thermal class, not this tegra_soctherm device.
>>
>>>
 +  const struct tegra_tsensor_group *sg;
  };
  
  struct tegra_soctherm {
 @@ -145,22 +150,158 @@ static int tegra_thermctl_get_temp(void *data, int 
 *out_temp)
u32 val;
  
val = readl(zone->reg);
 -  val = REG_GET_MASK(val, zone->mask);
 +  val = REG_GET_MASK(val, zone->sg->sensor_temp_mask);
*out_temp = translate_temp(val);
  
return 0;
  }
  
 +static int
 +thermtrip_program(struct device *dev, const struct tegra_tsensor_group 
 *sg,
 +int trip_temp);
 +
 +static int tegra_thermctl_set_trip_temp(void *data, int trip, int temp)
 +{
 +  struct tegra_thermctl_zone *zone = data;
 +  struct thermal_zone_device *tz = zone->tz;
 +  const struct tegra_tsensor_group *sg = zone->sg;
 +  struct device *dev = zone->dev;
 +  enum thermal_trip_type type;
 +  int ret;
 +
 +  if (!tz)
 +  return -EINVAL;
>>>
>>>
>>> Is the above check needed? If you saw a case in which your function is
>>> called without tz, would it be the case we have a but in the probe (or
>>> even worse, in thermal-core)?
>>
>> This tz isn't from thermal-core, it's from the "void *data".
>> This *data is the private structure "struct tegra_thermctl_zone *zone = 
>> data;".
>> It is registered in devm_thermal_zone_of_sensor_register(*dev, sensor_id, 
>> *data,
>> *ops). And when it register successful, I will set zone->tz = z, in here, the
>> zone is the private data.
>> Let's consider a special case, once the thermal_zone_of_sensor_register
>> successful and didn't run to "zone->tz = z" yet, then the thermal_core 
>> implement
>> .set_trip(), then it may cause problems in here, although it's difficult to 
>> hit
>> this case. So I think we need to do this check.
> 
> 
> Can you be more specific? I don't recall a case that core would call any
> driver callbacks before setting up the data structures properly.

Sorry for the confusion, I mean this data structure is the private data pointer,
it doesn't handled by thermal_core. Let me explain more:
In this tegra soctherm driver, I run following steps in probe routine:
step1:
z = devm_thermal_zone_of_sensor_register(*dev, sensor_id, zone, ops);
register thermal zone device, in here, the parameter "zone" is the private data
pointer "structure tegra_thermctl_zone".
step 2:
After register, it return the "z", and I set it to the private data:
zone->tz = z;

In the .set_trip() callback, it will pass back this private data pointer.
So if the callback was called between step1 and step2, at that time the zone->tz
didn't be set yet, it will cause problems, although I didn't hit this case.

This check doesn't relate with core driver, it is used to check my private data
pointer.

Wei.

> 
>>>
> 
> * Unknown Key
> * 0x7DA4E256
> 

Re: [RFC PATCH kernel] Revert "net/mlx4_core: Set UAR page size to 4KB regardless of system page size"

[Alexey Kardashevskiy]

On 03/16/2016 04:10 PM, Eli Cohen wrote:

On Wed, Mar 16, 2016 at 01:07:58PM +1100, Alexey Kardashevskiy wrote:


So with v4.5 as a host, there is no actual distro available today to
use as a guest in the next 6 months (or whatever it takes to
backport this partucular patch back there).

You could have added a module parameter to enforce the old behavoir,
at least...

And sorry but from the original commit log I could not understand
why exactly all existing guests need to be broken. Could you please
point me to a piece of documentation describing all this UAR
bisuness (what is UAR, why 128 UARs are required and for what, etc).
Thanks.



We are going to send a patch that fixes this using a module parameter.
The patch will be on top of Huy's patch.

Some background to the problem: mlx4 supported devices require 128 UAR


What does UAR stand for?


pages from PCI memory space defined by BAR2-3. Each UAR page can be
any power of 2 value from 4K up to 64K. Before Huy's patch the driver
chose UAR page size to be equal to system page size. Since PowerPC's
page size is 64K this means minimum requirement of UAR pages is not
met (default UAR BAR is 8MB and only half of it is really reserved for
UARs).


And what was the downside? afaict the performance was good...



More details can be found in the programmer's manual.


Can you please point me to this manual on the website? I tried, honestly, 
could not find it. Thanks.



--
Alexey

Re: [RFC PATCH kernel] Revert "net/mlx4_core: Set UAR page size to 4KB regardless of system page size"

[Alexey Kardashevskiy]

On 03/16/2016 04:10 PM, Eli Cohen wrote:

On Wed, Mar 16, 2016 at 01:07:58PM +1100, Alexey Kardashevskiy wrote:


So with v4.5 as a host, there is no actual distro available today to
use as a guest in the next 6 months (or whatever it takes to
backport this partucular patch back there).

You could have added a module parameter to enforce the old behavoir,
at least...

And sorry but from the original commit log I could not understand
why exactly all existing guests need to be broken. Could you please
point me to a piece of documentation describing all this UAR
bisuness (what is UAR, why 128 UARs are required and for what, etc).
Thanks.



We are going to send a patch that fixes this using a module parameter.
The patch will be on top of Huy's patch.

Some background to the problem: mlx4 supported devices require 128 UAR


What does UAR stand for?


pages from PCI memory space defined by BAR2-3. Each UAR page can be
any power of 2 value from 4K up to 64K. Before Huy's patch the driver
chose UAR page size to be equal to system page size. Since PowerPC's
page size is 64K this means minimum requirement of UAR pages is not
met (default UAR BAR is 8MB and only half of it is really reserved for
UARs).


And what was the downside? afaict the performance was good...



More details can be found in the programmer's manual.


Can you please point me to this manual on the website? I tried, honestly, 
could not find it. Thanks.



--
Alexey

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

[Pratyush Anand]

On 15/03/2016:06:47:52 PM, James Morse wrote:
> Hi David,
> 
> On 09/03/16 05:32, David Long wrote:
> > From: "David A. Long" 
> > diff --git a/arch/arm64/lib/copy_from_user.S 
> > b/arch/arm64/lib/copy_from_user.S
> > index 4699cd7..0ac2131 100644
> > --- a/arch/arm64/lib/copy_from_user.S
> > +++ b/arch/arm64/lib/copy_from_user.S
> > @@ -66,6 +66,7 @@
> > .endm
> >  
> >  end.reqx5
> > +   .section .kprobes.text,"ax",%progbits
> >  ENTRY(__copy_from_user)
> >  ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
> > CONFIG_ARM64_PAN)
> > diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
> > index 7512bbb..e4eb84c 100644
> > --- a/arch/arm64/lib/copy_to_user.S
> > +++ b/arch/arm64/lib/copy_to_user.S
> > @@ -65,6 +65,7 @@
> > .endm
> >  
> >  end.reqx5
> > +   .section .kprobes.text,"ax",%progbits
> >  ENTRY(__copy_to_user)
> >  ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
> > CONFIG_ARM64_PAN)
> > 
> 
> If I understand this correctly -  you can't kprobe these ldr/str instructions 
> as
> the fault handler wouldn't find kprobe's out-of line version of the 
> instruction
> in the exception table... but why only these two functions? (for library
> functions, we also have clear_user() and copy_in_user()...)

May be not clear_user() because those are inlined, but may be __clear_user().

There can be many other functions (see [1], [2] and can be many more) which need
to be blacklisted, but I think they can always be added latter on, and atleast
this aspect should not hinder inclusion of these patches.

> 
> The get_user()/put_user() stuff in uaccess.h gets inlined all over the 
> kernel, I
> don't think its feasible to put all of these in a separate section.

Yes, It does not seem possible to blacklist  inlined functions. There can be
some other places like valid kprobable instructions in atomic context, .word
instruction having data as valid instruction, etc... So, probably its not
possible to make 100% safe, but yes wherever possible, we should take care.

Infact, other ARCHs are also not completely safe. One can try to instrument
kprobe on all the symbols in Kallsyms on an x86_64 machine and kernel crashes.

> 
> Is it feasible to search the exception table at runtime instead? If an
> address-to-be-kprobed appears in the list, we know it could generate 
> exceptions,
> so we should report that we can't probe this address. That would catch all of
> the library functions, all the places uaccess.h was inlined, and anything new
> that gets invented in the future.

Sorry, probably I could not get it. How can an inlined addresses range be placed
in exception table or any other code area.

~Pratyush

[1] 
https://github.com/pratyushanand/linux/commit/855bc4dbb98ceafac4c933e00d203b1cd7ee9ca4
[2] 
https://github.com/pratyushanand/linux/commit/8bc586d6f767240e9ffa582f45a9ad11de47ecfb

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

[Pratyush Anand]

On 15/03/2016:06:47:52 PM, James Morse wrote:
> Hi David,
> 
> On 09/03/16 05:32, David Long wrote:
> > From: "David A. Long" 
> > diff --git a/arch/arm64/lib/copy_from_user.S 
> > b/arch/arm64/lib/copy_from_user.S
> > index 4699cd7..0ac2131 100644
> > --- a/arch/arm64/lib/copy_from_user.S
> > +++ b/arch/arm64/lib/copy_from_user.S
> > @@ -66,6 +66,7 @@
> > .endm
> >  
> >  end.reqx5
> > +   .section .kprobes.text,"ax",%progbits
> >  ENTRY(__copy_from_user)
> >  ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
> > CONFIG_ARM64_PAN)
> > diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
> > index 7512bbb..e4eb84c 100644
> > --- a/arch/arm64/lib/copy_to_user.S
> > +++ b/arch/arm64/lib/copy_to_user.S
> > @@ -65,6 +65,7 @@
> > .endm
> >  
> >  end.reqx5
> > +   .section .kprobes.text,"ax",%progbits
> >  ENTRY(__copy_to_user)
> >  ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
> > CONFIG_ARM64_PAN)
> > 
> 
> If I understand this correctly -  you can't kprobe these ldr/str instructions 
> as
> the fault handler wouldn't find kprobe's out-of line version of the 
> instruction
> in the exception table... but why only these two functions? (for library
> functions, we also have clear_user() and copy_in_user()...)

May be not clear_user() because those are inlined, but may be __clear_user().

There can be many other functions (see [1], [2] and can be many more) which need
to be blacklisted, but I think they can always be added latter on, and atleast
this aspect should not hinder inclusion of these patches.

> 
> The get_user()/put_user() stuff in uaccess.h gets inlined all over the 
> kernel, I
> don't think its feasible to put all of these in a separate section.

Yes, It does not seem possible to blacklist  inlined functions. There can be
some other places like valid kprobable instructions in atomic context, .word
instruction having data as valid instruction, etc... So, probably its not
possible to make 100% safe, but yes wherever possible, we should take care.

Infact, other ARCHs are also not completely safe. One can try to instrument
kprobe on all the symbols in Kallsyms on an x86_64 machine and kernel crashes.

> 
> Is it feasible to search the exception table at runtime instead? If an
> address-to-be-kprobed appears in the list, we know it could generate 
> exceptions,
> so we should report that we can't probe this address. That would catch all of
> the library functions, all the places uaccess.h was inlined, and anything new
> that gets invented in the future.

Sorry, probably I could not get it. How can an inlined addresses range be placed
in exception table or any other code area.

~Pratyush

[1] 
https://github.com/pratyushanand/linux/commit/855bc4dbb98ceafac4c933e00d203b1cd7ee9ca4
[2] 
https://github.com/pratyushanand/linux/commit/8bc586d6f767240e9ffa582f45a9ad11de47ecfb

Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage

[Johannes Weiner]

On Fri, Mar 11, 2016 at 11:34:40AM +0300, Vladimir Davydov wrote:
> On Thu, Mar 10, 2016 at 03:50:13PM -0500, Johannes Weiner wrote:
> > When setting memory.high below usage, nothing happens until the next
> > charge comes along, and then it will only reclaim its own charge and
> > not the now potentially huge excess of the new memory.high. This can
> > cause groups to stay in excess of their memory.high indefinitely.
> > 
> > To fix that, when shrinking memory.high, kick off a reclaim cycle that
> > goes after the delta.
> 
> I agree that we should reclaim the high excess, but I don't think it's a
> good idea to do it synchronously. Currently, memory.low and memory.high
> knobs can be easily used by a single-threaded load manager implemented
> in userspace, because it doesn't need to care about potential stalls
> caused by writes to these files. After this change it might happen that
> a write to memory.high would take long, seconds perhaps, so in order to
> react quickly to changes in other cgroups, a load manager would have to
> spawn a thread per each write to memory.high, which would complicate its
> implementation significantly.

While I do expect memory.high to be adjusted every once in a while, I
can't see anybody doing it by a significant fraction of the cgroup
every couple of seconds - or tighter than the workingset; and dropping
use-once cache is cheap. What kind of usecase would that be?

But even if we're wrong about it and this becomes a scalability issue,
the knob - even when reclaiming synchroneously - makes no guarantees
about the target being met once the write finishes. It's a best effort
mechanism. What would break if we made it async later on?

Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage

[Johannes Weiner]

On Fri, Mar 11, 2016 at 11:34:40AM +0300, Vladimir Davydov wrote:
> On Thu, Mar 10, 2016 at 03:50:13PM -0500, Johannes Weiner wrote:
> > When setting memory.high below usage, nothing happens until the next
> > charge comes along, and then it will only reclaim its own charge and
> > not the now potentially huge excess of the new memory.high. This can
> > cause groups to stay in excess of their memory.high indefinitely.
> > 
> > To fix that, when shrinking memory.high, kick off a reclaim cycle that
> > goes after the delta.
> 
> I agree that we should reclaim the high excess, but I don't think it's a
> good idea to do it synchronously. Currently, memory.low and memory.high
> knobs can be easily used by a single-threaded load manager implemented
> in userspace, because it doesn't need to care about potential stalls
> caused by writes to these files. After this change it might happen that
> a write to memory.high would take long, seconds perhaps, so in order to
> react quickly to changes in other cgroups, a load manager would have to
> spawn a thread per each write to memory.high, which would complicate its
> implementation significantly.

While I do expect memory.high to be adjusted every once in a while, I
can't see anybody doing it by a significant fraction of the cgroup
every couple of seconds - or tighter than the workingset; and dropping
use-once cache is cheap. What kind of usecase would that be?

But even if we're wrong about it and this becomes a scalability issue,
the knob - even when reclaiming synchroneously - makes no guarantees
about the target being met once the write finishes. It's a best effort
mechanism. What would break if we made it async later on?

RE: [PATCH V2] ACPI: APD: Add device HID for future AMD UART controller

[Xue, Ken]

> From: Wang Hongcheng [mailto:annie.w...@amd.com]
> Sent: Friday, March 11, 2016 5:28 PM
> To: Rafael J. Wysocki; Len Brown; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org; SPG_Linux_Kernel
> Cc: Wang, Annie
> Subject: [PATCH V2] ACPI: APD: Add device HID for future AMD UART
> controller
> 
> Add device HID AMDI0020 to match the AMD ACPI Vendor ID (AMDI) as
> registered in http://www.uefi.org/acpi_id_list, and the UART controller on
> future AMD paltform will use the HID instead of AMD0020.
> 
> Signed-off-by: Wang Hongcheng 


Acked-by: Ken Xue 

Hi Rafael,
Can you help apply and queue this patch into V4.6 like patch  "i2c: designware: 
Add device HID for future AMD I2C controller"?
Thanks.

> ---
>  drivers/acpi/acpi_apd.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c index
> a450e7a..dc2d8a5 100644
> --- a/drivers/acpi/acpi_apd.c
> +++ b/drivers/acpi/acpi_apd.c
> @@ -134,6 +134,7 @@ static const struct acpi_device_id
> acpi_apd_device_ids[] = {
>   /* Generic apd devices */
>   { "AMD0010", APD_ADDR(cz_i2c_desc) },
>   { "AMD0020", APD_ADDR(cz_uart_desc) },
> + { "AMDI0020", APD_ADDR(cz_uart_desc) },
>   { "AMD0030", },
>   { }
>  };
> --
> 1.9.1

RE: [PATCH V2] ACPI: APD: Add device HID for future AMD UART controller

[Xue, Ken]

> From: Wang Hongcheng [mailto:annie.w...@amd.com]
> Sent: Friday, March 11, 2016 5:28 PM
> To: Rafael J. Wysocki; Len Brown; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org; SPG_Linux_Kernel
> Cc: Wang, Annie
> Subject: [PATCH V2] ACPI: APD: Add device HID for future AMD UART
> controller
> 
> Add device HID AMDI0020 to match the AMD ACPI Vendor ID (AMDI) as
> registered in http://www.uefi.org/acpi_id_list, and the UART controller on
> future AMD paltform will use the HID instead of AMD0020.
> 
> Signed-off-by: Wang Hongcheng 


Acked-by: Ken Xue 

Hi Rafael,
Can you help apply and queue this patch into V4.6 like patch  "i2c: designware: 
Add device HID for future AMD I2C controller"?
Thanks.

> ---
>  drivers/acpi/acpi_apd.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c index
> a450e7a..dc2d8a5 100644
> --- a/drivers/acpi/acpi_apd.c
> +++ b/drivers/acpi/acpi_apd.c
> @@ -134,6 +134,7 @@ static const struct acpi_device_id
> acpi_apd_device_ids[] = {
>   /* Generic apd devices */
>   { "AMD0010", APD_ADDR(cz_i2c_desc) },
>   { "AMD0020", APD_ADDR(cz_uart_desc) },
> + { "AMDI0020", APD_ADDR(cz_uart_desc) },
>   { "AMD0030", },
>   { }
>  };
> --
> 1.9.1

Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async

[Byungchul Park]

On Tue, Mar 15, 2016 at 11:07:38PM +0900, Sergey Senozhatsky wrote:
> 
> something like this (*minimally tested so far*).
> 
> -- move wake_up() and friends under the logbuf section; so we can detect
  ^^
  section protected by logbuf_lock?

>printk() recursion from wake_up()

Excuse me, but I fear that it can cause an unnecessary deadlock.
Furthermore it cannot be handled if it is caused by logbuf_lock. IMHO,
nothing including synced printk can help us in this case. Is there
something I missed? I'am sorry if I did, but could you let me know if so?

I mean that it would be better to keep the wake_up and friend out of the
critical section by logbuf_lock.

Thanks,
Byungchul

> 
> -- in recursion_bug branch switch to sync printk. we don't know why did we
>recurse, may be because of wake_up()->spin_lock(). doing
>kthread_stop()->wake_up_process() can be unsafe, I guess, just set
>`printk_sync' to true.
> 
> 
> Signed-off-by: Jan Kara 
> Signed-off-by: Sergey Senozhatsky 
> ---
>  Documentation/kernel-parameters.txt |  10 ++
>  kernel/printk/printk.c  | 202 
> +---
>  2 files changed, 154 insertions(+), 58 deletions(-)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 1e58ae9..454999e 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -3114,6 +3114,16 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   printk.time=Show timing data prefixed to each printk message line
>   Format:   (1/Y/y=enable, 0/N/n=disable)
>  
> + printk.synchronous=
> + By default kernel messages are printed to console
> + asynchronously (except during early boot or when oops
> + is happening). That avoids kernel stalling behind slow
> + serial console and thus avoids softlockups, interrupt
> + timeouts, or userspace timing out during heavy printing.
> + However for debugging problems, printing messages to
> + console immediately may be desirable. This option
> + enables such behavior.
> +
>   processor.max_cstate=   [HW,ACPI]
>   Limit processor to maximum C-state
>   max_cstate=9 overrides any DMI blacklist limit.
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index d5fd844..38baed1 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -46,6 +46,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -284,6 +285,105 @@ static char __log_buf[__LOG_BUF_LEN] 
> __aligned(LOG_ALIGN);
>  static char *log_buf = __log_buf;
>  static u32 log_buf_len = __LOG_BUF_LEN;
>  
> +/*
> + * When true, printing to console will happen synchronously unless someone 
> else
> + * is already printing messages.
> + *
> + * The default value on UP systems is 'true'.
> + */
> +static bool __read_mostly printk_sync = !IS_ENABLED(CONFIG_SMP);
> +module_param_named(synchronous, printk_sync, bool, S_IRUGO | S_IWUSR);
> +MODULE_PARM_DESC(synchronous, "make printing to console synchronous");
> +
> +/* Printing kthread for async vprintk_emit() */
> +static struct task_struct *printk_thread;
> +/* Wait for printing wakeups from async vprintk_emit() */
> +static DECLARE_WAIT_QUEUE_HEAD(printing_wait);
> +
> +static int printing_func(void *data)
> +{
> + while (1) {
> + DECLARE_WAITQUEUE(wait, current);
> + set_current_state(TASK_INTERRUPTIBLE);
> + add_wait_queue(_wait, );
> +
> + schedule();
> + remove_wait_queue(_wait, );
> +
> + console_lock();
> + console_unlock();
> + }
> +
> + return 0;
> +}
> +
> +static int __init init_printk_thread(void)
> +{
> + if (printk_sync)
> + return 0;
> +
> + printk_thread = kthread_run(printing_func, NULL, "printk");
> + BUG_ON(IS_ERR(printk_thread));
> + return 0;
> +}
> +late_initcall(init_printk_thread);
> +
> +/*
> + * Delayed printk version, for scheduler-internal messages:
> + */
> +#define PRINTK_PENDING_WAKEUP(1<<0)
> +#define PRINTK_PENDING_OUTPUT(1<<1)
> +
> +static DEFINE_PER_CPU(int, printk_pending);
> +
> +static void wake_up_klogd_work_func(struct irq_work *irq_work)
> +{
> + int pending = __this_cpu_xchg(printk_pending, 0);
> +
> + if (pending & PRINTK_PENDING_OUTPUT) {
> + if (!printk_sync && printk_thread) {
> + wake_up(_wait);
> + } else {
> + /*
> +  * If trylock fails, someone else is doing
> +  * the printing
> +  */
> +

Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async

[Byungchul Park]

On Tue, Mar 15, 2016 at 11:07:38PM +0900, Sergey Senozhatsky wrote:
> 
> something like this (*minimally tested so far*).
> 
> -- move wake_up() and friends under the logbuf section; so we can detect
  ^^
  section protected by logbuf_lock?

>printk() recursion from wake_up()

Excuse me, but I fear that it can cause an unnecessary deadlock.
Furthermore it cannot be handled if it is caused by logbuf_lock. IMHO,
nothing including synced printk can help us in this case. Is there
something I missed? I'am sorry if I did, but could you let me know if so?

I mean that it would be better to keep the wake_up and friend out of the
critical section by logbuf_lock.

Thanks,
Byungchul

> 
> -- in recursion_bug branch switch to sync printk. we don't know why did we
>recurse, may be because of wake_up()->spin_lock(). doing
>kthread_stop()->wake_up_process() can be unsafe, I guess, just set
>`printk_sync' to true.
> 
> 
> Signed-off-by: Jan Kara 
> Signed-off-by: Sergey Senozhatsky 
> ---
>  Documentation/kernel-parameters.txt |  10 ++
>  kernel/printk/printk.c  | 202 
> +---
>  2 files changed, 154 insertions(+), 58 deletions(-)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 1e58ae9..454999e 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -3114,6 +3114,16 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   printk.time=Show timing data prefixed to each printk message line
>   Format:   (1/Y/y=enable, 0/N/n=disable)
>  
> + printk.synchronous=
> + By default kernel messages are printed to console
> + asynchronously (except during early boot or when oops
> + is happening). That avoids kernel stalling behind slow
> + serial console and thus avoids softlockups, interrupt
> + timeouts, or userspace timing out during heavy printing.
> + However for debugging problems, printing messages to
> + console immediately may be desirable. This option
> + enables such behavior.
> +
>   processor.max_cstate=   [HW,ACPI]
>   Limit processor to maximum C-state
>   max_cstate=9 overrides any DMI blacklist limit.
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index d5fd844..38baed1 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -46,6 +46,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -284,6 +285,105 @@ static char __log_buf[__LOG_BUF_LEN] 
> __aligned(LOG_ALIGN);
>  static char *log_buf = __log_buf;
>  static u32 log_buf_len = __LOG_BUF_LEN;
>  
> +/*
> + * When true, printing to console will happen synchronously unless someone 
> else
> + * is already printing messages.
> + *
> + * The default value on UP systems is 'true'.
> + */
> +static bool __read_mostly printk_sync = !IS_ENABLED(CONFIG_SMP);
> +module_param_named(synchronous, printk_sync, bool, S_IRUGO | S_IWUSR);
> +MODULE_PARM_DESC(synchronous, "make printing to console synchronous");
> +
> +/* Printing kthread for async vprintk_emit() */
> +static struct task_struct *printk_thread;
> +/* Wait for printing wakeups from async vprintk_emit() */
> +static DECLARE_WAIT_QUEUE_HEAD(printing_wait);
> +
> +static int printing_func(void *data)
> +{
> + while (1) {
> + DECLARE_WAITQUEUE(wait, current);
> + set_current_state(TASK_INTERRUPTIBLE);
> + add_wait_queue(_wait, );
> +
> + schedule();
> + remove_wait_queue(_wait, );
> +
> + console_lock();
> + console_unlock();
> + }
> +
> + return 0;
> +}
> +
> +static int __init init_printk_thread(void)
> +{
> + if (printk_sync)
> + return 0;
> +
> + printk_thread = kthread_run(printing_func, NULL, "printk");
> + BUG_ON(IS_ERR(printk_thread));
> + return 0;
> +}
> +late_initcall(init_printk_thread);
> +
> +/*
> + * Delayed printk version, for scheduler-internal messages:
> + */
> +#define PRINTK_PENDING_WAKEUP(1<<0)
> +#define PRINTK_PENDING_OUTPUT(1<<1)
> +
> +static DEFINE_PER_CPU(int, printk_pending);
> +
> +static void wake_up_klogd_work_func(struct irq_work *irq_work)
> +{
> + int pending = __this_cpu_xchg(printk_pending, 0);
> +
> + if (pending & PRINTK_PENDING_OUTPUT) {
> + if (!printk_sync && printk_thread) {
> + wake_up(_wait);
> + } else {
> + /*
> +  * If trylock fails, someone else is doing
> +  * the printing
> +  */
> + if (console_trylock())
> + 

Re: [RFC PATCH kernel] Revert "net/mlx4_core: Set UAR page size to 4KB regardless of system page size"

[Eli Cohen]

On Wed, Mar 16, 2016 at 01:07:58PM +1100, Alexey Kardashevskiy wrote:
> 
> So with v4.5 as a host, there is no actual distro available today to
> use as a guest in the next 6 months (or whatever it takes to
> backport this partucular patch back there).
> 
> You could have added a module parameter to enforce the old behavoir,
> at least...
> 
> And sorry but from the original commit log I could not understand
> why exactly all existing guests need to be broken. Could you please
> point me to a piece of documentation describing all this UAR
> bisuness (what is UAR, why 128 UARs are required and for what, etc).
> Thanks.
> 

We are going to send a patch that fixes this using a module parameter.
The patch will be on top of Huy's patch.

Some background to the problem: mlx4 supported devices require 128 UAR
pages from PCI memory space defined by BAR2-3. Each UAR page can be
any power of 2 value from 4K up to 64K. Before Huy's patch the driver
chose UAR page size to be equal to system page size. Since PowerPC's
page size is 64K this means minimum requirement of UAR pages is not
met (default UAR BAR is 8MB and only half of it is really reserved for
UARs).

More details can be found in the programmer's manual.

Re: [RFC PATCH kernel] Revert "net/mlx4_core: Set UAR page size to 4KB regardless of system page size"

[Eli Cohen]

On Wed, Mar 16, 2016 at 01:07:58PM +1100, Alexey Kardashevskiy wrote:
> 
> So with v4.5 as a host, there is no actual distro available today to
> use as a guest in the next 6 months (or whatever it takes to
> backport this partucular patch back there).
> 
> You could have added a module parameter to enforce the old behavoir,
> at least...
> 
> And sorry but from the original commit log I could not understand
> why exactly all existing guests need to be broken. Could you please
> point me to a piece of documentation describing all this UAR
> bisuness (what is UAR, why 128 UARs are required and for what, etc).
> Thanks.
> 

We are going to send a patch that fixes this using a module parameter.
The patch will be on top of Huy's patch.

Some background to the problem: mlx4 supported devices require 128 UAR
pages from PCI memory space defined by BAR2-3. Each UAR page can be
any power of 2 value from 4K up to 64K. Before Huy's patch the driver
chose UAR page size to be equal to system page size. Since PowerPC's
page size is 64K this means minimum requirement of UAR pages is not
met (default UAR BAR is 8MB and only half of it is really reserved for
UARs).

More details can be found in the programmer's manual.

RE: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller

[Xue, Ken]

> From: Wang Hongcheng [mailto:annie.w...@amd.com]
> Sent: Friday, March 11, 2016 10:59 AM
> To: Linus Walleij; linux-g...@vger.kernel.org; linux-kernel@vger.kernel.org;
> SPG_Linux_Kernel
> Cc: Wang, Annie
> Subject: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller
> 
> Add device HID AMDI0030 to match the AMD ACPI Vendor ID (AMDI) as
> registered in http://www.uefi.org/acpi_id_list, and the GPIO controller on
> future AMD paltform will use the HID instead of AMD0030.
> 
> Signed-off-by: Wang Hongcheng 
> ---

Acked-by: Ken Xue 

Hi Linus,
Can you please help apply and queue this patch into V4.6?
Thanks.

>  drivers/pinctrl/pinctrl-amd.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c 
> index
> 3318f1d..d7eb9ad 100644
> --- a/drivers/pinctrl/pinctrl-amd.c
> +++ b/drivers/pinctrl/pinctrl-amd.c
> @@ -849,6 +849,7 @@ static int amd_gpio_remove(struct platform_device
> *pdev)
> 
>  static const struct acpi_device_id amd_gpio_acpi_match[] = {
>   { "AMD0030", 0 },
> + { "AMDI0030", 0},
>   { },
>  };
>  MODULE_DEVICE_TABLE(acpi, amd_gpio_acpi_match);
> --
> 1.9.1

RE: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller

[Xue, Ken]

> From: Wang Hongcheng [mailto:annie.w...@amd.com]
> Sent: Friday, March 11, 2016 10:59 AM
> To: Linus Walleij; linux-g...@vger.kernel.org; linux-kernel@vger.kernel.org;
> SPG_Linux_Kernel
> Cc: Wang, Annie
> Subject: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller
> 
> Add device HID AMDI0030 to match the AMD ACPI Vendor ID (AMDI) as
> registered in http://www.uefi.org/acpi_id_list, and the GPIO controller on
> future AMD paltform will use the HID instead of AMD0030.
> 
> Signed-off-by: Wang Hongcheng 
> ---

Acked-by: Ken Xue 

Hi Linus,
Can you please help apply and queue this patch into V4.6?
Thanks.

>  drivers/pinctrl/pinctrl-amd.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c 
> index
> 3318f1d..d7eb9ad 100644
> --- a/drivers/pinctrl/pinctrl-amd.c
> +++ b/drivers/pinctrl/pinctrl-amd.c
> @@ -849,6 +849,7 @@ static int amd_gpio_remove(struct platform_device
> *pdev)
> 
>  static const struct acpi_device_id amd_gpio_acpi_match[] = {
>   { "AMD0030", 0 },
> + { "AMDI0030", 0},
>   { },
>  };
>  MODULE_DEVICE_TABLE(acpi, amd_gpio_acpi_match);
> --
> 1.9.1

Re: [PATCH] mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage

[Johannes Weiner]

On Fri, Mar 11, 2016 at 12:19:31PM +0300, Vladimir Davydov wrote:
> On Fri, Mar 11, 2016 at 09:18:25AM +0100, Michal Hocko wrote:
> > On Thu 10-03-16 15:50:14, Johannes Weiner wrote:
> ...
> > > @@ -5037,9 +5040,36 @@ static ssize_t memory_max_write(struct 
> > > kernfs_open_file *of,
> > >   if (err)
> > >   return err;
> > >  
> > > - err = mem_cgroup_resize_limit(memcg, max);
> > > - if (err)
> > > - return err;
> > > + xchg(>memory.limit, max);
> > > +
> > > + for (;;) {
> > > + unsigned long nr_pages = page_counter_read(>memory);
> > > +
> > > + if (nr_pages <= max)
> > > + break;
> > > +
> > > + if (signal_pending(current)) {
> > 
> > Didn't you want fatal_signal_pending here? At least the changelog
> > suggests that.
> 
> I suppose the user might want to interrupt the write by hitting CTRL-C.

Yeah. This is the same thing we do for the current limit setting loop.

> Come to think of it, shouldn't we restore the old limit and return EBUSY
> if we failed to reclaim enough memory?

I suspect it's very rare that it would fail. But even in that case
it's probably better to at least not allow new charges past what the
user requested, even if we can't push the level back far enough.

Re: [PATCH] mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage

[Johannes Weiner]

On Fri, Mar 11, 2016 at 12:19:31PM +0300, Vladimir Davydov wrote:
> On Fri, Mar 11, 2016 at 09:18:25AM +0100, Michal Hocko wrote:
> > On Thu 10-03-16 15:50:14, Johannes Weiner wrote:
> ...
> > > @@ -5037,9 +5040,36 @@ static ssize_t memory_max_write(struct 
> > > kernfs_open_file *of,
> > >   if (err)
> > >   return err;
> > >  
> > > - err = mem_cgroup_resize_limit(memcg, max);
> > > - if (err)
> > > - return err;
> > > + xchg(>memory.limit, max);
> > > +
> > > + for (;;) {
> > > + unsigned long nr_pages = page_counter_read(>memory);
> > > +
> > > + if (nr_pages <= max)
> > > + break;
> > > +
> > > + if (signal_pending(current)) {
> > 
> > Didn't you want fatal_signal_pending here? At least the changelog
> > suggests that.
> 
> I suppose the user might want to interrupt the write by hitting CTRL-C.

Yeah. This is the same thing we do for the current limit setting loop.

> Come to think of it, shouldn't we restore the old limit and return EBUSY
> if we failed to reclaim enough memory?

I suspect it's very rare that it would fail. But even in that case
it's probably better to at least not allow new charges past what the
user requested, even if we can't push the level back far enough.

Re: [PATCH RFC 0/2] mempool based chained scatterlist alloc/free api api

[Ming Lin]

On Tue, 2016-03-15 at 16:12 -0700, James Bottomley wrote:
> On Tue, 2016-03-15 at 15:39 -0700, Ming Lin wrote:
> > From: Ming Lin 
> > 
> > Hi list,
> > 
> > This moves the mempool based chained scatterlist alloc/free code
> > from
> > scsi_lib.c to lib/scatterlist.c.
> > 
> > So other drivers(for example, the under development NVMe over
> > fabric 
> > drivers) can also use it.
> > 
> > Ming Lin (2):
> >   scatterlist: add mempool based chained SG alloc/free api
> >   scsi: use the new chained SG api
> > 
> >  drivers/scsi/scsi_lib.c | 129 ++
> > --
> >  include/linux/scatterlist.h |  12 
> >  lib/scatterlist.c   | 156
> > 
> >  3 files changed, 175 insertions(+), 122 deletions(-)
> 
> I'd really rather this were a single patch so git can tell us the
> code
> motion.  If you add in one patch and remove in another the code
> motion
> trackers don't see it.
> 
> Secondly, you said "This copied code from scsi_lib.c to scatterlist.c
> and modified it a bit" could you move in one patch and modify in
> another, so we can see exactly what you're changing.

The modification is mostly about structure names and function names
changes.

I can do it in a single patch.

> 
> Thirdly, are you sure the pool structure for NVMe should be the same
> as
> for SCSI?  We don't do buddy pools for 1,2 or 4 entry transactions in
> SCSI just basically because of heuristics, but the packetised io
> characteristics of NVMe make single entry lists more likely for it,
> don't they?

Not sure about this, but the nvme-pci driver may not use this api,
because it also has a PRP lists except for the SG lists.

But nvme-over-rdma/nvme-over-fiber-channel driver is good to use this
api.

> 
> James
> 
> 

Re: [PATCH RFC 0/2] mempool based chained scatterlist alloc/free api api

[Ming Lin]

On Tue, 2016-03-15 at 16:12 -0700, James Bottomley wrote:
> On Tue, 2016-03-15 at 15:39 -0700, Ming Lin wrote:
> > From: Ming Lin 
> > 
> > Hi list,
> > 
> > This moves the mempool based chained scatterlist alloc/free code
> > from
> > scsi_lib.c to lib/scatterlist.c.
> > 
> > So other drivers(for example, the under development NVMe over
> > fabric 
> > drivers) can also use it.
> > 
> > Ming Lin (2):
> >   scatterlist: add mempool based chained SG alloc/free api
> >   scsi: use the new chained SG api
> > 
> >  drivers/scsi/scsi_lib.c | 129 ++
> > --
> >  include/linux/scatterlist.h |  12 
> >  lib/scatterlist.c   | 156
> > 
> >  3 files changed, 175 insertions(+), 122 deletions(-)
> 
> I'd really rather this were a single patch so git can tell us the
> code
> motion.  If you add in one patch and remove in another the code
> motion
> trackers don't see it.
> 
> Secondly, you said "This copied code from scsi_lib.c to scatterlist.c
> and modified it a bit" could you move in one patch and modify in
> another, so we can see exactly what you're changing.

The modification is mostly about structure names and function names
changes.

I can do it in a single patch.

> 
> Thirdly, are you sure the pool structure for NVMe should be the same
> as
> for SCSI?  We don't do buddy pools for 1,2 or 4 entry transactions in
> SCSI just basically because of heuristics, but the packetised io
> characteristics of NVMe make single entry lists more likely for it,
> don't they?

Not sure about this, but the nvme-pci driver may not use this api,
because it also has a PRP lists except for the SG lists.

But nvme-over-rdma/nvme-over-fiber-channel driver is good to use this
api.

> 
> James
> 
> 

Re: [PATCH V2 2/2] mailbox: Introduce TI message manager driver

[Jassi Brar]

On Tue, Mar 15, 2016 at 10:35 PM, Nishanth Menon  wrote:
> On Tue, Mar 15, 2016 at 12:31 AM, Jassi Brar  wrote:
>> On Tue, Mar 8, 2016 at 8:07 PM, Nishanth Menon  wrote:
>>> Jassi,
>>>
>>> On Tue, Mar 8, 2016 at 1:10 AM, Jassi Brar  wrote:
 On Tue, Mar 8, 2016 at 2:18 AM, Nishanth Menon  wrote:
> On 03/07/2016 12:31 PM, Jassi Brar wrote:
>> On Fri, Mar 4, 2016 at 8:05 PM, Nishanth Menon  wrote:

> +static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
> +{
> +   struct device *dev = chan->mbox->dev;
> +   struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
> +   const struct ti_msgmgr_desc *desc;
> +   struct ti_queue_inst *qinst = chan->con_priv;
> +   int msg_count, num_words, trail_bytes;
> +   struct ti_msgmgr_message *message = data;
> +   void __iomem *data_reg;
> +   u32 *word_data;
> +
> +   if (WARN_ON(!inst)) {
> +   dev_err(dev, "no platform drv data??\n");
> +   return -EINVAL;
> +   }
> +   desc = inst->desc;
> +
> +   if (desc->max_message_size < message->len) {
> +   dev_err(dev, "Queue %s message length %d > max %d\n",
> +   qinst->name, message->len, 
> desc->max_message_size);
> +   return -EINVAL;
> +   }
> +
> +   /* Are we able to send this or not? */
> +   msg_count = ti_msgmgr_queue_get_num_messages(qinst);
> +   if (msg_count >= desc->max_messages) {
> +   dev_warn(dev, "Queue %s is full (%d messages)\n", 
> qinst->name,
> +msg_count);
> +   return -EBUSY;
> +   }
 This seems fishy. mailbox api always submit 1 'complete' message to be
 sent and checks for completion by last_tx_done() before calling
 send_data() again. Controller drivers are not supposed to queue
 messages - mailbox core does. So you should never be unable to send a
 message.
>>>
>>>
>>> OK-> to explain this, few reasons: (queue messages check and usage of
>>> last_tx_done are kind of intertwined answer..
>>> a) we need to remember that the message manager has a shared RAM.
>>> multiple transmitter over other queues can be sharing the same.
>>> unfortunately, we dont get a threshold kind of interrupt or status that
>>> I am able to exploit in the current incarnation of the solution. The
>>> best we can do in the full system is to constrain the number of messages
>>> that are max pending simultaneously in each of the queue from various
>>> transmitters in the SoC.
>>> b) last_tx_done() is checked if TXDONE_BY_POLL, not if TXDONE_BY_ACK
>>> right? which is how this'd work since txdone_poll is false -> that is
>>> how we want this mechanism to work once the far end is ready for next
>>> message, it acks. I do see your point about being tied to protocol - I
>>> dont like it either.. in fact, I'd prefer that client registration
>>> mention what kind of handshaking is necessary, but: a) that is not how
>>> mailbox framework is constructed at the moment(we state txdone_poll at
>>> mailbox registration, not at client usage) and b) I have no real need
>>> for multiple clients to users of message manager who actually need
>>> non-ACK usage - even for the foreseeable future (at least 1 next
>>> generation of SoC) - if such a need does arise in the future, I will
>>> have to rework framework and make this capability at the registration
>>> time of the client - allowing each client path to use different
>>> mechanisms on hardware such as these that need it.
>>> c) message manager can actually queue more than one message(depending on
>>> client capability). Even though, at this point, we are not really
>>> capable of doing it(again from what I can see for immediate future),
>>> mailbox framework by checking last_tx_done forces a single message
>>> sequencing - which is not really exploiting the capability of the
>>> hardware - in theory, we should be able to queue max num messages, hit
>>> cpuidle and snooze away while the remote entity chomp away data at it's
>>> own pace and finally give us a notification back - but again, we can
>>> argue it is indeed protocol dependent, so setting txdone_poll to false
>>> actually enables that to be done in user. Again - i have no immediate
>>> need for any queued multiple transfer needs yet.. even if i need to, in
>>> the future, it can easily be done by the client by maintaining code as
>>> is - txdone_poll is false.
>>>
>> All 

Re: [PATCH V2 2/2] mailbox: Introduce TI message manager driver

[Jassi Brar]

On Tue, Mar 15, 2016 at 10:35 PM, Nishanth Menon  wrote:
> On Tue, Mar 15, 2016 at 12:31 AM, Jassi Brar  wrote:
>> On Tue, Mar 8, 2016 at 8:07 PM, Nishanth Menon  wrote:
>>> Jassi,
>>>
>>> On Tue, Mar 8, 2016 at 1:10 AM, Jassi Brar  wrote:
 On Tue, Mar 8, 2016 at 2:18 AM, Nishanth Menon  wrote:
> On 03/07/2016 12:31 PM, Jassi Brar wrote:
>> On Fri, Mar 4, 2016 at 8:05 PM, Nishanth Menon  wrote:

> +static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
> +{
> +   struct device *dev = chan->mbox->dev;
> +   struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
> +   const struct ti_msgmgr_desc *desc;
> +   struct ti_queue_inst *qinst = chan->con_priv;
> +   int msg_count, num_words, trail_bytes;
> +   struct ti_msgmgr_message *message = data;
> +   void __iomem *data_reg;
> +   u32 *word_data;
> +
> +   if (WARN_ON(!inst)) {
> +   dev_err(dev, "no platform drv data??\n");
> +   return -EINVAL;
> +   }
> +   desc = inst->desc;
> +
> +   if (desc->max_message_size < message->len) {
> +   dev_err(dev, "Queue %s message length %d > max %d\n",
> +   qinst->name, message->len, 
> desc->max_message_size);
> +   return -EINVAL;
> +   }
> +
> +   /* Are we able to send this or not? */
> +   msg_count = ti_msgmgr_queue_get_num_messages(qinst);
> +   if (msg_count >= desc->max_messages) {
> +   dev_warn(dev, "Queue %s is full (%d messages)\n", 
> qinst->name,
> +msg_count);
> +   return -EBUSY;
> +   }
 This seems fishy. mailbox api always submit 1 'complete' message to be
 sent and checks for completion by last_tx_done() before calling
 send_data() again. Controller drivers are not supposed to queue
 messages - mailbox core does. So you should never be unable to send a
 message.
>>>
>>>
>>> OK-> to explain this, few reasons: (queue messages check and usage of
>>> last_tx_done are kind of intertwined answer..
>>> a) we need to remember that the message manager has a shared RAM.
>>> multiple transmitter over other queues can be sharing the same.
>>> unfortunately, we dont get a threshold kind of interrupt or status that
>>> I am able to exploit in the current incarnation of the solution. The
>>> best we can do in the full system is to constrain the number of messages
>>> that are max pending simultaneously in each of the queue from various
>>> transmitters in the SoC.
>>> b) last_tx_done() is checked if TXDONE_BY_POLL, not if TXDONE_BY_ACK
>>> right? which is how this'd work since txdone_poll is false -> that is
>>> how we want this mechanism to work once the far end is ready for next
>>> message, it acks. I do see your point about being tied to protocol - I
>>> dont like it either.. in fact, I'd prefer that client registration
>>> mention what kind of handshaking is necessary, but: a) that is not how
>>> mailbox framework is constructed at the moment(we state txdone_poll at
>>> mailbox registration, not at client usage) and b) I have no real need
>>> for multiple clients to users of message manager who actually need
>>> non-ACK usage - even for the foreseeable future (at least 1 next
>>> generation of SoC) - if such a need does arise in the future, I will
>>> have to rework framework and make this capability at the registration
>>> time of the client - allowing each client path to use different
>>> mechanisms on hardware such as these that need it.
>>> c) message manager can actually queue more than one message(depending on
>>> client capability). Even though, at this point, we are not really
>>> capable of doing it(again from what I can see for immediate future),
>>> mailbox framework by checking last_tx_done forces a single message
>>> sequencing - which is not really exploiting the capability of the
>>> hardware - in theory, we should be able to queue max num messages, hit
>>> cpuidle and snooze away while the remote entity chomp away data at it's
>>> own pace and finally give us a notification back - but again, we can
>>> argue it is indeed protocol dependent, so setting txdone_poll to false
>>> actually enables that to be done in user. Again - i have no immediate
>>> need for any queued multiple transfer needs yet.. even if i need to, in
>>> the future, it can easily be done by the client by maintaining code as
>>> is - txdone_poll is false.
>>>
>> All I suggest is that the controller does not queue more than 1
>> message at a time, which means the 

Re: [GIT PULL] LED subsystem updates for 4.6

[Linus Torvalds]

On Mon, Mar 14, 2016 at 3:24 AM, Jacek Anaszewski
 wrote:
>
> New LED class driver:
>
> - Add driver for the ISSI IS31FL32xx family of LED controllers.

Grr. This has apparently not gotten with the program, and causes a few
annoying warnings:

drivers/leds/leds-is31fl32xx.c: In function ‘is31fl32xx_parse_child_dt’:
drivers/leds/leds-is31fl32xx.c:345:30: warning: passing argument 1 of
‘of_property_read_string’ discards ‘const’ qualifier from pointer
target type [-Wdiscarded-qualifiers]
  if (of_property_read_string(child, "label", >name))
  ^

(there's another at line 357)

I've pulled, but I'll expect this to be fixed.

  Linus

Re: [GIT PULL] LED subsystem updates for 4.6

[Linus Torvalds]

On Mon, Mar 14, 2016 at 3:24 AM, Jacek Anaszewski
 wrote:
>
> New LED class driver:
>
> - Add driver for the ISSI IS31FL32xx family of LED controllers.

Grr. This has apparently not gotten with the program, and causes a few
annoying warnings:

drivers/leds/leds-is31fl32xx.c: In function ‘is31fl32xx_parse_child_dt’:
drivers/leds/leds-is31fl32xx.c:345:30: warning: passing argument 1 of
‘of_property_read_string’ discards ‘const’ qualifier from pointer
target type [-Wdiscarded-qualifiers]
  if (of_property_read_string(child, "label", >name))
  ^

(there's another at line 357)

I've pulled, but I'll expect this to be fixed.

  Linus

Re: [GIT PULL] LED subsystem updates for 4.6

[Linus Torvalds]

On Tue, Mar 15, 2016 at 12:51 AM, Jacek Anaszewski
 wrote:
>
> I just wanted to make sure that no unexpected problem has occurred
> after rebasing onto 4.5 release. Is it in some way more advantageous to
> base a pull request on rc7, than on a final release?

I'd rather see the pull request based on whatever it has been tested
on, and just keep it that way.

Any rebasing will inevitably mean that you are basically throwing all
previous testing out the window (or at least make it dubious).

Rebasing also makes it much harder to see the history (for example,
compare it against previous linux-next trees), so the rule really
should be that you should never rebase unless you have a major reason
to do so.

So for example, if you actually find a problem, and you notice that
that problem comes not from your own changes, but from the base you
picked - *then* you'd want to rebase to a more stable base. But a
rebase "just because" is not a good idea.

I'll pull it, since it looks fairly harmless, but basically please
don't do that again.

  Linus

Re: [GIT PULL] LED subsystem updates for 4.6

[Linus Torvalds]

On Tue, Mar 15, 2016 at 12:51 AM, Jacek Anaszewski
 wrote:
>
> I just wanted to make sure that no unexpected problem has occurred
> after rebasing onto 4.5 release. Is it in some way more advantageous to
> base a pull request on rc7, than on a final release?

I'd rather see the pull request based on whatever it has been tested
on, and just keep it that way.

Any rebasing will inevitably mean that you are basically throwing all
previous testing out the window (or at least make it dubious).

Rebasing also makes it much harder to see the history (for example,
compare it against previous linux-next trees), so the rule really
should be that you should never rebase unless you have a major reason
to do so.

So for example, if you actually find a problem, and you notice that
that problem comes not from your own changes, but from the base you
picked - *then* you'd want to rebase to a more stable base. But a
rebase "just because" is not a good idea.

I'll pull it, since it looks fairly harmless, but basically please
don't do that again.

  Linus

Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources

[David Lechner]

On 03/15/2016 10:46 PM, David Lechner wrote:

On 03/15/2016 05:45 PM, Sergei Shtylyov wrote:


No, this register is shared b/w MUSB and OHCI. The proper thing to
do is to write the PHY driver and let it control this shared register.



OK. I've started working on this. I am looking at using struct usb_phy,
however, enum usb_phy_type only has USB_PHY_TYPE_UNDEFINED,
USB_PHY_TYPE_USB2, and USB_PHY_TYPE_USB3. Would it be acceptable to use
USB_PHY_TYPE_UNDEFINED for the ohci since it is USB 1.1? Or perhaps I
should use the more generic struct phy for that one?



Also, I am not finding any existing data structure to pass the musb 
set_mode function to the phy in either usb_phy or usb_otg. Setting the 
mode (host/peripheral/otg) is done in the same PHY register, so it seems 
like it should be implemented in the new phy driver as well.


I guess I could use a generic phy instead and use phy_set_drvdata() to 
share data between the phy driver and the musb driver. Does this sound 
like a reasonable thing to do?

Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources

[David Lechner]

On 03/15/2016 10:46 PM, David Lechner wrote:

On 03/15/2016 05:45 PM, Sergei Shtylyov wrote:


No, this register is shared b/w MUSB and OHCI. The proper thing to
do is to write the PHY driver and let it control this shared register.



OK. I've started working on this. I am looking at using struct usb_phy,
however, enum usb_phy_type only has USB_PHY_TYPE_UNDEFINED,
USB_PHY_TYPE_USB2, and USB_PHY_TYPE_USB3. Would it be acceptable to use
USB_PHY_TYPE_UNDEFINED for the ohci since it is USB 1.1? Or perhaps I
should use the more generic struct phy for that one?



Also, I am not finding any existing data structure to pass the musb 
set_mode function to the phy in either usb_phy or usb_otg. Setting the 
mode (host/peripheral/otg) is done in the same PHY register, so it seems 
like it should be implemented in the new phy driver as well.


I guess I could use a generic phy instead and use phy_set_drvdata() to 
share data between the phy driver and the musb driver. Does this sound 
like a reasonable thing to do?

Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature

[Pankaj Gupta]

> 
> The following series adds the ability for a hypervisor to set an MTU on the
> guest during feature negotiation phase. This is useful for VM orchestration
> when, for instance, tunneling is involved and the MTU of the various systems
> should be homogenous.
> 
> The first patch adds the feature bit as described in the proposed VFIO spec

You mean VIRTIO spec?

> addition found at
> https://lists.oasis-open.org/archives/virtio-dev/201603/msg1.html
> 
> The second patch adds a user of the bit, and a warning when the guest changes
> the MTU from the hypervisor advised MTU. Future patches may add more thorough
> error handling.
> 
> v2:
> * Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni
> * Additional test before printing a warning
> 
> Aaron Conole (2):
>   virtio: Start feature MTU support
>   virtio_net: Read the advised MTU
> 
>  drivers/net/virtio_net.c| 12 
>  include/uapi/linux/virtio_net.h |  3 +++
>  2 files changed, 15 insertions(+)
> 
> --
> 2.5.0
> 
> 

Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature

[Pankaj Gupta]

> 
> The following series adds the ability for a hypervisor to set an MTU on the
> guest during feature negotiation phase. This is useful for VM orchestration
> when, for instance, tunneling is involved and the MTU of the various systems
> should be homogenous.
> 
> The first patch adds the feature bit as described in the proposed VFIO spec

You mean VIRTIO spec?

> addition found at
> https://lists.oasis-open.org/archives/virtio-dev/201603/msg1.html
> 
> The second patch adds a user of the bit, and a warning when the guest changes
> the MTU from the hypervisor advised MTU. Future patches may add more thorough
> error handling.
> 
> v2:
> * Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni
> * Additional test before printing a warning
> 
> Aaron Conole (2):
>   virtio: Start feature MTU support
>   virtio_net: Read the advised MTU
> 
>  drivers/net/virtio_net.c| 12 
>  include/uapi/linux/virtio_net.h |  3 +++
>  2 files changed, 15 insertions(+)
> 
> --
> 2.5.0
> 
> 

Re: [PATCH] nouveau: fix nv40_perfctr_next() cleanup regression

[Ben Skeggs]

On 03/15/2016 12:24 AM, Arnd Bergmann wrote:
> gcc-6 warns about code in the nouveau driver that is obviously silly:
> 
> drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function 
> 'nv40_perfctr_next':
> drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison 
> always evaluats to false [-Wtautological-compare]
>   if (pm->sequence != pm->sequence) {
> 
> The behavior was accidentally introduced in a patch described as "This is
> purely preparation for upcoming commits, there should be no code changes 
> here.".
> As far as I can tell, that was true for the rest of that patch except for
> this one function, which has been changed to a NOP.
> 
> This patch restores the original behavior.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 8c1aeaa13954 ("drm/nouveau/pm: cosmetic changes")
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> index 4bef72a9d106..3fda594700e0 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> @@ -59,9 +59,11 @@ static void
>  nv40_perfctr_next(struct nvkm_pm *pm, struct nvkm_perfdom *dom)
>  {
>   struct nvkm_device *device = pm->engine.subdev.device;
> - if (pm->sequence != pm->sequence) {
> + struct nv40_pm *nv40pm = container_of(pm, struct nv40_pm, base);
> +
> + if (nv40pm->sequence != pm->sequence) {
>   nvkm_wr32(device, 0x400084, 0x0020);
> - pm->sequence = pm->sequence;
> + nv40pm->sequence = pm->sequence;
>   }
>  }
>  
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] nouveau: fix nv40_perfctr_next() cleanup regression

[Ben Skeggs]

On 03/15/2016 12:24 AM, Arnd Bergmann wrote:
> gcc-6 warns about code in the nouveau driver that is obviously silly:
> 
> drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function 
> 'nv40_perfctr_next':
> drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison 
> always evaluats to false [-Wtautological-compare]
>   if (pm->sequence != pm->sequence) {
> 
> The behavior was accidentally introduced in a patch described as "This is
> purely preparation for upcoming commits, there should be no code changes 
> here.".
> As far as I can tell, that was true for the rest of that patch except for
> this one function, which has been changed to a NOP.
> 
> This patch restores the original behavior.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 8c1aeaa13954 ("drm/nouveau/pm: cosmetic changes")
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> index 4bef72a9d106..3fda594700e0 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> @@ -59,9 +59,11 @@ static void
>  nv40_perfctr_next(struct nvkm_pm *pm, struct nvkm_perfdom *dom)
>  {
>   struct nvkm_device *device = pm->engine.subdev.device;
> - if (pm->sequence != pm->sequence) {
> + struct nv40_pm *nv40pm = container_of(pm, struct nv40_pm, base);
> +
> + if (nv40pm->sequence != pm->sequence) {
>   nvkm_wr32(device, 0x400084, 0x0020);
> - pm->sequence = pm->sequence;
> + nv40pm->sequence = pm->sequence;
>   }
>  }
>  
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] cpufreq: acpi: Allow new dynamics attributes to be added to acpi_cpufreq_attr

[Viresh Kumar]

On 09-03-16, 14:13, Rafael J. Wysocki wrote:
> On Wed, Mar 9, 2016 at 10:41 AM, Viresh Kumar  wrote:
> > On 03-03-16, 18:29, Rafael J. Wysocki wrote:
> >> Srinivas, can you please take this and rebase your patch on top of it?
> >>  Or if you prefer, I can take it into my linux-next branch.
> >
> > Right, so you need to apply this patch as Srinivas already sent a separate 
> > patch
> > for his stuff, rebased over this.
> 
> I know, but I'm deferring that one as we aren't entirely sure about
> the approach yet.

I might have missed, but what are we not sure about here ? I thought, all three
of us agreed that this is a good idea ..

-- 
viresh

Re: [PATCH] cpufreq: acpi: Allow new dynamics attributes to be added to acpi_cpufreq_attr

[Viresh Kumar]

On 09-03-16, 14:13, Rafael J. Wysocki wrote:
> On Wed, Mar 9, 2016 at 10:41 AM, Viresh Kumar  wrote:
> > On 03-03-16, 18:29, Rafael J. Wysocki wrote:
> >> Srinivas, can you please take this and rebase your patch on top of it?
> >>  Or if you prefer, I can take it into my linux-next branch.
> >
> > Right, so you need to apply this patch as Srinivas already sent a separate 
> > patch
> > for his stuff, rebased over this.
> 
> I know, but I'm deferring that one as we aren't entirely sure about
> the approach yet.

I might have missed, but what are we not sure about here ? I thought, all three
of us agreed that this is a good idea ..

-- 
viresh

Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()

[Viresh Kumar]

On 16-03-16, 01:51, Rafael J. Wysocki wrote:
> OK, so the problem with doing that in syscore ops is that the I2C bus
> needed for it may not be available at that point, which is fair
> enough.

Not just that. We wouldn't call syscore-ops for the boot-cpu. It never went
away.

> Still, though, the way it is done now is really awful and has to go.
> 
> I guess something along the lines of cpufreq_update_policy() might be
> done in cpufreq_resume() before governors are started, but it might
> even be better to set policy->cur from scratch when starting the
> governors.  Just do driver->get() and set policy->cur to what that
> returns (or just use the average of min and max if ->get is not
> available).  And that unconditionally, regardless of the reason why
> the governors are started.

I think doing it from a somewhat centric location would make more sense then
pushing this for the governors. Maybe the beginning of cpufreq_resume() is good
enough for that.

-- 
viresh

Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()

[Viresh Kumar]

On 16-03-16, 01:51, Rafael J. Wysocki wrote:
> OK, so the problem with doing that in syscore ops is that the I2C bus
> needed for it may not be available at that point, which is fair
> enough.

Not just that. We wouldn't call syscore-ops for the boot-cpu. It never went
away.

> Still, though, the way it is done now is really awful and has to go.
> 
> I guess something along the lines of cpufreq_update_policy() might be
> done in cpufreq_resume() before governors are started, but it might
> even be better to set policy->cur from scratch when starting the
> governors.  Just do driver->get() and set policy->cur to what that
> returns (or just use the average of min and max if ->get is not
> available).  And that unconditionally, regardless of the reason why
> the governors are started.

I think doing it from a somewhat centric location would make more sense then
pushing this for the governors. Maybe the beginning of cpufreq_resume() is good
enough for that.

-- 
viresh

Re: [RESEND PATCH v2] ARM64: ACPI: Update documentation for latest specification version

[Vikas Sajjan]

Hi Al Stone,

On Wed, Mar 16, 2016 at 1:58 AM, Al Stone  wrote:
> The ACPI 6.1 specification was recently released at the end of January 2016,
> but the arm64 kernel documentation for the use of ACPI was written for the
> 5.1 version of the spec.  There were significant additions to the spec that
> had not yet been mentioned -- for example, the 6.0 mechanisms added to make
> it easier to define processors and low power idle states, as well as the
> 6.1 addition allowing regular interrupts (not just from GPIO) be used to
> signal ACPI general purpose events.
>
> This patch reflects going back through and examining the specs in detail
> and updating content appropriately.  Whilst there, a few odds and ends of
> typos were caught as well.  This brings the documentation up to date with
> ACPI 6.1 for arm64.
>
> RESEND:
>-- Corrected From: header and added missing Cc's
>
> Changes for v2:
>-- Clean up white space (Harb Abdulhahmid)
>-- Clarification on _CCA usage (Harb Abdulhamid)
>-- IORT moved to required from recommended (Hanjun Guo)
>-- Clarify IORT description (Hanjun Guo)
>
> Signed-off-by: Al Stone 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Jonathan Corbet 
> ---
>  Documentation/arm64/acpi_object_usage.txt | 445 
> ++
>  Documentation/arm64/arm-acpi.txt  |  28 +-
>  2 files changed, 356 insertions(+), 117 deletions(-)
>
> diff --git a/Documentation/arm64/acpi_object_usage.txt 
> b/Documentation/arm64/acpi_object_usage.txt
> index a6e1a18..29bc1a1 100644
> --- a/Documentation/arm64/acpi_object_usage.txt
> +++ b/Documentation/arm64/acpi_object_usage.txt
> @@ -11,15 +11,16 @@ outside of the UEFI Forum (see Section 5.2.6 of the 
> specification).
>
>  For ACPI on arm64, tables also fall into the following categories:
>
> -   -- Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
> +   -- Required: DSDT, FADT, GTDT, IORT, MADT, MCFG, RSDP, SPCR, XSDT
>
> -   -- Recommended: BERT, EINJ, ERST, HEST, SSDT
> +   -- Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT
>
> -   -- Optional: BGRT, CPEP, CSRT, DRTM, ECDT, FACS, FPDT, MCHI, MPST,
> -  MSCT, RASF, SBST, SLIT, SPMI, SRAT, TCPA, TPM2, UEFI
> +   -- Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, MCHI,
> +  MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO, TCPA,
> +  TPM2, UEFI, XENV
>
> -   -- Not supported: BOOT, DBG2, DBGP, DMAR, ETDT, HPET, IBFT, IVRS,
> -  LPIT, MSDM, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
> +   -- Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, LPIT,
> +  MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
>
>
>  Table  Usage for ARMv8 Linux
> @@ -50,7 +51,8 @@ CSRT   Signature Reserved (signature == "CSRT")
>
>  DBG2   Signature Reserved (signature == "DBG2")
> == DeBuG port table 2 ==
> -   Microsoft only table, will not be supported.
> +   License has changed and should be usable.  Optional if used instead
> +   of earlycon= on the command line.
>
>  DBGP   Signature Reserved (signature == "DBGP")
> == DeBuG Port table ==
> @@ -133,10 +135,11 @@ GTDT   Section 5.2.24 (signature == "GTDT")
>
>  HEST   Section 18.3.2 (signature == "HEST")
> == Hardware Error Source Table ==
> -   Until further error source types are defined, use only types 6 (AER
> -   Root Port), 7 (AER Endpoint), 8 (AER Bridge), or 9 (Generic Hardware
> -   Error Source).  Firmware first error handling is possible if and only
> -   if Trusted Firmware is being used on arm64.
> +   ARM-specific error sources have been defined; please use those or the
> +   PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 (AER
> +   Bridge), or use type 9 (Generic Hardware Error Source).  Firmware 
> first
> +   error handling is possible if and only if Trusted Firmware is being
> +   used on arm64.
>
> Must be supplied if RAS support is provided by the platform.  It
> is recommended this table be supplied.
> @@ -149,20 +152,27 @@ IBFT   Signature Reserved (signature == "IBFT")
> == iSCSI Boot Firmware Table ==
> Microsoft defined table, support TBD.
>
> +IORT   Signature Reserved (signature == "IORT")
> +   == Input Output Remapping Table ==
> +   arm64 only table, required in order to describe IO topology, SMMUs,
> +   and GIC ITSs, and how those various components are connected together,
> +   such as identifying which components are behind which SMMUs/ITSs.
> +
>  IVRS   Signature Reserved (signature == "IVRS")
> == I/O Virtualization Reporting Structure ==
> x86_64 (AMD) only table, will not be supported.
>
>  LPIT   Signature Reserved (signature == "LPIT")
> == Low Power Idle Table ==
> -   x86 only table as of ACPI 5.1; future versions have been adapted 

Re: [RESEND PATCH v2] ARM64: ACPI: Update documentation for latest specification version

[Vikas Sajjan]

Hi Al Stone,

On Wed, Mar 16, 2016 at 1:58 AM, Al Stone  wrote:
> The ACPI 6.1 specification was recently released at the end of January 2016,
> but the arm64 kernel documentation for the use of ACPI was written for the
> 5.1 version of the spec.  There were significant additions to the spec that
> had not yet been mentioned -- for example, the 6.0 mechanisms added to make
> it easier to define processors and low power idle states, as well as the
> 6.1 addition allowing regular interrupts (not just from GPIO) be used to
> signal ACPI general purpose events.
>
> This patch reflects going back through and examining the specs in detail
> and updating content appropriately.  Whilst there, a few odds and ends of
> typos were caught as well.  This brings the documentation up to date with
> ACPI 6.1 for arm64.
>
> RESEND:
>-- Corrected From: header and added missing Cc's
>
> Changes for v2:
>-- Clean up white space (Harb Abdulhahmid)
>-- Clarification on _CCA usage (Harb Abdulhamid)
>-- IORT moved to required from recommended (Hanjun Guo)
>-- Clarify IORT description (Hanjun Guo)
>
> Signed-off-by: Al Stone 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Jonathan Corbet 
> ---
>  Documentation/arm64/acpi_object_usage.txt | 445 
> ++
>  Documentation/arm64/arm-acpi.txt  |  28 +-
>  2 files changed, 356 insertions(+), 117 deletions(-)
>
> diff --git a/Documentation/arm64/acpi_object_usage.txt 
> b/Documentation/arm64/acpi_object_usage.txt
> index a6e1a18..29bc1a1 100644
> --- a/Documentation/arm64/acpi_object_usage.txt
> +++ b/Documentation/arm64/acpi_object_usage.txt
> @@ -11,15 +11,16 @@ outside of the UEFI Forum (see Section 5.2.6 of the 
> specification).
>
>  For ACPI on arm64, tables also fall into the following categories:
>
> -   -- Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
> +   -- Required: DSDT, FADT, GTDT, IORT, MADT, MCFG, RSDP, SPCR, XSDT
>
> -   -- Recommended: BERT, EINJ, ERST, HEST, SSDT
> +   -- Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT
>
> -   -- Optional: BGRT, CPEP, CSRT, DRTM, ECDT, FACS, FPDT, MCHI, MPST,
> -  MSCT, RASF, SBST, SLIT, SPMI, SRAT, TCPA, TPM2, UEFI
> +   -- Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, MCHI,
> +  MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO, TCPA,
> +  TPM2, UEFI, XENV
>
> -   -- Not supported: BOOT, DBG2, DBGP, DMAR, ETDT, HPET, IBFT, IVRS,
> -  LPIT, MSDM, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
> +   -- Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, LPIT,
> +  MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
>
>
>  Table  Usage for ARMv8 Linux
> @@ -50,7 +51,8 @@ CSRT   Signature Reserved (signature == "CSRT")
>
>  DBG2   Signature Reserved (signature == "DBG2")
> == DeBuG port table 2 ==
> -   Microsoft only table, will not be supported.
> +   License has changed and should be usable.  Optional if used instead
> +   of earlycon= on the command line.
>
>  DBGP   Signature Reserved (signature == "DBGP")
> == DeBuG Port table ==
> @@ -133,10 +135,11 @@ GTDT   Section 5.2.24 (signature == "GTDT")
>
>  HEST   Section 18.3.2 (signature == "HEST")
> == Hardware Error Source Table ==
> -   Until further error source types are defined, use only types 6 (AER
> -   Root Port), 7 (AER Endpoint), 8 (AER Bridge), or 9 (Generic Hardware
> -   Error Source).  Firmware first error handling is possible if and only
> -   if Trusted Firmware is being used on arm64.
> +   ARM-specific error sources have been defined; please use those or the
> +   PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 (AER
> +   Bridge), or use type 9 (Generic Hardware Error Source).  Firmware 
> first
> +   error handling is possible if and only if Trusted Firmware is being
> +   used on arm64.
>
> Must be supplied if RAS support is provided by the platform.  It
> is recommended this table be supplied.
> @@ -149,20 +152,27 @@ IBFT   Signature Reserved (signature == "IBFT")
> == iSCSI Boot Firmware Table ==
> Microsoft defined table, support TBD.
>
> +IORT   Signature Reserved (signature == "IORT")
> +   == Input Output Remapping Table ==
> +   arm64 only table, required in order to describe IO topology, SMMUs,
> +   and GIC ITSs, and how those various components are connected together,
> +   such as identifying which components are behind which SMMUs/ITSs.
> +
>  IVRS   Signature Reserved (signature == "IVRS")
> == I/O Virtualization Reporting Structure ==
> x86_64 (AMD) only table, will not be supported.
>
>  LPIT   Signature Reserved (signature == "LPIT")
> == Low Power Idle Table ==
> -   x86 only table as of ACPI 5.1; future versions have been adapted for
> -   use with ARM and will be recommended in order to support ACPI power
> -   management.

Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()

[Viresh Kumar]

On 15-03-16, 13:11, Rafael J. Wysocki wrote:
> On Tue, Mar 15, 2016 at 7:10 AM, Viresh Kumar  wrote:
> > On 12-03-16, 03:05, Rafael J. Wysocki wrote:
> >> From: Rafael J. Wysocki 
> >>
> >> cpufreq_resume() attempts to resync the current frequency with
> >> policy->cur for the first online CPU, but first it does that after
> >> restarting governors for all active policies (which means that this
> >> is racy with respect to whatever the governors do) and second it
> >
> > Why? Its doing the update withing policy->rwsem ..
> 
> Which doesn't matter.
> 
> dbs_work_handler() doesn't acquire policy->rwsem and may be executed
> in parallel with this, for example.

Right, so we need to fixup something here.

> >> already is too late for that when cpufreq_resume() is called (that
> >> happens after invoking ->resume callbacks for all devices in the
> >> system).
> >>
> >> Also it doesn't make sense to do that for one CPU only in any case,
> >> because the other CPUs in the system need not share the policy with
> >> it and their policy->cur may be out of sync as well in principle.
> >
> > Its done just for the boot CPU, because that's the only CPU that goes to
> > suspend. All other CPUs are disabled/enabled and so the policies are
> > reinitialized for policy->cur as well.
> >
> > I think, its still important to get things in sync, as some bootloader may
> > change the frequency to something else during resume.
> >
> > And our code may not be safe for the case, the current frequency of the CPU
> > isn't part of the freq-table of the policy.
> 
> Since we're already started the governor at this point (or called the
> driver's ->resume), so the CPU is (or shortly will be) running at a
> frequency that makes sense at this point.
> 
> It might be running at a wrong one before, but not when this code is executed.

Not necessarily.

Consider Performance governor for example. Lets say policy->max is 1 GHz, so
before suspend policy->cur will be 1 GHz. We suspended and resumed, and the
bootloader changed the frequency to 500 MHz (but policy->cur remains the same at
1 GHz). Even after calling START for the governor, it will continue to run at
500 MHz.

So, your patch break things for sure.

> I kind of understand the motivation for this code, but it's too late
> to fix up the frequency of the boot CPU at this point.  If you are
> really worried about it, the time to do that is in syscore ops.

Hmm, so maybe fix policy->cur at the top of this routine? syscore-ops wouldn't
get called for boot-cpu and so it wouldn't matter.

-- 
viresh

Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()

[Viresh Kumar]

On 15-03-16, 13:11, Rafael J. Wysocki wrote:
> On Tue, Mar 15, 2016 at 7:10 AM, Viresh Kumar  wrote:
> > On 12-03-16, 03:05, Rafael J. Wysocki wrote:
> >> From: Rafael J. Wysocki 
> >>
> >> cpufreq_resume() attempts to resync the current frequency with
> >> policy->cur for the first online CPU, but first it does that after
> >> restarting governors for all active policies (which means that this
> >> is racy with respect to whatever the governors do) and second it
> >
> > Why? Its doing the update withing policy->rwsem ..
> 
> Which doesn't matter.
> 
> dbs_work_handler() doesn't acquire policy->rwsem and may be executed
> in parallel with this, for example.

Right, so we need to fixup something here.

> >> already is too late for that when cpufreq_resume() is called (that
> >> happens after invoking ->resume callbacks for all devices in the
> >> system).
> >>
> >> Also it doesn't make sense to do that for one CPU only in any case,
> >> because the other CPUs in the system need not share the policy with
> >> it and their policy->cur may be out of sync as well in principle.
> >
> > Its done just for the boot CPU, because that's the only CPU that goes to
> > suspend. All other CPUs are disabled/enabled and so the policies are
> > reinitialized for policy->cur as well.
> >
> > I think, its still important to get things in sync, as some bootloader may
> > change the frequency to something else during resume.
> >
> > And our code may not be safe for the case, the current frequency of the CPU
> > isn't part of the freq-table of the policy.
> 
> Since we're already started the governor at this point (or called the
> driver's ->resume), so the CPU is (or shortly will be) running at a
> frequency that makes sense at this point.
> 
> It might be running at a wrong one before, but not when this code is executed.

Not necessarily.

Consider Performance governor for example. Lets say policy->max is 1 GHz, so
before suspend policy->cur will be 1 GHz. We suspended and resumed, and the
bootloader changed the frequency to 500 MHz (but policy->cur remains the same at
1 GHz). Even after calling START for the governor, it will continue to run at
500 MHz.

So, your patch break things for sure.

> I kind of understand the motivation for this code, but it's too late
> to fix up the frequency of the boot CPU at this point.  If you are
> really worried about it, the time to do that is in syscore ops.

Hmm, so maybe fix policy->cur at the top of this routine? syscore-ops wouldn't
get called for boot-cpu and so it wouldn't matter.

-- 
viresh

Re: kernel OOPS in MM(?)

[Evgenii Lepikhin]

Hello,

On 2016-03-10 12:31, Evgenii Lepikhin wrote:

> We need help to understand the source of the problem and may be to create a 
> bugreport. Here is crash report:
>
> Mar 10 04:03:51 l28 kernel: [2075560.434445] BUG: unable to handle kernel 
> paging request at 40008021
> Mar 10 04:03:51 l28 kernel: [2075560.434669] IP: [] 
> __kmalloc+0x69/0x100
> Mar 10 04:03:51 l28 kernel: [2075560.434800] PGD b7e462067 PUD 0 
> Mar 10 04:03:51 l28 kernel: [2075560.434913] Oops:  [#1] SMP 
> Mar 10 04:03:51 l28 kernel: [2075560.435044] Modules linked in:
> tcm_loop iscsi_target_mod target_core_pscsi target_core_file
> target_core_iblock target_core_mod ipt_NETFLOW(O) configfs iscsi_tcp
> libis
> csi_tcp libiscsi scsi_transport_iscsi fuse [last unloaded: ipfw_mod]
> Mar 10 04:03:51 l28 kernel: [2075560.435539] CPU: 4 PID: 27141 Comm: rm 
> Tainted: G   O 3.12.51-jl-2015-12-25 #1
> Mar 10 04:03:51 l28 kernel: [2075560.435734] Hardware name: Intel Corporation 
> S2600IP ../S2600IP, BIOS SE5C600.86B.01.08.0003.022620131521 
> 02/26/2013
> Mar 10 04:03:51 l28 kernel: [2075560.435939] task: 880e622ccba0 ti: 
> 880eeb008000 task.ti: 880eeb008000
> Mar 10 04:03:51 l28 kernel: [2075560.436131] RIP: 0010:[]  
> [] __kmalloc+0x69/0x100
> Mar 10 04:03:51 l28 kernel: [2075560.436333] RSP: 0018:880eeb009b38  
> EFLAGS: 00010282
> Mar 10 04:03:51 l28 kernel: [2075560.436439] RAX:  RBX: 
>  RCX: a8a73dc2
> Mar 10 04:03:51 l28 kernel: [2075560.436632] RDX: a8a73dc1 RSI: 
>  RDI: 00013500
> Mar 10 04:03:51 l28 kernel: [2075560.438248] RBP: 880eeb009b58 R08: 
> 88103fc13500 R09: 811a0267
> Mar 10 04:03:51 l28 kernel: [2075560.438446] R10: 880eeb009d84 R11: 
>  R12: 88081f803a00
> Mar 10 04:03:51 l28 kernel: [2075560.438656] R13: 40008021 R14: 
> 0250 R15: 880250e833b0
> Mar 10 04:03:51 l28 kernel: [2075560.438851] FS:  7fe2316dd700() 
> GS:88103fc0() knlGS:
> Mar 10 04:03:51 l28 kernel: [2075560.439045] CS:  0010 DS:  ES:  CR0: 
> 80050033
> Mar 10 04:03:51 l28 kernel: [2075560.439152] CR2: 40008021 CR3: 
> 000a20736000 CR4: 000407e0
> Mar 10 04:03:51 l28 kernel: [2075560.439343] Stack:
> Mar 10 04:03:51 l28 kernel: [2075560.439439]   
> 0250 0060 
> Mar 10 04:03:51 l28 kernel: [2075560.439663]  880eeb009b88 
> 811a0267 881015fb7fe0 0060
> Mar 10 04:03:51 l28 kernel: [2075560.439898]  880250e83490 
>  880eeb009ba8 811a02f8
> Mar 10 04:03:51 l28 kernel: [2075560.440153] Call Trace:
> Mar 10 04:03:51 l28 kernel: [2075560.440257]  [] 
> kmem_alloc+0x67/0xe0
> Mar 10 04:03:51 l28 kernel: [2075560.440365]  [] 
> kmem_zalloc+0x18/0x40
> Mar 10 04:03:51 l28 kernel: [2075560.440473]  [] 
> xfs_log_commit_cil+0x373/0x4c0
> Mar 10 04:03:51 l28 kernel: [2075560.440585]  [] ? 
> xfs_bmap_search_multi_extents+0xe0/0x110
> Mar 10 04:03:51 l28 kernel: [2075560.440783]  [] 
> xfs_trans_commit+0x6c/0x250
> Mar 10 04:03:51 l28 kernel: [2075560.440899]  [] 
> xfs_bmap_finish+0xb7/0x1a0

Another issue on the same server, same instruction pointer:

Mar 16 04:53:54 l28 kernel: [521052.387878] BUG: unable to handle kernel paging 
request at 40008021
Mar 16 04:53:54 l28 kernel: [521052.388022] IP: [] 
__kmalloc+0x69/0x100
Mar 16 04:53:54 l28 kernel: [521052.388171] PGD 0 
Mar 16 04:53:54 l28 kernel: [521052.388289] Oops:  [#1] SMP 
Mar 16 04:53:54 l28 kernel: [521052.388410] Modules linked in: tcm_loop 
iscsi_target_mod target_core_pscsi target_core_file target_core_iblock 
target_core_mod ipt_NETFLOW(O) configfs iscsi_tcp libis
csi_tcp libiscsi scsi_transport_iscsi fuse
Mar 16 04:53:54 l28 kernel: [521052.388913] CPU: 6 PID: 5947 Comm: iscsi_trx 
Tainted: G   O 3.12.51-jl-2015-12-25 #1
Mar 16 04:53:54 l28 kernel: [521052.389125] Hardware name: Intel Corporation 
S2600IP ../S2600IP, BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013
Mar 16 04:53:54 l28 kernel: [521052.389351] task: 88081a3a6720 ti: 
8808162de000 task.ti: 8808162de000
Mar 16 04:53:54 l28 kernel: [521052.389566] RIP: 0010:[]  
[] __kmalloc+0x69/0x100
Mar 16 04:53:54 l28 kernel: [521052.389782] RSP: 0018:8808162dfd18  EFLAGS: 
00010286
Mar 16 04:53:54 l28 kernel: [521052.389899] RAX:  RBX: 
880819a51800 RCX: 03b305d3
Mar 16 04:53:54 l28 kernel: [521052.390112] RDX: 03b305d2 RSI: 
 RDI: 00013500
Mar 16 04:53:54 l28 kernel: [521052.390309] RBP: 8808162dfd38 R08: 
88103fd13500 R09: a00e7072
Mar 16 04:53:54 l28 kernel: [521052.390503] R10: 0010 R11: 
0030 R12: 88081f803a00
Mar 16 04:53:54 l28 kernel: [521052.390694] R13: 40008021 R14: 
80d0 R15: 8808162dfdd0
Mar 16 

Re: kernel OOPS in MM(?)

[Evgenii Lepikhin]

Hello,

On 2016-03-10 12:31, Evgenii Lepikhin wrote:

> We need help to understand the source of the problem and may be to create a 
> bugreport. Here is crash report:
>
> Mar 10 04:03:51 l28 kernel: [2075560.434445] BUG: unable to handle kernel 
> paging request at 40008021
> Mar 10 04:03:51 l28 kernel: [2075560.434669] IP: [] 
> __kmalloc+0x69/0x100
> Mar 10 04:03:51 l28 kernel: [2075560.434800] PGD b7e462067 PUD 0 
> Mar 10 04:03:51 l28 kernel: [2075560.434913] Oops:  [#1] SMP 
> Mar 10 04:03:51 l28 kernel: [2075560.435044] Modules linked in:
> tcm_loop iscsi_target_mod target_core_pscsi target_core_file
> target_core_iblock target_core_mod ipt_NETFLOW(O) configfs iscsi_tcp
> libis
> csi_tcp libiscsi scsi_transport_iscsi fuse [last unloaded: ipfw_mod]
> Mar 10 04:03:51 l28 kernel: [2075560.435539] CPU: 4 PID: 27141 Comm: rm 
> Tainted: G   O 3.12.51-jl-2015-12-25 #1
> Mar 10 04:03:51 l28 kernel: [2075560.435734] Hardware name: Intel Corporation 
> S2600IP ../S2600IP, BIOS SE5C600.86B.01.08.0003.022620131521 
> 02/26/2013
> Mar 10 04:03:51 l28 kernel: [2075560.435939] task: 880e622ccba0 ti: 
> 880eeb008000 task.ti: 880eeb008000
> Mar 10 04:03:51 l28 kernel: [2075560.436131] RIP: 0010:[]  
> [] __kmalloc+0x69/0x100
> Mar 10 04:03:51 l28 kernel: [2075560.436333] RSP: 0018:880eeb009b38  
> EFLAGS: 00010282
> Mar 10 04:03:51 l28 kernel: [2075560.436439] RAX:  RBX: 
>  RCX: a8a73dc2
> Mar 10 04:03:51 l28 kernel: [2075560.436632] RDX: a8a73dc1 RSI: 
>  RDI: 00013500
> Mar 10 04:03:51 l28 kernel: [2075560.438248] RBP: 880eeb009b58 R08: 
> 88103fc13500 R09: 811a0267
> Mar 10 04:03:51 l28 kernel: [2075560.438446] R10: 880eeb009d84 R11: 
>  R12: 88081f803a00
> Mar 10 04:03:51 l28 kernel: [2075560.438656] R13: 40008021 R14: 
> 0250 R15: 880250e833b0
> Mar 10 04:03:51 l28 kernel: [2075560.438851] FS:  7fe2316dd700() 
> GS:88103fc0() knlGS:
> Mar 10 04:03:51 l28 kernel: [2075560.439045] CS:  0010 DS:  ES:  CR0: 
> 80050033
> Mar 10 04:03:51 l28 kernel: [2075560.439152] CR2: 40008021 CR3: 
> 000a20736000 CR4: 000407e0
> Mar 10 04:03:51 l28 kernel: [2075560.439343] Stack:
> Mar 10 04:03:51 l28 kernel: [2075560.439439]   
> 0250 0060 
> Mar 10 04:03:51 l28 kernel: [2075560.439663]  880eeb009b88 
> 811a0267 881015fb7fe0 0060
> Mar 10 04:03:51 l28 kernel: [2075560.439898]  880250e83490 
>  880eeb009ba8 811a02f8
> Mar 10 04:03:51 l28 kernel: [2075560.440153] Call Trace:
> Mar 10 04:03:51 l28 kernel: [2075560.440257]  [] 
> kmem_alloc+0x67/0xe0
> Mar 10 04:03:51 l28 kernel: [2075560.440365]  [] 
> kmem_zalloc+0x18/0x40
> Mar 10 04:03:51 l28 kernel: [2075560.440473]  [] 
> xfs_log_commit_cil+0x373/0x4c0
> Mar 10 04:03:51 l28 kernel: [2075560.440585]  [] ? 
> xfs_bmap_search_multi_extents+0xe0/0x110
> Mar 10 04:03:51 l28 kernel: [2075560.440783]  [] 
> xfs_trans_commit+0x6c/0x250
> Mar 10 04:03:51 l28 kernel: [2075560.440899]  [] 
> xfs_bmap_finish+0xb7/0x1a0

Another issue on the same server, same instruction pointer:

Mar 16 04:53:54 l28 kernel: [521052.387878] BUG: unable to handle kernel paging 
request at 40008021
Mar 16 04:53:54 l28 kernel: [521052.388022] IP: [] 
__kmalloc+0x69/0x100
Mar 16 04:53:54 l28 kernel: [521052.388171] PGD 0 
Mar 16 04:53:54 l28 kernel: [521052.388289] Oops:  [#1] SMP 
Mar 16 04:53:54 l28 kernel: [521052.388410] Modules linked in: tcm_loop 
iscsi_target_mod target_core_pscsi target_core_file target_core_iblock 
target_core_mod ipt_NETFLOW(O) configfs iscsi_tcp libis
csi_tcp libiscsi scsi_transport_iscsi fuse
Mar 16 04:53:54 l28 kernel: [521052.388913] CPU: 6 PID: 5947 Comm: iscsi_trx 
Tainted: G   O 3.12.51-jl-2015-12-25 #1
Mar 16 04:53:54 l28 kernel: [521052.389125] Hardware name: Intel Corporation 
S2600IP ../S2600IP, BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013
Mar 16 04:53:54 l28 kernel: [521052.389351] task: 88081a3a6720 ti: 
8808162de000 task.ti: 8808162de000
Mar 16 04:53:54 l28 kernel: [521052.389566] RIP: 0010:[]  
[] __kmalloc+0x69/0x100
Mar 16 04:53:54 l28 kernel: [521052.389782] RSP: 0018:8808162dfd18  EFLAGS: 
00010286
Mar 16 04:53:54 l28 kernel: [521052.389899] RAX:  RBX: 
880819a51800 RCX: 03b305d3
Mar 16 04:53:54 l28 kernel: [521052.390112] RDX: 03b305d2 RSI: 
 RDI: 00013500
Mar 16 04:53:54 l28 kernel: [521052.390309] RBP: 8808162dfd38 R08: 
88103fd13500 R09: a00e7072
Mar 16 04:53:54 l28 kernel: [521052.390503] R10: 0010 R11: 
0030 R12: 88081f803a00
Mar 16 04:53:54 l28 kernel: [521052.390694] R13: 40008021 R14: 
80d0 R15: 8808162dfdd0
Mar 16 

Re: [PATCH V2 2/3] vfio, platform: make reset driver a requirement

[Eric Auger]

Hi Sinan,
On 03/13/2016 06:25 PM, Sinan Kaya wrote:
> On 3/11/2016 11:54 AM, Sinan Kaya wrote:
>> The code was allowing platform devices to be used without a supporting VFIO
>> reset driver. The hardware can be left in some inconsistent state after a
>> guest machine abort.
>>
>> The reset driver will put the hardware back to safe state and disable
>> interrupts before returning the control back to the host machine.
>>
>> Signed-off-by: Sinan Kaya 
>> ---
>>  drivers/vfio/platform/vfio_platform_common.c | 16 +---
>>  1 file changed, 9 insertions(+), 7 deletions(-)
>>
> I was looking at the code. It looks like this is going to break VFIO AMBA. The
> common implementation is shared with AMBA and platform devices.
> 
> I couldn't see a reset function for AMBA devices.
> 
> Is there anyway to write reset function for it? I have no experience with 
> AMBA devices.
To my knowledge only the PL330 DMA controller (drivers/dma/pl330.c) was
passthrough'ed at some point, rather for development purpose than
production purpose. This was done by Virtual Open Systems (ask Baptiste
for more details). But I don't think this is really used.
> 
> Would you include a reset needed flag and just not require it for AMBA? 
> (I honestly don't like this idea)
> 
I think the requirement also makes sense for AMBA.

Maybe an option would be to add a module parameter that would allow to
use the vfio platform/amba driver without reset module (with explicit
opt-in from the user). Maybe this can be done later on.

FYI I will not have access to my mailbox until the end of the week.

Best Regards

Eric

Re: [PATCH V2 2/3] vfio, platform: make reset driver a requirement

[Eric Auger]

Hi Sinan,
On 03/13/2016 06:25 PM, Sinan Kaya wrote:
> On 3/11/2016 11:54 AM, Sinan Kaya wrote:
>> The code was allowing platform devices to be used without a supporting VFIO
>> reset driver. The hardware can be left in some inconsistent state after a
>> guest machine abort.
>>
>> The reset driver will put the hardware back to safe state and disable
>> interrupts before returning the control back to the host machine.
>>
>> Signed-off-by: Sinan Kaya 
>> ---
>>  drivers/vfio/platform/vfio_platform_common.c | 16 +---
>>  1 file changed, 9 insertions(+), 7 deletions(-)
>>
> I was looking at the code. It looks like this is going to break VFIO AMBA. The
> common implementation is shared with AMBA and platform devices.
> 
> I couldn't see a reset function for AMBA devices.
> 
> Is there anyway to write reset function for it? I have no experience with 
> AMBA devices.
To my knowledge only the PL330 DMA controller (drivers/dma/pl330.c) was
passthrough'ed at some point, rather for development purpose than
production purpose. This was done by Virtual Open Systems (ask Baptiste
for more details). But I don't think this is really used.
> 
> Would you include a reset needed flag and just not require it for AMBA? 
> (I honestly don't like this idea)
> 
I think the requirement also makes sense for AMBA.

Maybe an option would be to add a module parameter that would allow to
use the vfio platform/amba driver without reset module (with explicit
opt-in from the user). Maybe this can be done later on.

FYI I will not have access to my mailbox until the end of the week.

Best Regards

Eric

Re: [WTF] utterly tasteless ABI in hfi1 (around ->write()/->write_iter())

[Linus Torvalds]

On Tue, Mar 15, 2016 at 9:17 PM, Al Viro  wrote:
>
> Take a look at drivers/staging/rdma/hfi1/file_ops.c in -next and
> compare hfi1_write_iter() with hfi1_file_write().  Folks, this ABI is too
> ugly to live, let alone to be allowed breeding.
>
> It's also brittle as hell - trivial massage around fs/read_write.c
> and fs/aio.c is quite capable of breaking that shit.  Arguably, 
> IOCB_CMD_PWRITE
> and IOCB_CMD_PWRITEV both triggering your writev() semantics is an example of
> just such breakage.  Sigh...

We could just decide that if a file descriptor has both ->write and
->write_iter entities, we always pick ->write_iter in the vfs layer.

That way it's always consistent.

Simple ordering change in __vfs_write()..

We can switch is back later, but make sure it hits a release or two.
Or at least a few rc's, to flush out any problems.

Anybody who thinks that they can have different semantics for write()
and writev() is just completely broken.

  Linus

Re: [WTF] utterly tasteless ABI in hfi1 (around ->write()/->write_iter())

[Linus Torvalds]

On Tue, Mar 15, 2016 at 9:17 PM, Al Viro  wrote:
>
> Take a look at drivers/staging/rdma/hfi1/file_ops.c in -next and
> compare hfi1_write_iter() with hfi1_file_write().  Folks, this ABI is too
> ugly to live, let alone to be allowed breeding.
>
> It's also brittle as hell - trivial massage around fs/read_write.c
> and fs/aio.c is quite capable of breaking that shit.  Arguably, 
> IOCB_CMD_PWRITE
> and IOCB_CMD_PWRITEV both triggering your writev() semantics is an example of
> just such breakage.  Sigh...

We could just decide that if a file descriptor has both ->write and
->write_iter entities, we always pick ->write_iter in the vfs layer.

That way it's always consistent.

Simple ordering change in __vfs_write()..

We can switch is back later, but make sure it hits a release or two.
Or at least a few rc's, to flush out any problems.

Anybody who thinks that they can have different semantics for write()
and writev() is just completely broken.

  Linus

[WTF] utterly tasteless ABI in hfi1 (around ->write()/->write_iter())

[Al Viro]

Folks, we'd discussed that kind of crap already; why, in name of
everything unholy, is that kind of garbage brought back in a new driver?

Having both ->write() and ->write_iter() *AND* having entirely
unrelated interpretation of user input on those two on the same device
is bogus, with the capital Stop That Shit Right Now.

As it is, write(fd, p, len) and writev(fd, &(struct iovec){p,len}, 1)
are interpreted in absolutely unrelated ways.  As in, entirely different
set of commands.  Moreover, aio IOCB_CMD_PWRITE matches writev(), not write().

What's going on?  Sure, ipathfs is a precious snowflake with the same
kind of braindamage.  Back when it had been brought to your attention
(along with the fact that this piece of idiocy happens to be a file on
filesystem of your own, under your full control and no need whatsofuckingever
to multiplex completely unrelated sets of commands on the same file with
"was it write(2) or writev(2)?" used as a selector) the answer had been
basically "it doesn't have to make sense, it's Special".  Now it turns out
that it has grown an equally special sibling.  With the idiocy directly
exposed as userland ABI.  Could we please fix that thing before it's cast in
stone?

Take a look at drivers/staging/rdma/hfi1/file_ops.c in -next and
compare hfi1_write_iter() with hfi1_file_write().  Folks, this ABI is too
ugly to live, let alone to be allowed breeding.

It's also brittle as hell - trivial massage around fs/read_write.c
and fs/aio.c is quite capable of breaking that shit.  Arguably, IOCB_CMD_PWRITE
and IOCB_CMD_PWRITEV both triggering your writev() semantics is an example of
just such breakage.  Sigh...

[WTF] utterly tasteless ABI in hfi1 (around ->write()/->write_iter())

[Al Viro]

Folks, we'd discussed that kind of crap already; why, in name of
everything unholy, is that kind of garbage brought back in a new driver?

Having both ->write() and ->write_iter() *AND* having entirely
unrelated interpretation of user input on those two on the same device
is bogus, with the capital Stop That Shit Right Now.

As it is, write(fd, p, len) and writev(fd, &(struct iovec){p,len}, 1)
are interpreted in absolutely unrelated ways.  As in, entirely different
set of commands.  Moreover, aio IOCB_CMD_PWRITE matches writev(), not write().

What's going on?  Sure, ipathfs is a precious snowflake with the same
kind of braindamage.  Back when it had been brought to your attention
(along with the fact that this piece of idiocy happens to be a file on
filesystem of your own, under your full control and no need whatsofuckingever
to multiplex completely unrelated sets of commands on the same file with
"was it write(2) or writev(2)?" used as a selector) the answer had been
basically "it doesn't have to make sense, it's Special".  Now it turns out
that it has grown an equally special sibling.  With the idiocy directly
exposed as userland ABI.  Could we please fix that thing before it's cast in
stone?

Take a look at drivers/staging/rdma/hfi1/file_ops.c in -next and
compare hfi1_write_iter() with hfi1_file_write().  Folks, this ABI is too
ugly to live, let alone to be allowed breeding.

It's also brittle as hell - trivial massage around fs/read_write.c
and fs/aio.c is quite capable of breaking that shit.  Arguably, IOCB_CMD_PWRITE
and IOCB_CMD_PWRITEV both triggering your writev() semantics is an example of
just such breakage.  Sigh...

Re: [PATCH 3.10 00/18] 3.10.101-stable review

[Greg Kroah-Hartman]

On Tue, Mar 15, 2016 at 08:08:09PM -0700, Guenter Roeck wrote:
> On 03/14/2016 10:52 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.10.101 release.
> >There are 18 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> 
> Hi Greg,
> 
> The projected EOL of 3.10 is still listed as "End of 2015" on kernel.org.
> Obviously that is not longer correct. Is there a new projected EOL ?

Sometime later than that :)

A few of us are talking about this right now, give us a few weeks to
come up with something solid.

thanks,

greg k-h

Re: [PATCH 3.10 00/18] 3.10.101-stable review

[Greg Kroah-Hartman]

On Tue, Mar 15, 2016 at 08:08:09PM -0700, Guenter Roeck wrote:
> On 03/14/2016 10:52 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.10.101 release.
> >There are 18 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> 
> Hi Greg,
> 
> The projected EOL of 3.10 is still listed as "End of 2015" on kernel.org.
> Obviously that is not longer correct. Is there a new projected EOL ?

Sometime later than that :)

A few of us are talking about this right now, give us a few weeks to
come up with something solid.

thanks,

greg k-h

Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util

[Steve Muckle]

Hi Mike,

On 03/15/2016 03:06 PM, Michael Turquette wrote:
>>> > >  void cpufreq_set_freq_update_hook(int cpu, struct freq_update_hook 
>>> > > *hook,
>>> > > + void (*func)(struct freq_update_hook *hook,
>>> > > +  enum sched_class_util sched_class,
>>> > > +  u64 time, unsigned long util,
>>> > > +  unsigned long max));
>> > 
>> > Have you looked at the asm that generated? At some point you'll start
>> > spilling on the stack and it'll be a god awful mess.
>> > 
> Is your complaint about the enum that I added to the existing function
> signature, or do you not like the original function signature[0] from
> Rafael's patch, sans enum?

The ARM procedure call standard has the first four arguments in
registers so the addition of the enum above will start using the stack.

Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util

[Steve Muckle]

Hi Mike,

On 03/15/2016 03:06 PM, Michael Turquette wrote:
>>> > >  void cpufreq_set_freq_update_hook(int cpu, struct freq_update_hook 
>>> > > *hook,
>>> > > + void (*func)(struct freq_update_hook *hook,
>>> > > +  enum sched_class_util sched_class,
>>> > > +  u64 time, unsigned long util,
>>> > > +  unsigned long max));
>> > 
>> > Have you looked at the asm that generated? At some point you'll start
>> > spilling on the stack and it'll be a god awful mess.
>> > 
> Is your complaint about the enum that I added to the existing function
> signature, or do you not like the original function signature[0] from
> Rafael's patch, sans enum?

The ARM procedure call standard has the first four arguments in
registers so the addition of the enum above will start using the stack.

Re: [PATCH 1/1] KVM: don't allow irq_fpu_usable when the VCPU's XCR0 is loaded

[Xiao Guangrong]

On 03/16/2016 03:32 AM, Paolo Bonzini wrote:



On 15/03/2016 19:27, Andy Lutomirski wrote:

On Mon, Mar 14, 2016 at 6:17 AM, Paolo Bonzini  wrote:



On 11/03/2016 22:33, David Matlack wrote:

Is this better than just always keeping the host's XCR0 loaded outside
if the KVM interrupts-disabled region?


Probably not. AFAICT KVM does not rely on it being loaded outside that
region. xsetbv isn't insanely expensive, is it? Maybe to minimize the
time spent with interrupts disabled it was put outside.

I do like that your solution would be contained to KVM.


I agree with Andy.  We do want a fix for recent kernels because of the
!eager_fpu case that Guangrong mentioned.


Relying on interrupt is not easy as XCR0 can not be automatically saved/loaded
by VMCS... Once interrupt happens, it will use guest's XCR0 anyway.

Re: [PATCH 1/1] KVM: don't allow irq_fpu_usable when the VCPU's XCR0 is loaded

[Xiao Guangrong]

On 03/16/2016 03:32 AM, Paolo Bonzini wrote:



On 15/03/2016 19:27, Andy Lutomirski wrote:

On Mon, Mar 14, 2016 at 6:17 AM, Paolo Bonzini  wrote:



On 11/03/2016 22:33, David Matlack wrote:

Is this better than just always keeping the host's XCR0 loaded outside
if the KVM interrupts-disabled region?


Probably not. AFAICT KVM does not rely on it being loaded outside that
region. xsetbv isn't insanely expensive, is it? Maybe to minimize the
time spent with interrupts disabled it was put outside.

I do like that your solution would be contained to KVM.


I agree with Andy.  We do want a fix for recent kernels because of the
!eager_fpu case that Guangrong mentioned.


Relying on interrupt is not easy as XCR0 can not be automatically saved/loaded
by VMCS... Once interrupt happens, it will use guest's XCR0 anyway.

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

[Andy Lutomirski]

On Tue, Mar 15, 2016 at 8:43 PM, Xiao Guangrong
 wrote:
>
>
> On 03/16/2016 03:01 AM, David Matlack wrote:
>>
>> On Mon, Mar 14, 2016 at 12:46 AM, Xiao Guangrong
>>  wrote:
>>>
>>>
>>>
>>> On 03/12/2016 04:47 AM, David Matlack wrote:
>>>
 I have not been able to trigger this bug on Linux 4.3, and suspect
 it is due to this commit from Linux 4.2:

 653f52c kvm,x86: load guest FPU context more eagerly

 With this commit, as long as the host is using eagerfpu, the guest's
 fpu is always loaded just before the guest's xcr0 (vcpu->fpu_active
 is always 1 in the following snippet):

 6569 if (vcpu->fpu_active)
 6570 kvm_load_guest_fpu(vcpu);
 6571 kvm_load_guest_xcr0(vcpu);

 When the guest's fpu is loaded, irq_fpu_usable() returns false.
>>>
>>>
>>>
>>> Er, i did not see that commit introduced this change.
>>>

 We've included our workaround for this bug, which applies to Linux 3.11.
 It does not apply cleanly to HEAD since the fpu subsystem was refactored
 in Linux 4.2. While the latest kernel does not look vulnerable, we may
 want to apply a fix to the vulnerable stable kernels.
>>>
>>>
>>>
>>> Is the latest kvm safe if we use !eager fpu?
>>
>>
>> Yes I believe so. When !eagerfpu, interrupted_kernel_fpu_idle()
>> returns "!current->thread.fpu.fpregs_active && (read_cr0() &
>> X86_CR0_TS)". This should ensure the interrupt handler never does
>> XSAVE/XRSTOR with the guest's xcr0.
>
>
>
> interrupted_kernel_fpu_idle() returns true if KVM-based hypervisor (e.g.
> QEMU)
> is not using fpu.　That can not stop handler using fpu.

Why is it safe to rely on interrupted_kernel_fpu_idle?  That function
is for interrupts, but is there any reason that KVM can't be preempted
(or explicitly schedule) with XCR0 having some funny value?

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

[Andy Lutomirski]

On Tue, Mar 15, 2016 at 8:43 PM, Xiao Guangrong
 wrote:
>
>
> On 03/16/2016 03:01 AM, David Matlack wrote:
>>
>> On Mon, Mar 14, 2016 at 12:46 AM, Xiao Guangrong
>>  wrote:
>>>
>>>
>>>
>>> On 03/12/2016 04:47 AM, David Matlack wrote:
>>>
 I have not been able to trigger this bug on Linux 4.3, and suspect
 it is due to this commit from Linux 4.2:

 653f52c kvm,x86: load guest FPU context more eagerly

 With this commit, as long as the host is using eagerfpu, the guest's
 fpu is always loaded just before the guest's xcr0 (vcpu->fpu_active
 is always 1 in the following snippet):

 6569 if (vcpu->fpu_active)
 6570 kvm_load_guest_fpu(vcpu);
 6571 kvm_load_guest_xcr0(vcpu);

 When the guest's fpu is loaded, irq_fpu_usable() returns false.
>>>
>>>
>>>
>>> Er, i did not see that commit introduced this change.
>>>

 We've included our workaround for this bug, which applies to Linux 3.11.
 It does not apply cleanly to HEAD since the fpu subsystem was refactored
 in Linux 4.2. While the latest kernel does not look vulnerable, we may
 want to apply a fix to the vulnerable stable kernels.
>>>
>>>
>>>
>>> Is the latest kvm safe if we use !eager fpu?
>>
>>
>> Yes I believe so. When !eagerfpu, interrupted_kernel_fpu_idle()
>> returns "!current->thread.fpu.fpregs_active && (read_cr0() &
>> X86_CR0_TS)". This should ensure the interrupt handler never does
>> XSAVE/XRSTOR with the guest's xcr0.
>
>
>
> interrupted_kernel_fpu_idle() returns true if KVM-based hypervisor (e.g.
> QEMU)
> is not using fpu.　That can not stop handler using fpu.

Why is it safe to rely on interrupted_kernel_fpu_idle?  That function
is for interrupts, but is there any reason that KVM can't be preempted
(or explicitly schedule) with XCR0 having some funny value?

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH V7 03/12] thermal: tegra: get rid of PDIV/HOTSPOT hack

[Wei Ni]

On 2016年03月16日 03:56, Eduardo Valentin wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Mar 15, 2016 at 02:21:53PM +0800, Wei Ni wrote:
>>
>>
>> On 2016年03月15日 04:05, Eduardo Valentin wrote:
 Old Signed by an unknown key
>>>
>>> On Fri, Mar 11, 2016 at 11:09:14AM +0800, Wei Ni wrote:
 Get rid of T124-specific PDIV/HOTSPOT hack.
 tegra-soctherm.c contained a hack to set the SENSOR_PDIV and
 SENSOR_HOTSPOT_OFFSET registers - it just did two writes of
 T124-specific opaque values.  Convert these into a form that can be
 substituted on a per-chip basis, and into structure fields that have
 at least some independent meaning.

 Signed-off-by: Wei Ni 
 ---
  drivers/thermal/tegra/tegra-soctherm.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

 diff --git a/drivers/thermal/tegra/tegra-soctherm.c 
 b/drivers/thermal/tegra/tegra-soctherm.c
 index b3ec0faa2bee..b4b791ebfbb6 100644
 --- a/drivers/thermal/tegra/tegra-soctherm.c
 +++ b/drivers/thermal/tegra/tegra-soctherm.c
 @@ -48,14 +48,12 @@
  #define SENSOR_CONFIG2_THERMB_SHIFT   0
  
  #define SENSOR_PDIV   0x1c0
 -#define SENSOR_PDIV_T124  0x
  #define SENSOR_PDIV_CPU_MASK  (0xf << 12)
  #define SENSOR_PDIV_GPU_MASK  (0xf << 8)
  #define SENSOR_PDIV_MEM_MASK  (0xf << 4)
  #define SENSOR_PDIV_PLLX_MASK (0xf << 0)
  
  #define SENSOR_HOTSPOT_OFF0x1c4
 -#define SENSOR_HOTSPOT_OFF_T124   0x00060600
  #define SENSOR_HOTSPOT_CPU_MASK   (0xff << 16)
  #define SENSOR_HOTSPOT_GPU_MASK   (0xff << 8)
  #define SENSOR_HOTSPOT_MEM_MASK   (0xff << 0)
 @@ -436,6 +434,7 @@ static int tegra_soctherm_probe(struct platform_device 
 *pdev)
struct resource *res;
unsigned int i;
int err;
 +  u32 pdiv, hotspot;
  
const struct tegra_tsensor *tsensors = t124_tsensors;
const struct tegra_tsensor_group **ttgs = tegra124_tsensor_groups;
 @@ -493,8 +492,19 @@ static int tegra_soctherm_probe(struct 
 platform_device *pdev)
goto disable_clocks;
}
  
 -  writel(SENSOR_PDIV_T124, tegra->regs + SENSOR_PDIV);
 -  writel(SENSOR_HOTSPOT_OFF_T124, tegra->regs + SENSOR_HOTSPOT_OFF);
 +  /* Program pdiv and hotspot offsets per THERM */
 +  pdiv = readl(tegra->regs + SENSOR_PDIV);
 +  hotspot = readl(tegra->regs + SENSOR_HOTSPOT_OFF);
 +  for (i = 0; i < TEGRA124_SOCTHERM_SENSOR_NUM; ++i) {
 +  pdiv = REG_SET_MASK(pdiv, ttgs[i]->pdiv_mask,
 +  ttgs[i]->pdiv);
 +  if (ttgs[i]->id != TEGRA124_SOCTHERM_SENSOR_PLLX)
 +  hotspot =  REG_SET_MASK(hotspot,
 +  ttgs[i]->pllx_hotspot_mask,
 +  ttgs[i]->pllx_hotspot_diff);
 +  }
 +  writel(pdiv, tegra->regs + SENSOR_PDIV);
 +  writel(hotspot, tegra->regs + SENSOR_HOTSPOT_OFF);
>>>
>>> Is the above logic the same for all supported chips? e.g. do we always
>>> skip pllx for hotspot configuration?
>>
>> Yes, this logic support Tegra124, Tegra210, and Tegra132 which I will send 
>> out
>> in next series.
> 
> 
> Ok. Could you please add a comment then explaining why pllx is not
> needed for the hotspot configuration?

This is the hotspot offset from PLLX, so we doesn't need to configure for PLLX,
the Tegra DRM introduced it.
I will add comment for it.

> 
>>
>>>
>>>
  
/* Initialize thermctl sensors */
  
 -- 
 1.9.1

>>>
>>> * Unknown Key
>>> * 0x7DA4E256
>>>
> 
> * Unknown Key
> * 0x7DA4E256
> 

Re: [PATCH V7 03/12] thermal: tegra: get rid of PDIV/HOTSPOT hack

[Wei Ni]

On 2016年03月16日 03:56, Eduardo Valentin wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Mar 15, 2016 at 02:21:53PM +0800, Wei Ni wrote:
>>
>>
>> On 2016年03月15日 04:05, Eduardo Valentin wrote:
 Old Signed by an unknown key
>>>
>>> On Fri, Mar 11, 2016 at 11:09:14AM +0800, Wei Ni wrote:
 Get rid of T124-specific PDIV/HOTSPOT hack.
 tegra-soctherm.c contained a hack to set the SENSOR_PDIV and
 SENSOR_HOTSPOT_OFFSET registers - it just did two writes of
 T124-specific opaque values.  Convert these into a form that can be
 substituted on a per-chip basis, and into structure fields that have
 at least some independent meaning.

 Signed-off-by: Wei Ni 
 ---
  drivers/thermal/tegra/tegra-soctherm.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

 diff --git a/drivers/thermal/tegra/tegra-soctherm.c 
 b/drivers/thermal/tegra/tegra-soctherm.c
 index b3ec0faa2bee..b4b791ebfbb6 100644
 --- a/drivers/thermal/tegra/tegra-soctherm.c
 +++ b/drivers/thermal/tegra/tegra-soctherm.c
 @@ -48,14 +48,12 @@
  #define SENSOR_CONFIG2_THERMB_SHIFT   0
  
  #define SENSOR_PDIV   0x1c0
 -#define SENSOR_PDIV_T124  0x
  #define SENSOR_PDIV_CPU_MASK  (0xf << 12)
  #define SENSOR_PDIV_GPU_MASK  (0xf << 8)
  #define SENSOR_PDIV_MEM_MASK  (0xf << 4)
  #define SENSOR_PDIV_PLLX_MASK (0xf << 0)
  
  #define SENSOR_HOTSPOT_OFF0x1c4
 -#define SENSOR_HOTSPOT_OFF_T124   0x00060600
  #define SENSOR_HOTSPOT_CPU_MASK   (0xff << 16)
  #define SENSOR_HOTSPOT_GPU_MASK   (0xff << 8)
  #define SENSOR_HOTSPOT_MEM_MASK   (0xff << 0)
 @@ -436,6 +434,7 @@ static int tegra_soctherm_probe(struct platform_device 
 *pdev)
struct resource *res;
unsigned int i;
int err;
 +  u32 pdiv, hotspot;
  
const struct tegra_tsensor *tsensors = t124_tsensors;
const struct tegra_tsensor_group **ttgs = tegra124_tsensor_groups;
 @@ -493,8 +492,19 @@ static int tegra_soctherm_probe(struct 
 platform_device *pdev)
goto disable_clocks;
}
  
 -  writel(SENSOR_PDIV_T124, tegra->regs + SENSOR_PDIV);
 -  writel(SENSOR_HOTSPOT_OFF_T124, tegra->regs + SENSOR_HOTSPOT_OFF);
 +  /* Program pdiv and hotspot offsets per THERM */
 +  pdiv = readl(tegra->regs + SENSOR_PDIV);
 +  hotspot = readl(tegra->regs + SENSOR_HOTSPOT_OFF);
 +  for (i = 0; i < TEGRA124_SOCTHERM_SENSOR_NUM; ++i) {
 +  pdiv = REG_SET_MASK(pdiv, ttgs[i]->pdiv_mask,
 +  ttgs[i]->pdiv);
 +  if (ttgs[i]->id != TEGRA124_SOCTHERM_SENSOR_PLLX)
 +  hotspot =  REG_SET_MASK(hotspot,
 +  ttgs[i]->pllx_hotspot_mask,
 +  ttgs[i]->pllx_hotspot_diff);
 +  }
 +  writel(pdiv, tegra->regs + SENSOR_PDIV);
 +  writel(hotspot, tegra->regs + SENSOR_HOTSPOT_OFF);
>>>
>>> Is the above logic the same for all supported chips? e.g. do we always
>>> skip pllx for hotspot configuration?
>>
>> Yes, this logic support Tegra124, Tegra210, and Tegra132 which I will send 
>> out
>> in next series.
> 
> 
> Ok. Could you please add a comment then explaining why pllx is not
> needed for the hotspot configuration?

This is the hotspot offset from PLLX, so we doesn't need to configure for PLLX,
the Tegra DRM introduced it.
I will add comment for it.

> 
>>
>>>
>>>
  
/* Initialize thermctl sensors */
  
 -- 
 1.9.1

>>>
>>> * Unknown Key
>>> * 0x7DA4E256
>>>
> 
> * Unknown Key
> * 0x7DA4E256
> 

Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources

[David Lechner]

On 03/15/2016 05:45 PM, Sergei Shtylyov wrote:


No, this register is shared b/w MUSB and OHCI. The proper thing to
do is to write the PHY driver and let it control this shared register.



OK. I've started working on this. I am looking at using struct usb_phy, 
however, enum usb_phy_type only has USB_PHY_TYPE_UNDEFINED, 
USB_PHY_TYPE_USB2, and USB_PHY_TYPE_USB3. Would it be acceptable to use 
USB_PHY_TYPE_UNDEFINED for the ohci since it is USB 1.1? Or perhaps I 
should use the more generic struct phy for that one?

Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources

[David Lechner]

On 03/15/2016 05:45 PM, Sergei Shtylyov wrote:


No, this register is shared b/w MUSB and OHCI. The proper thing to
do is to write the PHY driver and let it control this shared register.



OK. I've started working on this. I am looking at using struct usb_phy, 
however, enum usb_phy_type only has USB_PHY_TYPE_UNDEFINED, 
USB_PHY_TYPE_USB2, and USB_PHY_TYPE_USB3. Would it be acceptable to use 
USB_PHY_TYPE_UNDEFINED for the ohci since it is USB 1.1? Or perhaps I 
should use the more generic struct phy for that one?

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

[Xiao Guangrong]

On 03/16/2016 03:01 AM, David Matlack wrote:

On Mon, Mar 14, 2016 at 12:46 AM, Xiao Guangrong
 wrote:



On 03/12/2016 04:47 AM, David Matlack wrote:


I have not been able to trigger this bug on Linux 4.3, and suspect
it is due to this commit from Linux 4.2:

653f52c kvm,x86: load guest FPU context more eagerly

With this commit, as long as the host is using eagerfpu, the guest's
fpu is always loaded just before the guest's xcr0 (vcpu->fpu_active
is always 1 in the following snippet):

6569 if (vcpu->fpu_active)
6570 kvm_load_guest_fpu(vcpu);
6571 kvm_load_guest_xcr0(vcpu);

When the guest's fpu is loaded, irq_fpu_usable() returns false.



Er, i did not see that commit introduced this change.



We've included our workaround for this bug, which applies to Linux 3.11.
It does not apply cleanly to HEAD since the fpu subsystem was refactored
in Linux 4.2. While the latest kernel does not look vulnerable, we may
want to apply a fix to the vulnerable stable kernels.



Is the latest kvm safe if we use !eager fpu?


Yes I believe so. When !eagerfpu, interrupted_kernel_fpu_idle()
returns "!current->thread.fpu.fpregs_active && (read_cr0() &
X86_CR0_TS)". This should ensure the interrupt handler never does
XSAVE/XRSTOR with the guest's xcr0.



interrupted_kernel_fpu_idle() returns true if KVM-based hypervisor (e.g. QEMU)
is not using fpu.　That can not stop handler using fpu.

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

[Xiao Guangrong]

On 03/16/2016 03:01 AM, David Matlack wrote:

On Mon, Mar 14, 2016 at 12:46 AM, Xiao Guangrong
 wrote:



On 03/12/2016 04:47 AM, David Matlack wrote:


I have not been able to trigger this bug on Linux 4.3, and suspect
it is due to this commit from Linux 4.2:

653f52c kvm,x86: load guest FPU context more eagerly

With this commit, as long as the host is using eagerfpu, the guest's
fpu is always loaded just before the guest's xcr0 (vcpu->fpu_active
is always 1 in the following snippet):

6569 if (vcpu->fpu_active)
6570 kvm_load_guest_fpu(vcpu);
6571 kvm_load_guest_xcr0(vcpu);

When the guest's fpu is loaded, irq_fpu_usable() returns false.



Er, i did not see that commit introduced this change.



We've included our workaround for this bug, which applies to Linux 3.11.
It does not apply cleanly to HEAD since the fpu subsystem was refactored
in Linux 4.2. While the latest kernel does not look vulnerable, we may
want to apply a fix to the vulnerable stable kernels.



Is the latest kvm safe if we use !eager fpu?


Yes I believe so. When !eagerfpu, interrupted_kernel_fpu_idle()
returns "!current->thread.fpu.fpregs_active && (read_cr0() &
X86_CR0_TS)". This should ensure the interrupt handler never does
XSAVE/XRSTOR with the guest's xcr0.



interrupted_kernel_fpu_idle() returns true if KVM-based hypervisor (e.g. QEMU)
is not using fpu.　That can not stop handler using fpu.

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

[Steve French]

On Tue, Mar 15, 2016 at 2:14 AM, Christoph Hellwig  wrote:
> On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote:
>> A loosely related question is what can be done for tools around existing
>> interfaces for ACLs.  I recently found out NTFS-3g has this xattr:
>>
>> static const char nf_ns_xattr_ntfs_acl[] = "system.ntfs_acl";
>>
>> which allows you to query system.ntfs_acl xattr to get their full ACL
>
> Bah.  Filesystems really have no business exposing random system xattrs,
> and we really need to add a filter to fs/xattr.c to not expose
> arbitrary attrs ouside the user.* prefix.

Hopefully we don't consider them random system xattrs, it is
plausible that ntfs uses these for user space tools that I don't
have.

At least for cifs.ko a similar subset (querying ACLs, streams and
reparse info e.g.)
to the ntfs set would be very helpful.  For example,
Being able to query the actual ACL over the wire, is important for backup
and for debug, the only question is whether to do it via an xattr (possibly
being able to have some synergy with existing ntfs-3g tools) or an ioctl
(since adding an NTFS specific syscall for a couple fs doesn't make sense).


For the specific example of the odd ntfs.streams.list xattr, I can see why
they have it.  I would have mixed feelings about having no way to tell
streams and EAs from each other
since NTFS-3g displaying streams as xattrs and also Extended
Attributes (EAs) as xattrs
(and if they didn't have an additional xattr to list streams)
without a way to tell the difference (at least a system xattr to list
the alternate
data streams is useful).   There is useful information in alternate data streams
that backup (and debugging) programs need for some workloads,
for example the origin (where internet explorer downloaded a file from)
and file classification information.

-- 
Thanks,

Steve

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

[Steve French]

On Tue, Mar 15, 2016 at 2:14 AM, Christoph Hellwig  wrote:
> On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote:
>> A loosely related question is what can be done for tools around existing
>> interfaces for ACLs.  I recently found out NTFS-3g has this xattr:
>>
>> static const char nf_ns_xattr_ntfs_acl[] = "system.ntfs_acl";
>>
>> which allows you to query system.ntfs_acl xattr to get their full ACL
>
> Bah.  Filesystems really have no business exposing random system xattrs,
> and we really need to add a filter to fs/xattr.c to not expose
> arbitrary attrs ouside the user.* prefix.

Hopefully we don't consider them random system xattrs, it is
plausible that ntfs uses these for user space tools that I don't
have.

At least for cifs.ko a similar subset (querying ACLs, streams and
reparse info e.g.)
to the ntfs set would be very helpful.  For example,
Being able to query the actual ACL over the wire, is important for backup
and for debug, the only question is whether to do it via an xattr (possibly
being able to have some synergy with existing ntfs-3g tools) or an ioctl
(since adding an NTFS specific syscall for a couple fs doesn't make sense).


For the specific example of the odd ntfs.streams.list xattr, I can see why
they have it.  I would have mixed feelings about having no way to tell
streams and EAs from each other
since NTFS-3g displaying streams as xattrs and also Extended
Attributes (EAs) as xattrs
(and if they didn't have an additional xattr to list streams)
without a way to tell the difference (at least a system xattr to list
the alternate
data streams is useful).   There is useful information in alternate data streams
that backup (and debugging) programs need for some workloads,
for example the origin (where internet explorer downloaded a file from)
and file classification information.

-- 
Thanks,

Steve

[PATCH v2 06/22] ncr5380: Remove PSEUDO_DMA macro

[Finn Thain]

For those wrapper drivers which only implement Programmed IO, have
NCR5380_dma_xfer_len() evaluate to zero. That allows PDMA to be easily
disabled at run-time and so the PSEUDO_DMA macro is no longer needed.

Also remove the spin counters used for debugging pseudo DMA drivers.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c  |   32 +---
 drivers/scsi/NCR5380.h  |4 
 drivers/scsi/arm/cumana_1.c |2 --
 drivers/scsi/arm/oak.c  |3 +--
 drivers/scsi/dmx3191d.c |4 
 drivers/scsi/dtc.c  |7 ---
 drivers/scsi/dtc.h  |2 --
 drivers/scsi/g_NCR5380.c|1 -
 drivers/scsi/g_NCR5380.h|1 -
 drivers/scsi/mac_scsi.c |   10 --
 drivers/scsi/pas16.c|   10 --
 drivers/scsi/pas16.h|2 --
 drivers/scsi/t128.c |4 
 drivers/scsi/t128.h |2 --
 14 files changed, 6 insertions(+), 78 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:09.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:11.0 +1100
@@ -469,34 +469,9 @@ static void prepare_info(struct Scsi_Hos
 #ifdef PARITY
 "PARITY "
 #endif
-#ifdef PSEUDO_DMA
-"PSEUDO_DMA "
-#endif
 "");
 }
 
-#ifdef PSEUDO_DMA
-static int __maybe_unused NCR5380_write_info(struct Scsi_Host *instance,
-   char *buffer, int length)
-{
-   struct NCR5380_hostdata *hostdata = shost_priv(instance);
-
-   hostdata->spin_max_r = 0;
-   hostdata->spin_max_w = 0;
-   return 0;
-}
-
-static int __maybe_unused NCR5380_show_info(struct seq_file *m,
-struct Scsi_Host *instance)
-{
-   struct NCR5380_hostdata *hostdata = shost_priv(instance);
-
-   seq_printf(m, "Highwater I/O busy spin counts: write %d, read %d\n",
-   hostdata->spin_max_w, hostdata->spin_max_r);
-   return 0;
-}
-#endif
-
 /**
  * NCR5380_init - initialise an NCR5380
  * @instance: adapter to configure
@@ -1436,7 +1411,6 @@ timeout:
return -1;
 }
 
-#if defined(PSEUDO_DMA)
 /*
  * Function : int NCR5380_transfer_dma (struct Scsi_Host *instance,
  * unsigned char *phase, int *count, unsigned char **data)
@@ -1592,7 +1566,6 @@ static int NCR5380_transfer_dma(struct S
*phase = NCR5380_read(STATUS_REG) & PHASE_MASK;
return foo;
 }
-#endif /* PSEUDO_DMA */
 
 /*
  * Function : NCR5380_information_transfer (struct Scsi_Host *instance)
@@ -1683,7 +1656,6 @@ static void NCR5380_information_transfer
 * in an unconditional loop.
 */
 
-#if defined(PSEUDO_DMA)
transfersize = 0;
if (!cmd->device->borken)
transfersize = 
NCR5380_dma_xfer_len(instance, cmd, phase);
@@ -1706,9 +1678,7 @@ static void NCR5380_information_transfer
/* XXX - need to source or sink 
data here, as appropriate */
} else
cmd->SCp.this_residual -= 
transfersize - len;
-   } else
-#endif /* PSEUDO_DMA */
-   {
+   } else {
/* Break up transfer into 3 ms chunks,
 * presuming 6 accesses per handshake.
 */
Index: linux/drivers/scsi/NCR5380.h
===
--- linux.orig/drivers/scsi/NCR5380.h   2016-03-16 14:18:09.0 +1100
+++ linux/drivers/scsi/NCR5380.h2016-03-16 14:18:11.0 +1100
@@ -257,10 +257,6 @@ struct NCR5380_hostdata {
 #ifdef SUPPORT_TAGS
struct tag_alloc TagAlloc[8][8];/* 8 targets and 8 LUNs */
 #endif
-#ifdef PSEUDO_DMA
-   unsigned spin_max_r;
-   unsigned spin_max_w;
-#endif
struct workqueue_struct *work_q;
unsigned long accesses_per_ms;  /* chip register accesses per ms */
 };
Index: linux/drivers/scsi/arm/cumana_1.c
===
--- linux.orig/drivers/scsi/arm/cumana_1.c  2016-03-16 14:18:09.0 
+1100
+++ linux/drivers/scsi/arm/cumana_1.c   2016-03-16 14:18:11.0 +1100
@@ -13,8 +13,6 @@
 
 #include 
 
-#define PSEUDO_DMA
-
 #define priv(host) ((struct NCR5380_hostdata 
*)(host)->hostdata)
 #define NCR5380_read(reg)  cumanascsi_read(instance, reg)
 #define NCR5380_write(reg, value)  cumanascsi_write(instance, reg, value)
Index: linux/drivers/scsi/arm/oak.c

[PATCH v2 06/22] ncr5380: Remove PSEUDO_DMA macro

[Finn Thain]

For those wrapper drivers which only implement Programmed IO, have
NCR5380_dma_xfer_len() evaluate to zero. That allows PDMA to be easily
disabled at run-time and so the PSEUDO_DMA macro is no longer needed.

Also remove the spin counters used for debugging pseudo DMA drivers.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c  |   32 +---
 drivers/scsi/NCR5380.h  |4 
 drivers/scsi/arm/cumana_1.c |2 --
 drivers/scsi/arm/oak.c  |3 +--
 drivers/scsi/dmx3191d.c |4 
 drivers/scsi/dtc.c  |7 ---
 drivers/scsi/dtc.h  |2 --
 drivers/scsi/g_NCR5380.c|1 -
 drivers/scsi/g_NCR5380.h|1 -
 drivers/scsi/mac_scsi.c |   10 --
 drivers/scsi/pas16.c|   10 --
 drivers/scsi/pas16.h|2 --
 drivers/scsi/t128.c |4 
 drivers/scsi/t128.h |2 --
 14 files changed, 6 insertions(+), 78 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:09.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:11.0 +1100
@@ -469,34 +469,9 @@ static void prepare_info(struct Scsi_Hos
 #ifdef PARITY
 "PARITY "
 #endif
-#ifdef PSEUDO_DMA
-"PSEUDO_DMA "
-#endif
 "");
 }
 
-#ifdef PSEUDO_DMA
-static int __maybe_unused NCR5380_write_info(struct Scsi_Host *instance,
-   char *buffer, int length)
-{
-   struct NCR5380_hostdata *hostdata = shost_priv(instance);
-
-   hostdata->spin_max_r = 0;
-   hostdata->spin_max_w = 0;
-   return 0;
-}
-
-static int __maybe_unused NCR5380_show_info(struct seq_file *m,
-struct Scsi_Host *instance)
-{
-   struct NCR5380_hostdata *hostdata = shost_priv(instance);
-
-   seq_printf(m, "Highwater I/O busy spin counts: write %d, read %d\n",
-   hostdata->spin_max_w, hostdata->spin_max_r);
-   return 0;
-}
-#endif
-
 /**
  * NCR5380_init - initialise an NCR5380
  * @instance: adapter to configure
@@ -1436,7 +1411,6 @@ timeout:
return -1;
 }
 
-#if defined(PSEUDO_DMA)
 /*
  * Function : int NCR5380_transfer_dma (struct Scsi_Host *instance,
  * unsigned char *phase, int *count, unsigned char **data)
@@ -1592,7 +1566,6 @@ static int NCR5380_transfer_dma(struct S
*phase = NCR5380_read(STATUS_REG) & PHASE_MASK;
return foo;
 }
-#endif /* PSEUDO_DMA */
 
 /*
  * Function : NCR5380_information_transfer (struct Scsi_Host *instance)
@@ -1683,7 +1656,6 @@ static void NCR5380_information_transfer
 * in an unconditional loop.
 */
 
-#if defined(PSEUDO_DMA)
transfersize = 0;
if (!cmd->device->borken)
transfersize = 
NCR5380_dma_xfer_len(instance, cmd, phase);
@@ -1706,9 +1678,7 @@ static void NCR5380_information_transfer
/* XXX - need to source or sink 
data here, as appropriate */
} else
cmd->SCp.this_residual -= 
transfersize - len;
-   } else
-#endif /* PSEUDO_DMA */
-   {
+   } else {
/* Break up transfer into 3 ms chunks,
 * presuming 6 accesses per handshake.
 */
Index: linux/drivers/scsi/NCR5380.h
===
--- linux.orig/drivers/scsi/NCR5380.h   2016-03-16 14:18:09.0 +1100
+++ linux/drivers/scsi/NCR5380.h2016-03-16 14:18:11.0 +1100
@@ -257,10 +257,6 @@ struct NCR5380_hostdata {
 #ifdef SUPPORT_TAGS
struct tag_alloc TagAlloc[8][8];/* 8 targets and 8 LUNs */
 #endif
-#ifdef PSEUDO_DMA
-   unsigned spin_max_r;
-   unsigned spin_max_w;
-#endif
struct workqueue_struct *work_q;
unsigned long accesses_per_ms;  /* chip register accesses per ms */
 };
Index: linux/drivers/scsi/arm/cumana_1.c
===
--- linux.orig/drivers/scsi/arm/cumana_1.c  2016-03-16 14:18:09.0 
+1100
+++ linux/drivers/scsi/arm/cumana_1.c   2016-03-16 14:18:11.0 +1100
@@ -13,8 +13,6 @@
 
 #include 
 
-#define PSEUDO_DMA
-
 #define priv(host) ((struct NCR5380_hostdata 
*)(host)->hostdata)
 #define NCR5380_read(reg)  cumanascsi_read(instance, reg)
 #define NCR5380_write(reg, value)  cumanascsi_write(instance, reg, value)
Index: linux/drivers/scsi/arm/oak.c
===
--- 

[PATCH v2 03/22] ncr5380: Remove REAL_DMA and REAL_DMA_POLL macros

[Finn Thain]

For the NCR5380.c core driver, these macros are never used.
If REAL_DMA were to be defined, compilation would fail.

For the atari_NCR5380.c core driver, REAL_DMA is always defined.

Hence these macros are pointless.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c   |  218 +--
 drivers/scsi/NCR5380.h   |  112 --
 drivers/scsi/atari_NCR5380.c |   62 +---
 drivers/scsi/atari_scsi.c|   32 --
 drivers/scsi/sun3_scsi.c |   13 --
 5 files changed, 22 insertions(+), 415 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:03.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:05.0 +1100
@@ -35,18 +35,10 @@
  * code so that everything does the same thing that's done at the
  * end of a pseudo-DMA read operation.
  *
- * 2.  Fix REAL_DMA (interrupt driven, polled works fine) -
- * basically, transfer size needs to be reduced by one
- * and the last byte read as is done with PSEUDO_DMA.
- *
  * 4.  Test SCSI-II tagged queueing (I have no devices which support
  * tagged queueing)
  */
 
-#ifndef notyet
-#undef REAL_DMA
-#endif
-
 #ifdef BOARD_REQUIRES_NO_DELAY
 #define io_recovery_delay(x)
 #else
@@ -131,12 +123,6 @@
  *
  * PSEUDO_DMA - if defined, PSEUDO DMA is used during the data transfer phases.
  *
- * REAL_DMA - if defined, REAL DMA is used during the data transfer phases.
- *
- * REAL_DMA_POLL - if defined, REAL DMA is used but the driver doesn't
- * rely on phase mismatch and EOP interrupts to determine end
- * of phase.
- *
  * These macros MUST be defined :
  *
  * NCR5380_read(register)  - read from the specified register
@@ -147,15 +133,9 @@
  * specific implementation of the NCR5380
  *
  * Either real DMA *or* pseudo DMA may be implemented
- * REAL functions :
- * NCR5380_REAL_DMA should be defined if real DMA is to be used.
  * Note that the DMA setup functions should return the number of bytes
  * that they were able to program the controller for.
  *
- * Also note that generic i386/PC versions of these macros are
- * available as NCR5380_i386_dma_write_setup,
- * NCR5380_i386_dma_read_setup, and NCR5380_i386_dma_residual.
- *
  * NCR5380_dma_write_setup(instance, src, count) - initialize
  * NCR5380_dma_read_setup(instance, dst, count) - initialize
  * NCR5380_dma_residual(instance); - residual count
@@ -486,12 +466,6 @@ static void prepare_info(struct Scsi_Hos
 #ifdef DIFFERENTIAL
 "DIFFERENTIAL "
 #endif
-#ifdef REAL_DMA
-"REAL_DMA "
-#endif
-#ifdef REAL_DMA_POLL
-"REAL_DMA_POLL "
-#endif
 #ifdef PARITY
 "PARITY "
 #endif
@@ -551,9 +525,8 @@ static int NCR5380_init(struct Scsi_Host
hostdata->id_higher_mask |= i;
for (i = 0; i < 8; ++i)
hostdata->busy[i] = 0;
-#ifdef REAL_DMA
-   hostdata->dmalen = 0;
-#endif
+   hostdata->dma_len = 0;
+
spin_lock_init(>lock);
hostdata->connected = NULL;
hostdata->sensing = NULL;
@@ -850,11 +823,7 @@ static void NCR5380_main(struct work_str
requeue_cmd(instance, cmd);
}
}
-   if (hostdata->connected
-#ifdef REAL_DMA
-   && !hostdata->dmalen
-#endif
-   ) {
+   if (hostdata->connected && !hostdata->dma_len) {
dsprintk(NDEBUG_MAIN, instance, "main: performing 
information transfer\n");
NCR5380_information_transfer(instance);
done = 0;
@@ -919,34 +888,6 @@ static irqreturn_t NCR5380_intr(int irq,
dsprintk(NDEBUG_INTR, instance, "IRQ %d, BASR 0x%02x, SR 
0x%02x, MR 0x%02x\n",
 irq, basr, sr, mr);
 
-#if defined(REAL_DMA)
-   if ((mr & MR_DMA_MODE) || (mr & MR_MONITOR_BSY)) {
-   /* Probably End of DMA, Phase Mismatch or Loss of BSY.
-* We ack IRQ after clearing Mode Register. Workarounds
-* for End of DMA errata need to happen in DMA Mode.
-*/
-
-   dsprintk(NDEBUG_INTR, instance, "interrupt in DMA 
mode\n");
-
-   int transferred;
-
-   if (!hostdata->connected)
-   panic("scsi%d : DMA interrupt with no connected 
cmd\n",
- instance->hostno);
-
-   transferred = hostdata->dmalen - 
NCR5380_dma_residual(instance);
-   hostdata->connected->SCp.this_residual -= transferred;
-   hostdata->connected->SCp.ptr += transferred;
-   hostdata->dmalen = 0;
-
-   /* 

[PATCH v2 03/22] ncr5380: Remove REAL_DMA and REAL_DMA_POLL macros

[Finn Thain]

For the NCR5380.c core driver, these macros are never used.
If REAL_DMA were to be defined, compilation would fail.

For the atari_NCR5380.c core driver, REAL_DMA is always defined.

Hence these macros are pointless.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c   |  218 +--
 drivers/scsi/NCR5380.h   |  112 --
 drivers/scsi/atari_NCR5380.c |   62 +---
 drivers/scsi/atari_scsi.c|   32 --
 drivers/scsi/sun3_scsi.c |   13 --
 5 files changed, 22 insertions(+), 415 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:03.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:05.0 +1100
@@ -35,18 +35,10 @@
  * code so that everything does the same thing that's done at the
  * end of a pseudo-DMA read operation.
  *
- * 2.  Fix REAL_DMA (interrupt driven, polled works fine) -
- * basically, transfer size needs to be reduced by one
- * and the last byte read as is done with PSEUDO_DMA.
- *
  * 4.  Test SCSI-II tagged queueing (I have no devices which support
  * tagged queueing)
  */
 
-#ifndef notyet
-#undef REAL_DMA
-#endif
-
 #ifdef BOARD_REQUIRES_NO_DELAY
 #define io_recovery_delay(x)
 #else
@@ -131,12 +123,6 @@
  *
  * PSEUDO_DMA - if defined, PSEUDO DMA is used during the data transfer phases.
  *
- * REAL_DMA - if defined, REAL DMA is used during the data transfer phases.
- *
- * REAL_DMA_POLL - if defined, REAL DMA is used but the driver doesn't
- * rely on phase mismatch and EOP interrupts to determine end
- * of phase.
- *
  * These macros MUST be defined :
  *
  * NCR5380_read(register)  - read from the specified register
@@ -147,15 +133,9 @@
  * specific implementation of the NCR5380
  *
  * Either real DMA *or* pseudo DMA may be implemented
- * REAL functions :
- * NCR5380_REAL_DMA should be defined if real DMA is to be used.
  * Note that the DMA setup functions should return the number of bytes
  * that they were able to program the controller for.
  *
- * Also note that generic i386/PC versions of these macros are
- * available as NCR5380_i386_dma_write_setup,
- * NCR5380_i386_dma_read_setup, and NCR5380_i386_dma_residual.
- *
  * NCR5380_dma_write_setup(instance, src, count) - initialize
  * NCR5380_dma_read_setup(instance, dst, count) - initialize
  * NCR5380_dma_residual(instance); - residual count
@@ -486,12 +466,6 @@ static void prepare_info(struct Scsi_Hos
 #ifdef DIFFERENTIAL
 "DIFFERENTIAL "
 #endif
-#ifdef REAL_DMA
-"REAL_DMA "
-#endif
-#ifdef REAL_DMA_POLL
-"REAL_DMA_POLL "
-#endif
 #ifdef PARITY
 "PARITY "
 #endif
@@ -551,9 +525,8 @@ static int NCR5380_init(struct Scsi_Host
hostdata->id_higher_mask |= i;
for (i = 0; i < 8; ++i)
hostdata->busy[i] = 0;
-#ifdef REAL_DMA
-   hostdata->dmalen = 0;
-#endif
+   hostdata->dma_len = 0;
+
spin_lock_init(>lock);
hostdata->connected = NULL;
hostdata->sensing = NULL;
@@ -850,11 +823,7 @@ static void NCR5380_main(struct work_str
requeue_cmd(instance, cmd);
}
}
-   if (hostdata->connected
-#ifdef REAL_DMA
-   && !hostdata->dmalen
-#endif
-   ) {
+   if (hostdata->connected && !hostdata->dma_len) {
dsprintk(NDEBUG_MAIN, instance, "main: performing 
information transfer\n");
NCR5380_information_transfer(instance);
done = 0;
@@ -919,34 +888,6 @@ static irqreturn_t NCR5380_intr(int irq,
dsprintk(NDEBUG_INTR, instance, "IRQ %d, BASR 0x%02x, SR 
0x%02x, MR 0x%02x\n",
 irq, basr, sr, mr);
 
-#if defined(REAL_DMA)
-   if ((mr & MR_DMA_MODE) || (mr & MR_MONITOR_BSY)) {
-   /* Probably End of DMA, Phase Mismatch or Loss of BSY.
-* We ack IRQ after clearing Mode Register. Workarounds
-* for End of DMA errata need to happen in DMA Mode.
-*/
-
-   dsprintk(NDEBUG_INTR, instance, "interrupt in DMA 
mode\n");
-
-   int transferred;
-
-   if (!hostdata->connected)
-   panic("scsi%d : DMA interrupt with no connected 
cmd\n",
- instance->hostno);
-
-   transferred = hostdata->dmalen - 
NCR5380_dma_residual(instance);
-   hostdata->connected->SCp.this_residual -= transferred;
-   hostdata->connected->SCp.ptr += transferred;
-   hostdata->dmalen = 0;
-
-   /* FIXME: we need to poll briefly then defer 

[PATCH v2 05/22] ncr5380: Disable the DMA errata workaround flag by default

[Finn Thain]

The only chip that needs the workarounds enabled is an early NMOS
device. That means that the common case is to disable them.

Unfortunately the sense of the flag is such that it has to be set
for the common case.

Rename the flag so that zero can be used to mean "no errata workarounds
needed". This simplifies the code.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c  |   14 +++---
 drivers/scsi/NCR5380.h  |2 +-
 drivers/scsi/arm/cumana_1.c |2 +-
 drivers/scsi/arm/oak.c  |2 +-
 drivers/scsi/dtc.c  |2 +-
 drivers/scsi/g_NCR5380.c|8 +---
 drivers/scsi/pas16.c|2 +-
 drivers/scsi/t128.c |2 +-
 8 files changed, 14 insertions(+), 20 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:05.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:09.0 +1100
@@ -457,7 +457,7 @@ static void prepare_info(struct Scsi_Hos
 instance->base, instance->irq,
 instance->can_queue, instance->cmd_per_lun,
 instance->sg_tablesize, instance->this_id,
-hostdata->flags & FLAG_NO_DMA_FIXUP  ? "NO_DMA_FIXUP "  : "",
+hostdata->flags & FLAG_DMA_FIXUP ? "DMA_FIXUP " : "",
 hostdata->flags & FLAG_NO_PSEUDO_DMA ? "NO_PSEUDO_DMA " : "",
 hostdata->flags & FLAG_TOSHIBA_DELAY ? "TOSHIBA_DELAY "  : "",
 #ifdef AUTOPROBE_IRQ
@@ -1480,11 +1480,11 @@ static int NCR5380_transfer_dma(struct S
 * before the setting of DMA mode to after transfer of the last byte.
 */
 
-   if (hostdata->flags & FLAG_NO_DMA_FIXUP)
+   if (hostdata->flags & FLAG_DMA_FIXUP)
+   NCR5380_write(MODE_REG, MR_BASE | MR_DMA_MODE | MR_MONITOR_BSY);
+   else
NCR5380_write(MODE_REG, MR_BASE | MR_DMA_MODE | MR_MONITOR_BSY |
MR_ENABLE_EOP_INTR);
-   else
-   NCR5380_write(MODE_REG, MR_BASE | MR_DMA_MODE | MR_MONITOR_BSY);
 
dprintk(NDEBUG_DMA, "scsi%d : mode reg = 0x%X\n", instance->host_no, 
NCR5380_read(MODE_REG));
 
@@ -1540,8 +1540,8 @@ static int NCR5380_transfer_dma(struct S
 
if (p & SR_IO) {
foo = NCR5380_pread(instance, d,
-   hostdata->flags & FLAG_NO_DMA_FIXUP ? c : c - 1);
-   if (!foo && !(hostdata->flags & FLAG_NO_DMA_FIXUP)) {
+   hostdata->flags & FLAG_DMA_FIXUP ? c - 1 : c);
+   if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
 * The workaround was to transfer fewer bytes than we
 * intended to with the pseudo-DMA read function, wait 
for
@@ -1571,7 +1571,7 @@ static int NCR5380_transfer_dma(struct S
}
} else {
foo = NCR5380_pwrite(instance, d, c);
-   if (!foo && !(hostdata->flags & FLAG_NO_DMA_FIXUP)) {
+   if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
 * Wait for the last byte to be sent.  If REQ is being 
asserted for
 * the byte we're interested, we'll ACK it and it will 
go false.
Index: linux/drivers/scsi/NCR5380.h
===
--- linux.orig/drivers/scsi/NCR5380.h   2016-03-16 14:18:05.0 +1100
+++ linux/drivers/scsi/NCR5380.h2016-03-16 14:18:09.0 +1100
@@ -220,7 +220,7 @@
 #define NO_IRQ 0
 #endif
 
-#define FLAG_NO_DMA_FIXUP  1   /* No DMA errata workarounds */
+#define FLAG_DMA_FIXUP 1   /* Use DMA errata workarounds */
 #define FLAG_NO_PSEUDO_DMA 8   /* Inhibit DMA */
 #define FLAG_LATE_DMA_SETUP32  /* Setup NCR before DMA H/W */
 #define FLAG_TAGGED_QUEUING64  /* as X3T9.2 spelled it */
Index: linux/drivers/scsi/dtc.c
===
--- linux.orig/drivers/scsi/dtc.c   2016-03-16 14:16:56.0 +1100
+++ linux/drivers/scsi/dtc.c2016-03-16 14:18:09.0 +1100
@@ -229,7 +229,7 @@ found:
instance->base = addr;
((struct NCR5380_hostdata *)(instance)->hostdata)->base = base;
 
-   if (NCR5380_init(instance, FLAG_NO_DMA_FIXUP))
+   if (NCR5380_init(instance, 0))
goto out_unregister;
 
NCR5380_maybe_reset_bus(instance);
Index: linux/drivers/scsi/g_NCR5380.c
===
--- linux.orig/drivers/scsi/g_NCR5380.c 2016-03-16 14:18:03.0 +1100
+++ linux/drivers/scsi/g_NCR5380.c  2016-03-16 14:18:09.0 +1100
@@ -348,23 

[PATCH v2 01/22] g_ncr5380: Remove CONFIG_SCSI_GENERIC_NCR53C400

[Finn Thain]

This change brings a number of improvements: fewer macros, better test
coverage, simpler code and sane Kconfig options. The downside is a small
chance of incompatibility (which seems unavoidable).

CONFIG_SCSI_GENERIC_NCR53C400 exists to enable or inhibit pseudo DMA
transfers when the driver is used with 53C400-compatible cards. Thanks to
Ondrej Zary's patches, PDMA now works which means it can be enabled
unconditionally.

Due to bad design, CONFIG_SCSI_GENERIC_NCR53C400 ties together unrelated
functionality as it sets both PSEUDO_DMA and BIOSPARAM macros. This patch
effectively enables PSEUDO_DMA and disables BIOSPARAM.

The defconfigs and the Kconfig default leave CONFIG_SCSI_GENERIC_NCR53C400
undefined. Red Hat 9 and CentOS 2.1 were the same. This leaves both
PSEUDO_DMA and BIOSPARAM disabled. The effect of this patch should be
better performance from enabling PSEUDO_DMA.

On the other hand, Debian 4 and SLES 10 had CONFIG_SCSI_GENERIC_NCR53C400
enabled, so both PSEUDO_DMA and BIOSPARAM were enabled. This patch might
affect configurations like this by disabling BIOSPARAM. My best guess is
that this could be a problem only in the vanishingly rare case that
1) the CHS values stored in the boot device partition table are wrong and
2) a 5380 card is in use (because PDMA on 53C400 used to be broken).

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---

Here are the distro kernel versions I looked at:

CentOS 2.1:

$ strings 
kernel-2.4.9-e.40.i686/lib/modules/2.4.9-e.40/kernel/drivers/scsi/g_NCR5380.o | 
grep extension
NO NCR53C400 driver extensions


Red Hat 7:

$ strings 
kernel-2.4.18-3.i386/lib/modules/2.4.18-3/kernel/drivers/scsi/g_NCR5380.o | 
grep extension
NO NCR53C400 driver extensions


Red Hat 9:

$ strings 
kernel-2.4.20-8.i586/lib/modules/2.4.20-8/kernel/drivers/scsi/g_NCR5380.o | 
grep extension
NO NCR53C400 driver extensions


Debian 4:

$ strings 
linux-image-2.6.24-etchnhalf.1-486_2.6.24-6-etchnhalf.9etch3_i386/lib/modules/2.6.24-etchnhalf.1-486/kernel/drivers/scsi/g_NCR5380_mmio.ko
 | grep extension
NCR53C400 extension version %d
$ strings 
kernel-image-2.6.8-2-386_2.6.8-13_i386/lib/modules/2.6.8-2-386/kernel/drivers/scsi/g_NCR5380_mmio.ko
 | grep extension
NCR53C400 extension version %d


SLES 10.2:

$ strings 
kernel-default-2.6.18.2-34.i586/lib/modules/2.6.18.2-34-default/kernel/drivers/scsi/g_NCR5380_mmio.ko
 | grep extension
NCR53C400 extension version %d

---
 drivers/scsi/Kconfig |   11 --
 drivers/scsi/g_NCR5380.c |   75 ++-
 drivers/scsi/g_NCR5380.h |   16 +-
 3 files changed, 25 insertions(+), 77 deletions(-)

Index: linux/drivers/scsi/Kconfig
===
--- linux.orig/drivers/scsi/Kconfig 2016-03-16 14:16:56.0 +1100
+++ linux/drivers/scsi/Kconfig  2016-03-16 14:18:01.0 +1100
@@ -812,17 +812,6 @@ config SCSI_GENERIC_NCR5380_MMIO
  To compile this driver as a module, choose M here: the
  module will be called g_NCR5380_mmio.
 
-config SCSI_GENERIC_NCR53C400
-   bool "Enable NCR53c400 extensions"
-   depends on SCSI_GENERIC_NCR5380
-   help
- This enables certain optimizations for the NCR53c400 SCSI cards.
- You might as well try it out.  Note that this driver will only probe
- for the Trantor T130B in its default configuration; you might have
- to pass a command line option to the kernel at boot time if it does
- not detect your card.  See the file
-  for details.
-
 config SCSI_IPS
tristate "IBM ServeRAID support"
depends on PCI && SCSI
Index: linux/drivers/scsi/g_NCR5380.c
===
--- linux.orig/drivers/scsi/g_NCR5380.c 2016-03-16 14:16:56.0 +1100
+++ linux/drivers/scsi/g_NCR5380.c  2016-03-16 14:18:01.0 +1100
@@ -57,10 +57,7 @@
  */
 
 #define AUTOPROBE_IRQ
-
-#ifdef CONFIG_SCSI_GENERIC_NCR53C400
 #define PSEUDO_DMA
-#endif
 
 #include 
 #include 
@@ -270,7 +267,7 @@ static int __init generic_NCR5380_detect
 #ifndef SCSI_G_NCR5380_MEM
int i;
int port_idx = -1;
-   unsigned long region_size = 16;
+   unsigned long region_size;
 #endif
static unsigned int __initdata ncr_53c400a_ports[] = {
0x280, 0x290, 0x300, 0x310, 0x330, 0x340, 0x348, 0x350, 0
@@ -290,6 +287,7 @@ static int __init generic_NCR5380_detect
 #ifdef SCSI_G_NCR5380_MEM
unsigned long base;
void __iomem *iomem;
+   resource_size_t iomem_size;
 #endif
 
if (ncr_irq)
@@ -353,9 +351,7 @@ static int __init generic_NCR5380_detect
flags = FLAG_NO_PSEUDO_DMA;
break;
case BOARD_NCR53C400:
-#ifdef PSEUDO_DMA
flags = FLAG_NO_DMA_FIXUP;
-#endif
break;
case 

[PATCH v2 01/22] g_ncr5380: Remove CONFIG_SCSI_GENERIC_NCR53C400

[Finn Thain]

This change brings a number of improvements: fewer macros, better test
coverage, simpler code and sane Kconfig options. The downside is a small
chance of incompatibility (which seems unavoidable).

CONFIG_SCSI_GENERIC_NCR53C400 exists to enable or inhibit pseudo DMA
transfers when the driver is used with 53C400-compatible cards. Thanks to
Ondrej Zary's patches, PDMA now works which means it can be enabled
unconditionally.

Due to bad design, CONFIG_SCSI_GENERIC_NCR53C400 ties together unrelated
functionality as it sets both PSEUDO_DMA and BIOSPARAM macros. This patch
effectively enables PSEUDO_DMA and disables BIOSPARAM.

The defconfigs and the Kconfig default leave CONFIG_SCSI_GENERIC_NCR53C400
undefined. Red Hat 9 and CentOS 2.1 were the same. This leaves both
PSEUDO_DMA and BIOSPARAM disabled. The effect of this patch should be
better performance from enabling PSEUDO_DMA.

On the other hand, Debian 4 and SLES 10 had CONFIG_SCSI_GENERIC_NCR53C400
enabled, so both PSEUDO_DMA and BIOSPARAM were enabled. This patch might
affect configurations like this by disabling BIOSPARAM. My best guess is
that this could be a problem only in the vanishingly rare case that
1) the CHS values stored in the boot device partition table are wrong and
2) a 5380 card is in use (because PDMA on 53C400 used to be broken).

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---

Here are the distro kernel versions I looked at:

CentOS 2.1:

$ strings 
kernel-2.4.9-e.40.i686/lib/modules/2.4.9-e.40/kernel/drivers/scsi/g_NCR5380.o | 
grep extension
NO NCR53C400 driver extensions


Red Hat 7:

$ strings 
kernel-2.4.18-3.i386/lib/modules/2.4.18-3/kernel/drivers/scsi/g_NCR5380.o | 
grep extension
NO NCR53C400 driver extensions


Red Hat 9:

$ strings 
kernel-2.4.20-8.i586/lib/modules/2.4.20-8/kernel/drivers/scsi/g_NCR5380.o | 
grep extension
NO NCR53C400 driver extensions


Debian 4:

$ strings 
linux-image-2.6.24-etchnhalf.1-486_2.6.24-6-etchnhalf.9etch3_i386/lib/modules/2.6.24-etchnhalf.1-486/kernel/drivers/scsi/g_NCR5380_mmio.ko
 | grep extension
NCR53C400 extension version %d
$ strings 
kernel-image-2.6.8-2-386_2.6.8-13_i386/lib/modules/2.6.8-2-386/kernel/drivers/scsi/g_NCR5380_mmio.ko
 | grep extension
NCR53C400 extension version %d


SLES 10.2:

$ strings 
kernel-default-2.6.18.2-34.i586/lib/modules/2.6.18.2-34-default/kernel/drivers/scsi/g_NCR5380_mmio.ko
 | grep extension
NCR53C400 extension version %d

---
 drivers/scsi/Kconfig |   11 --
 drivers/scsi/g_NCR5380.c |   75 ++-
 drivers/scsi/g_NCR5380.h |   16 +-
 3 files changed, 25 insertions(+), 77 deletions(-)

Index: linux/drivers/scsi/Kconfig
===
--- linux.orig/drivers/scsi/Kconfig 2016-03-16 14:16:56.0 +1100
+++ linux/drivers/scsi/Kconfig  2016-03-16 14:18:01.0 +1100
@@ -812,17 +812,6 @@ config SCSI_GENERIC_NCR5380_MMIO
  To compile this driver as a module, choose M here: the
  module will be called g_NCR5380_mmio.
 
-config SCSI_GENERIC_NCR53C400
-   bool "Enable NCR53c400 extensions"
-   depends on SCSI_GENERIC_NCR5380
-   help
- This enables certain optimizations for the NCR53c400 SCSI cards.
- You might as well try it out.  Note that this driver will only probe
- for the Trantor T130B in its default configuration; you might have
- to pass a command line option to the kernel at boot time if it does
- not detect your card.  See the file
-  for details.
-
 config SCSI_IPS
tristate "IBM ServeRAID support"
depends on PCI && SCSI
Index: linux/drivers/scsi/g_NCR5380.c
===
--- linux.orig/drivers/scsi/g_NCR5380.c 2016-03-16 14:16:56.0 +1100
+++ linux/drivers/scsi/g_NCR5380.c  2016-03-16 14:18:01.0 +1100
@@ -57,10 +57,7 @@
  */
 
 #define AUTOPROBE_IRQ
-
-#ifdef CONFIG_SCSI_GENERIC_NCR53C400
 #define PSEUDO_DMA
-#endif
 
 #include 
 #include 
@@ -270,7 +267,7 @@ static int __init generic_NCR5380_detect
 #ifndef SCSI_G_NCR5380_MEM
int i;
int port_idx = -1;
-   unsigned long region_size = 16;
+   unsigned long region_size;
 #endif
static unsigned int __initdata ncr_53c400a_ports[] = {
0x280, 0x290, 0x300, 0x310, 0x330, 0x340, 0x348, 0x350, 0
@@ -290,6 +287,7 @@ static int __init generic_NCR5380_detect
 #ifdef SCSI_G_NCR5380_MEM
unsigned long base;
void __iomem *iomem;
+   resource_size_t iomem_size;
 #endif
 
if (ncr_irq)
@@ -353,9 +351,7 @@ static int __init generic_NCR5380_detect
flags = FLAG_NO_PSEUDO_DMA;
break;
case BOARD_NCR53C400:
-#ifdef PSEUDO_DMA
flags = FLAG_NO_DMA_FIXUP;
-#endif
break;
case BOARD_NCR53C400A:
flags = 

[PATCH v2 05/22] ncr5380: Disable the DMA errata workaround flag by default

[Finn Thain]

The only chip that needs the workarounds enabled is an early NMOS
device. That means that the common case is to disable them.

Unfortunately the sense of the flag is such that it has to be set
for the common case.

Rename the flag so that zero can be used to mean "no errata workarounds
needed". This simplifies the code.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c  |   14 +++---
 drivers/scsi/NCR5380.h  |2 +-
 drivers/scsi/arm/cumana_1.c |2 +-
 drivers/scsi/arm/oak.c  |2 +-
 drivers/scsi/dtc.c  |2 +-
 drivers/scsi/g_NCR5380.c|8 +---
 drivers/scsi/pas16.c|2 +-
 drivers/scsi/t128.c |2 +-
 8 files changed, 14 insertions(+), 20 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:05.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:09.0 +1100
@@ -457,7 +457,7 @@ static void prepare_info(struct Scsi_Hos
 instance->base, instance->irq,
 instance->can_queue, instance->cmd_per_lun,
 instance->sg_tablesize, instance->this_id,
-hostdata->flags & FLAG_NO_DMA_FIXUP  ? "NO_DMA_FIXUP "  : "",
+hostdata->flags & FLAG_DMA_FIXUP ? "DMA_FIXUP " : "",
 hostdata->flags & FLAG_NO_PSEUDO_DMA ? "NO_PSEUDO_DMA " : "",
 hostdata->flags & FLAG_TOSHIBA_DELAY ? "TOSHIBA_DELAY "  : "",
 #ifdef AUTOPROBE_IRQ
@@ -1480,11 +1480,11 @@ static int NCR5380_transfer_dma(struct S
 * before the setting of DMA mode to after transfer of the last byte.
 */
 
-   if (hostdata->flags & FLAG_NO_DMA_FIXUP)
+   if (hostdata->flags & FLAG_DMA_FIXUP)
+   NCR5380_write(MODE_REG, MR_BASE | MR_DMA_MODE | MR_MONITOR_BSY);
+   else
NCR5380_write(MODE_REG, MR_BASE | MR_DMA_MODE | MR_MONITOR_BSY |
MR_ENABLE_EOP_INTR);
-   else
-   NCR5380_write(MODE_REG, MR_BASE | MR_DMA_MODE | MR_MONITOR_BSY);
 
dprintk(NDEBUG_DMA, "scsi%d : mode reg = 0x%X\n", instance->host_no, 
NCR5380_read(MODE_REG));
 
@@ -1540,8 +1540,8 @@ static int NCR5380_transfer_dma(struct S
 
if (p & SR_IO) {
foo = NCR5380_pread(instance, d,
-   hostdata->flags & FLAG_NO_DMA_FIXUP ? c : c - 1);
-   if (!foo && !(hostdata->flags & FLAG_NO_DMA_FIXUP)) {
+   hostdata->flags & FLAG_DMA_FIXUP ? c - 1 : c);
+   if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
 * The workaround was to transfer fewer bytes than we
 * intended to with the pseudo-DMA read function, wait 
for
@@ -1571,7 +1571,7 @@ static int NCR5380_transfer_dma(struct S
}
} else {
foo = NCR5380_pwrite(instance, d, c);
-   if (!foo && !(hostdata->flags & FLAG_NO_DMA_FIXUP)) {
+   if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
 * Wait for the last byte to be sent.  If REQ is being 
asserted for
 * the byte we're interested, we'll ACK it and it will 
go false.
Index: linux/drivers/scsi/NCR5380.h
===
--- linux.orig/drivers/scsi/NCR5380.h   2016-03-16 14:18:05.0 +1100
+++ linux/drivers/scsi/NCR5380.h2016-03-16 14:18:09.0 +1100
@@ -220,7 +220,7 @@
 #define NO_IRQ 0
 #endif
 
-#define FLAG_NO_DMA_FIXUP  1   /* No DMA errata workarounds */
+#define FLAG_DMA_FIXUP 1   /* Use DMA errata workarounds */
 #define FLAG_NO_PSEUDO_DMA 8   /* Inhibit DMA */
 #define FLAG_LATE_DMA_SETUP32  /* Setup NCR before DMA H/W */
 #define FLAG_TAGGED_QUEUING64  /* as X3T9.2 spelled it */
Index: linux/drivers/scsi/dtc.c
===
--- linux.orig/drivers/scsi/dtc.c   2016-03-16 14:16:56.0 +1100
+++ linux/drivers/scsi/dtc.c2016-03-16 14:18:09.0 +1100
@@ -229,7 +229,7 @@ found:
instance->base = addr;
((struct NCR5380_hostdata *)(instance)->hostdata)->base = base;
 
-   if (NCR5380_init(instance, FLAG_NO_DMA_FIXUP))
+   if (NCR5380_init(instance, 0))
goto out_unregister;
 
NCR5380_maybe_reset_bus(instance);
Index: linux/drivers/scsi/g_NCR5380.c
===
--- linux.orig/drivers/scsi/g_NCR5380.c 2016-03-16 14:18:03.0 +1100
+++ linux/drivers/scsi/g_NCR5380.c  2016-03-16 14:18:09.0 +1100
@@ -348,23 +348,17 @@ static int __init 

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

[Steve Muckle]

On 03/15/2016 03:37 PM, Michael Turquette wrote:
 Yuck sysfs.. I would really rather we did not expose this per default.
 > > > And certainly not in this weird form.
>>> > > 
>>> > > I'm happy to change capacity_margin to up_threshold and use a
>>> > > percentage.
>>> > > 
>>> > > The sysfs approach has two benefits. First, it is aligned with cpufreq
>>> > > user expectations. Second, there has been rough consensus that this
>>> > > value should be tunable and sysfs gets us there quickly and painlessly.
>>> > > We're already exporting rate_limit_us for schedutil via sysfs. Is there
>>> > > a better way interface you can recommend?
>> > 
>> > It really depends on how tunable you want this to be. Do we always want
>> > this to be a tunable, or just now while we're playing about with the
>> > whole thing?
>
> I had considered this myself, and I really think that Steve and Juri
> should chime in as they have spent more time tuning and running the
> numbers.
> 
> I'm inclined to think that a debug version would be good enough, as I
> don't imagine this value being changed at run-time by some userspace
> daemon or something.
> 
> Then again, maybe this knob will be part of the mythical
> power-vs-performance slider?

Patrick Bellasi's schedtune series [0] (which I think is the referenced
mythical slider) aims to provide a more sophisticated interface for
tuning scheduler-driven frequency selection. In addition to a global
boost value it includes a cgroup controller as well for per-task tuning.

I would definitely expect the margin/boost value to be modified at
runtime, for example if the battery is running low, or the user wants
100% performance for a while, or the userspace framework wants to
temporarily tailor the performance level for a particular set of tasks, etc.

[0] http://article.gmane.org/gmane.linux.kernel/2022959

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

[Steve Muckle]

On 03/15/2016 03:37 PM, Michael Turquette wrote:
 Yuck sysfs.. I would really rather we did not expose this per default.
 > > > And certainly not in this weird form.
>>> > > 
>>> > > I'm happy to change capacity_margin to up_threshold and use a
>>> > > percentage.
>>> > > 
>>> > > The sysfs approach has two benefits. First, it is aligned with cpufreq
>>> > > user expectations. Second, there has been rough consensus that this
>>> > > value should be tunable and sysfs gets us there quickly and painlessly.
>>> > > We're already exporting rate_limit_us for schedutil via sysfs. Is there
>>> > > a better way interface you can recommend?
>> > 
>> > It really depends on how tunable you want this to be. Do we always want
>> > this to be a tunable, or just now while we're playing about with the
>> > whole thing?
>
> I had considered this myself, and I really think that Steve and Juri
> should chime in as they have spent more time tuning and running the
> numbers.
> 
> I'm inclined to think that a debug version would be good enough, as I
> don't imagine this value being changed at run-time by some userspace
> daemon or something.
> 
> Then again, maybe this knob will be part of the mythical
> power-vs-performance slider?

Patrick Bellasi's schedtune series [0] (which I think is the referenced
mythical slider) aims to provide a more sophisticated interface for
tuning scheduler-driven frequency selection. In addition to a global
boost value it includes a cgroup controller as well for per-task tuning.

I would definitely expect the margin/boost value to be modified at
runtime, for example if the battery is running low, or the user wants
100% performance for a while, or the userspace framework wants to
temporarily tailor the performance level for a particular set of tasks, etc.

[0] http://article.gmane.org/gmane.linux.kernel/2022959

[PATCH v2 10/22] ncr5380: Merge DMA implementation from atari_NCR5380 core driver

[Finn Thain]

Adopt the DMA implementation from atari_NCR5380.c. This means that
atari_scsi and sun3_scsi can make use of the NCR5380.c core driver
and the atari_NCR5380.c driver fork can be made redundant.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c  |  170 +++-
 drivers/scsi/arm/cumana_1.c |3 
 drivers/scsi/arm/oak.c  |3 
 drivers/scsi/dmx3191d.c |1 
 drivers/scsi/dtc.c  |2 
 drivers/scsi/dtc.h  |1 
 drivers/scsi/g_NCR5380.c|2 
 drivers/scsi/g_NCR5380.h|1 
 drivers/scsi/mac_scsi.c |3 
 drivers/scsi/pas16.c|2 
 drivers/scsi/pas16.h|1 
 drivers/scsi/t128.c |2 
 drivers/scsi/t128.h |1 
 13 files changed, 152 insertions(+), 40 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:19.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:20.0 +1100
@@ -31,9 +31,6 @@
 
 /*
  * Further development / testing that should be done :
- * 1.  Cleanup the NCR5380_transfer_dma function and DMA operation complete
- * code so that everything does the same thing that's done at the
- * end of a pseudo-DMA read operation.
  *
  * 4.  Test SCSI-II tagged queueing (I have no devices which support
  * tagged queueing)
@@ -117,6 +114,8 @@
  *
  * PSEUDO_DMA - if defined, PSEUDO DMA is used during the data transfer phases.
  *
+ * REAL_DMA - if defined, REAL DMA is used during the data transfer phases.
+ *
  * These macros MUST be defined :
  *
  * NCR5380_read(register)  - read from the specified register
@@ -801,6 +800,72 @@ static void NCR5380_main(struct work_str
} while (!done);
 }
 
+/*
+ * NCR5380_dma_complete - finish DMA transfer
+ * @instance: the scsi host instance
+ *
+ * Called by the interrupt handler when DMA finishes or a phase
+ * mismatch occurs (which would end the DMA transfer).
+ */
+
+static void NCR5380_dma_complete(struct Scsi_Host *instance)
+{
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
+   int transferred;
+   unsigned char **data;
+   int *count;
+   int saved_data = 0, overrun = 0;
+   unsigned char p;
+
+   if (hostdata->read_overruns) {
+   p = hostdata->connected->SCp.phase;
+   if (p & SR_IO) {
+   udelay(10);
+   if ((NCR5380_read(BUS_AND_STATUS_REG) &
+(BASR_PHASE_MATCH | BASR_ACK)) ==
+   (BASR_PHASE_MATCH | BASR_ACK)) {
+   saved_data = NCR5380_read(INPUT_DATA_REG);
+   overrun = 1;
+   dsprintk(NDEBUG_DMA, instance, "read overrun 
handled\n");
+   }
+   }
+   }
+
+   NCR5380_write(MODE_REG, MR_BASE);
+   NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
+   NCR5380_read(RESET_PARITY_INTERRUPT_REG);
+
+   transferred = hostdata->dma_len - NCR5380_dma_residual(instance);
+   hostdata->dma_len = 0;
+
+   data = (unsigned char **)>connected->SCp.ptr;
+   count = >connected->SCp.this_residual;
+   *data += transferred;
+   *count -= transferred;
+
+   if (hostdata->read_overruns) {
+   int cnt, toPIO;
+
+   if ((NCR5380_read(STATUS_REG) & PHASE_MASK) == p && (p & 
SR_IO)) {
+   cnt = toPIO = hostdata->read_overruns;
+   if (overrun) {
+   dsprintk(NDEBUG_DMA, instance,
+"Got an input overrun, using saved 
byte\n");
+   *(*data)++ = saved_data;
+   (*count)--;
+   cnt--;
+   toPIO--;
+   }
+   if (toPIO > 0) {
+   dsprintk(NDEBUG_DMA, instance,
+"Doing %d byte PIO to 0x%p\n", cnt, 
*data);
+   NCR5380_transfer_pio(instance, , , data);
+   *count -= toPIO - cnt;
+   }
+   }
+   }
+}
+
 #ifndef DONT_USE_INTR
 
 /**
@@ -855,7 +920,22 @@ static irqreturn_t NCR5380_intr(int irq,
dsprintk(NDEBUG_INTR, instance, "IRQ %d, BASR 0x%02x, SR 
0x%02x, MR 0x%02x\n",
 irq, basr, sr, mr);
 
-   if ((NCR5380_read(CURRENT_SCSI_DATA_REG) & hostdata->id_mask) &&
+   if ((mr & MR_DMA_MODE) || (mr & MR_MONITOR_BSY)) {
+   /* Probably End of DMA, Phase Mismatch or Loss of BSY.
+* We ack IRQ after clearing Mode Register. Workarounds
+* for End of DMA errata need 

[PATCH v2 08/22] ncr5380: Use DMA hooks for PDMA

[Finn Thain]

Those wrapper drivers which use DMA define the REAL_DMA macro and
those which use pseudo DMA define PSEUDO_DMA. These macros need to be
removed for a number of reasons, not least of which is to have drivers
share more code.

Redefine the PDMA send and receive hooks as DMA setup hooks, so that the
DMA code can be shared by all 5380 wrapper drivers. This will help to
reunify the forked core driver.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c  |   10 ++
 drivers/scsi/arm/cumana_1.c |   10 ++
 drivers/scsi/arm/oak.c  |   10 ++
 drivers/scsi/dmx3191d.c |4 ++--
 drivers/scsi/dtc.c  |6 --
 drivers/scsi/dtc.h  |2 ++
 drivers/scsi/g_NCR5380.c|   10 ++
 drivers/scsi/g_NCR5380.h|4 ++--
 drivers/scsi/mac_scsi.c |5 ++---
 drivers/scsi/pas16.c|   14 --
 drivers/scsi/pas16.h|2 ++
 drivers/scsi/t128.c |   12 ++--
 drivers/scsi/t128.h |2 ++
 13 files changed, 50 insertions(+), 41 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:14.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:15.0 +1100
@@ -127,17 +127,11 @@
  * specific implementation of the NCR5380
  *
  * Either real DMA *or* pseudo DMA may be implemented
- * Note that the DMA setup functions should return the number of bytes
- * that they were able to program the controller for.
  *
  * NCR5380_dma_write_setup(instance, src, count) - initialize
  * NCR5380_dma_read_setup(instance, dst, count) - initialize
  * NCR5380_dma_residual(instance); - residual count
  *
- * PSEUDO functions :
- * NCR5380_pwrite(instance, src, count)
- * NCR5380_pread(instance, dst, count);
- *
  * The generic driver is initialized by calling NCR5380_init(instance),
  * after setting the appropriate host specific fields and ID.  If the
  * driver wishes to autoprobe for an IRQ line, the NCR5380_probe_irq(instance,
@@ -1511,7 +1505,7 @@ static int NCR5380_transfer_dma(struct S
  */
 
if (p & SR_IO) {
-   foo = NCR5380_pread(instance, d,
+   foo = NCR5380_dma_recv_setup(instance, d,
hostdata->flags & FLAG_DMA_FIXUP ? c - 1 : c);
if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
@@ -1542,7 +1536,7 @@ static int NCR5380_transfer_dma(struct S
d[c - 1] = NCR5380_read(INPUT_DATA_REG);
}
} else {
-   foo = NCR5380_pwrite(instance, d, c);
+   foo = NCR5380_dma_send_setup(instance, d, c);
if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
 * Wait for the last byte to be sent.  If REQ is being 
asserted for
Index: linux/drivers/scsi/arm/cumana_1.c
===
--- linux.orig/drivers/scsi/arm/cumana_1.c  2016-03-16 14:18:11.0 
+1100
+++ linux/drivers/scsi/arm/cumana_1.c   2016-03-16 14:18:15.0 +1100
@@ -18,6 +18,8 @@
 #define NCR5380_write(reg, value)  cumanascsi_write(instance, reg, value)
 
 #define NCR5380_dma_xfer_len(instance, cmd, phase) (cmd->transfersize)
+#define NCR5380_dma_recv_setup cumanascsi_pread
+#define NCR5380_dma_send_setup cumanascsi_pwrite
 
 #define NCR5380_intr   cumanascsi_intr
 #define NCR5380_queue_command  cumanascsi_queue_command
@@ -39,8 +41,8 @@ void cumanascsi_setup(char *str, int *in
 #define L(v)   (((v)<<16)|((v) & 0x))
 #define H(v)   (((v)>>16)|((v) & 0x))
 
-static inline int
-NCR5380_pwrite(struct Scsi_Host *host, unsigned char *addr, int len)
+static inline int cumanascsi_pwrite(struct Scsi_Host *host,
+unsigned char *addr, int len)
 {
   unsigned long *laddr;
   void __iomem *dma = priv(host)->dma + 0x2000;
@@ -102,8 +104,8 @@ end:
   return len;
 }
 
-static inline int
-NCR5380_pread(struct Scsi_Host *host, unsigned char *addr, int len)
+static inline int cumanascsi_pread(struct Scsi_Host *host,
+   unsigned char *addr, int len)
 {
   unsigned long *laddr;
   void __iomem *dma = priv(host)->dma + 0x2000;
Index: linux/drivers/scsi/arm/oak.c
===
--- linux.orig/drivers/scsi/arm/oak.c   2016-03-16 14:18:11.0 +1100
+++ linux/drivers/scsi/arm/oak.c2016-03-16 14:18:15.0 +1100
@@ -24,6 +24,8 @@
writeb(value, priv(instance)->base + ((reg) << 2))
 
 #define NCR5380_dma_xfer_len(instance, cmd, phase) (0)
+#define NCR5380_dma_recv_setup oakscsi_pread
+#define NCR5380_dma_send_setup oakscsi_pwrite
 
 #define NCR5380_queue_command  

[PATCH v2 10/22] ncr5380: Merge DMA implementation from atari_NCR5380 core driver

[Finn Thain]

Adopt the DMA implementation from atari_NCR5380.c. This means that
atari_scsi and sun3_scsi can make use of the NCR5380.c core driver
and the atari_NCR5380.c driver fork can be made redundant.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c  |  170 +++-
 drivers/scsi/arm/cumana_1.c |3 
 drivers/scsi/arm/oak.c  |3 
 drivers/scsi/dmx3191d.c |1 
 drivers/scsi/dtc.c  |2 
 drivers/scsi/dtc.h  |1 
 drivers/scsi/g_NCR5380.c|2 
 drivers/scsi/g_NCR5380.h|1 
 drivers/scsi/mac_scsi.c |3 
 drivers/scsi/pas16.c|2 
 drivers/scsi/pas16.h|1 
 drivers/scsi/t128.c |2 
 drivers/scsi/t128.h |1 
 13 files changed, 152 insertions(+), 40 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:19.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:20.0 +1100
@@ -31,9 +31,6 @@
 
 /*
  * Further development / testing that should be done :
- * 1.  Cleanup the NCR5380_transfer_dma function and DMA operation complete
- * code so that everything does the same thing that's done at the
- * end of a pseudo-DMA read operation.
  *
  * 4.  Test SCSI-II tagged queueing (I have no devices which support
  * tagged queueing)
@@ -117,6 +114,8 @@
  *
  * PSEUDO_DMA - if defined, PSEUDO DMA is used during the data transfer phases.
  *
+ * REAL_DMA - if defined, REAL DMA is used during the data transfer phases.
+ *
  * These macros MUST be defined :
  *
  * NCR5380_read(register)  - read from the specified register
@@ -801,6 +800,72 @@ static void NCR5380_main(struct work_str
} while (!done);
 }
 
+/*
+ * NCR5380_dma_complete - finish DMA transfer
+ * @instance: the scsi host instance
+ *
+ * Called by the interrupt handler when DMA finishes or a phase
+ * mismatch occurs (which would end the DMA transfer).
+ */
+
+static void NCR5380_dma_complete(struct Scsi_Host *instance)
+{
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
+   int transferred;
+   unsigned char **data;
+   int *count;
+   int saved_data = 0, overrun = 0;
+   unsigned char p;
+
+   if (hostdata->read_overruns) {
+   p = hostdata->connected->SCp.phase;
+   if (p & SR_IO) {
+   udelay(10);
+   if ((NCR5380_read(BUS_AND_STATUS_REG) &
+(BASR_PHASE_MATCH | BASR_ACK)) ==
+   (BASR_PHASE_MATCH | BASR_ACK)) {
+   saved_data = NCR5380_read(INPUT_DATA_REG);
+   overrun = 1;
+   dsprintk(NDEBUG_DMA, instance, "read overrun 
handled\n");
+   }
+   }
+   }
+
+   NCR5380_write(MODE_REG, MR_BASE);
+   NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
+   NCR5380_read(RESET_PARITY_INTERRUPT_REG);
+
+   transferred = hostdata->dma_len - NCR5380_dma_residual(instance);
+   hostdata->dma_len = 0;
+
+   data = (unsigned char **)>connected->SCp.ptr;
+   count = >connected->SCp.this_residual;
+   *data += transferred;
+   *count -= transferred;
+
+   if (hostdata->read_overruns) {
+   int cnt, toPIO;
+
+   if ((NCR5380_read(STATUS_REG) & PHASE_MASK) == p && (p & 
SR_IO)) {
+   cnt = toPIO = hostdata->read_overruns;
+   if (overrun) {
+   dsprintk(NDEBUG_DMA, instance,
+"Got an input overrun, using saved 
byte\n");
+   *(*data)++ = saved_data;
+   (*count)--;
+   cnt--;
+   toPIO--;
+   }
+   if (toPIO > 0) {
+   dsprintk(NDEBUG_DMA, instance,
+"Doing %d byte PIO to 0x%p\n", cnt, 
*data);
+   NCR5380_transfer_pio(instance, , , data);
+   *count -= toPIO - cnt;
+   }
+   }
+   }
+}
+
 #ifndef DONT_USE_INTR
 
 /**
@@ -855,7 +920,22 @@ static irqreturn_t NCR5380_intr(int irq,
dsprintk(NDEBUG_INTR, instance, "IRQ %d, BASR 0x%02x, SR 
0x%02x, MR 0x%02x\n",
 irq, basr, sr, mr);
 
-   if ((NCR5380_read(CURRENT_SCSI_DATA_REG) & hostdata->id_mask) &&
+   if ((mr & MR_DMA_MODE) || (mr & MR_MONITOR_BSY)) {
+   /* Probably End of DMA, Phase Mismatch or Loss of BSY.
+* We ack IRQ after clearing Mode Register. Workarounds
+* for End of DMA errata need to happen in DMA Mode.
+   

[PATCH v2 08/22] ncr5380: Use DMA hooks for PDMA

[Finn Thain]

Those wrapper drivers which use DMA define the REAL_DMA macro and
those which use pseudo DMA define PSEUDO_DMA. These macros need to be
removed for a number of reasons, not least of which is to have drivers
share more code.

Redefine the PDMA send and receive hooks as DMA setup hooks, so that the
DMA code can be shared by all 5380 wrapper drivers. This will help to
reunify the forked core driver.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c  |   10 ++
 drivers/scsi/arm/cumana_1.c |   10 ++
 drivers/scsi/arm/oak.c  |   10 ++
 drivers/scsi/dmx3191d.c |4 ++--
 drivers/scsi/dtc.c  |6 --
 drivers/scsi/dtc.h  |2 ++
 drivers/scsi/g_NCR5380.c|   10 ++
 drivers/scsi/g_NCR5380.h|4 ++--
 drivers/scsi/mac_scsi.c |5 ++---
 drivers/scsi/pas16.c|   14 --
 drivers/scsi/pas16.h|2 ++
 drivers/scsi/t128.c |   12 ++--
 drivers/scsi/t128.h |2 ++
 13 files changed, 50 insertions(+), 41 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:14.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:15.0 +1100
@@ -127,17 +127,11 @@
  * specific implementation of the NCR5380
  *
  * Either real DMA *or* pseudo DMA may be implemented
- * Note that the DMA setup functions should return the number of bytes
- * that they were able to program the controller for.
  *
  * NCR5380_dma_write_setup(instance, src, count) - initialize
  * NCR5380_dma_read_setup(instance, dst, count) - initialize
  * NCR5380_dma_residual(instance); - residual count
  *
- * PSEUDO functions :
- * NCR5380_pwrite(instance, src, count)
- * NCR5380_pread(instance, dst, count);
- *
  * The generic driver is initialized by calling NCR5380_init(instance),
  * after setting the appropriate host specific fields and ID.  If the
  * driver wishes to autoprobe for an IRQ line, the NCR5380_probe_irq(instance,
@@ -1511,7 +1505,7 @@ static int NCR5380_transfer_dma(struct S
  */
 
if (p & SR_IO) {
-   foo = NCR5380_pread(instance, d,
+   foo = NCR5380_dma_recv_setup(instance, d,
hostdata->flags & FLAG_DMA_FIXUP ? c - 1 : c);
if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
@@ -1542,7 +1536,7 @@ static int NCR5380_transfer_dma(struct S
d[c - 1] = NCR5380_read(INPUT_DATA_REG);
}
} else {
-   foo = NCR5380_pwrite(instance, d, c);
+   foo = NCR5380_dma_send_setup(instance, d, c);
if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
 * Wait for the last byte to be sent.  If REQ is being 
asserted for
Index: linux/drivers/scsi/arm/cumana_1.c
===
--- linux.orig/drivers/scsi/arm/cumana_1.c  2016-03-16 14:18:11.0 
+1100
+++ linux/drivers/scsi/arm/cumana_1.c   2016-03-16 14:18:15.0 +1100
@@ -18,6 +18,8 @@
 #define NCR5380_write(reg, value)  cumanascsi_write(instance, reg, value)
 
 #define NCR5380_dma_xfer_len(instance, cmd, phase) (cmd->transfersize)
+#define NCR5380_dma_recv_setup cumanascsi_pread
+#define NCR5380_dma_send_setup cumanascsi_pwrite
 
 #define NCR5380_intr   cumanascsi_intr
 #define NCR5380_queue_command  cumanascsi_queue_command
@@ -39,8 +41,8 @@ void cumanascsi_setup(char *str, int *in
 #define L(v)   (((v)<<16)|((v) & 0x))
 #define H(v)   (((v)>>16)|((v) & 0x))
 
-static inline int
-NCR5380_pwrite(struct Scsi_Host *host, unsigned char *addr, int len)
+static inline int cumanascsi_pwrite(struct Scsi_Host *host,
+unsigned char *addr, int len)
 {
   unsigned long *laddr;
   void __iomem *dma = priv(host)->dma + 0x2000;
@@ -102,8 +104,8 @@ end:
   return len;
 }
 
-static inline int
-NCR5380_pread(struct Scsi_Host *host, unsigned char *addr, int len)
+static inline int cumanascsi_pread(struct Scsi_Host *host,
+   unsigned char *addr, int len)
 {
   unsigned long *laddr;
   void __iomem *dma = priv(host)->dma + 0x2000;
Index: linux/drivers/scsi/arm/oak.c
===
--- linux.orig/drivers/scsi/arm/oak.c   2016-03-16 14:18:11.0 +1100
+++ linux/drivers/scsi/arm/oak.c2016-03-16 14:18:15.0 +1100
@@ -24,6 +24,8 @@
writeb(value, priv(instance)->base + ((reg) << 2))
 
 #define NCR5380_dma_xfer_len(instance, cmd, phase) (0)
+#define NCR5380_dma_recv_setup oakscsi_pread
+#define NCR5380_dma_send_setup oakscsi_pwrite
 
 #define NCR5380_queue_command  oakscsi_queue_command
 #define 

[PATCH v2 11/22] atari_scsi: Adopt NCR5380.c core driver

[Finn Thain]

Add support for the Atari ST DMA chip to the NCR5380.c core driver.
This code is copied from atari_NCR5380.c.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c|   32 
 drivers/scsi/atari_scsi.c |6 +++---
 2 files changed, 35 insertions(+), 3 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:20.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:24.0 +1100
@@ -29,6 +29,8 @@
  * Ronald van Cuijlenborg, Alan Cox and others.
  */
 
+/* Ported to Atari by Roman Hodek and others. */
+
 /*
  * Further development / testing that should be done :
  *
@@ -141,6 +143,14 @@
 #define NCR5380_io_delay(x)
 #endif
 
+#ifndef NCR5380_acquire_dma_irq
+#define NCR5380_acquire_dma_irq(x) (1)
+#endif
+
+#ifndef NCR5380_release_dma_irq
+#define NCR5380_release_dma_irq(x)
+#endif
+
 static int do_abort(struct Scsi_Host *);
 static void do_reset(struct Scsi_Host *);
 
@@ -658,6 +668,9 @@ static int NCR5380_queue_command(struct
 
cmd->result = 0;
 
+   if (!NCR5380_acquire_dma_irq(instance))
+   return SCSI_MLQUEUE_HOST_BUSY;
+
spin_lock_irqsave(>lock, flags);
 
/*
@@ -682,6 +695,19 @@ static int NCR5380_queue_command(struct
return 0;
 }
 
+static inline void maybe_release_dma_irq(struct Scsi_Host *instance)
+{
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
+
+   /* Caller does the locking needed to set & test these data atomically */
+   if (list_empty(>disconnected) &&
+   list_empty(>unissued) &&
+   list_empty(>autosense) &&
+   !hostdata->connected &&
+   !hostdata->selecting)
+   NCR5380_release_dma_irq(instance);
+}
+
 /**
  * dequeue_next_cmd - dequeue a command for processing
  * @instance: the scsi host instance
@@ -783,6 +809,7 @@ static void NCR5380_main(struct work_str
 
if (!NCR5380_select(instance, cmd)) {
dsprintk(NDEBUG_MAIN, instance, "main: select 
complete\n");
+   maybe_release_dma_irq(instance);
} else {
dsprintk(NDEBUG_MAIN | NDEBUG_QUEUES, instance,
 "main: select failed, returning %p to 
queue\n", cmd);
@@ -1828,6 +1855,8 @@ static void NCR5380_information_transfer
 
/* Enable reselect interrupts */
NCR5380_write(SELECT_ENABLE_REG, 
hostdata->id_mask);
+
+   maybe_release_dma_irq(instance);
return;
case MESSAGE_REJECT:
/* Accept message by clearing ACK */
@@ -1963,6 +1992,7 @@ static void NCR5380_information_transfer
hostdata->connected = NULL;
cmd->result = DID_ERROR << 16;
complete_cmd(instance, cmd);
+   maybe_release_dma_irq(instance);
NCR5380_write(SELECT_ENABLE_REG, 
hostdata->id_mask);
return;
}
@@ -2256,6 +2286,7 @@ out:
dsprintk(NDEBUG_ABORT, instance, "abort: successfully aborted 
%p\n", cmd);
 
queue_work(hostdata->work_q, >main_task);
+   maybe_release_dma_irq(instance);
spin_unlock_irqrestore(>lock, flags);
 
return result;
@@ -2336,6 +2367,7 @@ static int NCR5380_bus_reset(struct scsi
hostdata->dma_len = 0;
 
queue_work(hostdata->work_q, >main_task);
+   maybe_release_dma_irq(instance);
spin_unlock_irqrestore(>lock, flags);
 
return SUCCESS;
Index: linux/drivers/scsi/atari_scsi.c
===
--- linux.orig/drivers/scsi/atari_scsi.c2016-03-16 14:18:19.0 
+1100
+++ linux/drivers/scsi/atari_scsi.c 2016-03-16 14:18:24.0 +1100
@@ -99,9 +99,9 @@
 #define NCR5380_abort   atari_scsi_abort
 #define NCR5380_infoatari_scsi_info
 
-#define NCR5380_dma_read_setup(instance, data, count) \
+#define NCR5380_dma_recv_setup(instance, data, count) \
 atari_scsi_dma_setup(instance, data, count, 0)
-#define NCR5380_dma_write_setup(instance, data, count) \
+#define NCR5380_dma_send_setup(instance, data, count) \
 atari_scsi_dma_setup(instance, data, count, 1)
 #define NCR5380_dma_residual(instance) \
 atari_scsi_dma_residual(instance)
@@ -715,7 +715,7 @@ static void atari_scsi_falcon_reg_write(
 }
 
 
-#include "atari_NCR5380.c"
+#include 

[PATCH v2 12/22] sun3_scsi: Adopt NCR5380.c core driver

[Finn Thain]

Add support for the custom Sun 3 DMA logic to the NCR5380.c core driver.
This code is copied from atari_NCR5380.c.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---

The Sun 3 DMA code is still configured by macros. I have simplified things
slightly but I have avoided more ambitious refactoring. It's not clear to
me what that should look like and I can't test sun3_scsi anyway. At least
this permits the removal of atari_NCR5380.c.

---
 drivers/scsi/NCR5380.c   |  131 +++
 drivers/scsi/sun3_scsi.c |8 +-
 2 files changed, 124 insertions(+), 15 deletions(-)

Index: linux/drivers/scsi/sun3_scsi.c
===
--- linux.orig/drivers/scsi/sun3_scsi.c 2016-03-16 14:18:07.0 +1100
+++ linux/drivers/scsi/sun3_scsi.c  2016-03-16 14:18:25.0 +1100
@@ -54,10 +54,8 @@
 #define NCR5380_abort   sun3scsi_abort
 #define NCR5380_infosun3scsi_info
 
-#define NCR5380_dma_read_setup(instance, data, count) \
-sun3scsi_dma_setup(instance, data, count, 0)
-#define NCR5380_dma_write_setup(instance, data, count) \
-sun3scsi_dma_setup(instance, data, count, 1)
+#define NCR5380_dma_recv_setup(instance, data, count) (count)
+#define NCR5380_dma_send_setup(instance, data, count) (count)
 #define NCR5380_dma_residual(instance) \
 sun3scsi_dma_residual(instance)
 #define NCR5380_dma_xfer_len(instance, cmd, phase) \
@@ -406,7 +404,7 @@ static int sun3scsi_dma_finish(int write
 
 }

-#include "atari_NCR5380.c"
+#include "NCR5380.c"
 
 #ifdef SUN3_SCSI_VME
 #define SUN3_SCSI_NAME  "Sun3 NCR5380 VME SCSI"
Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:24.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:25.0 +1100
@@ -31,6 +31,8 @@
 
 /* Ported to Atari by Roman Hodek and others. */
 
+/* Adapted for the Sun 3 by Sam Creasey. */
+
 /*
  * Further development / testing that should be done :
  *
@@ -858,6 +860,23 @@ static void NCR5380_dma_complete(struct
}
}
 
+#ifdef CONFIG_SUN3
+   if ((sun3scsi_dma_finish(rq_data_dir(hostdata->connected->request {
+   pr_err("scsi%d: overrun in UDC counter -- not prepared to deal 
with this!\n",
+  instance->host_no);
+   BUG();
+   }
+
+   if ((NCR5380_read(BUS_AND_STATUS_REG) & (BASR_PHASE_MATCH | BASR_ACK)) 
==
+   (BASR_PHASE_MATCH | BASR_ACK)) {
+   pr_err("scsi%d: BASR %02x\n", instance->host_no,
+  NCR5380_read(BUS_AND_STATUS_REG));
+   pr_err("scsi%d: bus stuck in data phase -- probably a single 
byte overrun!\n",
+  instance->host_no);
+   BUG();
+   }
+#endif
+
NCR5380_write(MODE_REG, MR_BASE);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
NCR5380_read(RESET_PARITY_INTERRUPT_REG);
@@ -981,10 +1000,16 @@ static irqreturn_t NCR5380_intr(int irq,
NCR5380_read(RESET_PARITY_INTERRUPT_REG);
 
dsprintk(NDEBUG_INTR, instance, "unknown interrupt\n");
+#ifdef SUN3_SCSI_VME
+   dregs->csr |= CSR_DMA_ENABLE;
+#endif
}
handled = 1;
} else {
shost_printk(KERN_NOTICE, instance, "interrupt without IRQ 
bit\n");
+#ifdef SUN3_SCSI_VME
+   dregs->csr |= CSR_DMA_ENABLE;
+#endif
}
 
spin_unlock_irqrestore(>lock, flags);
@@ -1274,6 +1299,10 @@ static struct scsi_cmnd *NCR5380_select(
hostdata->connected = cmd;
hostdata->busy[cmd->device->id] |= 1 << cmd->device->lun;
 
+#ifdef SUN3_SCSI_VME
+   dregs->csr |= CSR_INTR;
+#endif
+
initialize_SCp(cmd);
 
cmd = NULL;
@@ -1557,6 +1586,11 @@ static int NCR5380_transfer_dma(struct S
dsprintk(NDEBUG_DMA, instance, "initializing DMA %s: length %d, address 
%p\n",
 (p & SR_IO) ? "receive" : "send", c, d);
 
+#ifdef CONFIG_SUN3
+   /* send start chain */
+   sun3scsi_dma_start(c, *data);
+#endif
+
NCR5380_write(TARGET_COMMAND_REG, PHASE_SR_TO_TCR(p));
NCR5380_write(MODE_REG, MR_BASE | MR_DMA_MODE | MR_MONITOR_BSY |
MR_ENABLE_EOP_INTR);
@@ -1577,6 +1611,7 @@ static int NCR5380_transfer_dma(struct S
 */
 
if (p & SR_IO) {
+   NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
NCR5380_io_delay(1);
NCR5380_write(START_DMA_INITIATOR_RECEIVE_REG, 0);
} else {
@@ -1587,6 +1622,13 @@ static int NCR5380_transfer_dma(struct S
NCR5380_io_delay(1);
}
 
+#ifdef CONFIG_SUN3
+#ifdef SUN3_SCSI_VME
+   dregs->csr |= CSR_DMA_ENABLE;
+#endif
+   

[PATCH v2 07/22] ncr5380: Remove BOARD_REQUIRES_NO_DELAY macro

[Finn Thain]

The io_recovery_delay macro is intended to insert a microsecond delay
between the chip register accesses that begin a DMA operation. This
is reportedly needed for some ISA boards.

Reverse the sense of the macro test so that in the common case,
where no delay is required, drivers need not define the macro.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c   |   18 --
 drivers/scsi/dtc.h   |2 ++
 drivers/scsi/g_NCR5380.h |2 ++
 drivers/scsi/t128.h  |2 ++
 4 files changed, 14 insertions(+), 10 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:11.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:14.0 +1100
@@ -39,12 +39,6 @@
  * tagged queueing)
  */
 
-#ifdef BOARD_REQUIRES_NO_DELAY
-#define io_recovery_delay(x)
-#else
-#define io_recovery_delay(x)   udelay(x)
-#endif
-
 /*
  * Design
  *
@@ -150,6 +144,10 @@
  * possible) function may be used.
  */
 
+#ifndef NCR5380_io_delay
+#define NCR5380_io_delay(x)
+#endif
+
 static int do_abort(struct Scsi_Host *);
 static void do_reset(struct Scsi_Host *);
 
@@ -1468,14 +1466,14 @@ static int NCR5380_transfer_dma(struct S
 */
 
if (p & SR_IO) {
-   io_recovery_delay(1);
+   NCR5380_io_delay(1);
NCR5380_write(START_DMA_INITIATOR_RECEIVE_REG, 0);
} else {
-   io_recovery_delay(1);
+   NCR5380_io_delay(1);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE | 
ICR_ASSERT_DATA);
-   io_recovery_delay(1);
+   NCR5380_io_delay(1);
NCR5380_write(START_DMA_SEND_REG, 0);
-   io_recovery_delay(1);
+   NCR5380_io_delay(1);
}
 
 /*
Index: linux/drivers/scsi/dtc.h
===
--- linux.orig/drivers/scsi/dtc.h   2016-03-16 14:18:11.0 +1100
+++ linux/drivers/scsi/dtc.h2016-03-16 14:18:14.0 +1100
@@ -28,6 +28,8 @@
 #define NCR5380_bus_reset  dtc_bus_reset
 #define NCR5380_info   dtc_info
 
+#define NCR5380_io_delay(x)udelay(x)
+
 /* 15 12 11 10
1001 1100   */
 
Index: linux/drivers/scsi/g_NCR5380.h
===
--- linux.orig/drivers/scsi/g_NCR5380.h 2016-03-16 14:18:11.0 +1100
+++ linux/drivers/scsi/g_NCR5380.h  2016-03-16 14:18:14.0 +1100
@@ -71,6 +71,8 @@
 #define NCR5380_pwrite generic_NCR5380_pwrite
 #define NCR5380_info generic_NCR5380_info
 
+#define NCR5380_io_delay(x)udelay(x)
+
 #define BOARD_NCR5380  0
 #define BOARD_NCR53C4001
 #define BOARD_NCR53C400A 2
Index: linux/drivers/scsi/t128.h
===
--- linux.orig/drivers/scsi/t128.h  2016-03-16 14:18:11.0 +1100
+++ linux/drivers/scsi/t128.h   2016-03-16 14:18:14.0 +1100
@@ -84,6 +84,8 @@
 #define NCR5380_bus_reset t128_bus_reset
 #define NCR5380_info t128_info
 
+#define NCR5380_io_delay(x)udelay(x)
+
 /* 15 14 12 10 7 5 3
1101 0100 1010 1000 */
 

[PATCH v2 12/22] sun3_scsi: Adopt NCR5380.c core driver

[Finn Thain]

Add support for the custom Sun 3 DMA logic to the NCR5380.c core driver.
This code is copied from atari_NCR5380.c.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---

The Sun 3 DMA code is still configured by macros. I have simplified things
slightly but I have avoided more ambitious refactoring. It's not clear to
me what that should look like and I can't test sun3_scsi anyway. At least
this permits the removal of atari_NCR5380.c.

---
 drivers/scsi/NCR5380.c   |  131 +++
 drivers/scsi/sun3_scsi.c |8 +-
 2 files changed, 124 insertions(+), 15 deletions(-)

Index: linux/drivers/scsi/sun3_scsi.c
===
--- linux.orig/drivers/scsi/sun3_scsi.c 2016-03-16 14:18:07.0 +1100
+++ linux/drivers/scsi/sun3_scsi.c  2016-03-16 14:18:25.0 +1100
@@ -54,10 +54,8 @@
 #define NCR5380_abort   sun3scsi_abort
 #define NCR5380_infosun3scsi_info
 
-#define NCR5380_dma_read_setup(instance, data, count) \
-sun3scsi_dma_setup(instance, data, count, 0)
-#define NCR5380_dma_write_setup(instance, data, count) \
-sun3scsi_dma_setup(instance, data, count, 1)
+#define NCR5380_dma_recv_setup(instance, data, count) (count)
+#define NCR5380_dma_send_setup(instance, data, count) (count)
 #define NCR5380_dma_residual(instance) \
 sun3scsi_dma_residual(instance)
 #define NCR5380_dma_xfer_len(instance, cmd, phase) \
@@ -406,7 +404,7 @@ static int sun3scsi_dma_finish(int write
 
 }

-#include "atari_NCR5380.c"
+#include "NCR5380.c"
 
 #ifdef SUN3_SCSI_VME
 #define SUN3_SCSI_NAME  "Sun3 NCR5380 VME SCSI"
Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:24.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:25.0 +1100
@@ -31,6 +31,8 @@
 
 /* Ported to Atari by Roman Hodek and others. */
 
+/* Adapted for the Sun 3 by Sam Creasey. */
+
 /*
  * Further development / testing that should be done :
  *
@@ -858,6 +860,23 @@ static void NCR5380_dma_complete(struct
}
}
 
+#ifdef CONFIG_SUN3
+   if ((sun3scsi_dma_finish(rq_data_dir(hostdata->connected->request {
+   pr_err("scsi%d: overrun in UDC counter -- not prepared to deal 
with this!\n",
+  instance->host_no);
+   BUG();
+   }
+
+   if ((NCR5380_read(BUS_AND_STATUS_REG) & (BASR_PHASE_MATCH | BASR_ACK)) 
==
+   (BASR_PHASE_MATCH | BASR_ACK)) {
+   pr_err("scsi%d: BASR %02x\n", instance->host_no,
+  NCR5380_read(BUS_AND_STATUS_REG));
+   pr_err("scsi%d: bus stuck in data phase -- probably a single 
byte overrun!\n",
+  instance->host_no);
+   BUG();
+   }
+#endif
+
NCR5380_write(MODE_REG, MR_BASE);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
NCR5380_read(RESET_PARITY_INTERRUPT_REG);
@@ -981,10 +1000,16 @@ static irqreturn_t NCR5380_intr(int irq,
NCR5380_read(RESET_PARITY_INTERRUPT_REG);
 
dsprintk(NDEBUG_INTR, instance, "unknown interrupt\n");
+#ifdef SUN3_SCSI_VME
+   dregs->csr |= CSR_DMA_ENABLE;
+#endif
}
handled = 1;
} else {
shost_printk(KERN_NOTICE, instance, "interrupt without IRQ 
bit\n");
+#ifdef SUN3_SCSI_VME
+   dregs->csr |= CSR_DMA_ENABLE;
+#endif
}
 
spin_unlock_irqrestore(>lock, flags);
@@ -1274,6 +1299,10 @@ static struct scsi_cmnd *NCR5380_select(
hostdata->connected = cmd;
hostdata->busy[cmd->device->id] |= 1 << cmd->device->lun;
 
+#ifdef SUN3_SCSI_VME
+   dregs->csr |= CSR_INTR;
+#endif
+
initialize_SCp(cmd);
 
cmd = NULL;
@@ -1557,6 +1586,11 @@ static int NCR5380_transfer_dma(struct S
dsprintk(NDEBUG_DMA, instance, "initializing DMA %s: length %d, address 
%p\n",
 (p & SR_IO) ? "receive" : "send", c, d);
 
+#ifdef CONFIG_SUN3
+   /* send start chain */
+   sun3scsi_dma_start(c, *data);
+#endif
+
NCR5380_write(TARGET_COMMAND_REG, PHASE_SR_TO_TCR(p));
NCR5380_write(MODE_REG, MR_BASE | MR_DMA_MODE | MR_MONITOR_BSY |
MR_ENABLE_EOP_INTR);
@@ -1577,6 +1611,7 @@ static int NCR5380_transfer_dma(struct S
 */
 
if (p & SR_IO) {
+   NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
NCR5380_io_delay(1);
NCR5380_write(START_DMA_INITIATOR_RECEIVE_REG, 0);
} else {
@@ -1587,6 +1622,13 @@ static int NCR5380_transfer_dma(struct S
NCR5380_io_delay(1);
}
 
+#ifdef CONFIG_SUN3
+#ifdef SUN3_SCSI_VME
+   dregs->csr |= CSR_DMA_ENABLE;
+#endif
+   sun3_dma_active = 1;
+#endif
+
if 

[PATCH v2 07/22] ncr5380: Remove BOARD_REQUIRES_NO_DELAY macro

[Finn Thain]

The io_recovery_delay macro is intended to insert a microsecond delay
between the chip register accesses that begin a DMA operation. This
is reportedly needed for some ISA boards.

Reverse the sense of the macro test so that in the common case,
where no delay is required, drivers need not define the macro.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c   |   18 --
 drivers/scsi/dtc.h   |2 ++
 drivers/scsi/g_NCR5380.h |2 ++
 drivers/scsi/t128.h  |2 ++
 4 files changed, 14 insertions(+), 10 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:11.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:14.0 +1100
@@ -39,12 +39,6 @@
  * tagged queueing)
  */
 
-#ifdef BOARD_REQUIRES_NO_DELAY
-#define io_recovery_delay(x)
-#else
-#define io_recovery_delay(x)   udelay(x)
-#endif
-
 /*
  * Design
  *
@@ -150,6 +144,10 @@
  * possible) function may be used.
  */
 
+#ifndef NCR5380_io_delay
+#define NCR5380_io_delay(x)
+#endif
+
 static int do_abort(struct Scsi_Host *);
 static void do_reset(struct Scsi_Host *);
 
@@ -1468,14 +1466,14 @@ static int NCR5380_transfer_dma(struct S
 */
 
if (p & SR_IO) {
-   io_recovery_delay(1);
+   NCR5380_io_delay(1);
NCR5380_write(START_DMA_INITIATOR_RECEIVE_REG, 0);
} else {
-   io_recovery_delay(1);
+   NCR5380_io_delay(1);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE | 
ICR_ASSERT_DATA);
-   io_recovery_delay(1);
+   NCR5380_io_delay(1);
NCR5380_write(START_DMA_SEND_REG, 0);
-   io_recovery_delay(1);
+   NCR5380_io_delay(1);
}
 
 /*
Index: linux/drivers/scsi/dtc.h
===
--- linux.orig/drivers/scsi/dtc.h   2016-03-16 14:18:11.0 +1100
+++ linux/drivers/scsi/dtc.h2016-03-16 14:18:14.0 +1100
@@ -28,6 +28,8 @@
 #define NCR5380_bus_reset  dtc_bus_reset
 #define NCR5380_info   dtc_info
 
+#define NCR5380_io_delay(x)udelay(x)
+
 /* 15 12 11 10
1001 1100   */
 
Index: linux/drivers/scsi/g_NCR5380.h
===
--- linux.orig/drivers/scsi/g_NCR5380.h 2016-03-16 14:18:11.0 +1100
+++ linux/drivers/scsi/g_NCR5380.h  2016-03-16 14:18:14.0 +1100
@@ -71,6 +71,8 @@
 #define NCR5380_pwrite generic_NCR5380_pwrite
 #define NCR5380_info generic_NCR5380_info
 
+#define NCR5380_io_delay(x)udelay(x)
+
 #define BOARD_NCR5380  0
 #define BOARD_NCR53C4001
 #define BOARD_NCR53C400A 2
Index: linux/drivers/scsi/t128.h
===
--- linux.orig/drivers/scsi/t128.h  2016-03-16 14:18:11.0 +1100
+++ linux/drivers/scsi/t128.h   2016-03-16 14:18:14.0 +1100
@@ -84,6 +84,8 @@
 #define NCR5380_bus_reset t128_bus_reset
 #define NCR5380_info t128_info
 
+#define NCR5380_io_delay(x)udelay(x)
+
 /* 15 14 12 10 7 5 3
1101 0100 1010 1000 */
 

[PATCH v2 11/22] atari_scsi: Adopt NCR5380.c core driver

[Finn Thain]

Add support for the Atari ST DMA chip to the NCR5380.c core driver.
This code is copied from atari_NCR5380.c.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c|   32 
 drivers/scsi/atari_scsi.c |6 +++---
 2 files changed, 35 insertions(+), 3 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:20.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:24.0 +1100
@@ -29,6 +29,8 @@
  * Ronald van Cuijlenborg, Alan Cox and others.
  */
 
+/* Ported to Atari by Roman Hodek and others. */
+
 /*
  * Further development / testing that should be done :
  *
@@ -141,6 +143,14 @@
 #define NCR5380_io_delay(x)
 #endif
 
+#ifndef NCR5380_acquire_dma_irq
+#define NCR5380_acquire_dma_irq(x) (1)
+#endif
+
+#ifndef NCR5380_release_dma_irq
+#define NCR5380_release_dma_irq(x)
+#endif
+
 static int do_abort(struct Scsi_Host *);
 static void do_reset(struct Scsi_Host *);
 
@@ -658,6 +668,9 @@ static int NCR5380_queue_command(struct
 
cmd->result = 0;
 
+   if (!NCR5380_acquire_dma_irq(instance))
+   return SCSI_MLQUEUE_HOST_BUSY;
+
spin_lock_irqsave(>lock, flags);
 
/*
@@ -682,6 +695,19 @@ static int NCR5380_queue_command(struct
return 0;
 }
 
+static inline void maybe_release_dma_irq(struct Scsi_Host *instance)
+{
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
+
+   /* Caller does the locking needed to set & test these data atomically */
+   if (list_empty(>disconnected) &&
+   list_empty(>unissued) &&
+   list_empty(>autosense) &&
+   !hostdata->connected &&
+   !hostdata->selecting)
+   NCR5380_release_dma_irq(instance);
+}
+
 /**
  * dequeue_next_cmd - dequeue a command for processing
  * @instance: the scsi host instance
@@ -783,6 +809,7 @@ static void NCR5380_main(struct work_str
 
if (!NCR5380_select(instance, cmd)) {
dsprintk(NDEBUG_MAIN, instance, "main: select 
complete\n");
+   maybe_release_dma_irq(instance);
} else {
dsprintk(NDEBUG_MAIN | NDEBUG_QUEUES, instance,
 "main: select failed, returning %p to 
queue\n", cmd);
@@ -1828,6 +1855,8 @@ static void NCR5380_information_transfer
 
/* Enable reselect interrupts */
NCR5380_write(SELECT_ENABLE_REG, 
hostdata->id_mask);
+
+   maybe_release_dma_irq(instance);
return;
case MESSAGE_REJECT:
/* Accept message by clearing ACK */
@@ -1963,6 +1992,7 @@ static void NCR5380_information_transfer
hostdata->connected = NULL;
cmd->result = DID_ERROR << 16;
complete_cmd(instance, cmd);
+   maybe_release_dma_irq(instance);
NCR5380_write(SELECT_ENABLE_REG, 
hostdata->id_mask);
return;
}
@@ -2256,6 +2286,7 @@ out:
dsprintk(NDEBUG_ABORT, instance, "abort: successfully aborted 
%p\n", cmd);
 
queue_work(hostdata->work_q, >main_task);
+   maybe_release_dma_irq(instance);
spin_unlock_irqrestore(>lock, flags);
 
return result;
@@ -2336,6 +2367,7 @@ static int NCR5380_bus_reset(struct scsi
hostdata->dma_len = 0;
 
queue_work(hostdata->work_q, >main_task);
+   maybe_release_dma_irq(instance);
spin_unlock_irqrestore(>lock, flags);
 
return SUCCESS;
Index: linux/drivers/scsi/atari_scsi.c
===
--- linux.orig/drivers/scsi/atari_scsi.c2016-03-16 14:18:19.0 
+1100
+++ linux/drivers/scsi/atari_scsi.c 2016-03-16 14:18:24.0 +1100
@@ -99,9 +99,9 @@
 #define NCR5380_abort   atari_scsi_abort
 #define NCR5380_infoatari_scsi_info
 
-#define NCR5380_dma_read_setup(instance, data, count) \
+#define NCR5380_dma_recv_setup(instance, data, count) \
 atari_scsi_dma_setup(instance, data, count, 0)
-#define NCR5380_dma_write_setup(instance, data, count) \
+#define NCR5380_dma_send_setup(instance, data, count) \
 atari_scsi_dma_setup(instance, data, count, 1)
 #define NCR5380_dma_residual(instance) \
 atari_scsi_dma_residual(instance)
@@ -715,7 +715,7 @@ static void atari_scsi_falcon_reg_write(
 }
 
 
-#include "atari_NCR5380.c"
+#include "NCR5380.c"
 
 static int 

[PATCH v2 09/22] ncr5380: Adopt uniform DMA setup convention

[Finn Thain]

Standardize the DMA setup hooks so that the DMA implementation in
atari_NCR5380.c can be reconciled with pseudo DMA implementation in
NCR5380.c.

Calls to NCR5380_dma_recv_setup() and NCR5380_dma_send_setup() return
a negative value on failure, zero on PDMA transfer success and a positive
byte count for DMA setup success.

This convention is not entirely new, but is now applied consistently.

Also remove a pointless Status Register access: the *phase assignment is
redundant because after NCR5380_transfer_dma() returns control to
NCR5380_information_transfer(), that routine then returns control
to NCR5380_main(), which means *phase is dead.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c  |   21 ++---
 drivers/scsi/arm/cumana_1.c |   10 --
 drivers/scsi/arm/oak.c  |4 ++--
 drivers/scsi/atari_scsi.c   |3 ---
 4 files changed, 20 insertions(+), 18 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:15.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:19.0 +1100
@@ -1431,7 +1431,7 @@ static int NCR5380_transfer_dma(struct S
register unsigned char p = *phase;
register unsigned char *d = *data;
unsigned char tmp;
-   int foo;
+   int result;
 
if ((tmp = (NCR5380_read(STATUS_REG) & PHASE_MASK)) != p) {
*phase = tmp;
@@ -1505,9 +1505,9 @@ static int NCR5380_transfer_dma(struct S
  */
 
if (p & SR_IO) {
-   foo = NCR5380_dma_recv_setup(instance, d,
+   result = NCR5380_dma_recv_setup(instance, d,
hostdata->flags & FLAG_DMA_FIXUP ? c - 1 : c);
-   if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
+   if (!result && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
 * The workaround was to transfer fewer bytes than we
 * intended to with the pseudo-DMA read function, wait 
for
@@ -1525,19 +1525,19 @@ static int NCR5380_transfer_dma(struct S
 
if (NCR5380_poll_politely(instance, BUS_AND_STATUS_REG,
  BASR_DRQ, BASR_DRQ, HZ) < 0) {
-   foo = -1;
+   result = -1;
shost_printk(KERN_ERR, instance, "PDMA read: 
DRQ timeout\n");
}
if (NCR5380_poll_politely(instance, STATUS_REG,
  SR_REQ, 0, HZ) < 0) {
-   foo = -1;
+   result = -1;
shost_printk(KERN_ERR, instance, "PDMA read: 
!REQ timeout\n");
}
d[c - 1] = NCR5380_read(INPUT_DATA_REG);
}
} else {
-   foo = NCR5380_dma_send_setup(instance, d, c);
-   if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
+   result = NCR5380_dma_send_setup(instance, d, c);
+   if (!result && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
 * Wait for the last byte to be sent.  If REQ is being 
asserted for
 * the byte we're interested, we'll ACK it and it will 
go false.
@@ -1545,7 +1545,7 @@ static int NCR5380_transfer_dma(struct S
if (NCR5380_poll_politely2(instance,
 BUS_AND_STATUS_REG, BASR_DRQ, BASR_DRQ,
 BUS_AND_STATUS_REG, BASR_PHASE_MATCH, 0, HZ) < 0) {
-   foo = -1;
+   result = -1;
shost_printk(KERN_ERR, instance, "PDMA write: 
DRQ and phase timeout\n");
}
}
@@ -1555,8 +1555,7 @@ static int NCR5380_transfer_dma(struct S
NCR5380_read(RESET_PARITY_INTERRUPT_REG);
*data = d + c;
*count = 0;
-   *phase = NCR5380_read(STATUS_REG) & PHASE_MASK;
-   return foo;
+   return result;
 }
 
 /*
@@ -1652,7 +1651,7 @@ static void NCR5380_information_transfer
if (!cmd->device->borken)
transfersize = 
NCR5380_dma_xfer_len(instance, cmd, phase);
 
-   if (transfersize) {
+   if (transfersize > 0) {
len = transfersize;
if (NCR5380_transfer_dma(instance, 
,
, (unsigned char 
**)>SCp.ptr)) {
Index: linux/drivers/scsi/arm/cumana_1.c
===
--- 

[PATCH v2 09/22] ncr5380: Adopt uniform DMA setup convention

[Finn Thain]

Standardize the DMA setup hooks so that the DMA implementation in
atari_NCR5380.c can be reconciled with pseudo DMA implementation in
NCR5380.c.

Calls to NCR5380_dma_recv_setup() and NCR5380_dma_send_setup() return
a negative value on failure, zero on PDMA transfer success and a positive
byte count for DMA setup success.

This convention is not entirely new, but is now applied consistently.

Also remove a pointless Status Register access: the *phase assignment is
redundant because after NCR5380_transfer_dma() returns control to
NCR5380_information_transfer(), that routine then returns control
to NCR5380_main(), which means *phase is dead.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c  |   21 ++---
 drivers/scsi/arm/cumana_1.c |   10 --
 drivers/scsi/arm/oak.c  |4 ++--
 drivers/scsi/atari_scsi.c   |3 ---
 4 files changed, 20 insertions(+), 18 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:15.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:19.0 +1100
@@ -1431,7 +1431,7 @@ static int NCR5380_transfer_dma(struct S
register unsigned char p = *phase;
register unsigned char *d = *data;
unsigned char tmp;
-   int foo;
+   int result;
 
if ((tmp = (NCR5380_read(STATUS_REG) & PHASE_MASK)) != p) {
*phase = tmp;
@@ -1505,9 +1505,9 @@ static int NCR5380_transfer_dma(struct S
  */
 
if (p & SR_IO) {
-   foo = NCR5380_dma_recv_setup(instance, d,
+   result = NCR5380_dma_recv_setup(instance, d,
hostdata->flags & FLAG_DMA_FIXUP ? c - 1 : c);
-   if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
+   if (!result && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
 * The workaround was to transfer fewer bytes than we
 * intended to with the pseudo-DMA read function, wait 
for
@@ -1525,19 +1525,19 @@ static int NCR5380_transfer_dma(struct S
 
if (NCR5380_poll_politely(instance, BUS_AND_STATUS_REG,
  BASR_DRQ, BASR_DRQ, HZ) < 0) {
-   foo = -1;
+   result = -1;
shost_printk(KERN_ERR, instance, "PDMA read: 
DRQ timeout\n");
}
if (NCR5380_poll_politely(instance, STATUS_REG,
  SR_REQ, 0, HZ) < 0) {
-   foo = -1;
+   result = -1;
shost_printk(KERN_ERR, instance, "PDMA read: 
!REQ timeout\n");
}
d[c - 1] = NCR5380_read(INPUT_DATA_REG);
}
} else {
-   foo = NCR5380_dma_send_setup(instance, d, c);
-   if (!foo && (hostdata->flags & FLAG_DMA_FIXUP)) {
+   result = NCR5380_dma_send_setup(instance, d, c);
+   if (!result && (hostdata->flags & FLAG_DMA_FIXUP)) {
/*
 * Wait for the last byte to be sent.  If REQ is being 
asserted for
 * the byte we're interested, we'll ACK it and it will 
go false.
@@ -1545,7 +1545,7 @@ static int NCR5380_transfer_dma(struct S
if (NCR5380_poll_politely2(instance,
 BUS_AND_STATUS_REG, BASR_DRQ, BASR_DRQ,
 BUS_AND_STATUS_REG, BASR_PHASE_MATCH, 0, HZ) < 0) {
-   foo = -1;
+   result = -1;
shost_printk(KERN_ERR, instance, "PDMA write: 
DRQ and phase timeout\n");
}
}
@@ -1555,8 +1555,7 @@ static int NCR5380_transfer_dma(struct S
NCR5380_read(RESET_PARITY_INTERRUPT_REG);
*data = d + c;
*count = 0;
-   *phase = NCR5380_read(STATUS_REG) & PHASE_MASK;
-   return foo;
+   return result;
 }
 
 /*
@@ -1652,7 +1651,7 @@ static void NCR5380_information_transfer
if (!cmd->device->borken)
transfersize = 
NCR5380_dma_xfer_len(instance, cmd, phase);
 
-   if (transfersize) {
+   if (transfersize > 0) {
len = transfersize;
if (NCR5380_transfer_dma(instance, 
,
, (unsigned char 
**)>SCp.ptr)) {
Index: linux/drivers/scsi/arm/cumana_1.c
===
--- linux.orig/drivers/scsi/arm/cumana_1.c  2016-03-16 14:18:15.0 

[PATCH v2 22/22] mac_scsi: Fix pseudo DMA implementation

[Finn Thain]

Fix various issues: Comments about bus errors are incorrect. The
PDMA asm must return the size of the memory access that faulted so the
transfer count can be adjusted accordingly. A phase change may cause a
bus error but should not be treated as failure. A bus error does not
always imply a phase change and generally the transfer may continue.
Scatter/gather can't be used with PDMA due to overruns (which is a pity
because peak throughput seems to double with SG_ALL). Increase default
cmd_per_lun to avoid work item startup and shutdown overhead.

Signed-off-by: Finn Thain 

---

Changed since v1:
- Set the default cmd_per_lun to 4 based on test results.

---
 drivers/scsi/NCR5380.h  |2 
 drivers/scsi/mac_scsi.c |  212 ++--
 2 files changed, 119 insertions(+), 95 deletions(-)

Index: linux/drivers/scsi/mac_scsi.c
===
--- linux.orig/drivers/scsi/mac_scsi.c  2016-03-16 14:18:27.0 +1100
+++ linux/drivers/scsi/mac_scsi.c   2016-03-16 14:18:38.0 +1100
@@ -28,7 +28,8 @@
 
 /* Definitions for the core NCR5380 driver. */
 
-#define NCR5380_implementation_fields   unsigned char *pdma_base
+#define NCR5380_implementation_fields   unsigned char *pdma_base; \
+int pdma_residual
 
 #define NCR5380_read(reg)   macscsi_read(instance, reg)
 #define NCR5380_write(reg, value)   macscsi_write(instance, reg, value)
@@ -37,7 +38,7 @@
 macscsi_dma_xfer_len(instance, cmd)
 #define NCR5380_dma_recv_setup  macscsi_pread
 #define NCR5380_dma_send_setup  macscsi_pwrite
-#define NCR5380_dma_residual(instance)  (0)
+#define NCR5380_dma_residual(instance)  (hostdata->pdma_residual)
 
 #define NCR5380_intrmacscsi_intr
 #define NCR5380_queue_command   macscsi_queue_command
@@ -104,18 +105,9 @@ static int __init mac_scsi_setup(char *s
 __setup("mac5380=", mac_scsi_setup);
 #endif /* !MODULE */
 
-/* 
-   Pseudo-DMA: (Ove Edlund)
-   The code attempts to catch bus errors that occur if one for example
-   "trips over the cable".
-   XXX: Since bus errors in the PDMA routines never happen on my 
-   computer, the bus error code is untested. 
-   If the code works as intended, a bus error results in Pseudo-DMA 
-   being disabled, meaning that the driver switches to slow handshake.
-   If bus errors are NOT extremely rare, this has to be changed. 
-*/
+/* Pseudo DMA asm originally by Ove Edlund */
 
-#define CP_IO_TO_MEM(s,d,len)  \
+#define CP_IO_TO_MEM(s,d,n)\
 __asm__ __volatile__   \
 ("cmp.w  #4,%2\n"  \
  "bls8f\n" \
@@ -152,61 +144,73 @@ __asm__ __volatile__  
\
  " 9: \n"  \
  ".section .fixup,\"ax\"\n"\
  ".even\n" \
- "90: moveq.l #1, %2\n"\
+ "91: moveq.l #1, %2\n"\
+ "jra 9b\n"\
+ "94: moveq.l #4, %2\n"\
  "jra 9b\n"\
  ".previous\n" \
  ".section __ex_table,\"a\"\n" \
  "   .align 4\n"   \
- "   .long  1b,90b\n"  \
- "   .long  3b,90b\n"  \
- "   .long 31b,90b\n"  \
- "   .long 32b,90b\n"  \
- "   .long 33b,90b\n"  \
- "   .long 34b,90b\n"  \
- "   .long 35b,90b\n"  \
- "   .long 36b,90b\n"  \
- "   .long 37b,90b\n"  \
- "   .long  5b,90b\n"  \
- "   .long  7b,90b\n"  \
+ "   .long  1b,91b\n"  \
+ "   .long  3b,94b\n"  \
+ "   .long 31b,94b\n"  \
+ "   .long 32b,94b\n"  \
+ "   .long 33b,94b\n"  \
+ "   .long 34b,94b\n"  \
+ "   .long 35b,94b\n"  \
+ "   .long 36b,94b\n"  \
+ "   .long 37b,94b\n"  \
+ "   .long  5b,94b\n"  \
+ "   .long  7b,91b\n"  \
  ".previous"   \
- : "=a"(s), "=a"(d), "=d"(len) \
- : "0"(s), 

[PATCH v2 14/22] ncr5380: Reduce max_lun limit

[Finn Thain]

The driver has a limit of eight LUs because of the byte-sized bitfield
that is used for busy flags. That means the maximum LUN is 7. The default
is 8.

Signed-off-by: Finn Thain 

---

Changed since v1:
- Reduce shost->max_lun limit instead of adding 'MAX_LUN' limit.

---
 drivers/scsi/NCR5380.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:27.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:29.0 +1100
@@ -488,6 +488,8 @@ static int NCR5380_init(struct Scsi_Host
int i;
unsigned long deadline;
 
+   instance->max_lun = 7;
+
hostdata->host = instance;
hostdata->id_mask = 1 << instance->this_id;
hostdata->id_higher_mask = 0;

[PATCH v2 22/22] mac_scsi: Fix pseudo DMA implementation

[Finn Thain]

Fix various issues: Comments about bus errors are incorrect. The
PDMA asm must return the size of the memory access that faulted so the
transfer count can be adjusted accordingly. A phase change may cause a
bus error but should not be treated as failure. A bus error does not
always imply a phase change and generally the transfer may continue.
Scatter/gather can't be used with PDMA due to overruns (which is a pity
because peak throughput seems to double with SG_ALL). Increase default
cmd_per_lun to avoid work item startup and shutdown overhead.

Signed-off-by: Finn Thain 

---

Changed since v1:
- Set the default cmd_per_lun to 4 based on test results.

---
 drivers/scsi/NCR5380.h  |2 
 drivers/scsi/mac_scsi.c |  212 ++--
 2 files changed, 119 insertions(+), 95 deletions(-)

Index: linux/drivers/scsi/mac_scsi.c
===
--- linux.orig/drivers/scsi/mac_scsi.c  2016-03-16 14:18:27.0 +1100
+++ linux/drivers/scsi/mac_scsi.c   2016-03-16 14:18:38.0 +1100
@@ -28,7 +28,8 @@
 
 /* Definitions for the core NCR5380 driver. */
 
-#define NCR5380_implementation_fields   unsigned char *pdma_base
+#define NCR5380_implementation_fields   unsigned char *pdma_base; \
+int pdma_residual
 
 #define NCR5380_read(reg)   macscsi_read(instance, reg)
 #define NCR5380_write(reg, value)   macscsi_write(instance, reg, value)
@@ -37,7 +38,7 @@
 macscsi_dma_xfer_len(instance, cmd)
 #define NCR5380_dma_recv_setup  macscsi_pread
 #define NCR5380_dma_send_setup  macscsi_pwrite
-#define NCR5380_dma_residual(instance)  (0)
+#define NCR5380_dma_residual(instance)  (hostdata->pdma_residual)
 
 #define NCR5380_intrmacscsi_intr
 #define NCR5380_queue_command   macscsi_queue_command
@@ -104,18 +105,9 @@ static int __init mac_scsi_setup(char *s
 __setup("mac5380=", mac_scsi_setup);
 #endif /* !MODULE */
 
-/* 
-   Pseudo-DMA: (Ove Edlund)
-   The code attempts to catch bus errors that occur if one for example
-   "trips over the cable".
-   XXX: Since bus errors in the PDMA routines never happen on my 
-   computer, the bus error code is untested. 
-   If the code works as intended, a bus error results in Pseudo-DMA 
-   being disabled, meaning that the driver switches to slow handshake.
-   If bus errors are NOT extremely rare, this has to be changed. 
-*/
+/* Pseudo DMA asm originally by Ove Edlund */
 
-#define CP_IO_TO_MEM(s,d,len)  \
+#define CP_IO_TO_MEM(s,d,n)\
 __asm__ __volatile__   \
 ("cmp.w  #4,%2\n"  \
  "bls8f\n" \
@@ -152,61 +144,73 @@ __asm__ __volatile__  
\
  " 9: \n"  \
  ".section .fixup,\"ax\"\n"\
  ".even\n" \
- "90: moveq.l #1, %2\n"\
+ "91: moveq.l #1, %2\n"\
+ "jra 9b\n"\
+ "94: moveq.l #4, %2\n"\
  "jra 9b\n"\
  ".previous\n" \
  ".section __ex_table,\"a\"\n" \
  "   .align 4\n"   \
- "   .long  1b,90b\n"  \
- "   .long  3b,90b\n"  \
- "   .long 31b,90b\n"  \
- "   .long 32b,90b\n"  \
- "   .long 33b,90b\n"  \
- "   .long 34b,90b\n"  \
- "   .long 35b,90b\n"  \
- "   .long 36b,90b\n"  \
- "   .long 37b,90b\n"  \
- "   .long  5b,90b\n"  \
- "   .long  7b,90b\n"  \
+ "   .long  1b,91b\n"  \
+ "   .long  3b,94b\n"  \
+ "   .long 31b,94b\n"  \
+ "   .long 32b,94b\n"  \
+ "   .long 33b,94b\n"  \
+ "   .long 34b,94b\n"  \
+ "   .long 35b,94b\n"  \
+ "   .long 36b,94b\n"  \
+ "   .long 37b,94b\n"  \
+ "   .long  5b,94b\n"  \
+ "   .long  7b,91b\n"  \
  ".previous"   \
- : "=a"(s), "=a"(d), "=d"(len) \
- : "0"(s), "1"(d), "2"(len)   

[PATCH v2 14/22] ncr5380: Reduce max_lun limit

[Finn Thain]

The driver has a limit of eight LUs because of the byte-sized bitfield
that is used for busy flags. That means the maximum LUN is 7. The default
is 8.

Signed-off-by: Finn Thain 

---

Changed since v1:
- Reduce shost->max_lun limit instead of adding 'MAX_LUN' limit.

---
 drivers/scsi/NCR5380.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:27.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:29.0 +1100
@@ -488,6 +488,8 @@ static int NCR5380_init(struct Scsi_Host
int i;
unsigned long deadline;
 
+   instance->max_lun = 7;
+
hostdata->host = instance;
hostdata->id_mask = 1 << instance->this_id;
hostdata->id_higher_mask = 0;

[PATCH v2 18/22] ncr5380: Remove DONT_USE_INTR and AUTOPROBE_IRQ macros

[Finn Thain]

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c   |   12 +---
 drivers/scsi/NCR5380.h   |4 
 drivers/scsi/arm/oak.c   |2 --
 drivers/scsi/dmx3191d.c  |2 --
 drivers/scsi/dtc.c   |   12 +++-
 drivers/scsi/g_NCR5380.c |2 --
 drivers/scsi/pas16.c |1 -
 drivers/scsi/t128.c  |1 -
 8 files changed, 4 insertions(+), 32 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:32.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:33.0 +1100
@@ -106,9 +106,6 @@
  * DIFFERENTIAL - if defined, NCR53c81 chips will use external differential
  * transceivers.
  *
- * DONT_USE_INTR - if defined, never use interrupts, even if we probe or
- * override-configure an IRQ.
- *
  * PSEUDO_DMA - if defined, PSEUDO DMA is used during the data transfer phases.
  *
  * REAL_DMA - if defined, REAL DMA is used during the data transfer phases.
@@ -464,9 +461,6 @@ static void prepare_info(struct Scsi_Hos
 hostdata->flags & FLAG_DMA_FIXUP ? "DMA_FIXUP " : "",
 hostdata->flags & FLAG_NO_PSEUDO_DMA ? "NO_PSEUDO_DMA " : "",
 hostdata->flags & FLAG_TOSHIBA_DELAY ? "TOSHIBA_DELAY "  : "",
-#ifdef AUTOPROBE_IRQ
-"AUTOPROBE_IRQ "
-#endif
 #ifdef DIFFERENTIAL
 "DIFFERENTIAL "
 #endif
@@ -915,8 +909,6 @@ static void NCR5380_dma_complete(struct
}
 }
 
-#ifndef DONT_USE_INTR
-
 /**
  * NCR5380_intr - generic NCR5380 irq handler
  * @irq: interrupt number
@@ -951,7 +943,7 @@ static void NCR5380_dma_complete(struct
  * the Busy Monitor interrupt is enabled together with DMA Mode.
  */
 
-static irqreturn_t NCR5380_intr(int irq, void *dev_id)
+static irqreturn_t __maybe_unused NCR5380_intr(int irq, void *dev_id)
 {
struct Scsi_Host *instance = dev_id;
struct NCR5380_hostdata *hostdata = shost_priv(instance);
@@ -1020,8 +1012,6 @@ static irqreturn_t NCR5380_intr(int irq,
return IRQ_RETVAL(handled);
 }
 
-#endif
-
 /*
  * Function : int NCR5380_select(struct Scsi_Host *instance,
  * struct scsi_cmnd *cmd)
Index: linux/drivers/scsi/NCR5380.h
===
--- linux.orig/drivers/scsi/NCR5380.h   2016-03-16 14:18:27.0 +1100
+++ linux/drivers/scsi/NCR5380.h2016-03-16 14:18:33.0 +1100
@@ -280,16 +280,12 @@ static void NCR5380_print(struct Scsi_Ho
 #define NCR5380_dprint_phase(flg, arg) do {} while (0)
 #endif
 
-#if defined(AUTOPROBE_IRQ)
 static int NCR5380_probe_irq(struct Scsi_Host *instance, int possible);
-#endif
 static int NCR5380_init(struct Scsi_Host *instance, int flags);
 static int NCR5380_maybe_reset_bus(struct Scsi_Host *);
 static void NCR5380_exit(struct Scsi_Host *instance);
 static void NCR5380_information_transfer(struct Scsi_Host *instance);
-#ifndef DONT_USE_INTR
 static irqreturn_t NCR5380_intr(int irq, void *dev_id);
-#endif
 static void NCR5380_main(struct work_struct *work);
 static const char *NCR5380_info(struct Scsi_Host *instance);
 static void NCR5380_reselect(struct Scsi_Host *instance);
Index: linux/drivers/scsi/arm/oak.c
===
--- linux.orig/drivers/scsi/arm/oak.c   2016-03-16 14:18:20.0 +1100
+++ linux/drivers/scsi/arm/oak.c2016-03-16 14:18:33.0 +1100
@@ -14,8 +14,6 @@
 
 #include 
 
-#define DONT_USE_INTR
-
 #define priv(host) ((struct NCR5380_hostdata 
*)(host)->hostdata)
 
 #define NCR5380_read(reg) \
Index: linux/drivers/scsi/dmx3191d.c
===
--- linux.orig/drivers/scsi/dmx3191d.c  2016-03-16 14:18:30.0 +1100
+++ linux/drivers/scsi/dmx3191d.c   2016-03-16 14:18:33.0 +1100
@@ -34,8 +34,6 @@
  * Definitions for the generic 5380 driver.
  */
 
-#define DONT_USE_INTR
-
 #define NCR5380_read(reg)  inb(instance->io_port + reg)
 #define NCR5380_write(reg, value)  outb(value, instance->io_port + reg)
 
Index: linux/drivers/scsi/dtc.c
===
--- linux.orig/drivers/scsi/dtc.c   2016-03-16 14:18:20.0 +1100
+++ linux/drivers/scsi/dtc.c2016-03-16 14:18:33.0 +1100
@@ -1,5 +1,3 @@
-#define DONT_USE_INTR
-
 /*
  * DTC 3180/3280 driver, by
  * Ray Van Tassle  ra...@comm.mot.com
@@ -53,7 +51,6 @@
 #include 
 
 #include "dtc.h"
-#define AUTOPROBE_IRQ
 #include "NCR5380.h"
 
 /*
@@ -243,9 +240,10 @@ found:
if (instance->irq == 255)
instance->irq = NO_IRQ;
 
-#ifndef DONT_USE_INTR
/* With interrupts enabled, it will sometimes hang when doing 
heavy
 * reads. So better not enable them until I finger it out. */

[PATCH v2 13/22] ncr5380: Remove disused atari_NCR5380.c core driver

[Finn Thain]

Now that atari_scsi and sun3_scsi have been converted to use the NCR5380.c
core driver, remove atari_NCR5380.c. Also remove the last vestiges of its
Tagged Command Queueing implementation from the wrapper drivers.

The TCQ support in atari_NCR5380.c is abandoned by this patch. It is not
merged into the remaining core driver because,

1) atari_scsi defines SUPPORT_TAGS but leaves FLAG_TAGGED_QUEUING disabled
by default, which indicates that it is mostly undesirable.

2) I'm told that it doesn't work correctly when enabled.

3) The algorithm does not make use of block layer tags which it will have
to do because scmd->tag is deprecated.

4) sun3_scsi doesn't define SUPPORT_TAGS at all, yet the the SUPPORT_TAGS
macro interacts with the CONFIG_SUN3 macro in 'interesting' ways.

5) Compile-time configuration with macros like SUPPORT_TAGS caused the
configuration space to explode, leading to untestable and unmaintainable
code that is too hard to reason about.

The merge_contiguous_buffers() code is also abandoned. This was unused
by sun3_scsi. Only atari_scsi used it and then only on TT, because only TT
supports scatter/gather. I suspect that the TT would work fine with
ENABLE_CLUSTERING instead. If someone can benchmark the difference then
perhaps the merge_contiguous_buffers() code can be be justified. Until
then we are better off without the extra complexity.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c   |   22 
 drivers/scsi/NCR5380.h   |   19 
 drivers/scsi/atari_NCR5380.c | 2632 ---
 drivers/scsi/atari_scsi.c|   11 
 drivers/scsi/mac_scsi.c  |8 
 drivers/scsi/sun3_scsi.c |   11 
 6 files changed, 4 insertions(+), 2699 deletions(-)

Index: linux/drivers/scsi/atari_scsi.c
===
--- linux.orig/drivers/scsi/atari_scsi.c2016-03-16 14:18:24.0 
+1100
+++ linux/drivers/scsi/atari_scsi.c 2016-03-16 14:18:27.0 +1100
@@ -87,9 +87,6 @@
 
 /* Definitions for the core NCR5380 driver. */
 
-#define SUPPORT_TAGS
-#define MAX_TAGS32
-
 #define NCR5380_implementation_fields   /* none */
 
 #define NCR5380_read(reg)   atari_scsi_reg_read(reg)
@@ -189,8 +186,6 @@ static int setup_cmd_per_lun = -1;
 module_param(setup_cmd_per_lun, int, 0);
 static int setup_sg_tablesize = -1;
 module_param(setup_sg_tablesize, int, 0);
-static int setup_use_tagged_queuing = -1;
-module_param(setup_use_tagged_queuing, int, 0);
 static int setup_hostid = -1;
 module_param(setup_hostid, int, 0);
 static int setup_toshiba_delay = -1;
@@ -479,8 +474,7 @@ static int __init atari_scsi_setup(char
setup_sg_tablesize = ints[3];
if (ints[0] >= 4)
setup_hostid = ints[4];
-   if (ints[0] >= 5)
-   setup_use_tagged_queuing = ints[5];
+   /* ints[5] (use_tagged_queuing) is ignored */
/* ints[6] (use_pdma) is ignored */
if (ints[0] >= 7)
setup_toshiba_delay = ints[7];
@@ -853,9 +847,6 @@ static int __init atari_scsi_probe(struc
instance->irq = irq->start;
 
host_flags |= IS_A_TT() ? 0 : FLAG_LATE_DMA_SETUP;
-#ifdef SUPPORT_TAGS
-   host_flags |= setup_use_tagged_queuing > 0 ? FLAG_TAGGED_QUEUING : 0;
-#endif
host_flags |= setup_toshiba_delay > 0 ? FLAG_TOSHIBA_DELAY : 0;
 
error = NCR5380_init(instance, host_flags);
Index: linux/drivers/scsi/sun3_scsi.c
===
--- linux.orig/drivers/scsi/sun3_scsi.c 2016-03-16 14:18:25.0 +1100
+++ linux/drivers/scsi/sun3_scsi.c  2016-03-16 14:18:27.0 +1100
@@ -41,9 +41,6 @@
 
 /* Definitions for the core NCR5380 driver. */
 
-/* #define SUPPORT_TAGS */
-/* #define MAX_TAGS 32 */
-
 #define NCR5380_implementation_fields   /* none */
 
 #define NCR5380_read(reg)   sun3scsi_read(reg)
@@ -75,10 +72,6 @@ static int setup_cmd_per_lun = -1;
 module_param(setup_cmd_per_lun, int, 0);
 static int setup_sg_tablesize = -1;
 module_param(setup_sg_tablesize, int, 0);
-#ifdef SUPPORT_TAGS
-static int setup_use_tagged_queuing = -1;
-module_param(setup_use_tagged_queuing, int, 0);
-#endif
 static int setup_hostid = -1;
 module_param(setup_hostid, int, 0);
 
@@ -512,10 +505,6 @@ static int __init sun3_scsi_probe(struct
instance->io_port = (unsigned long)ioaddr;
instance->irq = irq->start;
 
-#ifdef SUPPORT_TAGS
-   host_flags |= setup_use_tagged_queuing > 0 ? FLAG_TAGGED_QUEUING : 0;
-#endif
-
error = NCR5380_init(instance, host_flags);
if (error)
goto fail_init;
Index: linux/drivers/scsi/mac_scsi.c
===
--- linux.orig/drivers/scsi/mac_scsi.c  2016-03-16 14:18:20.0 +1100
+++ linux/drivers/scsi/mac_scsi.c   

[PATCH v2 18/22] ncr5380: Remove DONT_USE_INTR and AUTOPROBE_IRQ macros

[Finn Thain]

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c   |   12 +---
 drivers/scsi/NCR5380.h   |4 
 drivers/scsi/arm/oak.c   |2 --
 drivers/scsi/dmx3191d.c  |2 --
 drivers/scsi/dtc.c   |   12 +++-
 drivers/scsi/g_NCR5380.c |2 --
 drivers/scsi/pas16.c |1 -
 drivers/scsi/t128.c  |1 -
 8 files changed, 4 insertions(+), 32 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-03-16 14:18:32.0 +1100
+++ linux/drivers/scsi/NCR5380.c2016-03-16 14:18:33.0 +1100
@@ -106,9 +106,6 @@
  * DIFFERENTIAL - if defined, NCR53c81 chips will use external differential
  * transceivers.
  *
- * DONT_USE_INTR - if defined, never use interrupts, even if we probe or
- * override-configure an IRQ.
- *
  * PSEUDO_DMA - if defined, PSEUDO DMA is used during the data transfer phases.
  *
  * REAL_DMA - if defined, REAL DMA is used during the data transfer phases.
@@ -464,9 +461,6 @@ static void prepare_info(struct Scsi_Hos
 hostdata->flags & FLAG_DMA_FIXUP ? "DMA_FIXUP " : "",
 hostdata->flags & FLAG_NO_PSEUDO_DMA ? "NO_PSEUDO_DMA " : "",
 hostdata->flags & FLAG_TOSHIBA_DELAY ? "TOSHIBA_DELAY "  : "",
-#ifdef AUTOPROBE_IRQ
-"AUTOPROBE_IRQ "
-#endif
 #ifdef DIFFERENTIAL
 "DIFFERENTIAL "
 #endif
@@ -915,8 +909,6 @@ static void NCR5380_dma_complete(struct
}
 }
 
-#ifndef DONT_USE_INTR
-
 /**
  * NCR5380_intr - generic NCR5380 irq handler
  * @irq: interrupt number
@@ -951,7 +943,7 @@ static void NCR5380_dma_complete(struct
  * the Busy Monitor interrupt is enabled together with DMA Mode.
  */
 
-static irqreturn_t NCR5380_intr(int irq, void *dev_id)
+static irqreturn_t __maybe_unused NCR5380_intr(int irq, void *dev_id)
 {
struct Scsi_Host *instance = dev_id;
struct NCR5380_hostdata *hostdata = shost_priv(instance);
@@ -1020,8 +1012,6 @@ static irqreturn_t NCR5380_intr(int irq,
return IRQ_RETVAL(handled);
 }
 
-#endif
-
 /*
  * Function : int NCR5380_select(struct Scsi_Host *instance,
  * struct scsi_cmnd *cmd)
Index: linux/drivers/scsi/NCR5380.h
===
--- linux.orig/drivers/scsi/NCR5380.h   2016-03-16 14:18:27.0 +1100
+++ linux/drivers/scsi/NCR5380.h2016-03-16 14:18:33.0 +1100
@@ -280,16 +280,12 @@ static void NCR5380_print(struct Scsi_Ho
 #define NCR5380_dprint_phase(flg, arg) do {} while (0)
 #endif
 
-#if defined(AUTOPROBE_IRQ)
 static int NCR5380_probe_irq(struct Scsi_Host *instance, int possible);
-#endif
 static int NCR5380_init(struct Scsi_Host *instance, int flags);
 static int NCR5380_maybe_reset_bus(struct Scsi_Host *);
 static void NCR5380_exit(struct Scsi_Host *instance);
 static void NCR5380_information_transfer(struct Scsi_Host *instance);
-#ifndef DONT_USE_INTR
 static irqreturn_t NCR5380_intr(int irq, void *dev_id);
-#endif
 static void NCR5380_main(struct work_struct *work);
 static const char *NCR5380_info(struct Scsi_Host *instance);
 static void NCR5380_reselect(struct Scsi_Host *instance);
Index: linux/drivers/scsi/arm/oak.c
===
--- linux.orig/drivers/scsi/arm/oak.c   2016-03-16 14:18:20.0 +1100
+++ linux/drivers/scsi/arm/oak.c2016-03-16 14:18:33.0 +1100
@@ -14,8 +14,6 @@
 
 #include 
 
-#define DONT_USE_INTR
-
 #define priv(host) ((struct NCR5380_hostdata 
*)(host)->hostdata)
 
 #define NCR5380_read(reg) \
Index: linux/drivers/scsi/dmx3191d.c
===
--- linux.orig/drivers/scsi/dmx3191d.c  2016-03-16 14:18:30.0 +1100
+++ linux/drivers/scsi/dmx3191d.c   2016-03-16 14:18:33.0 +1100
@@ -34,8 +34,6 @@
  * Definitions for the generic 5380 driver.
  */
 
-#define DONT_USE_INTR
-
 #define NCR5380_read(reg)  inb(instance->io_port + reg)
 #define NCR5380_write(reg, value)  outb(value, instance->io_port + reg)
 
Index: linux/drivers/scsi/dtc.c
===
--- linux.orig/drivers/scsi/dtc.c   2016-03-16 14:18:20.0 +1100
+++ linux/drivers/scsi/dtc.c2016-03-16 14:18:33.0 +1100
@@ -1,5 +1,3 @@
-#define DONT_USE_INTR
-
 /*
  * DTC 3180/3280 driver, by
  * Ray Van Tassle  ra...@comm.mot.com
@@ -53,7 +51,6 @@
 #include 
 
 #include "dtc.h"
-#define AUTOPROBE_IRQ
 #include "NCR5380.h"
 
 /*
@@ -243,9 +240,10 @@ found:
if (instance->irq == 255)
instance->irq = NO_IRQ;
 
-#ifndef DONT_USE_INTR
/* With interrupts enabled, it will sometimes hang when doing 
heavy
 * reads. So better not enable them until I finger it out. */
+   instance->irq = NO_IRQ;
+
 

[PATCH v2 13/22] ncr5380: Remove disused atari_NCR5380.c core driver

[Finn Thain]

Now that atari_scsi and sun3_scsi have been converted to use the NCR5380.c
core driver, remove atari_NCR5380.c. Also remove the last vestiges of its
Tagged Command Queueing implementation from the wrapper drivers.

The TCQ support in atari_NCR5380.c is abandoned by this patch. It is not
merged into the remaining core driver because,

1) atari_scsi defines SUPPORT_TAGS but leaves FLAG_TAGGED_QUEUING disabled
by default, which indicates that it is mostly undesirable.

2) I'm told that it doesn't work correctly when enabled.

3) The algorithm does not make use of block layer tags which it will have
to do because scmd->tag is deprecated.

4) sun3_scsi doesn't define SUPPORT_TAGS at all, yet the the SUPPORT_TAGS
macro interacts with the CONFIG_SUN3 macro in 'interesting' ways.

5) Compile-time configuration with macros like SUPPORT_TAGS caused the
configuration space to explode, leading to untestable and unmaintainable
code that is too hard to reason about.

The merge_contiguous_buffers() code is also abandoned. This was unused
by sun3_scsi. Only atari_scsi used it and then only on TT, because only TT
supports scatter/gather. I suspect that the TT would work fine with
ENABLE_CLUSTERING instead. If someone can benchmark the difference then
perhaps the merge_contiguous_buffers() code can be be justified. Until
then we are better off without the extra complexity.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/NCR5380.c   |   22 
 drivers/scsi/NCR5380.h   |   19 
 drivers/scsi/atari_NCR5380.c | 2632 ---
 drivers/scsi/atari_scsi.c|   11 
 drivers/scsi/mac_scsi.c  |8 
 drivers/scsi/sun3_scsi.c |   11 
 6 files changed, 4 insertions(+), 2699 deletions(-)

Index: linux/drivers/scsi/atari_scsi.c
===
--- linux.orig/drivers/scsi/atari_scsi.c2016-03-16 14:18:24.0 
+1100
+++ linux/drivers/scsi/atari_scsi.c 2016-03-16 14:18:27.0 +1100
@@ -87,9 +87,6 @@
 
 /* Definitions for the core NCR5380 driver. */
 
-#define SUPPORT_TAGS
-#define MAX_TAGS32
-
 #define NCR5380_implementation_fields   /* none */
 
 #define NCR5380_read(reg)   atari_scsi_reg_read(reg)
@@ -189,8 +186,6 @@ static int setup_cmd_per_lun = -1;
 module_param(setup_cmd_per_lun, int, 0);
 static int setup_sg_tablesize = -1;
 module_param(setup_sg_tablesize, int, 0);
-static int setup_use_tagged_queuing = -1;
-module_param(setup_use_tagged_queuing, int, 0);
 static int setup_hostid = -1;
 module_param(setup_hostid, int, 0);
 static int setup_toshiba_delay = -1;
@@ -479,8 +474,7 @@ static int __init atari_scsi_setup(char
setup_sg_tablesize = ints[3];
if (ints[0] >= 4)
setup_hostid = ints[4];
-   if (ints[0] >= 5)
-   setup_use_tagged_queuing = ints[5];
+   /* ints[5] (use_tagged_queuing) is ignored */
/* ints[6] (use_pdma) is ignored */
if (ints[0] >= 7)
setup_toshiba_delay = ints[7];
@@ -853,9 +847,6 @@ static int __init atari_scsi_probe(struc
instance->irq = irq->start;
 
host_flags |= IS_A_TT() ? 0 : FLAG_LATE_DMA_SETUP;
-#ifdef SUPPORT_TAGS
-   host_flags |= setup_use_tagged_queuing > 0 ? FLAG_TAGGED_QUEUING : 0;
-#endif
host_flags |= setup_toshiba_delay > 0 ? FLAG_TOSHIBA_DELAY : 0;
 
error = NCR5380_init(instance, host_flags);
Index: linux/drivers/scsi/sun3_scsi.c
===
--- linux.orig/drivers/scsi/sun3_scsi.c 2016-03-16 14:18:25.0 +1100
+++ linux/drivers/scsi/sun3_scsi.c  2016-03-16 14:18:27.0 +1100
@@ -41,9 +41,6 @@
 
 /* Definitions for the core NCR5380 driver. */
 
-/* #define SUPPORT_TAGS */
-/* #define MAX_TAGS 32 */
-
 #define NCR5380_implementation_fields   /* none */
 
 #define NCR5380_read(reg)   sun3scsi_read(reg)
@@ -75,10 +72,6 @@ static int setup_cmd_per_lun = -1;
 module_param(setup_cmd_per_lun, int, 0);
 static int setup_sg_tablesize = -1;
 module_param(setup_sg_tablesize, int, 0);
-#ifdef SUPPORT_TAGS
-static int setup_use_tagged_queuing = -1;
-module_param(setup_use_tagged_queuing, int, 0);
-#endif
 static int setup_hostid = -1;
 module_param(setup_hostid, int, 0);
 
@@ -512,10 +505,6 @@ static int __init sun3_scsi_probe(struct
instance->io_port = (unsigned long)ioaddr;
instance->irq = irq->start;
 
-#ifdef SUPPORT_TAGS
-   host_flags |= setup_use_tagged_queuing > 0 ? FLAG_TAGGED_QUEUING : 0;
-#endif
-
error = NCR5380_init(instance, host_flags);
if (error)
goto fail_init;
Index: linux/drivers/scsi/mac_scsi.c
===
--- linux.orig/drivers/scsi/mac_scsi.c  2016-03-16 14:18:20.0 +1100
+++ linux/drivers/scsi/mac_scsi.c   2016-03-16 14:18:27.0 +1100
@@ -55,8 

[PATCH v2 04/22] atari_NCR5380: Remove DMA_MIN_SIZE macro

[Finn Thain]

Only the atari_scsi and sun3_scsi drivers define DMA_MIN_SIZE.
Both drivers also define NCR5380_dma_xfer_len, which means
DMA_MIN_SIZE can be removed from the core driver.

This removes another discrepancy between the two core drivers.

Signed-off-by: Finn Thain 

---

Changes since v1:
- Retain MIN_DMA_SIZE macro in wrapper drivers.

---
 drivers/scsi/atari_NCR5380.c |   16 
 drivers/scsi/atari_scsi.c|6 +-
 drivers/scsi/sun3_scsi.c |   19 +--
 3 files changed, 22 insertions(+), 19 deletions(-)

Index: linux/drivers/scsi/atari_NCR5380.c
===
--- linux.orig/drivers/scsi/atari_NCR5380.c 2016-03-16 14:18:05.0 
+1100
+++ linux/drivers/scsi/atari_NCR5380.c  2016-03-16 14:18:07.0 +1100
@@ -1857,12 +1857,11 @@ static void NCR5380_information_transfer
d = cmd->SCp.ptr;
}
/* this command setup for dma yet? */
-   if ((count >= DMA_MIN_SIZE) && 
(sun3_dma_setup_done != cmd)) {
-   if (cmd->request->cmd_type == 
REQ_TYPE_FS) {
-   sun3scsi_dma_setup(instance, d, 
count,
-  
rq_data_dir(cmd->request));
-   sun3_dma_setup_done = cmd;
-   }
+   if (sun3_dma_setup_done != cmd &&
+   sun3scsi_dma_xfer_len(count, cmd) > 0) {
+   sun3scsi_dma_setup(instance, d, count,
+  
rq_data_dir(cmd->request));
+   sun3_dma_setup_done = cmd;
}
 #ifdef SUN3_SCSI_VME
dregs->csr |= CSR_INTR;
@@ -1927,7 +1926,7 @@ static void NCR5380_information_transfer
 #endif
transfersize = 
NCR5380_dma_xfer_len(instance, cmd, phase);
 
-   if (transfersize >= DMA_MIN_SIZE) {
+   if (transfersize > 0) {
len = transfersize;
cmd->SCp.phase = phase;
if (NCR5380_transfer_dma(instance, 
,
@@ -2366,7 +2365,8 @@ static void NCR5380_reselect(struct Scsi
d = tmp->SCp.ptr;
}
/* setup this command for dma if not already */
-   if ((count >= DMA_MIN_SIZE) && (sun3_dma_setup_done != tmp)) {
+   if (sun3_dma_setup_done != tmp &&
+   sun3scsi_dma_xfer_len(count, tmp) > 0) {
sun3scsi_dma_setup(instance, d, count,
   rq_data_dir(tmp->request));
sun3_dma_setup_done = tmp;
Index: linux/drivers/scsi/atari_scsi.c
===
--- linux.orig/drivers/scsi/atari_scsi.c2016-03-16 14:18:05.0 
+1100
+++ linux/drivers/scsi/atari_scsi.c 2016-03-16 14:18:07.0 +1100
@@ -83,11 +83,12 @@
 
 #include 
 
+#define DMA_MIN_SIZE32
+
 /* Definitions for the core NCR5380 driver. */
 
 #define SUPPORT_TAGS
 #define MAX_TAGS32
-#define DMA_MIN_SIZE32
 
 #define NCR5380_implementation_fields   /* none */
 
@@ -605,6 +606,9 @@ static unsigned long atari_dma_xfer_len(
 {
unsigned long   possible_len, limit;
 
+   if (wanted_len < DMA_MIN_SIZE)
+   return 0;
+
if (IS_A_TT())
/* TT SCSI DMA can transfer arbitrary #bytes */
return wanted_len;
Index: linux/drivers/scsi/sun3_scsi.c
===
--- linux.orig/drivers/scsi/sun3_scsi.c 2016-03-16 14:18:05.0 +1100
+++ linux/drivers/scsi/sun3_scsi.c  2016-03-16 14:18:07.0 +1100
@@ -36,12 +36,12 @@
 #include 
 #include "sun3_scsi.h"
 
-/* Definitions for the core NCR5380 driver. */
-
-/* #define SUPPORT_TAGS */
 /* minimum number of bytes to do dma on */
 #define DMA_MIN_SIZE129
 
+/* Definitions for the core NCR5380 driver. */
+
+/* #define SUPPORT_TAGS */
 /* #define MAX_TAGS 32 */
 
 #define NCR5380_implementation_fields   /* none */
@@ -61,7 +61,7 @@
 #define NCR5380_dma_residual(instance) \
 sun3scsi_dma_residual(instance)
 #define NCR5380_dma_xfer_len(instance, cmd, phase) \
-sun3scsi_dma_xfer_len(cmd->SCp.this_residual, cmd, !((phase) & SR_IO))
+sun3scsi_dma_xfer_len(cmd->SCp.this_residual, cmd)
 
 #define NCR5380_acquire_dma_irq(instance)(1)
 #define 

[PATCH v2 00/22] ncr5380: Eliminate macros, reduce code duplication, fix bugs etc

[Finn Thain]

This patch series has more macro elimination and some tweaks to the
DMA hooks so that all the wrapper drivers can share the same core
DMA algorithm. This resolves the major discrepancies between the two
core drivers, which relate to code conditional on the REAL_DMA and
PSEUDO_DMA macros.

After all the wrapper drivers agree on the DMA hook api, the core driver
fork gets resolved. NCR5380.c is adopted by atari_scsi and sun3_scsi and
atari_NCR5380.c is then deleted.

Historically, the 5380 drivers suffered from over-use of conditional
compilation, which caused the compile-time configuration space to explode,
leading to core driver code that was practically untestable, unmaintainable
and difficult to reason about. It also prevented driver modules from
sharing object code.

Along with REAL_DMA, REAL_DMA_POLL and PSEUDO_DMA, most of the remaining
macros are also eradicated, such as CONFIG_SCSI_GENERIC_NCR53C400,
SUPPORT_TAGS, DONT_USE_INTR, AUTOPROBE_IRQ and BIOSPARAM.

Also in this patch series, some duplicated documentation is removed and
the PDMA implementation in mac_scsi finally gets fixed.

This patch series was tested by exercising the dmx3191d and mac_scsi modules
on suitable hardware. Help with driver testing on ISA and Atari hardware
is sought as I don't have any (likewise RiscPC ecards and Sun 3 hardware).

Changes since v1:
- Patch 4: don't remove MIN_DMA_SIZE macro from wrapper drivers.
- Patch 9: improve commit log entry and add 'Reviewed-by' tag.
- Patch 14: reduce shost->max_lun limit instead of adding MAX_LUN limit.
- Patches 20 and 22: set the default cmd_per_lun to 4.
- For the rest: add 'Reviewed-by' tag.

---
 Documentation/scsi/g_NCR5380.txt   |   17 
 Documentation/scsi/scsi-parameters.txt |   11 
 drivers/scsi/Kconfig   |   11 
 drivers/scsi/NCR5380.c |  657 +++-
 drivers/scsi/NCR5380.h |  143 -
 drivers/scsi/arm/cumana_1.c|   25 
 drivers/scsi/arm/oak.c |   22 
 drivers/scsi/atari_NCR5380.c   | 2676 -
 drivers/scsi/atari_scsi.c  |  144 -
 drivers/scsi/dmx3191d.c|   10 
 drivers/scsi/dtc.c |   27 
 drivers/scsi/dtc.h |7 
 drivers/scsi/g_NCR5380.c   |  143 -
 drivers/scsi/g_NCR5380.h   |   26 
 drivers/scsi/mac_scsi.c|  241 +-
 drivers/scsi/pas16.c   |   27 
 drivers/scsi/pas16.h   |5 
 drivers/scsi/sun3_scsi.c   |   47 
 drivers/scsi/t128.c|   19 
 drivers/scsi/t128.h|7 
 20 files changed, 634 insertions(+), 3631 deletions(-)

[PATCH v2 04/22] atari_NCR5380: Remove DMA_MIN_SIZE macro

[Finn Thain]

Only the atari_scsi and sun3_scsi drivers define DMA_MIN_SIZE.
Both drivers also define NCR5380_dma_xfer_len, which means
DMA_MIN_SIZE can be removed from the core driver.

This removes another discrepancy between the two core drivers.

Signed-off-by: Finn Thain 

---

Changes since v1:
- Retain MIN_DMA_SIZE macro in wrapper drivers.

---
 drivers/scsi/atari_NCR5380.c |   16 
 drivers/scsi/atari_scsi.c|6 +-
 drivers/scsi/sun3_scsi.c |   19 +--
 3 files changed, 22 insertions(+), 19 deletions(-)

Index: linux/drivers/scsi/atari_NCR5380.c
===
--- linux.orig/drivers/scsi/atari_NCR5380.c 2016-03-16 14:18:05.0 
+1100
+++ linux/drivers/scsi/atari_NCR5380.c  2016-03-16 14:18:07.0 +1100
@@ -1857,12 +1857,11 @@ static void NCR5380_information_transfer
d = cmd->SCp.ptr;
}
/* this command setup for dma yet? */
-   if ((count >= DMA_MIN_SIZE) && 
(sun3_dma_setup_done != cmd)) {
-   if (cmd->request->cmd_type == 
REQ_TYPE_FS) {
-   sun3scsi_dma_setup(instance, d, 
count,
-  
rq_data_dir(cmd->request));
-   sun3_dma_setup_done = cmd;
-   }
+   if (sun3_dma_setup_done != cmd &&
+   sun3scsi_dma_xfer_len(count, cmd) > 0) {
+   sun3scsi_dma_setup(instance, d, count,
+  
rq_data_dir(cmd->request));
+   sun3_dma_setup_done = cmd;
}
 #ifdef SUN3_SCSI_VME
dregs->csr |= CSR_INTR;
@@ -1927,7 +1926,7 @@ static void NCR5380_information_transfer
 #endif
transfersize = 
NCR5380_dma_xfer_len(instance, cmd, phase);
 
-   if (transfersize >= DMA_MIN_SIZE) {
+   if (transfersize > 0) {
len = transfersize;
cmd->SCp.phase = phase;
if (NCR5380_transfer_dma(instance, 
,
@@ -2366,7 +2365,8 @@ static void NCR5380_reselect(struct Scsi
d = tmp->SCp.ptr;
}
/* setup this command for dma if not already */
-   if ((count >= DMA_MIN_SIZE) && (sun3_dma_setup_done != tmp)) {
+   if (sun3_dma_setup_done != tmp &&
+   sun3scsi_dma_xfer_len(count, tmp) > 0) {
sun3scsi_dma_setup(instance, d, count,
   rq_data_dir(tmp->request));
sun3_dma_setup_done = tmp;
Index: linux/drivers/scsi/atari_scsi.c
===
--- linux.orig/drivers/scsi/atari_scsi.c2016-03-16 14:18:05.0 
+1100
+++ linux/drivers/scsi/atari_scsi.c 2016-03-16 14:18:07.0 +1100
@@ -83,11 +83,12 @@
 
 #include 
 
+#define DMA_MIN_SIZE32
+
 /* Definitions for the core NCR5380 driver. */
 
 #define SUPPORT_TAGS
 #define MAX_TAGS32
-#define DMA_MIN_SIZE32
 
 #define NCR5380_implementation_fields   /* none */
 
@@ -605,6 +606,9 @@ static unsigned long atari_dma_xfer_len(
 {
unsigned long   possible_len, limit;
 
+   if (wanted_len < DMA_MIN_SIZE)
+   return 0;
+
if (IS_A_TT())
/* TT SCSI DMA can transfer arbitrary #bytes */
return wanted_len;
Index: linux/drivers/scsi/sun3_scsi.c
===
--- linux.orig/drivers/scsi/sun3_scsi.c 2016-03-16 14:18:05.0 +1100
+++ linux/drivers/scsi/sun3_scsi.c  2016-03-16 14:18:07.0 +1100
@@ -36,12 +36,12 @@
 #include 
 #include "sun3_scsi.h"
 
-/* Definitions for the core NCR5380 driver. */
-
-/* #define SUPPORT_TAGS */
 /* minimum number of bytes to do dma on */
 #define DMA_MIN_SIZE129
 
+/* Definitions for the core NCR5380 driver. */
+
+/* #define SUPPORT_TAGS */
 /* #define MAX_TAGS 32 */
 
 #define NCR5380_implementation_fields   /* none */
@@ -61,7 +61,7 @@
 #define NCR5380_dma_residual(instance) \
 sun3scsi_dma_residual(instance)
 #define NCR5380_dma_xfer_len(instance, cmd, phase) \
-sun3scsi_dma_xfer_len(cmd->SCp.this_residual, cmd, !((phase) & SR_IO))
+sun3scsi_dma_xfer_len(cmd->SCp.this_residual, cmd)
 
 #define NCR5380_acquire_dma_irq(instance)(1)
 #define NCR5380_release_dma_irq(instance)

[PATCH v2 00/22] ncr5380: Eliminate macros, reduce code duplication, fix bugs etc

[Finn Thain]

This patch series has more macro elimination and some tweaks to the
DMA hooks so that all the wrapper drivers can share the same core
DMA algorithm. This resolves the major discrepancies between the two
core drivers, which relate to code conditional on the REAL_DMA and
PSEUDO_DMA macros.

After all the wrapper drivers agree on the DMA hook api, the core driver
fork gets resolved. NCR5380.c is adopted by atari_scsi and sun3_scsi and
atari_NCR5380.c is then deleted.

Historically, the 5380 drivers suffered from over-use of conditional
compilation, which caused the compile-time configuration space to explode,
leading to core driver code that was practically untestable, unmaintainable
and difficult to reason about. It also prevented driver modules from
sharing object code.

Along with REAL_DMA, REAL_DMA_POLL and PSEUDO_DMA, most of the remaining
macros are also eradicated, such as CONFIG_SCSI_GENERIC_NCR53C400,
SUPPORT_TAGS, DONT_USE_INTR, AUTOPROBE_IRQ and BIOSPARAM.

Also in this patch series, some duplicated documentation is removed and
the PDMA implementation in mac_scsi finally gets fixed.

This patch series was tested by exercising the dmx3191d and mac_scsi modules
on suitable hardware. Help with driver testing on ISA and Atari hardware
is sought as I don't have any (likewise RiscPC ecards and Sun 3 hardware).

Changes since v1:
- Patch 4: don't remove MIN_DMA_SIZE macro from wrapper drivers.
- Patch 9: improve commit log entry and add 'Reviewed-by' tag.
- Patch 14: reduce shost->max_lun limit instead of adding MAX_LUN limit.
- Patches 20 and 22: set the default cmd_per_lun to 4.
- For the rest: add 'Reviewed-by' tag.

---
 Documentation/scsi/g_NCR5380.txt   |   17 
 Documentation/scsi/scsi-parameters.txt |   11 
 drivers/scsi/Kconfig   |   11 
 drivers/scsi/NCR5380.c |  657 +++-
 drivers/scsi/NCR5380.h |  143 -
 drivers/scsi/arm/cumana_1.c|   25 
 drivers/scsi/arm/oak.c |   22 
 drivers/scsi/atari_NCR5380.c   | 2676 -
 drivers/scsi/atari_scsi.c  |  144 -
 drivers/scsi/dmx3191d.c|   10 
 drivers/scsi/dtc.c |   27 
 drivers/scsi/dtc.h |7 
 drivers/scsi/g_NCR5380.c   |  143 -
 drivers/scsi/g_NCR5380.h   |   26 
 drivers/scsi/mac_scsi.c|  241 +-
 drivers/scsi/pas16.c   |   27 
 drivers/scsi/pas16.h   |5 
 drivers/scsi/sun3_scsi.c   |   47 
 drivers/scsi/t128.c|   19 
 drivers/scsi/t128.h|7 
 20 files changed, 634 insertions(+), 3631 deletions(-)

[PATCH v2 20/22] atari_scsi: Set a reasonable default for cmd_per_lun

[Finn Thain]

This setting does not need to be conditional on Atari ST or TT.

Signed-off-by: Finn Thain 

---

Changed since v1:
- Set the default cmd_per_lun to 4 based on test results.

---
 drivers/scsi/atari_scsi.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Index: linux/drivers/scsi/atari_scsi.c
===
--- linux.orig/drivers/scsi/atari_scsi.c2016-03-16 14:18:27.0 
+1100
+++ linux/drivers/scsi/atari_scsi.c 2016-03-16 14:18:36.0 +1100
@@ -752,6 +752,7 @@ static struct scsi_host_template atari_s
.eh_abort_handler   = atari_scsi_abort,
.eh_bus_reset_handler   = atari_scsi_bus_reset,
.this_id= 7,
+   .cmd_per_lun= 4,
.use_clustering = DISABLE_CLUSTERING,
.cmd_size   = NCR5380_CMD_SIZE,
 };
@@ -788,11 +789,9 @@ static int __init atari_scsi_probe(struc
 */
if (ATARIHW_PRESENT(TT_SCSI)) {
atari_scsi_template.can_queue= 16;
-   atari_scsi_template.cmd_per_lun  = 8;
atari_scsi_template.sg_tablesize = SG_ALL;
} else {
atari_scsi_template.can_queue= 8;
-   atari_scsi_template.cmd_per_lun  = 1;
atari_scsi_template.sg_tablesize = SG_NONE;
}
 

[PATCH v2 21/22] atari_scsi: Allow can_queue to be increased for Falcon

[Finn Thain]

The benefit of limiting can_queue to 1 is that atari_scsi shares the
ST DMA chip more fairly with other drivers (e.g. falcon-ide).

Unfortunately, this can limit SCSI bus utilization. On systems without
IDE, atari_scsi should issue SCSI commands whenever it can arbitrate for
the bus. Make that possible by making can_queue configurable.

Signed-off-by: Finn Thain 
Reviewed-by: Hannes Reinecke 

---
 drivers/scsi/atari_scsi.c |   83 --
 1 file changed, 22 insertions(+), 61 deletions(-)

Index: linux/drivers/scsi/atari_scsi.c
===
--- linux.orig/drivers/scsi/atari_scsi.c2016-03-16 14:18:36.0 
+1100
+++ linux/drivers/scsi/atari_scsi.c 2016-03-16 14:18:37.0 +1100
@@ -14,55 +14,23 @@
  *
  */
 
-
-/**/
-/**/
-/* Notes for Falcon SCSI: */
-/* -- */
-/**/
-/* Since the Falcon SCSI uses the ST-DMA chip, that is shared among   */
-/* several device drivers, locking and unlocking the access to this   */
-/* chip is required. But locking is not possible from an interrupt,   */
-/* since it puts the process to sleep if the lock is not available.   */
-/* This prevents "late" locking of the DMA chip, i.e. locking it just */
-/* before using it, since in case of disconnection-reconnection   */
-/* commands, the DMA is started from the reselection interrupt.   */
-/**/
-/* Two possible schemes for ST-DMA-locking would be:  */
-/*  1) The lock is taken for each command separately and disconnecting*/
-/* is forbidden (i.e. can_queue = 1). */
-/*  2) The DMA chip is locked when the first command comes in and */
-/* released when the last command is finished and all queues are  */
-/* empty. */
-/* The first alternative would result in bad performance, since the   */
-/* interleaving of commands would not be used. The second is unfair to*/
-/* other drivers using the ST-DMA, because the queues will seldom be  */
-/* totally empty if there is a lot of disk traffic.   */
-/**/
-/* For this reasons I decided to employ a more elaborate scheme:  */
-/*  - First, we give up the lock every time we can (for fairness), this*/
-/*means every time a command finishes and there are no other commands */
-/*on the disconnected queue.  */
-/*  - If there are others waiting to lock the DMA chip, we stop   */
-/*issuing commands, i.e. moving them onto the issue queue.   */
-/*Because of that, the disconnected queue will run empty in a */
-/*while. Instead we go to sleep on a 'fairness_queue'.*/
-/*  - If the lock is released, all processes waiting on the fairness  */
-/*queue will be woken. The first of them tries to re-lock the DMA, */
-/*the others wait for the first to finish this task. After that,  */
-/*they can all run on and do their commands...*/
-/* This sounds complicated (and it is it :-(), but it seems to be a   */
-/* good compromise between fairness and performance: As long as no one */
-/* else wants to work with the ST-DMA chip, SCSI can go along as  */
-/* usual. If now someone else comes, this behaviour is changed to a   */
-/* "fairness mode": just already initiated commands are finished and  */
-/* then the lock is released. The other one waiting will probably win */
-/* the race for locking the DMA, since it was waiting for longer. And */
-/* after it has finished, SCSI can go ahead again. Finally: I hope I  */
-/* have not produced any deadlock possibilities!  */
-/**/
-/**/
-
+/*
+ * Notes for Falcon SCSI DMA
+ *
+ * The 5380 device is one of several that all share the DMA chip. Hence
+ * "locking" and "unlocking" access to this chip is required.
+ *
+ * Two possible schemes for ST DMA acquisition by atari_scsi are:
+ * 1) The lock is taken for each command separately (i.e. can_queue == 1).
+ * 2) The lock is taken when the first command arrives and released
+ * when the last command is finished (i.e. can_queue > 1).