Compensation,

[Mr. Newton Williams]

Attention Beneficiary!!!

We have actually been authorized by the newly appointed United
Nation’s Secretary-General, and the governing body of the UNITED
NATION’S Monetary Unit, to investigate the unnecessary delay on your
compensation payment, recommended and approved in your favor. During
the course of our investigation, we discovered with dismay that your
payment has been unnecessarily delayed by corrupt officials who are
trying to divert your funds into their private accounts.

To forestall this, security for your funds was organized in the form
of your personal identification number (PIN) (Atm Card) and this will
enable only you to have direct control over your funds in the (Atm
Card). We will monitor this payment ourselves to avoid the hopeless
situation created by the Officials. An irrevocable payment guarantee
has been issued on your payment. However, we are happy to inform you
that based on our recommendation/instructions, your complete
compensation funds have been credited in your favor through (Atm
Card).

You are therefore advised to contact: Mrs. Syvie Riene, through her
e-mail address: syvierien...@gmail.com contact her now for the release
of your (Atm Card ) to you. As soon as you establish a contact with
her, an Atm Card will be issued to you which you can use to withdraw
your funds in any Atm machine in any part of the world, So if you like
to receive your funds through this means you are advised to contact
Mrs. Syvie Riene, Also be inform that the total amount in the Atm Card
which you are to receive is USD$2,750,000.00.

We expect your urgent response to this email to enable us to monitor
this payment effectively, thereby, making contact with Mrs. Syvie
Riene, as directed to avoid further delay.

Regards
Mr. Newton Williams

Re: Is PROT_SOCK still relevant?

[Jason Newton]

I can only assume from lack of criticism that either:

1)  This is a completely great idea with no cons and thus worthy of
time to implement

or

2) The topic has been ignored

Is it reasonable to allocate a 8KiB buffer for a bit vector covering
2*16 ports?  Should I instead just focus on a list/container to have a
smaller foot print in the average case?

Regards,
Jason

On Wed, Dec 16, 2015 at 9:52 AM, Jason Newton  wrote:
> How about changing how this mechanism works from a range of the lowest
> N ports and instead have it as a user specifiable set?  Towards more
> proper security, this allows distros/admins to put any ports they
> consider important to have security feature going well beyond the
> current limit without recompiling the kernel.
>
> It may make more sense to make this protocol specific too but I'm not
> sure if that would be so simple to implement and manage.
>
> Do we need a default list?  What would the contents be if so?  [0,
> 1024)?  {22, ...}? {}?
>
> Would there be any special considerations needed for the set
> container?  How about a hash table? 2^16-1 uchar bool vector?
>
> In terms of setting/initializing - sysctl?
>
> -Jason
>
> On Mon, Dec 14, 2015 at 3:43 PM, Jason Newton  wrote:
>> On Mon, Dec 14, 2015 at 2:39 PM, One Thousand Gnomes
>>  wrote:
>>>> Perhaps lets consider this in another way if it is strongly held that
>>>> this is worth while in the default configuration: can it default off
>>>> in the context of selinux / other security frameworks (preferably
>>>> based on their detection and/or controllably settable at runtime)?
>>>> Those allow more powerful and finer grain control and don't need this
>>>> to be there as they already provide auditing on what operations and
>>>> port numbers should be allowed by what programs.
>>>
>>> That would be a regression and a very very bad one to have. The defaults
>>> need to always be the same as before - or stronger and never go back
>>> towards insecurity, otherwise they could make things less safe.
>>
>> Even if you don't think it should be default, there's still a case
>> having a knob for leaving it to the auditing framework to deal with
>> it, or perhaps sysctl tunable ranges like on FreeBSD.  That way none
>> of the workarounds mentioned have to be invoked and tuned, which
>> increases maintenance and setup burden.  On some systems, these
>> methods may not be available, too.  Android is one that comes to mind.
>>
>> I openly stated this issue has been brought up for me *this time* due
>> to Android, but it still does keep coming up.  It's on my Linux Kernel
>> bucket list to get it addressed/tunable.  This isn't isn't going to be
>> changed and make it to where it matters for me this occurrence with
>> any practical timing - but I'm trying to prevent the next occurrence
>> I'll have with it - and its not in my expectations it'll be Android at
>> that point.
>>
>>>
>>>> Or how about letting port number concerns be handled by those security
>>>> frameworks all together considering it is limited security?
>>>
>>> There are already half a dozen different ways to handle it from xinetd
>>> through setcap, to systemd spawning it, to iptables.
>>
>> Most (all?) of those methods have sacrifices as previously noted:
>> Systemd isn't everywhere still and may never be, setcap doesn't work
>> with java/python and the like, iptables has significant performance
>> loss when scalability is important and increased configuration
>> detail... never tried with xinetd.  Is one of these the sure fire way
>> or should we be happy we have so many choices with each their own
>> caveats?
>>
>> -Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is PROT_SOCK still relevant?

[Jason Newton]

I can only assume from lack of criticism that either:

1)  This is a completely great idea with no cons and thus worthy of
time to implement

or

2) The topic has been ignored

Is it reasonable to allocate a 8KiB buffer for a bit vector covering
2*16 ports?  Should I instead just focus on a list/container to have a
smaller foot print in the average case?

Regards,
Jason

On Wed, Dec 16, 2015 at 9:52 AM, Jason Newton <nev...@gmail.com> wrote:
> How about changing how this mechanism works from a range of the lowest
> N ports and instead have it as a user specifiable set?  Towards more
> proper security, this allows distros/admins to put any ports they
> consider important to have security feature going well beyond the
> current limit without recompiling the kernel.
>
> It may make more sense to make this protocol specific too but I'm not
> sure if that would be so simple to implement and manage.
>
> Do we need a default list?  What would the contents be if so?  [0,
> 1024)?  {22, ...}? {}?
>
> Would there be any special considerations needed for the set
> container?  How about a hash table? 2^16-1 uchar bool vector?
>
> In terms of setting/initializing - sysctl?
>
> -Jason
>
> On Mon, Dec 14, 2015 at 3:43 PM, Jason Newton <nev...@gmail.com> wrote:
>> On Mon, Dec 14, 2015 at 2:39 PM, One Thousand Gnomes
>> <gno...@lxorguk.ukuu.org.uk> wrote:
>>>> Perhaps lets consider this in another way if it is strongly held that
>>>> this is worth while in the default configuration: can it default off
>>>> in the context of selinux / other security frameworks (preferably
>>>> based on their detection and/or controllably settable at runtime)?
>>>> Those allow more powerful and finer grain control and don't need this
>>>> to be there as they already provide auditing on what operations and
>>>> port numbers should be allowed by what programs.
>>>
>>> That would be a regression and a very very bad one to have. The defaults
>>> need to always be the same as before - or stronger and never go back
>>> towards insecurity, otherwise they could make things less safe.
>>
>> Even if you don't think it should be default, there's still a case
>> having a knob for leaving it to the auditing framework to deal with
>> it, or perhaps sysctl tunable ranges like on FreeBSD.  That way none
>> of the workarounds mentioned have to be invoked and tuned, which
>> increases maintenance and setup burden.  On some systems, these
>> methods may not be available, too.  Android is one that comes to mind.
>>
>> I openly stated this issue has been brought up for me *this time* due
>> to Android, but it still does keep coming up.  It's on my Linux Kernel
>> bucket list to get it addressed/tunable.  This isn't isn't going to be
>> changed and make it to where it matters for me this occurrence with
>> any practical timing - but I'm trying to prevent the next occurrence
>> I'll have with it - and its not in my expectations it'll be Android at
>> that point.
>>
>>>
>>>> Or how about letting port number concerns be handled by those security
>>>> frameworks all together considering it is limited security?
>>>
>>> There are already half a dozen different ways to handle it from xinetd
>>> through setcap, to systemd spawning it, to iptables.
>>
>> Most (all?) of those methods have sacrifices as previously noted:
>> Systemd isn't everywhere still and may never be, setcap doesn't work
>> with java/python and the like, iptables has significant performance
>> loss when scalability is important and increased configuration
>> detail... never tried with xinetd.  Is one of these the sure fire way
>> or should we be happy we have so many choices with each their own
>> caveats?
>>
>> -Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is PROT_SOCK still relevant?

[Jason Newton]

How about changing how this mechanism works from a range of the lowest
N ports and instead have it as a user specifiable set?  Towards more
proper security, this allows distros/admins to put any ports they
consider important to have security feature going well beyond the
current limit without recompiling the kernel.

It may make more sense to make this protocol specific too but I'm not
sure if that would be so simple to implement and manage.

Do we need a default list?  What would the contents be if so?  [0,
1024)?  {22, ...}? {}?

Would there be any special considerations needed for the set
container?  How about a hash table? 2^16-1 uchar bool vector?

In terms of setting/initializing - sysctl?

-Jason

On Mon, Dec 14, 2015 at 3:43 PM, Jason Newton  wrote:
> On Mon, Dec 14, 2015 at 2:39 PM, One Thousand Gnomes
>  wrote:
>>> Perhaps lets consider this in another way if it is strongly held that
>>> this is worth while in the default configuration: can it default off
>>> in the context of selinux / other security frameworks (preferably
>>> based on their detection and/or controllably settable at runtime)?
>>> Those allow more powerful and finer grain control and don't need this
>>> to be there as they already provide auditing on what operations and
>>> port numbers should be allowed by what programs.
>>
>> That would be a regression and a very very bad one to have. The defaults
>> need to always be the same as before - or stronger and never go back
>> towards insecurity, otherwise they could make things less safe.
>
> Even if you don't think it should be default, there's still a case
> having a knob for leaving it to the auditing framework to deal with
> it, or perhaps sysctl tunable ranges like on FreeBSD.  That way none
> of the workarounds mentioned have to be invoked and tuned, which
> increases maintenance and setup burden.  On some systems, these
> methods may not be available, too.  Android is one that comes to mind.
>
> I openly stated this issue has been brought up for me *this time* due
> to Android, but it still does keep coming up.  It's on my Linux Kernel
> bucket list to get it addressed/tunable.  This isn't isn't going to be
> changed and make it to where it matters for me this occurrence with
> any practical timing - but I'm trying to prevent the next occurrence
> I'll have with it - and its not in my expectations it'll be Android at
> that point.
>
>>
>>> Or how about letting port number concerns be handled by those security
>>> frameworks all together considering it is limited security?
>>
>> There are already half a dozen different ways to handle it from xinetd
>> through setcap, to systemd spawning it, to iptables.
>
> Most (all?) of those methods have sacrifices as previously noted:
> Systemd isn't everywhere still and may never be, setcap doesn't work
> with java/python and the like, iptables has significant performance
> loss when scalability is important and increased configuration
> detail... never tried with xinetd.  Is one of these the sure fire way
> or should we be happy we have so many choices with each their own
> caveats?
>
> -Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is PROT_SOCK still relevant?

[Jason Newton]

How about changing how this mechanism works from a range of the lowest
N ports and instead have it as a user specifiable set?  Towards more
proper security, this allows distros/admins to put any ports they
consider important to have security feature going well beyond the
current limit without recompiling the kernel.

It may make more sense to make this protocol specific too but I'm not
sure if that would be so simple to implement and manage.

Do we need a default list?  What would the contents be if so?  [0,
1024)?  {22, ...}? {}?

Would there be any special considerations needed for the set
container?  How about a hash table? 2^16-1 uchar bool vector?

In terms of setting/initializing - sysctl?

-Jason

