On 64 bit CPUs there is a memory corruption bug on probe(). It should
be a u32 pointer instead of an unsigned long pointer or we write past
the end of the setupdata[] array.
Signed-off-by: Dan Carpenter
Reviewed-by: Hannes Reinecke
---
Resending because we have shuffled the code around so the p
There were a couple cases where the error codes weren't set and also I
changed the success return to "return 0;" which is the same as
"return rc;" but more explicit.
Fixes: 42e7a69368a5 ('hisi_sas: Add ssp command functio')
Signed-off-by: Dan Carpenter
diff --git a/drivers/scsi/hisi_sas/hisi_sas
On Tuesday 08 December 2015 12:40:18 Finn Thain wrote:
>
> On Tue, 8 Dec 2015, Ondrej Zary wrote:
>
> > HP C2502 cards (based on 53C400A chips) use different magic numbers for
> > software-based I/O address configuration than other cards. The
> > configuration is also extended to allow setting
Sudip Mukherjee
> > ---
> A gentle ping.
> I still get the build warning while building for i386 allmodconfig with
> next-20150915.
> Build is at https://travis-ci.org/sudipm-mukherjee/parport/jobs/80365417
Another gentle ping. Build warning with i386 allmodconfig is still the
On Wednesday 09 December 2015 12:53:39 One Thousand Gnomes wrote:
> On Wed, 9 Dec 2015 13:24:53 +0300
> Dan Carpenter wrote:
>
> > On 64 bit CPUs there is a memory corruption bug on probe(). It should
> > be a u32 pointer instead of an unsigned long pointer or we write past
> > the end of the se
HP C2502 cards (based on 53C400A chips) use different magic numbers for
software-based I/O address configuration than other cards.
The configuration is also extended to allow setting the IRQ.
Move the configuration to a new function magic_configure() and move
magic the magic numbers into an array.
On Wed, 9 Dec 2015 13:24:53 +0300
Dan Carpenter wrote:
> On 64 bit CPUs there is a memory corruption bug on probe(). It should
> be a u32 pointer instead of an unsigned long pointer or we write past
> the end of the setupdata[] array.
>
> Signed-off-by: Dan Carpenter
> Reviewed-by: Hannes Rein
https://bugzilla.kernel.org/show_bug.cgi?id=108771
--- Comment #2 from Pavel Tikhomirov ---
On 12/08/2015 07:16 PM, James Bottomley wrote:
> On Mon, 2015-12-07 at 14:01 +, bugzilla-dae...@bugzilla.kernel.org
> wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=108771
>>
>> --- Comment #1 f
On 12/08/2015 07:16 PM, James Bottomley wrote:
On Mon, 2015-12-07 at 14:01 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=108771
--- Comment #1 from Pavel Tikhomirov ---
Aditional info about enclosue(from that node, but older 3.10 based kernel):
On 09/12/2015 10:48, Dan Carpenter wrote:
There were a couple cases where the error codes weren't set and also I
changed the success return to "return 0;" which is the same as
"return rc;" but more explicit.
Fixes: 42e7a69368a5 ('hisi_sas: Add ssp command functio')
Signed-off-by: Dan Carpenter
On Tuesday 08 December 2015 03:05:11 Finn Thain wrote:
>
> On Sun, 6 Dec 2015, Ondrej Zary wrote:
>
> > Add I/O register mapping for NCR53C400A and enable PDMA mode to
> > improve performance and fix non-working IRQ.
> >
> > Tested with HP C2502 (and user-space enabler).
> >
> > Signed-off-by:
Everyone knows I didn't test it but it's an obvious one line fix for
memory corruption. If no one uses the code, at least this is harmless
and silences a static checker warning.
In olden times we used to say, "Oh this bounds checking is crap but it's
root only so let's leave it alone." But these
On Wed, 9 Dec 2015 16:45:12 +0300
Dan Carpenter wrote:
> Everyone knows I didn't test it but it's an obvious one line fix for
> memory corruption. If no one uses the code, at least this is harmless
> and silences a static checker warning.
>
> In olden times we used to say, "Oh this bounds check
On 8.12.2015 18:00, James Bottomley wrote:
> Simple enclosure implementations (mostly USB) are allowed to return only
> page 8 to every diagnostic query. That really confuses our
> implementation because we assume the return is the page we asked for and
> end up doing incorrect offsets based on bo
We should add a tag to indicate that we are sending a patch for a crappy
driver.
IMHO-this-driver-is-garbage: Your Name
If it got 10 votes of no confidence it would be moved to staging and
then deleted.
Anyway, realistically, let's just apply this fix. It's tempting to
think we could delete al
On Wed, 9 Dec 2015, Dan Carpenter wrote:
> We should add a tag to indicate that we are sending a patch for a crappy
> driver.
>
> IMHO-this-driver-is-garbage: Your Name
>
> If it got 10 votes of no confidence it would be moved to staging and
> then deleted.
Forgive my ignorance, but what is th
On Wed, 2015-12-09 at 18:07 +0100, Tomas Henzl wrote:
> On 8.12.2015 18:00, James Bottomley wrote:
> > Simple enclosure implementations (mostly USB) are allowed to return only
> > page 8 to every diagnostic query. That really confuses our
> > implementation because we assume the return is the page
On Wed, Dec 09, 2015 at 07:11:15PM +0100, Julia Lawall wrote:
> Forgive my ignorance, but what is the exact procedure? For example, the
> following file: drivers/pcmcia/vrc4173_cardu.c contains the following
> code: INIT_WORK(&socket->tq_work, cardu_bh, socket);. The last time
> INIT_WORK took th
A big use of SAS enclosures is actually to hold SATA devices. Right at
the moment, the ses enclosure system doesn't recognize SATA devices.
The reason for this is that SAS actually makes up an endpoint address
for a SATA device since SATA doesn't have an addressing scheme. The
problem this causes
Adds a function designed to be callable any time (regardless of
whether the transport attributes are configured or not) which returns
true if the device is attached over a SAS transport. The design of
this function is that transport specific functions can be embedded
within a
if (is_sas_attached(
For a device known to be SAS connected, this will return the endpoint
address. This is useful for getting the SAS address of SATA devices.
Signed-off-by: James Bottomley
---
drivers/scsi/scsi_transport_sas.c | 14 ++
include/scsi/scsi_transport_sas.h |1 +
2 files changed, 15
The current discovery routines use the VPD 0x83 inquiry page to find
the device SAS address and match it to the end point in the enclosure.
This doesn't work for SATA devices because expanders (or hosts) simply
make up an endpoint address for STP and thus the address returned by
the VPD page never
> You should just delete that code along with the Kconfig and Makefile
> entries. Don't bother moving it to staging. The move to staging is
> supposed to give people one last chance to yell if they absolutely need
> the code. No one has compiled this code for years so no one will miss
> it.
And
Christoph,
Understood. I was not sure which way the community is swinging.
For what it¹s worth, this fix was required to stabilize one of our
customer environment in the older kernel.
Regards,
Quinn Tran
On 12/7/15, 6:48 PM, "target-devel-ow...@vger.kernel.org on behalf of
Christoph Hellwig
On 12/7/15, 6:48 PM, "target-devel-ow...@vger.kernel.org on behalf of
Christoph Hellwig" wrote:
>> diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
>>b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
>> index 842fcca..2e9c194 100644
>> --- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
>> +++ b/drivers/scsi/qla2xxx/tcm
Hi James,
[auto build test ERROR on v4.4-rc4]
[cannot apply to scsi/for-next next-20151209]
url:
https://github.com/0day-ci/linux/commits/James-Bottomley/Fix-the-problem-of-SATA-devices-within-SAS-enclosures/20151210-031802
config: i386-randconfig-b0-12100330 (attached as .config)
reproduce
On Thu, 2015-12-10 at 04:38 +0800, kbuild test robot wrote:
> Hi James,
>
> [auto build test ERROR on v4.4-rc4]
> [cannot apply to scsi/for-next next-20151209]
>
> url:
> https://github.com/0day-ci/linux/commits/James-Bottomley/Fix-the-problem-of-SATA-devices-within-SA
The current discovery routines use the VPD 0x83 inquiry page to find
the device SAS address and match it to the end point in the enclosure.
This doesn't work for SATA devices because expanders (or hosts) simply
make up an endpoint address for STP and thus the address returned by
the VPD page never
Reviewed-by: Justin Lindley
Reviewed-by: Kevin Barnett
Reviewed-by: Scott Teel
Signed-off-by: Don Brace
---
drivers/scsi/hpsa.c | 108 ---
drivers/scsi/hpsa_cmd.h | 13 ++
2 files changed, 114 insertions(+), 7 deletions(-)
diff --git a/dr
left off some changes from Rasmus Villemoes where he changed
snprintf to scnprintf
Suggested-by: Rasmus Villemoes
Reviewed-by: Justin Lindley
Reviewed-by: Kevin Barnett
Reviewed-by: Scott Teel
Signed-off-by: Don Brace
---
drivers/scsi/hpsa.c | 12 ++--
1 file changed, 6 insertions(
These patches are based on Linus's tree
The changes are:
- correct missing changes from snprintf to scnprintf
in path_info_show by Rasmus Villemoes
- fix reported bus for SAS transport devices
- add in enclosure information
---
Don Brace (3):
hpsa: fix path_info_show
hpsa: chan
sas transport places devices on bus 0 but driver was setting
the bus to 3.
Reviewed-by: Justin Lindley
Reviewed-by: Kevin Barnett
Reviewed-by: Scott Teel
Signed-off-by: Don Brace
---
drivers/scsi/hpsa.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/hpsa.h
On 12/7/15, 6:37 PM, "target-devel-ow...@vger.kernel.org on behalf of
Christoph Hellwig" wrote:
>> -void qlt_abort_cmd(struct qla_tgt_cmd *cmd)
>> +int qlt_abort_cmd(struct qla_tgt_cmd *cmd)
>> {
>> struct qla_tgt *tgt = cmd->tgt;
>> struct scsi_qla_host *vha = tgt->vha;
>> struc
Hannes,
ACK. We¹ll move the flags to bitops in the "follow on" patch to clean it
up. Those flags was introduced from a different patch. Will move the few
overloaded flag to bit field.
However, getting rid of the spin lock would prove tricky because the code
is trying to serialize the cleanup.
Reviewed-by: Matthew R. Ochs
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Dec 9, 2015, at 3:18 PM, Don Brace wrote:
>
> sas transport places devices on bus 0 but driver was setting
> the bus to 3.
>
> Reviewed-by: Justin Lindley
> Reviewed-by: Kevin Barnett
> Reviewed-by: Scott Teel
> Signed-off-by: Don Brace
> ---
> drivers/scsi/hpsa.h |2 +-
> 1 file cha
> On Dec 9, 2015, at 3:18 PM, Don Brace wrote:
No commit message?
>
> Reviewed-by: Justin Lindley
> Reviewed-by: Kevin Barnett
> Reviewed-by: Scott Teel
> Signed-off-by: Don Brace
> ---
> drivers/scsi/hpsa.c | 108 ---
> drivers/scsi/hpsa_cmd.
On Wed, 2015-12-09 at 15:35 +0300, Pavel Tikhomirov wrote:
>
> On 12/08/2015 07:16 PM, James Bottomley wrote:
> > On Mon, 2015-12-07 at 14:01 +, bugzilla-dae...@bugzilla.kernel.org
> > wrote:
> >> https://bugzilla.kernel.org/show_bug.cgi?id=108771
> >>
> >> --- Comment #1 from Pavel Tikhomirov
On 12/8/15, 10:56 PM, "target-devel-ow...@vger.kernel.org on behalf of
Hannes Reinecke" wrote:
>On 12/08/2015 01:48 AM, Himanshu Madhani wrote:
>> From: Quinn Tran
>>
>> change tcm_qla2xxx_check_stop_free to always return 1
>> to prevent transport_cmd_finish_abort from accidently
>> taking ext
_microsoft rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul
crc32c_intel serio_raw drm e1000e ptp rtsx_pci pps_core fjes video
[ 125.109197] CPU: 2 PID: 142 Comm: kworker/u16:6 Tainted: G W
4.4.0-rc4-usbbadness-next-20151209+ #3
[ 125.109198] Hardware name: LENOVO 20BFS0EC00/20BFS0EC00, BIOS GMET
ockd grace sunrpc
binfmt_misc
dm_crypt hid_microsoft rtsx_pci_sdmmc mmc_core crct10dif_pclmul
crc32_pclmul
crc32c_intel serio_raw drm e1000e ptp rtsx_pci pps_core fjes video
[ 125.109197] CPU: 2 PID: 142 Comm: kworker/u16:6 Tainted: G W
4.4.0-rc4-usbbadness-next-20151209+ #3
[ 125.109198] Hardware na
41 matches
Mail list logo
