LIBCFS_ALLOC
It is not clear that all of the uses of LIBCFS_ALLOC really risk needing
vmalloc. For example:
lnet/klnds/socklnd/socklnd.c, function ksocknal_accept:
ksock_connreq_t *cr;
...
LIBCFS_ALLOC(cr, sizeof(*cr));
The definition of ksock_connreq_t is:
typedef struct ksock_connreq {
struct list_head ksncr_list; /* stash on ksnd_connd_connreqs */
lnet_ni_t*ksncr_ni; /* chosen NI */
struct socket*ksncr_sock; /* accepted socket */
} ksock_connreq_t;
This looks like a very small structure.
LIBCFS_ALLOC relies on a test on the size, which should be able to be
compiled away. libcfs_kvzalloc on the other hand relies on the failure of
kmalloc and so the test for that won't be compiled away.
Does it matter?
julia
--
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: f_op->read seems to be always NULL since Linux 4.1
On Sat, Jun 27, 2015 at 8:10 PM, Richard Weinberger wrote: On Sat, Jun 27, 2015 at 7:32 PM, Andreas Hartmann wrote: [...] See __vfs_read(). Your module most not rely on such internals. Thanks for your hint to the function which exists since 3.19. Is there a site out there which lists all relevant changes done for each kernel version and the recommendations how to correctly handle them? Kind regards, Andreas -- 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] staging: lustre: lnet: fix type warning in lib-socket.c
This patch fixes the following sparse warning: drivers/staging/lustre/lnet/lnet/lib-socket.c:175:29: warning: incorrect type in assignment (different address spaces) expected char [noderef] *ifcu_buf got char * Signed-off-by: Geliang Tang --- drivers/staging/lustre/lnet/lnet/lib-socket.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lnet/lnet/lib-socket.c b/drivers/staging/lustre/lnet/lnet/lib-socket.c index 6f7ef4c..e3d1c42 100644 --- a/drivers/staging/lustre/lnet/lnet/lib-socket.c +++ b/drivers/staging/lustre/lnet/lnet/lib-socket.c @@ -172,7 +172,7 @@ lnet_ipif_enumerate(char ***namesp) goto out0; } - ifc.ifc_buf = (char *)ifr; + ifc.ifc_buf = (char __user *)ifr; ifc.ifc_len = nalloc * sizeof(*ifr); rc = lnet_sock_ioctl(SIOCGIFCONF, (unsigned long)&ifc); -- 2.3.4 -- 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] modules: elide param_lock if !CONFIG_SYSFS
Stephen Rothwell writes: > Hi Rusty, > > On Thu, 25 Jun 2015 17:34:31 -0400 Dan Streetman wrote: >> >> On Thu, Jun 25, 2015 at 5:18 PM, Rusty Russell wrote: >> > Dan Streetman writes: >> >> Only include the built-in and per-module param_lock, and corresponding >> >> lock/unlock functions, if sysfs is enabled. If there is no sysfs there >> >> is no need for locking kernel params. >> >> >> >> This fixes a build break when CONFIG_SYSFS is not enabled, introduced >> >> by commit b51d23e. >> > >> > This doesn't even come close to applying to my tree? >> >> sorry, I had the !CONFIG_MODULES patch in my tree also, so this was on >> top of that one: >> https://lkml.org/lkml/2015/6/24/550 >> >> I can resend that one, on top of this one, or you can fix it up. >> >> Sorry for not getting it right the first time ;-) > > This is what I ended up applying to yesterday's linux-next: Thanks, added correct description to previous patch and applied this on top. Sorry for the hassle, Rusty. -- 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] clocksource: imx: define clocksource for mx27
On Sat, Jun 27, 2015 at 11:11:44PM +0200, Philippe Reynes wrote: > The clocksource imx27 wasn't defined in timer-imx-gpt.c, > so the kernel no longer boot on imx27. Just define > clocksource imx27 as an imx21. > > Signed-off-by: Philippe Reynes Acked-by: Shawn Guo Daniel, Please help send this as a fix for 4.2-rc, thanks. Shawn -- 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] ASoC: fsl_ssi: fix AC'97 mode
Maciej S. Szmigiero wrote:
+ if (newbinding && fsl_ssi_is_ac97(ssi_private)) {
Is the "newbinding" necessary? I thought only the original PowerPC
device trees were the only one that have the old binding, and they never
supported AC97.
--
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 03/10] Drivers: hv: vmbus: add special kexec handler
From: Vitaly Kuznetsov
When general-purpose kexec (not kdump) is being performed in Hyper-V guest
the newly booted kernel fails with an MCE error coming from the host. It
is the same error which was fixed in the "Drivers: hv: vmbus: Implement
the protocol for tearing down vmbus state" commit - monitor pages remain
special and when they're being written to (as the new kernel doesn't know
these pages are special) bad things happen. We need to perform some
minimalistic cleanup before booting a new kernel on kexec. To do so we
need to register a special machine_ops.shutdown handler to be executed
before the native_machine_shutdown(). Registering a shutdown notification
handler via the register_reboot_notifier() call is not sufficient as it
happens to early for our purposes. machine_ops is not being exported to
modules (and I don't think we want to export it) so let's do this in
mshyperv.c
The minimalistic cleanup consists of cleaning up clockevents, synic MSRs,
guest os id MSR, and hypercall MSR.
Kdump doesn't require all this stuff as it lives in a separate memory
space.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
arch/x86/include/asm/mshyperv.h |2 ++
arch/x86/kernel/cpu/mshyperv.c | 24
drivers/hv/vmbus_drv.c | 14 ++
3 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index c163215..d3db910 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -20,4 +20,6 @@ void hyperv_vector_handler(struct pt_regs *regs);
void hv_setup_vmbus_irq(void (*handler)(void));
void hv_remove_vmbus_irq(void);
+void hv_setup_kexec_handler(void (*handler)(void));
+void hv_remove_kexec_handler(void);
#endif
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 939155f..09911aa 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -28,10 +29,13 @@
#include
#include
#include
+#include
struct ms_hyperv_info ms_hyperv;
EXPORT_SYMBOL_GPL(ms_hyperv);
+static void (*hv_kexec_handler)(void);
+
#if IS_ENABLED(CONFIG_HYPERV)
static void (*vmbus_handler)(void);
@@ -69,8 +73,27 @@ void hv_remove_vmbus_irq(void)
}
EXPORT_SYMBOL_GPL(hv_setup_vmbus_irq);
EXPORT_SYMBOL_GPL(hv_remove_vmbus_irq);
+
+void hv_setup_kexec_handler(void (*handler)(void))
+{
+ hv_kexec_handler = handler;
+}
+EXPORT_SYMBOL_GPL(hv_setup_kexec_handler);
+
+void hv_remove_kexec_handler(void)
+{
+ hv_kexec_handler = NULL;
+}
+EXPORT_SYMBOL_GPL(hv_remove_kexec_handler);
#endif
+static void hv_machine_shutdown(void)
+{
+ if (kexec_in_progress && hv_kexec_handler)
+ hv_kexec_handler();
+ native_machine_shutdown();
+}
+
static uint32_t __init ms_hyperv_platform(void)
{
u32 eax;
@@ -143,6 +166,7 @@ static void __init ms_hyperv_init_platform(void)
no_timer_check = 1;
#endif
+ machine_ops.shutdown = hv_machine_shutdown;
}
const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 00d5158..31748a2 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1060,6 +1060,17 @@ static struct acpi_driver vmbus_acpi_driver = {
},
};
+static void hv_kexec_handler(void)
+{
+ int cpu;
+
+ hv_synic_clockevents_cleanup();
+ vmbus_initiate_unload();
+ for_each_online_cpu(cpu)
+ smp_call_function_single(cpu, hv_synic_cleanup, NULL, 1);
+ hv_cleanup();
+};
+
static int __init hv_acpi_init(void)
{
int ret, t;
@@ -1092,6 +1103,8 @@ static int __init hv_acpi_init(void)
if (ret)
goto cleanup;
+ hv_setup_kexec_handler(hv_kexec_handler);
+
return 0;
cleanup:
@@ -1104,6 +1117,7 @@ static void __exit vmbus_exit(void)
{
int cpu;
+ hv_remove_kexec_handler();
vmbus_connection.conn_state = DISCONNECTED;
hv_synic_clockevents_cleanup();
vmbus_disconnect();
--
1.7.4.1
--
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 01/10] Drivers: hv: vmbus: remove hv_synic_free_cpu() call from hv_synic_cleanup()
From: Vitaly Kuznetsov We already have hv_synic_free() which frees all per-cpu pages for all CPUs, let's remove the hv_synic_free_cpu() call from hv_synic_cleanup() so it will be possible to do separate cleanup (writing to MSRs) and final freeing. This is going to be used to assist kexec. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan --- drivers/hv/hv.c|2 -- drivers/hv/vmbus_drv.c |1 + 2 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c index d3943bc..5b87042 100644 --- a/drivers/hv/hv.c +++ b/drivers/hv/hv.c @@ -530,6 +530,4 @@ void hv_synic_cleanup(void *arg) rdmsrl(HV_X64_MSR_SCONTROL, sctrl.as_uint64); sctrl.enable = 0; wrmsrl(HV_X64_MSR_SCONTROL, sctrl.as_uint64); - - hv_synic_free_cpu(cpu); } diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index cf20400..00d5158 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -1120,6 +1120,7 @@ static void __exit vmbus_exit(void) tasklet_kill(hv_context.event_dpc[cpu]); smp_call_function_single(cpu, hv_synic_cleanup, NULL, 1); } + hv_synic_free(); acpi_bus_unregister_driver(&vmbus_acpi_driver); hv_cpu_hotplug_quirk(false); } -- 1.7.4.1 -- 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 02/10] kexec: define kexec_in_progress in !CONFIG_KEXEC case
From: Vitaly Kuznetsov
If some piece of code wants to check kexec_in_progress it has to be put
in #ifdef CONFIG_KEXEC block to not break the build in !CONFIG_KEXEC
case. Overcome this limitation by defining kexec_in_progress to false.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
include/linux/kexec.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index e804306..b63218f 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -323,6 +323,7 @@ struct pt_regs;
struct task_struct;
static inline void crash_kexec(struct pt_regs *regs) { }
static inline int kexec_should_crash(struct task_struct *p) { return 0; }
+#define kexec_in_progress false
#endif /* CONFIG_KEXEC */
#endif /* !defined(__ASSEBMLY__) */
--
1.7.4.1
--
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 00/10] Drivers: hv: vmbus: Enable kexec and other misc cleanup
In addition to enabling kexec, this patch-set has a bunch of miscellaneous fixes. Alex Ng (1): Drivers: hv: balloon: Enable dynamic memory protocol negotiation with Windows 10 hosts K. Y. Srinivasan (1): Drivers: hv: vmbus: Permit sending of packets without payload Vitaly Kuznetsov (8): Drivers: hv: vmbus: remove hv_synic_free_cpu() call from hv_synic_cleanup() kexec: define kexec_in_progress in !CONFIG_KEXEC case Drivers: hv: vmbus: add special kexec handler Drivers: hv: don't do hypercalls when hypercall_page is NULL Drivers: hv: vmbus: add special crash handler Drivers: hv: vmbus: prefer 'die' notification chain to 'panic' Drivers: hv: kvp: check kzalloc return value Drivers: hv: fcopy: dynamically allocate smsg_out in fcopy_send_data() arch/x86/include/asm/mshyperv.h |4 ++ arch/x86/kernel/cpu/mshyperv.c | 46 ++ drivers/hv/channel.c|4 ++- drivers/hv/hv.c | 15 drivers/hv/hv_balloon.c | 26 +++--- drivers/hv/hv_fcopy.c | 21 +++ drivers/hv/hv_kvp.c |3 ++ drivers/hv/vmbus_drv.c | 69 -- include/linux/kexec.h |1 + 9 files changed, 163 insertions(+), 26 deletions(-) -- 1.7.4.1 -- 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: [all better] Re: regression: massive trouble with fpu rework
On Sat, 2015-06-27 at 18:02 -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 27 Jun 2015, Mike Galbraith wrote:
> > > > BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily.
> >
> > That BIOS setting is annotated with the helpful text "Disabled for
> > Windows XP". It makes box say interesting things during boot, like...
> >
> > x86/fpu: XSTATE_CPUID missing!
> >
> >
> > ..or with HEAD, it triggers warning..
> >
> > if (boot_cpu_data.cpuid_level < XSTATE_CPUID) {
> > WARN_ON_FPU(1);
> > return;
> > }
> >
> > ..and all kinds of bad juju follows. I have no idea what the thing does
> > beyond what I can interpolate from the word 'limit'.
>
> Well, it is supposed to disable CPUID levels >= 0x04. This thing should
> *NEVER* be enabled, the last operating system that required it to be enabled
> was Windows 98.
>
> Can/do we override that crap during cpu init? If we cannot/don't, maybe
> instead of limping along with CPUID crippled, it would be better to either
> output a very nasty warning, or outright stop booting [with an appropriate
> error message] ?
Why get all upset? We didn't even notice before, nor did/does that
other OS. A casual "BTW, your BIOS sucks.." should suffice, no?
-Mike
--
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/
GOOD DAY, MY NAME IS FABIO VERDE , I WROTE TO YOU A MONTH AGO AND YOU DID NOT RESPOND THAT IS WHY I AM SENDING THIS MAIL ONCE AGAIN , I NEED YOUR ASSISTANCE TO TRANSFER 4.5 MILLION EUROS THROUGH AN OF
-- 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] scsi: storvsc: be more picky about scmnd->sc_data_direction
> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Thursday, June 25, 2015 9:12 AM
> To: linux-s...@vger.kernel.org
> Cc: Long Li; KY Srinivasan; Haiyang Zhang; James E.J. Bottomley;
> de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; Radim Krčmář
> Subject: [PATCH] scsi: storvsc: be more picky about scmnd-
> >sc_data_direction
>
> Under the 'default' case in scmnd->sc_data_direction we have 3 options:
> - DMA_NONE which we handle correctly.
> - DMA_BIDIRECTIONAL which is never supposed to be set by SCSI stack.
> - Garbage value.
>
> Do WARN() and return -EINVAL in the last two cases. virtio_scsi does
> BUG_ON() here but it looks like an overkill.
>
> Reported-by: Radim Krčmář
> Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
> ---
> drivers/scsi/storvsc_drv.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 3c6584f..61f4855 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1598,10 +1598,18 @@ static int storvsc_queuecommand(struct
> Scsi_Host *host, struct scsi_cmnd *scmnd)
> vm_srb->data_in = READ_TYPE;
> vm_srb->win8_extension.srb_flags |=
> SRB_FLAGS_DATA_IN;
> break;
> - default:
> + case DMA_NONE:
> vm_srb->data_in = UNKNOWN_TYPE;
> vm_srb->win8_extension.srb_flags |=
> SRB_FLAGS_NO_DATA_TRANSFER;
> break;
> + default:
> + /*
> + * This is DMA_BIDIRECTIONAL or something else we are
> never
> + * supposed to see here.
> + */
> + WARN(1, "Unexpected data direction: %d\n",
> + scmnd->sc_data_direction);
> + return -EINVAL;
> }
>
>
> --
> 2.4.3
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control
On Fri, Jun 26, 2015 at 11:17 PM, Ville Syrjälä wrote: > On Fri, Jun 26, 2015 at 06:31:37PM +0200, Daniel Vetter wrote: >> On Fri, Jun 26, 2015 at 02:32:03PM +0530, Shobhit Kumar wrote: >> > Hi, >> > Next update of the series reviewed at >> > https://lkml.org/lkml/2015/6/22/155 >> > >> > Major changes are few review comments from Varka and Ville being >> > addressed. Also except >> > for intel-gfx patches, all patches reviesion history is moved out of >> > commit message. >> > >> > Hope this series finally finds its mark. >> > >> > Regards >> > Shobhit >> > >> > Shobhit Kumar (7): >> > gpiolib: Add support for removing registered consumer lookup table >> > mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO >> > signal >> > mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC >> > mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM >> > pwm: crc: Add Crystalcove (CRC) PWM driver >> > drm/i915: Use the CRC gpio for panel enable/disable >> > drm/i915: Backlight control using CRC PMIC based PWM driver >> >> I think we have r-b/acks on all the patches now. Ok if I pull this in >> through drm-intel.git for 4.3? Or should I make a topic branch with tag >> and then send out pull requests to everyone? Or will each maintainer merge >> on their own since it's all only coupled at runtime anyway? Any of these >> would suit me. > > I forgot to mention that I had a build failure due to > builtin_platform_driver() when I tried this (just changed it to > module_platform_driver() to get past it). So I'm not sure if this > now depends on some tree which isn't included in -nightly... These patches are based on linux-next/master Regards Shobhit -- 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/
[RFC v3 01/24] scsi/atari_scsi: Dont select CONFIG_NVRAM
On powerpc, setting CONFIG_NVRAM=n builds a kernel with no NVRAM support.
Setting CONFIG_NVRAM=m enables the /dev/nvram misc device module without
enabling NVRAM support in drivers. Setting CONFIG_NVRAM=y enables the
misc device (built-in) and also enables NVRAM support in drivers.
m68k shares the valkyriefb driver with powerpc, and since that driver uses
NVRAM, it is affected by CONFIG_ATARI_SCSI, because of the use of
"select NVRAM".
Adopt the powerpc convention on m68k to avoid surprises.
Signed-off-by: Finn Thain
---
This patch temporarily disables CONFIG_NVRAM on Atari, to prevent build
failures when bisecting the rest of this patch series. It gets enabled
again with the introduction of CONFIG_HAVE_ARCH_NVRAM_OPS, once the
nvram_* global functions have been moved to an ops struct.
The removal of "select NVRAM" may mean that some kernel configs (such
as Debian/m68k) may need tweaking.
---
drivers/char/Kconfig |5 +
drivers/scsi/Kconfig |6 +++---
drivers/scsi/atari_scsi.c |8
3 files changed, 8 insertions(+), 11 deletions(-)
Index: linux/drivers/char/Kconfig
===
--- linux.orig/drivers/char/Kconfig 2015-06-28 11:41:28.0 +1000
+++ linux/drivers/char/Kconfig 2015-06-28 11:41:28.0 +1000
@@ -247,7 +247,7 @@ source "drivers/char/hw_random/Kconfig"
config NVRAM
tristate "/dev/nvram support"
- depends on ATARI || X86 || (ARM && RTC_DRV_CMOS) || GENERIC_NVRAM
+ depends on X86 || (ARM && RTC_DRV_CMOS) || GENERIC_NVRAM
---help---
If you say Y here and create a character special file /dev/nvram
with major number 10 and minor number 144 using mknod ("man mknod"),
@@ -265,9 +265,6 @@ config NVRAM
should NEVER idly tamper with it. See Ralf Brown's interrupt list
for a guide to the use of CMOS bytes by your BIOS.
- On Atari machines, /dev/nvram is always configured and does not need
- to be selected.
-
To compile this driver as a module, choose M here: the
module will be called nvram.
Index: linux/drivers/scsi/Kconfig
===
--- linux.orig/drivers/scsi/Kconfig 2015-06-28 11:41:28.0 +1000
+++ linux/drivers/scsi/Kconfig 2015-06-28 11:41:28.0 +1000
@@ -1592,14 +1592,14 @@ config ATARI_SCSI
tristate "Atari native SCSI support"
depends on ATARI && SCSI
select SCSI_SPI_ATTRS
- select NVRAM
---help---
If you have an Atari with built-in NCR5380 SCSI controller (TT,
Falcon, ...) say Y to get it supported. Of course also, if you have
a compatible SCSI controller (e.g. for Medusa).
- To compile this driver as a module, choose M here: the
- module will be called atari_scsi.
+ To compile this driver as a module, choose M here: the module will
+ be called atari_scsi. If you also enable NVRAM support, the SCSI
+ host's ID is taken from the setting in TT RTC NVRAM.
This driver supports both styles of NCR integration into the
system: the TT style (separate DMA), and the Falcon style (via
Index: linux/drivers/scsi/atari_scsi.c
===
--- linux.orig/drivers/scsi/atari_scsi.c2015-06-28 11:41:28.0
+1000
+++ linux/drivers/scsi/atari_scsi.c 2015-06-28 11:41:28.0 +1000
@@ -875,9 +875,10 @@ static int __init atari_scsi_probe(struc
if (ATARIHW_PRESENT(TT_SCSI) && setup_sg_tablesize >= 0)
atari_scsi_template.sg_tablesize = setup_sg_tablesize;
- if (setup_hostid >= 0) {
+ if (setup_hostid >= 0)
atari_scsi_template.this_id = setup_hostid & 7;
- } else {
+#ifdef CONFIG_NVRAM
+ else
/* Test if a host id is set in the NVRam */
if (ATARIHW_PRESENT(TT_CLK) && nvram_check_checksum()) {
unsigned char b = nvram_read_byte(14);
@@ -888,8 +889,7 @@ static int __init atari_scsi_probe(struc
if (b & 0x80)
atari_scsi_template.this_id = b & 7;
}
- }
-
+#endif
#ifdef REAL_DMA
/* If running on a Falcon and if there's TT-Ram (i.e., more than one
--
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/
[RFC v3 02/24] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
Move the m68k-specific code elsewhere to make the driver generic.
Change the vmode calculation from logical OR to bitwise OR, since it is
obviously wrong.
Signed-off-by: Finn Thain
---
BTW, I didn't change the SCSI ID location in NVRAM. This code says 16
whereas atari_scsi says 14. Which one is correct?
---
arch/m68k/atari/Makefile |2
arch/m68k/atari/nvram.c | 255 ++
drivers/char/nvram.c | 280 +--
3 files changed, 292 insertions(+), 245 deletions(-)
Index: linux/arch/m68k/atari/nvram.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux/arch/m68k/atari/nvram.c 2015-06-28 11:41:29.0 +1000
@@ -0,0 +1,255 @@
+/*
+ * CMOS/NV-RAM driver for Atari. Adapted from drivers/char/nvram.c.
+ * Copyright (C) 1997 Roman Hodek
+ * idea by and with help from Richard Jelinek
+ * Portions copyright (c) 2001,2002 Sun Microsystems (thoc...@sun.com)
+ * Further contributions from Cesar Barros, Erik Gilling, Tim Hockin and
+ * Wim Van Sebroeck.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NVRAM_BYTES50
+
+/* It is worth noting that these functions all access bytes of general
+ * purpose memory in the NVRAM - that is to say, they all add the
+ * NVRAM_FIRST_BYTE offset. Pass them offsets into NVRAM as if you did not
+ * know about the RTC cruft.
+ */
+
+/* Note that *all* calls to CMOS_READ and CMOS_WRITE must be done with
+ * rtc_lock held. Due to the index-port/data-port design of the RTC, we
+ * don't want two different things trying to get to it at once. (e.g. the
+ * periodic 11 min sync from kernel/time/ntp.c vs. this driver.)
+ */
+
+unsigned char __nvram_read_byte(int i)
+{
+ return CMOS_READ(NVRAM_FIRST_BYTE + i);
+}
+
+unsigned char nvram_read_byte(int i)
+{
+ unsigned long flags;
+ unsigned char c;
+
+ spin_lock_irqsave(&rtc_lock, flags);
+ c = __nvram_read_byte(i);
+ spin_unlock_irqrestore(&rtc_lock, flags);
+ return c;
+}
+EXPORT_SYMBOL(nvram_read_byte);
+
+/* This races nicely with trying to read with checksum checking */
+void __nvram_write_byte(unsigned char c, int i)
+{
+ CMOS_WRITE(c, NVRAM_FIRST_BYTE + i);
+}
+
+void nvram_write_byte(unsigned char c, int i)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&rtc_lock, flags);
+ __nvram_write_byte(c, i);
+ spin_unlock_irqrestore(&rtc_lock, flags);
+}
+
+/* On Ataris, the checksum is over all bytes except the checksum bytes
+ * themselves; these are at the very end.
+ */
+#define ATARI_CKS_RANGE_START 0
+#define ATARI_CKS_RANGE_END47
+#define ATARI_CKS_LOC 48
+
+int __nvram_check_checksum(void)
+{
+ int i;
+ unsigned char sum = 0;
+
+ for (i = ATARI_CKS_RANGE_START; i <= ATARI_CKS_RANGE_END; ++i)
+ sum += __nvram_read_byte(i);
+ return (__nvram_read_byte(ATARI_CKS_LOC) == (~sum & 0xff)) &&
+ (__nvram_read_byte(ATARI_CKS_LOC + 1) == (sum & 0xff));
+}
+
+int nvram_check_checksum(void)
+{
+ unsigned long flags;
+ int rv;
+
+ spin_lock_irqsave(&rtc_lock, flags);
+ rv = __nvram_check_checksum();
+ spin_unlock_irqrestore(&rtc_lock, flags);
+ return rv;
+}
+EXPORT_SYMBOL(nvram_check_checksum);
+
+static void __nvram_set_checksum(void)
+{
+ int i;
+ unsigned char sum = 0;
+
+ for (i = ATARI_CKS_RANGE_START; i <= ATARI_CKS_RANGE_END; ++i)
+ sum += __nvram_read_byte(i);
+ __nvram_write_byte(~sum, ATARI_CKS_LOC);
+ __nvram_write_byte(sum, ATARI_CKS_LOC + 1);
+}
+
+#ifdef CONFIG_PROC_FS
+static struct {
+ unsigned char val;
+ char *name;
+} boot_prefs[] = {
+ { 0x80, "TOS" },
+ { 0x40, "ASV" },
+ { 0x20, "NetBSD (?)" },
+ { 0x10, "Linux" },
+ { 0x00, "unspecified" },
+};
+
+static char *languages[] = {
+ "English (US)",
+ "German",
+ "French",
+ "English (UK)",
+ "Spanish",
+ "Italian",
+ "6 (undefined)",
+ "Swiss (French)",
+ "Swiss (German)",
+};
+
+static char *dateformat[] = {
+ "MM%cDD%cYY",
+ "DD%cMM%cYY",
+ "YY%cMM%cDD",
+ "YY%cDD%cMM",
+ "4 (undefined)",
+ "5 (undefined)",
+ "6 (undefined)",
+ "7 (undefined)",
+};
+
+static char *colors[] = {
+ "2", "4", "16", "256", "65536", "??", "??", "??"
+};
+
+static void atari_nvram_proc_read(unsigned char *nvram, struct seq_file *seq,
+ void *offset)
+{
+ int checksum;
+ int i;
+ unsigned vmode;
+
+ spin_lock_irq(&rtc_lock);
+ checksum = __nvram_check_checksum();
+ spin_unlock_irq(&rtc_lock);
+
+ seq_printf(seq, "Checksum status : %svalid\n", checksum ? "" : "not ");
+
+ seq_puts(seq, "B
[RFC v3 03/24] m68k/atari: Replace nvram_{read,write}_byte with arch_nvram_ops
By implementing an arch_nvram_ops struct, any platform can re-use the
drivers/char/nvram module without needing any arch-specific code
in that module. Atari does so here.
Atari has one user of nvram_check_checksum() whereas the other platforms
(i.e. x86 and ARM platforms) have none at all. Replace this
validate-checksum-and-read-byte sequence with the equivalent
rtc_nvram_ops.read() call and remove the now unused functions.
Signed-off-by: Finn Thain
---
The advantage of the new ops struct over the old global nvram_* functions
is that the misc device module can be shared by different platforms
without requiring every platform to implement every nvram_* function.
E.g. only RTC "CMOS" NVRAMs have a checksum and only PowerPC platforms
have a "sync" ioctl.
---
arch/m68k/atari/nvram.c | 89 --
drivers/scsi/atari_scsi.c |8 ++--
include/linux/nvram.h |9
3 files changed, 70 insertions(+), 36 deletions(-)
Index: linux/arch/m68k/atari/nvram.c
===
--- linux.orig/arch/m68k/atari/nvram.c 2015-06-28 11:41:29.0 +1000
+++ linux/arch/m68k/atari/nvram.c 2015-06-28 11:41:31.0 +1000
@@ -38,33 +38,12 @@ unsigned char __nvram_read_byte(int i)
return CMOS_READ(NVRAM_FIRST_BYTE + i);
}
-unsigned char nvram_read_byte(int i)
-{
- unsigned long flags;
- unsigned char c;
-
- spin_lock_irqsave(&rtc_lock, flags);
- c = __nvram_read_byte(i);
- spin_unlock_irqrestore(&rtc_lock, flags);
- return c;
-}
-EXPORT_SYMBOL(nvram_read_byte);
-
/* This races nicely with trying to read with checksum checking */
void __nvram_write_byte(unsigned char c, int i)
{
CMOS_WRITE(c, NVRAM_FIRST_BYTE + i);
}
-void nvram_write_byte(unsigned char c, int i)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&rtc_lock, flags);
- __nvram_write_byte(c, i);
- spin_unlock_irqrestore(&rtc_lock, flags);
-}
-
/* On Ataris, the checksum is over all bytes except the checksum bytes
* themselves; these are at the very end.
*/
@@ -83,18 +62,6 @@ int __nvram_check_checksum(void)
(__nvram_read_byte(ATARI_CKS_LOC + 1) == (sum & 0xff));
}
-int nvram_check_checksum(void)
-{
- unsigned long flags;
- int rv;
-
- spin_lock_irqsave(&rtc_lock, flags);
- rv = __nvram_check_checksum();
- spin_unlock_irqrestore(&rtc_lock, flags);
- return rv;
-}
-EXPORT_SYMBOL(nvram_check_checksum);
-
static void __nvram_set_checksum(void)
{
int i;
@@ -106,6 +73,62 @@ static void __nvram_set_checksum(void)
__nvram_write_byte(sum, ATARI_CKS_LOC + 1);
}
+static ssize_t nvram_read(char *buf, size_t count, loff_t *ppos)
+{
+ char *p = buf;
+ loff_t i;
+
+ spin_lock_irq(&rtc_lock);
+
+ if (!__nvram_check_checksum()) {
+ spin_unlock_irq(&rtc_lock);
+ return -EIO;
+ }
+
+ for (i = *ppos; count > 0 && i < NVRAM_BYTES; --count, ++i, ++p)
+ *p = __nvram_read_byte(i);
+
+ spin_unlock_irq(&rtc_lock);
+
+ *ppos = i;
+ return p - buf;
+}
+
+static ssize_t nvram_write(char *buf, size_t count, loff_t *ppos)
+{
+ char *p = buf;
+ loff_t i;
+
+ spin_lock_irq(&rtc_lock);
+
+ if (!__nvram_check_checksum()) {
+ spin_unlock_irq(&rtc_lock);
+ return -EIO;
+ }
+
+ for (i = *ppos; count > 0 && i < NVRAM_BYTES; --count, ++i, ++p)
+ __nvram_write_byte(*p, i);
+
+ __nvram_set_checksum();
+
+ spin_unlock_irq(&rtc_lock);
+
+ *ppos = i;
+ return p - buf;
+}
+
+static ssize_t nvram_get_size(void)
+{
+ return NVRAM_BYTES;
+}
+
+const struct nvram_ops arch_nvram_ops = {
+ .read = nvram_read,
+ .write = nvram_write,
+ .get_size = nvram_get_size,
+};
+EXPORT_SYMBOL(arch_nvram_ops);
+
#ifdef CONFIG_PROC_FS
static struct {
unsigned char val;
Index: linux/drivers/scsi/atari_scsi.c
===
--- linux.orig/drivers/scsi/atari_scsi.c2015-06-28 11:41:28.0
+1000
+++ linux/drivers/scsi/atari_scsi.c 2015-06-28 11:41:31.0 +1000
@@ -880,13 +880,15 @@ static int __init atari_scsi_probe(struc
#ifdef CONFIG_NVRAM
else
/* Test if a host id is set in the NVRam */
- if (ATARIHW_PRESENT(TT_CLK) && nvram_check_checksum()) {
- unsigned char b = nvram_read_byte(14);
+ if (ATARIHW_PRESENT(TT_CLK)) {
+ unsigned char b;
+ loff_t offset = 14;
+ ssize_t count = arch_nvram_ops.read(&b, 1, &offset);
/* Arbitration enabled? (for TOS)
* If yes, use configured host ID
*/
- if (b &
[RFC v3 08/24] char/nvram: Implement NVRAM read/write methods
Refactor the RTC "CMOS" NVRAM functions so that they can be used as
arch_nvram_ops methods. Checksumming logic is moved from the misc device
operations to the nvram read/write operations.
This makes the misc device implementation more generic. This also
preserves the locking semantics such that "read if checksum valid" and
"write and update checksum" remain atomic operations.
PPC64 implements byte-range read/write methods which are similar to
file_operations struct methods. Other platforms provide only
byte-at-a-time functions. So the misc device prefers the former but
will fall back on the latter.
Signed-off-by: Finn Thain
---
drivers/char/nvram.c | 162 +++
1 file changed, 114 insertions(+), 48 deletions(-)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/drivers/char/nvram.c 2015-06-28 11:41:36.0 +1000
+++ linux/drivers/char/nvram.c 2015-06-28 11:41:37.0 +1000
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -178,9 +179,48 @@ static ssize_t nvram_get_size(void)
return NVRAM_BYTES;
}
+static ssize_t nvram_read(char *buf, size_t count, loff_t *ppos)
+{
+ char *p = buf;
+ loff_t i;
+
+ spin_lock_irq(&rtc_lock);
+ if (!__nvram_check_checksum()) {
+ spin_unlock_irq(&rtc_lock);
+ return -EIO;
+ }
+ for (i = *ppos; count > 0 && i < NVRAM_BYTES; --count, ++i, ++p)
+ *p = __nvram_read_byte(i);
+ spin_unlock_irq(&rtc_lock);
+
+ *ppos = i;
+ return p - buf;
+}
+
+static ssize_t nvram_write(char *buf, size_t count, loff_t *ppos)
+{
+ char *p = buf;
+ loff_t i;
+
+ spin_lock_irq(&rtc_lock);
+ if (!__nvram_check_checksum()) {
+ spin_unlock_irq(&rtc_lock);
+ return -EIO;
+ }
+ for (i = *ppos; count > 0 && i < NVRAM_BYTES; --count, ++i, ++p)
+ __nvram_write_byte(*p, i);
+ __nvram_set_checksum();
+ spin_unlock_irq(&rtc_lock);
+
+ *ppos = i;
+ return p - buf;
+}
+
const struct nvram_ops arch_nvram_ops = {
.read_byte = nvram_read_byte,
.write_byte = nvram_write_byte,
+ .read = nvram_read,
+ .write = nvram_write,
.get_size = nvram_get_size,
.set_checksum = nvram_set_checksum,
.initialize = nvram_initialize,
@@ -215,69 +255,95 @@ static loff_t nvram_misc_llseek(struct f
static ssize_t nvram_misc_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
- unsigned char contents[NVRAM_BYTES];
- unsigned i = *ppos;
- unsigned char *tmp;
-
- spin_lock_irq(&rtc_lock);
+ loff_t i;
+ char __user *p = buf;
- if (!__nvram_check_checksum())
- goto checksum_err;
-
- for (tmp = contents; count-- > 0 && i < NVRAM_BYTES; ++i, ++tmp)
- *tmp = __nvram_read_byte(i);
-
- spin_unlock_irq(&rtc_lock);
-
- if (copy_to_user(buf, contents, tmp - contents))
+ if (!access_ok(VERIFY_WRITE, buf, count))
return -EFAULT;
+ if (*ppos >= nvram_size)
+ return 0;
- *ppos = i;
-
- return tmp - contents;
+ /* If the arch provided a byte range read op, use it. Otherwise
+* fall back on the byte-at-a-time accessor.
+*/
+ if (arch_nvram_ops.read != NULL) {
+ char *tmp;
+ ssize_t ret;
+
+ count = min_t(size_t, count, nvram_size - *ppos);
+ count = min_t(size_t, count, PAGE_SIZE);
+
+ tmp = kmalloc(count, GFP_KERNEL);
+ if (!tmp)
+ return -ENOMEM;
+
+ ret = arch_nvram_ops.read(tmp, count, ppos);
+ if (ret <= 0)
+ goto out;
+
+ if (copy_to_user(buf, tmp, ret)) {
+ *ppos -= ret;
+ ret = -EFAULT;
+ }
+
+out:
+ kfree(tmp);
+ return ret;
+ }
-checksum_err:
- spin_unlock_irq(&rtc_lock);
- return -EIO;
+ for (i = *ppos; count > 0 && i < nvram_size; ++i, ++p, --count)
+ if (__put_user(arch_nvram_ops.read_byte(i), p))
+ return -EFAULT;
+ *ppos = i;
+ return p - buf;
}
static ssize_t nvram_misc_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
- unsigned char contents[NVRAM_BYTES];
- unsigned i = *ppos;
- unsigned char *tmp;
-
- if (i >= NVRAM_BYTES)
- return 0; /* Past EOF */
-
- if (count > NVRAM_BYTES - i)
- count = NVRAM_BYTES - i;
- if (count > NVRAM_BYTES)
- return -EFAULT; /* Can't happen, b
[RFC v3 06/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()
Make use of arch_nvram_ops in the thinkpad_acpi driver so that the
nvram_* function exports can be removed.
This patch series was tested on a ThinkPad T43.
Signed-off-by: Finn Thain
Acked-by: Henrique de Moraes Holschuh
Reviewed-by: Darren Hart
---
drivers/platform/x86/thinkpad_acpi.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
Index: linux/drivers/platform/x86/thinkpad_acpi.c
===
--- linux.orig/drivers/platform/x86/thinkpad_acpi.c 2015-06-28
11:41:28.0 +1000
+++ linux/drivers/platform/x86/thinkpad_acpi.c 2015-06-28 11:41:35.0
+1000
@@ -2311,30 +2311,30 @@ static void hotkey_read_nvram(struct tp_
u8 d;
if (m & TP_NVRAM_HKEY_GROUP_HK2) {
- d = nvram_read_byte(TP_NVRAM_ADDR_HK2);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_HK2);
n->thinkpad_toggle = !!(d & TP_NVRAM_MASK_HKT_THINKPAD);
n->zoom_toggle = !!(d & TP_NVRAM_MASK_HKT_ZOOM);
n->display_toggle = !!(d & TP_NVRAM_MASK_HKT_DISPLAY);
n->hibernate_toggle = !!(d & TP_NVRAM_MASK_HKT_HIBERNATE);
}
if (m & TP_ACPI_HKEY_THNKLGHT_MASK) {
- d = nvram_read_byte(TP_NVRAM_ADDR_THINKLIGHT);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_THINKLIGHT);
n->thinklight_toggle = !!(d & TP_NVRAM_MASK_THINKLIGHT);
}
if (m & TP_ACPI_HKEY_DISPXPAND_MASK) {
- d = nvram_read_byte(TP_NVRAM_ADDR_VIDEO);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_VIDEO);
n->displayexp_toggle =
!!(d & TP_NVRAM_MASK_HKT_DISPEXPND);
}
if (m & TP_NVRAM_HKEY_GROUP_BRIGHTNESS) {
- d = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
n->brightness_level = (d & TP_NVRAM_MASK_LEVEL_BRIGHTNESS)
>> TP_NVRAM_POS_LEVEL_BRIGHTNESS;
n->brightness_toggle =
!!(d & TP_NVRAM_MASK_HKT_BRIGHTNESS);
}
if (m & TP_NVRAM_HKEY_GROUP_VOLUME) {
- d = nvram_read_byte(TP_NVRAM_ADDR_MIXER);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER);
n->volume_level = (d & TP_NVRAM_MASK_LEVEL_VOLUME)
>> TP_NVRAM_POS_LEVEL_VOLUME;
n->mute = !!(d & TP_NVRAM_MASK_MUTE);
@@ -6155,7 +6155,7 @@ static unsigned int tpacpi_brightness_nv
{
u8 lnvram;
- lnvram = (nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS)
+ lnvram = (arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS)
& TP_NVRAM_MASK_LEVEL_BRIGHTNESS)
>> TP_NVRAM_POS_LEVEL_BRIGHTNESS;
lnvram &= bright_maxlvl;
@@ -6180,7 +6180,7 @@ static void tpacpi_brightness_checkpoint
if (unlikely(!acpi_ec_read(TP_EC_BACKLIGHT, &lec)))
goto unlock;
lec &= TP_EC_BACKLIGHT_LVLMSK;
- b_nvram = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
+ b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
if (lec != ((b_nvram & TP_NVRAM_MASK_LEVEL_BRIGHTNESS)
>> TP_NVRAM_POS_LEVEL_BRIGHTNESS)) {
@@ -6188,7 +6188,7 @@ static void tpacpi_brightness_checkpoint
b_nvram &= ~(TP_NVRAM_MASK_LEVEL_BRIGHTNESS <<
TP_NVRAM_POS_LEVEL_BRIGHTNESS);
b_nvram |= lec;
- nvram_write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS);
+ arch_nvram_ops.write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS);
dbg_printk(TPACPI_DBG_BRGHT,
"updated NVRAM backlight level to %u (0x%02x)\n",
(unsigned int) lec, (unsigned int) b_nvram);
@@ -6796,13 +6796,13 @@ static void tpacpi_volume_checkpoint_nvr
if (unlikely(!acpi_ec_read(TP_EC_AUDIO, &lec)))
goto unlock;
lec &= ec_mask;
- b_nvram = nvram_read_byte(TP_NVRAM_ADDR_MIXER);
+ b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER);
if (lec != (b_nvram & ec_mask)) {
/* NVRAM needs update */
b_nvram &= ~ec_mask;
b_nvram |= lec;
- nvram_write_byte(b_nvram, TP_NVRAM_ADDR_MIXER);
+ arch_nvram_ops.write_byte(b_nvram, TP_NVRAM_ADDR_MIXER);
dbg_printk(TPACPI_DBG_MIXER,
"updated NVRAM mixer status to 0x%02x (0x%02x)\n",
(unsigned int) lec, (unsigned int) b_nvram);
--
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/
[RFC v3 07/24] char/nvram: Allow the set_checksum and initialize ioctls to be omitted
The drivers/char/nvram module has previously only supported RTC "CMOS"
NVRAM, for which it provides appropriate checksum ioctls. Make these
ioctls optional so the module can be re-used with other kinds of NVRAM.
The ops struct methods that implement the ioctls now return error
codes so that a multi-platform kernel binary can do the right thing when
running on hardware without suitable NVRAM.
Signed-off-by: Finn Thain
---
Changed since v1:
- Don't bother acquiring the mutex for unimplemented ioctls.
---
drivers/char/nvram.c | 71 --
include/linux/nvram.h |2 +
2 files changed, 43 insertions(+), 30 deletions(-)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/drivers/char/nvram.c 2015-06-28 11:41:34.0 +1000
+++ linux/drivers/char/nvram.c 2015-06-28 11:41:36.0 +1000
@@ -153,16 +153,25 @@ static void __nvram_set_checksum(void)
__nvram_write_byte(sum & 0xff, PC_CKS_LOC + 1);
}
-#if 0
-void nvram_set_checksum(void)
+static long nvram_set_checksum(void)
{
- unsigned long flags;
+ spin_lock_irq(&rtc_lock);
+ __nvram_set_checksum();
+ spin_unlock_irq(&rtc_lock);
+ return 0;
+}
+
+static long nvram_initialize(void)
+{
+ ssize_t i;
- spin_lock_irqsave(&rtc_lock, flags);
+ spin_lock_irq(&rtc_lock);
+ for (i = 0; i < NVRAM_BYTES; ++i)
+ __nvram_write_byte(0, i);
__nvram_set_checksum();
- spin_unlock_irqrestore(&rtc_lock, flags);
+ spin_unlock_irq(&rtc_lock);
+ return 0;
}
-#endif /* 0 */
static ssize_t nvram_get_size(void)
{
@@ -173,6 +182,8 @@ const struct nvram_ops arch_nvram_ops =
.read_byte = nvram_read_byte,
.write_byte = nvram_write_byte,
.get_size = nvram_get_size,
+ .set_checksum = nvram_set_checksum,
+ .initialize = nvram_initialize,
};
EXPORT_SYMBOL(arch_nvram_ops);
@@ -272,51 +283,51 @@ checksum_err:
static long nvram_misc_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
- int i;
+ long ret = -ENOTTY;
switch (cmd) {
-
case NVRAM_INIT:
/* initialize NVRAM contents and checksum */
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
- mutex_lock(&nvram_mutex);
- spin_lock_irq(&rtc_lock);
-
- for (i = 0; i < NVRAM_BYTES; ++i)
- __nvram_write_byte(0, i);
- __nvram_set_checksum();
-
- spin_unlock_irq(&rtc_lock);
- mutex_unlock(&nvram_mutex);
- return 0;
-
+ if (arch_nvram_ops.initialize != NULL) {
+ mutex_lock(&nvram_mutex);
+ ret = arch_nvram_ops.initialize();
+ mutex_unlock(&nvram_mutex);
+ }
+ break;
case NVRAM_SETCKS:
/* just set checksum, contents unchanged (maybe useful after
* checksum garbaged somehow...) */
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
- mutex_lock(&nvram_mutex);
- spin_lock_irq(&rtc_lock);
- __nvram_set_checksum();
- spin_unlock_irq(&rtc_lock);
- mutex_unlock(&nvram_mutex);
- return 0;
-
- default:
- return -ENOTTY;
+ if (arch_nvram_ops.set_checksum != NULL) {
+ mutex_lock(&nvram_mutex);
+ ret = arch_nvram_ops.set_checksum();
+ mutex_unlock(&nvram_mutex);
+ }
+ break;
}
+ return ret;
}
static int nvram_misc_open(struct inode *inode, struct file *file)
{
spin_lock(&nvram_state_lock);
+ /* Prevent multiple readers/writers if desired. */
if ((nvram_open_cnt && (file->f_flags & O_EXCL)) ||
- (nvram_open_mode & NVRAM_EXCL) ||
- ((file->f_mode & FMODE_WRITE) && (nvram_open_mode & NVRAM_WRITE))) {
+ (nvram_open_mode & NVRAM_EXCL)) {
+ spin_unlock(&nvram_state_lock);
+ return -EBUSY;
+ }
+
+ /* Prevent multiple writers if the set_checksum ioctl is implemented. */
+ if ((arch_nvram_ops.set_checksum != NULL) &&
+ (file->f_mode & FMODE_WRITE) &&
+ (nvram_open_mode & NVRAM_WRITE)) {
spin_unlock(&nvram_state_lock);
return -EBUSY;
}
Index: linux/include/linux/nvram.h
===
--- linux.orig/include/linux/nvram.h2015-06-28 11:41:34.0 +1000
+++ linux/include/linux/nvram.h 2015-06-28 11:41:36.0 +1000
@@ -17,6 +17,8 @@ struct nvram_ops {
unsigned char (*read_byte)(int);
void
[RFC v3 12/24] powerpc: Cleanup nvram includes
The nvram_read_byte() and nvram_write_byte() definitions in asm/nvram.h duplicate those in linux/nvram.h. Get rid of the former to prepare for adoption of struct arch_nvram_ops (which is defined in linux/nvram.h for general use). Signed-off-by: Finn Thain --- arch/powerpc/include/asm/nvram.h |3 --- arch/powerpc/kernel/setup_32.c |1 + drivers/char/generic_nvram.c |4 +++- drivers/video/fbdev/matrox/matroxfb_base.c |2 +- 4 files changed, 5 insertions(+), 5 deletions(-) Index: linux/arch/powerpc/include/asm/nvram.h === --- linux.orig/arch/powerpc/include/asm/nvram.h 2015-06-28 11:41:27.0 +1000 +++ linux/arch/powerpc/include/asm/nvram.h 2015-06-28 11:41:41.0 +1000 @@ -101,7 +101,4 @@ extern int nvram_write_os_partition(stru /* Determine NVRAM size */ extern ssize_t nvram_get_size(void); -/* Normal access to NVRAM */ -extern unsigned char nvram_read_byte(int i); -extern void nvram_write_byte(unsigned char c, int i); #endif /* _ASM_POWERPC_NVRAM_H */ Index: linux/arch/powerpc/kernel/setup_32.c === --- linux.orig/arch/powerpc/kernel/setup_32.c 2015-06-28 11:41:27.0 +1000 +++ linux/arch/powerpc/kernel/setup_32.c2015-06-28 11:41:41.0 +1000 @@ -16,6 +16,7 @@ #include #include #include +#include #include #include Index: linux/drivers/char/generic_nvram.c === --- linux.orig/drivers/char/generic_nvram.c 2015-06-28 11:41:27.0 +1000 +++ linux/drivers/char/generic_nvram.c 2015-06-28 11:41:41.0 +1000 @@ -20,9 +20,11 @@ #include #include #include +#include #include -#include + #ifdef CONFIG_PPC_PMAC +#include #include #endif Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c === --- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-06-28 11:41:27.0 +1000 +++ linux/drivers/video/fbdev/matrox/matroxfb_base.c2015-06-28 11:41:41.0 +1000 @@ -111,12 +111,12 @@ #include "matroxfb_g450.h" #include #include +#include #include #include #ifdef CONFIG_PPC_PMAC #include -unsigned char nvram_read_byte(int); static int default_vmode = VMODE_NVRAM; static int default_cmode = CMODE_NVRAM; #endif -- 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/
[RFC v3 10/24] m68k/atari: Implement arch_nvram_ops methods and enable CONFIG_HAVE_ARCH_NVRAM_OPS
Atari RTC NVRAM has a checksum so implement the remaining arch_nvram_ops
methods for the set_checksum and initialize ioctls. Enable
CONFIG_HAVE_ARCH_NVRAM_OPS.
Signed-off-by: Finn Thain
---
This re-enables the nvram module for Atari.
---
arch/m68k/Kconfig |3 +++
arch/m68k/atari/nvram.c | 24
drivers/char/Kconfig|2 +-
3 files changed, 28 insertions(+), 1 deletion(-)
Index: linux/arch/m68k/atari/nvram.c
===
--- linux.orig/arch/m68k/atari/nvram.c 2015-06-28 11:41:31.0 +1000
+++ linux/arch/m68k/atari/nvram.c 2015-06-28 11:41:39.0 +1000
@@ -73,6 +73,26 @@ static void __nvram_set_checksum(void)
__nvram_write_byte(sum, ATARI_CKS_LOC + 1);
}
+static long nvram_set_checksum(void)
+{
+ spin_lock_irq(&rtc_lock);
+ __nvram_set_checksum();
+ spin_unlock_irq(&rtc_lock);
+ return 0;
+}
+
+static long nvram_initialize(void)
+{
+ loff_t i;
+
+ spin_lock_irq(&rtc_lock);
+ for (i = 0; i < NVRAM_BYTES; ++i)
+ __nvram_write_byte(0, i);
+ __nvram_set_checksum();
+ spin_unlock_irq(&rtc_lock);
+ return 0;
+}
+
static ssize_t nvram_read(char *buf, size_t count, loff_t *ppos)
{
char *p = buf;
@@ -119,6 +139,8 @@ static ssize_t nvram_write(char *buf, si
static ssize_t nvram_get_size(void)
{
+ if (!MACH_IS_ATARI)
+ return -ENODEV;
return NVRAM_BYTES;
}
@@ -126,6 +148,8 @@ const struct nvram_ops arch_nvram_ops =
.read = nvram_read,
.write = nvram_write,
.get_size = nvram_get_size,
+ .set_checksum = nvram_set_checksum,
+ .initialize = nvram_initialize,
};
EXPORT_SYMBOL(arch_nvram_ops);
Index: linux/drivers/char/Kconfig
===
--- linux.orig/drivers/char/Kconfig 2015-06-28 11:41:28.0 +1000
+++ linux/drivers/char/Kconfig 2015-06-28 11:41:39.0 +1000
@@ -247,7 +247,7 @@ source "drivers/char/hw_random/Kconfig"
config NVRAM
tristate "/dev/nvram support"
- depends on X86 || (ARM && RTC_DRV_CMOS) || GENERIC_NVRAM
+ depends on X86 || (ARM && RTC_DRV_CMOS) || GENERIC_NVRAM ||
HAVE_ARCH_NVRAM_OPS
---help---
If you say Y here and create a character special file /dev/nvram
with major number 10 and minor number 144 using mknod ("man mknod"),
Index: linux/arch/m68k/Kconfig
===
--- linux.orig/arch/m68k/Kconfig2015-06-28 11:41:27.0 +1000
+++ linux/arch/m68k/Kconfig 2015-06-28 11:41:39.0 +1000
@@ -71,6 +71,9 @@ config PGTABLE_LEVELS
default 2 if SUN3 || COLDFIRE
default 3
+config HAVE_ARCH_NVRAM_OPS
+ def_bool ATARI
+
source "init/Kconfig"
source "kernel/Kconfig.freezer"
--
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/
[RFC v3 09/24] char/nvram: Use generic fixed_size_llseek()
Signed-off-by: Finn Thain
---
drivers/char/nvram.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/drivers/char/nvram.c 2015-06-28 11:41:37.0 +1000
+++ linux/drivers/char/nvram.c 2015-06-28 11:41:38.0 +1000
@@ -235,21 +235,7 @@ EXPORT_SYMBOL(arch_nvram_ops);
static loff_t nvram_misc_llseek(struct file *file, loff_t offset, int origin)
{
- switch (origin) {
- case 0:
- /* nothing to do */
- break;
- case 1:
- offset += file->f_pos;
- break;
- case 2:
- offset += NVRAM_BYTES;
- break;
- default:
- return -EINVAL;
- }
-
- return (offset >= 0) ? (file->f_pos = offset) : -EINVAL;
+ return fixed_size_llseek(file, offset, origin, nvram_size);
}
static ssize_t nvram_misc_read(struct file *file, char __user *buf,
--
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/
[RFC v3 11/24] char/nvram: Add "devname:nvram" module alias
Signed-off-by: Finn Thain
---
drivers/char/nvram.c |1 +
1 file changed, 1 insertion(+)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/drivers/char/nvram.c 2015-06-28 11:41:38.0 +1000
+++ linux/drivers/char/nvram.c 2015-06-28 11:41:40.0 +1000
@@ -577,3 +577,4 @@ module_exit(nvram_module_exit);
MODULE_LICENSE("GPL");
MODULE_ALIAS_MISCDEV(NVRAM_MINOR);
+MODULE_ALIAS("devname:nvram");
--
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/
[RFC v3 20/24] powerpc: Adopt nvram module for PPC64
Adopt nvram module to reduce code duplication.
The IOC_NVRAM_GET_OFFSET ioctl as implemented on PPC64 validates the offset
returned by pmac_get_partition(). Add this test to the nvram module.
Note that the old PPC32 generic_nvram module lacked this test.
So when CONFIG_PPC32 && CONFIG_PPC_PMAC, the IOC_NVRAM_GET_OFFSET ioctl
would have returned 0 (always). But when CONFIG_PPC64 && CONFIG_PPC_PMAC,
the IOC_NVRAM_GET_OFFSET ioctl would have returned -1 (which is -EPERM)
when the requested partition was not found.
With this patch, the result is now -EINVAL on both PPC32 and PPC64 when
the requested PowerMac NVRAM partition is not found.
This is a userspace-visible change, in the non-existent partition case,
which would be in an error path for an IOC_NVRAM_GET_OFFSET ioctl syscall.
Signed-off-by: Finn Thain
---
BTW, the IOC_NVRAM_SYNC ioctl call returns -EINVAL on PPC64. This patch
retains this behaviour though it might be better to actually perform a sync.
Both PPC64 and PPC32 kernels implement ppc_md.nvram_sync() for Core99,
but on PPC64 the ioctl is unimplemented (unlike PPC32).
---
Changed since v1:
- The -ENOENT that appeared in v1 was changed to -EINVAL, to be
consistent with existing logic, that is,
if (part < pmac_nvram_OF || part > pmac_nvram_NR)
return -EINVAL;
---
arch/powerpc/Kconfig |3
arch/powerpc/kernel/nvram_64.c | 203 ---
arch/powerpc/platforms/powermac/Makefile |5
arch/powerpc/platforms/powermac/setup.c |2
drivers/char/nvram.c |2
5 files changed, 36 insertions(+), 179 deletions(-)
Index: linux/arch/powerpc/Kconfig
===
--- linux.orig/arch/powerpc/Kconfig 2015-06-28 11:41:49.0 +1000
+++ linux/arch/powerpc/Kconfig 2015-06-28 11:41:52.0 +1000
@@ -177,10 +177,9 @@ config SYSVIPC_COMPAT
depends on COMPAT && SYSVIPC
default y
-# All PPC32s use generic nvram driver through ppc_md
config HAVE_ARCH_NVRAM_OPS
bool
- default y if PPC32
+ default y
config SCHED_OMIT_FRAME_POINTER
bool
Index: linux/arch/powerpc/kernel/nvram_64.c
===
--- linux.orig/arch/powerpc/kernel/nvram_64.c 2015-06-28 11:41:27.0
+1000
+++ linux/arch/powerpc/kernel/nvram_64.c2015-06-28 11:41:52.0
+1000
@@ -7,12 +7,6 @@
* 2 of the License, or (at your option) any later version.
*
* /dev/nvram driver for PPC64
- *
- * This perhaps should live in drivers/char
- *
- * TODO: Split the /dev/nvram part (that one can use
- * drivers/char/generic_nvram.c) from the arch & partition
- * parsing code.
*/
#include
@@ -731,153 +725,6 @@ static void oops_to_nvram(struct kmsg_du
spin_unlock_irqrestore(&lock, flags);
}
-static loff_t dev_nvram_llseek(struct file *file, loff_t offset, int origin)
-{
- int size;
-
- if (ppc_md.nvram_size == NULL)
- return -ENODEV;
- size = ppc_md.nvram_size();
-
- switch (origin) {
- case 1:
- offset += file->f_pos;
- break;
- case 2:
- offset += size;
- break;
- }
- if (offset < 0)
- return -EINVAL;
- file->f_pos = offset;
- return file->f_pos;
-}
-
-
-static ssize_t dev_nvram_read(struct file *file, char __user *buf,
- size_t count, loff_t *ppos)
-{
- ssize_t ret;
- char *tmp = NULL;
- ssize_t size;
-
- if (!ppc_md.nvram_size) {
- ret = -ENODEV;
- goto out;
- }
-
- size = ppc_md.nvram_size();
- if (size < 0) {
- ret = size;
- goto out;
- }
-
- if (*ppos >= size) {
- ret = 0;
- goto out;
- }
-
- count = min_t(size_t, count, size - *ppos);
- count = min(count, PAGE_SIZE);
-
- tmp = kmalloc(count, GFP_KERNEL);
- if (!tmp) {
- ret = -ENOMEM;
- goto out;
- }
-
- ret = ppc_md.nvram_read(tmp, count, ppos);
- if (ret <= 0)
- goto out;
-
- if (copy_to_user(buf, tmp, ret))
- ret = -EFAULT;
-
-out:
- kfree(tmp);
- return ret;
-
-}
-
-static ssize_t dev_nvram_write(struct file *file, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- ssize_t ret;
- char *tmp = NULL;
- ssize_t size;
-
- ret = -ENODEV;
- if (!ppc_md.nvram_size)
- goto out;
-
- ret = 0;
- size = ppc_md.nvram_size();
- if (*ppos >= size || size < 0)
- goto out;
-
- count = min_t(size_t, count, size - *ppos);
- count = min(count, PAGE_SIZE);
-
- ret = -ENOMEM;
- tmp = kmalloc(count, GFP_KERNEL);
- if (!tmp)
-
[RFC v3 18/24] powerpc: Remove CONFIG_GENERIC_NVRAM and adopt CONFIG_HAVE_ARCH_NVRAM_OPS
Switch PPC32 kernels from the generic_nvram module to the nvram module.
Also fix a theoretical bug where CHRP omits the chrp_nvram_init()
call when CONFIG_NVRAM_MODULE=m.
As before, when CONFIG_PPC && !CONFIG_PPC_PMAC, the IOC_NVRAM_GET_OFFSET
ioctl is unimplemented. For the nvram module, unimplemented ioctls return
-ENOTTY. Whereas, for the superseded generic_nvram module they would
return -EINVAL.
Signed-off-by: Finn Thain
---
This ioctl change is visible to userspace code but only in an error path.
I didn't find any userspace code that uses the IOC_NVRAM_GET_OFFSET ioctl.
The change in the name of the module is also visible. The module that
implements /dev/nvram on PowerPC now has suitable aliases, i.e.
MODULE_ALIAS_MISCDEV(NVRAM_MINOR);
MODULE_ALIAS("devname:nvram");
so that the device special file can be automatically created and the
module automatically loaded when needed. Previously this was not the case.
---
Changes since v1:
- Small indentation fix.
---
arch/powerpc/Kconfig|2 +-
arch/powerpc/kernel/setup_32.c |2 +-
arch/powerpc/platforms/chrp/Makefile|2 +-
arch/powerpc/platforms/chrp/setup.c |2 +-
arch/powerpc/platforms/powermac/setup.c |3 +--
drivers/char/Kconfig| 10 ++
6 files changed, 11 insertions(+), 10 deletions(-)
Index: linux/arch/powerpc/Kconfig
===
--- linux.orig/arch/powerpc/Kconfig 2015-06-28 11:41:27.0 +1000
+++ linux/arch/powerpc/Kconfig 2015-06-28 11:41:49.0 +1000
@@ -178,7 +178,7 @@ config SYSVIPC_COMPAT
default y
# All PPC32s use generic nvram driver through ppc_md
-config GENERIC_NVRAM
+config HAVE_ARCH_NVRAM_OPS
bool
default y if PPC32
Index: linux/arch/powerpc/kernel/setup_32.c
===
--- linux.orig/arch/powerpc/kernel/setup_32.c 2015-06-28 11:41:46.0
+1000
+++ linux/arch/powerpc/kernel/setup_32.c2015-06-28 11:41:49.0
+1000
@@ -168,7 +168,7 @@ int __init ppc_setup_l3cr(char *str)
}
__setup("l3cr=", ppc_setup_l3cr);
-#ifdef CONFIG_GENERIC_NVRAM
+#if IS_ENABLED(CONFIG_NVRAM)
static unsigned char ppc_nvram_read_byte(int addr)
{
Index: linux/arch/powerpc/platforms/chrp/Makefile
===
--- linux.orig/arch/powerpc/platforms/chrp/Makefile 2015-06-28
11:41:27.0 +1000
+++ linux/arch/powerpc/platforms/chrp/Makefile 2015-06-28 11:41:49.0
+1000
@@ -1,3 +1,3 @@
obj-y += setup.o time.o pegasos_eth.o pci.o
obj-$(CONFIG_SMP) += smp.o
-obj-$(CONFIG_NVRAM)+= nvram.o
+obj-$(CONFIG_NVRAM:m=y)+= nvram.o
Index: linux/arch/powerpc/platforms/chrp/setup.c
===
--- linux.orig/arch/powerpc/platforms/chrp/setup.c 2015-06-28
11:41:27.0 +1000
+++ linux/arch/powerpc/platforms/chrp/setup.c 2015-06-28 11:41:49.0
+1000
@@ -557,7 +557,7 @@ void __init chrp_init_IRQ(void)
void __init
chrp_init2(void)
{
-#ifdef CONFIG_NVRAM
+#if IS_ENABLED(CONFIG_NVRAM)
chrp_nvram_init();
#endif
Index: linux/arch/powerpc/platforms/powermac/setup.c
===
--- linux.orig/arch/powerpc/platforms/powermac/setup.c 2015-06-28
11:41:27.0 +1000
+++ linux/arch/powerpc/platforms/powermac/setup.c 2015-06-28
11:41:49.0 +1000
@@ -321,8 +321,7 @@ static void __init pmac_setup_arch(void)
find_via_pmu();
smu_init();
-#if defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE) || \
-defined(CONFIG_PPC64)
+#if IS_ENABLED(CONFIG_NVRAM) || defined(CONFIG_PPC64)
pmac_nvram_init();
#endif
Index: linux/drivers/char/Kconfig
===
--- linux.orig/drivers/char/Kconfig 2015-06-28 11:41:39.0 +1000
+++ linux/drivers/char/Kconfig 2015-06-28 11:41:49.0 +1000
@@ -247,7 +247,7 @@ source "drivers/char/hw_random/Kconfig"
config NVRAM
tristate "/dev/nvram support"
- depends on X86 || (ARM && RTC_DRV_CMOS) || GENERIC_NVRAM ||
HAVE_ARCH_NVRAM_OPS
+ depends on X86 || (ARM && RTC_DRV_CMOS) || HAVE_ARCH_NVRAM_OPS
---help---
If you say Y here and create a character special file /dev/nvram
with major number 10 and minor number 144 using mknod ("man mknod"),
@@ -256,9 +256,11 @@ config NVRAM
and most Ataris. The actual number of bytes varies, depending on the
nvram in the system, but is usually 114 (128-14 for the RTC).
- This memory is conventionally called "CMOS RAM" on PCs and "NVRAM"
- on Ataris. /dev/nvram may be used to view settings there, or to
- change them (with some utility). It could also be used to frequently
[RFC v3 17/24] nvram: Drop nvram_* symbol exports and prototypes
Drivers now use the arch_nvram_ops calls so remove the function exports and
prototypes. nvram_check_checksum() is unused so remove it.
Signed-off-by: Finn Thain
---
arch/m68k/atari/nvram.c |6 +++---
drivers/char/nvram.c| 27 +--
include/linux/nvram.h |8
3 files changed, 8 insertions(+), 33 deletions(-)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/drivers/char/nvram.c 2015-06-28 11:41:44.0 +1000
+++ linux/drivers/char/nvram.c 2015-06-28 11:41:48.0 +1000
@@ -82,13 +82,12 @@ static ssize_t nvram_size;
* periodic 11 min sync from kernel/time/ntp.c vs. this driver.)
*/
-unsigned char __nvram_read_byte(int i)
+static unsigned char __nvram_read_byte(int i)
{
return CMOS_READ(NVRAM_FIRST_BYTE + i);
}
-EXPORT_SYMBOL(__nvram_read_byte);
-unsigned char nvram_read_byte(int i)
+static unsigned char nvram_read_byte(int i)
{
unsigned long flags;
unsigned char c;
@@ -98,16 +97,14 @@ unsigned char nvram_read_byte(int i)
spin_unlock_irqrestore(&rtc_lock, flags);
return c;
}
-EXPORT_SYMBOL(nvram_read_byte);
/* This races nicely with trying to read with checksum checking (nvram_read) */
-void __nvram_write_byte(unsigned char c, int i)
+static void __nvram_write_byte(unsigned char c, int i)
{
CMOS_WRITE(c, NVRAM_FIRST_BYTE + i);
}
-EXPORT_SYMBOL(__nvram_write_byte);
-void nvram_write_byte(unsigned char c, int i)
+static void nvram_write_byte(unsigned char c, int i)
{
unsigned long flags;
@@ -115,14 +112,13 @@ void nvram_write_byte(unsigned char c, i
__nvram_write_byte(c, i);
spin_unlock_irqrestore(&rtc_lock, flags);
}
-EXPORT_SYMBOL(nvram_write_byte);
/* On PCs, the checksum is built only over bytes 2..31 */
#define PC_CKS_RANGE_START 2
#define PC_CKS_RANGE_END 31
#define PC_CKS_LOC 32
-int __nvram_check_checksum(void)
+static int __nvram_check_checksum(void)
{
int i;
unsigned short sum = 0;
@@ -134,19 +130,6 @@ int __nvram_check_checksum(void)
__nvram_read_byte(PC_CKS_LOC+1);
return (sum & 0x) == expect;
}
-EXPORT_SYMBOL(__nvram_check_checksum);
-
-int nvram_check_checksum(void)
-{
- unsigned long flags;
- int rv;
-
- spin_lock_irqsave(&rtc_lock, flags);
- rv = __nvram_check_checksum();
- spin_unlock_irqrestore(&rtc_lock, flags);
- return rv;
-}
-EXPORT_SYMBOL(nvram_check_checksum);
static void __nvram_set_checksum(void)
{
Index: linux/include/linux/nvram.h
===
--- linux.orig/include/linux/nvram.h2015-06-28 11:41:44.0 +1000
+++ linux/include/linux/nvram.h 2015-06-28 11:41:48.0 +1000
@@ -3,14 +3,6 @@
#include
-/* __foo is foo without grabbing the rtc_lock - get it yourself */
-extern unsigned char __nvram_read_byte(int i);
-extern unsigned char nvram_read_byte(int i);
-extern void __nvram_write_byte(unsigned char c, int i);
-extern void nvram_write_byte(unsigned char c, int i);
-extern int __nvram_check_checksum(void);
-extern int nvram_check_checksum(void);
-
struct nvram_ops {
ssize_t (*read)(char *, size_t, loff_t *);
ssize_t (*write)(char *, size_t, loff_t *);
Index: linux/arch/m68k/atari/nvram.c
===
--- linux.orig/arch/m68k/atari/nvram.c 2015-06-28 11:41:39.0 +1000
+++ linux/arch/m68k/atari/nvram.c 2015-06-28 11:41:48.0 +1000
@@ -33,13 +33,13 @@
* periodic 11 min sync from kernel/time/ntp.c vs. this driver.)
*/
-unsigned char __nvram_read_byte(int i)
+static unsigned char __nvram_read_byte(int i)
{
return CMOS_READ(NVRAM_FIRST_BYTE + i);
}
/* This races nicely with trying to read with checksum checking */
-void __nvram_write_byte(unsigned char c, int i)
+static void __nvram_write_byte(unsigned char c, int i)
{
CMOS_WRITE(c, NVRAM_FIRST_BYTE + i);
}
@@ -51,7 +51,7 @@ void __nvram_write_byte(unsigned char c,
#define ATARI_CKS_RANGE_END47
#define ATARI_CKS_LOC 48
-int __nvram_check_checksum(void)
+static int __nvram_check_checksum(void)
{
int i;
unsigned char sum = 0;
--
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/
[RFC v3 16/24] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()
Make use of arch_nvram_ops in device drivers so that the nvram_*
function exports can be removed.
Since they are no longer global symbols, rename the PPC32 nvram_* functions
appropriately.
Add the missing CONFIG_NVRAM test to imsttfb to avoid a build failure.
Signed-off-by: Finn Thain
---
arch/powerpc/kernel/setup_32.c |8
drivers/char/generic_nvram.c |4 ++--
drivers/video/fbdev/controlfb.c|4 ++--
drivers/video/fbdev/imsttfb.c |7 +++
drivers/video/fbdev/matrox/matroxfb_base.c |2 +-
drivers/video/fbdev/platinumfb.c |4 ++--
drivers/video/fbdev/valkyriefb.c |4 ++--
7 files changed, 16 insertions(+), 17 deletions(-)
Index: linux/arch/powerpc/kernel/setup_32.c
===
--- linux.orig/arch/powerpc/kernel/setup_32.c 2015-06-28 11:41:44.0
+1000
+++ linux/arch/powerpc/kernel/setup_32.c2015-06-28 11:41:46.0
+1000
@@ -170,20 +170,18 @@ __setup("l3cr=", ppc_setup_l3cr);
#ifdef CONFIG_GENERIC_NVRAM
-unsigned char nvram_read_byte(int addr)
+static unsigned char ppc_nvram_read_byte(int addr)
{
if (ppc_md.nvram_read_val)
return ppc_md.nvram_read_val(addr);
return 0xff;
}
-EXPORT_SYMBOL(nvram_read_byte);
-void nvram_write_byte(unsigned char val, int addr)
+static void ppc_nvram_write_byte(unsigned char val, int addr)
{
if (ppc_md.nvram_write_val)
ppc_md.nvram_write_val(addr, val);
}
-EXPORT_SYMBOL(nvram_write_byte);
static ssize_t ppc_nvram_get_size(void)
{
@@ -200,6 +198,8 @@ static long ppc_nvram_sync(void)
}
const struct nvram_ops arch_nvram_ops = {
+ .read_byte = ppc_nvram_read_byte,
+ .write_byte = ppc_nvram_write_byte,
.get_size = ppc_nvram_get_size,
.sync = ppc_nvram_sync,
};
Index: linux/drivers/char/generic_nvram.c
===
--- linux.orig/drivers/char/generic_nvram.c 2015-06-28 11:41:44.0
+1000
+++ linux/drivers/char/generic_nvram.c 2015-06-28 11:41:46.0 +1000
@@ -64,7 +64,7 @@ static ssize_t read_nvram(struct file *f
if (*ppos >= nvram_len)
return 0;
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count)
- if (__put_user(nvram_read_byte(i), p))
+ if (__put_user(arch_nvram_ops.read_byte(i), p))
return -EFAULT;
*ppos = i;
return p - buf;
@@ -84,7 +84,7 @@ static ssize_t write_nvram(struct file *
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count) {
if (__get_user(c, p))
return -EFAULT;
- nvram_write_byte(c, i);
+ arch_nvram_ops.write_byte(c, i);
}
*ppos = i;
return p - buf;
Index: linux/drivers/video/fbdev/controlfb.c
===
--- linux.orig/drivers/video/fbdev/controlfb.c 2015-06-28 11:41:27.0
+1000
+++ linux/drivers/video/fbdev/controlfb.c 2015-06-28 11:41:46.0
+1000
@@ -415,7 +415,7 @@ static int __init init_control(struct fb
/* Try to pick a video mode out of NVRAM if we have one. */
#ifdef CONFIG_NVRAM
if (default_cmode == CMODE_NVRAM) {
- cmode = nvram_read_byte(NV_CMODE);
+ cmode = arch_nvram_ops.read_byte(NV_CMODE);
if(cmode < CMODE_8 || cmode > CMODE_32)
cmode = CMODE_8;
} else
@@ -423,7 +423,7 @@ static int __init init_control(struct fb
cmode=default_cmode;
#ifdef CONFIG_NVRAM
if (default_vmode == VMODE_NVRAM) {
- vmode = nvram_read_byte(NV_VMODE);
+ vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (vmode < 1 || vmode > VMODE_MAX ||
control_mac_modes[vmode - 1].m[full] < cmode) {
sense = read_control_sense(p);
Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
===
--- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-06-28
11:41:41.0 +1000
+++ linux/drivers/video/fbdev/matrox/matroxfb_base.c2015-06-28
11:41:46.0 +1000
@@ -1888,7 +1888,7 @@ static int initMatrox2(struct matrox_fb_
default_vmode = VMODE_640_480_60;
#ifdef CONFIG_NVRAM
if (default_cmode == CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
default_cmode = CMODE_8;
Index: linux/drivers/video/fbdev/platinumfb.c
===
---
[RFC v3 13/24] powerpc: Add missing ppc_md.nvram_size for CHRP and PowerMac
Add the nvram_size() function to those PowerPC platforms that don't already
have one: CHRP and PowerMac. This means that the ppc_md.nvram_size()
function can be used to implement arch_nvram_ops.get_size()
Since we are addressing inconsistencies here, also rename chrp_nvram_read
and chrp_nvram_write, which break the naming convention used across
PowerPC platforms for NVRAM accessor functions.
Signed-off-by: Finn Thain
---
arch/powerpc/platforms/chrp/nvram.c | 14 ++
arch/powerpc/platforms/powermac/nvram.c |9 +
2 files changed, 19 insertions(+), 4 deletions(-)
Index: linux/arch/powerpc/platforms/chrp/nvram.c
===
--- linux.orig/arch/powerpc/platforms/chrp/nvram.c 2015-06-28
11:41:27.0 +1000
+++ linux/arch/powerpc/platforms/chrp/nvram.c 2015-06-28 11:41:42.0
+1000
@@ -23,7 +23,7 @@ static unsigned int nvram_size;
static unsigned char nvram_buf[4];
static DEFINE_SPINLOCK(nvram_lock);
-static unsigned char chrp_nvram_read(int addr)
+static unsigned char chrp_nvram_read_byte(int addr)
{
unsigned int done;
unsigned long flags;
@@ -45,7 +45,7 @@ static unsigned char chrp_nvram_read(int
return ret;
}
-static void chrp_nvram_write(int addr, unsigned char val)
+static void chrp_nvram_write_byte(int addr, unsigned char val)
{
unsigned int done;
unsigned long flags;
@@ -63,6 +63,11 @@ static void chrp_nvram_write(int addr, u
spin_unlock_irqrestore(&nvram_lock, flags);
}
+static ssize_t chrp_nvram_size(void)
+{
+ return nvram_size;
+}
+
void __init chrp_nvram_init(void)
{
struct device_node *nvram;
@@ -84,8 +89,9 @@ void __init chrp_nvram_init(void)
printk(KERN_INFO "CHRP nvram contains %u bytes\n", nvram_size);
of_node_put(nvram);
- ppc_md.nvram_read_val = chrp_nvram_read;
- ppc_md.nvram_write_val = chrp_nvram_write;
+ ppc_md.nvram_read_val = chrp_nvram_read_byte;
+ ppc_md.nvram_write_val = chrp_nvram_write_byte;
+ ppc_md.nvram_size = chrp_nvram_size;
return;
}
Index: linux/arch/powerpc/platforms/powermac/nvram.c
===
--- linux.orig/arch/powerpc/platforms/powermac/nvram.c 2015-06-28
11:41:27.0 +1000
+++ linux/arch/powerpc/platforms/powermac/nvram.c 2015-06-28
11:41:42.0 +1000
@@ -147,6 +147,11 @@ static ssize_t core99_nvram_size(void)
static volatile unsigned char __iomem *nvram_addr;
static int nvram_mult;
+static ssize_t ppc32_nvram_size(void)
+{
+ return NVRAM_SIZE;
+}
+
static unsigned char direct_nvram_read_byte(int addr)
{
return in_8(&nvram_data[(addr & (NVRAM_SIZE - 1)) * nvram_mult]);
@@ -590,21 +595,25 @@ int __init pmac_nvram_init(void)
nvram_mult = 1;
ppc_md.nvram_read_val = direct_nvram_read_byte;
ppc_md.nvram_write_val = direct_nvram_write_byte;
+ ppc_md.nvram_size = ppc32_nvram_size;
} else if (nvram_naddrs == 1) {
nvram_data = ioremap(r1.start, s1);
nvram_mult = (s1 + NVRAM_SIZE - 1) / NVRAM_SIZE;
ppc_md.nvram_read_val = direct_nvram_read_byte;
ppc_md.nvram_write_val = direct_nvram_write_byte;
+ ppc_md.nvram_size = ppc32_nvram_size;
} else if (nvram_naddrs == 2) {
nvram_addr = ioremap(r1.start, s1);
nvram_data = ioremap(r2.start, s2);
ppc_md.nvram_read_val = indirect_nvram_read_byte;
ppc_md.nvram_write_val = indirect_nvram_write_byte;
+ ppc_md.nvram_size = ppc32_nvram_size;
} else if (nvram_naddrs == 0 && sys_ctrler == SYS_CTRLER_PMU) {
#ifdef CONFIG_ADB_PMU
nvram_naddrs = -1;
ppc_md.nvram_read_val = pmu_nvram_read_byte;
ppc_md.nvram_write_val = pmu_nvram_write_byte;
+ ppc_md.nvram_size = ppc32_nvram_size;
#endif /* CONFIG_ADB_PMU */
} else {
printk(KERN_ERR "Incompatible type of NVRAM\n");
--
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/
[RFC v3 14/24] powerpc: Implement arch_nvram_ops.get_size() and remove old nvram_* exports
Implement arch_nvram_ops for PPC32 and make use of it in the generic_nvram
misc device module so that the nvram_* function exports can be removed.
Signed-off-by: Finn Thain
---
arch/powerpc/include/asm/nvram.h |3 ---
arch/powerpc/kernel/setup_32.c | 10 +++---
drivers/char/generic_nvram.c | 24
3 files changed, 19 insertions(+), 18 deletions(-)
Index: linux/arch/powerpc/include/asm/nvram.h
===
--- linux.orig/arch/powerpc/include/asm/nvram.h 2015-06-28 11:41:41.0
+1000
+++ linux/arch/powerpc/include/asm/nvram.h 2015-06-28 11:41:43.0
+1000
@@ -98,7 +98,4 @@ extern int nvram_write_os_partition(stru
unsigned int err_type,
unsigned int error_log_cnt);
-/* Determine NVRAM size */
-extern ssize_t nvram_get_size(void);
-
#endif /* _ASM_POWERPC_NVRAM_H */
Index: linux/arch/powerpc/kernel/setup_32.c
===
--- linux.orig/arch/powerpc/kernel/setup_32.c 2015-06-28 11:41:41.0
+1000
+++ linux/arch/powerpc/kernel/setup_32.c2015-06-28 11:41:43.0
+1000
@@ -186,13 +186,12 @@ void nvram_write_byte(unsigned char val,
}
EXPORT_SYMBOL(nvram_write_byte);
-ssize_t nvram_get_size(void)
+static ssize_t ppc_nvram_get_size(void)
{
if (ppc_md.nvram_size)
return ppc_md.nvram_size();
- return -1;
+ return -ENODEV;
}
-EXPORT_SYMBOL(nvram_get_size);
void nvram_sync(void)
{
@@ -201,6 +200,11 @@ void nvram_sync(void)
}
EXPORT_SYMBOL(nvram_sync);
+const struct nvram_ops arch_nvram_ops = {
+ .get_size = ppc_nvram_get_size,
+};
+EXPORT_SYMBOL(arch_nvram_ops);
+
#endif /* CONFIG_NVRAM */
int __init ppc_init(void)
Index: linux/drivers/char/generic_nvram.c
===
--- linux.orig/drivers/char/generic_nvram.c 2015-06-28 11:41:41.0
+1000
+++ linux/drivers/char/generic_nvram.c 2015-06-28 11:41:43.0 +1000
@@ -28,8 +28,6 @@
#include
#endif
-#define NVRAM_SIZE 8192
-
static DEFINE_MUTEX(nvram_mutex);
static ssize_t nvram_len;
@@ -150,20 +148,22 @@ static struct miscdevice nvram_dev = {
int __init nvram_init(void)
{
- int ret = 0;
+ int ret;
- printk(KERN_INFO "Generic non-volatile memory driver v%s\n",
- NVRAM_VERSION);
- ret = misc_register(&nvram_dev);
- if (ret != 0)
- goto out;
+ if (arch_nvram_ops.get_size == NULL)
+ return -ENODEV;
- nvram_len = nvram_get_size();
+ nvram_len = arch_nvram_ops.get_size();
if (nvram_len < 0)
- nvram_len = NVRAM_SIZE;
+ return nvram_len;
-out:
- return ret;
+ ret = misc_register(&nvram_dev);
+ if (ret)
+ return ret;
+
+ pr_info("Generic non-volatile memory driver v%s\n", NVRAM_VERSION);
+
+ return 0;
}
void __exit nvram_cleanup(void)
--
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/
[RFC v3 22/24] m68k/mac: Use macros for RTC accesses not magic numbers
Signed-off-by: Finn Thain
---
This is intended to improve code style and not affect code behaviour.
I've tested this on a Quadra 650.
I don't know the meanings of the 4 undocumented write protect register
bits 0x55, so I decided against defining 4 macros for those bits.
---
arch/m68k/mac/misc.c | 59 +++
1 file changed, 41 insertions(+), 18 deletions(-)
Index: linux/arch/m68k/mac/misc.c
===
--- linux.orig/arch/m68k/mac/misc.c 2015-06-28 11:41:53.0 +1000
+++ linux/arch/m68k/mac/misc.c 2015-06-28 11:41:54.0 +1000
@@ -242,6 +242,21 @@ static void via_rtc_send(__u8 data)
}
/*
+ * These values can be found in Inside Macintosh vol. III ch. 2
+ * which has a description of the RTC chip in the original Mac.
+ */
+
+#define RTC_FLG_READBIT(7)
+#define RTC_FLG_WRITE_PROTECT BIT(7)
+#define RTC_CMD_READ(r) (RTC_FLG_READ | (r << 2))
+#define RTC_CMD_WRITE(r)(r << 2)
+#define RTC_REG_SECONDS_0 0
+#define RTC_REG_SECONDS_1 1
+#define RTC_REG_SECONDS_2 2
+#define RTC_REG_SECONDS_3 3
+#define RTC_REG_WRITE_PROTECT 13
+
+/*
* Execute a VIA PRAM/RTC command. For read commands
* data should point to a one-byte buffer for the
* resulting data. For write commands it should point
@@ -250,13 +265,17 @@ static void via_rtc_send(__u8 data)
* This function disables all interrupts while running.
*/
-static void via_pram_command(int command, __u8 *data)
+static void via_rtc_command(int command, __u8 *data)
{
unsigned long flags;
int is_read;
local_irq_save(flags);
+ /* The least significant bits must be 0b01 according to Inside Mac */
+
+ command = (command & ~3) | 1;
+
/* Enable the RTC and make sure the strobe line is high */
via1[vBufB] = (via1[vBufB] | VIA1B_vRTCClk) & ~VIA1B_vRTCEnb;
@@ -264,10 +283,10 @@ static void via_pram_command(int command
if (command & 0xFF00) { /* extended (two-byte) command */
via_rtc_send((command & 0xFF00) >> 8);
via_rtc_send(command & 0xFF);
- is_read = command & 0x8000;
+ is_read = command & (RTC_FLG_READ << 8);
} else {/* one-byte command */
via_rtc_send(command);
- is_read = command & 0x80;
+ is_read = command & RTC_FLG_READ;
}
if (is_read) {
*data = via_rtc_recv();
@@ -306,10 +325,10 @@ static long via_read_time(void)
} result, last_result;
int count = 1;
- via_pram_command(0x81, &last_result.cdata[3]);
- via_pram_command(0x85, &last_result.cdata[2]);
- via_pram_command(0x89, &last_result.cdata[1]);
- via_pram_command(0x8D, &last_result.cdata[0]);
+ via_rtc_command(RTC_CMD_READ(RTC_REG_SECONDS_0), &last_result.cdata[3]);
+ via_rtc_command(RTC_CMD_READ(RTC_REG_SECONDS_1), &last_result.cdata[2]);
+ via_rtc_command(RTC_CMD_READ(RTC_REG_SECONDS_2), &last_result.cdata[1]);
+ via_rtc_command(RTC_CMD_READ(RTC_REG_SECONDS_3), &last_result.cdata[0]);
/*
* The NetBSD guys say to loop until you get the same reading
@@ -317,10 +336,14 @@ static long via_read_time(void)
*/
while (1) {
- via_pram_command(0x81, &result.cdata[3]);
- via_pram_command(0x85, &result.cdata[2]);
- via_pram_command(0x89, &result.cdata[1]);
- via_pram_command(0x8D, &result.cdata[0]);
+ via_rtc_command(RTC_CMD_READ(RTC_REG_SECONDS_0),
+ &result.cdata[3]);
+ via_rtc_command(RTC_CMD_READ(RTC_REG_SECONDS_1),
+ &result.cdata[2]);
+ via_rtc_command(RTC_CMD_READ(RTC_REG_SECONDS_2),
+ &result.cdata[1]);
+ via_rtc_command(RTC_CMD_READ(RTC_REG_SECONDS_3),
+ &result.cdata[0]);
if (result.idata == last_result.idata)
return result.idata - RTC_OFFSET;
@@ -356,18 +379,18 @@ static void via_write_time(long time)
/* Clear the write protect bit */
temp = 0x55;
- via_pram_command(0x35, &temp);
+ via_rtc_command(RTC_CMD_WRITE(RTC_REG_WRITE_PROTECT), &temp);
data.idata = time + RTC_OFFSET;
- via_pram_command(0x01, &data.cdata[3]);
- via_pram_command(0x05, &data.cdata[2]);
- via_pram_command(0x09, &data.cdata[1]);
- via_pram_command(0x0D, &data.cdata[0]);
+ via_rtc_command(RTC_CMD_WRITE(RTC_REG_SECONDS_0), &data.cdata[3]);
+ via_rtc_command(RTC_CMD_WRITE(RTC_REG_SECONDS_1), &data.cdata[2]);
+ via_rtc_command(RTC_CMD_WRITE(RTC_REG_SECONDS_2), &data.cdata[1]);
+ via_rtc_command(RTC_CMD_WRITE(RTC_REG_SECONDS_3), &data.cdata[0]);
/* Set the w
[RFC v3 19/24] char/generic_nvram: Remove as unused
And thus eliminate some twisted CONFIG_GENERIC_NVRAM logic.
Signed-off-by: Finn Thain
---
drivers/char/Makefile|6 -
drivers/char/generic_nvram.c | 176 ---
2 files changed, 1 insertion(+), 181 deletions(-)
Index: linux/drivers/char/Makefile
===
--- linux.orig/drivers/char/Makefile2015-06-28 11:41:27.0 +1000
+++ linux/drivers/char/Makefile 2015-06-28 11:41:51.0 +1000
@@ -30,11 +30,7 @@ obj-$(CONFIG_GEN_RTC)+= genrtc.o
obj-$(CONFIG_EFI_RTC) += efirtc.o
obj-$(CONFIG_DS1302) += ds1302.o
obj-$(CONFIG_XILINX_HWICAP)+= xilinx_hwicap/
-ifeq ($(CONFIG_GENERIC_NVRAM),y)
- obj-$(CONFIG_NVRAM) += generic_nvram.o
-else
- obj-$(CONFIG_NVRAM) += nvram.o
-endif
+obj-$(CONFIG_NVRAM)+= nvram.o
obj-$(CONFIG_TOSHIBA) += toshiba.o
obj-$(CONFIG_I8K) += i8k.o
obj-$(CONFIG_DS1620) += ds1620.o
Index: linux/drivers/char/generic_nvram.c
===
--- linux.orig/drivers/char/generic_nvram.c 2015-06-28 11:41:46.0
+1000
+++ /dev/null 1970-01-01 00:00:00.0 +
@@ -1,176 +0,0 @@
-/*
- * Generic /dev/nvram driver for architectures providing some
- * "generic" hooks, that is :
- *
- * nvram_read_byte, nvram_write_byte, nvram_sync, nvram_get_size
- *
- * Note that an additional hook is supported for PowerMac only
- * for getting the nvram "partition" informations
- *
- */
-
-#define NVRAM_VERSION "1.1"
-
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#ifdef CONFIG_PPC_PMAC
-#include
-#include
-#endif
-
-static DEFINE_MUTEX(nvram_mutex);
-static ssize_t nvram_len;
-
-static loff_t nvram_llseek(struct file *file, loff_t offset, int origin)
-{
- switch (origin) {
- case 0:
- break;
- case 1:
- offset += file->f_pos;
- break;
- case 2:
- offset += nvram_len;
- break;
- default:
- offset = -1;
- }
- if (offset < 0)
- return -EINVAL;
-
- file->f_pos = offset;
-
- return file->f_pos;
-}
-
-static ssize_t read_nvram(struct file *file, char __user *buf,
- size_t count, loff_t *ppos)
-{
- unsigned int i;
- char __user *p = buf;
-
- if (!access_ok(VERIFY_WRITE, buf, count))
- return -EFAULT;
- if (*ppos >= nvram_len)
- return 0;
- for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count)
- if (__put_user(arch_nvram_ops.read_byte(i), p))
- return -EFAULT;
- *ppos = i;
- return p - buf;
-}
-
-static ssize_t write_nvram(struct file *file, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- unsigned int i;
- const char __user *p = buf;
- char c;
-
- if (!access_ok(VERIFY_READ, buf, count))
- return -EFAULT;
- if (*ppos >= nvram_len)
- return 0;
- for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count) {
- if (__get_user(c, p))
- return -EFAULT;
- arch_nvram_ops.write_byte(c, i);
- }
- *ppos = i;
- return p - buf;
-}
-
-static int nvram_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
-{
- switch(cmd) {
-#ifdef CONFIG_PPC_PMAC
- case OBSOLETE_PMAC_NVRAM_GET_OFFSET:
- printk(KERN_WARNING "nvram: Using obsolete
PMAC_NVRAM_GET_OFFSET ioctl\n");
- case IOC_NVRAM_GET_OFFSET: {
- int part, offset;
-
- if (!machine_is(powermac))
- return -EINVAL;
- if (copy_from_user(&part, (void __user*)arg, sizeof(part)) != 0)
- return -EFAULT;
- if (part < pmac_nvram_OF || part > pmac_nvram_NR)
- return -EINVAL;
- offset = pmac_get_partition(part);
- if (copy_to_user((void __user*)arg, &offset, sizeof(offset)) !=
0)
- return -EFAULT;
- break;
- }
-#endif /* CONFIG_PPC_PMAC */
- case IOC_NVRAM_SYNC:
- arch_nvram_ops.sync();
- break;
- default:
- return -EINVAL;
- }
-
- return 0;
-}
-
-static long nvram_unlocked_ioctl(struct file *file, unsigned int cmd, unsigned
long arg)
-{
- int ret;
-
- mutex_lock(&nvram_mutex);
- ret = nvram_ioctl(file, cmd, arg);
- mutex_unlock(&nvram_mutex);
-
- return ret;
-}
-
-const struct file_operations nvram_fops = {
- .owner = THIS_MODULE,
- .llseek = nvram_llseek,
- .read = read_nvram,
- .write = write_nvram,
- .unlocked_i
[RFC v3 15/24] powerpc: Implement nvram sync ioctl
Add the powerpc-specific sync() method to struct nvram_ops and implement
the corresponding ioctl in the nvram module. This allows the nvram module
to replace the generic_nvram module.
Signed-off-by: Finn Thain
---
On PPC32, the IOC_NVRAM_SYNC ioctl call always returns 0, even for those
platforms that don't implement ppc_md.nvram_sync. This patch retains
that quirk. It might be better to return failure (which is what PPC64 does).
Changed since v1:
- Don't bother acquiring the mutex for unimplemented ioctls.
---
arch/powerpc/include/asm/nvram.h |3 ---
arch/powerpc/kernel/setup_32.c |6 +++---
drivers/char/generic_nvram.c |2 +-
drivers/char/nvram.c | 39 +++
include/linux/nvram.h|4
5 files changed, 47 insertions(+), 7 deletions(-)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/drivers/char/nvram.c 2015-06-28 11:41:40.0 +1000
+++ linux/drivers/char/nvram.c 2015-06-28 11:41:44.0 +1000
@@ -48,6 +48,11 @@
#include
+#ifdef CONFIG_PPC
+#include
+#include
+#endif
+
static DEFINE_MUTEX(nvram_mutex);
static DEFINE_SPINLOCK(nvram_state_lock);
static int nvram_open_cnt; /* #times opened */
@@ -338,6 +343,37 @@ static long nvram_misc_ioctl(struct file
long ret = -ENOTTY;
switch (cmd) {
+#ifdef CONFIG_PPC
+#ifdef CONFIG_PPC_PMAC
+ case OBSOLETE_PMAC_NVRAM_GET_OFFSET:
+ pr_warn("nvram: Using obsolete PMAC_NVRAM_GET_OFFSET ioctl\n");
+ /* fall through */
+ case IOC_NVRAM_GET_OFFSET: {
+ int part, offset;
+
+ if (!machine_is(powermac))
+ return -EINVAL;
+ if (copy_from_user(&part,
+ (void __user *)arg, sizeof(part)) != 0)
+ return -EFAULT;
+ if (part < pmac_nvram_OF || part > pmac_nvram_NR)
+ return -EINVAL;
+ offset = pmac_get_partition(part);
+ if (copy_to_user((void __user *)arg,
+&offset, sizeof(offset)) != 0)
+ return -EFAULT;
+ ret = 0;
+ break;
+ }
+#endif
+ case IOC_NVRAM_SYNC:
+ if (arch_nvram_ops.sync != NULL) {
+ mutex_lock(&nvram_mutex);
+ ret = arch_nvram_ops.sync();
+ mutex_unlock(&nvram_mutex);
+ }
+ break;
+#else /* !CONFIG_PPC */
case NVRAM_INIT:
/* initialize NVRAM contents and checksum */
if (!capable(CAP_SYS_ADMIN))
@@ -361,6 +397,7 @@ static long nvram_misc_ioctl(struct file
mutex_unlock(&nvram_mutex);
}
break;
+#endif /* CONFIG_PPC */
}
return ret;
}
@@ -376,6 +413,7 @@ static int nvram_misc_open(struct inode
return -EBUSY;
}
+#ifndef CONFIG_PPC
/* Prevent multiple writers if the set_checksum ioctl is implemented. */
if ((arch_nvram_ops.set_checksum != NULL) &&
(file->f_mode & FMODE_WRITE) &&
@@ -383,6 +421,7 @@ static int nvram_misc_open(struct inode
spin_unlock(&nvram_state_lock);
return -EBUSY;
}
+#endif
if (file->f_flags & O_EXCL)
nvram_open_mode |= NVRAM_EXCL;
Index: linux/include/linux/nvram.h
===
--- linux.orig/include/linux/nvram.h2015-06-28 11:41:36.0 +1000
+++ linux/include/linux/nvram.h 2015-06-28 11:41:44.0 +1000
@@ -17,8 +17,12 @@ struct nvram_ops {
unsigned char (*read_byte)(int);
void(*write_byte)(unsigned char, int);
ssize_t (*get_size)(void);
+#ifdef CONFIG_PPC
+ long(*sync)(void);
+#else
long(*set_checksum)(void);
long(*initialize)(void);
+#endif
};
extern const struct nvram_ops arch_nvram_ops;
Index: linux/arch/powerpc/include/asm/nvram.h
===
--- linux.orig/arch/powerpc/include/asm/nvram.h 2015-06-28 11:41:43.0
+1000
+++ linux/arch/powerpc/include/asm/nvram.h 2015-06-28 11:41:44.0
+1000
@@ -78,9 +78,6 @@ extern intpmac_get_partition(int partit
extern u8 pmac_xpram_read(int xpaddr);
extern voidpmac_xpram_write(int xpaddr, u8 data);
-/* Synchronize NVRAM */
-extern voidnvram_sync(void);
-
/* Initialize NVRAM OS partition */
extern int __init nvram_init_os_partition(struct nvram_os_partition *part);
Index: linux/arch/powerpc/kernel/setup_32.c
===
--- linux.orig/arch/powerpc/kernel/setup_32.c 2015-06-28 11:41:43.0
+1000
+++ linux/arch/powerpc/kernel/se
[RFC v3 24/24] m68k: Dispatch nvram_ops calls to Atari or Mac functions
A multi-platform kernel binary needs to decide at run-time how to dispatch
the arch_nvram_ops calls. Add platform-independent arch_nvram_ops, for use
when multiple platform-specific NVRAM ops implementations are needed.
Enable CONFIG_HAVE_ARCH_NVRAM_OPS for Macs.
Signed-off-by: Finn Thain
---
Changed since v1:
- Removed Mac and Atari ops struct definitions and the associated #ifdefs.
- Moved extern declarations for fewer lines of code and better readability.
- The IS_ENABLED(CONFIG_NVRAM) tests were moved to this patch, because it is
now in this patch that CONFIG_HAVE_ARCH_NVRAM_OPS is enabled for Macs.
---
arch/m68k/Kconfig |2
arch/m68k/atari/nvram.c | 21 ++--
arch/m68k/kernel/setup_mm.c | 107
arch/m68k/mac/misc.c| 18 +++
4 files changed, 131 insertions(+), 17 deletions(-)
Index: linux/arch/m68k/mac/misc.c
===
--- linux.orig/arch/m68k/mac/misc.c 2015-06-28 11:41:55.0 +1000
+++ linux/arch/m68k/mac/misc.c 2015-06-28 11:41:56.0 +1000
@@ -61,6 +61,7 @@ static void cuda_write_time(long data)
cuda_poll();
}
+#if IS_ENABLED(CONFIG_NVRAM)
static unsigned char cuda_pram_read_byte(int offset)
{
struct adb_request req;
@@ -81,6 +82,8 @@ static void cuda_pram_write_byte(unsigne
while (!req.complete)
cuda_poll();
}
+#endif /* CONFIG_NVRAM */
+
#else
#define cuda_read_time() 0
#define cuda_write_time(n)
@@ -116,6 +119,7 @@ static void pmu_write_time(long data)
pmu_poll();
}
+#if IS_ENABLED(CONFIG_NVRAM)
static unsigned char pmu_pram_read_byte(int offset)
{
struct adb_request req;
@@ -139,6 +143,8 @@ static void pmu_pram_write_byte(unsigned
while (!req.complete)
pmu_poll();
}
+#endif /* CONFIG_NVRAM */
+
#else
#define pmu_read_time() 0
#define pmu_write_time(n)
@@ -172,6 +178,7 @@ static void maciisi_write_time(long data
(data >> 8) & 0xFF, data & 0xFF);
}
+#if IS_ENABLED(CONFIG_NVRAM)
static unsigned char maciisi_pram_read_byte(int offset)
{
struct adb_request req;
@@ -187,6 +194,8 @@ static void maciisi_pram_write_byte(unsi
maciisi_request(&req, NULL, 5, CUDA_PACKET, CUDA_SET_PRAM,
(offset >> 8) & 0xFF, offset & 0xFF, data);
}
+#endif /* CONFIG_NVRAM */
+
#else
#define maciisi_read_time() 0
#define maciisi_write_time(n)
@@ -314,6 +323,7 @@ static void via_rtc_command(int command,
local_irq_restore(flags);
}
+#if IS_ENABLED(CONFIG_NVRAM)
static unsigned char via_pram_read_byte(int offset)
{
unsigned char temp;
@@ -336,6 +346,7 @@ static void via_pram_write_byte(unsigned
temp = 0x55 | RTC_FLG_WRITE_PROTECT;
via_rtc_command(RTC_CMD_WRITE(RTC_REG_WRITE_PROTECT), &temp);
}
+#endif /* CONFIG_NVRAM */
/*
* Return the current time in seconds since January 1, 1904.
@@ -503,6 +514,7 @@ void pmu_shutdown(void)
*---
*/
+#if IS_ENABLED(CONFIG_NVRAM)
unsigned char mac_pram_read_byte(int addr)
{
unsigned char (*func)(int);
@@ -550,6 +562,12 @@ void mac_pram_write_byte(unsigned char v
(*func)(val, addr);
}
+ssize_t mac_pram_get_size(void)
+{
+ return 256;
+}
+#endif /* CONFIG_NVRAM */
+
void mac_poweroff(void)
{
/*
Index: linux/arch/m68k/atari/nvram.c
===
--- linux.orig/arch/m68k/atari/nvram.c 2015-06-28 11:41:48.0 +1000
+++ linux/arch/m68k/atari/nvram.c 2015-06-28 11:41:56.0 +1000
@@ -73,7 +73,7 @@ static void __nvram_set_checksum(void)
__nvram_write_byte(sum, ATARI_CKS_LOC + 1);
}
-static long nvram_set_checksum(void)
+long atari_nvram_set_checksum(void)
{
spin_lock_irq(&rtc_lock);
__nvram_set_checksum();
@@ -81,7 +81,7 @@ static long nvram_set_checksum(void)
return 0;
}
-static long nvram_initialize(void)
+long atari_nvram_initialize(void)
{
loff_t i;
@@ -93,7 +93,7 @@ static long nvram_initialize(void)
return 0;
}
-static ssize_t nvram_read(char *buf, size_t count, loff_t *ppos)
+ssize_t atari_nvram_read(char *buf, size_t count, loff_t *ppos)
{
char *p = buf;
loff_t i;
@@ -114,7 +114,7 @@ static ssize_t nvram_read(char *buf, siz
return p - buf;
}
-static ssize_t nvram_write(char *buf, size_t count, loff_t *ppos)
+ssize_t atari_nvram_write(char *buf, size_t count, loff_t *ppos)
{
char *p = buf;
loff_t i;
@@ -137,22 +137,11 @@ static ssize_t nvram_write(char *buf, si
return p - buf;
}
-static ssize_t nvram_get_size(void)
+ssize_t atari_nvram_get_size(void)
{
- if (!MACH_IS_ATARI)
- return -ENODEV;
return NVRAM_BYTES;
}
-const struct nvram_ops arch_nvram_ops = {
- .read
[RFC v3 23/24] m68k/mac: Fix PRAM accessors
Signed-off-by: Finn Thain
---
Tested on a PowerBook 520 and Quadra 650.
Changes since v2:
- Make use of the RTC_* macros from the previous patch and add a few more
besides.
---
arch/m68k/mac/misc.c | 39 +--
include/uapi/linux/pmu.h |2 ++
2 files changed, 35 insertions(+), 6 deletions(-)
Index: linux/arch/m68k/mac/misc.c
===
--- linux.orig/arch/m68k/mac/misc.c 2015-06-28 11:41:54.0 +1000
+++ linux/arch/m68k/mac/misc.c 2015-06-28 11:41:55.0 +1000
@@ -119,19 +119,22 @@ static void pmu_write_time(long data)
static unsigned char pmu_pram_read_byte(int offset)
{
struct adb_request req;
- if (pmu_request(&req, NULL, 3, PMU_READ_NVRAM,
- (offset >> 8) & 0xFF, offset & 0xFF) < 0)
+
+ if (pmu_request(&req, NULL, 3, PMU_READ_XPRAM,
+ offset & 0xFF, 1) < 0)
return 0;
while (!req.complete)
pmu_poll();
- return req.reply[3];
+
+ return req.reply[1];
}
static void pmu_pram_write_byte(unsigned char data, int offset)
{
struct adb_request req;
- if (pmu_request(&req, NULL, 4, PMU_WRITE_NVRAM,
- (offset >> 8) & 0xFF, offset & 0xFF, data) < 0)
+
+ if (pmu_request(&req, NULL, 4, PMU_WRITE_XPRAM,
+ offset & 0xFF, 1, data) < 0)
return;
while (!req.complete)
pmu_poll();
@@ -257,6 +260,16 @@ static void via_rtc_send(__u8 data)
#define RTC_REG_WRITE_PROTECT 13
/*
+ * Inside Mac has no information about two-byte RTC commands but
+ * the MESS source code has the essentials.
+ */
+
+#define RTC_REG_XPRAM 14
+#define RTC_CMD_XPRAM_READ (RTC_CMD_READ(RTC_REG_XPRAM) << 8)
+#define RTC_CMD_XPRAM_WRITE (RTC_CMD_WRITE(RTC_REG_XPRAM) << 8)
+#define RTC_CMD_XPRAM_ARG(a)(((a & 0xE0) << 3) | ((a & 0x1F) << 2))
+
+/*
* Execute a VIA PRAM/RTC command. For read commands
* data should point to a one-byte buffer for the
* resulting data. For write commands it should point
@@ -303,11 +316,25 @@ static void via_rtc_command(int command,
static unsigned char via_pram_read_byte(int offset)
{
- return 0;
+ unsigned char temp;
+
+ via_rtc_command(RTC_CMD_XPRAM_READ | RTC_CMD_XPRAM_ARG(offset), &temp);
+
+ return temp;
}
static void via_pram_write_byte(unsigned char data, int offset)
{
+ unsigned char temp;
+
+ temp = 0x55;
+ via_rtc_command(RTC_CMD_WRITE(RTC_REG_WRITE_PROTECT), &temp);
+
+ temp = data;
+ via_rtc_command(RTC_CMD_XPRAM_WRITE | RTC_CMD_XPRAM_ARG(offset), &temp);
+
+ temp = 0x55 | RTC_FLG_WRITE_PROTECT;
+ via_rtc_command(RTC_CMD_WRITE(RTC_REG_WRITE_PROTECT), &temp);
}
/*
Index: linux/include/uapi/linux/pmu.h
===
--- linux.orig/include/uapi/linux/pmu.h 2015-06-28 11:41:27.0 +1000
+++ linux/include/uapi/linux/pmu.h 2015-06-28 11:41:55.0 +1000
@@ -18,7 +18,9 @@
#define PMU_POWER_CTRL 0x11/* control power of some devices */
#define PMU_ADB_CMD0x20/* send ADB packet */
#define PMU_ADB_POLL_OFF 0x21/* disable ADB auto-poll */
+#define PMU_WRITE_XPRAM0x32/* write eXtended Parameter RAM
*/
#define PMU_WRITE_NVRAM0x33/* write non-volatile RAM */
+#define PMU_READ_XPRAM 0x3a/* read eXtended Parameter RAM */
#define PMU_READ_NVRAM 0x3b/* read non-volatile RAM */
#define PMU_SET_RTC0x30/* set real-time clock */
#define PMU_READ_RTC 0x38/* read real-time clock */
--
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/
[RFC v3 21/24] m68k/mac: Adopt naming and calling conventions for PRAM routines
Adopt the existing *_read_byte and *_write_byte naming convention.
Rename via_pram_readbyte and via_pram_writebyte to avoid confusion.
Adjust calling conventions of mac_pram_* functions to match the
arch_nvram_ops struct methods.
Signed-off-by: Finn Thain
---
Changes since v1:
- Don't introduce the arch_nvram_ops struct in this patch, even if it
would form a logical progression. Since the struct would get replaced
later on, some might see it as churn.
Changes since v2:
- Rename via_pram_send() and via_pram_recv() as
via_rtc_send() and via_rtc_recv() resp.
---
arch/m68k/mac/misc.c | 91 +--
1 file changed, 46 insertions(+), 45 deletions(-)
Index: linux/arch/m68k/mac/misc.c
===
--- linux.orig/arch/m68k/mac/misc.c 2015-06-28 11:41:27.0 +1000
+++ linux/arch/m68k/mac/misc.c 2015-06-28 11:41:53.0 +1000
@@ -61,7 +61,7 @@ static void cuda_write_time(long data)
cuda_poll();
}
-static __u8 cuda_read_pram(int offset)
+static unsigned char cuda_pram_read_byte(int offset)
{
struct adb_request req;
if (cuda_request(&req, NULL, 4, CUDA_PACKET, CUDA_GET_PRAM,
@@ -72,7 +72,7 @@ static __u8 cuda_read_pram(int offset)
return req.reply[3];
}
-static void cuda_write_pram(int offset, __u8 data)
+static void cuda_pram_write_byte(unsigned char data, int offset)
{
struct adb_request req;
if (cuda_request(&req, NULL, 5, CUDA_PACKET, CUDA_SET_PRAM,
@@ -84,8 +84,8 @@ static void cuda_write_pram(int offset,
#else
#define cuda_read_time() 0
#define cuda_write_time(n)
-#define cuda_read_pram NULL
-#define cuda_write_pram NULL
+#define cuda_pram_read_byte NULL
+#define cuda_pram_write_byte NULL
#endif
#ifdef CONFIG_ADB_PMU68K
@@ -116,7 +116,7 @@ static void pmu_write_time(long data)
pmu_poll();
}
-static __u8 pmu_read_pram(int offset)
+static unsigned char pmu_pram_read_byte(int offset)
{
struct adb_request req;
if (pmu_request(&req, NULL, 3, PMU_READ_NVRAM,
@@ -127,7 +127,7 @@ static __u8 pmu_read_pram(int offset)
return req.reply[3];
}
-static void pmu_write_pram(int offset, __u8 data)
+static void pmu_pram_write_byte(unsigned char data, int offset)
{
struct adb_request req;
if (pmu_request(&req, NULL, 4, PMU_WRITE_NVRAM,
@@ -139,8 +139,8 @@ static void pmu_write_pram(int offset, _
#else
#define pmu_read_time() 0
#define pmu_write_time(n)
-#define pmu_read_pram NULL
-#define pmu_write_pram NULL
+#define pmu_pram_read_byte NULL
+#define pmu_pram_write_byte NULL
#endif
#if 0 /* def CONFIG_ADB_MACIISI */
@@ -169,7 +169,7 @@ static void maciisi_write_time(long data
(data >> 8) & 0xFF, data & 0xFF);
}
-static __u8 maciisi_read_pram(int offset)
+static unsigned char maciisi_pram_read_byte(int offset)
{
struct adb_request req;
if (maciisi_request(&req, NULL, 4, CUDA_PACKET, CUDA_GET_PRAM,
@@ -178,7 +178,7 @@ static __u8 maciisi_read_pram(int offset
return req.reply[3];
}
-static void maciisi_write_pram(int offset, __u8 data)
+static void maciisi_pram_write_byte(unsigned char data, int offset)
{
struct adb_request req;
maciisi_request(&req, NULL, 5, CUDA_PACKET, CUDA_SET_PRAM,
@@ -187,8 +187,8 @@ static void maciisi_write_pram(int offse
#else
#define maciisi_read_time() 0
#define maciisi_write_time(n)
-#define maciisi_read_pram NULL
-#define maciisi_write_pram NULL
+#define maciisi_pram_read_byte NULL
+#define maciisi_pram_write_byte NULL
#endif
/*
@@ -198,7 +198,7 @@ static void maciisi_write_pram(int offse
* the RTC should be enabled.
*/
-static __u8 via_pram_readbyte(void)
+static __u8 via_rtc_recv(void)
{
int i,reg;
__u8data;
@@ -225,7 +225,7 @@ static __u8 via_pram_readbyte(void)
return data;
}
-static void via_pram_writebyte(__u8 data)
+static void via_rtc_send(__u8 data)
{
int i,reg,bit;
@@ -262,17 +262,17 @@ static void via_pram_command(int command
via1[vBufB] = (via1[vBufB] | VIA1B_vRTCClk) & ~VIA1B_vRTCEnb;
if (command & 0xFF00) { /* extended (two-byte) command */
- via_pram_writebyte((command & 0xFF00) >> 8);
- via_pram_writebyte(command & 0xFF);
+ via_rtc_send((command & 0xFF00) >> 8);
+ via_rtc_send(command & 0xFF);
is_read = command & 0x8000;
} else {/* one-byte command */
- via_pram_writebyte(command);
+ via_rtc_send(command);
is_read = command & 0x80;
}
if (is_read) {
- *data = via_pram_readbyte();
+ *data = via_rtc_recv();
} else {
- via_pram_writebyte(*data);
+ via_rtc_send(*data);
}
/* All done, disable the RTC */
@@ -282,12 +282,12 @@ static v
[RFC v3 04/24] char/nvram: Re-order functions to remove forward declarations and #ifdefs
Also give functions more sensible names: nvram_misc_* for misc device ops,
nvram_proc_* for proc file ops and nvram_module_* for init and exit
functions. This makes them distict from nvram_ops members.
Signed-off-by: Finn Thain
---
drivers/char/nvram.c | 194 ++-
1 file changed, 86 insertions(+), 108 deletions(-)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/drivers/char/nvram.c 2015-06-28 11:41:29.0 +1000
+++ linux/drivers/char/nvram.c 2015-06-28 11:41:32.0 +1000
@@ -54,11 +54,6 @@ static int nvram_open_mode; /* special o
#define NVRAM_WRITE1 /* opened for writing (exclusive) */
#define NVRAM_EXCL 2 /* opened with O_EXCL */
-#ifdef CONFIG_PROC_FS
-static void pc_nvram_proc_read(unsigned char *contents, struct seq_file *seq,
- void *offset);
-#endif
-
/*
* These functions are provided to be called internally or by other parts of
* the kernel. It's up to the caller to ensure correct checksum before reading
@@ -170,7 +165,7 @@ void nvram_set_checksum(void)
* The are the file operation function for user access to /dev/nvram
*/
-static loff_t nvram_llseek(struct file *file, loff_t offset, int origin)
+static loff_t nvram_misc_llseek(struct file *file, loff_t offset, int origin)
{
switch (origin) {
case 0:
@@ -189,8 +184,8 @@ static loff_t nvram_llseek(struct file *
return (offset >= 0) ? (file->f_pos = offset) : -EINVAL;
}
-static ssize_t nvram_read(struct file *file, char __user *buf,
- size_t count, loff_t *ppos)
+static ssize_t nvram_misc_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
{
unsigned char contents[NVRAM_BYTES];
unsigned i = *ppos;
@@ -218,8 +213,8 @@ checksum_err:
return -EIO;
}
-static ssize_t nvram_write(struct file *file, const char __user *buf,
- size_t count, loff_t *ppos)
+static ssize_t nvram_misc_write(struct file *file, const char __user *buf,
+size_t count, loff_t *ppos)
{
unsigned char contents[NVRAM_BYTES];
unsigned i = *ppos;
@@ -257,8 +252,8 @@ checksum_err:
return -EIO;
}
-static long nvram_ioctl(struct file *file, unsigned int cmd,
- unsigned long arg)
+static long nvram_misc_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
{
int i;
@@ -298,7 +293,7 @@ static long nvram_ioctl(struct file *fil
}
}
-static int nvram_open(struct inode *inode, struct file *file)
+static int nvram_misc_open(struct inode *inode, struct file *file)
{
spin_lock(&nvram_state_lock);
@@ -320,7 +315,7 @@ static int nvram_open(struct inode *inod
return 0;
}
-static int nvram_release(struct inode *inode, struct file *file)
+static int nvram_misc_release(struct inode *inode, struct file *file)
{
spin_lock(&nvram_state_lock);
@@ -337,100 +332,6 @@ static int nvram_release(struct inode *i
return 0;
}
-#ifndef CONFIG_PROC_FS
-static int nvram_add_proc_fs(void)
-{
- return 0;
-}
-
-#else
-
-static int nvram_proc_read(struct seq_file *seq, void *offset)
-{
- unsigned char contents[NVRAM_BYTES];
- int i = 0;
-
- spin_lock_irq(&rtc_lock);
- for (i = 0; i < NVRAM_BYTES; ++i)
- contents[i] = __nvram_read_byte(i);
- spin_unlock_irq(&rtc_lock);
-
- pc_nvram_proc_read(contents, seq, offset);
-
- return 0;
-}
-
-static int nvram_proc_open(struct inode *inode, struct file *file)
-{
- return single_open(file, nvram_proc_read, NULL);
-}
-
-static const struct file_operations nvram_proc_fops = {
- .owner = THIS_MODULE,
- .open = nvram_proc_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
-
-static int nvram_add_proc_fs(void)
-{
- if (!proc_create("driver/nvram", 0, NULL, &nvram_proc_fops))
- return -ENOMEM;
- return 0;
-}
-
-#endif /* CONFIG_PROC_FS */
-
-static const struct file_operations nvram_fops = {
- .owner = THIS_MODULE,
- .llseek = nvram_llseek,
- .read = nvram_read,
- .write = nvram_write,
- .unlocked_ioctl = nvram_ioctl,
- .open = nvram_open,
- .release= nvram_release,
-};
-
-static struct miscdevice nvram_dev = {
- NVRAM_MINOR,
- "nvram",
- &nvram_fops
-};
-
-static int __init nvram_init(void)
-{
- int ret;
-
- ret = misc_register(&nvram_dev);
- if (ret) {
- printk(KERN_ERR "nvram: can't misc_register on minor=%d\n",
- NVRAM_MINOR);
- goto out;
-
[RFC v3 00/24] Re-use nvram module
The generic NVRAM module, drivers/char/generic_nvram, implements a /dev/nvram misc device. It is used only by 32-bit PowerPC platforms and isn't generic enough to be more widely used. The RTC NVRAM module, drivers/char/nvram, also implements a /dev/nvram misc device. It is used by x86, ARM and m68k. The former module cannot be used on x86, ARM or m68k because it cannot co-exist with the latter module, partly due to the Kconfig logic. It is possible to modify the modules so that one kernel binary could have either, neither or both. However, automatically loading the appropriate module is then impossible; if both provide the char-major-10-144 alias then the wrong module will end up being loaded. Hence a multi-platform kernel binary needs a single generic nvram module with alias char-major-10-144. Therefore, drivers/char/nvram.c should be made more generic and the arch-specific code therein should be moved to a more appropriate place under arch/. Also, drivers/char/generic_nvram.c should be removed to reduce code duplication. In this patch series, Atari-specific code is moved from the nvram module to arch/m68k/atari. More arch-specific code in the nvram module could be moved, probably to arch/x86, but it is difficult to determine just what code is relevant to ARM platforms and what code is x86-only. In addressing code duplication, this patch series removes three inconsistent /dev/nvram misc device implementations. One of these, drivers/macintosh/nvram.c is entirely unused already. The other two, drivers/char/generic_nvram.c and the misc device implementation in arch/powerpc/kernel/nvram_64.c, are replaced by drivers/char/nvram.c. A benefit of this work is better consistency -- between PPC32 and PPC64 as well as between PPC_PMAC and MAC. This new uniformity does have implications for userspace, that is, some error codes for some ioctl calls become consistent on all PowerPC platforms. The drivers/char/nvram module becomes sufficiently generic to be useful to other platforms and architectures, besides those with "CMOS" RTC. At the end of this patch series the module is adopted by the m68k Mac port, which already has PRAM access functions but lacks the /dev/nvram misc device. This patch series has been compile-tested for arm, m68k, powerpc and x86. The nvram and thinkpad_acpi modules were regression tested on a ThinkPad T43. The /dev/nvram functionality was also regression tested on a G3 PowerMac. The nvram module was also tested on a PowerBook 520 and Quadra 650. Note that my testing doesn't cover PPC64 or Atari. Changes since v1: - Minor changes to patches 7, 15 and 20 as described in commit logs. - Revised patches 21 and 24 to address comments from Geert. Changes since v2: - Dropped patch 1, "macintosh/nvram: Remove as unused", because it has since been merged. - Inserted a new patch, "m68k/mac: Use macros for RTC accesses not magic numbers". - Revised patches 21 and 23 to address comments from Geert. --- arch/m68k/Kconfig |3 arch/m68k/atari/Makefile |2 arch/m68k/atari/nvram.c| 291 +++ arch/m68k/kernel/setup_mm.c| 107 arch/m68k/mac/misc.c | 207 +--- arch/powerpc/Kconfig |5 arch/powerpc/include/asm/nvram.h |9 arch/powerpc/kernel/nvram_64.c | 203 +-- arch/powerpc/kernel/setup_32.c | 27 - arch/powerpc/platforms/chrp/Makefile |2 arch/powerpc/platforms/chrp/nvram.c| 14 arch/powerpc/platforms/chrp/setup.c|2 arch/powerpc/platforms/powermac/Makefile |5 arch/powerpc/platforms/powermac/nvram.c|9 arch/powerpc/platforms/powermac/setup.c|3 drivers/char/Kconfig | 13 drivers/char/Makefile |6 drivers/char/generic_nvram.c | 174 -- drivers/char/nvram.c | 742 - drivers/platform/x86/thinkpad_acpi.c | 20 drivers/scsi/Kconfig |6 drivers/scsi/atari_scsi.c | 16 drivers/video/fbdev/controlfb.c|4 drivers/video/fbdev/imsttfb.c |7 drivers/video/fbdev/matrox/matroxfb_base.c |4 drivers/video/fbdev/platinumfb.c |4 drivers/video/fbdev/valkyriefb.c |4 include/linux/nvram.h | 23 include/uapi/linux/pmu.h |2 29 files changed, 982 insertions(+), 932 deletions(-) -- 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/
[RFC v3 05/24] char/nvram: Adopt arch_nvram_ops
Different platforms and architectures offer different NVRAM sizes and
access methods. E.g. PPC32 has byte-at-a-time read/write functions whereas
PPC64 has byte-range read/write functions. Adopt the nvram_ops struct so
the nvram module can call such functions as are defined by the various
platforms and architectures.
Signed-off-by: Finn Thain
---
The #ifdefs here restrict the procfs and checksumming code to those
architectures with PC-style RTC NVRAM. There may be a better place for
that code but it's an open question. See https://lkml.org/lkml/2015/2/3/22
The procfs code here, if irrelevant to ARM platforms, could be moved to
arch/x86 (like the earlier patch does for m68k code) and the nvram ops
could be implemented and exported by the rtc-cmos driver instead. This
would eliminate these #ifdefs.
---
drivers/char/nvram.c | 30 +++---
include/linux/nvram.h |2 ++
2 files changed, 29 insertions(+), 3 deletions(-)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/drivers/char/nvram.c 2015-06-28 11:41:32.0 +1000
+++ linux/drivers/char/nvram.c 2015-06-28 11:41:34.0 +1000
@@ -51,9 +51,12 @@ static DEFINE_MUTEX(nvram_mutex);
static DEFINE_SPINLOCK(nvram_state_lock);
static int nvram_open_cnt; /* #times opened */
static int nvram_open_mode;/* special open modes */
+static ssize_t nvram_size;
#define NVRAM_WRITE1 /* opened for writing (exclusive) */
#define NVRAM_EXCL 2 /* opened with O_EXCL */
+#if defined(CONFIG_X86) || defined(CONFIG_ARM)
+
/*
* These functions are provided to be called internally or by other parts of
* the kernel. It's up to the caller to ensure correct checksum before reading
@@ -161,6 +164,20 @@ void nvram_set_checksum(void)
}
#endif /* 0 */
+static ssize_t nvram_get_size(void)
+{
+ return NVRAM_BYTES;
+}
+
+const struct nvram_ops arch_nvram_ops = {
+ .read_byte = nvram_read_byte,
+ .write_byte = nvram_write_byte,
+ .get_size = nvram_get_size,
+};
+EXPORT_SYMBOL(arch_nvram_ops);
+
+#endif /* CONFIG_X86 || CONFIG_ARM */
+
/*
* The are the file operation function for user access to /dev/nvram
*/
@@ -332,7 +349,7 @@ static int nvram_misc_release(struct ino
return 0;
}
-#ifdef CONFIG_PROC_FS
+#if defined(CONFIG_PROC_FS) && (defined(CONFIG_X86) || defined(CONFIG_ARM))
static char *floppy_types[] = {
"none", "5.25'' 360k", "5.25'' 1.2M", "3.5'' 720k", "3.5'' 1.44M",
@@ -459,13 +476,20 @@ static int __init nvram_module_init(void
{
int ret;
+ if (arch_nvram_ops.get_size == NULL)
+ return -ENODEV;
+
+ nvram_size = arch_nvram_ops.get_size();
+ if (nvram_size < 0)
+ return nvram_size;
+
ret = misc_register(&nvram_misc);
if (ret) {
pr_err("nvram: can't misc_register on minor=%d\n", NVRAM_MINOR);
return ret;
}
-#ifdef CONFIG_PROC_FS
+#if defined(CONFIG_PROC_FS) && (defined(CONFIG_X86) || defined(CONFIG_ARM))
if (!proc_create("driver/nvram", 0, NULL, &nvram_proc_fops)) {
pr_err("nvram: can't create /proc/driver/nvram\n");
misc_deregister(&nvram_misc);
@@ -479,7 +503,7 @@ static int __init nvram_module_init(void
static void __exit nvram_module_exit(void)
{
-#ifdef CONFIG_PROC_FS
+#if defined(CONFIG_PROC_FS) && (defined(CONFIG_X86) || defined(CONFIG_ARM))
remove_proc_entry("driver/nvram", NULL);
#endif
misc_deregister(&nvram_misc);
Index: linux/include/linux/nvram.h
===
--- linux.orig/include/linux/nvram.h2015-06-28 11:41:31.0 +1000
+++ linux/include/linux/nvram.h 2015-06-28 11:41:34.0 +1000
@@ -14,6 +14,8 @@ extern int nvram_check_checksum(void);
struct nvram_ops {
ssize_t (*read)(char *, size_t, loff_t *);
ssize_t (*write)(char *, size_t, loff_t *);
+ unsigned char (*read_byte)(int);
+ void(*write_byte)(unsigned char, int);
ssize_t (*get_size)(void);
};
--
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 2/2] Check tcsetpgrp p is a process group.
On Sat, Jun 27, 2015 at 7:26 PM, Greg Kroah-Hartman
wrote:
> On Sat, Jun 27, 2015 at 05:17:03PM -0400, Patrick Donnelly wrote:
>> This fixes a bug where a process can set the foreground process group to its
>> pid even if its pid is not a valid pgrp.
>>
>> Signed-off-by: Patrick Donnelly
>> ---
>> drivers/tty/tty_io.c | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
>> index 401d05e..c20a2fb 100644
>> --- a/drivers/tty/tty_io.c
>> +++ b/drivers/tty/tty_io.c
>> @@ -2560,9 +2560,11 @@ static int tiocspgrp(struct tty_struct *tty, struct
>> tty_struct *real_tty, pid_t
>> {
>> struct pid *pgrp;
>> pid_t pgrp_nr;
>> - int retval = tty_check_change(real_tty);
>> + int retval;
>> unsigned long flags;
>>
>> + retval = tty_check_change(real_tty);
>
> Why this churn?
I removed it in the new version, sorry. I thought it made the code
more consistent.
--
Patrick Donnelly
--
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 v2 1/2] tty: add missing rcu_read_lock for task_pgrp
task_pgrp requires an rcu or tasklist lock to be obtained if the returned pid
is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the
duration of use.
Signed-off-by: Patrick Donnelly
---
drivers/tty/tty_io.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 57fc6ee..fbb55db 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -388,33 +388,39 @@ EXPORT_SYMBOL_GPL(tty_find_polling_driver);
int tty_check_change(struct tty_struct *tty)
{
unsigned long flags;
+ struct pid *pgrp;
int ret = 0;
if (current->signal->tty != tty)
return 0;
- spin_lock_irqsave(&tty->ctrl_lock, flags);
+ rcu_read_lock();
+ pgrp = task_pgrp(current);
+ spin_lock_irqsave(&tty->ctrl_lock, flags);
if (!tty->pgrp) {
printk(KERN_WARNING "tty_check_change: tty->pgrp == NULL!\n");
- goto out_unlock;
+ goto out_irqunlock;
}
- if (task_pgrp(current) == tty->pgrp)
- goto out_unlock;
+ if (pgrp == tty->pgrp)
+ goto out_irqunlock;
spin_unlock_irqrestore(&tty->ctrl_lock, flags);
+
if (is_ignored(SIGTTOU))
- goto out;
+ goto out_rcuunlock;
if (is_current_pgrp_orphaned()) {
ret = -EIO;
- goto out;
+ goto out_rcuunlock;
}
- kill_pgrp(task_pgrp(current), SIGTTOU, 1);
+ kill_pgrp(pgrp, SIGTTOU, 1);
+ rcu_read_unlock();
set_thread_flag(TIF_SIGPENDING);
ret = -ERESTARTSYS;
-out:
return ret;
-out_unlock:
+out_irqunlock:
spin_unlock_irqrestore(&tty->ctrl_lock, flags);
+out_rcuunlock:
+ rcu_read_unlock();
return ret;
}
--
Patrick Donnelly
--
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 v2 2/2] tty: check tcsetpgrp p is a process group
This fixes a bug where a process can set the foreground process group to its pid even if its pid is not a valid pgrp. Signed-off-by: Patrick Donnelly --- drivers/tty/tty_io.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index fbb55db..01b4769 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -2579,6 +2579,9 @@ static int tiocspgrp(struct tty_struct *tty, struct tty_struct *real_tty, pid_t retval = -ESRCH; if (!pgrp) goto out_unlock; + retval = -EINVAL; + if (!pid_task(pgrp, PIDTYPE_PGID)) + goto out_unlock; retval = -EPERM; if (session_of_pgrp(pgrp) != task_session(current)) goto out_unlock; -- Patrick Donnelly -- 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 v5 5/5] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
On Sun, 28 Jun 2015, Ruslan Bilovol wrote: > > Weren't you going to replace this loop with a simple list_del()? IIRC, > > this is the third time I have asked you to make this change. > > I understand the improvement that replacing this loop with a list_del() > may bring for us, but I disagree with doing it in this particular case. > > The reason is simple. The usb_gadget_unregister_driver() funciton is > externally visible so we can get junk as input. Current implementation > checks passed pointer and only after that does list_del(), or > returns -EINVAL. Your variant will do list_del() unconditionally, that > may cause a kernel crash or unexpected behavior in case of junk > passed with *driver. The list_del_init() usage can't help here since > there is no way to check that list_head structure is initialized with correct > data or contains junk. That's right. > There is no noticeable performance loss with current implementation,just > because current use case is pretty simple: one gadget driver per one UDC, > and usually there is only one UDC per machine (or rare cases with few > UDCs), thus number of pending gadget drivers is relatively small. > We can return back to this discussion if someone needs to register > many gadget drivers, and want to improve performance, because > there are few existing places (not created by me) in this file that uses > same approach of walking through list of registered gadget drivers. > > As a bottom line, choosing between stability and little performance > improvement, I prefer stability. It's not really a question of code size or performance. As you say, the difference in each is minimal. It _is_ a question of style. Adding unnecessary code to check for something that shouldn't need to be checked looks bad. Other kernel developers reading that code will notice it and wonder why it's there. That's the argument for getting rid of the loop. Your argument for keeping the loop is to prevent crashes when the function is called by a buggy driver. Lots of other people have made similar arguments in the past. But that's not how the kernel is written -- we don't go out of our way to cover up potential bugs. If a driver is buggy, we _want_ it to cause a crash! How else are we going to know about the bug? Sure, there might be other symptoms that someone might eventually notice. But nobody can miss an oops. In short, don't try to protect against mistakes in other people's code. Let them stand out so they can get fixed! Alan Stern -- 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 2/8] driver-core: add asynchronous probing support for drivers
On Mon, Mar 30, 2015 at 4:20 PM, Dmitry Torokhov wrote: > Some devices take a long time when initializing, and not all drivers are > suited to initialize their devices when they are open. For example, > input drivers need to interrogate their devices in order to publish > device's capabilities before userspace will open them. When such drivers > are compiled into kernel they may stall entire kernel initialization. > > This change allows drivers request for their probe functions to be > called asynchronously during driver and device registration (manual > binding is still synchronous). Because async_schedule is used to perform > asynchronous calls module loading will still wait for the probing to > complete. > > Note that the end goal is to make the probing asynchronous by default, > so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary > measure that allows us to speed up boot process while we validating and > fixing the rest of the drivers and preparing userspace. > > This change is based on earlier patch by "Luis R. Rodriguez" > > > Signed-off-by: Dmitry Torokhov > --- > drivers/base/base.h| 1 + > drivers/base/bus.c | 31 +++--- > drivers/base/dd.c | 149 > ++--- > include/linux/device.h | 28 ++ > 4 files changed, 182 insertions(+), 27 deletions(-) Just noticed this patch. It caught my eye because I had a hard time getting an open coded implementation of asynchronous probing to work in the new libnvdimm subsystem. Especially the messy races of tearing things down while probing is still in flight. I ended up implementing asynchronous device registration which eliminated a lot of complexity and of course the bugs. In general I tend to think that async registration is less risky than async probe since it keeps wider portions of the traditional device model synchronous and leverages the fact that the device model is already well prepared for asynchronous arrival of devices due to hotplug. Splitting the "initial probe" from the "manual probe" case seems like a recipe for confusion. -- 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 2/2] Check tcsetpgrp p is a process group.
On Sat, Jun 27, 2015 at 05:17:03PM -0400, Patrick Donnelly wrote:
> This fixes a bug where a process can set the foreground process group to its
> pid even if its pid is not a valid pgrp.
>
> Signed-off-by: Patrick Donnelly
> ---
> drivers/tty/tty_io.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 401d05e..c20a2fb 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -2560,9 +2560,11 @@ static int tiocspgrp(struct tty_struct *tty, struct
> tty_struct *real_tty, pid_t
> {
> struct pid *pgrp;
> pid_t pgrp_nr;
> - int retval = tty_check_change(real_tty);
> + int retval;
> unsigned long flags;
>
> + retval = tty_check_change(real_tty);
> +
> if (retval == -EIO)
> return -ENOTTY;
> if (retval)
> @@ -2580,6 +2582,10 @@ static int tiocspgrp(struct tty_struct *tty, struct
> tty_struct *real_tty, pid_t
> retval = -ESRCH;
> if (!pgrp)
> goto out_unlock;
> + retval = -EINVAL;
> + if (!pid_task(pgrp, PIDTYPE_PGID)) {
> + goto out_unlock;
> + }
> retval = -EPERM;
> if (session_of_pgrp(pgrp) != task_session(current))
> goto out_unlock;
Always run your patches though checkpatch.pl so you don't get emails
telling you to fix the things that checkpatch.pl tells you to...
--
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 2/2] Check tcsetpgrp p is a process group.
On Sat, Jun 27, 2015 at 05:17:03PM -0400, Patrick Donnelly wrote:
> This fixes a bug where a process can set the foreground process group to its
> pid even if its pid is not a valid pgrp.
>
> Signed-off-by: Patrick Donnelly
> ---
> drivers/tty/tty_io.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 401d05e..c20a2fb 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -2560,9 +2560,11 @@ static int tiocspgrp(struct tty_struct *tty, struct
> tty_struct *real_tty, pid_t
> {
> struct pid *pgrp;
> pid_t pgrp_nr;
> - int retval = tty_check_change(real_tty);
> + int retval;
> unsigned long flags;
>
> + retval = tty_check_change(real_tty);
Why this churn?
--
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/2] Add missing rcu_read_lock for task_pgrp.
On Sat, Jun 27, 2015 at 05:17:02PM -0400, Patrick Donnelly wrote: > Signed-off-by: Patrick Donnelly No changelog text? Sorry, it's required. -- 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] ASoC: fsl_ssi: fix AC'97 mode
Hello Fabio,
W dniu 28.06.2015 01:06, Fabio Estevam pisze:
> Hi Maciej,
>
> On Sat, Jun 27, 2015 at 7:51 PM, Maciej S. Szmigiero
> wrote:
>> Currently the AC'97 mode in fsl_ssi driver isn't functional.
>
> Thanks for the fix. I look forward to test it on my udoo board.
Thanks.
>> This patch implements the following changes to make it work
>> properly:
>> * IPG clock have to be enabled during AC'97 CODEC
>> register access,
>> * AC'97 DAI driver struct need the same probe method as
>> I2S one to setup DMA params,
>> * AC'97 bus can support asymmetric playback/capture rates,
>> * Check whether setting AC'97 ops succeeded and
>> clean them on removal so the driver can be reloaded,
>> * AC'97 CODEC will be instantiated in AC'97 mode,
>> * Set DAI format function small fixes in AC'97 mode.
>
> It seems like a lot of changes in a single patch.
>
> Care to split it into smaller pieces?
OK, I will resend this split into individual patches.
>> +
>> + ret = clk_prepare_enable(fsl_ac97_data->clk);
>> + if (ret) {
>> + pr_err("ac97 read clk_prepare_enable failed: %d\n",
>> + ret);
>> + return -1;
> 'return ret' would be better here.
This function normal return value is an AC'97 register value,
so isn't more appropriate to return 0x in case of error
than linux error code?
> Thanks
Best regards,
Maciej Szmigiero
--
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] ASoC: fsl_ssi: fix AC'97 mode
On Sat, Jun 27, 2015 at 7:51 PM, Maciej S. Szmigiero
wrote:
> +
> + ret = clk_prepare_enable(fsl_ac97_data->clk);
> + if (ret) {
> + pr_err("ac97 read clk_prepare_enable failed: %d\n",
> + ret);
> + return -1;
'return ret' would be better here.
Thanks
--
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] ASoC: fsl_ssi: fix AC'97 mode
Hi Maciej, On Sat, Jun 27, 2015 at 7:51 PM, Maciej S. Szmigiero wrote: > Currently the AC'97 mode in fsl_ssi driver isn't functional. Thanks for the fix. I look forward to test it on my udoo board. > This patch implements the following changes to make it work > properly: > * IPG clock have to be enabled during AC'97 CODEC > register access, > * AC'97 DAI driver struct need the same probe method as > I2S one to setup DMA params, > * AC'97 bus can support asymmetric playback/capture rates, > * Check whether setting AC'97 ops succeeded and > clean them on removal so the driver can be reloaded, > * AC'97 CODEC will be instantiated in AC'97 mode, > * Set DAI format function small fixes in AC'97 mode. It seems like a lot of changes in a single patch. Care to split it into smaller pieces? Thanks -- 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] ASoC: fsl_ssi: fix AC'97 mode
Currently the AC'97 mode in fsl_ssi driver isn't functional.
This patch implements the following changes to make it work
properly:
* IPG clock have to be enabled during AC'97 CODEC
register access,
* AC'97 DAI driver struct need the same probe method as
I2S one to setup DMA params,
* AC'97 bus can support asymmetric playback/capture rates,
* Check whether setting AC'97 ops succeeded and
clean them on removal so the driver can be reloaded,
* AC'97 CODEC will be instantiated in AC'97 mode,
* Set DAI format function small fixes in AC'97 mode.
Tested on UDOO board.
Signed-off-by: Maciej Szmigiero
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index c7647e0..9a63df2 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -900,14 +900,16 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
scr &= ~CCSR_SSI_SCR_SYS_CLK_EN;
break;
default:
- return -EINVAL;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ return -EINVAL;
}
stcr |= strcr;
srcr |= strcr;
- if (ssi_private->cpu_dai_drv.symmetric_rates) {
- /* Need to clear RXDIR when using SYNC mode */
+ if (ssi_private->cpu_dai_drv.symmetric_rates
+ || fsl_ssi_is_ac97(ssi_private)) {
+ /* Need to clear RXDIR when using SYNC or AC97 mode */
srcr &= ~CCSR_SSI_SRCR_RXDIR;
scr |= CCSR_SSI_SCR_SYN;
}
@@ -1101,6 +1103,7 @@ static const struct snd_soc_component_driver
fsl_ssi_component = {
static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
.bus_control = true,
+ .probe = fsl_ssi_dai_probe,
.playback = {
.stream_name = "AC97 Playback",
.channels_min = 2,
@@ -1127,10 +1130,17 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97,
unsigned short reg,
struct regmap *regs = fsl_ac97_data->regs;
unsigned int lreg;
unsigned int lval;
+ int ret;
if (reg > 0x7f)
return;
+ ret = clk_prepare_enable(fsl_ac97_data->clk);
+ if (ret) {
+ pr_err("ac97 write clk_prepare_enable failed: %d\n",
+ ret);
+ return;
+ }
lreg = reg << 12;
regmap_write(regs, CCSR_SSI_SACADD, lreg);
@@ -1141,6 +1151,8 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97,
unsigned short reg,
regmap_update_bits(regs, CCSR_SSI_SACNT, CCSR_SSI_SACNT_RDWR_MASK,
CCSR_SSI_SACNT_WR);
udelay(100);
+
+ clk_disable_unprepare(fsl_ac97_data->clk);
}
static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
@@ -1151,6 +1163,14 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97
*ac97,
unsigned short val = -1;
u32 reg_val;
unsigned int lreg;
+ int ret;
+
+ ret = clk_prepare_enable(fsl_ac97_data->clk);
+ if (ret) {
+ pr_err("ac97 read clk_prepare_enable failed: %d\n",
+ ret);
+ return -1;
+ }
lreg = (reg & 0x7f) << 12;
regmap_write(regs, CCSR_SSI_SACADD, lreg);
@@ -1162,6 +1182,8 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97
*ac97,
regmap_read(regs, CCSR_SSI_SACDAT, ®_val);
val = (reg_val >> 4) & 0x;
+ clk_disable_unprepare(fsl_ac97_data->clk);
+
return val;
}
@@ -1291,6 +1313,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *iomem;
char name[64];
+ bool newbinding;
of_id = of_match_device(fsl_ssi_ids, &pdev->dev);
if (!of_id || !of_id->data)
@@ -1320,7 +1343,11 @@ static int fsl_ssi_probe(struct platform_device *pdev)
fsl_ac97_data = ssi_private;
- snd_soc_set_ac97_ops_of_reset(&fsl_ssi_ac97_ops, pdev);
+ ret = snd_soc_set_ac97_ops_of_reset(&fsl_ssi_ac97_ops, pdev);
+ if (ret) {
+ dev_err(&pdev->dev, "could not set AC'97 ops\n");
+ return ret;
+ }
} else {
/* Initialize this copy of the CPU DAI driver structure */
memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
@@ -1357,7 +1384,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
/* Are the RX and the TX clocks locked? */
if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
- ssi_private->cpu_dai_drv.symmetric_rates = 1;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ ssi_private->cpu_dai_drv.symmetric_rates = 1;
+
ssi_private->cpu_dai_drv.symmetric_channels = 1;
ssi_private->cpu_dai_drv.symmetric_samplebits = 1;
}
@@ -1405,7 +1434,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
* that the machine driver uses new binding
Re: [PATCH v5 5/5] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
Hi Alan,
On Tue, Jun 23, 2015 at 5:08 PM, Alan Stern wrote:
> On Tue, 23 Jun 2015, Ruslan Bilovol wrote:
>
>> Change behavior during registration of gadgets and
>> gadget drivers in udc-core. Instead of previous
>> approach when for successful probe of usb gadget driver
>> at least one usb gadget should be already registered
>> use another one where gadget drivers and gadgets
>> can be registered in udc-core independently.
>>
>> Independent registration of gadgets and gadget drivers
>> is useful for built-in into kernel gadget and gadget
>> driver case - because it's possible that gadget is
>> really probed only on late_init stage (due to deferred
>> probe) whereas gadget driver's probe is silently failed
>> on module_init stage due to no any UDC added.
>>
>> Also it is useful for modules case - now there is no
>> difference what module to insert first: gadget module
>> or gadget driver one.
>>
>> Tested-by: Maxime Ripard
>> Signed-off-by: Ruslan Bilovol
>
>> @@ -484,6 +507,16 @@ int usb_gadget_unregister_driver(struct
>> usb_gadget_driver *driver)
>> break;
>> }
>>
>> + if (ret) {
>> + struct usb_gadget_driver *tmp;
>> +
>> + list_for_each_entry(tmp, &gadget_driver_pending_list, pending)
>> + if (tmp == driver) {
>> + list_del(&driver->pending);
>> + ret = 0;
>> + break;
>> + }
>> + }
>
> Weren't you going to replace this loop with a simple list_del()? IIRC,
> this is the third time I have asked you to make this change.
I understand the improvement that replacing this loop with a list_del()
may bring for us, but I disagree with doing it in this particular case.
The reason is simple. The usb_gadget_unregister_driver() funciton is
externally visible so we can get junk as input. Current implementation
checks passed pointer and only after that does list_del(), or
returns -EINVAL. Your variant will do list_del() unconditionally, that
may cause a kernel crash or unexpected behavior in case of junk
passed with *driver. The list_del_init() usage can't help here since
there is no way to check that list_head structure is initialized with correct
data or contains junk.
There is no noticeable performance loss with current implementation,just
because current use case is pretty simple: one gadget driver per one UDC,
and usually there is only one UDC per machine (or rare cases with few
UDCs), thus number of pending gadget drivers is relatively small.
We can return back to this discussion if someone needs to register
many gadget drivers, and want to improve performance, because
there are few existing places (not created by me) in this file that uses
same approach of walking through list of registered gadget drivers.
As a bottom line, choosing between stability and little performance
improvement, I prefer stability.
Best regards,
Ruslan
--
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] hwmon: (nct7802) add temperature sensor type attribute
On 06/27/2015 02:34 PM, Constantine Shulyupin wrote: From: const 0, 3 - Temperature attributes are hidden 1 - Current mode 2 - Thermistor mode Reference: Nuvoton Hardware Monitoring IC NCT7802Y 7.2.32 Mode Selection Register Location : Index 22h Signed-off-by: Constantine Shulyupin Hi Constantine, when resending a patch, please mark its version and provide a change log. Remember that the patches are visible online forever, and without an indication what changed no one will know the difference a year from now with out version and change log. Thanks, Guenter -- 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] hwmon: (nct7802) add temperature sensor type attribute
Hi Constantine,
On 06/27/2015 02:23 PM, Constantine Shulyupin wrote:
From: const
0, 3 - Temperature attributes are hidden
Not really per your code (though they should be hidden).
1 - Current mode
2 - Thermistor mode
Wrong - that should be 3 for current (diode) mode and 4 for thermistor mode.
The values are part of the ABI and must not be changed
(look at the output of the sensors command and you'll understand why).
Reference:
Nuvoton Hardware Monitoring IC NCT7802Y
7.2.32 Mode Selection Register
Location : Index 22h
Signed-off-by: Constantine Shulyupin
---
drivers/hwmon/nct7802.c | 53 -
scripts/checkpatch.pl | 2 +-
2 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/nct7802.c b/drivers/hwmon/nct7802.c
index 60cf5d1..444eedf 100644
--- a/drivers/hwmon/nct7802.c
+++ b/drivers/hwmon/nct7802.c
@@ -49,7 +49,7 @@ static const u8 REG_VOLTAGE_LIMIT_MSB_SHIFT[2][5] = {
#define REG_VOLTAGE_LOW 0x0f
#define REG_FANCOUNT_LOW 0x13
#define REG_START 0x21
-#define REG_MODE 0x22
+#define REG_MODE 0x22 /* 7.2.32 Mode Selection Register */
#define REG_PECI_ENABLE 0x23
#define REG_FAN_ENABLE0x24
#define REG_VMON_ENABLE 0x25
@@ -725,7 +725,58 @@ static struct attribute_group nct7802_fan_group = {
.is_visible = nct7802_fan_is_visible,
};
+static ssize_t show_temp_type(struct device *dev, struct device_attribute
*attr,
+ char *buf)
+{
+ struct nct7802_data *data = dev_get_drvdata(dev);
+ struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(data->regmap, REG_MODE, &val);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "%u\n", val >> (2 * sattr->index) & 3);
Please convert to correct ABI values.
+}
+
+static ssize_t store_temp_type(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct nct7802_data *data = dev_get_drvdata(dev);
+ struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
+ unsigned int val;
+ int err;
+
+ err = kstrtouint(buf, 0, &val);
+ if (err < 0)
+ return err;
+ if (val > 0xF)
+ return -EINVAL;
+
Please only accept 3 and 4 for the first two sensors,
and only 4 for the third sensor, and convert to register
values as needed.
+ err = regmap_update_bits(data->regmap, REG_MODE,
+ 3 << 2 * sattr->index, val << 2 * sattr->index);
+ sysfs_update_group(&dev->kobj, &nct7802_temp_group);
+ return err ? : count;
+}
+
+/* 7.2.32 Mode Selection Register */
+static SENSOR_DEVICE_ATTR(temp1_type, S_IRUGO | S_IWUSR,
+ show_temp_type, store_temp_type, 0);
+static SENSOR_DEVICE_ATTR(temp2_type, S_IRUGO | S_IWUSR,
+ show_temp_type, store_temp_type, 1);
+static SENSOR_DEVICE_ATTR(temp3_type, S_IRUGO | S_IWUSR,
+ show_temp_type, store_temp_type, 2);
Please align continuation lines with '('.
+
+static struct attribute *general_attributes[] = {
+ &sensor_dev_attr_temp1_type.dev_attr.attr,
+ &sensor_dev_attr_temp2_type.dev_attr.attr,
+ &sensor_dev_attr_temp3_type.dev_attr.attr,
+ NULL
+};
+
static const struct attribute_group *nct7802_groups[] = {
+ &(const struct attribute_group){ .attrs = general_attributes },
Please merge the new attributes into temp_group to get correct visibility.
&nct7802_temp_group,
&nct7802_in_group,
&nct7802_fan_group,
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4f484ac..bf9a680 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -14,7 +14,7 @@ my $V = '0.32';
use Getopt::Long qw(:config no_auto_abbrev);
-my $LINELENGTH=120;
+my $LINELENGTH=80;
That doesn't belong here.
my $quiet = 0;
my $tree = 1;
--
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] hwmon: (nct7802) add temperature sensor type attribute
From: const
0, 3 - Temperature attributes are hidden
1 - Current mode
2 - Thermistor mode
Reference:
Nuvoton Hardware Monitoring IC NCT7802Y
7.2.32 Mode Selection Register
Location : Index 22h
Signed-off-by: Constantine Shulyupin
---
drivers/hwmon/nct7802.c | 53 -
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/nct7802.c b/drivers/hwmon/nct7802.c
index 60cf5d1..444eedf 100644
--- a/drivers/hwmon/nct7802.c
+++ b/drivers/hwmon/nct7802.c
@@ -49,7 +49,7 @@ static const u8 REG_VOLTAGE_LIMIT_MSB_SHIFT[2][5] = {
#define REG_VOLTAGE_LOW0x0f
#define REG_FANCOUNT_LOW 0x13
#define REG_START 0x21
-#define REG_MODE 0x22
+#define REG_MODE 0x22 /* 7.2.32 Mode Selection Register */
#define REG_PECI_ENABLE0x23
#define REG_FAN_ENABLE 0x24
#define REG_VMON_ENABLE0x25
@@ -725,7 +725,58 @@ static struct attribute_group nct7802_fan_group = {
.is_visible = nct7802_fan_is_visible,
};
+static ssize_t show_temp_type(struct device *dev, struct device_attribute
*attr,
+ char *buf)
+{
+ struct nct7802_data *data = dev_get_drvdata(dev);
+ struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(data->regmap, REG_MODE, &val);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "%u\n", val >> (2 * sattr->index) & 3);
+}
+
+static ssize_t store_temp_type(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct nct7802_data *data = dev_get_drvdata(dev);
+ struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
+ unsigned int val;
+ int err;
+
+ err = kstrtouint(buf, 0, &val);
+ if (err < 0)
+ return err;
+ if (val > 0xF)
+ return -EINVAL;
+
+ err = regmap_update_bits(data->regmap, REG_MODE,
+ 3 << 2 * sattr->index, val << 2 * sattr->index);
+ sysfs_update_group(&dev->kobj, &nct7802_temp_group);
+ return err ? : count;
+}
+
+/* 7.2.32 Mode Selection Register */
+static SENSOR_DEVICE_ATTR(temp1_type, S_IRUGO | S_IWUSR,
+ show_temp_type, store_temp_type, 0);
+static SENSOR_DEVICE_ATTR(temp2_type, S_IRUGO | S_IWUSR,
+ show_temp_type, store_temp_type, 1);
+static SENSOR_DEVICE_ATTR(temp3_type, S_IRUGO | S_IWUSR,
+ show_temp_type, store_temp_type, 2);
+
+static struct attribute *general_attributes[] = {
+ &sensor_dev_attr_temp1_type.dev_attr.attr,
+ &sensor_dev_attr_temp2_type.dev_attr.attr,
+ &sensor_dev_attr_temp3_type.dev_attr.attr,
+ NULL
+};
+
static const struct attribute_group *nct7802_groups[] = {
+ &(const struct attribute_group){ .attrs = general_attributes },
&nct7802_temp_group,
&nct7802_in_group,
&nct7802_fan_group,
--
1.9.1
--
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] hwmon: (nct7802) add temperature sensor type attribute
From: const
0, 3 - Temperature attributes are hidden
1 - Current mode
2 - Thermistor mode
Reference:
Nuvoton Hardware Monitoring IC NCT7802Y
7.2.32 Mode Selection Register
Location : Index 22h
Signed-off-by: Constantine Shulyupin
---
drivers/hwmon/nct7802.c | 53 -
scripts/checkpatch.pl | 2 +-
2 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/nct7802.c b/drivers/hwmon/nct7802.c
index 60cf5d1..444eedf 100644
--- a/drivers/hwmon/nct7802.c
+++ b/drivers/hwmon/nct7802.c
@@ -49,7 +49,7 @@ static const u8 REG_VOLTAGE_LIMIT_MSB_SHIFT[2][5] = {
#define REG_VOLTAGE_LOW0x0f
#define REG_FANCOUNT_LOW 0x13
#define REG_START 0x21
-#define REG_MODE 0x22
+#define REG_MODE 0x22 /* 7.2.32 Mode Selection Register */
#define REG_PECI_ENABLE0x23
#define REG_FAN_ENABLE 0x24
#define REG_VMON_ENABLE0x25
@@ -725,7 +725,58 @@ static struct attribute_group nct7802_fan_group = {
.is_visible = nct7802_fan_is_visible,
};
+static ssize_t show_temp_type(struct device *dev, struct device_attribute
*attr,
+ char *buf)
+{
+ struct nct7802_data *data = dev_get_drvdata(dev);
+ struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(data->regmap, REG_MODE, &val);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "%u\n", val >> (2 * sattr->index) & 3);
+}
+
+static ssize_t store_temp_type(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct nct7802_data *data = dev_get_drvdata(dev);
+ struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
+ unsigned int val;
+ int err;
+
+ err = kstrtouint(buf, 0, &val);
+ if (err < 0)
+ return err;
+ if (val > 0xF)
+ return -EINVAL;
+
+ err = regmap_update_bits(data->regmap, REG_MODE,
+ 3 << 2 * sattr->index, val << 2 * sattr->index);
+ sysfs_update_group(&dev->kobj, &nct7802_temp_group);
+ return err ? : count;
+}
+
+/* 7.2.32 Mode Selection Register */
+static SENSOR_DEVICE_ATTR(temp1_type, S_IRUGO | S_IWUSR,
+ show_temp_type, store_temp_type, 0);
+static SENSOR_DEVICE_ATTR(temp2_type, S_IRUGO | S_IWUSR,
+ show_temp_type, store_temp_type, 1);
+static SENSOR_DEVICE_ATTR(temp3_type, S_IRUGO | S_IWUSR,
+ show_temp_type, store_temp_type, 2);
+
+static struct attribute *general_attributes[] = {
+ &sensor_dev_attr_temp1_type.dev_attr.attr,
+ &sensor_dev_attr_temp2_type.dev_attr.attr,
+ &sensor_dev_attr_temp3_type.dev_attr.attr,
+ NULL
+};
+
static const struct attribute_group *nct7802_groups[] = {
+ &(const struct attribute_group){ .attrs = general_attributes },
&nct7802_temp_group,
&nct7802_in_group,
&nct7802_fan_group,
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4f484ac..bf9a680 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -14,7 +14,7 @@ my $V = '0.32';
use Getopt::Long qw(:config no_auto_abbrev);
-my $LINELENGTH=120;
+my $LINELENGTH=80;
my $quiet = 0;
my $tree = 1;
--
1.9.1
--
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 2/2] drm/msm/dsi: One function call less in dsi_init() after error detection
From: Markus Elfring
Date: Sat, 27 Jun 2015 22:23:28 +0200
The dsi_destroy() function was called in two cases by the dsi_init() function
during error handling even if the passed variable contained a null pointer.
* This implementation detail could be improved by adjustments for jump
targets according to the Linux coding style convention.
* Drop an unnecessary initialisation for the variable "msm_dsi" then.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/msm/dsi/dsi.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index dc4f38f..971f000 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -74,19 +74,15 @@ static void dsi_destroy(struct msm_dsi *msm_dsi)
static struct msm_dsi *dsi_init(struct platform_device *pdev)
{
- struct msm_dsi *msm_dsi = NULL;
+ struct msm_dsi *msm_dsi;
int ret;
- if (!pdev) {
- ret = -ENXIO;
- goto fail;
- }
+ if (!pdev)
+ return -ENXIO;
msm_dsi = devm_kzalloc(&pdev->dev, sizeof(*msm_dsi), GFP_KERNEL);
- if (!msm_dsi) {
- ret = -ENOMEM;
- goto fail;
- }
+ if (!msm_dsi)
+ return -ENOMEM;
DBG("dsi probed=%p", msm_dsi);
msm_dsi->pdev = pdev;
@@ -95,21 +91,21 @@ static struct msm_dsi *dsi_init(struct platform_device
*pdev)
/* Init dsi host */
ret = msm_dsi_host_init(msm_dsi);
if (ret)
- goto fail;
+ goto destroy_dsi;
/* GET dsi PHY */
ret = dsi_get_phy(msm_dsi);
if (ret)
- goto fail;
+ goto destroy_dsi;
/* Register to dsi manager */
ret = msm_dsi_manager_register(msm_dsi);
if (ret)
- goto fail;
+ goto destroy_dsi;
return msm_dsi;
-fail:
+destroy_dsi:
dsi_destroy(msm_dsi);
return ERR_PTR(ret);
}
--
2.4.4
--
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 1/2] drm/msm/dsi: Delete an unnecessary check before the function call "dsi_destroy"
From: Markus Elfring Date: Sat, 27 Jun 2015 22:05:31 +0200 The dsi_destroy() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/gpu/drm/msm/dsi/dsi.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c index 1f2561e..dc4f38f 100644 --- a/drivers/gpu/drm/msm/dsi/dsi.c +++ b/drivers/gpu/drm/msm/dsi/dsi.c @@ -110,9 +110,7 @@ static struct msm_dsi *dsi_init(struct platform_device *pdev) return msm_dsi; fail: - if (msm_dsi) - dsi_destroy(msm_dsi); - + dsi_destroy(msm_dsi); return ERR_PTR(ret); } -- 2.4.4 -- 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] clocksource: imx: define clocksource for mx27
On Sat, Jun 27, 2015 at 6:11 PM, Philippe Reynes wrote: > The clocksource imx27 wasn't defined in timer-imx-gpt.c, > so the kernel no longer boot on imx27. Just define > clocksource imx27 as an imx21. > > Signed-off-by: Philippe Reynes Reviewed-by: Fabio Estevam -- 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 2/2] Check tcsetpgrp p is a process group.
This fixes a bug where a process can set the foreground process group to its
pid even if its pid is not a valid pgrp.
Signed-off-by: Patrick Donnelly
---
drivers/tty/tty_io.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 401d05e..c20a2fb 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -2560,9 +2560,11 @@ static int tiocspgrp(struct tty_struct *tty, struct
tty_struct *real_tty, pid_t
{
struct pid *pgrp;
pid_t pgrp_nr;
- int retval = tty_check_change(real_tty);
+ int retval;
unsigned long flags;
+ retval = tty_check_change(real_tty);
+
if (retval == -EIO)
return -ENOTTY;
if (retval)
@@ -2580,6 +2582,10 @@ static int tiocspgrp(struct tty_struct *tty, struct
tty_struct *real_tty, pid_t
retval = -ESRCH;
if (!pgrp)
goto out_unlock;
+ retval = -EINVAL;
+ if (!pid_task(pgrp, PIDTYPE_PGID)) {
+ goto out_unlock;
+ }
retval = -EPERM;
if (session_of_pgrp(pgrp) != task_session(current))
goto out_unlock;
--
Patrick Donnelly
--
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 1/2] Add missing rcu_read_lock for task_pgrp.
Signed-off-by: Patrick Donnelly
---
drivers/tty/tty_io.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 57fc6ee..401d05e 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -388,33 +388,40 @@ EXPORT_SYMBOL_GPL(tty_find_polling_driver);
int tty_check_change(struct tty_struct *tty)
{
unsigned long flags;
+ struct pid *pgrp;
int ret = 0;
if (current->signal->tty != tty)
return 0;
- spin_lock_irqsave(&tty->ctrl_lock, flags);
+ rcu_read_lock();
+ pgrp = task_pgrp(current);
+ spin_lock_irqsave(&tty->ctrl_lock, flags);
if (!tty->pgrp) {
printk(KERN_WARNING "tty_check_change: tty->pgrp == NULL!\n");
- goto out_unlock;
+ goto out_irqunlock;
}
- if (task_pgrp(current) == tty->pgrp)
- goto out_unlock;
spin_unlock_irqrestore(&tty->ctrl_lock, flags);
+
+ if (pgrp == tty->pgrp)
+ goto out_rcuunlock;
if (is_ignored(SIGTTOU))
goto out;
if (is_current_pgrp_orphaned()) {
ret = -EIO;
goto out;
}
- kill_pgrp(task_pgrp(current), SIGTTOU, 1);
+ kill_pgrp(pgrp, SIGTTOU, 1);
+ rcu_read_unlock();
set_thread_flag(TIF_SIGPENDING);
ret = -ERESTARTSYS;
out:
return ret;
-out_unlock:
+out_irqunlock:
spin_unlock_irqrestore(&tty->ctrl_lock, flags);
+out_rcuunlock:
+ rcu_read_unlock();
return ret;
}
--
Patrick Donnelly
--
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 0/2] drm/msm/dsi: Deletion of an unnecessary check
From: Markus Elfring Further update suggestions were taken into account after a patch was applied from static source code analysis. Markus Elfring (2): Delete an unnecessary check before the function call "dsi_destroy" One function call less in dsi_init() after error detection drivers/gpu/drm/msm/dsi/dsi.c | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) -- 2.4.4 -- 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] clocksource: imx: define clocksource for mx27
The clocksource imx27 wasn't defined in timer-imx-gpt.c, so the kernel no longer boot on imx27. Just define clocksource imx27 as an imx21. Signed-off-by: Philippe Reynes --- drivers/clocksource/timer-imx-gpt.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/clocksource/timer-imx-gpt.c b/drivers/clocksource/timer-imx-gpt.c index 879c784..2d59038 100644 --- a/drivers/clocksource/timer-imx-gpt.c +++ b/drivers/clocksource/timer-imx-gpt.c @@ -529,6 +529,7 @@ static void __init imx6dl_timer_init_dt(struct device_node *np) CLOCKSOURCE_OF_DECLARE(imx1_timer, "fsl,imx1-gpt", imx1_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx21_timer, "fsl,imx21-gpt", imx21_timer_init_dt); +CLOCKSOURCE_OF_DECLARE(imx27_timer, "fsl,imx27-gpt", imx21_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx31_timer, "fsl,imx31-gpt", imx31_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx25_timer, "fsl,imx25-gpt", imx31_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx50_timer, "fsl,imx50-gpt", imx31_timer_init_dt); -- 1.7.4.4 -- 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: [all better] Re: regression: massive trouble with fpu rework
On Sat, 27 Jun 2015, Mike Galbraith wrote:
> > > BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily.
>
> That BIOS setting is annotated with the helpful text "Disabled for
> Windows XP". It makes box say interesting things during boot, like...
>
> x86/fpu: XSTATE_CPUID missing!
>
>
> ..or with HEAD, it triggers warning..
>
> if (boot_cpu_data.cpuid_level < XSTATE_CPUID) {
> WARN_ON_FPU(1);
> return;
> }
>
> ..and all kinds of bad juju follows. I have no idea what the thing does
> beyond what I can interpolate from the word 'limit'.
Well, it is supposed to disable CPUID levels >= 0x04. This thing should
*NEVER* be enabled, the last operating system that required it to be enabled
was Windows 98.
Can/do we override that crap during cpu init? If we cannot/don't, maybe
instead of limping along with CPUID crippled, it would be better to either
output a very nasty warning, or outright stop booting [with an appropriate
error message] ?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
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: imx: apf27: the board no longer boot with latest git kernel
Hi Philippe, On Sat, Jun 27, 2015 at 5:38 PM, Philippe Reynes wrote: > I've tested this change, and it works fine. > In the file drivers/clocksource/timer-imx-gpt.c, there is : > #define imx21_gpt_irq_disable imx1_gpt_irq_disable > #define imx21_gpt_irq_enable imx1_gpt_irq_enable > So I think that using imx1 or imx21 has the same result; > > Do you think I should put both change in on patch ? > Or is it better to do two patches please ? I think they should be separate patches. Let's do the following: you sent the drivers/clocksource/timer-imx-gpt.c fix and I will send the dtsi change. Thanks, Fabio Estevam -- 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: imx: apf27: the board no longer boot with latest git kernel
Hi Fabio,
On 27/06/15 21:17, Fabio Estevam wrote:
Philippe,
On Sat, Jun 27, 2015 at 2:34 PM, Fabio Estevam wrote:
Yes, please submit a formal patch.
I thought it was imx1_timer_init_dt because in imx27.dtsi we have:
compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
So I am wondering if this is correct or it should be
compatible = "fsl,imx27-gpt", "fsl,imx21-gpt"; instead?
In addition to the drivers/clocksource/timer-imx-gpt.c patch, could
you also try the change below?
Yes, I do it
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -108,7 +108,7 @@
};
gpt1: timer@10003000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg =<0x10003000 0x1000>;
interrupts =<26>;
clocks =<&clks IMX27_CLK_GPT1_IPG_GATE>,
@@ -117,7 +117,7 @@
};
gpt2: timer@10004000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg =<0x10004000 0x1000>;
interrupts =<25>;
clocks =<&clks IMX27_CLK_GPT2_IPG_GATE>,
@@ -126,7 +126,7 @@
};
gpt3: timer@10005000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg =<0x10005000 0x1000>;
interrupts =<24>;
clocks =<&clks IMX27_CLK_GPT3_IPG_GATE>,
@@ -376,7 +376,7 @@
};
gpt4: timer@10019000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg =<0x10019000 0x1000>;
interrupts =<4>;
clocks =<&clks IMX27_CLK_GPT4_IPG_GATE>,
@@ -385,7 +385,7 @@
};
gpt5: timer@1001a000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg =<0x1001a000 0x1000>;
interrupts =<3>;
clocks =<&clks IMX27_CLK_GPT5_IPG_GATE>,
@@ -436,7 +436,7 @@
};
gpt6: timer@1001f000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg =<0x1001f000 0x1000>;
interrupts =<2>;
clocks =<&clks IMX27_CLK_GPT6_IPG_GATE>,
I've tested this change, and it works fine.
In the file drivers/clocksource/timer-imx-gpt.c, there is :
#define imx21_gpt_irq_disable imx1_gpt_irq_disable
#define imx21_gpt_irq_enable imx1_gpt_irq_enable
So I think that using imx1 or imx21 has the same result;
Do you think I should put both change in on patch ?
Or is it better to do two patches please ?
Regards,
Philippe
--
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] i8042: Add debug_kbd option
Hi,
[no In-Reply-To header - lkml.org "headers" is broken ATM]
> +
> +static bool i8042_debug_kbd;
> +module_param_named(debug_kbd, i8042_debug_kbd, bool, 0600);
> +MODULE_PARM_DESC(i8042_kbd, "Turn i8042 kbd debugging output on or off
> (requires i8042.debug=1)");
seems inconsistent:
i8042_debug_kbd != debug_kbd != i8042_kbd
While the first two seem perfectly fine,
"i8042_kbd" sounds like a build error or similar to me, on the severity front.
(grepping kernel tree drivers/ on quick glance
does not seem to show any naming deviations in the MODULE_PARM_DESC area)
> "Turn i8042 kbd debugging output on or off (requires i8042.debug=1)"
should be improved to
"Turn i8042 kbd debugging output on (requires i8042.debug=1)"
(it *is* default-off)
The point is that it
(at least now that it reached current implementation version?)
merely *enables* additional output,
it does *not* actively *disable* (veto)
something which may have been default-enabled elsewhere.
Also, since this is about "special" situations only
(many standard situations already have this output enabled),
it should be worded to somehow include this "special" enabling.
Also, I'd prefer to also see the *reason*
for it being default-disabled in modinfo output.
Also, "i8042" is useless (since completely scope-superfluous) information
(this *is* i8042 driver)
So perhaps wording in total could be something like
"Turn kbd debugging output unconditionally on (may reveal sensitive data)"
or possibly best
"Unconditional enable (may reveal sensitive data) of normally sanitize-filtered
kbd data traffic log"
and in combination:
"[DESCRIPTION] (pre-condition: i8042.debug=1 enabled)"
"kbd debugging output"
could be shortened to
"kbd debug log"
So, a final suggestion might be:
"Unconditional enable (may reveal sensitive data) of normally sanitize-filtered
kbd data traffic debug log [pre-condition: i8042.debug=1 enabled]"
And given that this description is now completely different,
one might choose to rename debug_kbd variable
to something more specific, too
("debug_full" / "debug_data" / "debug_traffic"?).
> + i8042.debug_kbd [HW] Enable printing of interrupt data from the
> KBD port
> + (disabled by default, requires that
> i8042.debug=1
> + be enabled)
is not correct - code implementation definitely conveys
that it needs to be "*and* requires"
(especially since current wording strongly suggests that
*while it's default-disabled*,
i8042.debug_kbd will be implicitly enabled once i8042.debug=1 is available,
which is wrong).
Perhaps write it as something like
"and as pre-condition requires i8042.debug=1 to be enabled too".
Definitely very good to see this (quote) "big problem" corrected!
Thanks,
Andreas Mohr
--
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] x86: fix -Wsign-compare warnings in uaccess.h
Toralf Förster писал в своём письме Sat, 27 Jun 2015 22:16:27 +0300: The casts are safe, since those conditions are only evaluated when sz >= 0. Wouldn't in this case the condition "sz < 0" be superfluously ? No, sz can be negative. I meant that if sz < 0, then the second halves won't be evaluated (though even if they did, it wouldn't matter). -- 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: imx: apf27: the board no longer boot with latest git kernel
Philippe,
On Sat, Jun 27, 2015 at 2:34 PM, Fabio Estevam wrote:
> Yes, please submit a formal patch.
>
> I thought it was imx1_timer_init_dt because in imx27.dtsi we have:
>
> compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
>
> So I am wondering if this is correct or it should be
>
> compatible = "fsl,imx27-gpt", "fsl,imx21-gpt"; instead?
In addition to the drivers/clocksource/timer-imx-gpt.c patch, could
you also try the change below?
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -108,7 +108,7 @@
};
gpt1: timer@10003000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg = <0x10003000 0x1000>;
interrupts = <26>;
clocks = <&clks IMX27_CLK_GPT1_IPG_GATE>,
@@ -117,7 +117,7 @@
};
gpt2: timer@10004000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg = <0x10004000 0x1000>;
interrupts = <25>;
clocks = <&clks IMX27_CLK_GPT2_IPG_GATE>,
@@ -126,7 +126,7 @@
};
gpt3: timer@10005000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg = <0x10005000 0x1000>;
interrupts = <24>;
clocks = <&clks IMX27_CLK_GPT3_IPG_GATE>,
@@ -376,7 +376,7 @@
};
gpt4: timer@10019000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg = <0x10019000 0x1000>;
interrupts = <4>;
clocks = <&clks IMX27_CLK_GPT4_IPG_GATE>,
@@ -385,7 +385,7 @@
};
gpt5: timer@1001a000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg = <0x1001a000 0x1000>;
interrupts = <3>;
clocks = <&clks IMX27_CLK_GPT5_IPG_GATE>,
@@ -436,7 +436,7 @@
};
gpt6: timer@1001f000 {
-compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg = <0x1001f000 0x1000>;
interrupts = <2>;
clocks = <&clks IMX27_CLK_GPT6_IPG_GATE>,
--
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] x86: fix -Wsign-compare warnings in uaccess.h
>The casts are safe, since those conditions are only evaluated when sz >= 0. Wouldn't in this case the condition "sz < 0" be superfluously ? -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E -- 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 3/4 v13] x86/earlyprintk: setup earlyprintk as early as possible
Hello Andy, 2015-06-28 0:39 GMT+06:00 Andy Shevchenko : > P.S. I guess you may try to submit first something a bit more trivial > that this to train your skills in open source community. You already > have 13 versions of the patch series with some stylistic issues. And > some of them might be due to you pay not much attention on them. This > makes your series quite unlikely to be reviewed and applied. First of all thank you for feedback and for you time. Yes, seems that main problem in my attention. Will I think and reconsider the changes a thousand times before sending it in next time. -- 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/
How to debug reboot/powerdown problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have a new Laptop, a Medion E4214, with a standard xubuntu LTS 14.04 installed. My problem is, that the notebook does neither reboot nor powerdown. It hangs late in the powerdown/reboot sequence, with no error message shown on the console, and I need to hold down the power button for 5s to switch it off hard. I switched off the grub splash screen, to not miss any console messages, I stopped X, network, sound and bluetooth, so that the loaded modules are only (lsmod output): Module Size Used by i915 1146880 1 drm_kms_helper126976 1 i915 drm 352256 3 i915,drm_kms_helper i2c_algo_bit 16384 1 i915 video 28672 1 i915 ahci 36864 2 libahci32768 1 ahci The problem persists, so if it the problem is in one of the drivers, it must be one of the drivers above. I tried to start with the reboot= set to acpi, bios, force or pci, to no avail. Needless to say, that the notebook reboots/powers off when running windows 8.1 The system is mostly intel, ValleyView SoC, with a Realtek Ethernet controller. Here is what lspci has to say: 00:00.0 Host bridge: Intel Corporation ValleyView SSA-CUnit (rev 0e) 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0e) 00:12.0 SD Host controller: Intel Corporation ValleyView SDIO Controller (rev 0e) 00:13.0 SATA controller: Intel Corporation ValleyView 6-Port SATA AHCI Controller (rev 0e) 00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host Controller (rev 0e) 00:17.0 SD Host controller: Intel Corporation ValleyView MIPI-HSI Controller (rev 0e) 00:1a.0 Encryption controller: Intel Corporation ValleyView SEC (rev 0e) 00:1b.0 Audio device: Intel Corporation ValleyView High Definition Audio Controller (rev 0e) 00:1c.0 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e) 00:1c.1 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e) 00:1d.0 USB controller: Intel Corporation ValleyView USB Enhanced Host Controller (rev 0e) 00:1f.0 ISA bridge: Intel Corporation ValleyView Power Control Unit (rev 0e) 00:1f.3 SMBus: Intel Corporation ValleyView SMBus Controller (rev 0e) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) Are there any options for startig / compiling to debug that further? Any tips appreciated. Nils -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVjvHrAAoJEAB3yxxbZhEBI5wP/0nNLm7nANstRO0mqwzZDYFl 1r2iNhJ1HV7yPTCXR/SPnCd8RWG/DIbAMUQlB/BwUaH8qq0LPCS9SLB+1EtNDVpF s7xjRMuSG2HXJWJuQ1uS3TDCv2UYhRZLnklbJn4iYU/0nqkb6aP8rm/EXr03KcT/ QGWktXwG2gzOZskldV4E9RHgErbIwHD+A9VdUdNdU81czCeiCfhJeYpESWu50E+t 9n+GqsSubB1/e97PWnEGstYM4qK13qbZjExa1PXEFfElrniz/FKg0aLIZ4ODGmRD DkFgVtWeN6304GcpZprsQhWc4YzsnJf11JjTFWQKrUiIrmpxq+2T75BeGbCbAJeN pU6AL7IOZFxQnxyISjKXlS1sex/Wh/6ecitMIOtb9N/qbSWzc4ms6kuAs7kIRDYu 0se8i8nLu9ezxpEUsNYNeJpkrhNho0LcZSGiwu6Ahepu+9wjpV/lUfH3FFhkfoIW J8IUE5RiCsM3D+28emOBbEgwBS6NzCE68KnXMBC4a8uGyYA80/UNIcT2b/eX+4RC aG0M6KtTbX80HApHeIR4YlKBH1ByTNhSvp4O7Kcy6jxR8JD4C23+NTspEhC5dND0 xFMrbVOpl5ELUakv2cLDRGeLiA6Zfhg6FwnDmZBW2Dk7hO7FNJ6gi4gjKV1O/XVn bFYbXvfS4oIVKgP05Ouc =slY7 -END PGP SIGNATURE- -- 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] drm/bridge: ps8622: Delete a check before backlight_device_unregister()
From: Markus Elfring
Date: Sat, 27 Jun 2015 20:44:49 +0200
The backlight_device_unregister() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/bridge/ps8622.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index 1a6607b..70dacb8 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -646,9 +646,7 @@ static int ps8622_remove(struct i2c_client *client)
{
struct ps8622_bridge *ps8622 = i2c_get_clientdata(client);
- if (ps8622->bl)
- backlight_device_unregister(ps8622->bl);
-
+ backlight_device_unregister(ps8622->bl);
drm_bridge_remove(&ps8622->bridge);
return 0;
--
2.4.4
--
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 3/4 v13] x86/earlyprintk: setup earlyprintk as early as possible
On Sat, Jun 27, 2015 at 4:48 PM, Alexander Kuleshov
wrote:
> The earlyprintk is usable only after the setup_early_printk will
You might use the standard form of the function representation in the
text, i.e. 'setup_early_printk()' (notice parens at the end of token).
> be executed. We pass 'earlyprintk' through the kernel command line, so it
> will be usable only after the 'parse_early_param' will be executed. This means
> that we have usable earlyprintk only during early boot, kernel decompression
> and after call of the 'parse_early_param', but sometimes it is very useful to
> know what occurs between.
'in between'
> The earlyprintk can allow us to know what occurs after
> kernel decompression and before parse_early_param will be called.
>
> This patch provides following stuff:
'the following'
> 1. Thi patch introduces the setup_earlyprintk_console function,
'This'
> which called arch/x86/kernel/hhead{32,64}.c, parses kernel command line,
'which is called by …head…'
> tries to find 'earlyprintk' option and calls setup_early_printk depending
> on the result.
>
> 2. As setup_earlyprintk_console setups earlyprintk very early, we can't
> use all console devices for now, but only serial and vga. There is
> earlyprintk_late variable which determines ability to setup earlyprintk
> for the certain device.
>
> 3. Call of the lockdep_init added to the arch/x86/kernel/head{32,64}.c
> to prevent call of the register_console before the initialization of lockdep.
> In other way there we will get:
>
> [ 0.00] WARNING: lockdep init error! lock-(console_sem).lock was
> acquiredbefore lockdep_init
> [ 0.00] Call stack leading to lockdep invocation was:
> [ 0.00] [] save_stack_trace+0x2f/0x50
> [ 0.00] [] __lock_acquire+0xa2c/0xf00
> [ 0.00] [] lock_acquire+0xdb/0x2b0
> [ 0.00] [] _raw_spin_lock_irqsave+0x53/0x90
> [ 0.00] [] down+0x16/0x50
> [ 0.00] [] console_lock+0x19/0x60
> [ 0.00] [] register_console+0x116/0x350
> [ 0.00] [] setup_early_printk+0x165/0x467
> [ 0.00] [] setup_early_serial_console+0x56/0x58
> [ 0.00] [] x86_64_start_kernel+0xce/0x110
> [ 0.00] [] 0x
> [ 0.00]
>
> This patch adds lockdep_init to the arch/x86/kernel/head{32,64}.c, but
> not removed it from the init/main.c, because there is a couple of
> architectures
> which have support of the lockdep, but do not call lockdep_init in their
> architecture-dependent code.
>
> 4. As setup_earlyprintk_console can be called twice: from the
> setup_earlyprintk_console and parse_early_param, additional
'from setup_earlyprintk_console()' (no need to have an article).
> check added to the really early consoles.
'is added'
>
> Tested it with qemu, so early_printk() is usable and prints to serial
'Tested with'
> console right after setup_early_printk function called.
>
> We will not see earlyprintk messages in the dmesg buffer, because
> it is too early to initialized log_buf.
>
I'm not a native speaker, so, my recommendation to you is to try to
find a guy who can check your messages before sending 'em out.
> Signed-off-by: Alexander Kuleshov
> ---
> arch/x86/include/asm/setup.h | 6 ++
> arch/x86/kernel/early_printk.c | 42
> +++---
> arch/x86/kernel/head32.c | 8
> arch/x86/kernel/head64.c | 7 +++
> 4 files changed, 56 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
> index 70dfa61..695f251 100644
> --- a/arch/x86/include/asm/setup.h
> +++ b/arch/x86/include/asm/setup.h
> @@ -126,0 +126,0 @@ asmlinkage void __init x86_64_start_kernel(char
> *real_mode);
> asmlinkage void __init x86_64_start_reservations(char *real_mode_data);
> #endif /* __i386__ */
> void __init setup_builtin_cmdline(void);
> +#ifdef CONFIG_EARLY_PRINTK
> +/* used by arch/x86/kernel/head{32,64}.c */
> +extern int __init setup_earlyprintk_console(void);
> +#else
> +static inline int __init setup_earlyprintk_console(void) { return 0; }
> +#endif /* CONFIG_EARLY_PRINTK */
> #endif /* _SETUP */
> #else
> #define RESERVE_BRK(name,sz) \
> diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
> index 89427d8..cc47bce 100644
> --- a/arch/x86/kernel/early_printk.c
> +++ b/arch/x86/kernel/early_printk.c
> @@ -329,6 +329,15 @@ static inline void early_console_register(struct console
> *con, int keep_early)
> register_console(early_console);
> }
>
> +/*
> + * Setup of earlyprintk is probably too early now. The setup_early_printk
> + * can be called from two places:
> from setup_earlyprintk_console and
> + * parse_early_param.
-> funcname1() and funcname2()
> In first case it is too early to setup earlyprintk
> + * for some devices as efi, pciserial and etc., but it can be set for
> + * vga and serial.
> + */
> +static bool earlyprintk_late = 1;
It's a bool! So: true or false (nothing here in cas
Re: [PATCH 1/4] x86/setup: introduce setup_bultin_cmdline
On Sat, Jun 27, 2015 at 4:54 PM, Alexander Kuleshov
wrote:
> sorry, forgot to add version to this patch, please skip this patch.
You may, for example, supply --subject-prefix="PATCH v13" to git
format-patch command to create a nice version token.
One comment below.
>
> 2015-06-27 19:46 GMT+06:00 Alexander Kuleshov :
>> This patch introduces the setup_builtin_cmdline function which appends or
>> overrides boot_command_line with the builtin_cmdline if CONFIG_CMDLINE_BOOL
>> is set.
>>
>> Previously this functional was in the setup_arch, but we need to move
>> it for getting actual command line as early as possible in the
>> arch/x86/kernel/head{32,64}.c for the earlyprintk setup.
I already once wrote you that commit message is not reflecting the
contents of the patch. Please, align, i.e. remove second paragraph and
add a line that there is no functional change.
Please, read carefully what others comment.
>>
>> Signed-off-by: Alexander Kuleshov
>> ---
>> arch/x86/include/asm/setup.h | 2 +-
>> arch/x86/kernel/setup.c | 29 +
>> 2 files changed, 18 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
>> index 11af24e..70dfa61 100644
>> --- a/arch/x86/include/asm/setup.h
>> +++ b/arch/x86/include/asm/setup.h
>> @@ -124,8 +124,8 @@ asmlinkage void __init i386_start_kernel(void);
>> #else
>> asmlinkage void __init x86_64_start_kernel(char *real_mode);
>> asmlinkage void __init x86_64_start_reservations(char *real_mode_data);
>> -
>> #endif /* __i386__ */
>> +void __init setup_builtin_cmdline(void);
>> #endif /* _SETUP */
>> #else
>> #define RESERVE_BRK(name,sz) \
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index d3b95b8..e528f12 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -847,6 +847,22 @@ dump_kernel_offset(struct notifier_block *self,
>> unsigned long v, void *p)
>> return 0;
>> }
>>
>> +void __init setup_builtin_cmdline(void)
>> +{
>> +#ifdef CONFIG_CMDLINE_BOOL
>> +#ifdef CONFIG_CMDLINE_OVERRIDE
>> + strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
>> +#else
>> + if (builtin_cmdline[0]) {
>> + /* append boot loader cmdline to builtin */
>> + strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
>> + strlcat(builtin_cmdline, boot_command_line,
>> COMMAND_LINE_SIZE);
>> + strlcpy(boot_command_line, builtin_cmdline,
>> COMMAND_LINE_SIZE);
>> + }
>> +#endif
>> +#endif
>> +}
>> +
>> /*
>> * Determine if we were loaded by an EFI loader. If so, then we have also
>> been
>> * passed the efi memmap, systab, etc., so we should use these data
>> structures
>> @@ -975,2 +991,2 @@ void __init setup_arch(char **cmdline_p)
>> bss_resource.start = __pa_symbol(__bss_start);
>> bss_resource.end = __pa_symbol(__bss_stop)-1;
>>
>> -#ifdef CONFIG_CMDLINE_BOOL
>> -#ifdef CONFIG_CMDLINE_OVERRIDE
>> - strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
>> -#else
>> - if (builtin_cmdline[0]) {
>> - /* append boot loader cmdline to builtin */
>> - strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
>> - strlcat(builtin_cmdline, boot_command_line,
>> COMMAND_LINE_SIZE);
>> - strlcpy(boot_command_line, builtin_cmdline,
>> COMMAND_LINE_SIZE);
>> - }
>> -#endif
>> -#endif
>> + setup_builtin_cmdline();
>>
>> strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
>> *cmdline_p = command_line;
>> --
>> 2.4.4.410.gc71d752
>>
> --
> 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/
--
With Best Regards,
Andy Shevchenko
--
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: f_op->read seems to be always NULL since Linux 4.1
On Sat, Jun 27, 2015 at 7:32 PM, Andreas Hartmann wrote: > Hello! > > Given is a module like the following snippet running fine w/ Linux 4.0 > and ext4 fs - but doesn't work w/ Linux 4.1 because f->f_op->read is not > defined any more (= NULL). Is this the intended behavior now? See __vfs_read(). Your module most not rely on such internals. -- Thanks, //richard -- 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: platform: x86: Deletion of checks before backlight_device_unregister()
> There is no way for a human being to remember the complete list of > functions with sanity checks and which don't have sanity checks. I understand also this software development challenge. > Markus has introduced quite a few bugs as well I have only found other opinions about specific update suggestions. Which of such "bugs" are real mistakes? Are you looking for a better consensus? > (people have so far managed to catch his bugs before they were committed). Would you like to refer to any concrete software developers? > He so far has resisted any suggestion that he should manually review > his patches before sending them. I am performing source code review to some degree. My approach does partly not fit to your expectations. Regards, Markus -- 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/
f_op->read seems to be always NULL since Linux 4.1
Hello!
Given is a module like the following snippet running fine w/ Linux 4.0
and ext4 fs - but doesn't work w/ Linux 4.1 because f->f_op->read is not
defined any more (= NULL). Is this the intended behavior now?
vfs_read(f, buf, 128, &f->f_pos) works fine.
module.c
#include
#include
#include
#include
int init_module(void)
{
struct file *f;
char buf[128];
mm_segment_t fs;
int i;
int len=128;
for(i=0;if_op->read) {
f->f_op->read(f, buf, len, &f->f_pos);
printk(KERN_INFO "buf:%s\n",buf);
}
else {
printk(KERN_INFO "No read method\n");
}
set_fs(fs);
}
filp_close(f,NULL);
return 0;
}
void cleanup_module(void)
{
printk(KERN_INFO "My module is unloaded\n");
}
---
Makefile:
---
obj-m += module.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
Regards,
Andreas
--
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: drm/mgag200: doesn't work in panic context
On Sat, Jun 27, 2015 at 4:12 PM, Borislav Petkov wrote: > On Sat, Jun 27, 2015 at 03:52:56PM +0200, Daniel Vetter wrote: >> Hm, what do you mean by fixing this in the allocator? I've made some >> rough sketch of the problem space in >> http://www.x.org/wiki/DRMJanitors/ under "Make panic handling work". >> Problem is that the folks which know what to do (drm hackers) have >> zero incentive to fix it (since if you blow up a drm driver any kind >> of fbcon panic handling is hopeless anyway). > > Ok, silly question: switching the GPU output to the simplest, > supported-by-all-GPUs mode before panicking is not that easy too, right? Anything that resembles doing a modeset (and the precise mode is totally irrelevant) will be almost impossible: There's clocks to tune, various links to train, a bunch of sidebind communication and all that takes time, needs to happen in a very precise order and also needs lots of mutexes (crossing subsystems sometimes even) to avoid trampling on maybe the thread that just died and caused the panic. In short you need specially-written codepaths for panic, which means only the most minimal thing has a chance to even work. fbdev/fbcon and the current drm panic handler are anything but that. Doing a full modeset isn't it either. Heck even the just updating the displayed buffer might need massive reconfiguration of the memory fetch watermarks if e.g. the screen is display high bpc yuv and you want to display the rgb fbcon buffer. And if you'd just try to take what's currently being displayed there's the annoying problem that often providing a cpu-contiguous view of that needs a vmalloc area, if not first moving the buffer around a bit in vram with the copy engine. That all involves lots of really complex code. > Or does that mean, one needs to reinit GPU in order to even show > something... If the gpu is runtime suspended, then yes you'd get to even init the entire thing first before you can display anything. fbdev panic handling was designed for a world where you'd bash a few values into a few registers and never wait for the CRTC to reach stable timings and output a useful signal. Which could all happen very much after the kernel made it's dying sigh. Display hw has long stopped being this simple and display drivers also. The only vestige is that we still call the display pipeline object in drm CRTC for cathode ray tube controller ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: [GIT PULL] (xen) stable/for-jens-4.2
On 06/23/2015 06:33 PM, Konrad Rzeszutek Wilk wrote: Hey Jens, Please git pull the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-4.2 in your 'for-4.2/drivers' branch. It is late - for which I am terrible sorry! The patches have been sitting in my branch for two weeks - except the last patch which was a fix and is now part of the branch. Please git pull at your convience. Pulled, thanks. But really, should be sent in before the last -rc of the previous window... Thankfully this isn't that large. -- Jens Axboe -- 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] bdi: Remove "inline" keyword from exported I_BDEV() implementation
On 06/26/2015 05:58 AM, Geert Uytterhoeven wrote:
With gcc 3.4.6/4.1.2/4.2.4 (not with 4.4.7/4.6.4/4.8.4):
CC fs/block_dev.o
include/linux/fs.h:804: warning: ‘I_BDEV’ declared inline after being
called
include/linux/fs.h:804: warning: previous declaration of ‘I_BDEV’ was here
Commit a212b105b07d75b4 ("bdi: make inode_to_bdi() inline") added a
caller of I_BDEV() in a header file, exposing the bogus "inline" on the
exported implementation.
Drop the "inline" keyword to fix this.
Added, thanks.
--
Jens Axboe
--
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] block: fix bogus EFAULT error from SG_IO ioctl
On 06/26/2015 03:44 AM, Paolo Bonzini wrote: Whenever blk_fill_sghdr_rq fails, its errno code is ignored and changed to EFAULT. This can cause very confusing errors: $ sg_persist -k /dev/sda persistent reservation in: pass through os error: Bad address The fix is trivial, just propagate the return value from blk_fill_sghdr_rq. Added, thanks. -- Jens Axboe -- 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: [GIT PULL] Block driver pull request for 4.2
On 06/26/2015 03:20 PM, Davidlohr Bueso wrote: On Thu, 2015-06-25 at 08:37 -0600, Jens Axboe wrote: - Code consolidation and cleanups from Christoph. Andrew, it seems your fix for gcc never went in. I am hitting it in Linus' tree. https://urldefense.proofpoint.com/v1/url?u=http://www.spinics.net/lists/mm-commits/msg111293.html&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=3JMVyziIyZtZ5cv9eWNLwQ%3D%3D%0A&m=%2Bik4Oo0rVdzlSM1PjOl%2BTRY22oM%2Bk3eJbVGPs9yYnks%3D%0A&s=73fcc4527d5299d9bbfa3a09663b2ae753b2a4712a5f4f312e52364a33cdc80a Not sure why Andrew hasn't sent it in yet. Andrew, you planning on doing that, I did see it get queued up? If not, I can funnel it through my tree for 4.2. -- Jens Axboe -- 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: imx: apf27: the board no longer boot with latest git kernel
On Sat, Jun 27, 2015 at 2:26 PM, Philippe Reynes wrote: > I've looked the code in drivers/clocksource/timer-imx-gpt.c, in the > definition > of imx_gpt_type, there is : > GPT_TYPE_IMX21, /* i.MX21/27 */ > > So I've done a little change in your patch, I've used imx21_timer_init_dt > for > imx27 : > > --- a/drivers/clocksource/timer-imx-gpt.c > +++ b/drivers/clocksource/timer-imx-gpt.c > @@ -529,6 +529,7 @@ static void __init imx6dl_timer_init_dt(struct > device_node *np) > CLOCKSOURCE_OF_DECLARE(imx1_timer, "fsl,imx1-gpt", imx1_timer_init_dt); > CLOCKSOURCE_OF_DECLARE(imx21_timer, "fsl,imx21-gpt", imx21_timer_init_dt); > +CLOCKSOURCE_OF_DECLARE(imx27_timer, "fsl,imx27-gpt", imx21_timer_init_dt); > CLOCKSOURCE_OF_DECLARE(imx31_timer, "fsl,imx31-gpt", imx31_timer_init_dt); > CLOCKSOURCE_OF_DECLARE(imx25_timer, "fsl,imx25-gpt", imx31_timer_init_dt); > CLOCKSOURCE_OF_DECLARE(imx50_timer, "fsl,imx50-gpt", imx31_timer_init_dt); > > I've tested it, and it works fine, now my apf27 (imx27) boot without any > issue. > So good catch, thanks a lot for this patch. Excellent :-) > > I may send a patch on lkml if you want. Yes, please submit a formal patch. I thought it was imx1_timer_init_dt because in imx27.dtsi we have: compatible = "fsl,imx27-gpt", "fsl,imx1-gpt"; So I am wondering if this is correct or it should be compatible = "fsl,imx27-gpt", "fsl,imx21-gpt"; instead? Regards, Fabio Estevam -- 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: imx: apf27: the board no longer boot with latest git kernel
Hi Fabio, On 27/06/15 19:05, Fabio Estevam wrote: Hi Philippe, On Sat, Jun 27, 2015 at 10:21 AM, Philippe Reynes wrote: Hi all, I've tested the lastest linus git kernel, and this kernel no longer boot on my armadeus apf27. The last line of the log are (after, the kernel is stalled) : [0.00] CPU identified as i.MX27, silicon rev 2.1 [0.00] Switching to timer-based delay loop, resolution 60ns [0.24] sched_clock: 32 bits at 16MHz, resolution 60ns, wraps every 129171917793ns [0.008172] clocksource mxc_timer1: mask: 0x max_cycles: 0x, max_idle_ns: 114963006693 ns [0.020252] Console: colour dummy device 80x30 [0.024894] Calibrating delay loop (skipped), value calculated using timer frequency.. I've done a bisect and the commit that raise this issue is : db2ae4b4f6b79bd11d6461d41bd0966b0006f20b ARM: imx: provide gpt device specific irq functions Do you also reproduce this issue please ? or may be I've missed to enable an new option ? I don't have access to a mx27 board at the moment, but I am wondering if the change below would fix the problem: I've got one, and I can do the test. --- a/drivers/clocksource/timer-imx-gpt.c +++ b/drivers/clocksource/timer-imx-gpt.c @@ -528,6 +528,7 @@ static void __init imx6dl_timer_init_dt(struct device_node * } CLOCKSOURCE_OF_DECLARE(imx1_timer, "fsl,imx1-gpt", imx1_timer_init_dt); +CLOCKSOURCE_OF_DECLARE(imx27_timer, "fsl,imx27-gpt", imx1_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx21_timer, "fsl,imx21-gpt", imx21_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx31_timer, "fsl,imx31-gpt", imx31_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx25_timer, "fsl,imx25-gpt", imx31_timer_init_dt); I've looked the code in drivers/clocksource/timer-imx-gpt.c, in the definition of imx_gpt_type, there is : GPT_TYPE_IMX21, /* i.MX21/27 */ So I've done a little change in your patch, I've used imx21_timer_init_dt for imx27 : --- a/drivers/clocksource/timer-imx-gpt.c +++ b/drivers/clocksource/timer-imx-gpt.c @@ -529,6 +529,7 @@ static void __init imx6dl_timer_init_dt(struct device_node *np) CLOCKSOURCE_OF_DECLARE(imx1_timer, "fsl,imx1-gpt", imx1_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx21_timer, "fsl,imx21-gpt", imx21_timer_init_dt); +CLOCKSOURCE_OF_DECLARE(imx27_timer, "fsl,imx27-gpt", imx21_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx31_timer, "fsl,imx31-gpt", imx31_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx25_timer, "fsl,imx25-gpt", imx31_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx50_timer, "fsl,imx50-gpt", imx31_timer_init_dt); I've tested it, and it works fine, now my apf27 (imx27) boot without any issue. So good catch, thanks a lot for this patch. I may send a patch on lkml if you want. Regards, Fabio Estevam Regards, Philippe -- 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] GPU-DRM-Exynos: Delete unnecessary checks before two function calls
>> From: Markus Elfring
>> Date: Wed, 4 Feb 2015 21:54:45 +0100
>>
>> The functions phy_power_on() and vunmap() perform also input
>> parameter validation. Thus the test around their calls is not needed.
>>
>> This issue was detected by using the Coccinelle software.
>>
>> Signed-off-by: Markus Elfring
>> ---
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 6 ++
>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
>> 2 files changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 34d46aa..306cf1d 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1057,14 +1057,12 @@ static int exynos_dp_create_connector(struct
>> exynos_drm_display *display,
>>
>> static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>> {
>> -if (dp->phy)
>> -phy_power_on(dp->phy);
>> +phy_power_on(dp->phy);
>> }
>>
>> static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>> {
>> -if (dp->phy)
>> -phy_power_off(dp->phy);
>> +phy_power_off(dp->phy);
>> }
>>
>> static void exynos_dp_poweron(struct exynos_drm_display *display)
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> index e12ea90..0dd448a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> @@ -313,7 +313,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device
>> *dev,
>> struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd->exynos_gem_obj;
>> struct drm_framebuffer *fb;
>>
>> -if (is_drm_iommu_supported(dev) && exynos_gem_obj->buffer->kvaddr)
>> +if (is_drm_iommu_supported(dev))
>> vunmap(exynos_gem_obj->buffer->kvaddr);
>>
>> /* release drm framebuffer and real buffer */
>>
>
> Acked-by: Joonyoung Shim
Do the chances increase to integrate this update suggestion
into another source code repository?
Regards,
Markus
--
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: imx: apf27: the board no longer boot with latest git kernel
Hi Philippe, On Sat, Jun 27, 2015 at 10:21 AM, Philippe Reynes wrote: > Hi all, > > I've tested the lastest linus git kernel, and this kernel > no longer boot on my armadeus apf27. The last line of the > log are (after, the kernel is stalled) : > > [0.00] CPU identified as i.MX27, silicon rev 2.1 > [0.00] Switching to timer-based delay loop, resolution 60ns > [0.24] sched_clock: 32 bits at 16MHz, resolution 60ns, wraps every > 129171917793ns > [0.008172] clocksource mxc_timer1: mask: 0x max_cycles: > 0x, max_idle_ns: 114963006693 ns > [0.020252] Console: colour dummy device 80x30 > [0.024894] Calibrating delay loop (skipped), value calculated using > timer frequency.. > > I've done a bisect and the commit that raise this issue is : > db2ae4b4f6b79bd11d6461d41bd0966b0006f20b > ARM: imx: provide gpt device specific irq functions > > Do you also reproduce this issue please ? or may be I've missed > to enable an new option ? I don't have access to a mx27 board at the moment, but I am wondering if the change below would fix the problem: --- a/drivers/clocksource/timer-imx-gpt.c +++ b/drivers/clocksource/timer-imx-gpt.c @@ -528,6 +528,7 @@ static void __init imx6dl_timer_init_dt(struct device_node * } CLOCKSOURCE_OF_DECLARE(imx1_timer, "fsl,imx1-gpt", imx1_timer_init_dt); +CLOCKSOURCE_OF_DECLARE(imx27_timer, "fsl,imx27-gpt", imx1_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx21_timer, "fsl,imx21-gpt", imx21_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx31_timer, "fsl,imx31-gpt", imx31_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx25_timer, "fsl,imx25-gpt", imx31_timer_init_dt); Regards, Fabio Estevam -- 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] x86: fix -Wsign-compare warnings in uaccess.h
The casts are safe, since those conditions are only evaluated when sz >= 0. Signed-off-by: Роман Донченко --- arch/x86/include/asm/uaccess.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h index a8df874..4c47002 100644 --- a/arch/x86/include/asm/uaccess.h +++ b/arch/x86/include/asm/uaccess.h @@ -714,7 +714,7 @@ copy_from_user(void *to, const void __user *from, unsigned long n) * case, and do only runtime checking for non-constant sizes. */ - if (likely(sz < 0 || sz >= n)) + if (likely(sz < 0 || (unsigned)sz >= n)) n = _copy_from_user(to, from, n); else if(__builtin_constant_p(n)) copy_from_user_overflow(); @@ -732,7 +732,7 @@ copy_to_user(void __user *to, const void *from, unsigned long n) might_fault(); /* See the comment in copy_from_user() above. */ - if (likely(sz < 0 || sz >= n)) + if (likely(sz < 0 || (unsigned)sz >= n)) n = _copy_to_user(to, from, n); else if(__builtin_constant_p(n)) copy_to_user_overflow(); -- 2.3.2 -- 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: Crypto Fixes for 4.2
On Fri, Jun 26, 2015 at 11:56 PM, Herbert Xu wrote: > > So I think Tadeusz's patch is the simplest fix for 4.2. Could you > please test it to see if it makes your warning go away? Seems to silence it here. I get the feeling that the patch is still wrong - why are not the *tests* run at late time when everything is properly set up, rather than forcing ordering at the code init level - but at least I don't see the annoying error, so it's certainly better than it was before. Linus -- 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] agp/intel-gtt: Deletion of unnecessary checks before the function call "pci_dev_put"
> From: Markus Elfring > Date: Wed, 19 Nov 2014 14:24:20 +0100 > > The pci_dev_put() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/char/agp/intel-gtt.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c > index 9a024f8..db5877e 100644 > --- a/drivers/char/agp/intel-gtt.c > +++ b/drivers/char/agp/intel-gtt.c > @@ -1434,10 +1434,8 @@ void intel_gmch_remove(void) > if (--intel_private.refcount) > return; > > - if (intel_private.pcidev) > - pci_dev_put(intel_private.pcidev); > - if (intel_private.bridge_dev) > - pci_dev_put(intel_private.bridge_dev); > + pci_dev_put(intel_private.pcidev); > + pci_dev_put(intel_private.bridge_dev); > intel_private.driver = NULL; > } > EXPORT_SYMBOL(intel_gmch_remove); > Would you like to integrate this update suggestion into a source code repository? Regards, Markus -- 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 PATCH 0/3] restartable sequences: fast user-space percpu critical sections
Let me try to summarize some of the approaches with their pros and cons: --- percpu segment --- This is probably the simplest and might make sense regardless. cmpxchg can be used to do an atomic push onto a linked list. I think that unlocked cmpxchg16b can be used to get an atomic pop. (You'd have the list head pointer next to an auxiliary pointer to the second element in the list, perhaps.) You can also use this for limited forms of speculative locking. Aborting cleanly if your lock is stolen might require the kernel's help, though (you're now on the wrong cpu, so you can't atomically poke the lock variable any more). The ABI is straightforward, and the only limitation on multiple users in the same process is that they need to coordinate their offsets into the percpu segment. --- vdso-provided atomic ops --- This could be quite flexible. The upside is that the ABI would be straightforward (call a function with clearly-specified behavior). The downside is that implementing it well might require percpu segments and a certain amount of coordination, and it requires a function call. One nice thing about doing it in the vdso is that we can change the implementation down the road. --- kernel preemption hooks --- I'm defining a preemption hook as an action taken by the kernel when a user task is preempted during a critical section. As an upside, we get extremely efficient, almost arbitrary percpu operations. We don't need to worry about memory ordering at all, because the whole sequence aborts if anything else might run on the same cpu. Push and pop are both easy. One con is that actually defining where the critical section is might be nasty. If there's a single IP range, then two libraries could fight over it. We could have a variable somewhere that you write to arm the critical section, but that's a bit slower. Another con is that you can't single-step through this type of critical section. It will be preempted every time. --- kernel migration hooks --- I'm not sure either Paul or Mattieu discussed this, but another option would be to have some special handling if a task is migrated during a critical section or to allow a task to prevent migration entirely during a critical section. From the user's point of view, this is weaker than preemption hooks: it's possible to start your critical section, be preempted, and have another thread enter its own critical section, then get rescheduled on the same cpu without aborting. Users would have to use local atomics (like cmpxchg) to make it useful. As a major advantage, single-stepping still works. This shares the coordination downside with preemption hooks (users have to tell the kernel about their critical sections somehow). Push can certainly be implemented using cmpxchg. The gs prefix isn't even needed. Pop might be harder to implement directly without resorting to cmpxchg16b or similar. --- Unnamed trick --- On entry to a critical section, try to take a per-cpu lock that stores the holder's tid. This might require percpu segments. If you get the lock, then start doing your thing. For example, you could pop by reading head->next and writing it back to head. If, however, you miss the lock, then you need to either wait or forcibly abort the lock holder. You could do the latter by sending a signal or possibly using a new syscall that atomically aborts the lock holder and takes the lock. You don't need to wait, though -- all you need to do is queue the signal and, if the lock holder is actually running, wait for signal delivery to start. Thoughts? I personally like the other options better than preemption hooks. I prefer solutions that don't interfere with debugging. --Andy -- 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 2/2] staging: wilc1000: One function call less in mac_ioctl() after error detection
On Sat, 27 Jun 2015, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sat, 27 Jun 2015 16:00:59 +0200
>
> The kfree() function was called in two cases by the mac_ioctl() function
> during error handling even if the passed variable did not contain a pointer
> for a valid data item.
>
> * This implementation detail could be improved by the introduction
> of another jump label.
>
> * Drop an unnecessary initialisation for the variable "buff" then.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/staging/wilc1000/linux_wlan.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/linux_wlan.c
> b/drivers/staging/wilc1000/linux_wlan.c
> index 2aa8d9b..f492310 100644
> --- a/drivers/staging/wilc1000/linux_wlan.c
> +++ b/drivers/staging/wilc1000/linux_wlan.c
> @@ -2351,16 +2351,13 @@ int mac_close(struct net_device *ndev)
>
> int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
> {
> -
> - u8 *buff = NULL;
> + u8 *buff;
> s8 rssi;
> u32 size = 0, length = 0;
> perInterface_wlan_t *nic;
> struct WILC_WFI_priv *priv;
> s32 s32Error = WILC_SUCCESS;
>
> -
> -
Removing these blank lines seems to have nothing to do with the topic of
the patch.
julia
> /* struct iwreq *wrq = (struct iwreq *) req;// tony moved to case
> SIOCSIWPRIV */
> #ifdef USE_WIRELESS
> nic = netdev_priv(ndev);
> @@ -2405,7 +2402,7 @@ int mac_ioctl(struct net_device *ndev, struct ifreq
> *req, int cmd)
> if (copy_to_user(wrq->u.data.pointer, buff,
> size)) {
> PRINT_ER("%s: failed to copy data to
> user buffer\n", __func__);
> s32Error = -EFAULT;
> - goto done;
> + goto free_buffer;
> }
> }
> }
> @@ -2420,8 +2417,9 @@ int mac_ioctl(struct net_device *ndev, struct ifreq
> *req, int cmd)
> }
> }
>
> -done:
> +free_buffer:
> kfree(buff);
> +done:
> return s32Error;
> }
>
> --
> 2.4.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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: [GIT PULL] workqueue changes for v4.2-rc1
On Sat, Jun 27, 2015 at 10:09:28AM +0200, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
> > On Fri, Jun 26, 2015 at 9:01 AM, Tejun Heo wrote:
> > >
> > > Ooh, it isn't in mainline yet but pulling rcu tree will cause a silent
> > > conflict with this pull request which leads to build failure.
> >
> > I tend to try to do a full "make allmodconfig" build between all pull
> > requests (although I can optimize that a bit for very targeted pull
> > requests), so hopefully I'll notice and remember your note.
> >
> > But just in case:
> >
> > > The two colliding commits are.
> > >
> > > 5b95e1af8d17 ("workqueue: wq_pool_mutex protects the attrs-installation")
> > > eeacf8982637 ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
> > >
> > > The former adds rcu_lockdep_assert() usage and the latter renames and
> > > flips
> > > it. It can be resolved by renaming and negating the conditions in the
> > > new
> > > usage.
> >
> > it would be great if when I get the RCU pull request that introduces that
> > renaming, whoever sends it to me could remind me about it.
> >
> > I'm assuming the pull request will come through Ingo. Ingo?
>
> Yeah.
>
> There was some discussion about how to warn about RCU failures precisely, so
> I
> think Paul yanked the new style RCU warnings for the time being. When/if they
> come back I'll be careful and will remind you of semantic conflicts.
Yes, it ended up in the batch destined for v4.3.
If it would make things easier, I could easily introduce the new API in
v4.3, along with the changes visible at that time, and pull the old API
in v4.4. That way, the conflicts appearing in v4.4 could be resolved
in the originating tree, given that the new API would then be in place
everywhere.
Either way works for me, just let me know!
Thanx, Paul
--
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] hwmon: (dell-smm-hwon) Use a valid name attribute
On Saturday 27 June 2015 16:39:09 Guenter Roeck wrote:
> On 06/27/2015 06:22 AM, Gabriele Mazzotta wrote:
> > As per Documentation/hwmon/sysfs-interface, hwmon name attributes
> > must not include '-', so replace 'dell-smm' with 'dell_smm'.
> >
> > Fixes: 039ae58503f3 ("hwmon: Allow to compile dell-smm-hwmon driver
> > without /proc/i8k") Signed-off-by: Gabriele Mazzotta
> >
>
> Applied.
>
> Pali, would be great if you can send me an Acked-by: before I send
> the pull request to Linus.
>
> Thanks,
> Guenter
It's ok,
Acked-by: Pali Rohár
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
[PATCH] ipmi: Delete an unnecessary check before the function call "cleanup_one_si"
From: Markus Elfring
Date: Sat, 27 Jun 2015 18:12:14 +0200
The cleanup_one_si() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/char/ipmi/ipmi_si_intf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index cb90f76..fbfed36 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2778,9 +2778,7 @@ static int ipmi_remove(struct platform_device *dev)
{
struct smi_info *info = dev_get_drvdata(&dev->dev);
- if (info)
- cleanup_one_si(info);
-
+ cleanup_one_si(info);
return 0;
}
--
2.4.4
--
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: [v2,2/3] watchdog: max63xx: add GPIO support
On 06/22/2015 01:43 PM, Vivien Didelot wrote:
Hi Guenter,
On Jun 22, 2015, at 12:53 PM, Guenter Roeck li...@roeck-us.net wrote:
On Wed, Jun 17, 2015 at 06:58:59PM -0400, Vivien Didelot wrote:
Introduce a new struct max63xx_platform_data to support MAX63xx watchdog
chips connected via GPIO. A platform code can fill this structure with
GPIO numbers for WDI and WDSET pins to enable GPIO support in the code.
The driver takes care of requesting and releasing the GPIOs.
Signed-off-by: Vivien Didelot
would it be possible to use gpiod functions ?
It might be, but I never played with it yet though. I'm using integer-based
GPIOs from a TCA6424 on an x86 platform (no Device Tree). Is it ok to keep
max63xx_gpio_{ping,set} for legacy GPIOs, and let someone add
max63xx_gpiod_{ping,set} if there is a need?
Hi Vivien,
That would pretty much defeat the purpose. The gpiod API is supposed
to replace the gpio API, not to augment it. Having both at the same time
does not really make sense.
There is a mapping from integer based pins to name based pins; check out
gpiod_add_lookup_table(). Essentially platform initialization code
(in your case probably the code which instantiates the tca6424) would
set up a pin lookup table, and then you would request pins using
a name instead of a number. That would also solve the "is the pin
valid" problem in patch 3/3 since you would have a string to identify
the gpio pin.
Thanks,
Guenter
--
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: [GIT PULL] workqueue changes for v4.2-rc1
On Sat, Jun 27, 2015 at 02:35:56PM +1000, Stephen Rothwell wrote:
> Hi Linus,
>
> On Fri, 26 Jun 2015 20:18:10 -0700 Linus Torvalds
> wrote:
> >
> > On Fri, Jun 26, 2015 at 9:01 AM, Tejun Heo wrote:
> > >
> > > Ooh, it isn't in mainline yet but pulling rcu tree will cause a silent
> > > conflict with this pull request which leads to build failure.
> >
> > I tend to try to do a full "make allmodconfig" build between all pull
> > requests (although I can optimize that a bit for very targeted pull
> > requests), so hopefully I'll notice and remember your note.
> >
> > But just in case:
> >
> > > The two colliding commits are.
> > >
> > > 5b95e1af8d17 ("workqueue: wq_pool_mutex protects the attrs-installation")
> > > eeacf8982637 ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
> > >
> > > The former adds rcu_lockdep_assert() usage and the latter renames and
> > > flips it. It can be resolved by renaming and negating the conditions
> > > in the new usage.
> >
> > it would be great if when I get the RCU pull request that introduces
> > that renaming, whoever sends it to me could remind me about it.
>
> I was wondering why I didn't see that in linux-next ... turns out I
> did, but that rcu commit vanished after June 23 ... I have no idea
> where it went, but it has not been in the last 3 -next releases.
On that date, I moved my rcu/next branch to the commit that I sent to
Ingo in my pull request for the current merge window. As I understand
it, during the merge window, I am not supposed to advertise commits
to -next that are not destined for that merge window. When the merge
window closes, I will rebase the rest of the RCU commits to v4.2-rc1,
at which point an updated version of that commit will reappear.
> If it turns up again, this is the merge fix patch I was using:
Thank you, I will include this.
Thanx, Paul
> From: Stephen Rothwell
> Date: Sat, 20 Jun 2015 19:39:43 +1000
> Subject: [PATCH] workqueue: fix up for rcu_lockdep_assert() rename
>
> Signed-off-by: Stephen Rothwell
> ---
> kernel/workqueue.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 837427cc5bdf..44cd4144ebcb 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -348,10 +348,10 @@ static void workqueue_sysfs_unregister(struct
> workqueue_struct *wq);
>"sched RCU or wq->mutex should be held")
>
> #define assert_rcu_or_wq_mutex_or_pool_mutex(wq) \
> - rcu_lockdep_assert(rcu_read_lock_sched_held() ||\
> -lockdep_is_held(&wq->mutex) || \
> -lockdep_is_held(&wq_pool_mutex), \
> -"sched RCU, wq->mutex or wq_pool_mutex should be
> held")
> + RCU_LOCKDEP_WARN(!rcu_read_lock_sched_held() && \
> + !lockdep_is_held(&wq->mutex) &&\
> + !lockdep_is_held(&wq_pool_mutex), \
> + "sched RCU, wq->mutex or wq_pool_mutex should be held")
>
> #define for_each_cpu_worker_pool(pool, cpu) \
> for ((pool) = &per_cpu(cpu_worker_pools, cpu)[0]; \
> --
> 2.1.4
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
--
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/
buongiorno
Salve
moto, mac Laptop, Kamera, Telefon
samsung 6, € 320
w eb: isgayre. com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 3/4] blk-mq: establish new mapping before cpu starts handling requests
On Sat, Jun 27, 2015 at 1:14 AM, Akinobu Mita wrote:
> Akinobu Mita wrote:
>> 2015-06-26 0:40 GMT+09:00 Ming Lei :
>> > On Thu, 25 Jun 2015 21:49:43 +0900
>> > Akinobu Mita wrote:
>> >> For example, there is a single hw queue (hctx) and two CPU queues
>> >> (ctx0 for CPU0, and ctx1 for CPU1). Now CPU1 is just onlined and
>> >> a request is inserted into ctx1->rq_list and set bit0 in pending
>> >> bitmap as ctx1->index_hw is still zero.
>> >>
>> >> And then while running hw queue, flush_busy_ctxs() finds bit0 is set
>> >> in pending bitmap and tries to retrieve requests in
>> >> hctx->ctxs[0].rq_list. But htx->ctxs[0] is ctx0, so the request in
>> >> ctx1->rq_list is ignored.
>> >
>> > Per current design, the request should have been inserted into ctx0 instead
>> > of ctx1 because ctx1 isn't mapped yet even though ctx1->cpu becomes ONLINE.
>> >
>> > So how about the following patch? which looks much simpler.
>>
>> OK, I'll try this patch to see if the problem disappears.
>
> This doesn't fix the problem. Because:
>
>> > diff --git a/block/blk-mq.c b/block/blk-mq.c
>> > index f537796..2f45b73 100644
>> > --- a/block/blk-mq.c
>> > +++ b/block/blk-mq.c
>> > @@ -1034,7 +1034,12 @@ void blk_mq_insert_request(struct request *rq, bool
>> > at_head, bool run_queue,
>> > struct blk_mq_ctx *ctx = rq->mq_ctx, *current_ctx;
>> >
>> > current_ctx = blk_mq_get_ctx(q);
>> > - if (!cpu_online(ctx->cpu))
>> > + /*
>> > +* ctx->cpu may become ONLINE but ctx hasn't been mapped to
>> > +* hctx yet because there is a tiny race window between
>> > +* ctx->cpu ONLINE and doing the remap
>> > +*/
>> > + if (!blk_mq_ctx_mapped(ctx))
>> > rq->mq_ctx = ctx = current_ctx;
>
> The process running on just onlined CPU1 in the above example can
> satisfy this condition and current_ctx will be ctx1. So the same
> scenario can happen (the request is ignored by flush_busy_ctxs).
Yeah, that is possible, and it should be bug of blk_mq_insert_request(),
because the function supposes that the current ctx is mapped.
Then I think the approach in your 1st email of this thread may be
good one, and looks we have to make the remapping during
CPU UP_PREPARE notifier.
>
> I found simple alternative solution that assigns the offline CPUs
> unique ctx->index_hw.
This solution looks simpler, but it may not be correct.
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 594eea0..a8fcfbf 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1787,10 +1787,11 @@ static void blk_mq_map_swqueue(struct
> request_queue *q)
> */
> queue_for_each_ctx(q, ctx, i) {
> /* If the cpu isn't online, the cpu is mapped to first hctx */
> - if (!cpu_online(i))
> - continue;
> + if (!cpu_online(i) && cpu_possible(i))
The cpu_possible() check isn't needed.
> + hctx = q->mq_ops->map_queue(q, 0);
> + else
> + hctx = q->mq_ops->map_queue(q, i);
The above change supposes that all offline CPUs(ctxs)
share the same 'hctx' mapped from CPU 0, and that is
obvious wrong.
All offline CPUs should have shared the 1st 'hctx' instead
of the 'hctx' mapped from CPU 0.
>
> - hctx = q->mq_ops->map_queue(q, i);
> cpumask_set_cpu(i, hctx->cpumask);
CPU i shouldn't have been set on hctx->cpumask in this approach
if it isn't online.
>ctx->index_hw = hctx->nr_ctx;
>hctx->ctxs[hctx->nr_ctx++] = ctx;
I am not sure the current code is ready about adding offline 'ctx' into
'hctx', and there are some observalbe effects at least:
- blk_mq_run_hw_queue() can run even the hctx hasn't mapped
'ctx'
- the offline ctx kobject will be exposed to user space in sysfs
- blk_mq_hw_queue_mapped() may becomes always true
- set->tags[i](request entries) may not be freed even if there
aren't mapped 'ctx' in one 'hctx'
--
Ming Lei
--
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] x86, msr: Allow read access to /dev/cpu/X/msr
On Sat, Jun 27, 2015 at 1:39 AM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>> So what's wrong with exposing them as a simplified PMU driver?
>>
>> That way we only expose the ones we want to - plus tooling can use all the
>> rich
>> perf features that can be used around this. (sampling, counting, call chains,
>> etc.)
>
> See below code from Andy that exposes a single MSR via perf. At the core of
> the
> PMU driver is a single rdmsrl():
>
> +static void aperfmperf_event_start(struct perf_event *event, int flags)
> +{
> + u64 now;
> +
> + rdmsrl(event->hw.event_base, now);
> + local64_set(&event->hw.prev_count, now);
> +}
>
> Now I think what we really want is to expose not a single MSR but multiple
> MSRs in
> a single driver, i.e. don't have one PMU driver per MSR, but have a driver
> that
> allows the exposure of select MSRs as counters.
I'm way ahead of you: this driver can expose *two* MSRs as counters :)
Seriously, though, it would be straightforward to make it handle a
more general list, complete with non-architectural stuff (such as the
upcoming PPERF in Skylake).
This driver only knows how to handle counters, though. I'm not sure
whether all of the MSRs that turbostat needs are counters.
--Andy
--
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/