On Mon, Dec 14, 2015 at 3:43 PM, Jason Newton <nev...@gmail.com> wrote:
> On Mon, Dec 14, 2015 at 2:39 PM, One Thousand Gnomes
> <gno...@lxorguk.ukuu.org.uk> wrote:
>>> Perhaps lets consider this in another way if it is strongly held that
>>> this is worth while in the default configuration: can it default off
>>> in the context of selinux / other security frameworks (preferably
>>> based on their detection and/or controllably settable at runtime)?
>>> Those allow more powerful and finer grain control and don't need this
>>> to be there as they already provide auditing on what operations and
>>> port numbers should be allowed by what programs.
>>
>> That would be a regression and a very very bad one to have. The defaults
>> need to always be the same as before - or stronger and never go back
>> towards insecurity, otherwise they could make things less safe.
>
> Even if you don't think it should be default, there's still a case
> having a knob for leaving it to the auditing framework to deal with
> it, or perhaps sysctl tunable ranges like on FreeBSD.  That way none
> of the workarounds mentioned have to be invoked and tuned, which
> increases maintenance and setup burden.  On some systems, these
> methods may not be available, too.  Android is one that comes to mind.
>
> I openly stated this issue has been brought up for me *this time* due
> to Android, but it still does keep coming up.  It's on my Linux Kernel
> bucket list to get it addressed/tunable.  This isn't isn't going to be
> changed and make it to where it matters for me this occurrence with
> any practical timing - but I'm trying to prevent the next occurrence
> I'll have with it - and its not in my expectations it'll be Android at
> that point.
>
>>
>>> Or how about letting port number concerns be handled by those security
>>> frameworks all together considering it is limited security?
>>
>> There are already half a dozen different ways to handle it from xinetd
>> through setcap, to systemd spawning it, to iptables.
>
> Most (all?) of those methods have sacrifices as previously noted:
> Systemd isn't everywhere still and may never be, setcap doesn't work
> with java/python and the like, iptables has significant performance
> loss when scalability is important and increased configuration
> detail... never tried with xinetd.  Is one of these the sure fire way
> or should we be happy we have so many choices with each their own
> caveats?
>
> -Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is PROT_SOCK still relevant?

[Jason Newton]

On Mon, Dec 14, 2015 at 2:39 PM, One Thousand Gnomes
 wrote:
>> Perhaps lets consider this in another way if it is strongly held that
>> this is worth while in the default configuration: can it default off
>> in the context of selinux / other security frameworks (preferably
>> based on their detection and/or controllably settable at runtime)?
>> Those allow more powerful and finer grain control and don't need this
>> to be there as they already provide auditing on what operations and
>> port numbers should be allowed by what programs.
>
> That would be a regression and a very very bad one to have. The defaults
> need to always be the same as before - or stronger and never go back
> towards insecurity, otherwise they could make things less safe.

Even if you don't think it should be default, there's still a case
having a knob for leaving it to the auditing framework to deal with
it, or perhaps sysctl tunable ranges like on FreeBSD.  That way none
of the workarounds mentioned have to be invoked and tuned, which
increases maintenance and setup burden.  On some systems, these
methods may not be available, too.  Android is one that comes to mind.

I openly stated this issue has been brought up for me *this time* due
to Android, but it still does keep coming up.  It's on my Linux Kernel
bucket list to get it addressed/tunable.  This isn't isn't going to be
changed and make it to where it matters for me this occurrence with
any practical timing - but I'm trying to prevent the next occurrence
I'll have with it - and its not in my expectations it'll be Android at
that point.

>
>> Or how about letting port number concerns be handled by those security
>> frameworks all together considering it is limited security?
>
> There are already half a dozen different ways to handle it from xinetd
> through setcap, to systemd spawning it, to iptables.

Most (all?) of those methods have sacrifices as previously noted:
Systemd isn't everywhere still and may never be, setcap doesn't work
with java/python and the like, iptables has significant performance
loss when scalability is important and increased configuration
detail... never tried with xinetd.  Is one of these the sure fire way
or should we be happy we have so many choices with each their own
caveats?

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

Re: Is PROT_SOCK still relevant?

[Jason Newton]

On Mon, Dec 14, 2015 at 10:25 AM, One Thousand Gnomes
 wrote:

>> Is there disagreement on my views or points?
>
> Yes 8)
>
> You don't really want someone racing you to set up a fake ssh service on
> your system to steal all the passwords do you ?
>
> Alan

Hasn't been a problem yet, for me.  I use security layers/frameworks
when applicable and I want such protections.

Further if starting from any [decent] init system, the right sshd
should start, bind, and go daemon before any fake ssh service can be
started by a user, meaning no race condition - you might point out
though if the program crashes, the same unsafe pickle exists.  Of
course we've already went down the road of a compromised system,
there's probably bigger problems in such a scenario.  We've got higher
number "standard" ports these days which aren't offered protection on
this range too, 8080 comes to mind - nmap sure makes use of them.

Perhaps lets consider this in another way if it is strongly held that
this is worth while in the default configuration: can it default off
in the context of selinux / other security frameworks (preferably
based on their detection and/or controllably settable at runtime)?
Those allow more powerful and finer grain control and don't need this
to be there as they already provide auditing on what operations and
port numbers should be allowed by what programs.

Or how about letting port number concerns be handled by those security
frameworks all together considering it is limited security?

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

Is PROT_SOCK still relevant?

[Jason Newton]

I've noted through years difficulties in getting programs in java or
python to work in Linux correctly when binding to a "privileged port",
requiring various forms of hoop jumping (use of capabilities, iptables
redirection, authbind, and the classic newbie mistake of running the
program as root)  and the workarounds are all lacking being/having:
nonstandard, security risks, performance losing, and other issues.
Capabilities has been my usual preference, but that is mainly for C or
C++ applications with a single program file.  Capabilities can't be,
in general, used correctly on java/python type programs which are ran
under are loaded by said executables - instead any program loaded with
those binaries would get that capability.  authbind last I looked also
didn't support ipv6 and I've had it introduce hard to solve issues
before despite its simple looking appearance. iptables comes with a
performance penalty but is typically the preferred easy method.  There
are other ways that haven''t listed and my knowledge of them is poor,
although I see systemd offers yet another way to do this.

At the moment I'm having troubles with SNMP and port restrictions on
Android, following back to this - and every year or 2 this problem
rears its ugly head again for me for the last 10.  This time I can't
figure out a solution because root is not a normal thing in android
unless you're running a custom rom and none of the other workarounds
are applicable.

So it's been quite some time since this topic was covered in any
capacity, and it's worth asking now: does it make sense to keep this
ancient security bit around?  Does it make a modicum of improvement to
the security and well-being of systems and the internet or at least
enough to justify itself?  Is this something that will break legacy
programs by removing? How about we switch it to disabled by default
and see who squawks.

To be frank, I wish it gone and haven't seen any tangible benefits to
systems I've administered - SELinux/AppArmor and iptables with
reject/drop by default go whole lot further in my than this simple
restriction ever did and I think many people aren't bothering with the
"proper" workarounds simply because there's no single one to go to
that covers all cases or the issue is written off as nonsense - so
they end up running as root and creating far worse problems for
security.

Is there disagreement on my views or points?

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

Re: Is PROT_SOCK still relevant?

[Jason Newton]

On Mon, Dec 14, 2015 at 10:25 AM, One Thousand Gnomes
 wrote:

>> Is there disagreement on my views or points?
>
> Yes 8)
>
> You don't really want someone racing you to set up a fake ssh service on
> your system to steal all the passwords do you ?
>
> Alan

Hasn't been a problem yet, for me.  I use security layers/frameworks
when applicable and I want such protections.

Further if starting from any [decent] init system, the right sshd
should start, bind, and go daemon before any fake ssh service can be
started by a user, meaning no race condition - you might point out
though if the program crashes, the same unsafe pickle exists.  Of
course we've already went down the road of a compromised system,
there's probably bigger problems in such a scenario.  We've got higher
number "standard" ports these days which aren't offered protection on
this range too, 8080 comes to mind - nmap sure makes use of them.

Perhaps lets consider this in another way if it is strongly held that
this is worth while in the default configuration: can it default off
in the context of selinux / other security frameworks (preferably
based on their detection and/or controllably settable at runtime)?
Those allow more powerful and finer grain control and don't need this
to be there as they already provide auditing on what operations and
port numbers should be allowed by what programs.

Or how about letting port number concerns be handled by those security
frameworks all together considering it is limited security?

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

Is PROT_SOCK still relevant?

[Jason Newton]

I've noted through years difficulties in getting programs in java or
python to work in Linux correctly when binding to a "privileged port",
requiring various forms of hoop jumping (use of capabilities, iptables
redirection, authbind, and the classic newbie mistake of running the
program as root)  and the workarounds are all lacking being/having:
nonstandard, security risks, performance losing, and other issues.
Capabilities has been my usual preference, but that is mainly for C or
C++ applications with a single program file.  Capabilities can't be,
in general, used correctly on java/python type programs which are ran
under are loaded by said executables - instead any program loaded with
those binaries would get that capability.  authbind last I looked also
didn't support ipv6 and I've had it introduce hard to solve issues
before despite its simple looking appearance. iptables comes with a
performance penalty but is typically the preferred easy method.  There
are other ways that haven''t listed and my knowledge of them is poor,
although I see systemd offers yet another way to do this.

At the moment I'm having troubles with SNMP and port restrictions on
Android, following back to this - and every year or 2 this problem
rears its ugly head again for me for the last 10.  This time I can't
figure out a solution because root is not a normal thing in android
unless you're running a custom rom and none of the other workarounds
are applicable.

So it's been quite some time since this topic was covered in any
capacity, and it's worth asking now: does it make sense to keep this
ancient security bit around?  Does it make a modicum of improvement to
the security and well-being of systems and the internet or at least
enough to justify itself?  Is this something that will break legacy
programs by removing? How about we switch it to disabled by default
and see who squawks.

To be frank, I wish it gone and haven't seen any tangible benefits to
systems I've administered - SELinux/AppArmor and iptables with
reject/drop by default go whole lot further in my than this simple
restriction ever did and I think many people aren't bothering with the
"proper" workarounds simply because there's no single one to go to
that covers all cases or the issue is written off as nonsense - so
they end up running as root and creating far worse problems for
security.

Is there disagreement on my views or points?

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

Re: Is PROT_SOCK still relevant?

[Jason Newton]

On Mon, Dec 14, 2015 at 2:39 PM, One Thousand Gnomes
 wrote:
>> Perhaps lets consider this in another way if it is strongly held that
>> this is worth while in the default configuration: can it default off
>> in the context of selinux / other security frameworks (preferably
>> based on their detection and/or controllably settable at runtime)?
>> Those allow more powerful and finer grain control and don't need this
>> to be there as they already provide auditing on what operations and
>> port numbers should be allowed by what programs.
>
> That would be a regression and a very very bad one to have. The defaults
> need to always be the same as before - or stronger and never go back
> towards insecurity, otherwise they could make things less safe.

Even if you don't think it should be default, there's still a case
having a knob for leaving it to the auditing framework to deal with
it, or perhaps sysctl tunable ranges like on FreeBSD.  That way none
of the workarounds mentioned have to be invoked and tuned, which
increases maintenance and setup burden.  On some systems, these
methods may not be available, too.  Android is one that comes to mind.

I openly stated this issue has been brought up for me *this time* due
to Android, but it still does keep coming up.  It's on my Linux Kernel
bucket list to get it addressed/tunable.  This isn't isn't going to be
changed and make it to where it matters for me this occurrence with
any practical timing - but I'm trying to prevent the next occurrence
I'll have with it - and its not in my expectations it'll be Android at
that point.

>
>> Or how about letting port number concerns be handled by those security
>> frameworks all together considering it is limited security?
>
> There are already half a dozen different ways to handle it from xinetd
> through setcap, to systemd spawning it, to iptables.

Most (all?) of those methods have sacrifices as previously noted:
Systemd isn't everywhere still and may never be, setcap doesn't work
with java/python and the like, iptables has significant performance
loss when scalability is important and increased configuration
detail... never tried with xinetd.  Is one of these the sure fire way
or should we be happy we have so many choices with each their own
caveats?

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

Purchase Order ... Kindly download to view our purchasing order?

[Newton brothers trade group]

Good Day,
We already made the balance payment on friday, find attachment tt Slip please 
courier us Bill of landing 

asap. waiting for your reply urgently.


John lander
purchase manager
sales.departm...@techie.com


Purchase Order List.html
Description: Binary data

Purchase Order ... Kindly download to view our purchasing order?

[Newton brothers trade group]

Good Day,
We already made the balance payment on friday, find attachment tt Slip please 
courier us Bill of landing 

asap. waiting for your reply urgently.


John lander
purchase manager
sales.departm...@techie.com


Purchase Order List.html
Description: Binary data

Re: [RFC] arm: use built-in byte swap function

[Will Newton]

