linux-kernel - Re: [loongson-PATCH-v1 24/27] fixup for FUJITSU disk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1243230339.9819.18.camel@localhost.localdomain>
Date:	Mon, 25 May 2009 13:45:39 +0800
From:	yanh <yanh@...ote.com>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	wuzhangjin@...il.com, linux-mips@...ux-mips.org,
	Ralf Baechle <ralf@...ux-mips.org>,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	Philippe Vachon <philippe@...pig.ca>,
	Zhang Le <r0bertz@...too.org>,
	Zhang Fuxin <zhangfx@...ote.com>,
	Arnaud Patard <apatard@...driva.com>,
	loongson-dev@...glegroups.com, gnewsense-dev@...gnu.org,
	Nicholas Mc Guire <hofrat@...r.at>,
	Liu Junliang <liujl@...ote.com>,
	Erwan Lerale <erwan@...scow.com>
Subject: Re: [loongson-PATCH-v1 24/27] fixup for FUJITSU disk

在 2009-05-23六的 13:47 +0200，Bartlomiej Zolnierkiewicz写道：
> On Saturday 23 May 2009 09:11:42 yanh wrote:
> > 在 2009-05-22五的 20:32 +0200，Bartlomiej Zolnierkiewicz写道：
> > > On Thursday 21 May 2009 00:12:46 wuzhangjin@...il.com wrote:
> > > > From: Wu Zhangjin <wuzhangjin@...il.com>
> > > > 
> > > > This is originally from the to-mips branch from
> > > > http://dev.lemote.com/code/linux_loongson
> > > 
> > > Sadly, the patch description lacks all the important information.
> > > 
> > > What is the original problem that this fixup tries to address?
> > > 
> > > Is it limited to amd74xx controllers?
> > 
> > In loongson2f yeeloong machines, the ide controller is AMD cs5536, or
> > say  amd74xx, and the hard drives is Fujistu. 
> 
> Then it should use the new & shiny :) native cs5536 IDE host driver
> instead of legacy support in amd74xx...
> 
> > While debuging the hard disk suspned and resume, the ide irq can not be
> > cleared. I guess this is a fake interrupt, hence the clear irq action
> > can not be finished. 
> 
> AFAICS the only change that the fixup would cause for suspend/resume paths
> is the one in ide_config_drive_speed() which is called during resume to set
> transfer mode on the drive:
> 
>        tp_ops->write_devctl(hwif, ATA_NIEN | ATA_DEVCTL_OBS);
> 
>         memset(&tf, 0, sizeof(tf));
>         tf.feature = SETFEATURES_XFER;
>         tf.nsect   = speed;
> 
>         tp_ops->tf_load(drive, &tf, IDE_VALID_FEATURE | IDE_VALID_NSECT);
> 
>         tp_ops->exec_command(hwif, ATA_CMD_SET_FEATURES);
> --->
>         if (drive->quirk_list == 2)
>                 tp_ops->write_devctl(hwif, ATA_DEVCTL_OBS);

> --->
>         error = __ide_wait_stat(drive, drive->ready_stat,
>                                 ATA_BUSY | ATA_DRQ | ATA_ERR,
>                                 WAIT_CMD, &stat);
> 
> Please tell me I if understand the issue correctly: if the above quirk is
> not executed we end up with spurious IRQs, right?
right.
> 
> > This patch is to fix this issue. Maybe other controller and drives also
> > have this issue, but I am not sure.
> 
> Probably moving it to a generic quirk_drives list later will be useful...
> 
> Anyway this fixup needs to be ported to / verified with cs5536 first.
the cs5536 pata driver have some geode platform dependent codes. We can
just ignore it, but the performance is poor(using hdparm to test it),
which only get 22+ MB/s. we find it only use udma2. However if using
amd74xx driver, it can set udma5, and the speed can reach to 50+ MB/s. 

we will test whether this driver is working well without this patch.

Anyway, thanks your advice.
> 
> Thanks.
> Bart
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/