diff mbox

[ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

Message ID m3d2kduwd7.fsf@t19.piap.pl
State New
Headers show

Commit Message

Krzysztof Hałasa Dec. 31, 2013, 10:51 a.m. UTC
drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in this function)

Now builds. Not tested on real hw.

Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>

Comments

Gerhard Sittig Dec. 31, 2013, 1:48 p.m. UTC | #1
On Tue, Dec 31, 2013 at 11:51 +0100, Krzysztof Hałasa wrote:
> 
> drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
> drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in this function)
> 
> Now builds. Not tested on real hw.
> 
> Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>

I understood that a 'Fixes: <hash> <subject>' line is suggested when
you can clearly identify what broke what you fix.  Is it 27c1789ca6a6
"DMA-API: crypto: remove last references to 'static struct device *dev'"?
Then v3.13-rc1 would have been affected.

> --- a/drivers/crypto/ixp4xx_crypto.c
> +++ b/drivers/crypto/ixp4xx_crypto.c
> @@ -1410,14 +1410,12 @@ static const struct platform_device_info ixp_dev_info __initdata = {
>  static int __init ixp_module_init(void)
>  {
>  	int num = ARRAY_SIZE(ixp4xx_algos);
> -	int i, err ;
> +	int i, err;
>  
>  	pdev = platform_device_register_full(&ixp_dev_info);
>  	if (IS_ERR(pdev))
>  		return PTR_ERR(pdev);
>  
> -	dev = &pdev->dev;
> -
>  	spin_lock_init(&desc_lock);
>  	spin_lock_init(&emerg_lock);


virtually yours
Gerhard Sittig
Randy Dunlap Dec. 31, 2013, 6:01 p.m. UTC | #2
On 12/31/13 05:48, Gerhard Sittig wrote:
> On Tue, Dec 31, 2013 at 11:51 +0100, Krzysztof Hałasa wrote:
>>
>> drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
>> drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in this function)
>>
>> Now builds. Not tested on real hw.
>>
>> Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
> 
> I understood that a 'Fixes: <hash> <subject>' line is suggested when
> you can clearly identify what broke what you fix.  Is it 27c1789ca6a6
> "DMA-API: crypto: remove last references to 'static struct device *dev'"?
> Then v3.13-rc1 would have been affected.
 
is 'Fixes: <whatever>' documented somewhere?

thanks,
Russell King - ARM Linux Dec. 31, 2013, 6:14 p.m. UTC | #3
Please get rid of your Mail-Followup-To: header:

Mail-Followup-To: Krzysztof Hałasa <khalasa@piap.pl>,                           
        lkml <linux-kernel@vger.kernel.org>,                                    
        linux-arm-kernel@lists.infradead.org,                                   
        Russell King <rmk+kernel@arm.linux.org.uk>,                             
        Christian Hohnstaedt <chohnstaedt@innominate.com>,                      
        Herbert Xu <herbert@gondor.apana.org.au>                                
User-Agent: Mutt/1.5.21 (2010-09-15)                                            

It causes all recipients following the thread to be moved into the To:
header when someone replies to one of your messages, which is deemed to
be anti-social.  You can kill this header by adding:

	set followup_to=no

to your .muttrc file.

Thanks.
Herbert Xu Jan. 1, 2014, 6:06 a.m. UTC | #4
On Tue, Dec 31, 2013 at 11:51:16AM +0100, Krzysztof Hałasa wrote:
> drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
> drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in this function)
> 
> Now builds. Not tested on real hw.
> 
> Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>

Patch applied.  Thanks!
Gerhard Sittig Jan. 1, 2014, 12:18 p.m. UTC | #5
On Tue, Dec 31, 2013 at 18:14 +0000, Russell King - ARM Linux wrote:
> 
> Please get rid of your Mail-Followup-To: header:
> 
> Mail-Followup-To: Krzysztof Hałasa <khalasa@piap.pl>,                           
>         lkml <linux-kernel@vger.kernel.org>,                                    
>         linux-arm-kernel@lists.infradead.org,                                   
>         Russell King <rmk+kernel@arm.linux.org.uk>,                             
>         Christian Hohnstaedt <chohnstaedt@innominate.com>,                      
>         Herbert Xu <herbert@gondor.apana.org.au>                                
> User-Agent: Mutt/1.5.21 (2010-09-15)                                            
> 
> It causes all recipients following the thread to be moved into the To:
> header when someone replies to one of your messages, which is deemed to
> be anti-social.  You can kill this header by adding:
> 
> 	set followup_to=no
> 
> to your .muttrc file.

Thank you for telling me, I was not aware.  Had no MFT related
setting in my config, learned from the manual that $followup_to
defaults to yes, have turned it off now.  Other mutt users may
want to check as well.  Happy new year! :)