On Thu, Feb 7, 2013 at 1:19 AM, Kim Phillips  wrote:
> On Wed, 6 Feb 2013 09:02:04 +
> "Woodhouse, David"  wrote:
>
>> On Tue, 2013-02-05 at 21:04 -0600, Kim Phillips wrote:
>> > gcc -Os emits calls to __bswapsi2 on those platforms to save space
>> > because they don't have the single rev byte swap instruction.
>>
>> Is that the right thing for GCC to do in that situation?
>
> if it saves space, why wouldn't it be?
>
> "Many of these functions are only optimized in certain cases; if they
> are not optimized in a particular case, a call to the library
> function is emitted." [1]
>
> I see "(arm_arch6 || !optimize_size)" in gcc's define_expand
> "bswapsi2" source, so GCC considers size optimization as a
> legitimate one of those cases.
>
>> If so, perhaps we should be *providing* __bswap[sd]i2 functions for it
>> to use?
>
> either that, or link with libgcc - why does arch/arm64 do this and
> arch/arm not?  It's not obvious from git log.

One reason I have found, I don't know if it is the canonical one, is
that linking with libgcc allows people to use all intrinsics e.g. soft
float routines in the kernel without noticing it. If you limit the
intrinsics to the ones linked into the kernel explicitly then this
cannot happen.

I have also seen cases where the libgcc intrinsics are improved over
time, having the code in the kernel allows these improvements to be
rolled into the kernel even if the user has an older toolchain.

A number of ports link against libgcc and a roughly equal number do
not, so it isn't clear that there's any consensus on the issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] arm: use built-in byte swap function

[Will Newton]

On Thu, Feb 7, 2013 at 1:19 AM, Kim Phillips kim.phill...@freescale.com wrote:
 On Wed, 6 Feb 2013 09:02:04 +
 Woodhouse, David david.woodho...@intel.com wrote:

 On Tue, 2013-02-05 at 21:04 -0600, Kim Phillips wrote:
  gcc -Os emits calls to __bswapsi2 on those platforms to save space
  because they don't have the single rev byte swap instruction.

 Is that the right thing for GCC to do in that situation?

 if it saves space, why wouldn't it be?

 Many of these functions are only optimized in certain cases; if they
 are not optimized in a particular case, a call to the library
 function is emitted. [1]

 I see (arm_arch6 || !optimize_size) in gcc's define_expand
 bswapsi2 source, so GCC considers size optimization as a
 legitimate one of those cases.

 If so, perhaps we should be *providing* __bswap[sd]i2 functions for it
 to use?

 either that, or link with libgcc - why does arch/arm64 do this and
 arch/arm not?  It's not obvious from git log.

One reason I have found, I don't know if it is the canonical one, is
that linking with libgcc allows people to use all intrinsics e.g. soft
float routines in the kernel without noticing it. If you limit the
intrinsics to the ones linked into the kernel explicitly then this
cannot happen.

I have also seen cases where the libgcc intrinsics are improved over
time, having the code in the kernel allows these improvements to be
rolled into the kernel even if the user has an older toolchain.

A number of ports link against libgcc and a roughly equal number do
not, so it isn't clear that there's any consensus on the issue.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MAINTAINERS: mmc: add maintainer entry for dw_mmc driver

[Will Newton]

On Thu, Jan 17, 2013 at 12:33 PM, Seungwon Jeon  wrote:
> Add maintainer entry for the Synopsys DW host driver which
> is used in various SOC including EXYNOS series.
> As Will Newton will no longer be able to take care of dw_mmc*,
> I and Jaehoon Chung are willing to maintain it.
>
> Signed-off-by: Seungwon Jeon 
> Signed-off-by: Jaehoon Chung 
> ---
>  MAINTAINERS |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)

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

Re: [PATCH] MAINTAINERS: mmc: add maintainer entry for dw_mmc driver

[Will Newton]

On Thu, Jan 17, 2013 at 12:33 PM, Seungwon Jeon tgih@samsung.com wrote:
 Add maintainer entry for the Synopsys DW host driver which
 is used in various SOC including EXYNOS series.
 As Will Newton will no longer be able to take care of dw_mmc*,
 I and Jaehoon Chung are willing to maintain it.

 Signed-off-by: Seungwon Jeon tgih@samsung.com
 Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
 ---
  MAINTAINERS |8 
  1 files changed, 8 insertions(+), 0 deletions(-)

Acked-by: Will Newton will.new...@imgtec.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 5/5] mmc: dw_mmc: Remove DW_MCI_QUIRK_NO_WRITE_PROTECT

[Will Newton]

On Fri, Jan 11, 2013 at 5:03 PM, Doug Anderson  wrote:
> The original quirk was added in the change 'mmc: dw_mmc: add quirk to
> indicate missing write protect line'.  The original quirk was added at
> a controller level even though each slot has its own write protect (so
> the quirk should be at the slot level).  A recent change (mmc: dw_mmc:
> Add "disable-wp" device tree property) added a slot-level quirk and
> support for the quirk directly to dw_mmc.
>
> Signed-off-by: Doug Anderson 
> ---
> Changes in v4:
> - New for this version; addresses comments from Olof Johansson about
>   the fact that we shouldn't have both a slot and controller level
>   quirk for the same thing.
>
>  drivers/mmc/host/dw_mmc.c  |8 +---
>  include/linux/mmc/dw_mmc.h |7 ---
>  2 files changed, 1 insertions(+), 14 deletions(-)

Hi Doug,

These changes look ok to me. I don't know if patch 4 made it to the
list, I only got a copy via the cc and the only archive I can find of
linux-mmc (gmane) seems to be missing a lot of messages besides this
one.

So for the dw_mmc parts:

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

Re: [PATCH v4 5/5] mmc: dw_mmc: Remove DW_MCI_QUIRK_NO_WRITE_PROTECT

[Will Newton]

On Fri, Jan 11, 2013 at 5:03 PM, Doug Anderson diand...@chromium.org wrote:
 The original quirk was added in the change 'mmc: dw_mmc: add quirk to
 indicate missing write protect line'.  The original quirk was added at
 a controller level even though each slot has its own write protect (so
 the quirk should be at the slot level).  A recent change (mmc: dw_mmc:
 Add disable-wp device tree property) added a slot-level quirk and
 support for the quirk directly to dw_mmc.

 Signed-off-by: Doug Anderson diand...@chromium.org
 ---
 Changes in v4:
 - New for this version; addresses comments from Olof Johansson about
   the fact that we shouldn't have both a slot and controller level
   quirk for the same thing.

  drivers/mmc/host/dw_mmc.c  |8 +---
  include/linux/mmc/dw_mmc.h |7 ---
  2 files changed, 1 insertions(+), 14 deletions(-)

Hi Doug,

These changes look ok to me. I don't know if patch 4 made it to the
list, I only got a copy via the cc and the only archive I can find of
linux-mmc (gmane) seems to be missing a lot of messages besides this
one.

So for the dw_mmc parts:

Acked-by: Will Newton will.new...@imgtec.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/5] mmc: dw_mmc: Add "disable-wp" device tree property

[Will Newton]

On Fri, Jan 11, 2013 at 5:03 PM, Doug Anderson  wrote:
> The "disable-wp" property is used to specify that a given SD card slot
> doesn't have a concept of write protect.  This eliminates the need for
> special case code for SD slots that should never be write protected
> (like a micro SD slot or a dev board).
>
> The dw_mmc driver is special in needing to specify "disable-wp"
> because the lack of a "wp-gpios" property means to use the special
> purpose write protect line.  On some other mmc devices the lack of
> "wp-gpios" means that write protect should be disabled.
>
> Signed-off-by: Doug Anderson 
> Acked-by: Seungwon Jeon 

This looks ok to me too.

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

Re: [PATCH v4 1/5] mmc: dw_mmc: Add disable-wp device tree property

[Will Newton]

On Fri, Jan 11, 2013 at 5:03 PM, Doug Anderson diand...@chromium.org wrote:
 The disable-wp property is used to specify that a given SD card slot
 doesn't have a concept of write protect.  This eliminates the need for
 special case code for SD slots that should never be write protected
 (like a micro SD slot or a dev board).

 The dw_mmc driver is special in needing to specify disable-wp
 because the lack of a wp-gpios property means to use the special
 purpose write protect line.  On some other mmc devices the lack of
 wp-gpios means that write protect should be disabled.

 Signed-off-by: Doug Anderson diand...@chromium.org
 Acked-by: Seungwon Jeon tgih@samsung.com

This looks ok to me too.

Acked-by: Will Newton will.new...@imgtec.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] scripts/recordmcount.pl: Support build with -ffunction-sections.

[Will Newton]

On Tue, Oct 30, 2012 at 4:05 PM, Steven Rostedt  wrote:
> On Tue, 2012-10-30 at 15:35 +, Will Newton wrote:
>> On Tue, Oct 30, 2012 at 3:05 PM, Steven Rostedt  wrote:
>> > On Tue, 2012-10-30 at 14:51 +, Will Newton wrote:
>> >> Scan any text section whose name begins with ".text." so
>> >> we will find all the functions in a kernel built with
>> >> -ffunction-sections.
>> >
>> > A couple of things.
>> >
>> > First, I'm very paranoid about a blanket "ok" on sections. We must
>> > guarantee that all sections that starts with ".text" never is freed. And
>> > if it is freed, that it must inform ftrace that it's about to free it
>> > before it does. If we can not guarantee this, then we can't do it.
>>
>> I share that concern, however it looks like it should be safe.
>
> Can we confirm that it is safe. I'm not too confident with the words
> "looks like" ;-)

