RE: [PATCH] PC-9800 subarch. support for 2.5.62-AC1 (16/21) SCSI

[Osamu Tomita]

-----Original Message-----
From: Christoph Hellwig
To: Osamu Tomita
Cc: Linux Kernel Mailing List; Alan Cox; Christoph Hellwig
Sent: 2003/02/23 19:52
Subject: Re: [PATCH] PC-9800 subarch. support for 2.5.62-AC1 (16/21) SCSI

>> +int pc98_bios_param(struct block_device *bdev, int *ip)
>> +{
>> +  /* Note: This function is called from fs/partitions/nec98.c too. */
>> +  /* So we creat 'sdp' from 'bdev' here. */
>> +  struct scsi_disk *sdkp = scsi_disk(bdev->bd_disk);
> 
> this is still not good - you shouldn't expose struct scsi_disk outside
> sd.c.  Please change the pc98_bios_param() prototype to that of the
> bios_param entry point (direct passing of capacity).
This is solved by using ioctl_by_bdev() in your suggestion. Thanks.

> Can you explain what this first_real_host() stuff is for - we need some
> way to handle this better.
PC98 BIOS create geometry table on boottime orderd by SCSI ID.
We read that to get geometry. If ide-scsi exist we mis-read table.

.
.
(Snipped, but I'll fix them. Thanks.)
.
.

>> +	BIOS_PARAM_OVERRIDE(sdp, bdev, sdkp->capacity, diskinfo);
>> +
> 
> the way this is done is ugly.  I'm still not sure how this is done
> best.  When do you need the pc98 geometry exactly?  i.e. can it happen
> with one of the existing linux scsi drivers?
We need BIOS geometry exactly to create a partion on linux (by fdisk or
GNU/parted). BIOS uses C/H/S access on boottime according to partition
table. If BIOS geometry is not exact, fail to boot from the partition.
I recived the report about this problem from people using advansys driver
without PC98 patch.

>> +#if defined(CONFIG_SCSI_PC980155) ||
defined(CONFIG_SCSI_PC980155_MODULE)
>> +#include "pc980155regs.h"
>> +#else /* !CONFIG_SCSI_PC980155 */
>>  
>>  static inline uchar read_wd33c93(const wd33c93_regs regs, uchar
reg_num)
>>  {
>> @@ -203,6 +206,7 @@
>>     *regs.SCMD = cmd;
>>     mb();
>>  }
>> +#endif /* CONFIG_SCSI_PC980155 */
> 
> The wd33c93 changes are ugly as hell, but that's not your fault.  I'll
> try to rework it to abstract out the different implementations better.
> Could you perform some testing for me if I send you updated versions?
Yes, of course.

Thanks,
Osamu Tomita