virtually yours
Gerhard Sittig
Gerhard Sittig Jan. 1, 2014, 12:37 p.m. UTC | #6
On Tue, Dec 31, 2013 at 10:01 -0800, Randy Dunlap wrote:
> 
> On 12/31/13 05:48, Gerhard Sittig wrote:
> > On Tue, Dec 31, 2013 at 11:51 +0100, Krzysztof Hałasa wrote:
> >>
> >> drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
> >> drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in this function)
> >>
> >> Now builds. Not tested on real hw.
> >>
> >> Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
> > 
> > I understood that a 'Fixes: <hash> <subject>' line is suggested when
> > you can clearly identify what broke what you fix.  Is it 27c1789ca6a6
> > "DMA-API: crypto: remove last references to 'static struct device *dev'"?
> > Then v3.13-rc1 would have been affected.
>  
> is 'Fixes: <whatever>' documented somewhere?

Last time I checked (few days ago, 'git grep -w Fixes:') it
wasn't, at least not within the kernel source tree and its
Documentation hierarchy.  Today's master still does not have it.

But a quick search in recent LAKML messages reveals that it's
been in use by e.g. Olof Johansson, Jason Cooper, Rusty Russell,
Dan Carpenter, Russell King, Mark Brown, Stephen Warren, Paul
Walmsley, and I'm not making this up but am just referring to
what repeatedly was requested in the past.  The form used there
was "Fixes: <hash> (<oneline>)" though.  A doc update may be due
to have a canonical format.

I do see the benefit of this tag, as it does not hide this
information in the commit message's prose, makes submitters think
about that property in more explicit ways and makes them provide
the information such that others need not do the research, and
greatly helps those involved in tests and release management to
determine affected versions and required actions that need to be
taken.  The tag is very useful.


virtually yours
Gerhard Sittig
Russell King - ARM Linux Jan. 1, 2014, 12:46 p.m. UTC | #7
On Wed, Jan 01, 2014 at 01:37:46PM +0100, Gerhard Sittig wrote:
> Last time I checked (few days ago, 'git grep -w Fixes:') it
> wasn't, at least not within the kernel source tree and its
> Documentation hierarchy.  Today's master still does not have it.
> 
> But a quick search in recent LAKML messages reveals that it's
> been in use by e.g. Olof Johansson, Jason Cooper, Rusty Russell,
> Dan Carpenter, Russell King, Mark Brown, Stephen Warren, Paul
> Walmsley, and I'm not making this up but am just referring to
> what repeatedly was requested in the past.  The form used there
> was "Fixes: <hash> (<oneline>)" though.  A doc update may be due
> to have a canonical format.

It was discussed at kernel summit, and I believe the resulting format
was only published in one of the kernel summit mailing lists.  The
outcome of it as I understand was that the format is:

Fixes: <hash> ("<one line summary>")

Though the addition of the quotes was (iirc) only something added after
the vocal discussion.  If you mail Linus a patch with a fixes line which
doesn't match that, Linus will probably fix it up... (Linus has done that
with one of mine in the past.)
Jason Cooper Jan. 2, 2014, 12:25 a.m. UTC | #8
On Wed, Jan 01, 2014 at 12:46:25PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 01, 2014 at 01:37:46PM +0100, Gerhard Sittig wrote:
> > Last time I checked (few days ago, 'git grep -w Fixes:') it
> > wasn't, at least not within the kernel source tree and its
> > Documentation hierarchy.  Today's master still does not have it.
> > 
> > But a quick search in recent LAKML messages reveals that it's
> > been in use by e.g. Olof Johansson, Jason Cooper, Rusty Russell,
> > Dan Carpenter, Russell King, Mark Brown, Stephen Warren, Paul
> > Walmsley, and I'm not making this up but am just referring to
> > what repeatedly was requested in the past.  The form used there
> > was "Fixes: <hash> (<oneline>)" though.  A doc update may be due
> > to have a canonical format.
> 
> It was discussed at kernel summit, and I believe the resulting format
> was only published in one of the kernel summit mailing lists.  The
> outcome of it as I understand was that the format is:
> 
> Fixes: <hash> ("<one line summary>")

fwiw, Linus also recommended setting core.abbrev = 12.

thx,

Jason.
Uwe Kleine-König Jan. 2, 2014, 8:42 a.m. UTC | #9
On Wed, Jan 01, 2014 at 01:18:22PM +0100, Gerhard Sittig wrote:
> On Tue, Dec 31, 2013 at 18:14 +0000, Russell King - ARM Linux wrote:
> > 
> > Please get rid of your Mail-Followup-To: header:
> > 
> > Mail-Followup-To: Krzysztof Hałasa <khalasa@piap.pl>,                           
> >         lkml <linux-kernel@vger.kernel.org>,                                    
> >         linux-arm-kernel@lists.infradead.org,                                   
> >         Russell King <rmk+kernel@arm.linux.org.uk>,                             
> >         Christian Hohnstaedt <chohnstaedt@innominate.com>,                      
> >         Herbert Xu <herbert@gondor.apana.org.au>                                
> > User-Agent: Mutt/1.5.21 (2010-09-15)                                            
> > 
> > It causes all recipients following the thread to be moved into the To:
> > header when someone replies to one of your messages, which is deemed to
> > be anti-social.  You can kill this header by adding:
> > 
> > 	set followup_to=no
> > 
> > to your .muttrc file.
> 
> Thank you for telling me, I was not aware.  Had no MFT related
> setting in my config, learned from the manual that $followup_to
> defaults to yes, have turned it off now.  Other mutt users may
> want to check as well.  Happy new year! :)
I have

	# set followup_to = yes