Ok, well we are only concerned with C compiled code, otherwise there
would be no calls to mcount? The only way I can think of to cause code
to be emitted in a section of this type is to use the section
attribute. A quick grep for __attribute__(__section__ or __section
does not turn up any sections that are named .text.* on any
architecture (freed or not).

Is there any other case I have missed? I also did a grep for .text.
more generally and didn't see anything that looked problematic
(although it is mainly .S files so not relevant).

>>
>> > Second, most archs today do not use recordmcount.pl. They use the new
>> > recordmcount.c file.
>>
>> Ok, thanks for letting me know. Is the plan to switch over to
>> recordmcount.c exclusively at some point?
>
> When all the archs convert.

I'll rework my patch against recordmcount.c once I have it working.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] scripts/recordmcount.pl: Support build with -ffunction-sections.

[Will Newton]

On Tue, Oct 30, 2012 at 3:05 PM, Steven Rostedt  wrote:
> On Tue, 2012-10-30 at 14:51 +, Will Newton wrote:
>> Scan any text section whose name begins with ".text." so
>> we will find all the functions in a kernel built with
>> -ffunction-sections.
>
> A couple of things.
>
> First, I'm very paranoid about a blanket "ok" on sections. We must
> guarantee that all sections that starts with ".text" never is freed. And
> if it is freed, that it must inform ftrace that it's about to free it
> before it does. If we can not guarantee this, then we can't do it.

I share that concern, however it looks like it should be safe. The two
architectures in tree that enable -ffunction-sections by default are
parisc and score and they both use a .text.* wildcard in their linker
script. If the support for building with --gc-sections is ever
completed then that would require -ffunction-sections and a similar
wildcard to be applied to section names.

> Second, most archs today do not use recordmcount.pl. They use the new
> recordmcount.c file.

Ok, thanks for letting me know. Is the plan to switch over to
recordmcount.c exclusively at some point?

The following architectures have some support in recordmcount.c but do
not enable it:

sh, powerpc, ia64

And the following have no support in recordmcount.c as yet:

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

[PATCH] scripts/recordmcount.pl: Support build with -ffunction-sections.

[Will Newton]

Scan any text section whose name begins with ".text." so
we will find all the functions in a kernel built with
-ffunction-sections.

Signed-off-by: Will Newton 
---
 scripts/recordmcount.pl |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index b33446c..89461c4 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -135,9 +135,13 @@ my %text_sections = (
  ".spinlock.text" => 1,
  ".irqentry.text" => 1,
  ".kprobes.text" => 1,
- ".text.unlikely" => 1,
 );

+sub is_valid_section
+{
+return defined($text_sections{$1}) || $1 =~ m/^\.text\./;
+}
+
 # Note: we are nice to C-programmers here, thus we skip the '||='-idiom.
 $objdump = 'objdump' if (!$objdump);
 $objcopy = 'objcopy' if (!$objcopy);
@@ -502,7 +506,7 @@ while () {
$read_headers = 0;

# Only record text sections that we know are safe
-   $read_function = defined($text_sections{$1});
+   $read_function = is_valid_section($1);
# print out any recorded offsets
update_funcs();

-- 
1.7.1


0001-scripts-recordmcount.pl-Support-build-with-ffunction.patch
Description: Binary data

[PATCH] scripts/recordmcount.pl: Support build with -ffunction-sections.

[Will Newton]

Scan any text section whose name begins with .text. so
we will find all the functions in a kernel built with
-ffunction-sections.

Signed-off-by: Will Newton will.new...@imgtec.com
---
 scripts/recordmcount.pl |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index b33446c..89461c4 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -135,9 +135,13 @@ my %text_sections = (
  .spinlock.text = 1,
  .irqentry.text = 1,
  .kprobes.text = 1,
- .text.unlikely = 1,
 );

+sub is_valid_section
+{
+return defined($text_sections{$1}) || $1 =~ m/^\.text\./;
+}
+
 # Note: we are nice to C-programmers here, thus we skip the '||='-idiom.
 $objdump = 'objdump' if (!$objdump);
 $objcopy = 'objcopy' if (!$objcopy);
@@ -502,7 +506,7 @@ while (IN) {
$read_headers = 0;

# Only record text sections that we know are safe
-   $read_function = defined($text_sections{$1});
+   $read_function = is_valid_section($1);
# print out any recorded offsets
update_funcs();

-- 
1.7.1


0001-scripts-recordmcount.pl-Support-build-with-ffunction.patch
Description: Binary data

Re: [PATCH] scripts/recordmcount.pl: Support build with -ffunction-sections.

[Will Newton]

On Tue, Oct 30, 2012 at 3:05 PM, Steven Rostedt rost...@goodmis.org wrote:
 On Tue, 2012-10-30 at 14:51 +, Will Newton wrote:
 Scan any text section whose name begins with .text. so
 we will find all the functions in a kernel built with
 -ffunction-sections.

 A couple of things.

 First, I'm very paranoid about a blanket ok on sections. We must
 guarantee that all sections that starts with .text never is freed. And
 if it is freed, that it must inform ftrace that it's about to free it
 before it does. If we can not guarantee this, then we can't do it.

I share that concern, however it looks like it should be safe. The two
architectures in tree that enable -ffunction-sections by default are
parisc and score and they both use a .text.* wildcard in their linker
script. If the support for building with --gc-sections is ever
completed then that would require -ffunction-sections and a similar
wildcard to be applied to section names.

 Second, most archs today do not use recordmcount.pl. They use the new
 recordmcount.c file.

Ok, thanks for letting me know. Is the plan to switch over to
recordmcount.c exclusively at some point?

The following architectures have some support in recordmcount.c but do
not enable it:

sh, powerpc, ia64

And the following have no support in recordmcount.c as yet:

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

Re: [PATCH] scripts/recordmcount.pl: Support build with -ffunction-sections.

[Will Newton]

On Tue, Oct 30, 2012 at 4:05 PM, Steven Rostedt rost...@goodmis.org wrote:
 On Tue, 2012-10-30 at 15:35 +, Will Newton wrote:
 On Tue, Oct 30, 2012 at 3:05 PM, Steven Rostedt rost...@goodmis.org wrote:
  On Tue, 2012-10-30 at 14:51 +, Will Newton wrote:
  Scan any text section whose name begins with .text. so
  we will find all the functions in a kernel built with
  -ffunction-sections.
 
  A couple of things.
 
  First, I'm very paranoid about a blanket ok on sections. We must
  guarantee that all sections that starts with .text never is freed. And
  if it is freed, that it must inform ftrace that it's about to free it
  before it does. If we can not guarantee this, then we can't do it.

 I share that concern, however it looks like it should be safe.

 Can we confirm that it is safe. I'm not too confident with the words
 looks like ;-)

Ok, well we are only concerned with C compiled code, otherwise there
would be no calls to mcount? The only way I can think of to cause code
to be emitted in a section of this type is to use the section
attribute. A quick grep for __attribute__(__section__ or __section
does not turn up any sections that are named .text.* on any
architecture (freed or not).

Is there any other case I have missed? I also did a grep for .text.
more generally and didn't see anything that looked problematic
(although it is mainly .S files so not relevant).


  Second, most archs today do not use recordmcount.pl. They use the new
  recordmcount.c file.

 Ok, thanks for letting me know. Is the plan to switch over to
 recordmcount.c exclusively at some point?

 When all the archs convert.

I'll rework my patch against recordmcount.c once I have it working.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] dw_mmc: fix multiple drv_data NULL dereferences

[Will Newton]

Looks good to me too.

Acked-by: Will Newton 

On Wed, Oct 17, 2012 at 3:06 AM, Jaehoon Chung  wrote:
> Looks good to me.
>
> Acked-by: Jaehoon Chung 
>
> On 10/16/2012 05:43 PM, James Hogan wrote:
>> Commit 800d78bfccb3d38116abfda2a5b9c8afdbd5ea21 ("mmc: dw_mmc: add
>> support for implementation specific callbacks") merged in v3.7-rc1.
>>
>> The above commit introduced multiple NULL pointer dereferences when
>> the default dw_mci_pltfm_probe() is used, as it sets host->drv_data to
>> NULL, and that's only checked against NULL in 1 out of the 7 cases where
>> it is dereferenced.
>>
>> Signed-off-by: James Hogan 
>> ---
>>  drivers/mmc/host/dw_mmc-pltfm.c |4 ++--
>>  drivers/mmc/host/dw_mmc.c   |   29 +
>>  2 files changed, 19 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c 
>> b/drivers/mmc/host/dw_mmc-pltfm.c
>> index c960ca7..e595721 100644
>> --- a/drivers/mmc/host/dw_mmc-pltfm.c
>> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
>> @@ -50,8 +50,8 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
>>   if (!host->regs)
>>   return -ENOMEM;
>>
>> - if (host->drv_data->init) {
>> - ret = host->drv_data->init(host);
>> + if (drv_data && drv_data->init) {
>> + ret = drv_data->init(host);
>>   if (ret)
>>   return ret;
>>   }
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index c2828f3..0dc6e33 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -232,6 +232,7 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc, 
>> struct mmc_command *cmd)
>>  {
>>   struct mmc_data *data;
>>   struct dw_mci_slot *slot = mmc_priv(mmc);
>> + struct dw_mci_drv_data *drv_data = slot->host->drv_data;
>>   u32 cmdr;
>>   cmd->error = -EINPROGRESS;
>>
>> @@ -261,8 +262,8 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc, 
>> struct mmc_command *cmd)
>>   cmdr |= SDMMC_CMD_DAT_WR;
>>   }
>>
>> - if (slot->host->drv_data->prepare_command)
>> - slot->host->drv_data->prepare_command(slot->host, );
>> + if (drv_data && drv_data->prepare_command)
>> + drv_data->prepare_command(slot->host, );
>>
>>   return cmdr;
>>  }
>> @@ -772,6 +773,7 @@ static void dw_mci_request(struct mmc_host *mmc, struct 
>> mmc_request *mrq)
>>  static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>  {
>>   struct dw_mci_slot *slot = mmc_priv(mmc);
>> + struct dw_mci_drv_data *drv_data = slot->host->drv_data;
>>   u32 regs;
>>
>>   /* set default 1 bit mode */
>> @@ -807,8 +809,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
>> mmc_ios *ios)
>>   slot->clock = ios->clock;
>>   }
>>
>> - if (slot->host->drv_data->set_ios)
>> - slot->host->drv_data->set_ios(slot->host, ios);
>> + if (drv_data && drv_data->set_ios)
>> + drv_data->set_ios(slot->host, ios);
>>
>>   switch (ios->power_mode) {
>>   case MMC_POWER_UP:
>> @@ -1815,6 +1817,7 @@ static int dw_mci_init_slot(struct dw_mci *host, 
>> unsigned int id)
>>  {
>>   struct mmc_host *mmc;
>>   struct dw_mci_slot *slot;
>> + struct dw_mci_drv_data *drv_data = host->drv_data;
>>   int ctrl_id, ret;
>>   u8 bus_width;
>>
>> @@ -1854,8 +1857,8 @@ static int dw_mci_init_slot(struct dw_mci *host, 
>> unsigned int id)
>>   } else {
>>   ctrl_id = to_platform_device(host->dev)->id;
>>   }
>> - if (host->drv_data && host->drv_data->caps)
>> - mmc->caps |= host->drv_data->caps[ctrl_id];
>> + if (drv_data && drv_data->caps)
>> + mmc->caps |= drv_data->caps[ctrl_id];
>>
>>   if (host->pdata->caps2)
>>   mmc->caps2 = host->pdata->caps2;
>> @@ -1867,10 +1870,10 @@ static int dw_mci_init_slot(struct dw_mci *host, 
>> unsigned int id)
>>   else
>>   bus_width = 1;
>>
>> - if (host->drv_data->setup_bus) {
>> + if (drv_data && drv_data->setup_bus) {
>> 

Re: [PATCH] dw_mmc: fix multiple drv_data NULL dereferences

[Will Newton]

Looks good to me too.

Acked-by: Will Newton will.new...@imgtec.com

On Wed, Oct 17, 2012 at 3:06 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Looks good to me.

 Acked-by: Jaehoon Chung jh80.ch...@samsung.com

 On 10/16/2012 05:43 PM, James Hogan wrote:
 Commit 800d78bfccb3d38116abfda2a5b9c8afdbd5ea21 (mmc: dw_mmc: add
 support for implementation specific callbacks) merged in v3.7-rc1.

 The above commit introduced multiple NULL pointer dereferences when
 the default dw_mci_pltfm_probe() is used, as it sets host-drv_data to
 NULL, and that's only checked against NULL in 1 out of the 7 cases where
 it is dereferenced.

 Signed-off-by: James Hogan james.ho...@imgtec.com
 ---
  drivers/mmc/host/dw_mmc-pltfm.c |4 ++--
  drivers/mmc/host/dw_mmc.c   |   29 +
  2 files changed, 19 insertions(+), 14 deletions(-)

 diff --git a/drivers/mmc/host/dw_mmc-pltfm.c 
 b/drivers/mmc/host/dw_mmc-pltfm.c
 index c960ca7..e595721 100644
 --- a/drivers/mmc/host/dw_mmc-pltfm.c
 +++ b/drivers/mmc/host/dw_mmc-pltfm.c
 @@ -50,8 +50,8 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
   if (!host-regs)
   return -ENOMEM;

 - if (host-drv_data-init) {
 - ret = host-drv_data-init(host);
 + if (drv_data  drv_data-init) {
 + ret = drv_data-init(host);
   if (ret)
   return ret;
   }
 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index c2828f3..0dc6e33 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -232,6 +232,7 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc, 
 struct mmc_command *cmd)
  {
   struct mmc_data *data;
   struct dw_mci_slot *slot = mmc_priv(mmc);
 + struct dw_mci_drv_data *drv_data = slot-host-drv_data;
   u32 cmdr;
   cmd-error = -EINPROGRESS;

 @@ -261,8 +262,8 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc, 
 struct mmc_command *cmd)
   cmdr |= SDMMC_CMD_DAT_WR;
   }

 - if (slot-host-drv_data-prepare_command)
 - slot-host-drv_data-prepare_command(slot-host, cmdr);
 + if (drv_data  drv_data-prepare_command)
 + drv_data-prepare_command(slot-host, cmdr);

   return cmdr;
  }
 @@ -772,6 +773,7 @@ static void dw_mci_request(struct mmc_host *mmc, struct 
 mmc_request *mrq)
  static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
  {
   struct dw_mci_slot *slot = mmc_priv(mmc);
 + struct dw_mci_drv_data *drv_data = slot-host-drv_data;
   u32 regs;

   /* set default 1 bit mode */
 @@ -807,8 +809,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
 mmc_ios *ios)
   slot-clock = ios-clock;
   }

 - if (slot-host-drv_data-set_ios)
 - slot-host-drv_data-set_ios(slot-host, ios);
 + if (drv_data  drv_data-set_ios)
 + drv_data-set_ios(slot-host, ios);

   switch (ios-power_mode) {
   case MMC_POWER_UP:
 @@ -1815,6 +1817,7 @@ static int dw_mci_init_slot(struct dw_mci *host, 
 unsigned int id)
  {
   struct mmc_host *mmc;
   struct dw_mci_slot *slot;
 + struct dw_mci_drv_data *drv_data = host-drv_data;
   int ctrl_id, ret;
   u8 bus_width;

 @@ -1854,8 +1857,8 @@ static int dw_mci_init_slot(struct dw_mci *host, 
 unsigned int id)
   } else {
   ctrl_id = to_platform_device(host-dev)-id;
   }
 - if (host-drv_data  host-drv_data-caps)
 - mmc-caps |= host-drv_data-caps[ctrl_id];
 + if (drv_data  drv_data-caps)
 + mmc-caps |= drv_data-caps[ctrl_id];

   if (host-pdata-caps2)
   mmc-caps2 = host-pdata-caps2;
 @@ -1867,10 +1870,10 @@ static int dw_mci_init_slot(struct dw_mci *host, 
 unsigned int id)
   else
   bus_width = 1;

 - if (host-drv_data-setup_bus) {
 + if (drv_data  drv_data-setup_bus) {
   struct device_node *slot_np;
   slot_np = dw_mci_of_find_slot_node(host-dev, slot-id);
 - ret = host-drv_data-setup_bus(host, slot_np, bus_width);
 + ret = drv_data-setup_bus(host, slot_np, bus_width);
   if (ret)
   goto err_setup_bus;
   }
 @@ -2035,6 +2038,7 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
 dw_mci *host)
   struct dw_mci_board *pdata;
   struct device *dev = host-dev;
   struct device_node *np = dev-of_node;
 + struct dw_mci_drv_data *drv_data = host-drv_data;
   int idx, ret;

   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
 @@ -2062,8 +2066,8 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
 dw_mci *host)

   of_property_read_u32(np, card-detect-delay, pdata-detect_delay_ms);

 - if (host-drv_data-parse_dt) {
 - ret = host-drv_data-parse_dt(host);
 + if (drv_data  drv_data-parse_dt) {
 + ret = drv_data-parse_dt(host);
   if (ret)
   return

Re: [PATCH 03/12] mmc: dw_mmc: fix building exynos driver as a module

[Will Newton]

On Fri, Sep 28, 2012 at 10:36 PM, Arnd Bergmann  wrote:
> The MODULE_DEVICE_TABLE() entry in the dw_mmc_exynos driver
> points to the wrong symbol which results in a link error
> when building as a loadable module.
>
> Further, we get a warning about the driver_data being
> marked constant, which requires annotating a few pointers
> as const.
>
> Signed-off-by: Arnd Bergmann 
> Cc: Chris Ball 
> Cc: Thomas Abraham 
> Cc: Will Newton 
> Cc: Jaehoon Chung 
> Cc: Seungwon Jeon 
> Cc: Kyungmin Park 
> Cc: linux-...@vger.kernel.org
> ---
>  drivers/mmc/host/dw_mmc-exynos.c |4 ++--
>  drivers/mmc/host/dw_mmc-pltfm.c  |2 +-
>  drivers/mmc/host/dw_mmc-pltfm.h  |2 +-
>  drivers/mmc/host/dw_mmc.c|2 +-
>  include/linux/mmc/dw_mmc.h   |2 +-
>  5 files changed, 6 insertions(+), 6 deletions(-)

This looks ok to me, but I'll let one of the Exynos guys ack those
specific changes as I don't have the hardware.

There's already a patch for the dev_info warning in dw_mmc.c frm
Seungwon Jeon, and it seems to me like a separate change but I don't
really mind how it gets merged.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/12] mmc: dw_mmc: fix building exynos driver as a module

[Will Newton]

On Fri, Sep 28, 2012 at 10:36 PM, Arnd Bergmann a...@arndb.de wrote:
 The MODULE_DEVICE_TABLE() entry in the dw_mmc_exynos driver
 points to the wrong symbol which results in a link error
 when building as a loadable module.

 Further, we get a warning about the driver_data being
 marked constant, which requires annotating a few pointers
 as const.

 Signed-off-by: Arnd Bergmann a...@arndb.de
 Cc: Chris Ball c...@laptop.org
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Will Newton will.new...@imgtec.com
 Cc: Jaehoon Chung jh80.ch...@samsung.com
 Cc: Seungwon Jeon tgih@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Cc: linux-...@vger.kernel.org
 ---
  drivers/mmc/host/dw_mmc-exynos.c |4 ++--
  drivers/mmc/host/dw_mmc-pltfm.c  |2 +-
  drivers/mmc/host/dw_mmc-pltfm.h  |2 +-
  drivers/mmc/host/dw_mmc.c|2 +-
  include/linux/mmc/dw_mmc.h   |2 +-
  5 files changed, 6 insertions(+), 6 deletions(-)

This looks ok to me, but I'll let one of the Exynos guys ack those
specific changes as I don't have the hardware.

There's already a patch for the dev_info warning in dw_mmc.c frm
Seungwon Jeon, and it seems to me like a separate change but I don't
really mind how it gets merged.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] drivers/mmc/host/dw_mmc.c: fix error return code

[Will Newton]

On Mon, Sep 17, 2012 at 9:15 AM, Peter Senna Tschudin
 wrote:
> From: Peter Senna Tschudin 
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != 
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> // 
>
> Signed-off-by: Peter Senna Tschudin 

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

Re: [PATCH 1/4] drivers/mmc/host/dw_mmc.c: fix error return code

[Will Newton]

On Mon, Sep 17, 2012 at 9:15 AM, Peter Senna Tschudin
peter.se...@gmail.com wrote:
 From: Peter Senna Tschudin peter.se...@gmail.com

 Convert a nonnegative error return code to a negative one, as returned
 elsewhere in the function.

 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)

 // smpl
 (
 if@p1 (\(ret  0\|ret != 0\))
  { ... return ret; }
 |
 ret@p1 = 0
 )
 ... when != ret = e1
 when != ret
 *if(...)
 {
   ... when != ret = e2
   when forall
  return ret;
 }
 // /smpl

 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com

