[PATCH] MAINTAINERS: add an entry for all the NCR5380 drivers
Signed-off-by: Finn Thain Cc: Michael Schmitz --- As requested: http://marc.info/?l=linux-arm-kernel&m=139853302724112&w=2 diff --git a/MAINTAINERS b/MAINTAINERS index e67ea24..60ea600 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5996,6 +5996,28 @@ M: Petr Vandrovec S: Odd Fixes F: fs/ncpfs/ +NCR 5380 SCSI DRIVERS +M: Finn Thain +M: Michael Schmitz +L: linux-scsi@vger.kernel.org +S: Maintained +F: Documentation/scsi/g_NCR5380.txt +F: drivers/scsi/NCR5380.* +F: drivers/scsi/arm/cumana_1.c +F: drivers/scsi/arm/oak.c +F: drivers/scsi/atari_NCR5380.c +F: drivers/scsi/atari_scsi.* +F: drivers/scsi/dmx3191d.c +F: drivers/scsi/dtc.* +F: drivers/scsi/g_NCR5380.* +F: drivers/scsi/g_NCR5380_mmio.c +F: drivers/scsi/mac_scsi.* +F: drivers/scsi/pas16.* +F: drivers/scsi/sun3_NCR5380.c +F: drivers/scsi/sun3_scsi.* +F: drivers/scsi/sun3_scsi_vme.c +F: drivers/scsi/t128.* + NCR DUAL 700 SCSI DRIVER (MICROCHANNEL) M: "James E.J. Bottomley" L: linux-scsi@vger.kernel.org -- 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
Re: [PATCH v1.0 12/16] arcmsr: revise alloction of second dma_coherent_handle for type B adapter
Hi Dan, This patch is not a bugfix. It is a simplification and consistency of coding for both adapter type B and D. Regards, Ching 2014-05-02 16:57 GMT+08:00 Dan Carpenter : > On Wed, Apr 30, 2014 at 07:30:29PM +0800, ching wrote: >> From: Ching >> >> Revise allocation of second dma_coherent_handle for type_B adapter. >> > > Is this a bugfix? I think it is. Do you know what the user visible > effects are? > > regards, > dan carpenter > -- 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
Re: [PATCH v1.0 14/16] arcmsr: fix sparse checking error
Hi Dan,
In this patch, there are several replace of call readl() or writel()
by direct access to memory.
Because in main memory, we allocated a block of memory for
post_qbuffer and done_qbuffer.
These memory are access by both of CPU and IOP, they are not hardware registers.
This change will not introduce a bug. I have verified it.
Thanks for your comment.
Regards,
Ching
2014-05-02 17:13 GMT+08:00 Dan Carpenter :
> On Wed, Apr 30, 2014 at 07:38:26PM +0800, ching wrote:
>> From: Ching
>>
>> Fix sparse utility checking errors.
>>
>
> I was expecting that this patch would add __iomem annotations throughout
> but in several places it actually removes calls to readl() and writel()
> as well.
>
>> case ACB_ADAPTER_TYPE_C:{
>> - struct MessageUnit_C *reg = (struct MessageUnit_C *)acb->pmuC;
>> + struct MessageUnit_C __iomem *reg = acb->pmuC;
>> /* disable all outbound interrupt */
>> orig_mask = readl(®->host_int_mask); /* disable outbound
>> message0 int */
>> writel(orig_mask|ARCMSR_HBCMU_ALL_INTMASKENABLE,
>> ®->host_int_mask);v
>> @@ -1085,8 +1085,9 @@ static void arcmsr_done4abort_postqueue(
>> /*clear all outbound posted Q*/
>> writel(ARCMSR_DOORBELL_INT_CLEAR_PATTERN,
>> reg->iop2drv_doorbell); /* clear doorbell interrupt */
>> for (i = 0; i < ARCMSR_MAX_HBB_POSTQUEUE; i++) {
>> - if ((flag_ccb = readl(®->done_qbuffer[i])) != 0) {
>> - writel(0, ®->done_qbuffer[i]);
>> + flag_ccb = reg->done_qbuffer[i];
>> + if (flag_ccb != 0) {
>> + reg->done_qbuffer[i] = 0;
>> pARCMSR_CDB = (struct ARCMSR_CDB
>> *)(acb->vir2phy_offset+(flag_ccb << 5));/*frame must be 32 bytes aligned*/
>> pCCB = container_of(pARCMSR_CDB, struct
>> CommandControlBlock, arcmsr_cdb);
>> error = (flag_ccb &
>> ARCMSR_CCBREPLY_FLAG_ERROR_MODE0) ? true : false;
>
> I don't know the hardware, but it doesn't even seem to make sense to me.
> if "reg" is an __iomem pointer surely an offset into reg is an iomem
> pointer as well.
>
> I am worried that this introduces a bug.
>
> regards,
> dan carpenter
--
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
Re: [PATCH RESEND] scsi_transport_sas: move bsg destructor into sas_rphy_remove
On Fri, 2014-05-02 at 12:26 -0700, Dan Williams wrote: > On Fri, May 2, 2014 at 12:01 PM, Joe Lawrence > wrote: > > On Wed, 2 Apr 2014 16:48:52 -0400 > > Joe Lawrence wrote: > > > >> On Wed, 2 Apr 2014 16:40:41 -0400 > >> Joe Lawrence wrote: > >> > >> > Since bsg creation is a side effect of sas_rphy_add, move its > >> > complementary removal call into sas_rphy_remove. > >> > >> Hello James, > >> > >> This a resend of a patch posted to quiet an end-device sysfs warning in > >> its device deletion path when removing the mpt2sas driver: > >> > >> (initial report) > >> sysfs group not found for kobject on mpt2sas unload > >> http://marc.info/?t=13849746004 > >> > >> (patch + ACK + comments) > >> http://marc.info/?t=13860945551 > >> > >> (gentoo, LSI repro) > >> mpt2sas driver barfs when force removing a drive on 3.13.1 > >> http://marc.info/?t=13912235131 > >> > >> Dan Williams had a few other suggestions for cleanup in this area, but > >> those could be handled in a subsequent patch. This one missed 3.14 > >> inclusion and the warning still occurs in Linus's tree as of today > >> (post scsi/block merge) hence the repost. > > > > Ping? Just reproduced on 3.15-rc3. Also found this: > > > > (~500 repro count on Fedora Problem Tracker) > > http://retrace.fedoraproject.org/faf/problems/1623421/ > > > > Hmm, looks like the re-send is missing my ack. Feel free to add: > > Acked-by: Dan Williams > > James, do you want me to shepherd sas infrastructure bits > (libsas/scsi_transport_sas) along in my own tree, or...? Well, let's try a tree for enhancements ... you know the drill: signed pull to me on or before -rc6. This one, based on the fedora tracker info (only just shown) looks like a bug affecting older kernels, so necessitating a cc to stable, right? I'll take it through scsi-fixes James -- 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
HELLO MY NEW FRIEND
Hello, How are you doing? I guess you would be surprise to receive this message from a total stranger like myself, Well my name is Nathalie, I am a female Swedish national and a temporary staff of Qatar Development Bank (QDB) Please i need your attention to share a business deal with you. The success of this business depends on your cooperation. I will give you more details and also will share my pictures and private telephone number with you once you indicate interest by replying back to me. Have a good day, Regards, Nathalie J. Theodor -- 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
Re: esp_scsi QTAG in FAS216
On 14.04.2014 12:01, Michael Schmitz wrote:
Hi Dave,
When this bit is set, the 53CF94/96 can receive 3-byte messages during
bus-initiated Select With ATN. This feature is also enabled by setting
bit 3 in the Configuration 2 register.
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.
Agreed. ESP_CONFIG2_SCSI2ENAB might do more than we intend, and have
unintended side effects. It's just easier to test whether this fixes
our problem.
But some pieces of documentation seem like they might not agree on
this point.
With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.
That's what I understood from the bits Kars quoted, yes. And in the
Amiga driver cases, it will always be the 3 byte message feature
controlled by that bit, as far as I can see.
Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
That would be even easier than setting it explicitly in the Zorro
driver, thanks,
Michael
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong
Reported-by: Michael Schmitz
Signed-off-by: David S. Miller
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp->rev = ESP100;
} else {
-esp->config2 = 0;
+esp->config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp->prev_cfg3 = 5;
esp_write8(esp->config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp->rev = ESP236;
}
-esp->config2 = 0;
-esp_write8(esp->config2, ESP_CFG2);
}
}
}
Hello,
The patch above doesn't work. I've attached a log. Looks like the same
problem we've had all along.
The gzipped logs have all esp_scsi debug messages enabled for a
non-patched and patched versions.
-Tuomas
modprobe zorro_esp
zorro_esp: Blizzard 1230 found at address 0xea.
esp: esp0, regs[80ea8000:80eb] irq[2]
esp: esp0 is a FAS236, 40 MHz (ccf=0), SCSI ID 7
scsi0 : esp
scsi 0:0:2:0: Direct-Access SEAGATE ST51080N 0913 PQ: 0 ANSI: 2
scsi target0:0:2: Beginning Domain Validation
scsi target0:0:2: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
scsi target0:0:2: Domain Validation skipping write tests
scsi target0:0:2: Ending Domain Validation
sd 0:0:2:0: [sda] 2109840 512-byte logical blocks: (1.08 GB/1.00 GiB)
sd 0:0:2:0: [sda] Write Protect is off
sd 0:0:2:0: [sda] Write cache: disabled, read cache: enabled, doesn't support
DPO or FUA
sd 0:0:2:0: Attached scsi generic sg0 type 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
Dev sda: unable to read RDB block 0
sda: unable to read partition table
sd 0:0:2:0: [sda] Attached SCSI disk
root@amiga:~# esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 20 31 00 00 00 08 00
end_request: I/O error, dev sda, sector 2109696
Buffer I/O error on device sda, logical block 263712
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 20 31 00 00 00 08 00
end_request: I/O error, dev sda, sector 2109696
Buffer I/O error on device sda, logical block 263712
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [
HELLO MY NEW FRIEND
Hello, How are you doing? I guess you would be surprise to receive this message from a total stranger like myself, Well my name is Nathalie, I am a female Swedish national and a temporary staff of Qatar Development Bank (QDB) Please i need your attention to share a business deal with you. The success of this business depends on your cooperation. I will give you more details and also will share my pictures and private telephone number with you once you indicate interest by replying back to me. Have a good day, Regards, Nathalie J. Theodor -- 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