in my .mutt/muttrc---so I'm using the default---but I'm still
unaffected. I think this is because I don't have any lists specified
(using the lists and subscribe commands). And note that there are lists
that consider using MFT to be good, ISTR that it applies to
*@lists.debian.org, but cannot currently find a reference to support
that claim. The problem is that using MFT only works if all recipents
are using and respecting it.

If Russell is annoyed in general by MFT, he could unset
honor_followup_to.
 
Best regards
Uwe
Russell King - ARM Linux Jan. 2, 2014, 10:35 a.m. UTC | #10
On Thu, Jan 02, 2014 at 09:42:52AM +0100, Uwe Kleine-König wrote:
> I have
> 
> 	# set followup_to = yes
> 
> in my .mutt/muttrc---so I'm using the default---but I'm still
> unaffected. I think this is because I don't have any lists specified
> (using the lists and subscribe commands). And note that there are lists
> that consider using MFT to be good, ISTR that it applies to
> *@lists.debian.org, but cannot currently find a reference to support
> that claim. The problem is that using MFT only works if all recipents
> are using and respecting it.

Your last statement is total rubbish.  This header is seen by the
mainstream Linux community as being totally evil.

> If Russell is annoyed in general by MFT, he could unset
> honor_followup_to.

And how does that stop the problem when someone *else* replies to the
message with a Mail-Followup-To?  FYI, I was hounded off LKML for having
that header set.

When people have this header set, and people reply to such a message, all
recipients get moved into the To: header.  This makes it impossible on
high traffic lists for people to prioritise their reading of messages
according to whether they're in the To: header or just in the Cc: header.

Being in the To: header means that someone is directing the message *AT*
you and wanting *YOU* to do something with it.  Being in the Cc: is more
"for information" and so takes a lower priority.

Hence, when someone replies to a message, and their mail client ends up
moving all recipients into the To: header, it completely destroys the
ability to prioritise the reading.  So, either we adopt the same position
here as the rest of the Linux community wrt this header, or I'm just going
to read messages on the list at random, completely ignoring whether I'm
in the To: header or not.

What that means is that there will have *no way* to attract my attention
to any email message - since I will not care one bit whether I'm listed
me in the To: header or not.

And no, you are NOT going to pester me on IRC each time.

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
Mark Brown Jan. 2, 2014, 5:51 p.m. UTC | #11
On Thu, Jan 02, 2014 at 09:42:52AM +0100, Uwe Kleine-König wrote:

> (using the lists and subscribe commands). And note that there are lists
> that consider using MFT to be good, ISTR that it applies to
> *@lists.debian.org, but cannot currently find a reference to support
> that claim. The problem is that using MFT only works if all recipents
> are using and respecting it.

No, Debian specifically wants replies to be sent to the list only but
it's not really related to Mail-Followup-To - I don't think there's a
general feeling on that within Debian but ICBW.  The thing about reply
to list predates the invention of MFT.
Borislav Petkov Jan. 2, 2014, 6:33 p.m. UTC | #12
On Thu, Jan 02, 2014 at 10:35:22AM +0000, Russell King - ARM Linux wrote:
> And how does that stop the problem when someone *else* replies to the
> message with a Mail-Followup-To?  FYI, I was hounded off LKML for having
> that header set.
> 
> When people have this header set, and people reply to such a message, all
> recipients get moved into the To: header.  This makes it impossible on
> high traffic lists for people to prioritise their reading of messages
> according to whether they're in the To: header or just in the Cc: header.
> 
> Being in the To: header means that someone is directing the message *AT*
> you and wanting *YOU* to do something with it.  Being in the Cc: is more
> "for information" and so takes a lower priority.

Totally agreed.

That MFT thing might've been a good idea at the time but in reality
it causes more problems than it solves, with our usage patterns. I've
started ignoring it and would suggest people simply drop all those
"lists/subsribe" directives in their .muttrc.

Thanks.
diff mbox

Patch

--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -1410,14 +1410,12 @@  static const struct platform_device_info ixp_dev_info __initdata = {
 static int __init ixp_module_init(void)
 {
 	int num = ARRAY_SIZE(ixp4xx_algos);
-	int i, err ;
+	int i, err;
 
 	pdev = platform_device_register_full(&ixp_dev_info);
 	if (IS_ERR(pdev))
 		return PTR_ERR(pdev);
 
-	dev = &pdev->dev;
-
 	spin_lock_init(&desc_lock);
 	spin_lock_init(&emerg_lock);