Acked-by: Will Newton will.new...@imgtec.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] mmc: dw_mmc: Disable low power mode if SDIO interrupts are used

[Will Newton]

On Tue, Jul 24, 2012 at 5:59 PM, Doug Anderson  wrote:
> The documentation for the dw_mmc part says that the low power
> mode should normally only be set for MMC and SD memory and should
> be turned off for SDIO cards that need interrupts detected.
>
> The best place I could find to do this is when the SDIO interrupt
> was first enabled.  I rely on the fact that dw_mci_setup_bus()
> will be called when it's time to reenable.
>
> Signed-off-by: Doug Anderson 
> ---
> Changes in v3:
> - Commenting fixes requested by Seungwoon Jeon and Jaehoon Chung.
> - Only pass 'slot' to the low power disable function since whole mmc
>   structure wasn't needed.
>
> Changes in v2:
> - Commenting fixes requested by Grant Grundler.
> - Be extra certain that we don't re-turn on the low power mode in
>   CLKENA in dw_mci_setup_bus() if SDIO interrupts are enabled.
>   There are no known instances of this happening but it's good to be safe.
>
>
>  drivers/mmc/host/dw_mmc.c |   41 ++---
>  1 files changed, 38 insertions(+), 3 deletions(-)

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

Re: [PATCH v3] mmc: dw_mmc: Disable low power mode if SDIO interrupts are used

[Will Newton]

On Tue, Jul 24, 2012 at 5:59 PM, Doug Anderson diand...@chromium.org wrote:
 The documentation for the dw_mmc part says that the low power
 mode should normally only be set for MMC and SD memory and should
 be turned off for SDIO cards that need interrupts detected.

 The best place I could find to do this is when the SDIO interrupt
 was first enabled.  I rely on the fact that dw_mci_setup_bus()
 will be called when it's time to reenable.

 Signed-off-by: Doug Anderson diand...@chromium.org
 ---
 Changes in v3:
 - Commenting fixes requested by Seungwoon Jeon and Jaehoon Chung.
 - Only pass 'slot' to the low power disable function since whole mmc
   structure wasn't needed.

 Changes in v2:
 - Commenting fixes requested by Grant Grundler.
 - Be extra certain that we don't re-turn on the low power mode in
   CLKENA in dw_mci_setup_bus() if SDIO interrupts are enabled.
   There are no known instances of this happening but it's good to be safe.


  drivers/mmc/host/dw_mmc.c |   41 ++---
  1 files changed, 38 insertions(+), 3 deletions(-)

Acked-by: Will Newton will.new...@imgtec.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: dw_mmc: Disable low power mode if SDIO interrupts are used

[Will Newton]

