Re: [PATCH #upstream] libata: implement libata.force module parameter

Re: [PATCH #upstream] libata: implement libata.force module parameter

[Jeff Garzik]

Tejun Heo wrote:
> This patch implements libata.force module parameter which can
> selectively override ATA port, link and device configurations
> including cable type, SATA PHY SPD limit, transfer mode and NCQ.
> 
> For example, you can say "use 1.5Gbps for all fan-out ports attached
> to the second port but allow 3.0Gbps for the PMP device itself, oh,
> the device attached to the third fan-out port chokes on NCQ and
> shouldn't go over UDMA4" by the following.
> 
>  libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4
> 
> Signed-off-by: Tejun Heo <htejun@gmail.com>
> ---
> I guess it's about time we add something like this.  More than
> anything else this should help debugging and can serve as a last
> resort to work around problems.
> 
> Thanks.
> 
>  Documentation/kernel-parameters.txt |   35 +++
>  drivers/ata/libata-core.c           |  375 +++++++++++++++++++++++++++++++++++-
>  drivers/ata/libata-eh.c             |    8 
>  drivers/ata/libata.h                |    1 
>  4 files changed, 415 insertions(+), 4 deletions(-)

ACK, but it breaks the build due to section type conflicts:

drivers/ata/libata-core.c:108: error: ata_force_param_buf causes a 
section type conflict

Given that the data is marked __initdata and the code is marked __init, 
I cannot see the problem.

Re: [PATCH #upstream] libata: implement libata.force module parameter

[Bartlomiej Zolnierkiewicz]

On Feb 1, 2008 6:28 PM, Jeff Garzik <jeff@garzik.org> wrote:
> Tejun Heo wrote:
> > This patch implements libata.force module parameter which can
> > selectively override ATA port, link and device configurations
> > including cable type, SATA PHY SPD limit, transfer mode and NCQ.
> >
> > For example, you can say "use 1.5Gbps for all fan-out ports attached
> > to the second port but allow 3.0Gbps for the PMP device itself, oh,
> > the device attached to the third fan-out port chokes on NCQ and
> > shouldn't go over UDMA4" by the following.
> >
> >  libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4
> >
> > Signed-off-by: Tejun Heo <htejun@gmail.com>
> > ---
> > I guess it's about time we add something like this.  More than
> > anything else this should help debugging and can serve as a last
> > resort to work around problems.
> >
> > Thanks.
> >
> >  Documentation/kernel-parameters.txt |   35 +++
> >  drivers/ata/libata-core.c           |  375 +++++++++++++++++++++++++++++++++++-
> >  drivers/ata/libata-eh.c             |    8
> >  drivers/ata/libata.h                |    1
> >  4 files changed, 415 insertions(+), 4 deletions(-)
>
> ACK, but it breaks the build due to section type conflicts:
>
> drivers/ata/libata-core.c:108: error: ata_force_param_buf causes a
> section type conflict
>
> Given that the data is marked __initdata and the code is marked __init,
> I cannot see the problem.

the data is marked as "const"

Re: [PATCH #upstream] libata: implement libata.force module parameter

[Sam Ravnborg]

On Fri, Feb 01, 2008 at 12:28:35PM -0500, Jeff Garzik wrote:
> Tejun Heo wrote:
> >This patch implements libata.force module parameter which can
> >selectively override ATA port, link and device configurations
> >including cable type, SATA PHY SPD limit, transfer mode and NCQ.
> >
> >For example, you can say "use 1.5Gbps for all fan-out ports attached
> >to the second port but allow 3.0Gbps for the PMP device itself, oh,
> >the device attached to the third fan-out port chokes on NCQ and
> >shouldn't go over UDMA4" by the following.
> >
> > libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4
> >
> >Signed-off-by: Tejun Heo <htejun@gmail.com>
> >---
> >I guess it's about time we add something like this.  More than
> >anything else this should help debugging and can serve as a last
> >resort to work around problems.
> >
> >Thanks.
> >
> > Documentation/kernel-parameters.txt |   35 +++
> > drivers/ata/libata-core.c           |  375 
> > +++++++++++++++++++++++++++++++++++-
> > drivers/ata/libata-eh.c             |    8 
> > drivers/ata/libata.h                |    1 
> > 4 files changed, 415 insertions(+), 4 deletions(-)
> 
> ACK, but it breaks the build due to section type conflicts:
> 
> drivers/ata/libata-core.c:108: error: ata_force_param_buf causes a 
> section type conflict
> 
> Given that the data is marked __initdata and the code is marked __init, 
> I cannot see the problem.

I have lost the actual patch.
But what you see is what happens when you mix const and non-const data
in the same section.

Look for use of __initdata for const data and replace it with __initconst.

And modpost cannot warn about it as gcc errors out before we look at the
.o file with modpost.

	Sam

Re: [PATCH #upstream] libata: implement libata.force module parameter

[Tejun Heo]

Sam Ravnborg wrote:
> I have lost the actual patch.
> But what you see is what happens when you mix const and non-const data
> in the same section.
> 
> Look for use of __initdata for const data and replace it with __initconst.
> 
> And modpost cannot warn about it as gcc errors out before we look at the
> .o file with modpost.

OIC, thanks.  Hmmm... in init.h, I see __{dev|cpu|mem}initconst but no
__initconst.  The data structure in question is used from module init
function tagged properly with __init.  What should be done here?


-- 
tejun

Re: [PATCH #upstream] libata: implement libata.force module parameter

[Tejun Heo]

Tejun Heo wrote:
> Sam Ravnborg wrote:
>> I have lost the actual patch.
>> But what you see is what happens when you mix const and non-const data
>> in the same section.
>>
>> Look for use of __initdata for const data and replace it with __initconst.
>>
>> And modpost cannot warn about it as gcc errors out before we look at the
>> .o file with modpost.
> 
> OIC, thanks.  Hmmm... in init.h, I see __{dev|cpu|mem}initconst but no
> __initconst.  The data structure in question is used from module init
> function tagged properly with __init.  What should be done here?

PING.

-- 
tejun

Re: [PATCH #upstream] libata: implement libata.force module parameter

[Tejun Heo]

Jeff Garzik wrote:
> Tejun Heo wrote:
>> This patch implements libata.force module parameter which can
>> selectively override ATA port, link and device configurations
>> including cable type, SATA PHY SPD limit, transfer mode and NCQ.
>>
>> For example, you can say "use 1.5Gbps for all fan-out ports attached
>> to the second port but allow 3.0Gbps for the PMP device itself, oh,
>> the device attached to the third fan-out port chokes on NCQ and
>> shouldn't go over UDMA4" by the following.
>>
>>  libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4
>>
>> Signed-off-by: Tejun Heo <htejun@gmail.com>
>> ---
>> I guess it's about time we add something like this.  More than
>> anything else this should help debugging and can serve as a last
>> resort to work around problems.
>>
>> Thanks.
>>
>>  Documentation/kernel-parameters.txt |   35 +++
>>  drivers/ata/libata-core.c           |  375
>> +++++++++++++++++++++++++++++++++++-
>>  drivers/ata/libata-eh.c             |    8
>>  drivers/ata/libata.h                |    1  4 files changed, 415
>> insertions(+), 4 deletions(-)
> 
> ACK, but it breaks the build due to section type conflicts:
> 
> drivers/ata/libata-core.c:108: error: ata_force_param_buf causes a
> section type conflict
> 
> Given that the data is marked __initdata and the code is marked __init,
> I cannot see the problem.

Jeff, this no longer causes build failure whether libata is configured
built-in or as a module.  I have no idea what's going on but there
doesn't seem to be a proper solution on the horizon yet.  I think we can
go ahead and commit this one and convert it to __initdataconst when it
becomes available.

Thanks.

-- 
tejun