Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO

On Tue, Dec 19, 2017 at 10:51:14AM -0800, Joe Perches wrote: > > The reason for the code churn being? > > Consistency for easier grep by use-type. Please explain that in the commit message so that we know why it was changed. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid

Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO

On Tue, Dec 19, 2017 at 10:15:09AM -0800, Joe Perches wrote: > Convert DEVICE_ATTR uses to DEVICE_ATTR_WO where possible. > > Done with perl script: > > $ git grep -w --name-only DEVICE_ATTR | \ > xargs perl -i -e 'local $/; while (<>) { >

Re: [PATCH 01/15] EDAC: make device_type const

On Sat, Aug 19, 2017 at 01:52:12PM +0530, Bhumika Goyal wrote: > Make these const as they are only stored in the type field of a device > structure, which is const. > Done using Coccinelle. > > Signed-off-by: Bhumika Goyal > --- > drivers/edac/edac_mc_sysfs.c | 8 >

Section mismatch in reference from the function generic_NCR5380_isa_match()

Hi, I'm seeing this during randconfig builds: WARNING: vmlinux.o(.text+0x1588439): Section mismatch in reference from the function generic_NCR5380_isa_match() to the function .init.text:probe_intr() The function generic_NCR5380_isa_match() references the function __init probe_intr(). This is

Re: [patch v2] arcmsr: buffer overflow in arcmsr_iop_message_xfer()

> > Applied to 4.9/scsi-queue. Yap, Tomas said the kfree was missing on the error path but can we simplify this further by doing the user_len check first so that the kfree() is not even needed? Patch ontop: --- From: Borislav Petkov <b...@suse.de> Date: Fri, 23 Sep 2016 13:04:51 +0200 Sub

Re: hpsa failure with 4.3.0-rc1

On Wed, Sep 30, 2015 at 09:40:50AM +0200, Hannes Reinecke wrote: > Hi all, > > trying to boot 4.3.0-rc1 on a system with hpsa results in a swiotlb > failure: > > hpsa :22:00.0: Logical aborts not supported > hpsa :22:00.0: HP SSD Smart Path aborts not supported > hpsa :22:00.0:

Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD

Hi Thomas, On Mon, Jun 16, 2014 at 09:13:20AM +0200, Thomas Schwinge wrote: The problem solved itself: the machine recently died of hardware failure. ;-| How convenient. :-P What happened? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To

Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD

On Mon, Jun 16, 2014 at 12:33:55PM +0200, Thomas Schwinge wrote: The power supply and/or mainboard didn't wake up after a recent power cycle. As both these aren't standard form factors (and the machine/architecture had some issues, as discussed, and see also

Re: [PATCH] checkpatch: Make camelcase test --strict and less noisy

On Thu, Apr 11, 2013 at 07:45:03AM -0700, Joe Perches wrote: CamelCase tests are a bit noisy against certain types of code acceptable to some kernel developers. Make the test applicable only with --strict. Do not bleat a message on nominally acceptable CamelCase uses that are separated by

Re: checkpatch: kill the bogus camelcase check

On Wed, Apr 10, 2013 at 07:35:58AM -0700, Joe Perches wrote: or maybe exclude drivers/scsi and include/scsi/ and arch/x86/kvm/emulate.c -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe

Re: checkpatch: kill the bogus camelcase check

On Wed, Apr 10, 2013 at 08:07:41AM -0700, James Bottomley wrote: On Wed, 2013-04-10 at 16:52 +0200, Borislav Petkov wrote: On Wed, Apr 10, 2013 at 07:35:58AM -0700, Joe Perches wrote: or maybe exclude drivers/scsi and include/scsi/ and arch/x86/kvm/emulate.c Actually, we get this all

Re: SYSFS errors

On Tue, Feb 19, 2013 at 08:11:49AM -0300, Mauro Carvalho Chehab wrote: I remember I saw some discussions about it in the past at bluesmoke ML, saying that -ENODEV is the expected behavior when this is not supported. Changing from -ENODEV to N/A will break anything that would be

Re: SYSFS errors

On Tue, Feb 19, 2013 at 09:16:10AM -0300, Mauro Carvalho Chehab wrote: I'm not sure if is there a way to pass fs permissions to something similar to device_create_file(). struct device_attribute.attr.mode? I.e., second arg. On both cases, an error will happen at open: - if file doesn't

Re: SYSFS errors

On Tue, Feb 19, 2013 at 09:46:40AM -0300, Mauro Carvalho Chehab wrote: Ah, now I see what you're meaning. That would require to dynamically create a per-mci DEVICE_ATTR(). Dude, look at the code, we do that already. And you're using it with dev_attr_sdram_scrub_rate. Simply change the

Re: SYSFS errors

On Tue, Feb 19, 2013 at 03:15:00PM +0200, Felipe Balbi wrote: what's the problem with that ? Not a problem - simply annoying. $ ./test.sh cat: /path/to/file/that/doesnt/exist.txt: No such file or directory Setting scrubrate to: I'm sure someone would ask themselves why all of a sudden the file

Re: SYSFS errors

On Tue, Feb 19, 2013 at 03:38:09PM +0200, Felipe Balbi wrote: because changing the permission will cause the same issue: Actually, I take that back. Mauro's patch will already create the file anyway: if (mci-set_sdram_scrub_rate || mci-get_sdram_scrub_rate) Adjusting the permissions is

Re: SYSFS errors

On Tue, Feb 19, 2013 at 10:50:48AM -0300, Mauro Carvalho Chehab wrote: It is actually worse, as if someone is using a C code to open the device with fp = open (/sys/devices/system/edac/mc/mc0/sdram_scrub_rate, O_RDWR); It will now start to fail if the device doesn't have both

Re: SYSFS errors

On Tue, Feb 19, 2013 at 02:58:07PM +0100, Hannes Reinecke wrote: Please consider adding a default attribute which return '-EINVAL' or somesuch when the function pointers are not set. But _not_ adding it via device_create_file(). That's evil. This is what we do now. We probably could add the

Re: SYSFS errors

, sdram_scrub_rate sysfs node is created even if the device doesn't support get/set the scub rate. Change the logic to only create this device node when the operation is supported. Reported-by: Felipe Balbi ba...@ti.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Acked-by: Borislav

Re: SYSFS errors

On Mon, Feb 18, 2013 at 01:54:34PM -0800, Greg KH wrote: Because sysfs is one value per file the lack of a file showing up shouldn't cause any userspace tools any problems, that is why we did things this way. But, of course, userspace programmers do know how to mess things up... How about

Re: SYSFS errors

On Mon, Feb 18, 2013 at 02:26:18PM -0800, Greg KH wrote: I don't know, it depends on if userspace can handle this properly or not. What tools rely on this sysfs file? WHat happens when they get a non-number in the file? I'm not aware of any, frankly speaking. If there are any, those tools

Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD

On Thu, Sep 13, 2012 at 02:58:25PM +0200, Borislav Petkov wrote: Here's the script, let me know how it goes: Here's a more correct version. I'm not saying yours won't work based on the rdmsr and setpci output on your box, but here's a version which should pay attention to one other workaround

Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD

On Fri, Sep 07, 2012 at 11:14:33AM +0200, Thomas Schwinge wrote: I have now finally been able to check this, and yes, I'm already using the latest version of the BIOS, which is Phoenix cME FirstBIOS Desktop Pro version 5.00 R1.07.2264.A1 (a.k.a. 5.00.1.07, 25.04.2006) for Fujitsu Siemens