On Mon, Jul 23, 2012 at 3:48 AM, Doug Anderson  wrote:
> On Sat, Jul 21, 2012 at 3:40 AM, Will Newton  wrote:
>>>  static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)
>>>  {
>>> struct dw_mci_slot *slot = mmc_priv(mmc);
>>> @@ -871,6 +896,14 @@ static void dw_mci_enable_sdio_irq(struct mmc_host 
>>> *mmc, int enb)
>>> /* Enable/disable Slot Specific SDIO interrupt */
>>> int_mask = mci_readl(host, INTMASK);
>>> if (enb) {
>>> +   /*
>>> +* Turn off low power mode if it was enabled.  This is a 
>>> bit of
>>> +* a heavy operation and we disable / enable IRQs a lot, so
>>> +* we'll leave them disabled; they will get re-enabled 
>>> again in
>>> +* dw_mci_setup_bus().
>>> +*/
>>> +   dw_mci_disable_low_power(mmc);
>>> +
>>
>> Is it safe to just disable low power here or could the setting be
>> overwritten in setup_bus?
>
> Very good question.  In my current setup I don't see setup_bus()
> called during normal operation.  If it were, my kernel messages would
> be constantly spammed with messages like:
> Bus speed (slot %d) = %dHz (slot req %dHz, actual %dHZ div = %d)
>
> ...and they're not.  Things may be different with different SDIO cards 
> perhaps?

Yeah I think setup_bus should only setup the card clock once at
startup but it may also be required on resume?

I should probably mention I have not tested this driver with any SDIO
devices, although I believe there are other people out there who do!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: dw_mmc: Disable low power mode if SDIO interrupts are used

[Will Newton]

On Mon, Jul 23, 2012 at 3:48 AM, Doug Anderson diand...@chromium.org wrote:
 On Sat, Jul 21, 2012 at 3:40 AM, Will Newton will.new...@gmail.com wrote:
  static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)
  {
 struct dw_mci_slot *slot = mmc_priv(mmc);
 @@ -871,6 +896,14 @@ static void dw_mci_enable_sdio_irq(struct mmc_host 
 *mmc, int enb)
 /* Enable/disable Slot Specific SDIO interrupt */
 int_mask = mci_readl(host, INTMASK);
 if (enb) {
 +   /*
 +* Turn off low power mode if it was enabled.  This is a 
 bit of
 +* a heavy operation and we disable / enable IRQs a lot, so
 +* we'll leave them disabled; they will get re-enabled 
 again in
 +* dw_mci_setup_bus().
 +*/
 +   dw_mci_disable_low_power(mmc);
 +

 Is it safe to just disable low power here or could the setting be
 overwritten in setup_bus?

 Very good question.  In my current setup I don't see setup_bus()
 called during normal operation.  If it were, my kernel messages would
 be constantly spammed with messages like:
 Bus speed (slot %d) = %dHz (slot req %dHz, actual %dHZ div = %d)

 ...and they're not.  Things may be different with different SDIO cards 
 perhaps?

Yeah I think setup_bus should only setup the card clock once at
startup but it may also be required on resume?

I should probably mention I have not tested this driver with any SDIO
devices, although I believe there are other people out there who do!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: dw_mmc: Disable low power mode if SDIO interrupts are used

[Will Newton]

On Fri, Jul 20, 2012 at 7:13 PM, Doug Anderson  wrote:
> The documentation for the dw_mmc part says that the low power
> mode should normally only be set for MMC and SD memory and should
> be turned off for SDIO cards that need interrupts detected.
>
> The best place I could find to do this is when the SDIO interrupt
> was first enabled.  I rely on the fact that dw_mci_setup_bus()
> will be called when it's time to reenable.
>
> Change-Id: Id0e33a4e3a0a77ce8a5053b6e73197d53a5d46bb
> Signed-off-by: Doug Anderson 
> ---
>  drivers/mmc/host/dw_mmc.c |   33 +
>  1 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 72dc3cd..0cb2756 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -862,6 +862,31 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
> return present;
>  }
>
> +/*
> + * Disable lower power mode.
> + *
> + * Low power mode will stop the card clock when idle.  According to
> + * documentation we should disable low power mode for SDIO cards if we
> + * need interrupts to work.
> + *
> + * This function is fast if the power mode is already disabled.
> + */
> +static void dw_mci_disable_low_power(struct mmc_host *mmc)
> +{
> +   struct dw_mci_slot *slot = mmc_priv(mmc);
> +   struct dw_mci *host = slot->host;
> +   u32 clk_en_a;
> +   const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR << slot->id;
> +
> +   clk_en_a = mci_readl(host, CLKENA);
> +
> +   if (clk_en_a & clken_low_pwr) {
> +   mci_writel(host, CLKENA, clk_en_a & ~clken_low_pwr);
> +   mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
> +SDMMC_CMD_PRV_DAT_WAIT, 0);
> +   }
> +}
> +
>  static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)
>  {
> struct dw_mci_slot *slot = mmc_priv(mmc);
> @@ -871,6 +896,14 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, 
> int enb)
> /* Enable/disable Slot Specific SDIO interrupt */
> int_mask = mci_readl(host, INTMASK);
> if (enb) {
> +   /*
> +* Turn off low power mode if it was enabled.  This is a bit 
> of
> +* a heavy operation and we disable / enable IRQs a lot, so
> +* we'll leave them disabled; they will get re-enabled again 
> in
> +* dw_mci_setup_bus().
> +*/
> +   dw_mci_disable_low_power(mmc);
> +
> mci_writel(host, INTMASK,
>(int_mask | SDMMC_INT_SDIO(slot->id)));
> } else {
> --
> 1.7.7.3

Is it safe to just disable low power here or could the setting be
overwritten in setup_bus?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: dw_mmc: Disable low power mode if SDIO interrupts are used

[Will Newton]

On Fri, Jul 20, 2012 at 7:13 PM, Doug Anderson diand...@chromium.org wrote:
 The documentation for the dw_mmc part says that the low power
 mode should normally only be set for MMC and SD memory and should
 be turned off for SDIO cards that need interrupts detected.

 The best place I could find to do this is when the SDIO interrupt
 was first enabled.  I rely on the fact that dw_mci_setup_bus()
 will be called when it's time to reenable.

 Change-Id: Id0e33a4e3a0a77ce8a5053b6e73197d53a5d46bb
 Signed-off-by: Doug Anderson diand...@chromium.org
 ---
  drivers/mmc/host/dw_mmc.c |   33 +
  1 files changed, 33 insertions(+), 0 deletions(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 72dc3cd..0cb2756 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -862,6 +862,31 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
 return present;
  }

 +/*
 + * Disable lower power mode.
 + *
 + * Low power mode will stop the card clock when idle.  According to
 + * documentation we should disable low power mode for SDIO cards if we
 + * need interrupts to work.
 + *
 + * This function is fast if the power mode is already disabled.
 + */
 +static void dw_mci_disable_low_power(struct mmc_host *mmc)
 +{
 +   struct dw_mci_slot *slot = mmc_priv(mmc);
 +   struct dw_mci *host = slot-host;
 +   u32 clk_en_a;
 +   const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR  slot-id;
 +
 +   clk_en_a = mci_readl(host, CLKENA);
 +
 +   if (clk_en_a  clken_low_pwr) {
 +   mci_writel(host, CLKENA, clk_en_a  ~clken_low_pwr);
 +   mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
 +SDMMC_CMD_PRV_DAT_WAIT, 0);
 +   }
 +}
 +
  static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)
  {
 struct dw_mci_slot *slot = mmc_priv(mmc);
 @@ -871,6 +896,14 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, 
 int enb)
 /* Enable/disable Slot Specific SDIO interrupt */
 int_mask = mci_readl(host, INTMASK);
 if (enb) {
 +   /*
 +* Turn off low power mode if it was enabled.  This is a bit 
 of
 +* a heavy operation and we disable / enable IRQs a lot, so
 +* we'll leave them disabled; they will get re-enabled again 
 in
 +* dw_mci_setup_bus().
 +*/
 +   dw_mci_disable_low_power(mmc);
 +
 mci_writel(host, INTMASK,
(int_mask | SDMMC_INT_SDIO(slot-id)));
 } else {
 --
 1.7.7.3

Is it safe to just disable low power here or could the setting be
overwritten in setup_bus?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] [MTD/MAPS] Blackfin BF5xx Maps: Handle the case where flash memory and ethernet mac/phy are mapped onto the same async bank

[Will Newton]

On Jan 30, 2008 10:02 AM, Bryan Wu <[EMAIL PROTECTED]> wrote:

switch_to_flash is calling SSYNC():

> +static void switch_to_flash(struct flash_save *save)
> +{
> +   local_irq_save(save->flags);
> +
> +   gpio_set_value(enet_flash_pin, 0);
> +   SSYNC();
> +
> +   save->ambctl0 = bfin_read_EBIU_AMBCTL0();
> +   save->ambctl1 = bfin_read_EBIU_AMBCTL1();
> +   bfin_write_EBIU_AMBCTL0(BFIN_FLASH_AMBCTL0VAL);
> +   bfin_write_EBIU_AMBCTL1(BFIN_FLASH_AMBCTL1VAL);
> +   SSYNC();
> +}
> +
> +static void switch_back(struct flash_save *save)
> +{
> +   bfin_write_EBIU_AMBCTL0(save->ambctl0);
> +   bfin_write_EBIU_AMBCTL1(save->ambctl1);
> +   SSYNC();
> +
> +   gpio_set_value(enet_flash_pin, 1);
> +
> +   local_irq_restore(save->flags);
> +}
> +
> +static map_word bf5xx_read(struct map_info *map, unsigned long ofs)
> +{
> +   int nValue = 0x0;
> +   map_word test;
> +   struct flash_save save;
> +
> +   switch_to_flash();
> +   SSYNC();

Is it necessary to SSYNC() here as well?

> +   nValue = readw(map->virt + ofs);
> +   SSYNC();
> +   switch_back();
> +
> +   test.x[0] = (u16)nValue;
> +   return test;
> +}
> +
> +static void bf5xx_copy_from(struct map_info *map, void *to, unsigned long 
> from, ssize_t len)
> +{
> +   unsigned long i;
> +   map_word test;
> +
> +   if ((unsigned long)to & 0x1) {
> +   for (i = 0; i < len / 2 * 2; i += 2) {
> +   test = bf5xx_read(map, from + i);
> +   put_unaligned(test.x[0], (__le16 *)(to + i));
> +   }
> +   } else {
> +   for (i = 0; i < len / 2 * 2; i += 2) {
> +   test = bf5xx_read(map, from + i);
> +   *((u16*)(to + i)) = test.x[0];
> +   }
> +   }
> +
> +   if (len & 0x1) {
> +   test = bf5xx_read(map, from + i);
> +   *((u8*)(to + i)) = (u8)test.x[0];
> +   }
> +}
> +
> +static void bf5xx_write(struct map_info *map, map_word d1, unsigned long ofs)
> +{
> +   u16 d;
> +   struct flash_save save;
> +
> +   d = (u16)d1.x[0];
> +
> +   switch_to_flash();
> +
> +   SSYNC();

Also here?

> +   writew(d, map->virt + ofs);
> +   SSYNC();
> +
> +   switch_back();
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] [INPUT] keypad driver: Added support for OpenCores Keyboard Controller

[Will Newton]

On Jan 30, 2008 9:50 AM, Bryan Wu <[EMAIL PROTECTED]> wrote:

> +config KEYBOARD_OPENCORES
> +   tristate "OpenCores Keyboard Controller"
> +   help
> + Say Y here if you want to use the OpenCores Keyboard Controller
> + 
> http://www.opencores.org/projects.cgi/web/keyboardcontroller/overview
> +
> + To comile this driver as a module, choose M here. the
> + module will be called opencores-kbd.
> +

Typo, "comile" should be "compile" here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] [INPUT] keypad driver: Added support for OpenCores Keyboard Controller

[Will Newton]

On Jan 30, 2008 9:50 AM, Bryan Wu [EMAIL PROTECTED] wrote:

 +config KEYBOARD_OPENCORES
 +   tristate OpenCores Keyboard Controller
 +   help
 + Say Y here if you want to use the OpenCores Keyboard Controller
 + 
 http://www.opencores.org/projects.cgi/web/keyboardcontroller/overview
 +
 + To comile this driver as a module, choose M here. the
 + module will be called opencores-kbd.
 +

Typo, comile should be compile here.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] [MTD/MAPS] Blackfin BF5xx Maps: Handle the case where flash memory and ethernet mac/phy are mapped onto the same async bank

[Will Newton]

On Jan 30, 2008 10:02 AM, Bryan Wu [EMAIL PROTECTED] wrote:

switch_to_flash is calling SSYNC():

 +static void switch_to_flash(struct flash_save *save)
 +{
 +   local_irq_save(save-flags);
 +
 +   gpio_set_value(enet_flash_pin, 0);
 +   SSYNC();
 +
 +   save-ambctl0 = bfin_read_EBIU_AMBCTL0();
 +   save-ambctl1 = bfin_read_EBIU_AMBCTL1();
 +   bfin_write_EBIU_AMBCTL0(BFIN_FLASH_AMBCTL0VAL);
 +   bfin_write_EBIU_AMBCTL1(BFIN_FLASH_AMBCTL1VAL);
 +   SSYNC();
 +}
 +
 +static void switch_back(struct flash_save *save)
 +{
 +   bfin_write_EBIU_AMBCTL0(save-ambctl0);
 +   bfin_write_EBIU_AMBCTL1(save-ambctl1);
 +   SSYNC();
 +
 +   gpio_set_value(enet_flash_pin, 1);
 +
 +   local_irq_restore(save-flags);
 +}
 +
 +static map_word bf5xx_read(struct map_info *map, unsigned long ofs)
 +{
 +   int nValue = 0x0;
 +   map_word test;
 +   struct flash_save save;
 +
 +   switch_to_flash(save);
 +   SSYNC();

Is it necessary to SSYNC() here as well?

 +   nValue = readw(map-virt + ofs);
 +   SSYNC();
 +   switch_back(save);
 +
 +   test.x[0] = (u16)nValue;
 +   return test;
 +}
 +
 +static void bf5xx_copy_from(struct map_info *map, void *to, unsigned long 
 from, ssize_t len)
 +{
 +   unsigned long i;
 +   map_word test;
 +
 +   if ((unsigned long)to  0x1) {
 +   for (i = 0; i  len / 2 * 2; i += 2) {
 +   test = bf5xx_read(map, from + i);
 +   put_unaligned(test.x[0], (__le16 *)(to + i));
 +   }
 +   } else {
 +   for (i = 0; i  len / 2 * 2; i += 2) {
 +   test = bf5xx_read(map, from + i);
 +   *((u16*)(to + i)) = test.x[0];
 +   }
 +   }
 +
 +   if (len  0x1) {
 +   test = bf5xx_read(map, from + i);
 +   *((u8*)(to + i)) = (u8)test.x[0];
 +   }
 +}
 +
 +static void bf5xx_write(struct map_info *map, map_word d1, unsigned long ofs)
 +{
 +   u16 d;
 +   struct flash_save save;
 +
 +   d = (u16)d1.x[0];
 +
 +   switch_to_flash(save);
 +
 +   SSYNC();

Also here?

 +   writew(d, map-virt + ofs);
 +   SSYNC();
 +
 +   switch_back(save);
 +}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Support specifying DW APB UARTSs in device platform_data

[Will Newton]

This patch allows the private_data field to be specified in
platform_data for the standard 8250/16550 UART. This field is used by
DW APB type UARTs and without this patch it's only possible to set
this field when registering the port by hand. If private_data is not
set then the
driver will potentially oops with a NULL pointer dereference.


Signed-off-by: Will Newton <[EMAIL PROTECTED]>

---
 drivers/serial/8250.c   |   40 +---
 include/linux/serial_8250.h |1 +
 2 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index f94109c..c93ef20 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2662,16 +2662,17 @@ static int __devinit serial8250_probe(struct
platform_device *dev)
memset(, 0, sizeof(struct uart_port));

for (i = 0; p && p->flags != 0; p++, i++) {
-   port.iobase = p->iobase;
-   port.membase= p->membase;
-   port.irq= p->irq;
-   port.uartclk= p->uartclk;
-   port.regshift   = p->regshift;
-   port.iotype = p->iotype;
-   port.flags  = p->flags;
-   port.mapbase= p->mapbase;
-   port.hub6   = p->hub6;
-   port.dev= >dev;
+   port.iobase = p->iobase;
+   port.membase= p->membase;
+   port.irq= p->irq;
+   port.uartclk= p->uartclk;
+   port.regshift   = p->regshift;
+   port.iotype = p->iotype;
+   port.flags  = p->flags;
+   port.mapbase= p->mapbase;
+   port.hub6   = p->hub6;
+   port.private_data   = p->private_data;
+   port.dev= >dev;
if (share_irqs)
port.flags |= UPF_SHARE_IRQ;
ret = serial8250_register_port();
@@ -2812,15 +2813,16 @@ int serial8250_register_port(struct uart_port *port)
if (uart) {
uart_remove_one_port(_reg, >port);

-   uart->port.iobase   = port->iobase;
-   uart->port.membase  = port->membase;
-   uart->port.irq  = port->irq;
-   uart->port.uartclk  = port->uartclk;
-   uart->port.fifosize = port->fifosize;
-   uart->port.regshift = port->regshift;
-   uart->port.iotype   = port->iotype;
-   uart->port.flags= port->flags | UPF_BOOT_AUTOCONF;
-   uart->port.mapbase  = port->mapbase;
+   uart->port.iobase   = port->iobase;
+   uart->port.membase  = port->membase;
+   uart->port.irq  = port->irq;
+   uart->port.uartclk  = port->uartclk;
+   uart->port.fifosize = port->fifosize;
+   uart->port.regshift = port->regshift;
+   uart->port.iotype   = port->iotype;
+   uart->port.flags= port->flags | UPF_BOOT_AUTOCONF;
+   uart->port.mapbase  = port->mapbase;
+   uart->port.private_data = port->private_data;
if (port->dev)
uart->port.dev = port->dev;

diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index afe0f6d..00b65c0 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -23,6 +23,7 @@ struct plat_serial8250_port {
resource_size_t mapbase;/* resource base */
unsigned intirq;/* interrupt number */
unsigned intuartclk;/* UART clock rate */
+   void*private_data;
unsigned char   regshift;   /* register shift */
unsigned char   iotype; /* UPIO_* */
unsigned char   hub6;
-- 
1.5.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Support specifying DW APB UARTSs in device platform_data

[Will Newton]

This patch allows the private_data field to be specified in
platform_data for the standard 8250/16550 UART. This field is used by
DW APB type UARTs and without this patch it's only possible to set
this field when registering the port by hand. If private_data is not
set then the
driver will potentially oops with a NULL pointer dereference.


Signed-off-by: Will Newton [EMAIL PROTECTED]

---
 drivers/serial/8250.c   |   40 +---
 include/linux/serial_8250.h |1 +
 2 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index f94109c..c93ef20 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2662,16 +2662,17 @@ static int __devinit serial8250_probe(struct
platform_device *dev)
memset(port, 0, sizeof(struct uart_port));

for (i = 0; p  p-flags != 0; p++, i++) {
-   port.iobase = p-iobase;
-   port.membase= p-membase;
-   port.irq= p-irq;
-   port.uartclk= p-uartclk;
-   port.regshift   = p-regshift;
-   port.iotype = p-iotype;
-   port.flags  = p-flags;
-   port.mapbase= p-mapbase;
-   port.hub6   = p-hub6;
-   port.dev= dev-dev;
+   port.iobase = p-iobase;
+   port.membase= p-membase;
+   port.irq= p-irq;
+   port.uartclk= p-uartclk;
+   port.regshift   = p-regshift;
+   port.iotype = p-iotype;
+   port.flags  = p-flags;
+   port.mapbase= p-mapbase;
+   port.hub6   = p-hub6;
+   port.private_data   = p-private_data;
+   port.dev= dev-dev;
if (share_irqs)
port.flags |= UPF_SHARE_IRQ;
ret = serial8250_register_port(port);
@@ -2812,15 +2813,16 @@ int serial8250_register_port(struct uart_port *port)
if (uart) {
uart_remove_one_port(serial8250_reg, uart-port);

-   uart-port.iobase   = port-iobase;
-   uart-port.membase  = port-membase;
-   uart-port.irq  = port-irq;
-   uart-port.uartclk  = port-uartclk;
-   uart-port.fifosize = port-fifosize;
-   uart-port.regshift = port-regshift;
-   uart-port.iotype   = port-iotype;
-   uart-port.flags= port-flags | UPF_BOOT_AUTOCONF;
-   uart-port.mapbase  = port-mapbase;
+   uart-port.iobase   = port-iobase;
+   uart-port.membase  = port-membase;
+   uart-port.irq  = port-irq;
+   uart-port.uartclk  = port-uartclk;
+   uart-port.fifosize = port-fifosize;
+   uart-port.regshift = port-regshift;
+   uart-port.iotype   = port-iotype;
+   uart-port.flags= port-flags | UPF_BOOT_AUTOCONF;
+   uart-port.mapbase  = port-mapbase;
+   uart-port.private_data = port-private_data;
if (port-dev)
uart-port.dev = port-dev;

diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index afe0f6d..00b65c0 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -23,6 +23,7 @@ struct plat_serial8250_port {
resource_size_t mapbase;/* resource base */
unsigned intirq;/* interrupt number */
unsigned intuartclk;/* UART clock rate */
+   void*private_data;
unsigned char   regshift;   /* register shift */
unsigned char   iotype; /* UPIO_* */
unsigned char   hub6;
-- 
1.5.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Small problem with kernel 2.6.20 and make menuconfig

[Dominic Newton]

Just a small issue with the latest kernel 2.6.20. When compiling make 
menuconfig our ncurses library is not being detected. I currently use 
2.6.15 with no problem and comparing the 2 I found a script ( 
scripts/kconfig/lxdialog/check-lxdialog.sh ) in the lxdialog directory 
that checks for the ncurses lib and sets compiler flags. For some reason 
it will not find the ncurses library and thus menuconfig will not 
compile and run.




I have ncurses installed (and symlinked) in the usual locations (/lib, 
/usr/lib, /usr/include). I tried compiling the stock kernel in various 
locations ( /, /usr /usr/src ) - same problem every time. I fixed the 
problem by editing the scripts/kconfig/Makefile line 88-89 to ignore the 
script and set HOST_EXTRACFLAGS = -DCURSES_LOC="" and 
HOST_LOADLIBES = -lncurses.


menuconfig runs perfectly now ! I'm hopeless at scripts which is why I 
gave up trying to get check-lxdialog.sh to work properly - sorry...


Any queries please let me know,


Regards



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

Small problem with kernel 2.6.20 and make menuconfig

[Dominic Newton]

Just a small issue with the latest kernel 2.6.20. When compiling make 
menuconfig our ncurses library is not being detected. I currently use 
2.6.15 with no problem and comparing the 2 I found a script ( 
scripts/kconfig/lxdialog/check-lxdialog.sh ) in the lxdialog directory 
that checks for the ncurses lib and sets compiler flags. For some reason 
it will not find the ncurses library and thus menuconfig will not 
compile and run.




I have ncurses installed (and symlinked) in the usual locations (/lib, 
/usr/lib, /usr/include). I tried compiling the stock kernel in various 
locations ( /, /usr /usr/src ) - same problem every time. I fixed the 
problem by editing the scripts/kconfig/Makefile line 88-89 to ignore the 
script and set HOST_EXTRACFLAGS = -DCURSES_LOC=ncurses.h and 
HOST_LOADLIBES = -lncurses.


menuconfig runs perfectly now ! I'm hopeless at scripts which is why I 
gave up trying to get check-lxdialog.sh to work properly - sorry...


Any queries please let me know,


Regards



Dominic Newton
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Q] IP Autoconfiguration problem..???

[newton]

Hi,

I use kernel 2.4.5 with IP Autoconfiguration included
dhcp, bootp, rarp .

but, This kernel has not request IP to my dhcp server.
so, kernel panic...

But, kernel 2.4.3 has no any problem.

Help me!

Peace be with you...:)

   Kihyung Ju

--
I love Jesus Christ who is my savior. He gives me meanning of life.
In Christ, I have become shepherd and bible teacher.
 
e-mail : [EMAIL PROTECTED]
home   : http://newton.skku.ac.kr/~newton (My old home page)
 
--

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

[Q] IP Autoconfiguration problem..???

[newton]

Hi,

I use kernel 2.4.5 with IP Autoconfiguration included
dhcp, bootp, rarp .

but, This kernel has not request IP to my dhcp server.
so, kernel panic...

But, kernel 2.4.3 has no any problem.

Help me!

Peace be with you...:)

   Kihyung Ju

--
I love Jesus Christ who is my savior. He gives me meanning of life.
In Christ, I have become shepherd and bible teacher.
 
e-mail : [EMAIL PROTECTED]
home   : http://newton.skku.ac.kr/~newton (My old home page)
 
--

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

[Q] IP autoconfiguration and make xconfig problem.. (fwd)

[newton]

Sorry, I have mistyping...

Hi,

I have a two problem...

1)
kernel 2.4.5 has a IP kernel level autoconfiguration problem.
This kernel do not receive IP from dhcp server.

but, kernel 2.4.3 has not any problem about it.   <--- this...

2) 
make xconfig has stop with following error message
--

drivers/net/Config.in: 145: can't handle dep_bool/dep_mbool/dep_tristate
condition
make[1]: *** [kconfig.tk] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.5/scripts'
make: *** [xconfig] Error 2
--

how can solve this problems?

thanks..

   Ki hyung Ju

--
I love Jesus Christ who is my savior. He gives me meanning of life.
In Christ, I have become shepherd and bible teacher.
 
e-mail : [EMAIL PROTECTED]
home   : http://newton.skku.ac.kr/~newton (My old home page)
 
--


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

[Q] IP autoconfiguration and make xconfig problem.. (fwd)

[newton]

Sorry, I have mistyping...

Hi,

I have a two problem...

1)
kernel 2.4.5 has a IP kernel level autoconfiguration problem.
This kernel do not receive IP from dhcp server.

but, kernel 2.4.3 has not any problem about it.   --- this...

2) 
make xconfig has stop with following error message
--

drivers/net/Config.in: 145: can't handle dep_bool/dep_mbool/dep_tristate
condition
make[1]: *** [kconfig.tk] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.5/scripts'
make: *** [xconfig] Error 2
--

how can solve this problems?

thanks..

   Ki hyung Ju

--
I love Jesus Christ who is my savior. He gives me meanning of life.
In Christ, I have become shepherd and bible teacher.
 
e-mail : [EMAIL PROTECTED]
home   : http://newton.skku.ac.kr/~newton (My old home page)
 
--


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

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Will Newton]

> is exhibiting weird behavior under K7 optimizations. The jist of my
> research is that compiling a kernel for ANY CPU with the Athlon MMX
> optimization
> *AND* 3DNOW results in massive amounts of oops'es and total system
> instability. The following is what I've tried:

With:

Athlon 700
Asus K7V (KX133 based)

I have been running Athlon based kernels for months, no problems (well,
none like you mention).

gcc 2.96-81 BTW



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

AC97/es1371 detection problem

[Will Newton]

Linux won't detect my AC97 (Cirrus Logic, er something I forget exactly)
soundcard from a cold start. Reset the machine and it loads up fine.

Ideas?

VIA KX133 motherboard BTW.

mtrr: 0xe000,0x200 overlaps existing 0xe000,0x100
es1371: version v0.30 time 14:11:05 Apr 28 2001
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
PCI: Found IRQ 10 for device 00:0b.0
es1371: found es1371 rev 8 at io 0xa400 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97  codec, id: 0x:0x (Unknown)

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

AC97/es1371 detection problem

[Will Newton]

Linux won't detect my AC97 (Cirrus Logic, er something I forget exactly)
soundcard from a cold start. Reset the machine and it loads up fine.

Ideas?

VIA KX133 motherboard BTW.

mtrr: 0xe000,0x200 overlaps existing 0xe000,0x100
es1371: version v0.30 time 14:11:05 Apr 28 2001
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
PCI: Found IRQ 10 for device 00:0b.0
es1371: found es1371 rev 8 at io 0xa400 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97  codec, id: 0x:0x (Unknown)

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

Re: VIA audio and parport in 2.4.2

[Will Newton]

On Tue, 20 Mar 2001, Jeff Garzik wrote:

> What are your parallel port settings in BIOS?

AFAICR there is only an option for setting the I/O port. I'll check
for anything else later (the machine in question is busy right now :).

> Do you have Plug-n-Play OS enabled in BIOS?

Yes.

> I am not sure that I agree, however, that an "irq=none" on the kernel
> cmd line should affect the operation of the Via code.  I would much
> rather fix the Via code as I suggest above.

irq=none seems pretty unequivocal to me, I'm not sure how easy it is to
explain to a user that irq=none doesn't do what it says.

> Time to look for and drag out the old Via laptop...  Oh well, I needed
> to debug the Via audio code some more anyway. :)

I'm getting all sorts of troubles with a SB PCI 128 card (AC97 also).
If it works at all, it seems to eventually stop getting interrupts until
the module is removed and reloaded.

Which is why I suspect there may be a larger problem with the VIA
motherboards.


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

Re: VIA audio and parport in 2.4.2

[Will Newton]

On Tue, 20 Mar 2001, Jeff Garzik wrote:

 What are your parallel port settings in BIOS?

AFAICR there is only an option for setting the I/O port. I'll check
for anything else later (the machine in question is busy right now :).

 Do you have Plug-n-Play OS enabled in BIOS?

Yes.

 I am not sure that I agree, however, that an "irq=none" on the kernel
 cmd line should affect the operation of the Via code.  I would much
 rather fix the Via code as I suggest above.

irq=none seems pretty unequivocal to me, I'm not sure how easy it is to
explain to a user that irq=none doesn't do what it says.

 Time to look for and drag out the old Via laptop...  Oh well, I needed
 to debug the Via audio code some more anyway. :)

I'm getting all sorts of troubles with a SB PCI 128 card (AC97 also).
If it works at all, it seems to eventually stop getting interrupts until
the module is removed and reloaded.

Which is why I suspect there may be a larger problem with the VIA
motherboards.


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

Re: VIA audio and parport in 2.4.2

[Will Newton]

On Sat, 17 Mar 2001, Mike Galbraith wrote:

> No device I'm using has irq troubles.. at least nothing obvious.  I've
> no idea if the spurious irq is VIA chipset related or not.. only that
> it's a fairly recent arrival.  All devices work fine here.

In /etc/modules.conf I have:

options parport_pc irq=none

but dmesg says:

parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
lp0: using parport0 (interrupt-driven).

How do I stop the parport module from using interrupts?


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

Re: VIA audio and parport in 2.4.2

[Will Newton]

On Sat, 17 Mar 2001, Mike Galbraith wrote:

 No device I'm using has irq troubles.. at least nothing obvious.  I've
 no idea if the spurious irq is VIA chipset related or not.. only that
 it's a fairly recent arrival.  All devices work fine here.

In /etc/modules.conf I have:

options parport_pc irq=none

but dmesg says:

parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
lp0: using parport0 (interrupt-driven).

How do I stop the parport module from using interrupts?


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

Re: VIA audio and parport in 2.4.2

[Will Newton]

On Sat, 17 Mar 2001, Mike Galbraith wrote:

> > messages.1:Mar  8 22:49:00 dogfox kernel: spurious 8259A interrupt: IRQ7.
>
> I see these once in a while too in 2.4.x, and only when copying largish
> files between boxes.  NIC is IRQ-10, but the spurious interrupt is always
> IRQ-7.  I'm not using the printer port for anything on this box.  It only
> happens here when the network is going full bore for at least a few secs.

With the VIA chipset?

There definitely seems to be something wrong in the IRQ handling on this
board. e.g. when I insmod the sound driver it just sits there on IRQ 10,
getting no interrupts. Unfortunately I don't know enough about Linux
internals to really investigate this further.


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

Re: VIA audio and parport in 2.4.2

[Will Newton]

On Sat, 17 Mar 2001, Mike Galbraith wrote:

  messages.1:Mar  8 22:49:00 dogfox kernel: spurious 8259A interrupt: IRQ7.

 I see these once in a while too in 2.4.x, and only when copying largish
 files between boxes.  NIC is IRQ-10, but the spurious interrupt is always
 IRQ-7.  I'm not using the printer port for anything on this box.  It only
 happens here when the network is going full bore for at least a few secs.

With the VIA chipset?

There definitely seems to be something wrong in the IRQ handling on this
board. e.g. when I insmod the sound driver it just sits there on IRQ 10,
getting no interrupts. Unfortunately I don't know enough about Linux
internals to really investigate this further.


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

Re: VIA audio and parport in 2.4.2

[Will Newton]

On Fri, 16 Mar 2001, Tim Waugh wrote:

> > I don't know why it prints it twice.
>
> Looks like the module is getting loaded, then unloaded, then loaded
> again.  Perhaps because of module autocleaning?

Could be, but the final lp0 line is only printed once:
lp0: using parport0 (interrupt-driven).

> > I also get spurios interrupts on 7 when the parport is not loaded.
>
> I'm not sure what you mean here.  Can you be more specific?

messages.1:Mar  8 22:49:00 dogfox kernel: spurious 8259A interrupt: IRQ7.


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

VIA audio and parport in 2.4.2

[Will Newton]

I have a Asus K7V motherboard and a SB 128 PCI soundcard.
The motherboard is vt82c686a based.
The SB is a ES1371/AC97 card, seemingly identical to the onboard sound on
this type of motherboard.
However, the sound rarely works, and there are problems with the parport
too.

Sound does not work (usually, I have had it work, but I can't reproduce
it). The parport behaves strangely.

Here is dmesg output:

Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict!
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq= dma=
parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict!
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq= dma=
parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
lp0: using parport0 (interrupt-driven).

I don't know why it prints it twice.

When printing errors are printed (buffer overrun or something like that,
it seems RedHat only logs these damn things to console).

Also if I try to disbale interrupt driven printing I get an error:

[root@dogfox log]# /usr/sbin/tunelp /dev/printers/0 -i 0
tunelp: ioctl: Invalid argument
/dev/printers/0 using IRQ 7


With sound, I get:

es1371: version v0.27 time 00:47:56 Mar  7 2001
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
PCI: Found IRQ 10 for device 00:0b.0
es1371: found es1371 rev 8 at io 0xa400 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97  codec, id: 0x:0x (Unknown)

Where the id field obviously should not be zero.

The IRQ, DMA, I/O ports etc. are all the same as they are in Windows, but
in Linux the sound doesn't work and the printer keeps hanging.

I also get spurios interrupts on 7 when the parport is not loaded.

I know other people are seeing similar effects with sinilar hardware, but
to my knowledge there have been no solutions put forward.

If anyone has any ideas I can try to diagnose this problem more clearly
or wants any specific information, please ask.


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

VIA audio and parport in 2.4.2

[Will Newton]

I have a Asus K7V motherboard and a SB 128 PCI soundcard.
The motherboard is vt82c686a based.
The SB is a ES1371/AC97 card, seemingly identical to the onboard sound on
this type of motherboard.
However, the sound rarely works, and there are problems with the parport
too.

Sound does not work (usually, I have had it work, but I can't reproduce
it). The parport behaves strangely.

Here is dmesg output:

Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict!
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq=none or set by other means dma=none or set by
other means
parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict!
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq=none or set by other means dma=none or set by
other means
parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
lp0: using parport0 (interrupt-driven).

I don't know why it prints it twice.

When printing errors are printed (buffer overrun or something like that,
it seems RedHat only logs these damn things to console).

Also if I try to disbale interrupt driven printing I get an error:

[root@dogfox log]# /usr/sbin/tunelp /dev/printers/0 -i 0
tunelp: ioctl: Invalid argument
/dev/printers/0 using IRQ 7


With sound, I get:

es1371: version v0.27 time 00:47:56 Mar  7 2001
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
PCI: Found IRQ 10 for device 00:0b.0
es1371: found es1371 rev 8 at io 0xa400 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97  codec, id: 0x:0x (Unknown)

Where the id field obviously should not be zero.

The IRQ, DMA, I/O ports etc. are all the same as they are in Windows, but
in Linux the sound doesn't work and the printer keeps hanging.

I also get spurios interrupts on 7 when the parport is not loaded.

I know other people are seeing similar effects with sinilar hardware, but
to my knowledge there have been no solutions put forward.

If anyone has any ideas I can try to diagnose this problem more clearly
or wants any specific information, please ask.


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

ES1371 driver in kernel 2.4.2

[Will Newton]

I am still having problems with this driver.

When loading the driver I get:

es1371: version v0.27 time 00:47:56 Mar  7 2001
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
PCI: Found IRQ 10 for device 00:0b.0
es1371: found es1371 rev 8 at io 0xa400 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97  codec, id: 0x:0x (Unknown)
spurious 8259A interrupt: IRQ7.

This last line seems strange as /proc/interrupts does not list IRQ7:

  0:2515137  XT-PIC  timer
  1:  18752  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  4:2438600  XT-PIC  serial
  5:  0  XT-PIC  bttv
  8:  1  XT-PIC  rtc
 10:  0  XT-PIC  es1371
 12: 310926  XT-PIC  PS/2 Mouse
 14: 137157  XT-PIC  ide0
 15:  35714  XT-PIC  ide1
NMI:  0
ERR:  1

The chip is actually a Cirrus Logic CS4297A.


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

ES1371 driver in kernel 2.4.2

[Will Newton]

I am still having problems with this driver.

When loading the driver I get:

es1371: version v0.27 time 00:47:56 Mar  7 2001
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
PCI: Found IRQ 10 for device 00:0b.0
es1371: found es1371 rev 8 at io 0xa400 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97  codec, id: 0x:0x (Unknown)
spurious 8259A interrupt: IRQ7.

This last line seems strange as /proc/interrupts does not list IRQ7:

  0:2515137  XT-PIC  timer
  1:  18752  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  4:2438600  XT-PIC  serial
  5:  0  XT-PIC  bttv
  8:  1  XT-PIC  rtc
 10:  0  XT-PIC  es1371
 12: 310926  XT-PIC  PS/2 Mouse
 14: 137157  XT-PIC  ide0
 15:  35714  XT-PIC  ide1
NMI:  0
ERR:  1

The chip is actually a Cirrus Logic CS4297A.


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

ES1371 problem (2.4.2)

[Will Newton]

Approx. 90% of the time my es1371 sound card refuses to work.
dmesg reveals:
es1371: version v0.27 time 16:38:48 Mar  3 2001
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
PCI: Found IRQ 10 for device 00:0b.0
es1371: found es1371 rev 8 at io 0xa400 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97  codec, id: 0x:0x (Unknown)

When it works (I'm not sure, but a clean boot helps) the id fields are
non-zero.

My setup:

Athlon/KX133 (VIA chipset)/Creative SB64 PCI
kernel 2.4.2/gcc 2.96 (latest)

I am using devfs also.

Please CC any replies to this address.


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

ES1371 problem (2.4.2)

[Will Newton]

Approx. 90% of the time my es1371 sound card refuses to work.
dmesg reveals:
es1371: version v0.27 time 16:38:48 Mar  3 2001
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
PCI: Found IRQ 10 for device 00:0b.0
es1371: found es1371 rev 8 at io 0xa400 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97  codec, id: 0x:0x (Unknown)

When it works (I'm not sure, but a clean boot helps) the id fields are
non-zero.

My setup:

Athlon/KX133 (VIA chipset)/Creative SB64 PCI
kernel 2.4.2/gcc 2.96 (latest)

I am using devfs also.

Please CC any replies to this address.


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