Re: [PATCH V2 6/6] vhost_net: correctly limit the max pending buffers
On Fri, Aug 30, 2013 at 12:29:22PM +0800, Jason Wang wrote:
> As Michael point out, We used to limit the max pending DMAs to get better
> cache
> utilization. But it was not done correctly since it was one done when there's
> no
> new buffers submitted from guest. Guest can easily exceeds the limitation by
> keeping sending packets.
>
> So this patch moves the check into main loop. Tests shows about 5%-10%
> improvement on per cpu throughput for guest tx. But a 5% drop on per cpu
> transaction rate for a single session TCP_RR.
Any explanation for the drop? single session TCP_RR is unlikely to
exceed VHOST_MAX_PEND, correct?
>
> Signed-off-by: Jason Wang
> ---
> drivers/vhost/net.c | 15 ---
> 1 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index d09c17c..592e1f2 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -363,6 +363,10 @@ static void handle_tx(struct vhost_net *net)
> if (zcopy)
> vhost_zerocopy_signal_used(net, vq);
>
> + if ((nvq->upend_idx + vq->num - VHOST_MAX_PEND) % UIO_MAXIOV ==
> + nvq->done_idx)
> + break;
> +
> head = vhost_get_vq_desc(>dev, vq, vq->iov,
>ARRAY_SIZE(vq->iov),
>, ,
> @@ -372,17 +376,6 @@ static void handle_tx(struct vhost_net *net)
> break;
> /* Nothing new? Wait for eventfd to tell us they refilled. */
> if (head == vq->num) {
> - int num_pends;
> -
> - /* If more outstanding DMAs, queue the work.
> - * Handle upend_idx wrap around
> - */
> - num_pends = likely(nvq->upend_idx >= nvq->done_idx) ?
> - (nvq->upend_idx - nvq->done_idx) :
> - (nvq->upend_idx + UIO_MAXIOV -
> - nvq->done_idx);
> - if (unlikely(num_pends > VHOST_MAX_PEND))
> - break;
> if (unlikely(vhost_enable_notify(>dev, vq))) {
> vhost_disable_notify(>dev, vq);
> continue;
> --
> 1.7.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: [PATCH V2 1/6] vhost_net: make vhost_zerocopy_signal_used() returns void
tweak subj s/returns/return/
On Fri, Aug 30, 2013 at 12:29:17PM +0800, Jason Wang wrote:
> None of its caller use its return value, so let it return void.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vhost/net.c |5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 969a859..280ee66 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -276,8 +276,8 @@ static void copy_iovec_hdr(const struct iovec *from,
> struct iovec *to,
> * of used idx. Once lower device DMA done contiguously, we will signal KVM
> * guest used idx.
> */
> -static int vhost_zerocopy_signal_used(struct vhost_net *net,
> - struct vhost_virtqueue *vq)
> +static void vhost_zerocopy_signal_used(struct vhost_net *net,
> +struct vhost_virtqueue *vq)
> {
> struct vhost_net_virtqueue *nvq =
> container_of(vq, struct vhost_net_virtqueue, vq);
> @@ -297,7 +297,6 @@ static int vhost_zerocopy_signal_used(struct vhost_net
> *net,
> }
> if (j)
> nvq->done_idx = i;
> - return j;
> }
>
> static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success)
> --
> 1.7.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: [PATCH V2 2/6] vhost_net: use vhost_add_used_and_signal_n() in vhost_zerocopy_signal_used()
On Fri, Aug 30, 2013 at 12:29:18PM +0800, Jason Wang wrote:
> We tend to batch the used adding and signaling in vhost_zerocopy_callback()
> which may result more than 100 used buffers to be updated in
> vhost_zerocopy_signal_used() in some cases. So wwitch to use
switch
> vhost_add_used_and_signal_n() to avoid multiple calls to
> vhost_add_used_and_signal(). Which means much more less times of used index
> updating and memory barriers.
pls put info on perf gain in commit log too
>
> Signed-off-by: Jason Wang
> ---
> drivers/vhost/net.c | 13 -
> 1 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 280ee66..8a6dd0d 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -281,7 +281,7 @@ static void vhost_zerocopy_signal_used(struct vhost_net
> *net,
> {
> struct vhost_net_virtqueue *nvq =
> container_of(vq, struct vhost_net_virtqueue, vq);
> - int i;
> + int i, add;
> int j = 0;
>
> for (i = nvq->done_idx; i != nvq->upend_idx; i = (i + 1) % UIO_MAXIOV) {
> @@ -289,14 +289,17 @@ static void vhost_zerocopy_signal_used(struct vhost_net
> *net,
> vhost_net_tx_err(net);
> if (VHOST_DMA_IS_DONE(vq->heads[i].len)) {
> vq->heads[i].len = VHOST_DMA_CLEAR_LEN;
> - vhost_add_used_and_signal(vq->dev, vq,
> - vq->heads[i].id, 0);
> ++j;
> } else
> break;
> }
> - if (j)
> - nvq->done_idx = i;
> + while (j) {
> + add = min(UIO_MAXIOV - nvq->done_idx, j);
> + vhost_add_used_and_signal_n(vq->dev, vq,
> + >heads[nvq->done_idx], add);
> + nvq->done_idx = (nvq->done_idx + add) % UIO_MAXIOV;
> + j -= add;
> + }
> }
>
> static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success)
> --
> 1.7.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: [PATCH] Remove support for score architecture
On 09/01/2013 09:13 PM, Lennox Wu wrote: Dear all, Indeed, Sunplus S+core is not a popular architecture and there is no standalone to be sold so you should not find related news on the Internet. However, the s+core is adopted by our SoCs and these SoCs are indeed adopted by some companies, we hope the architecture can be reserved to provide the more and more powerful Linux for our customers. It is true that we rarely update the code because that we are rarely requested to add new functions and to correct bugs by our customers, and it is also because we have no new product to release. In the near future, we will release some patches for the existed S+core architecture. Key question is not if the platform is popular, but if it is maintained. The commit log over the last two years strongly suggests that this is not the case. I suspect that the code is far from compilable at this point, much less executable. Unfortunately this is hard to verify, as a pre-built or even buildable toolchain is not easily available. From a company perspective, you might want to decide if you want to put resources into this architecture to keep it alive, or focus on more recent chips and architectures. Information available on the internet suggests that Suncore's more recent chips are based on ARM. Given that, it appears somewhat unlikely that resources for maintaining S+core will be made available. Guess we'll see if the situation changes. Guenter 2013/8/31 Guenter Roeck : The web site associated with the score architecture in MAINTAINERS is non-functional and available for sale. The last Ack from one of the maintainers was in December 2012. The main maintainer's last commit was in 2011. The last maintainer pull request was early 2011. Cc: Lennox Wu Cc: Chen Liqin Signed-off-by: Guenter Roeck --- More housekeeping. Maybe this removal request is a bit early, but architecture support seems to have vanished entirely. At the very least this puts interested parties (if there are any) on notice. -- 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 3/3] dma: Add Freescale eDMA engine driver support
On Thu, Aug 29, 2013 at 03:32:04AM +, Lu Jingchang-B35083 wrote:
Please use a right MUA and wrap your lines at 80chars...
>
> >
> > > + return -EINVAL;
> > > + }
> > > + return 0;
> > > +
> > > + default:
> > > + return -ENXIO;
> > > + }
> > > +}
> > > +
> > > +static enum dma_status fsl_edma_tx_status(struct dma_chan *chan,
> > > + dma_cookie_t cookie, struct dma_tx_state *txstate)
> > > +{
> > > + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> > > +
> > > + if (fsl_chan->status == DMA_ERROR)
> > > + return DMA_ERROR;
> > > +
> > > + return dma_cookie_status(chan, cookie, txstate);
> > this will tell if the DMA is completed or not only.
> > You also need to calculate residue for the pending dma
> >
> > Since you support cyclic this should be done properly...
> >
> > also you cna take more help from vchan support to make your life
> > simpler...
> [Lu Jingchang]
No need to put your name :)
> Ok, if it is needed, I will add residue calculation in the next version.
Yes this is needed
> > > +static bool fsl_edma_filter_fn(struct dma_chan *chan, void *fn_param)
> > > +{
> > > + struct fsl_edma_filter_param *fparam = fn_param;
> > > + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> > > +
> > > + if (fsl_chan->edmamux->mux_id != fparam->mux_id)
> > > + return false;
> > > +
> > > + fsl_chan->slot_id = fparam->slot_id;
> > > + chan->private = fn_param;
> > why do you need to use chan->private?
> [Lu Jingchang]
> The private used here is to store the slot_id information, which must be used
> by the DMAMUX in alloc_chan_resources function. Thanks.
Why dont you pass this in struct dma_slave_config memeber slave_id for this.
>
> > > + return true;
> > > +}
> > > +
> > > +static struct dma_chan *fsl_edma_xlate(struct of_phandle_args
> > *dma_spec,
> > > + struct of_dma *ofdma)
> > > +{
> > > + dma_cap_mask_t mask;
> > > + struct fsl_edma_filter_param fparam;
> > > +
> > > + if (dma_spec->args_count != 2)
> > > + return NULL;
> > > +
> > > + fparam.mux_id = dma_spec->args[0];
> > > + fparam.slot_id = dma_spec->args[1];
> > > +
> > > + dma_cap_zero(mask);
> > > + dma_cap_set(DMA_SLAVE, mask);
> > > + dma_cap_set(DMA_CYCLIC, mask);
> > > + return dma_request_channel(mask, fsl_edma_filter_fn, (void
> > *));
> > > +}
> > > +
> > > +static int fsl_edma_alloc_chan_resources(struct dma_chan *chan)
> > > +{
> > > + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> > > + struct fsl_edma_filter_param *data = chan->private;
> > > + unsigned char val;
> > > +
> > > + val = EDMAMUX_CHCFG_ENBL | EDMAMUX_CHCFG_SOURCE(data->slot_id);
> > okay, so what does the slot_id mean?
> >
> [Lu Jingchang]
> slot_id is the request source id, a peripheral device ID. Each peripheral
> using DMA has a ID that can be identified by the DMA engine. the peripheral ID
> must be written to the DMAMUX configuration register to route the peripheral
> to DMA engine channel. Thanks.
And thanks makes me belive you dont need this way, slave_id is the thing for
you...
~Vinod
--
--
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 0/10] Add additional security checks when module loading is restricted
於 三，2013-08-28 於 16:07 -0700，Kees Cook 提到： > On Wed, Aug 28, 2013 at 3:58 PM, Lenny Szubowicz wrote: > > > > > > - Original Message - > >> From: "Matthew Garrett" > >> To: "Lenny Szubowicz" > >> Cc: linux-kernel@vger.kernel.org, linux-...@vger.kernel.org, > >> jwbo...@redhat.com, keesc...@chromium.org > >> Sent: Wednesday, August 28, 2013 6:41:55 PM > >> Subject: Re: [PATCH 0/10] Add additional security checks when module > >> loading is restricted > >> > >> On Wed, 2013-08-28 at 18:37 -0400, Lenny Szubowicz wrote: > >> > >> > Did you purposely exclude similar checks for hibernate that were covered > >> > by earlier versions of your patch set? > >> > >> Yes, I think it's worth tying it in with the encrypted hibernation > >> support. The local attack is significantly harder in the hibernation > >> case - in the face of unknown hardware it basically involves a > >> pre-generated memory image corresponding to your system or the ability > >> to force a reboot into an untrusted environment. I think it's probably > >> more workable to just add a configuration option for forcing encrypted > >> hibernation when secure boot is in use. > >> > >> -- > >> Matthew Garrett > > > > I'm root. So I can write anything I want to the swap file that looks > > like a valid hibernate image but is code of my choosing. I can read > > anything I need from /dev/mem or /dev/kmem to help me do that. > > I can then immediately initiate a reboot. > > Strictly speaking, RAM contents are not available via /dev/*mem, even > to root. However, you can request a suspend image be written, but to > not enter hibernation. Then modify the image, and request a resume > from it. > > -Kees > I agreed! As a userland hibernate tool, it possible trigger kernel to generate a snapshot image of current memory, read the snapshot, modify and upload it back to the temporary memory space of snapshot, trigger S4 resume to restore it. The signature check of S4 snapshot can prevent this attack because the patches put the signature of snapshot image to snapshot header. Even attacker change the signature of header or modified the data page in snapshot. The modified snapshot image will not pass by signature check. Thanks a lot! Joey Lee -- 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: ipc-msg broken again on 3.11-rc7?
On 08/31/2013 11:20 PM, Linus Torvalds wrote: > Vineet, actual patch for what Davidlohr suggests attached. Can you try it? > > Linus Apologies for late in getting back to this - I was away from my computer for a bit. Unfortunately, with a quick test, this patch doesn't help. FWIW, this is latest mainline (.config attached). Let me know what diagnostics I can add to help with this. -Vineet > > On Fri, Aug 30, 2013 at 9:31 AM, Davidlohr Bueso wrote: >> After a quick glance, I suspect that the problem might be because we >> are calling security_msg_queue_msgsnd() without taking the lock. This >> is similar to the issue Sedat reported in the original thread with >> find_msg() concerning msgrcv. # # Automatically generated file; DO NOT EDIT. # Linux/arc 3.11.0-rc7 Kernel Configuration # CONFIG_ARC=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_GENERIC_CSUM=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_MMU=y CONFIG_NO_IOPORT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HWEIGHT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y # CONFIG_NO_DMA is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="arc-linux-uclibc-" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_DEFAULT_HOSTNAME="ARCLinux" # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_FHANDLE is not set # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_BOOST is not set # CONFIG_RCU_NOCB_CPU is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_IPC_NS=y # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_NET_NS=y CONFIG_UIDGID_CONVERTED=y # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="../arc_initramfs/" CONFIG_INITRAMFS_ROOT_UID=0 CONFIG_INITRAMFS_ROOT_GID=0 CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set # CONFIG_RD_LZO is not set # CONFIG_RD_LZ4 is not set CONFIG_INITRAMFS_COMPRESSION_NONE=y # CONFIG_INITRAMFS_COMPRESSION_GZIP is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EXPERT=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # # CONFIG_PERF_EVENTS is not set CONFIG_VM_EVENT_COUNTERS=y # CONFIG_SLUB_DEBUG is not set # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_SLUB_CPU_PARTIAL=y # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_MODULES_USE_ELF_RELA=y CONFIG_CLONE_BACKWARDS=y # # GCOV-based kernel profiling # # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set # CONFIG_MODULE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_MODULE_SIG is not set CONFIG_BLOCK=y # CONFIG_LBDAF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_EFI_PARTITION=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_NOOP=y CONFIG_DEFAULT_IOSCHED="noop" CONFIG_UNINLINE_SPIN_UNLOCK=y # CONFIG_FREEZER is not set # # ARC
Re: device_create_file returns 0 but doesn't work
On 09/01/2013 06:38 PM, Ian Pilcher wrote:
> I am trying to add an additional sysfs attribute to a device (LED) that
> is created by another driver. (My ultimate goal is to provide a way for
> a userspace application to use the functionality provided by
> led_blink_set, which doesn't currently seem to be possible.)
Turns out it is possible, with the LED timer trigger, so this issue is
now moot.
>
> The kernel module code that sets up all the GPIOs & LEDs in my NAS is
> at:
>
> http://pastebin.com/TJZGww8T
>
> The call to device_create_file is at line 373.
>
> device_create_file is returning 0, but the "foo" attribute is not being
> created. ("find /sys -name '*foo*'" doesn't find anything, so I'm not
> just looking in the wrong place.)
Still rather odd that it doesn't work, however, since ledtrig-timer.c
seems to do pretty much the same thing. Oh well.
--
Ian Pilcher arequip...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
--
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 6/6] ACPI / processor: Remove outdated comments
acpi_get_processor_id() can be find nowhere, and the acpi id
is synchronized to APIC id when acpi_get_cpuid() is called, so
the comments can be removed.
Signed-off-by: Hanjun Guo
---
drivers/acpi/acpi_processor.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 7ce0750..da42892 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -240,11 +240,6 @@ static int acpi_processor_get_info(struct acpi_device
*device)
return -ENODEV;
}
- /*
-* TBD: Synch processor ID (via LAPIC/LSAPIC structures) on SMP.
-* >>> 'acpi_get_processor_id(acpi_id, )' in
-* arch/xxx/acpi.c
-*/
pr->acpi_id = object.processor.proc_id;
} else {
/*
--
1.7.9.5
--
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 5/6] ACPI / processor: remove unnecessary if (!pr) check
acpi_processor_errata() is only called in acpi_processor_get_info(),
and the argument 'pr' passed to acpi_processor_errata() will never be
NULL, so the if (!pr) check is unnecessary and can be removed.
Since the 'pr' argument is not used by acpi_processor_errata() any more,
so change the argument into void too.
Signed-off-by: Hanjun Guo
---
drivers/acpi/acpi_processor.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 5364d02..7ce0750 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -140,15 +140,11 @@ static int acpi_processor_errata_piix4(struct pci_dev
*dev)
return 0;
}
-static int acpi_processor_errata(struct acpi_processor *pr)
+static int acpi_processor_errata(void)
{
int result = 0;
struct pci_dev *dev = NULL;
-
- if (!pr)
- return -EINVAL;
-
/*
* PIIX4
*/
@@ -220,7 +216,7 @@ static int acpi_processor_get_info(struct acpi_device
*device)
acpi_status status = AE_OK;
static int cpu0_initialized;
- acpi_processor_errata(pr);
+ acpi_processor_errata();
/*
* Check to see if we have bus mastering arbitration control. This
--
1.7.9.5
--
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 4/6] ACPI / processor: remove some dead code in acpi_processor_get_info()
From: Jiang Liu errata.smp is used by nowhere, so the variable assignment is meanless, remove it. Signed-off-by: Jiang Liu Signed-off-by: Hanjun Guo --- drivers/acpi/acpi_processor.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 66c9b70..5364d02 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -220,9 +220,6 @@ static int acpi_processor_get_info(struct acpi_device *device) acpi_status status = AE_OK; static int cpu0_initialized; - if (num_online_cpus() > 1) - errata.smp = TRUE; - acpi_processor_errata(pr); /* -- 1.7.9.5 -- 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] rtl8187: fix use after free on failure path in rtl8187_init_urbs()
On 01.09.2013 10:51, Hin-Tak Leung wrote:
--
On Sat, Aug 31, 2013 22:18 BST Alexey Khoroshilov wrote:
In case of __dev_alloc_skb() failure rtl8187_init_urbs()
calls usb_free_urb(entry) where 'entry' can points to urb
allocated at the previous iteration. That means refcnt will be
decremented incorrectly and the urb can be used after memory
deallocation.
The patch fixes the issue and implements error handling of init_urbs
in rtl8187_start().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/net/wireless/rtl818x/rtl8187/dev.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c
b/drivers/net/wireless/rtl818x/rtl8187/dev.c
index f49220e..e83d53c 100644
--- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
@@ -438,17 +438,16 @@ static int rtl8187_init_urbs(struct ieee80211_hw *dev)
skb_queue_tail(>rx_queue, skb);
usb_anchor_urb(entry, >anchored);
ret = usb_submit_urb(entry, GFP_KERNEL);
+usb_free_urb(entry);
if (ret) {
skb_unlink(skb, >rx_queue);
usb_unanchor_urb(entry);
goto err;
}
-usb_free_urb(entry);
}
return ret;
err:
-usb_free_urb(entry);
kfree_skb(skb);
usb_kill_anchored_urbs(>anchored);
return ret;
This part looks wrong - you free_urb(entry) then unanchor_urb(entry).
I do not see any problems here.
usb_free_urb() just decrements refcnt of the urb.
While usb_anchor_urb() and usb_unanchor_urb() increment and decrement it
as well.
So actual memory deallocation will happen in usb_unanchor_urb().
@@ -956,8 +955,12 @@ static int rtl8187_start(struct ieee80211_hw *dev)
(RETRY_COUNT < 8 /* short retry limit */) |
(RETRY_COUNT < 0 /* long retry limit */) |
(7 < 21 /* MAX TX DMA */));
-rtl8187_init_urbs(dev);
-rtl8187b_init_status_urb(dev);
+ret = rtl8187_init_urbs(dev);
+if (ret)
+goto rtl8187_start_exit;
+ret = rtl8187b_init_status_urb(dev);
+if (ret)
+usb_kill_anchored_urbs(>anchored);
goto rtl8187_start_exit;
}
@@ -966,7 +969,9 @@ static int rtl8187_start(struct ieee80211_hw *dev)
rtl818x_iowrite32(priv, >map->MAR[0], ~0);
rtl818x_iowrite32(priv, >map->MAR[1], ~0);
-rtl8187_init_urbs(dev);
+ret = rtl8187_init_urbs(dev);
+if (ret)
+goto rtl8187_start_exit;
reg = RTL818X_RX_CONF_ONLYERLPKT |
RTL818X_RX_CONF_RX_AUTORESETPHY |
--
1.8.1.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/
[PATCH v2 3/6] x86 / ACPI: simplify _acpi_map_lsapic()
From: Jiang Liu
In acpi_register_lapic(), it will generates a new logical cpu
number and maps to the local APIC id, this logical cpu number
can be returned to simplify _acpi_map_lsapic() implementation.
Signed-off-by: Jiang Liu
Signed-off-by: Hanjun Guo
---
arch/x86/include/asm/mpspec.h |2 +-
arch/x86/kernel/acpi/boot.c | 50 +
arch/x86/kernel/apic/apic.c |8 ---
3 files changed, 22 insertions(+), 38 deletions(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index 626cf70..3142a94 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -94,7 +94,7 @@ static inline void early_reserve_e820_mpc_new(void) { }
#define default_get_smp_config x86_init_uint_noop
#endif
-void generic_processor_info(int apicid, int version);
+int generic_processor_info(int apicid, int version);
#ifdef CONFIG_ACPI
extern void mp_register_ioapic(int id, u32 address, u32 gsi_base);
extern void mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger,
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 3e186d1..ab89c2b 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -195,24 +195,31 @@ static int __init acpi_parse_madt(struct
acpi_table_header *table)
return 0;
}
-static void acpi_register_lapic(int id, u8 enabled)
+/**
+ * acpi_register_lapic - register a local apic and generates a logic cpu number
+ * @id: local apic id to register
+ * @enabled: this cpu is enabled or not
+ *
+ * Returns the logic cpu number which maps to the local apic
+ */
+static int acpi_register_lapic(int id, u8 enabled)
{
unsigned int ver = 0;
if (id >= (MAX_LOCAL_APIC-1)) {
printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
- return;
+ return -EINVAL;
}
if (!enabled) {
++disabled_cpus;
- return;
+ return -EINVAL;
}
if (boot_cpu_physical_apicid != -1U)
ver = apic_version[boot_cpu_physical_apicid];
- generic_processor_info(id, ver);
+ return generic_processor_info(id, ver);
}
static int __init
@@ -622,44 +629,19 @@ static void acpi_map_cpu2node(acpi_handle handle, int
cpu, int physid)
static int _acpi_map_lsapic(acpi_handle handle, int physid, int *pcpu)
{
- cpumask_var_t tmp_map, new_map;
int cpu;
- int retval = -ENOMEM;
-
- if (!alloc_cpumask_var(_map, GFP_KERNEL))
- goto out;
- if (!alloc_cpumask_var(_map, GFP_KERNEL))
- goto free_tmp_map;
-
- cpumask_copy(tmp_map, cpu_present_mask);
- acpi_register_lapic(physid, ACPI_MADT_ENABLED);
-
- /*
-* If acpi_register_lapic successfully generates a new logical cpu
-* number, then the following will get us exactly what was mapped
-*/
- cpumask_andnot(new_map, cpu_present_mask, tmp_map);
- if (cpumask_empty(new_map)) {
- printk ("Unable to map lapic to logical cpu number\n");
- retval = -EINVAL;
- goto free_new_map;
+ cpu = acpi_register_lapic(physid, ACPI_MADT_ENABLED);
+ if (cpu < 0) {
+ pr_info(PREFIX "Unable to map lapic to logical cpu number\n");
+ return cpu;
}
acpi_processor_set_pdc(handle);
-
- cpu = cpumask_first(new_map);
acpi_map_cpu2node(handle, cpu, physid);
*pcpu = cpu;
- retval = 0;
-
-free_new_map:
- free_cpumask_var(new_map);
-free_tmp_map:
- free_cpumask_var(tmp_map);
-out:
- return retval;
+ return 0;
}
/* wrapper to silence section mismatch warning */
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index eca89c5..c98fe31 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2107,7 +2107,7 @@ void disconnect_bsp_APIC(int virt_wire_setup)
apic_write(APIC_LVT1, value);
}
-void generic_processor_info(int apicid, int version)
+int generic_processor_info(int apicid, int version)
{
int cpu, max = nr_cpu_ids;
bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
@@ -2127,7 +2127,7 @@ void generic_processor_info(int apicid, int version)
" Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
disabled_cpus++;
- return;
+ return -ENODEV;
}
if (num_processors >= nr_cpu_ids) {
@@ -2138,7 +2138,7 @@ void generic_processor_info(int apicid, int version)
" Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
disabled_cpus++;
- return;
+ return -EINVAL;
}
num_processors++;
@@ -2183,6 +2183,8 @@ void generic_processor_info(int apicid, int version)
#endif
set_cpu_possible(cpu, true);
[PATCH v2 2/6] ACPI / processor: use apic_id and remove duplicated _MAT evaluation
From: Jiang Liu
Since APIC id is saved in processor struct, just use it and
remove the duplicated _MAT evaluation.
Signed-off-by: Jiang Liu
Signed-off-by: Hanjun Guo
---
arch/ia64/kernel/acpi.c | 38 --
arch/x86/kernel/acpi/boot.c | 38 +++---
drivers/acpi/acpi_processor.c |2 +-
include/linux/acpi.h |2 +-
4 files changed, 9 insertions(+), 71 deletions(-)
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index 5eb71d2..59d52e3 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -882,40 +882,10 @@ __init void prefill_possible_map(void)
set_cpu_possible(i, true);
}
-static int _acpi_map_lsapic(acpi_handle handle, int *pcpu)
+static int _acpi_map_lsapic(acpi_handle handle, int physid, int *pcpu)
{
- struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
- union acpi_object *obj;
- struct acpi_madt_local_sapic *lsapic;
cpumask_t tmp_map;
- int cpu, physid;
-
- if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, )))
- return -EINVAL;
-
- if (!buffer.length || !buffer.pointer)
- return -EINVAL;
-
- obj = buffer.pointer;
- if (obj->type != ACPI_TYPE_BUFFER)
- {
- kfree(buffer.pointer);
- return -EINVAL;
- }
-
- lsapic = (struct acpi_madt_local_sapic *)obj->buffer.pointer;
-
- if ((lsapic->header.type != ACPI_MADT_TYPE_LOCAL_SAPIC) ||
- (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))) {
- kfree(buffer.pointer);
- return -EINVAL;
- }
-
- physid = ((lsapic->id << 8) | (lsapic->eid));
-
- kfree(buffer.pointer);
- buffer.length = ACPI_ALLOCATE_BUFFER;
- buffer.pointer = NULL;
+ int cpu;
cpumask_complement(_map, cpu_present_mask);
cpu = cpumask_first(_map);
@@ -934,9 +904,9 @@ static int _acpi_map_lsapic(acpi_handle handle, int *pcpu)
}
/* wrapper to silence section mismatch warning */
-int __ref acpi_map_lsapic(acpi_handle handle, int *pcpu)
+int __ref acpi_map_lsapic(acpi_handle handle, int physid, int *pcpu)
{
- return _acpi_map_lsapic(handle, pcpu);
+ return _acpi_map_lsapic(handle, physid, pcpu);
}
EXPORT_SYMBOL(acpi_map_lsapic);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 2627a81..3e186d1 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -620,44 +620,12 @@ static void acpi_map_cpu2node(acpi_handle handle, int
cpu, int physid)
#endif
}
-static int _acpi_map_lsapic(acpi_handle handle, int *pcpu)
+static int _acpi_map_lsapic(acpi_handle handle, int physid, int *pcpu)
{
- struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
- union acpi_object *obj;
- struct acpi_madt_local_apic *lapic;
cpumask_var_t tmp_map, new_map;
- u8 physid;
int cpu;
int retval = -ENOMEM;
- if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, )))
- return -EINVAL;
-
- if (!buffer.length || !buffer.pointer)
- return -EINVAL;
-
- obj = buffer.pointer;
- if (obj->type != ACPI_TYPE_BUFFER ||
- obj->buffer.length < sizeof(*lapic)) {
- kfree(buffer.pointer);
- return -EINVAL;
- }
-
- lapic = (struct acpi_madt_local_apic *)obj->buffer.pointer;
-
- if (lapic->header.type != ACPI_MADT_TYPE_LOCAL_APIC ||
- !(lapic->lapic_flags & ACPI_MADT_ENABLED)) {
- kfree(buffer.pointer);
- return -EINVAL;
- }
-
- physid = lapic->id;
-
- kfree(buffer.pointer);
- buffer.length = ACPI_ALLOCATE_BUFFER;
- buffer.pointer = NULL;
- lapic = NULL;
-
if (!alloc_cpumask_var(_map, GFP_KERNEL))
goto out;
@@ -695,9 +663,9 @@ out:
}
/* wrapper to silence section mismatch warning */
-int __ref acpi_map_lsapic(acpi_handle handle, int *pcpu)
+int __ref acpi_map_lsapic(acpi_handle handle, int physid, int *pcpu)
{
- return _acpi_map_lsapic(handle, pcpu);
+ return _acpi_map_lsapic(handle, physid, pcpu);
}
EXPORT_SYMBOL(acpi_map_lsapic);
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index f89f914..66c9b70 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -181,7 +181,7 @@ static int acpi_processor_hotadd_init(struct acpi_processor
*pr)
cpu_maps_update_begin();
cpu_hotplug_begin();
- ret = acpi_map_lsapic(pr->handle, >id);
+ ret = acpi_map_lsapic(pr->handle, pr->apic_id, >id);
if (ret)
goto out;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index a5db4ae..3bc7414 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -116,7 +116,7 @@ void acpi_numa_arch_fixup(void);
#ifdef
[PATCH v2 1/6] ACPI / processor: Introduce apic_id in struct processor to save parsed APIC id
From: Jiang Liu
For cpu hot add, we evaluate _MAT or parse MADT twice to get APIC id,
here is the code logic:
acpi_processor_add()
acpi_processor_get_info()
acpi_get_cpuid() will evaluate _MAT or parse MADT;
acpi_processor_hotadd_init()
acpi_map_lsapic() will evaluate _MAT again;
This can be done more effectively, this patch introduces apic_id in struct
processor to save parsed APIC id, and then we can use it and remove the
duplicated _MAT evaluation.
Signed-off-by: Jiang Liu
Signed-off-by: Hanjun Guo
---
drivers/acpi/acpi_processor.c |4 +++-
drivers/acpi/processor_core.c | 26 +-
include/acpi/processor.h |3 +++
3 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index f29e06e..f89f914 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -270,7 +270,9 @@ static int acpi_processor_get_info(struct acpi_device
*device)
device_declaration = 1;
pr->acpi_id = value;
}
- cpu_index = acpi_get_cpuid(pr->handle, device_declaration, pr->acpi_id);
+ pr->apic_id = acpi_get_apicid(pr->handle, device_declaration,
+ pr->acpi_id);
+ cpu_index = acpi_map_cpuid(pr->apic_id, pr->acpi_id);
/* Handle UP system running SMP kernel, with no LAPIC in MADT */
if (!cpu0_initialized && (cpu_index == -1) &&
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index cf34d90..b3171f3 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -162,16 +162,23 @@ exit:
return apic_id;
}
-int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id)
+int acpi_get_apicid(acpi_handle handle, int type, u32 acpi_id)
{
-#ifdef CONFIG_SMP
- int i;
-#endif
- int apic_id = -1;
+ int apic_id;
apic_id = map_mat_entry(handle, type, acpi_id);
if (apic_id == -1)
apic_id = map_madt_entry(type, acpi_id);
+
+ return apic_id;
+}
+
+int acpi_map_cpuid(int apic_id, u32 acpi_id)
+{
+#ifdef CONFIG_SMP
+ int i;
+#endif
+
if (apic_id == -1) {
/*
* On UP processor, there is no _MAT or MADT table.
@@ -211,6 +218,15 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32
acpi_id)
#endif
return -1;
}
+
+int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id)
+{
+ int apic_id;
+
+ apic_id = acpi_get_apicid(handle, type, acpi_id);
+
+ return acpi_map_cpuid(apic_id, acpi_id);
+}
EXPORT_SYMBOL_GPL(acpi_get_cpuid);
static bool __init processor_physically_present(acpi_handle handle)
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index 66096d0..7816e45 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -199,6 +199,7 @@ struct acpi_processor_flags {
struct acpi_processor {
acpi_handle handle;
u32 acpi_id;
+ u32 apic_id;
u32 id;
u32 pblk;
int performance_platform_limit;
@@ -314,6 +315,8 @@ static inline int acpi_processor_get_bios_limit(int cpu,
unsigned int *limit)
/* in processor_core.c */
void acpi_processor_set_pdc(acpi_handle handle);
+int acpi_get_apicid(acpi_handle, int type, u32 acpi_id);
+int acpi_map_cpuid(int apic_id, u32 acpi_id);
int acpi_get_cpuid(acpi_handle, int type, u32 acpi_id);
/* in processor_throttling.c */
--
1.7.9.5
--
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 0/6] Remove the duplicated _MAT evaluation and simplify _acpi_map_lsapic()
v1->v2: Return specific error value instead of just return -1, and correct some grammar mistake in changelog. For cpu hot add, evaluate _MAT or parse MADT will did twice to get APIC id: acpi_processor_add() acpi_processor_get_info() acpi_get_cpuid() will evaluate _MAT or parse MADT; acpi_processor_hotadd_init() acpi_map_lsapic() will evaluate _MAT again; This patch set introduces apic_id in struct processor to save parsed APIC id, and use it to remove the duplicated _MAT evaluation. Further more, the new logical cpu number will be generated in acpi_register_lapic(), this can be returned to remove the cpumask allocation and operation to simplify _acpi_map_lsapic(). There are also some cleanups for the ACPI processor dirver code. Hanjun Guo (2): ACPI / processor: remove unnecessary if (!pr) check ACPI / processor: Remove outdated comments Jiang Liu (4): ACPI / processor: Introduce apic_id in struct processor to save parsed APIC id ACPI / processor: use apic_id and remove duplicated _MAT evaluation x86 / ACPI: simplify _acpi_map_lsapic() ACPI / processor: remove some dead code in acpi_processor_get_info() arch/ia64/kernel/acpi.c | 38 ++ arch/x86/include/asm/mpspec.h |2 +- arch/x86/kernel/acpi/boot.c | 88 + arch/x86/kernel/apic/apic.c |8 ++-- drivers/acpi/acpi_processor.c | 22 +++ drivers/acpi/processor_core.c | 26 +--- include/acpi/processor.h |3 ++ include/linux/acpi.h |2 +- 8 files changed, 60 insertions(+), 129 deletions(-) -- 1.7.9.5 -- 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/
linux-next: manual merge of the ipsec-next tree with Linus' tree
Hi Steffen,
Today's linux-next merge of the ipsec-next tree got a conflict in
include/net/xfrm.h between commit 628e341f319f ("xfrm: make local error
reporting more robust") from Linus' tree and commit aba826958830
("{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode
callback") from the ipsec-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/net/xfrm.h
index e253bf0,c7afa6e..000
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@@ -1499,9 -1501,8 +1505,9 @@@ extern int xfrm4_output(struct sk_buff
extern int xfrm4_output_finish(struct sk_buff *skb);
extern int xfrm4_tunnel_register(struct xfrm_tunnel *handler, unsigned short
family);
extern int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler, unsigned
short family);
- extern int xfrm4_mode_tunnel_input_register(struct xfrm_tunnel *handler);
- extern int xfrm4_mode_tunnel_input_deregister(struct xfrm_tunnel *handler);
+ extern int xfrm4_mode_tunnel_input_register(struct xfrm_tunnel_notifier
*handler);
+ extern int xfrm4_mode_tunnel_input_deregister(struct xfrm_tunnel_notifier
*handler);
+extern void xfrm4_local_error(struct sk_buff *skb, u32 mtu);
extern int xfrm6_extract_header(struct sk_buff *skb);
extern int xfrm6_extract_input(struct xfrm_state *x, struct sk_buff *skb);
extern int xfrm6_rcv_spi(struct sk_buff *skb, int nexthdr, __be32 spi);
pgpKiU4FHIMnZ.pgp
Description: PGP signature
Re: [PATCH V2 0/6] perf: New conditional branch filter
On 08/30/2013 05:18 PM, Stephane Eranian wrote: > 2013/8/30 Anshuman Khandual >> > >> > This patchset is the re-spin of the original branch stack sampling >> > patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset >> > also enables SW based branch filtering support for PPC64 platforms which >> > have >> > branch stack sampling support. With this new enablement, the branch filter >> > support >> > for PPC64 platforms have been extended to include all these combinations >> > discussed >> > below with a sample test application program. >> > >> > > I am trying to understand which HW has support for capturing the > branches: PPC7 or PPC8. > Then it seems you're saying that only PPC8 has the filtering support. > On PPC7 you use the > SW filter. Did I get this right? > > I will look at the patch set. > Hey Stephane, POWER7 does not have BHRB support required to capture the branches. Right now its only POWER8 (which has BHRB) can capture branches in HW. It has some PMU level branch filters and rest we have implemented in SW. But these SW filters cannot be applied in POWER7 as it does not support branch stack sampling because of lack of BHRB. I have mentioned PPC64 support in the sense that this SW filtering code could be used in existing or future generation powerpc processors which would have PMU support for branch stack sampling. My apologies if the description for the patchset was ambiguous. Regards Anshuman -- 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: [PATCHv2 1/4] pwm: Add Freescale FTM PWM driver support
> > +static void fsl_pwm_free(struct pwm_chip *chip, struct pwm_device
> > +*pwm) {
> > + struct fsl_pwm_chip *fpc;
> > + struct fsl_pwm_data *pwm_data;
> > +
> > + fpc = to_fsl_chip(chip);
> > +
> > + pwm_data = pwm_get_chip_data(pwm);
> > + if (!pwm_data)
> > + return;
>
> THis check seems unnecessary.
>
But if do not check it here, I must check it in the following code.
> > +
> > + if (pwm_data->available != FSL_AVAILABLE)
> > + return;
> > +
So the ' struct fsl_pwm_data' may be removed in the future.
>
> > +
> > +
> > + pwm_data->period_cycles = period_cycles;
> > + pwm_data->duty_cycles = duty_cycles;
>
> These fields are set but never read. Please drop them.
>
> If you drop the 'available' field also the you can drop chip_data
> completely.
>
I think I may move the 'available' field to the PWM driver data struct.
> > +
> > + writel(FTMCnSC_MSB | FTMCnSC_ELSB, fpc->base + FTM_CSC(pwm->hwpwm));
> > +
> > + writel(0xF0, fpc->base + FTM_OUTMASK);
> > + writel(0x0F, fpc->base + FTM_OUTINIT);
> > + writel(FTM_CNTIN_VAL, fpc->base + FTM_CNTIN);
> > +
> > + writel(period_cycles + cntin - 1, fpc->base + FTM_MOD);
> > + writel(duty_cycles + cntin, fpc->base + FTM_CV(pwm->hwpwm));
> > +
> > + return 0;
> > +}
> > +
> > +static int fsl_pwm_set_polarity(struct pwm_chip *chip, struct
> pwm_device *pwm,
> > + enum pwm_polarity polarity)
> > +{
> > + unsigned long reg;
> > + struct fsl_pwm_data *pwm_data;
> > + struct fsl_pwm_chip *fpc;
> > +
> > + fpc = to_fsl_chip(chip);
> > +
> > + pwm_data = pwm_get_chip_data(pwm);
> > + if (!pwm_data)
> > + return -EINVAL;
> > +
> > + if (pwm_data->available != FSL_AVAILABLE)
> > + return -EINVAL;
> > +
> > + reg = readl(fpc->base + FTM_POL);
> > + reg &= ~BIT(pwm->hwpwm);
>
> Either drop this line...
>
This is just for unmasking this bit field.
Here it's not needed, so I will revise it.
> > + if (polarity == PWM_POLARITY_INVERSED)
> > + reg |= BIT(pwm->hwpwm);
> > + else
> > + reg &= ~BIT(pwm->hwpwm);
>
> ...or this one
>
> > +static int fsl_pwm_enable(struct pwm_chip *chip, struct pwm_device
> > +*pwm) {
> > + int ret;
> > + struct fsl_pwm_chip *fpc;
> > + struct pinctrl_state *pins_state;
> > + struct fsl_pwm_data *pwm_data;
> > + const char *statename;
> > +
> > + fpc = to_fsl_chip(chip);
> > +
> > + pwm_data = pwm_get_chip_data(pwm);
> > + if (!pwm_data)
> > + return -EINVAL;
> > +
> > + if (pwm_data->available != FSL_AVAILABLE)
> > + return -EINVAL;
> > +
> > + statename = kasprintf(GFP_KERNEL, "ch%d-active", pwm->hwpwm);
>
> You loose memory here and in fsl_pwm_disable aswell.
>
Yes, I will revise it.
> > + pins_state = pinctrl_lookup_state(fpc->pinctrl,
> > + statename);
> > + /* enable pins to be muxed in and configured */
> > + if (!IS_ERR(pins_state)) {
> > + ret = pinctrl_select_state(fpc->pinctrl, pins_state);
> > + if (ret)
> > + dev_warn(chip->dev, "could not set default pins\n");
> > + } else
> > + dev_warn(chip->dev, "could not get default pinstate\n");
>
> Either it's ok to do without pinctrl or it's not ok, so either return an
> error or drop the warnings. Polluting the kernel log with such messages
> from a frequently called function is not a good idea.
>
Well, I will just print out some error logs and return the error.
--
Best Regards.
Xiubo
--
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 4/4] ASoC: rsnd: use regmap instead of original register mapping method
Current Linux kernel is supporting regmap/regmap_field,
and, it is good match for Renesas Sound Gen1/Gen2 register mapping.
This patch uses regmap instead of original method for register access
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
- exchange macro naming (RSND_GEN1_S_REG/RSND_GEN1_M_REG)
sound/soc/sh/rcar/core.c | 45 -
sound/soc/sh/rcar/gen.c | 231 ++
2 files changed, 150 insertions(+), 126 deletions(-)
diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index a357060..fc83f0f 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -106,51 +106,6 @@
(!(priv->info->func) ? -ENODEV :\
priv->info->func(param))
-
-/*
- * basic function
- */
-u32 rsnd_read(struct rsnd_priv *priv,
- struct rsnd_mod *mod, enum rsnd_reg reg)
-{
- void __iomem *base = rsnd_gen_reg_get(priv, mod, reg);
-
- BUG_ON(!base);
-
- return ioread32(base);
-}
-
-void rsnd_write(struct rsnd_priv *priv,
- struct rsnd_mod *mod,
- enum rsnd_reg reg, u32 data)
-{
- void __iomem *base = rsnd_gen_reg_get(priv, mod, reg);
- struct device *dev = rsnd_priv_to_dev(priv);
-
- BUG_ON(!base);
-
- dev_dbg(dev, "w %p : %08x\n", base, data);
-
- iowrite32(data, base);
-}
-
-void rsnd_bset(struct rsnd_priv *priv, struct rsnd_mod *mod,
- enum rsnd_reg reg, u32 mask, u32 data)
-{
- void __iomem *base = rsnd_gen_reg_get(priv, mod, reg);
- struct device *dev = rsnd_priv_to_dev(priv);
- u32 val;
-
- BUG_ON(!base);
-
- val = ioread32(base);
- val &= ~mask;
- val |= data & mask;
- iowrite32(val, base);
-
- dev_dbg(dev, "s %p : %08x\n", base, val);
-}
-
/*
* rsnd_mod functions
*/
diff --git a/sound/soc/sh/rcar/gen.c b/sound/soc/sh/rcar/gen.c
index 331fc55..9a55fdf 100644
--- a/sound/soc/sh/rcar/gen.c
+++ b/sound/soc/sh/rcar/gen.c
@@ -24,21 +24,106 @@ struct rsnd_gen_ops {
struct rsnd_dai_stream *io);
};
-struct rsnd_gen_reg_map {
- int index; /* -1 : not supported */
- u32 offset_id; /* offset of ssi0, ssi1, ssi2... */
- u32 offset_adr; /* offset of SSICR, SSISR, ... */
-};
-
struct rsnd_gen {
void __iomem *base[RSND_BASE_MAX];
- struct rsnd_gen_reg_map reg_map[RSND_REG_MAX];
struct rsnd_gen_ops *ops;
+
+ struct regmap *regmap;
+ struct regmap_field *regs[RSND_REG_MAX];
};
#define rsnd_priv_to_gen(p)((struct rsnd_gen *)(p)->gen)
+#define RSND_REG_SET(gen, id, reg_id, offset, _id_offset, _id_size)\
+ [id] = {\
+ .reg = (unsigned int)gen->base[reg_id] + offset,\
+ .lsb = 0, \
+ .msb = 31, \
+ .id_size = _id_size,\
+ .id_offset = _id_offset,\
+ }
+
+/*
+ * basic function
+ */
+static int rsnd_regmap_write32(void *context, const void *_data, size_t count)
+{
+ struct rsnd_priv *priv = context;
+ struct device *dev = rsnd_priv_to_dev(priv);
+ u32 *data = (u32 *)_data;
+ u32 val = data[1];
+ void __iomem *reg = (void *)data[0];
+
+ iowrite32(val, reg);
+
+ dev_dbg(dev, "w %p : %08x\n", reg, val);
+
+ return 0;
+}
+
+static int rsnd_regmap_read32(void *context,
+ const void *_data, size_t reg_size,
+ void *_val, size_t val_size)
+{
+ struct rsnd_priv *priv = context;
+ struct device *dev = rsnd_priv_to_dev(priv);
+ u32 *data = (u32 *)_data;
+ u32 *val = (u32 *)_val;
+ void __iomem *reg = (void *)data[0];
+
+ *val = ioread32(reg);
+
+ dev_dbg(dev, "r %p : %08x\n", reg, *val);
+
+ return 0;
+}
+
+static struct regmap_bus rsnd_regmap_bus = {
+ .write = rsnd_regmap_write32,
+ .read = rsnd_regmap_read32,
+ .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
+ .val_format_endian_default = REGMAP_ENDIAN_NATIVE,
+};
+
+u32 rsnd_read(struct rsnd_priv *priv,
+ struct rsnd_mod *mod, enum rsnd_reg reg)
+{
+ struct rsnd_gen *gen = rsnd_priv_to_gen(priv);
+ u32 val;
+
+ if (regmap_fields_enable(gen->regs[reg]))
+ regmap_fields_read(gen->regs[reg], rsnd_mod_id(mod), );
+ else
+ regmap_field_read(gen->regs[reg], );
+
+ return val;
+}
+
+void rsnd_write(struct rsnd_priv *priv,
+ struct rsnd_mod *mod,
+ enum rsnd_reg reg, u32 data)
+{
+ struct rsnd_gen *gen = rsnd_priv_to_gen(priv);
+
+ if (regmap_fields_enable(gen->regs[reg]))
+
[PATCH v2 2/4] regmap: Add regmap_fields APIs
Current Linux kernel is supporting regmap_field method
and it is very useful feature.
It needs one regmap_filed for one register access.
OTOH, there is multi port device which
has many same registers in the market.
The difference for each register access is
only its address offset.
Current API needs many regmap_field for such device,
but it is not good.
This patch adds new regmap_fileds API which can care
about multi port/offset access via regmap.
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
- fixup EXPORT_SYMBOL_GPL() naming
drivers/base/regmap/internal.h |3 ++
drivers/base/regmap/regmap.c | 97
include/linux/regmap.h | 12 +
3 files changed, 112 insertions(+)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 57f7778..9010614 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -179,6 +179,9 @@ struct regmap_field {
/* lsb */
unsigned int shift;
unsigned int reg;
+
+ unsigned int id_size;
+ unsigned int id_offset;
};
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 285afa7..7cb2e9f 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -821,6 +821,8 @@ static void regmap_field_init(struct regmap_field *rm_field,
rm_field->reg = reg_field.reg;
rm_field->shift = reg_field.lsb;
rm_field->mask = ((BIT(field_bits) - 1) << reg_field.lsb);
+ rm_field->id_size = reg_field.id_size;
+ rm_field->id_offset = reg_field.id_offset;
}
/**
@@ -1389,6 +1391,68 @@ int regmap_field_update_bits(struct regmap_field *field,
unsigned int mask, unsi
}
EXPORT_SYMBOL_GPL(regmap_field_update_bits);
+/**
+ * regmap_fields_write(): Write a value to a single register field with port ID
+ *
+ * @field: Register field to write to
+ * @id: port ID
+ * @val: Value to be written
+ *
+ * A value of zero will be returned on success, a negative errno will
+ * be returned in error cases.
+ */
+int regmap_fields_write(struct regmap_field *field, unsigned int id,
+ unsigned int val)
+{
+ if (id >= field->id_size)
+ return -EINVAL;
+
+ return regmap_update_bits(field->regmap,
+ field->reg + (field->id_offset * id),
+ field->mask, val << field->shift);
+}
+EXPORT_SYMBOL_GPL(regmap_fields_write);
+
+/**
+ * regmap_fields_update_bits():Perform a read/modify/write cycle
+ * on the register field
+ *
+ * @field: Register field to write to
+ * @id: port ID
+ * @mask: Bitmask to change
+ * @val: Value to be written
+ *
+ * A value of zero will be returned on success, a negative errno will
+ * be returned in error cases.
+ */
+int regmap_fields_update_bits(struct regmap_field *field, unsigned int id,
+ unsigned int mask, unsigned int val)
+{
+ if (id >= field->id_size)
+ return -EINVAL;
+
+ mask = (mask << field->shift) & field->mask;
+
+ return regmap_update_bits(field->regmap,
+ field->reg + (field->id_offset * id),
+ mask, val << field->shift);
+}
+EXPORT_SYMBOL_GPL(regmap_fields_update_bits);
+
+/**
+ * regmap_fields_enable(): query fields access
+ *
+ * @field: Query Register field
+ *
+ * A non-zero will be returned when fields access enable,
+ * a zero will be returned in single field.
+ */
+int regmap_fields_enable(struct regmap_field *field)
+{
+ return field->id_size && field->id_offset;
+}
+EXPORT_SYMBOL_GPL(regmap_fields_enable);
+
/*
* regmap_bulk_write(): Write multiple registers to the device
*
@@ -1697,6 +1761,39 @@ int regmap_field_read(struct regmap_field *field,
unsigned int *val)
EXPORT_SYMBOL_GPL(regmap_field_read);
/**
+ * regmap_fields_read(): Read a value to a single register field with port ID
+ *
+ * @field: Register field to read from
+ * @id: port ID
+ * @val: Pointer to store read value
+ *
+ * A value of zero will be returned on success, a negative errno will
+ * be returned in error cases.
+ */
+int regmap_fields_read(struct regmap_field *field, unsigned int id,
+ unsigned int *val)
+{
+ int ret;
+ unsigned int reg_val;
+
+ if (id >= field->id_size)
+ return -EINVAL;
+
+ ret = regmap_read(field->regmap,
+ field->reg + (field->id_offset * id),
+ _val);
+ if (ret != 0)
+ return ret;
+
+ reg_val &= field->mask;
+ reg_val >>= field->shift;
+ *val = reg_val;
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(regmap_fields_read);
+
+/**
* regmap_bulk_read(): Read multiple registers from the device
*
* @map: Register map to write to
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index
[PATCH v2 3/4] ASoC: rsnd: gen: rsnd_gen_ops cares .probe and .remove
Current rsnd_gen_ops didn't care about .probe and .remove
functions, but it was not good sense.
This patch tidyup it
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
- no change
sound/soc/sh/rcar/gen.c | 41 -
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/sound/soc/sh/rcar/gen.c b/sound/soc/sh/rcar/gen.c
index babb203..331fc55 100644
--- a/sound/soc/sh/rcar/gen.c
+++ b/sound/soc/sh/rcar/gen.c
@@ -11,6 +11,11 @@
#include "rsnd.h"
struct rsnd_gen_ops {
+ int (*probe)(struct platform_device *pdev,
+struct rcar_snd_info *info,
+struct rsnd_priv *priv);
+ void (*remove)(struct platform_device *pdev,
+ struct rsnd_priv *priv);
int (*path_init)(struct rsnd_priv *priv,
struct rsnd_dai *rdai,
struct rsnd_dai_stream *io);
@@ -98,11 +103,6 @@ static int rsnd_gen1_path_exit(struct rsnd_priv *priv,
return ret;
}
-static struct rsnd_gen_ops rsnd_gen1_ops = {
- .path_init = rsnd_gen1_path_init,
- .path_exit = rsnd_gen1_path_exit,
-};
-
#define RSND_GEN1_REG_MAP(g, s, i, oi, oa) \
do {\
(g)->reg_map[RSND_REG_##i].index = RSND_GEN1_##s; \
@@ -163,7 +163,6 @@ static int rsnd_gen1_probe(struct platform_device *pdev,
IS_ERR(gen->base[RSND_GEN1_SSI]))
return -ENODEV;
- gen->ops = _gen1_ops;
rsnd_gen1_reg_map_init(gen);
dev_dbg(dev, "Gen1 device probed\n");
@@ -183,6 +182,13 @@ static void rsnd_gen1_remove(struct platform_device *pdev,
{
}
+static struct rsnd_gen_ops rsnd_gen1_ops = {
+ .probe = rsnd_gen1_probe,
+ .remove = rsnd_gen1_remove,
+ .path_init = rsnd_gen1_path_init,
+ .path_exit = rsnd_gen1_path_exit,
+};
+
/*
* Gen
*/
@@ -251,6 +257,14 @@ int rsnd_gen_probe(struct platform_device *pdev,
return -ENOMEM;
}
+ if (rsnd_is_gen1(priv))
+ gen->ops = _gen1_ops;
+
+ if (!gen->ops) {
+ dev_err(dev, "unknown generation R-Car sound device\n");
+ return -ENODEV;
+ }
+
priv->gen = gen;
/*
@@ -261,20 +275,13 @@ int rsnd_gen_probe(struct platform_device *pdev,
for (i = 0; i < RSND_REG_MAX; i++)
gen->reg_map[i].index = -1;
- /*
-* init each module
-*/
- if (rsnd_is_gen1(priv))
- return rsnd_gen1_probe(pdev, info, priv);
-
- dev_err(dev, "unknown generation R-Car sound device\n");
-
- return -ENODEV;
+ return gen->ops->probe(pdev, info, priv);
}
void rsnd_gen_remove(struct platform_device *pdev,
struct rsnd_priv *priv)
{
- if (rsnd_is_gen1(priv))
- rsnd_gen1_remove(pdev, priv);
+ struct rsnd_gen *gen = rsnd_priv_to_gen(priv);
+
+ gen->ops->remove(pdev, priv);
}
--
1.7.9.5
--
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 v2] h8300/kernel/setup.c: add "linux/initrd.h" to pass compiling
On 08/30/2013 08:20 PM, Guenter Roeck wrote: > On 08/30/2013 04:44 AM, richard -rw- weinberger wrote: >> On Fri, Aug 30, 2013 at 1:18 PM, Guenter Roeck >> wrote: >>> On 08/29/2013 11:34 PM, Chen Gang wrote: On 08/30/2013 12:53 PM, Guenter Roeck wrote: > > On 08/29/2013 08:59 PM, Chen Gang wrote: >> >> The related error (allmodconfig for h8300): >> >> arch/h8300/kernel/setup.c: In function 'setup_arch': >> arch/h8300/kernel/setup.c:103:3: error: 'initrd_start' >> undeclared >> (first use in this function) >> initrd_start = memory_start; >> ^ >> arch/h8300/kernel/setup.c:103:3: note: each undeclared >> identifier >> is reported only once for each function it appears in >> arch/h8300/kernel/setup.c:104:3: error: 'initrd_end' undeclared >> (first use in this function) >> initrd_end = memory_start += be32_to_cpu(((unsigned long *) >> (memory_start))[2]); >> ^ >> >> Signed-off-by: Chen Gang >> --- > > > Maybe an odd question, but is there a way to actually compile the > h8300 > target Firstly, at least for me, I don't think it is an odd question. :-) For the tool-chain: I compiled the cross-compiler from the gcc and binutils source code. GCC has too many bugs to compile kernel with -Os (normal make will fail). If without -Os (no optimization), it can work correctly which is enough for my goal: "let h8300 pass allmodconfig". ;-) > From building with allmodconfig for h8300: I can find more chances to provide contributes (both for h8300 and for others). I can learn more in kernel wide. I can familiar the gcc and binutils step by step (especially to familiar with their issues). Next: I will communicate/work with the gcc guys for the gcc issues which found by building kernel. :-) > in the first place ? The cross compiler on kernel.org doesn't work, > nor > does > the one available through Ubuntu. > > Guenter > For binutils, no release under Ubuntu, and the Fedora17's is incorrect (can not use), but the binutils-2.22 from gnu is OK. For gcc, no release under Ubuntu, for Fedora17's, gcc-4.9, gcc-4.8, gcc-4.7.4, and gcc-4.4.7 all have bugs for compiling kernel(their bugs are different too). It is really not easy to fix these bugs (gcc guys have too many issues to fix), even if really find the root cause, it is still difficult to fix (fix one bug is very easy to cause another more issues). >>> >>> I have to wonder ... is this all worth it ? It almost looks like no one >>> is using this architecture anymore. Do you have target hardware to test >>> any of your changes ? >> No, I have no related hardwares. Hmm... but I still think it is worth to do: 1. until now, we do not get confirmation that "h8300 is useless, need remove it from kernel". 2. it is an architecture which may cause more issues (no MMU, but has IOMAP; support ISA, but not support PCI; has gpio, but not use gpio lib, ...). so can have more chances to fine another related sub-systems' issues. 3. It is worth to scan all architectures one by one, and let all of them pass compiling with allmodconfig, h8300 is part of them. >> Chen has to achieve his 10 patches/month quota. :-\ >> Yeah, it is a basic requrement to me (which I made by myself, it is not my company's requirement). It is a protection goal: if I finish them or more, does not mean I am well done (more patches may not mean more contributes). if I can not finish them, that means I should improve myself in time. > > I don't mind that, but there might be more valuable targets to achieve > that goal > than a potentially dead architecture. > Yeah, in fact, I feel each architecture can archieve that goal (e.g. with srandconfig, or find issues only by reading source code). And now I am scanning all architectures by cross-compiling with allmodconfig, h8300 is just one of them. :-) > A more useful change may be to remove the code from the kernel if there > is no plan > to fix it (for real, I mean). > Hmm... if we are sure about it, that sounds reasonable to me (but excuse me, I can not sure about it). Welcome any other members' suggestions or completions. > Guenter > > > Thanks. -- Chen Gang -- 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 v2 0/4] add regmap_filelds and use it on Renesas Sound driver
Hi Mark These patches are v2 of new regmap_filelds API on kernel. ~ It can care about multi port register offset via regmap. 0x + 0x40-- port 0 -- regX regY regZ 0x + 0x80-- port 1 -- regX regY regZ This case, current API needs 2 (= port) x 3 (= regX/Y/Z) regmap_fileld, but this new API can care about all port via 3 regmap_filelds with port ID. I'm not sure that regmap_filelds is good naming or not. Please let me know if you have good naming idea. The difference between v1 <-> v2 is EXPORT_SYMBOL_GPL() naming on regmap_filelds these are based on below branchs regmap/for-next + asoc/for-next Kuninori Morimoto (4): regmap: add regmap_field_update_bits() regmap: Add regmap_fields APIs ASoC: rsnd: gen: rsnd_gen_ops cares .probe and .remove ASoC: rsnd: use regmap instead of original register mapping method drivers/base/regmap/internal.h |3 + drivers/base/regmap/regmap.c | 117 + include/linux/regmap.h | 14 +++ sound/soc/sh/rcar/core.c | 45 --- sound/soc/sh/rcar/gen.c| 270 +--- 5 files changed, 307 insertions(+), 142 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/
[PATCH v2 1/4] regmap: add regmap_field_update_bits()
Current regmap_field is supporting read/write functions.
This patch adds new update_bits function for it.
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
- fixup EXPORT_SYMBOL_GPL() naming
drivers/base/regmap/regmap.c | 20
include/linux/regmap.h |2 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 7d689a1..285afa7 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1369,6 +1369,26 @@ int regmap_field_write(struct regmap_field *field,
unsigned int val)
}
EXPORT_SYMBOL_GPL(regmap_field_write);
+/**
+ * regmap_field_update_bits(): Perform a read/modify/write cycle
+ * on the register field
+ *
+ * @field: Register field to write to
+ * @mask: Bitmask to change
+ * @val: Value to be written
+ *
+ * A value of zero will be returned on success, a negative errno will
+ * be returned in error cases.
+ */
+int regmap_field_update_bits(struct regmap_field *field, unsigned int mask,
unsigned int val)
+{
+ mask = (mask << field->shift) & field->mask;
+
+ return regmap_update_bits(field->regmap, field->reg,
+ mask, val << field->shift);
+}
+EXPORT_SYMBOL_GPL(regmap_field_update_bits);
+
/*
* regmap_bulk_write(): Write multiple registers to the device
*
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index a10380b..4c8c20a 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -448,6 +448,8 @@ void devm_regmap_field_free(struct device *dev, struct
regmap_field *field);
int regmap_field_read(struct regmap_field *field, unsigned int *val);
int regmap_field_write(struct regmap_field *field, unsigned int val);
+int regmap_field_update_bits(struct regmap_field *field,
+unsigned int mask, unsigned int val);
/**
* Description of an IRQ for the generic regmap irq_chip.
--
1.7.9.5
--
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 V2 4/6] vhost_net: determine whether or not to use zerocopy at one time
On 08/31/2013 02:35 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 08/30/2013 08:29 AM, Jason Wang wrote:
>
>> Currently, even if the packet length is smaller than
>> VHOST_GOODCOPY_LEN, if
>> upend_idx != done_idx we still set zcopy_used to true and rollback
>> this choice
>> later. This could be avoided by determine zerocopy once by checking all
>> conditions at one time before.
>
>> Signed-off-by: Jason Wang
>> ---
>> drivers/vhost/net.c | 46
>> +++---
>> 1 files changed, 19 insertions(+), 27 deletions(-)
>
>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> index 8a6dd0d..ff60c2a 100644
>> --- a/drivers/vhost/net.c
>> +++ b/drivers/vhost/net.c
>> @@ -404,43 +404,35 @@ static void handle_tx(struct vhost_net *net)
>> iov_length(nvq->hdr, s), hdr_size);
>> break;
>> }
>> -zcopy_used = zcopy && (len >= VHOST_GOODCOPY_LEN ||
>> - nvq->upend_idx != nvq->done_idx);
>> +
>> +zcopy_used = zcopy && len >= VHOST_GOODCOPY_LEN
>> +&& (nvq->upend_idx + 1) % UIO_MAXIOV != nvq->done_idx
>> +&& vhost_net_tx_select_zcopy(net);
>
>Could you leave && on a first of two lines, matching the previous
> style?
>
ok.
>>
>> /* use msg_control to pass vhost zerocopy ubuf info to skb */
>> if (zcopy_used) {
>> +struct ubuf_info *ubuf;
>> +ubuf = nvq->ubuf_info + nvq->upend_idx;
>> +
>> vq->heads[nvq->upend_idx].id = head;
> [...]
>> +vq->heads[nvq->upend_idx].len = VHOST_DMA_IN_PROGRESS;
>> +ubuf->callback = vhost_zerocopy_callback;
>> +ubuf->ctx = nvq->ubufs;
>> +ubuf->desc = nvq->upend_idx;
>> +msg.msg_control = ubuf;
>> +msg.msg_controllen = sizeof(ubuf);
>
>'sizeof(ubuf)' where 'ubuf' is a pointer? Are you sure it shouldn't
> be 'sizeof(*ubuf)'?
Yes, pointer is sufficiet. Vhost allocate an arrays of ubuf and
tun/macvtap just need a reference of it.
>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" 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: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
On 09/01/2013 10:06 PM, Gleb Natapov wrote:
> On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
>> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
>> and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
>> them to user space which saves time on switching to user space and back.
>>
>> Both real and virtual modes are supported. The kernel tries to
>> handle a TCE request in the real mode, if fails it passes the request
>> to the virtual mode to complete the operation. If it a virtual mode
>> handler fails, the request is passed to user space.
>>
>> The first user of this is VFIO on POWER. Trampolines to the VFIO external
>> user API functions are required for this patch.
>>
>> This adds a "SPAPR TCE IOMMU" KVM device to associate a logical bus
>> number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
>> of map/unmap requests. The device supports a single attribute which is
>> a struct with LIOBN and IOMMU fd. When the attribute is set, the device
>> establishes the connection between KVM and VFIO.
>>
>> Tests show that this patch increases transmission speed from 220MB/s
>> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
>>
>> Signed-off-by: Paul Mackerras
>> Signed-off-by: Alexey Kardashevskiy
>>
>> ---
>>
>> Changes:
>> v9:
>> * KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with "SPAPR TCE IOMMU"
>> KVM device
>> * release_spapr_tce_table() is not shared between different TCE types
>> * reduced the patch size by moving VFIO external API
>> trampolines to separate patche
>> * moved documentation from Documentation/virtual/kvm/api.txt to
>> Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>>
>> v8:
>> * fixed warnings from check_patch.pl
>>
>> 2013/07/11:
>> * removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
>> for KVM_BOOK3S_64
>> * kvmppc_gpa_to_hva_and_get also returns host phys address. Not much sense
>> for this here but the next patch for hugepages support will use it more.
>>
>> 2013/07/06:
>> * added realmode arch_spin_lock to protect TCE table from races
>> in real and virtual modes
>> * POWERPC IOMMU API is changed to support real mode
>> * iommu_take_ownership and iommu_release_ownership are protected by
>> iommu_table's locks
>> * VFIO external user API use rewritten
>> * multiple small fixes
>>
>> 2013/06/27:
>> * tce_list page is referenced now in order to protect it from accident
>> invalidation during H_PUT_TCE_INDIRECT execution
>> * added use of the external user VFIO API
>>
>> 2013/06/05:
>> * changed capability number
>> * changed ioctl number
>> * update the doc article number
>>
>> 2013/05/20:
>> * removed get_user() from real mode handlers
>> * kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
>> translated TCEs, tries realmode_get_page() on those and if it fails, it
>> passes control over the virtual mode handler which tries to finish
>> the request handling
>> * kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
>> on a page
>> * The only reason to pass the request to user mode now is when the user mode
>> did not register TCE table in the kernel, in all other cases the virtual mode
>> handler is expected to do the job
>> ---
>> .../virtual/kvm/devices/spapr_tce_iommu.txt| 37 +++
>> arch/powerpc/include/asm/kvm_host.h| 4 +
>> arch/powerpc/kvm/book3s_64_vio.c | 310
>> -
>> arch/powerpc/kvm/book3s_64_vio_hv.c| 122
>> arch/powerpc/kvm/powerpc.c | 1 +
>> include/linux/kvm_host.h | 1 +
>> virt/kvm/kvm_main.c| 5 +
>> 7 files changed, 477 insertions(+), 3 deletions(-)
>> create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>>
>> diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>> b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>> new file mode 100644
>> index 000..4bc8fc3
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
>> @@ -0,0 +1,37 @@
>> +SPAPR TCE IOMMU device
>> +
>> +Capability: KVM_CAP_SPAPR_TCE_IOMMU
>> +Architectures: powerpc
>> +
>> +Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
>> +
>> +Groups:
>> + KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
>> + Attributes: single attribute with pair { LIOBN, IOMMU fd}
>> +
>> +This is completely made up device which provides API to link
>> +logical bus number (LIOBN) and IOMMU group. The user space has
>> +to create a new SPAPR TCE IOMMU device per a logical bus.
>> +
> Why not have one device that can handle multimple links?
I can do that. If I make it so, it won't even look as a device at all, just
some weird interface to KVM but ok. What bothers me is it is just a
question what I will have to do next. Because I can easily predict a
suggestion to move kvmppc_spapr_tce_table's (a links list) from
linux-next: manual merge of the net-next tree with Linus' tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c between commit
64c3b252e9fc ("net: stmmac: fixed the pbl setting with DT") from the
tree and commit e2a240c7d3bc ("driver:net:stmmac: Disable DMA store and
forward mode if platform data force_thresh_dma_mode is set") from the
net-next tree.
I fixed it up (I think - see below) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1c83a44,623ebc5..000
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@@ -71,18 -71,19 +71,23 @@@ static int stmmac_probe_config_dt(struc
plat->force_sf_dma_mode = 1;
}
- dma_cfg = devm_kzalloc(>dev, sizeof(*dma_cfg), GFP_KERNEL);
- if (!dma_cfg)
- return -ENOMEM;
-
- plat->dma_cfg = dma_cfg;
- of_property_read_u32(np, "snps,pbl", _cfg->pbl);
- dma_cfg->fixed_burst = of_property_read_bool(np, "snps,fixed-burst");
- dma_cfg->mixed_burst = of_property_read_bool(np, "snps,mixed-burst");
+ if (of_find_property(np, "snps,pbl", NULL)) {
+ dma_cfg = devm_kzalloc(>dev, sizeof(*dma_cfg),
+ GFP_KERNEL);
+ if (!dma_cfg)
+ return -ENOMEM;
+ plat->dma_cfg = dma_cfg;
+ of_property_read_u32(np, "snps,pbl", _cfg->pbl);
+ dma_cfg->fixed_burst =
+ of_property_read_bool(np, "snps,fixed-burst");
+ dma_cfg->mixed_burst =
+ of_property_read_bool(np, "snps,mixed-burst");
+ }
+ plat->force_thresh_dma_mode = of_property_read_bool(np,
"snps,force_thresh_dma_mode");
+ if (plat->force_thresh_dma_mode) {
+ plat->force_sf_dma_mode = 0;
+ pr_warn("force_sf_dma_mode is ignored if force_thresh_dma_mode
is set.");
+ }
return 0;
}
pgpNtiu2cjpKk.pgp
Description: PGP signature
Re: Re: [PATCH] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking of ioapic_lock
Hi Eric and Don, Sorry for the late reply. (2013/08/31 9:58), Eric W. Biederman wrote: > Don Zickus writes: > >> On Tue, Aug 27, 2013 at 12:41:51PM +0900, Yoshihiro YUNOMAE wrote: >>> Hi Don, >>> >>> Sorry for the late reply. >>> >>> (2013/08/22 22:11), Don Zickus wrote: On Thu, Aug 22, 2013 at 05:38:07PM +0900, Yoshihiro YUNOMAE wrote: >> So, I agree with Eric, let's remove the disable_IO_APIC() stuff and keep >> the code simpler. > > Thank you for commenting about my patch. > I didn't know you already have submitted the patches for this deadlock > problem. > > I can't answer definitively right now that no problems are induced by > removing disable_IO_APIC(). However, my patch should be work well (and > has already been merged to -tip tree). So how about taking my patch at > first, and then discussing the removal of disabled_IO_APIC()? It doesn't matter to me. My orignal patch last year was similar to yours until it was suggested that we were working around a problem which was we shouldn't touch the IO_APIC code on panic. Then I wrote the removal of disable_IO_APIC patch and did lots of testing on it. I don't think I have seen any issues with it (just the removal of disabling the lapic stuff). >>> >>> Yes, you really did a lot of testing about this problem according to >>> your patch(https://lkml.org/lkml/2012/1/31/391). Although you >>> said jiffies calibration code does not need the PIT in >>> http://lists.infradead.org/pipermail/kexec/2012-February/006017.html, >>> I don't understand yet why we can remove disable_IO_APIC. >>> Would you please explain about the calibration codes? >> >> I forgot a lot of this, Eric B. might remember more (as he was the one that >> pointed this out initially). I believe initially the io_apic had to be in >> a pre-configured state in order to do some early calibration of the timing >> code. Later on, it was my understanding, that the calibration of various >> time keeping stuff did not need the io_apic in a correct state. The code >> might have switched to tsc instead of PIT, I forget. > > Yes. Alan Coxe's initial SMP port had a few cases where it still > exepected the system to be in PIT mode during boot and it took us a > decade or so before those assumptions were finally expunged. Would you please tell me the commit ID or the hint like files, functions, or when? >> Then again looking at the output of the latest dmesg, it seems the IO APIC >> is initialized way before the tsc is calibrated. So I am not sure what >> needed to get done or what interrupts are needed before the IO APIC gets >> initialized. > > The practical issue is that jiffies was calibrated off of the PIT timer > if I recall. But that is all old news. Are the jiffies calibration codes calibrate_delay()? It seems that the jiffies calibration have not used PIT in 2005 according to 8a9e1b0. >>> By the way, can we remove disable_IO_APIC even if an old dump capture >>> kernel is used? >> >> Good question. I did a bunch of testing with RHEL-6 too, which is 2.6.32 >> based. But I think we added some IRR fixes (commit 1e75b31d638), which >> may or may not have helped in this case. So I don't know when a kernel >> started worked correctly during init (with the right changes). I believe >> 2.6.32 had everything. > > A sufficient old and buggy dump capture kernel will fail because of bugs > in it's startup path, but I don't think anyone cares. OK, if the jiffies calibration problem has been fixed in the old days, we don't need to care for the old kernel. > The kernel startup path has been fixed for years, and disable_IO_APIC in > crash_kexec has always been a bug work-around for deficiencies in the > kernel's start up path (not part of the guaranteed interface). > Furthermore every real system configuration I have encountered used the > same kernel version for the crashdump kernel and the production kernel. > So we should be good. We also will be use the kdump(crashdump) kernel as the production kernel. Should I only care for the current kernel? Thanks, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 5/6] vhost_net: poll vhost queue after marking DMA is done
On 08/31/2013 12:44 AM, Ben Hutchings wrote: > On Fri, 2013-08-30 at 12:29 +0800, Jason Wang wrote: >> We used to poll vhost queue before making DMA is done, this is racy if vhost >> thread were waked up before marking DMA is done which can result the signal >> to >> be missed. Fix this by always poll the vhost thread before DMA is done. > Does this bug only exist in net-next or is it older? Should the fix go > to net and stable branches? This should go for the stable branches too (3.4 above). Thanks for the checking. > > Ben. > >> Signed-off-by: Jason Wang >> --- >> drivers/vhost/net.c |9 + >> 1 files changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c >> index ff60c2a..d09c17c 100644 >> --- a/drivers/vhost/net.c >> +++ b/drivers/vhost/net.c >> @@ -308,6 +308,11 @@ static void vhost_zerocopy_callback(struct ubuf_info >> *ubuf, bool success) >> struct vhost_virtqueue *vq = ubufs->vq; >> int cnt = atomic_read(>kref.refcount); >> >> +/* set len to mark this desc buffers done DMA */ >> +vq->heads[ubuf->desc].len = success ? >> +VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN; >> +vhost_net_ubuf_put(ubufs); >> + >> /* >> * Trigger polling thread if guest stopped submitting new buffers: >> * in this case, the refcount after decrement will eventually reach 1 >> @@ -318,10 +323,6 @@ static void vhost_zerocopy_callback(struct ubuf_info >> *ubuf, bool success) >> */ >> if (cnt <= 2 || !(cnt % 16)) >> vhost_poll_queue(>poll); >> -/* set len to mark this desc buffers done DMA */ >> -vq->heads[ubuf->desc].len = success ? >> -VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN; >> -vhost_net_ubuf_put(ubufs); >> } >> >> /* Expects to be always run from workqueue - which acts as -- 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 v2] h8300/kernel/setup.c: add "linux/initrd.h" to pass compiling
On 08/30/2013 07:12 PM, Guenter Roeck wrote: > On 08/29/2013 10:49 PM, Chen Gang wrote: >> On 08/30/2013 12:32 PM, Guenter Roeck wrote: >>> On 08/29/2013 08:59 PM, Chen Gang wrote: The related error (allmodconfig for h8300): arch/h8300/kernel/setup.c: In function 'setup_arch': arch/h8300/kernel/setup.c:103:3: error: 'initrd_start' undeclared (first use in this function) initrd_start = memory_start; ^ arch/h8300/kernel/setup.c:103:3: note: each undeclared identifier is reported only once for each function it appears in arch/h8300/kernel/setup.c:104:3: error: 'initrd_end' undeclared (first use in this function) initrd_end = memory_start += be32_to_cpu(((unsigned long *) (memory_start))[2]); ^ Signed-off-by: Chen Gang --- arch/h8300/kernel/setup.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c index d0b1607..85639a1 100644 --- a/arch/h8300/kernel/setup.c +++ b/arch/h8300/kernel/setup.c @@ -47,6 +47,10 @@ #include #endif +#if defined(CONFIG_BLK_DEV_INITRD) +#include +#endif + >>> >>> Is the #ifdef/#endif really needed ? If not you should drop it. >>> >> >> "linux/initrd.h" is needed by 'initrd_start' and 'initrd_end' when >> BLK_DEV_INITRD enabled. >> >> 'memory_start' is defined within this file, and also only one place may >> use "linux/initrd.h" within this file. >> >> So if BLK_DEV_INITRD disabled, do not need "linux/initrd.h" either. >> > > I didn't ask if the include is needed, I asked if the ifdef is needed. > Adding "ifdef" can mach original/local code style (no matter whether the code style is good or not), > The goal is to reduce the number of ifdefs in the code. We should not > include new ones if not necessary. That there are already other > (possibly unnecessary) ifdefs in the code doesn't mean we should add new > ones. > Yeah, if necessary, we need send additional patch to try to reduce all of "ifdef" within this ".c" file. In my opinion, we'd better to avoid 2 or more coding styles in one ".c" file. > Guenter > Thanks. -- Chen Gang -- 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: perf_event: rdpmc self-monitoring overhead issue
Stephane Eranian writes: > I don't see a flag in mmap() to fault it in immediately. MAP_PRESENT -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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: [PATCHv2 00/25] perf tool: Add support for multiple data file storage
On Sun, Sep 01, 2013 at 12:36:11PM +0200, Jiri Olsa wrote: > hi, > sending the support for multiple file storage. Initial > RFC is here: > http://marc.info/?l=linux-kernel=137408381902423=2 Just a general comment. If you repost please always keep the overview description/motivation in 0/0. -Andi -- 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: [PATCHv2 4/4] Documentation: Add device tree bindings for Freescale FTM PWM.
> Subject: Re: [PATCHv2 4/4] Documentation: Add device tree bindings for
> Freescale FTM PWM.
>
...
> > +
> > +pwm0: pwm@40038000 {
> > + compatible = "fsl,vf610-ftm-pwm";
> > + reg = <0x40038000 0x1000>;
> > + #pwm-cells = <3>;
> > + clock-names = "ftm0", "ftm0_fix_sel", "ftm0_ext_sel";
> > + clocks = < VF610_CLK_FTM0>,
> > + < VF610_CLK_FTM0_FIX_SEL>,
> > + < VF610_CLK_FTM0_EXT_SEL>;
> > + pinctrl-names = "ch0-active", "ch0-idle", "ch1-active", "ch1-
> idle",
> > + ;
> > + pinctrl-0 = <_pwm0_ch0_active>;
> > + pinctrl-1 = <_pwm0_ch0_idle>;
> > + pinctrl-2 = <_pwm0_ch1_active>;
> > + pinctrl-3 = <_pwm0_ch1_idle>;
> > + ...
> > + fsl,pwm-counter-clk = "ftm0_ext_sel";
> > + fsl,pwm-avaliable-chs = <0 3 5 6>;
>
> I don't think this proerty is useful. Just enable all channels. I think
> this was mentioned before.
>
Yes.
Actully this property is located in board level dts file.
I have added and requested all the channels in SoC level dtsi file, and in
board level dts file to tell the customer the limitation, I think is much
safter and better.
--
Best Regards.
Xiubo
--
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/4] regmap: Add regmap_fields APIs
Hi > Current Linux kernel is supporting regmap_field method > and it is very useful feature. > It needs one regmap_filed for one register access. > > OTOH, there is multi port device which > has many same registers in the market. > The difference for each port register access is > only its address offset. > > Current API needs many regmap_field for such device, > but it is not good. > This patch adds new regmap_fileds API which can care > about multi port/offset access via regmap. > > Signed-off-by: Kuninori Morimoto I noticed that this series didin't care EXPORT_SYMBOL_GPL() name (many same names) Please give me v2 chance Best regards --- Kuninori Morimoto -- 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] x86, apic: Disable BSP if boot cpu is AP
(2013/08/31 14:22), Borislav Petkov wrote:
On Thu, Aug 29, 2013 at 06:28:04PM +0900, HATAYAMA Daisuke wrote:
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 66cab35..fd969d1 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2113,13 +2113,29 @@ void disconnect_bsp_APIC(int virt_wire_setup)
apic_write(APIC_LVT1, value);
}
-void generic_processor_info(int apicid, int version)
+void generic_processor_info(int apicid, bool isbsp, int version)
{
int cpu, max = nr_cpu_ids;
bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
phys_cpu_present_map);
/*
+* If boot cpu is AP, we now don't have any way to initialize
+* BSP. To save memory consumed, we disable BSP this case and
I don't think we disable the BSP just so that we save memory and rather
because we hang in the kdump kernel otherwise, right?
Thanks for your reviewing.
Yes, primary reason of disabling BSP is to avoid hang/reset in the kdump
2nd kernel. Saving memory is the secondary merit compared with
the user-space workaround by specifying nr_cpus=1 or maxcpus=1 and
waking up APs later except for the BSP. I will not write this in the
next version.
+* use (N-1)-cpus.
+*/
+ if (isbsp && !boot_cpu_is_bsp) {
This variable naming looks confusing, IMHO. It would probably be more
understandable if 'isbsp' was called 'boot_cpu' to denote that this is
the CPU we're booting on currently. The comment above it then explains
that it is an AP and it might also refer to the issue why we're doing
that.
As you suggest, boot_cpu seems more understandable also to me. BTW, please
notice that it doesn't denote that the CPU we're booting on currently,
but that the CPU with BSP flag set.
In general, current code uses many terms to denote the cpu that is run
at kernel boot-up processing such as boot cpu, bsp, cpu0 and possibly others
since in usual situation, boot cpu is always BSP and assigned to cpu0.
But it is not the case in case of kexec. I'm using the word bsp purposely
in the isbsp to mean the CPU with BSP flag set.
So I think it's better to use bsp_cpu here to denote the CPU with BSP flag set.
For the comment, how about the following one?
/*
* In this case, boot cpu is AP. This can happen on
* kexec/kdump. Consider the case that crash happens on some
* AP and enters kdump 2nd kernel with the AP.
*
* Then, there's issue that if we send INIT to BSP, due to x86
* hardware specification, it is forced to jump at BIOS init
* code and system hangs or resets immediately.
*
* To avoid the issue, we disable BSP. Then, there's no longer
* possbility to send INIT to BSP.
*/
+ int thiscpu = num_processors + disabled_cpus;
+
+ pr_warning("ACPI: The boot cpu is not BSP. "
+ "The BSP Processor %d/0x%x ignored.\n",
+ thiscpu, apicid);
Visible comment, so needs a bit of correcting:
"ACPI: We're not booting on the BSP; BSP %d/0x%x ignored."
Yes, I'll use this message in the next patch.
+
+ disabled_cpus++;
+ return;
+ }
+
+ /*
* If boot cpu has not been detected yet, then only allow upto
* nr_cpu_ids - 1 processors and keep one slot free for boot cpu
*/
Thanks.
--
Thanks.
HATAYAMA, Daisuke
--
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 v3 0/3] cleanup of gpio_pcf857x.c
This patch series - removes the irq_demux_work - Uses devm_request_threaded_irq - Call the user handler iff gpio_to_irq is done. v1 --> v2 Split v1 to 3 patches v2 --> v3 Remove the unnecessary dts patches. George Cherian (3): gpio: pcf857x: change to devm_request_threaded_irq gpio: pcf857x: remove the irq_demux_work gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done drivers/gpio/gpio-pcf857x.c | 51 +++-- 1 file changed, 26 insertions(+), 25 deletions(-) -- 1.8.1.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 v3 3/3] gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done
For pcf857x driver if the initial state is not set properly (proper
n_latch is not passed), we get bad irq prints on console.
We get this only for the first interrupt and doesnot repeat for further
interrupts unles and until there are other gpio pins which are not flipping
continously.
following prints are seen on console.
[ 40.983924] irq 0, desc: ce004080, depth: 1, count: 0, unhandled: 0
[ 40.990511] ->handle_irq(): c00aa538, handle_bad_irq+0x0/0x260
[ 40.996768] ->irq_data.chip(): c080b6ec, no_irq_chip+0x0/0x60
[ 41.002842] ->action(): (null)
[ 41.006242]IRQ_NOPROBE set
[ 41.009465] IRQ_NOREQUEST set
Signed-off-by: George Cherian
---
drivers/gpio/gpio-pcf857x.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 4890e97..578d93f 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -93,6 +93,7 @@ struct pcf857x {
unsignedout;/* software latch */
unsignedstatus; /* current status */
int irq;/* real irq number */
+ unsignedirq_mapped; /* mapped gpio irqs */
int (*write)(struct i2c_client *client, unsigned data);
int (*read)(struct i2c_client *client);
@@ -185,8 +186,13 @@ static void pcf857x_set(struct gpio_chip *chip, unsigned
offset, int value)
static int pcf857x_to_irq(struct gpio_chip *chip, unsigned offset)
{
struct pcf857x *gpio = container_of(chip, struct pcf857x, chip);
+ int ret;
- return irq_create_mapping(gpio->irq_domain, offset);
+ ret = irq_create_mapping(gpio->irq_domain, offset);
+ if (ret > 0)
+ gpio->irq_mapped |= (1 << offset);
+
+ return ret;
}
static irqreturn_t pcf857x_irq(int irq, void *data)
@@ -198,7 +204,12 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
spin_lock_irqsave(>slock, flags);
- change = gpio->status ^ status;
+ /*
+* call the interrupt handler iff gpio is used as
+* interrupt source, just to avoid bad irqs
+*/
+
+ change = ((gpio->status ^ status) & gpio->irq_mapped);
for_each_set_bit(i, , gpio->chip.ngpio)
generic_handle_irq(irq_find_mapping(gpio->irq_domain, i));
gpio->status = status;
@@ -211,9 +222,14 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
static int pcf857x_irq_domain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hw)
{
+ struct pcf857x *gpio = domain->host_data;
+
irq_set_chip_and_handler(virq,
_irq_chip,
handle_level_irq);
+ set_irq_flags(virq, IRQF_VALID);
+ gpio->irq_mapped |= (1 << hw);
+
return 0;
}
@@ -236,7 +252,7 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
gpio->irq_domain = irq_domain_add_linear(client->dev.of_node,
gpio->chip.ngpio,
_irq_domain_ops,
-NULL);
+gpio);
if (!gpio->irq_domain)
goto fail;
--
1.8.1.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 2/2] dma: k3dma: use devm_ioremap_resource() instead of devm_request_and_ioremap()
On 13-09-02 09:26 AM, Jingoo Han wrote:
Use devm_ioremap_resource() because devm_request_and_ioremap() is
obsoleted by devm_ioremap_resource().
Signed-off-by: Jingoo Han
Thanks Jingoo for point out.
Acked-by: Zhangfei Gao
---
drivers/dma/k3dma.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index ef7bc85..a2c330f 100644
--- a/drivers/dma/k3dma.c
+++ b/drivers/dma/k3dma.c
@@ -673,9 +673,9 @@ static int k3_dma_probe(struct platform_device *op)
if (!d)
return -ENOMEM;
- d->base = devm_request_and_ioremap(>dev, iores);
- if (!d->base)
- return -EADDRNOTAVAIL;
+ d->base = devm_ioremap_resource(>dev, iores);
+ if (IS_ERR(d->base))
+ return PTR_ERR(d->base);
of_id = of_match_device(k3_pdma_dt_ids, >dev);
if (of_id) {
--
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 v3 2/3] gpio: pcf857x: remove the irq_demux_work
Now that we are using devm_request_threaded_irq no need for
irq_demux_work. Remove all its references.
Signed-off-by: George Cherian
---
drivers/gpio/gpio-pcf857x.c | 35 ---
1 file changed, 35 deletions(-)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 4d0d28c..4890e97 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -30,7 +30,6 @@
#include
#include
#include
-#include
static const struct i2c_device_id pcf857x_id[] = {
@@ -89,7 +88,6 @@ struct pcf857x {
struct gpio_chipchip;
struct i2c_client *client;
struct mutexlock; /* protect 'out' */
- struct work_struct work; /* irq demux work */
struct irq_domain *irq_domain;/* for irq demux */
spinlock_t slock; /* protect irq demux */
unsignedout;/* software latch */
@@ -210,38 +208,6 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
return IRQ_HANDLED;
}
-static void pcf857x_irq_demux_work(struct work_struct *work)
-{
- struct pcf857x *gpio = container_of(work,
- struct pcf857x,
- work);
- unsigned long change, i, status, flags;
-
- status = gpio->read(gpio->client);
-
- spin_lock_irqsave(>slock, flags);
-
- change = gpio->status ^ status;
- for_each_set_bit(i, , gpio->chip.ngpio)
- generic_handle_irq(irq_find_mapping(gpio->irq_domain, i));
- gpio->status = status;
-
- spin_unlock_irqrestore(>slock, flags);
-}
-
-static irqreturn_t pcf857x_irq_demux(int irq, void *data)
-{
- struct pcf857x *gpio = data;
-
- /*
-* pcf857x can't read/write data here,
-* since i2c data access might go to sleep.
-*/
- schedule_work(>work);
-
- return IRQ_HANDLED;
-}
-
static int pcf857x_irq_domain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hw)
{
@@ -284,7 +250,6 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
goto fail;
/* enable gpio_to_irq() */
- INIT_WORK(>work, pcf857x_irq_demux_work);
gpio->chip.to_irq = pcf857x_to_irq;
gpio->irq = client->irq;
--
1.8.1.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 v3 1/3] gpio: pcf857x: change to devm_request_threaded_irq
Remove the request_irq and use devm_request_threaded_irq
also cleanup free_irq. devm_* takes care of that.
Signed-off-by: George Cherian
---
drivers/gpio/gpio-pcf857x.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 947cff4..4d0d28c 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -191,6 +191,25 @@ static int pcf857x_to_irq(struct gpio_chip *chip, unsigned
offset)
return irq_create_mapping(gpio->irq_domain, offset);
}
+static irqreturn_t pcf857x_irq(int irq, void *data)
+{
+ struct pcf857x *gpio = data;
+ unsigned long change, i, status, flags;
+
+ status = gpio->read(gpio->client);
+
+ spin_lock_irqsave(>slock, flags);
+
+ change = gpio->status ^ status;
+ for_each_set_bit(i, , gpio->chip.ngpio)
+ generic_handle_irq(irq_find_mapping(gpio->irq_domain, i));
+ gpio->status = status;
+
+ spin_unlock_irqrestore(>slock, flags);
+
+ return IRQ_HANDLED;
+}
+
static void pcf857x_irq_demux_work(struct work_struct *work)
{
struct pcf857x *gpio = container_of(work,
@@ -241,8 +260,6 @@ static void pcf857x_irq_domain_cleanup(struct pcf857x *gpio)
if (gpio->irq_domain)
irq_domain_remove(gpio->irq_domain);
- if (gpio->irq)
- free_irq(gpio->irq, gpio);
}
static int pcf857x_irq_domain_init(struct pcf857x *gpio,
@@ -258,8 +275,11 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
goto fail;
/* enable real irq */
- status = request_irq(client->irq, pcf857x_irq_demux, 0,
-dev_name(>dev), gpio);
+ status = devm_request_threaded_irq(>dev, client->irq,
+ NULL, pcf857x_irq, IRQF_ONESHOT |
+ IRQF_TRIGGER_FALLING,
+ dev_name(>dev), gpio);
+
if (status)
goto fail;
--
1.8.1.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 1/5] jump_label: factor out the base part of jump_label.h to a separate file
On Fri, Aug 30, 2013 at 06:37:33PM +0200, Radim Krčmář wrote: > 2013-08-25 15:15+0800, Kevin Hao: > > We plan to use the jump label in the cpu/mmu feature check on ppc. > > This will need to include the jump_label.h in several very basic header > > files of ppc which seems to be included by most of the other head > > files implicitly or explicitly. But in the current jump_label.h, > > it also include the "linux/workqueue.h" and this will cause recursive > > inclusion. In order to fix this, we choose to factor out the base > > part of jump_label.h to a separate header file and we can include > > that file instead of jump_label.h to avoid the recursive inclusion. > > No functional change. > > "linux/workqueue.h" was included because of deferred keys and they are > split into "linux/jump_label_ratelimit.h" to solve the same problem in > paravirt ticket spinlock series. > (still in -next: 851cf6e7 jump_label: Split jumplabel ratelimit) OK. I will respin a new version based on this patch. Thanks for the information Radim. Thanks, Kevin pgpnObBkhbr6p.pgp Description: PGP signature
RE: [PATCH 4/4] Documentation: Add device tree bindings for Freescale FTM PWM
> Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for > Freescale FTM PWM > > Should have at least something w/regards to a commit message. > I have sent a V2 patch and have added it. > > + used to encode the polarity of PWM output. Set bit 0 of the third > > +in PWM > > + specifier to 1 for inverse polarity & set to 0 for normal polarity. > > +- fsl,pwm-clk-ps: the ftm0 pwm clock's prescaler, divide-by 2^n(n = 0 > ~ 7). > > +- fsl,pwm-cpwm: Center-Aligned PWM (CPWM) mode. > > Should describe this in more detail, what does the value actually mean > for what modes there are? > It's maybe a very useful feature for FTM core, but for PWM is not. This isn't needed any more for PWM, and in V2 patch I have removed CPWM mode. > > +- fsl,pwm-number: the number of PWM devices, and is must equal to the > > +number > > + of "fsl,pwm-channels". > > If they must be equal why do we need both? > I have replaced both of them too in V2. > > +- fsl,pwm-channels: the channels' order which is be used for pwm in > > +ftm0 > > + module, and they must be one or some of 0 ~ 7, because the ftm0 > > +only has > > + 8 channels can be used. > > +- for very channel, the revlatived the pinctrl should be at least two > > +state > > revlatived? > This too. -- Best Regards. Xiubo -- 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/6] x86: simplify _acpi_map_lsapic()
On 2013-9-1 4:14, Rafael J. Wysocki wrote:
> On Saturday, August 31, 2013 06:15:58 PM Hanjun Guo wrote:
[...]
>> +static int acpi_register_lapic(int id, u8 enabled)
>> {
>> unsigned int ver = 0;
>>
>> if (id >= (MAX_LOCAL_APIC-1)) {
>> printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
>> -return;
>> +return -1;
>> }
>>
>> if (!enabled) {
>> ++disabled_cpus;
>> -return;
>> +return -1;
>> }
>
> If this returned -EINVAL instead of just -1, ->
>
>>
>> if (boot_cpu_physical_apicid != -1U)
>> ver = apic_version[boot_cpu_physical_apicid];
>>
>> -generic_processor_info(id, ver);
>> +return generic_processor_info(id, ver);
>
> -> and this too (on errors), -->
>
>> }
>>
>> static int __init
>> @@ -622,44 +629,19 @@ static void acpi_map_cpu2node(acpi_handle handle, int
>> cpu, int physid)
>>
>> static int _acpi_map_lsapic(acpi_handle handle, int physid, int *pcpu)
>> {
>> -cpumask_var_t tmp_map, new_map;
>> int cpu;
>> -int retval = -ENOMEM;
>> -
>> -if (!alloc_cpumask_var(_map, GFP_KERNEL))
>> -goto out;
>>
>> -if (!alloc_cpumask_var(_map, GFP_KERNEL))
>> -goto free_tmp_map;
>> -
>> -cpumask_copy(tmp_map, cpu_present_mask);
>> -acpi_register_lapic(physid, ACPI_MADT_ENABLED);
>> -
>> -/*
>> - * If acpi_register_lapic successfully generates a new logical cpu
>> - * number, then the following will get us exactly what was mapped
>> - */
>> -cpumask_andnot(new_map, cpu_present_mask, tmp_map);
>> -if (cpumask_empty(new_map)) {
>> +cpu = acpi_register_lapic(physid, ACPI_MADT_ENABLED);
>> +if (cpu == -1) {
>> printk ("Unable to map lapic to logical cpu number\n");
>> -retval = -EINVAL;
>> -goto free_new_map;
>> +return -EINVAL;
>> }
>
> --> then this could be
>
> if (cpu < 0) {
> ...
> return cpu;
> }
Thanks for the suggestion, and I find out some grammar mistake in the
changelog too, I will update this patch set and send out soon.
Thanks
Hanjun
--
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 00/18 v3] Signature verification of hibernate snapshot
於 日，2013-09-01 於 18:40 +0200，Florian Weimer 提到： > * Matthew Garrett: > > > On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote: > > > >> But if you don't generate fresh keys on every boot, the persistent > >> keys are mor exposed to other UEFI applications. Correct me if I'm > >> wrong, but I don't think UEFI variables are segregated between > >> different UEFI applications, so if anyone gets a generic UEFI variable > >> dumper (or setter) signed by the trusted key, this cryptographic > >> validation of hibernate snapshots is bypassable. > > > > If anyone can execute arbitrary code in your UEFI environment then > > you've already lost. > > This is not about arbitrary code execution. The problematic > applications which conflict with this proposed functionality are not > necessarily malicious by themselves and even potentially useful. > > For example, if you want to provision a bunch of machines and you have > to set certain UEFI variables, it might be helpful to do so in an > unattended fashion, just by booting from a USB stick with a suitable > UEFI application. Is this evil? I don't think so. > -- Yes, if there have the kind of UEFI tools like you said, and it leak to attacker, then we lost. Even we re-generate key-pair for every S4, the tool, if it can set variable, means it can replace the public key that was stored by efi bootloader in bootservices variable. Then we still lost. When the tool can only dump variable but not set, then re-generate key-pair to every S4 can prevent it. If the tool can also set variable, then I don't think there have any way to protect key-pair in UEFI variables. Using TPM is a way to protect key-pair, but user need key-in password when generate and use key to sign stuff. It noises to user, but the best way to keep the password is in brain. Thanks a lot! Joey Lee -- 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] irqchip: irq-mxs: Include
From: Fabio Estevam Include in order to fix the following sparse warning: drivers/irqchip/irq-mxs.c:75:39: warning: symbol 'icoll_handle_irq' was not declared. Should it be static? Signed-off-by: Fabio Estevam --- drivers/irqchip/irq-mxs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/irqchip/irq-mxs.c b/drivers/irqchip/irq-mxs.c index 63b3d4e..4269f22 100644 --- a/drivers/irqchip/irq-mxs.c +++ b/drivers/irqchip/irq-mxs.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include -- 1.8.1.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: [PATCH v2 1/3] gpio: pcf857x: change to devm_request_threaded_irq
On 9/2/2013 6:50 AM, Kuninori Morimoto wrote: Hi Remove the request_irq and use devm_request_threaded_irq also cleanup free_irq. devm_* takes care of that. Signed-off-by: George Cherian --- arch/arm/boot/dts/dra7-evm.dts | 2 +- drivers/gpio/gpio-pcf857x.c| 28 2 files changed, 25 insertions(+), 5 deletions(-) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 8b0738a..39b44bc 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -65,7 +65,7 @@ n_latch = <0x1408>; gpio-controller; #gpio-cells = <2>; - interrupt-parent = <_20>; + interrupt-parent = <>; interrupts = <14 2>; interrupt-controller; #interrupt-cells = <2>; I'm not sure detail, but does above "exchange interrupt-parent" and "using devm_request_threaded_irq()" have any relationship ? Exactly. will resend this change alone. Separate patch seems nice ? okay Best regards --- Kuninori Morimoto -- -George -- 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] rcu: Make rcu_assign_pointer's assignment volatile and type-safe
On Sun, Sep 01, 2013 at 04:42:52PM -0700, Josh Triplett wrote:
> rcu_assign_pointer needs to use ACCESS_ONCE to make the assignment to
> the destination pointer volatile, to protect against compilers too
> clever for their own good.
>
> In addition, since rcu_assign_pointer force-casts the source pointer to
> add the __rcu address space (overriding any existing address space), add
> an explicit check that the source pointer has the __kernel address space
> to start with.
>
> This new check produces warnings like this, when attempting to assign
> from a __user pointer:
>
> test.c:25:9: warning: incorrect type in argument 2 (different address spaces)
> test.c:25:9:expected struct foo *
> test.c:25:9:got struct foo [noderef] *badsrc
>
> Signed-off-by: Josh Triplett
Queued for 3.13, thank you very much!
Thanx, Paul
> ---
> include/linux/rcupdate.h | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 4b14bdc..3f62def 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -510,8 +510,17 @@ static inline void rcu_preempt_sleep_check(void)
> #ifdef __CHECKER__
> #define rcu_dereference_sparse(p, space) \
> ((void)(((typeof(*p) space *)p) == p))
> +/* The dummy first argument in __rcu_assign_pointer_typecheck makes the
> + * typechecked pointer the second argument, matching rcu_assign_pointer
> itself;
> + * this avoids confusion about argument numbers in warning messages. */
> +#define __rcu_assign_pointer_check_kernel(v) \
> + do { \
> + extern void __rcu_assign_pointer_typecheck(int, typeof(*(v))
> __kernel *); \
> + __rcu_assign_pointer_typecheck(0, v); \
> + } while (0)
> #else /* #ifdef __CHECKER__ */
> #define rcu_dereference_sparse(p, space)
> +#define __rcu_assign_pointer_check_kernel(v) do { } while (0)
> #endif /* #else #ifdef __CHECKER__ */
>
> #define __rcu_access_pointer(p, space) \
> @@ -555,7 +564,8 @@ static inline void rcu_preempt_sleep_check(void)
> #define __rcu_assign_pointer(p, v, space) \
> do { \
> smp_wmb(); \
> - (p) = (typeof(*v) __force space *)(v); \
> + __rcu_assign_pointer_check_kernel(v); \
> + ACCESS_ONCE(p) = (typeof(*(v)) __force space *)(v); \
> } while (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/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
On 8/30/2013 12:44 PM, Chanwoo Choi wrote:
Hi George,
In addition, I add answer about that device driver control gpio pin directly.
On 08/30/2013 03:15 PM, George Cherian wrote:
Hi Chanwoo,
On 8/30/2013 5:41 AM, Chanwoo Choi wrote:
Hi George,
On 08/29/2013 10:45 PM, George Cherian wrote:
Hi Chanwoo,
On 8/29/2013 5:42 PM, Chanwoo Choi wrote:
[big snip ]
I tested various development board based on Samsung Exynos series SoC.
Although some gpio of Exynos series SoC set high state(non zero, 1) as default
value,
this gpio state could mean off state, disconnected or un-powered state
according to gpio.
Of course, above explanation about specific gpio don't include all gpios.
This is meaning that there is possibility.
okay then how about adding a flag for inverted logic too. something like this
if(of_property_read_bool(np,"inverted_gpio))
gpio_usbvid->gpio_inv = 1;
And always check on this before deciding?
Is this fine ?
OK.
But, as Stephen commented on other mail, you should use proper DT helper
function.
okay
Second,
gpio_usbvid_set_initial_state() dertermine both "USB-HOST" and "USB" cable
state at same time
in 'case ID_DETCT' according to 'gpio_usbvid->id_gpio'. But, I think that other
extcon devices
would not control both "USB-HOST" and "USB" cable state at same time.
Other extcon devices would support either "USB-HOST" or "USB" cable.
The driver has 2 configurations.
1) supports implementations with both VBUS and ID pin are routed via gpio's for
swicthing roles(compatible gpio-usb-vid).
As you explained about case 1, it is only used on dra7x SoC.
No gpio-usb-id is used in dra7xx. dra7xx has got only ID pin routed via gpio.
Other SoC could not wish to control both "USB-HOST" and "USB" cable at same
time.
I could'nt actually parse this. You meant since the id_irq_handler handles both
USB and USB-HOST cable
its not proper?
It's not proper in general case. The generic driver must guarantee all of
extcon device using gpio.
As far as I know, the generic driver cannot direclty control gpio pin and get
value from gpio pin.
Almost device driver including in kernel/drivers control gpio pin on specific
device driver
instead of generic driver.
But without reading the gpio value how can we set the cable states?
hmm. I mentioned above my answer as following:
>> As far as I know, the generic driver cannot direclty control gpio
pin and get value from gpio pin.
>> Almost device driver including in kernel/drivers control gpio pin on
specific device driver
Because your extcon driver directly control gpio pin so I think your extcon
driver isn't generic.
for this driver the assumption is the dedicated gpio
Obviously when I am writing a generic driver for USB VBUS-ID detetction
which is via gpio then i assume I have a dedicated gpio.
what is wrong in that assumption? How else can you detect ID pin change
and VBUS change via gpio if not you have them dedicated?
is always DIR_IN and in the driver we just read the value.
What is DIR_IN?
Direction IN gpio.
I need your answer about above my opinion for other SoC.
So how about this, I have removed the dra7x specific stuffs (gpio-usb-id)
static void gpio_usbvid_set_initial_state(struct gpio_usbvid *gpio_usbvid)
{
int id_current, vbus_current;
id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
if (!!id_current == ID_FLOAT)
extcon_set_cable_state(_usbvid->edev, "USB-HOST", false);
else
extcon_set_cable_state(_usbvid->edev, "USB-HOST", true);
vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
if (!!vbus_current == VBUS_ON)
extcon_set_cable_state(_usbvid->edev, "USB", true);
else
extcon_set_cable_state(_usbvid->edev, "USB", false);
}
and the irq handlers like this
static irqreturn_t id_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int id_current;
id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
if (id_current == ID_GND)
extcon_set_cable_state(_usbvid->edev, "USB-HOST", true);
else
extcon_set_cable_state(_usbvid->edev, "USB-HOST", false);
return IRQ_HANDLED;
}
static irqreturn_t vbus_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int vbus_current;
vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
if (vbus_current == VBUS_OFF)
extcon_set_cable_state(_usbvid->edev, "USB", false);
else
extcon_set_cable_state(_usbvid->edev, "USB", true);
return IRQ_HANDLED;
}
I know your intention dividing interrupt handler for each cable.
But I don't think this driver must guarantee all of extcon device using gpio.
For example,
below three SoC wish to detect USB/USB-HOST cable with each different methods.
Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
On 8/30/2013 12:23 PM, Chanwoo Choi wrote:
Hi George,
On 08/30/2013 03:15 PM, George Cherian wrote:
Hi Chanwoo,
On 8/30/2013 5:41 AM, Chanwoo Choi wrote:
Hi George,
On 08/29/2013 10:45 PM, George Cherian wrote:
Hi Chanwoo,
On 8/29/2013 5:42 PM, Chanwoo Choi wrote:
[big snip ]
I tested various development board based on Samsung Exynos series SoC.
Although some gpio of Exynos series SoC set high state(non zero, 1) as default
value,
this gpio state could mean off state, disconnected or un-powered state
according to gpio.
Of course, above explanation about specific gpio don't include all gpios.
This is meaning that there is possibility.
okay then how about adding a flag for inverted logic too. something like this
if(of_property_read_bool(np,"inverted_gpio))
gpio_usbvid->gpio_inv = 1;
And always check on this before deciding?
Is this fine ?
OK.
But, as Stephen commented on other mail, you should use proper DT helper
function.
okay
Second,
gpio_usbvid_set_initial_state() dertermine both "USB-HOST" and "USB" cable
state at same time
in 'case ID_DETCT' according to 'gpio_usbvid->id_gpio'. But, I think that other
extcon devices
would not control both "USB-HOST" and "USB" cable state at same time.
Other extcon devices would support either "USB-HOST" or "USB" cable.
The driver has 2 configurations.
1) supports implementations with both VBUS and ID pin are routed via gpio's for
swicthing roles(compatible gpio-usb-vid).
As you explained about case 1, it is only used on dra7x SoC.
No gpio-usb-id is used in dra7xx. dra7xx has got only ID pin routed via gpio.
Other SoC could not wish to control both "USB-HOST" and "USB" cable at same
time.
I could'nt actually parse this. You meant since the id_irq_handler handles both
USB and USB-HOST cable
its not proper?
It's not proper in general case. The generic driver must guarantee all of
extcon device using gpio.
As far as I know, the generic driver cannot direclty control gpio pin and get
value from gpio pin.
Almost device driver including in kernel/drivers control gpio pin on specific
device driver
instead of generic driver.
But without reading the gpio value how can we set the cable states? for this
driver the assumption is the dedicated gpio
is always DIR_IN and in the driver we just read the value.
I need your answer about above my opinion for other SoC.
So how about this, I have removed the dra7x specific stuffs (gpio-usb-id)
static void gpio_usbvid_set_initial_state(struct gpio_usbvid *gpio_usbvid)
{
int id_current, vbus_current;
id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
if (!!id_current == ID_FLOAT)
extcon_set_cable_state(_usbvid->edev, "USB-HOST", false);
else
extcon_set_cable_state(_usbvid->edev, "USB-HOST", true);
vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
if (!!vbus_current == VBUS_ON)
extcon_set_cable_state(_usbvid->edev, "USB", true);
else
extcon_set_cable_state(_usbvid->edev, "USB", false);
}
and the irq handlers like this
static irqreturn_t id_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int id_current;
id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
if (id_current == ID_GND)
extcon_set_cable_state(_usbvid->edev, "USB-HOST", true);
else
extcon_set_cable_state(_usbvid->edev, "USB-HOST", false);
return IRQ_HANDLED;
}
static irqreturn_t vbus_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int vbus_current;
vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
if (vbus_current == VBUS_OFF)
extcon_set_cable_state(_usbvid->edev, "USB", false);
else
extcon_set_cable_state(_usbvid->edev, "USB", true);
return IRQ_HANDLED;
}
I know your intention dividing interrupt handler for each cable.
But I don't think this driver must guarantee all of extcon device using gpio.
For example,
below three SoC wish to detect USB/USB-HOST cable with each different methods.
"SoC A" wish to detect USB/USB-HOST cable through only one gpio pin.
You mean to say that both USB ID pin and VBUS are connected to same gpio?
If so that is a really bad h/w design and it will not fly.
Or, you meant that only USB ID pin is connected to single gpio and it controls
the state of the USB/USB-HOST cables?
If so thats what exactly the v3 driver did with compatible gpio-usb-id.
My original question intention,
I'd like you to answer that this driver can support all case of "SoC A"/"SoC B"/"SoC
C" without othe implementation?
Definitely supports SoC A and SoC C. this is neither a generic extcon
driver nor a generic gpio driver.
This is a generic driver for USB VBUS-ID detection connected via gpios.
so doesnot
Re: [PATCH] block: trace all devices plug operation.
Hi axboe:
How about this patch?
Thanks!
Jianpeng Ma
>In func blk_queue_bio, if list of plug is empty,it will call
>blk_trace_plug.
>If process deal with a single device,it't ok.But if process deal with
>multi devices,it only trace the first device.
>Using request_count to judge, it can soleve this problem.
>
>In addition, i modify the comment.
>
>Signed-off-by: Jianpeng Ma
>---
> block/blk-core.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
>diff --git a/block/blk-core.c b/block/blk-core.c
>index 93a18d1..91037f7 100644
>--- a/block/blk-core.c
>+++ b/block/blk-core.c
>@@ -1549,11 +1549,9 @@ get_rq:
> if (plug) {
> /*
>* If this is the first request added after a plug, fire
>- * of a plug trace. If others have been added before, check
>- * if we have multiple devices in this plug. If so, make a
>- * note to sort the list before dispatch.
>+ * of a plug trace.
>*/
>- if (list_empty(>list))
>+ if (!request_count)
> trace_block_plug(q);
> else {
> if (request_count >= BLK_MAX_REQUEST_COUNT) {
>--
>1.8.3
Re: network stopped with a kernel error
lspci: 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03) 04:01.0 Ethernet controller: SysKonnect SK-9871 V2.0 Gigabit Ethernet 1000Base-ZX Adapter, PCI64, Fiber ZX/SC (rev 18) 04:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8129 (rev 10) 2013/9/1 Roberto Spadim : > the XID: > good card: > > Sep 1 11:41:41 localhost kernel: [4.332165] r8169 Gigabit > Ethernet driver 2.3LK-NAPI loaded > Sep 1 11:41:41 localhost kernel: [4.332184] r8169 :01:00.0: > PCI INT A -> GSI 17 (level, low) -> IRQ 17 > Sep 1 11:41:41 localhost kernel: [4.332236] r8169 :01:00.0: > setting latency timer to 64 > Sep 1 11:41:41 localhost kernel: [4.332283] r8169 :01:00.0: > irq 40 for MSI/MSI-X > Sep 1 11:41:41 localhost kernel: [4.332490] r8169 :01:00.0: > eth0: RTL8168d/8111d at 0xc900057a2000, f4:6d:04:cc:e9:13, XID > 083000c0 IRQ 40 > > > > bad card: > Sep 1 11:41:41 localhost kernel: [4.356510] r8169 Gigabit > Ethernet driver 2.3LK-NAPI loaded > Sep 1 11:41:41 localhost kernel: [4.356524] r8169 :04:02.0: > PCI INT A -> GSI 17 (level, low) -> IRQ 17 > Sep 1 11:41:41 localhost kernel: [4.356561] r8169 :04:02.0: > (unregistered net_device): no PCI Express capability > Sep 1 11:41:41 localhost kernel: [4.356569] r8169 :04:02.0: > (unregistered net_device): unknown MAC, using family default > Sep 1 11:41:41 localhost kernel: [4.356815] r8169 :04:02.0: > eth2: RTL8169 at 0xc90005796000, ff:ff:ff:ff:ff:ff, XID 1040 > IRQ 17 -- Roberto Spadim SPAEmpresarial -- 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: network stopped with a kernel error
the XID: good card: Sep 1 11:41:41 localhost kernel: [4.332165] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded Sep 1 11:41:41 localhost kernel: [4.332184] r8169 :01:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 Sep 1 11:41:41 localhost kernel: [4.332236] r8169 :01:00.0: setting latency timer to 64 Sep 1 11:41:41 localhost kernel: [4.332283] r8169 :01:00.0: irq 40 for MSI/MSI-X Sep 1 11:41:41 localhost kernel: [4.332490] r8169 :01:00.0: eth0: RTL8168d/8111d at 0xc900057a2000, f4:6d:04:cc:e9:13, XID 083000c0 IRQ 40 bad card: Sep 1 11:41:41 localhost kernel: [4.356510] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded Sep 1 11:41:41 localhost kernel: [4.356524] r8169 :04:02.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 Sep 1 11:41:41 localhost kernel: [4.356561] r8169 :04:02.0: (unregistered net_device): no PCI Express capability Sep 1 11:41:41 localhost kernel: [4.356569] r8169 :04:02.0: (unregistered net_device): unknown MAC, using family default Sep 1 11:41:41 localhost kernel: [4.356815] r8169 :04:02.0: eth2: RTL8169 at 0xc90005796000, ff:ff:ff:ff:ff:ff, XID 1040 IRQ 17 -- 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: network stopped with a kernel error
here the dmesg (from /var/log/kernel.log) http://pastebin.com/gcHgTYXZ -- 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] dma: k3dma: use devm_ioremap_resource() instead of devm_request_and_ioremap()
Use devm_ioremap_resource() because devm_request_and_ioremap() is
obsoleted by devm_ioremap_resource().
Signed-off-by: Jingoo Han
---
drivers/dma/k3dma.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index ef7bc85..a2c330f 100644
--- a/drivers/dma/k3dma.c
+++ b/drivers/dma/k3dma.c
@@ -673,9 +673,9 @@ static int k3_dma_probe(struct platform_device *op)
if (!d)
return -ENOMEM;
- d->base = devm_request_and_ioremap(>dev, iores);
- if (!d->base)
- return -EADDRNOTAVAIL;
+ d->base = devm_ioremap_resource(>dev, iores);
+ if (IS_ERR(d->base))
+ return PTR_ERR(d->base);
of_id = of_match_device(k3_pdma_dt_ids, >dev);
if (of_id) {
--
1.7.10.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 2/2] dma: k3dma: use devm_ioremap_resource() instead of devm_request_and_ioremap()
Use devm_ioremap_resource() because devm_request_and_ioremap() is
obsoleted by devm_ioremap_resource().
Signed-off-by: Jingoo Han
---
drivers/dma/k3dma.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index ef7bc85..a2c330f 100644
--- a/drivers/dma/k3dma.c
+++ b/drivers/dma/k3dma.c
@@ -673,9 +673,9 @@ static int k3_dma_probe(struct platform_device *op)
if (!d)
return -ENOMEM;
- d->base = devm_request_and_ioremap(>dev, iores);
- if (!d->base)
- return -EADDRNOTAVAIL;
+ d->base = devm_ioremap_resource(>dev, iores);
+ if (IS_ERR(d->base))
+ return PTR_ERR(d->base);
of_id = of_match_device(k3_pdma_dt_ids, >dev);
if (of_id) {
--
1.7.10.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] dma: sh: use devm_ioremap_resource() instead of devm_request_and_ioremap()
Use devm_ioremap_resource() because devm_request_and_ioremap() is obsoleted by devm_ioremap_resource(). Signed-off-by: Jingoo Han --- drivers/dma/sh/sudmac.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma/sh/sudmac.c b/drivers/dma/sh/sudmac.c index bf85b8e..7c1ffaa 100644 --- a/drivers/dma/sh/sudmac.c +++ b/drivers/dma/sh/sudmac.c @@ -358,9 +358,9 @@ static int sudmac_probe(struct platform_device *pdev) dma_dev = _dev->shdma_dev.dma_dev; - su_dev->chan_reg = devm_request_and_ioremap(>dev, chan); - if (!su_dev->chan_reg) - return err; + su_dev->chan_reg = devm_ioremap_resource(>dev, chan); + if (IS_ERR(su_dev->chan_reg)) + return PTR_ERR(su_dev->chan_reg); dma_cap_set(DMA_SLAVE, dma_dev->cap_mask); -- 1.7.10.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 1/2] mfd: 88pm800: Fix the bug that pdata may be NULL
On Fri, Aug 30, 2013 at 8:30 PM, Samuel Ortiz wrote: > Hi Xie, > > On Tue, Aug 27, 2013 at 02:11:58PM +0800, Chao Xie wrote: >> On Tue, Aug 20, 2013 at 9:40 AM, Samuel Ortiz wrote: >> > Hi Xie, >> > >> > On Sun, Aug 18, 2013 at 09:27:54PM -0400, Chao Xie wrote: >> >> User pass platform data to device, and platform data may be >> >> NULL. >> > In which case do you get that ? With DT ? >> > Should rtc_init fail when pdata is NULL ? >> > >> > You need to explain that, be it only for us to know if it's a critical >> > fix or not. >> > >> Sorry for late response. >> If pdata is NULL, the driver will fail. > The question is: Why would pdata be NULL ? If there's a fundamental > issue you're hiding with this patch, you probably want to fix the real > problem instead. > Maybe i do not explain it clearly. The error is detected y some software checking tool. Pdata is passed from dev->platform_data. If the user pass the dev->platform_data to be NULL, at least mfd device driver need detect it, and reject it if it is not accpetable like return -EINVAL. Then the following probing code will not cause kernel panic if we access pdata->xxx. > Cheers, > Samuel. > > -- > Intel Open Source Technology Centre > http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] gpio: pcf857x: change to devm_request_threaded_irq
Hi > Remove the request_irq and use devm_request_threaded_irq > also cleanup free_irq. devm_* takes care of that. > > Signed-off-by: George Cherian > --- > arch/arm/boot/dts/dra7-evm.dts | 2 +- > drivers/gpio/gpio-pcf857x.c| 28 > 2 files changed, 25 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts > index 8b0738a..39b44bc 100644 > --- a/arch/arm/boot/dts/dra7-evm.dts > +++ b/arch/arm/boot/dts/dra7-evm.dts > @@ -65,7 +65,7 @@ > n_latch = <0x1408>; > gpio-controller; > #gpio-cells = <2>; > - interrupt-parent = <_20>; > + interrupt-parent = <>; > interrupts = <14 2>; > interrupt-controller; > #interrupt-cells = <2>; I'm not sure detail, but does above "exchange interrupt-parent" and "using devm_request_threaded_irq()" have any relationship ? Separate patch seems nice ? Best regards --- Kuninori Morimoto -- 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/3] extcon: Simplify extcon_dev_register() prototype by removing unnecessary parameter
Hi Greg, On 09/02/2013 09:40 AM, Greg KH wrote: > On Mon, Sep 02, 2013 at 09:20:08AM +0900, Chanwoo Choi wrote: >> This patch remove extcon_dev_register()'s second parameter which means >> the pointer of parent device to simplify prototype of this function. > > No, please don't. You want the parent to be passed in, as the core > needs it when it is registered with the system, otherwise it will not > show up in sysfs properly (i.e. you can't set it afterwards.) Currently, each extcon driver have allocated memory for extcon device by using devm_kzalloc() in each extcon device driver.So,I have plan to implement "devm_extcon_allocate_device()" which allocate managed extcon device and connect with parent device(->dev.parent = dev). (I refer to devm_input_allocate_device() in drivers/input/input.c) So, This patch is precedence work before implementing devm_extcon_allocate_device() because the pointer of parent device have to pass devm_extcon_allocate_device() instead of extcon_dev_register(). I'm going to change registration prcedure for extcon device as following: Before: ret = extcon_dev_register(edev, dev); After: edev = devm_extcon_allocate_device(dev); ... ret = extcon_dev_register(edev); ... If you want me to send this feature including in 'devm_extcon_allocate_device()' at the same time, I'll complete this feature and then post this patchset again. > >> So, if extcon device has the parent device, it should set the pointer of >> parent device to edev.dev.parent in extcon device driver instead of in >> extcon_dev_register(). > > No it will break things if you do that :( Best Regards, Chanwoo Choi -- 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] imx-drm: imx-ldb: Staticize of_get_data_mapping()
From: Fabio Estevam
Staticize of_get_data_mapping() in order to fix the following sparse warning:
drivers/staging/imx-drm/imx-ldb.c:424:11: warning: symbol 'of_get_data_mapping'
was not declared. Should it be static?
Signed-off-by: Fabio Estevam
---
drivers/staging/imx-drm/imx-ldb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/imx-ldb.c
b/drivers/staging/imx-drm/imx-ldb.c
index af733ea..b81ed41 100644
--- a/drivers/staging/imx-drm/imx-ldb.c
+++ b/drivers/staging/imx-drm/imx-ldb.c
@@ -421,7 +421,7 @@ static const char *imx_ldb_bit_mappings[] = {
[LVDS_BIT_MAP_JEIDA] = "jeida",
};
-const int of_get_data_mapping(struct device_node *np)
+static const int of_get_data_mapping(struct device_node *np)
{
const char *bm;
int ret, i;
--
1.8.1.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: [PATCH 00/11] x86, memblock: Allocate memory near kernel image before SRAT parsed.
Hi guys, Any comment to this patch-set ? And shall agree on using this solution suggested by Tejun ? Thanks. On 08/27/2013 05:37 PM, Tang Chen wrote: This patch-set is based on tj's suggestion, and not fully tested. Just for review and discussion. [Problem] The current Linux cannot migrate pages used by the kerenl because of the kernel direct mapping. In Linux kernel space, va = pa + PAGE_OFFSET. When the pa is changed, we cannot simply update the pagetable and keep the va unmodified. So the kernel pages are not migratable. There are also some other issues will cause the kernel pages not migratable. For example, the physical address may be cached somewhere and will be used. It is not to update all the caches. When doing memory hotplug in Linux, we first migrate all the pages in one memory device somewhere else, and then remove the device. But if pages are used by the kernel, they are not migratable. As a result, memory used by the kernel cannot be hot-removed. Modifying the kernel direct mapping mechanism is too difficult to do. And it may cause the kernel performance down and unstable. So we use the following way to do memory hotplug. [What we are doing] In Linux, memory in one numa node is divided into several zones. One of the zones is ZONE_MOVABLE, which the kernel won't use. In order to implement memory hotplug in Linux, we are going to arrange all hotpluggable memory in ZONE_MOVABLE so that the kernel won't use these memory. To do this, we need ACPI's help. In ACPI, SRAT(System Resource Affinity Table) contains NUMA info. The memory affinities in SRAT record every memory range in the system, and also, flags specifying if the memory range is hotpluggable. (Please refer to ACPI spec 5.0 5.2.16) With the help of SRAT, we have to do the following two things to achieve our goal: 1. When doing memory hot-add, allow the users arranging hotpluggable as ZONE_MOVABLE. (This has been done by the MOVABLE_NODE functionality in Linux.) 2. when the system is booting, prevent bootmem allocator from allocating hotpluggable memory for the kernel before the memory initialization finishes. The problem 2 is the key problem we are going to solve. But before solving it, we need some preparation. Please see below. [Preparation] Bootloader has to load the kernel image into memory. And this memory must be unhotpluggable. We cannot prevent this anyway. So in a memory hotplug system, we can assume any node the kernel resides in is not hotpluggable. Before SRAT is parsed, we don't know which memory ranges are hotpluggable. But memblock has already started to work. In the current kernel, memblock allocates the following memory before SRAT is parsed: setup_arch() |->memblock_x86_fill()/* memblock is ready */ |.. |->early_reserve_e820_mpc_new() /* allocate memory under 1MB */ |->reserve_real_mode()/* allocate memory under 1MB */ |->init_mem_mapping() /* allocate page tables, about 2MB to map 1GB memory */ |->dma_contiguous_reserve() /* specified by user, should be low */ |->setup_log_buf()/* specified by user, several mega bytes */ |->relocate_initrd() /* could be large, but will be freed after boot, should reorder */ |->acpi_initrd_override() /* several mega bytes */ |->reserve_crashkernel() /* could be large, should reorder */ |.. |->initmem_init() /* Parse SRAT */ According to Tejun's advice, before SRAT is parsed, we should try our best to allocate memory near the kernel image. Since the whole node the kernel resides in won't be hotpluggable, and for a modern server, a node may have at least 16GB memory, allocating several mega bytes memory around the kernel image won't cross to hotpluggable memory. [About this patch-set] So this patch-set does the following: 1. Make memblock be able to allocate memory from low address to high address. Also introduce low limit to prevent memblock allocating memory too low. 2. Improve init_mem_mapping() to support allocate page tables from low address to high address. 3. Introduce "movablenode" boot option to enable and disable this functionality. PS: Reordering of relocate_initrd() and reserve_crashkernel() has not been done yet. acpi_initrd_override() needs to access initrd with virtual address. So relocate_initrd() must be done before acpi_initrd_override(). Tang Chen (11): memblock: Rename current_limit to current_limit_high in memblock. memblock: Rename memblock_set_current_limit() to memblock_set_current_limit_high(). memblock: Introduce lowest limit in memblock. memblock: Introduce memblock_set_current_limit_low() to set lower limit of memblock. memblock: Introduce allocation order to memblock. memblock: Improve memblock to support allocation from lower address. x86, memblock: Set lowest limit for memblock_alloc_base_nid(). x86, acpi, memblock: Use
Re: [PATCH 2/2] cpufreq: serialize calls to __cpufreq_governor()
On 2 September 2013 01:57, Rafael J. Wysocki wrote: > The second tab is one too many, I usually write such things like this: > > if (policy->governor_busy > || (policy->governor_enabled && event == CPUFREQ_GOV_START) > || ... > > Then it is much easier to distinguish the conditional code from the condition > itself. I see... I tried to do it this way but got confused again :) You fix it this time and I will understand it from that :) -- viresh -- 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] dma: imx-sdma: Staticize sdma_driver_data structures
From: Fabio Estevam
Sparse report the following warnings:
drivers/dma/imx-sdma.c:330:25: warning: symbol 'sdma_imx31' was not declared.
Should it be static?
drivers/dma/imx-sdma.c:351:25: warning: symbol 'sdma_imx25' was not declared.
Should it be static?
drivers/dma/imx-sdma.c:357:25: warning: symbol 'sdma_imx35' was not declared.
Should it be static?
drivers/dma/imx-sdma.c:375:25: warning: symbol 'sdma_imx51' was not declared.
Should it be static?
drivers/dma/imx-sdma.c:395:25: warning: symbol 'sdma_imx53' was not declared.
Should it be static?
drivers/dma/imx-sdma.c:414:25: warning: symbol 'sdma_imx6q' was not declared.
Should it be static?
Make the sdma_driver_data structures static.
Signed-off-by: Fabio Estevam
---
drivers/dma/imx-sdma.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 59bf9f5..fc43603 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -327,7 +327,7 @@ struct sdma_engine {
const struct sdma_driver_data *drvdata;
};
-struct sdma_driver_data sdma_imx31 = {
+static struct sdma_driver_data sdma_imx31 = {
.chnenbl0 = SDMA_CHNENBL0_IMX31,
.num_events = 32,
};
@@ -348,13 +348,13 @@ static struct sdma_script_start_addrs sdma_script_imx25 =
{
.shp_2_mcu_addr = 979,
};
-struct sdma_driver_data sdma_imx25 = {
+static struct sdma_driver_data sdma_imx25 = {
.chnenbl0 = SDMA_CHNENBL0_IMX35,
.num_events = 48,
.script_addrs = _script_imx25,
};
-struct sdma_driver_data sdma_imx35 = {
+static struct sdma_driver_data sdma_imx35 = {
.chnenbl0 = SDMA_CHNENBL0_IMX35,
.num_events = 48,
};
@@ -372,7 +372,7 @@ static struct sdma_script_start_addrs sdma_script_imx51 = {
.shp_2_mcu_addr = 892,
};
-struct sdma_driver_data sdma_imx51 = {
+static struct sdma_driver_data sdma_imx51 = {
.chnenbl0 = SDMA_CHNENBL0_IMX35,
.num_events = 48,
.script_addrs = _script_imx51,
@@ -392,7 +392,7 @@ static struct sdma_script_start_addrs sdma_script_imx53 = {
.mcu_2_firi_addr = 1290,
};
-struct sdma_driver_data sdma_imx53 = {
+static struct sdma_driver_data sdma_imx53 = {
.chnenbl0 = SDMA_CHNENBL0_IMX35,
.num_events = 48,
.script_addrs = _script_imx53,
@@ -411,7 +411,7 @@ static struct sdma_script_start_addrs sdma_script_imx6q = {
.mcu_2_spdif_addr = 1134,
};
-struct sdma_driver_data sdma_imx6q = {
+static struct sdma_driver_data sdma_imx6q = {
.chnenbl0 = SDMA_CHNENBL0_IMX35,
.num_events = 48,
.script_addrs = _script_imx6q,
--
1.8.1.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: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount
On Sun, Sep 1, 2013 at 5:12 PM, Linus Torvalds wrote: > > It *is* one of the few locked accesses remaining, and it's clearly > getting called a lot (three calls per system call: two mntput's - one > for the root path, one for the result path, and one from path_init -> > rcu_walk_init), but with up to 8% CPU time for basically that one > "lock xadd" instruction is damn odd. I can't see how that could happen > without seriously nasty cacheline bouncing, but I can't see how *that* > can happen when all the accesses seem to be from the current CPU. So, I wanted to double-check that "it can only be that expensive if there's cacheline bouncing" statement. Thinking "maybe it's just really expensive. Even when running just a single thread". So I set MAX_THREADS to 1 in my stupid benchmark, just to see what happens.. And almost everything changes as expected: now we don't have any cacheline bouncing any more, so lockref_put_or_lock() and lockref_get_or_lock() no longer dominate - instead of being 20%+ each, they are now just 3%. What _didn't_ change? Right. lg_local_lock() is still 6.40%. Even when single-threaded. It's now the #1 function in my profile: 6.40% lg_local_lock 5.42% copy_user_enhanced_fast_string 5.14% sysret_check 4.79% link_path_walk 4.41% 0x7ff861834ee3 4.33% avc_has_perm_flags 4.19% __lookup_mnt 3.83% lookup_fast (that "copy_user_enhanced_fast_string" is when we copy the "struct stat" from kernel space to user space) The instruction-level profile just looking like │81078e70 : 2.06 │ push %rbp 1.06 │ mov%rsp,%rbp 0.11 │ mov(%rdi),%rdx 2.13 │ add%gs:0xcd48,%rdx 0.92 │ mov$0x100,%eax 85.87 │ lock xadd %ax,(%rdx) 0.04 │ movzbl %ah,%ecx │ cmp%al,%cl 3.60 │↓ je 31 │ nop │28: pause │ movzbl (%rdx),%eax │ cmp%cl,%al │↑ jne28 │31: pop%rbp 4.22 │← retq so that instruction sequence is just expensive, and it is expensive without any cacheline bouncing. The expense seems to be 100% simply due to the fact that it's an atomic serializing instruction, and it just gets called way too much. So lockref_[get|put]_or_lock() are each called once per pathname lookup (because the RCU accesses to the dentries get turned into a refcount, and then that refcount gets dropped). But lg_local_lock() gets called twice: once for path_init(), and once for mntput() - I think I was wrong about mntput getting called twice. So it doesn't seem to be cacheline bouncing at all. It's just "serializing instructions are really expensive" together with calling that function too much. And we've optimized pathname lookup so much that even a single locked instruction shows up like a sort thumb. I guess we should be proud. 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: [RFC PATCH v2 next]module: Fix mod->mkobj.kobj potentially freed too early
On Mon, Sep 02, 2013 at 09:21:55AM +0930, Rusty Russell wrote: > Greg KH writes: > > On Tue, Aug 27, 2013 at 02:08:27PM +0930, Rusty Russell wrote: > >> Greg KH writes: > >> > On Thu, Aug 22, 2013 at 03:37:55PM +0800, Li Zhong wrote: > >> >> DEBUG_KOBJECT_RELEASE helps to find the issue attached below. > >> > People are starting to hit these types of issues, and I'd like to take > >> > this one out of the picture. > >> > > >> > Rusty, any objection to me taking this through my driver-core tree, > >> > where this new config option shows up? > >> > >> The original fix was better. > >> > >> Moving the module_kobject out and giving it its own lifetime solves this > >> immediate issue, but it still means there's an accessible module_kobject > >> around referring to a module which doesn't exist any more. > > > > That's ok, it could happen before as well. What's wrong with that? > > > >> Original copied below, feel free to take it. > > > > You are just sitting and sleeping until someone drops the last reference > > to the module. What if userspace grabs a reference from sysfs? That > > could never return, I don't think you want to stall that out. > > In your scenario, what happens if userspace grabs a reference via sysfs? > It then tries to use module_kobj->mod which points into freed memory? > > eg. show_modinfo_##field or show_refcnt. The sysfs file will not be able to be "called" as Tejun fixed that up a long time ago, but yes, you are right, it really doesn't solve the issue. > Is there an owner field I'm missing somewhere which stops this from > happening? Otherwise, we can't unload the module until it's done. Good point. > > I'd prefer not having 2 things determining the lifecycle of a single > > object, that's messy, and not needed at all. > > Normally you'd grab a reference to the module via an owner pointer. > Doing that in kobject seems like overkill, so we're working around it > here... Ok, fair enough, your version is fine, feel free to add a: Acked-by: Greg Kroah-Hartman if you want it. thanks, greg k-h -- 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/3] extcon: Change field type of 'dev' in extcon_dev structure
Hi Greg, On 09/02/2013 09:38 AM, Greg KH wrote: > On Mon, Sep 02, 2013 at 09:20:07AM +0900, Chanwoo Choi wrote: >> -edev->dev = kzalloc(sizeof(struct device), GFP_KERNEL); >> -if (!edev->dev) >> -return -ENOMEM; >> -edev->dev->parent = dev; >> -edev->dev->class = extcon_class; >> -edev->dev->release = extcon_dev_release; >> +edev->dev.parent = dev; >> +edev->dev.class = extcon_class; >> +edev->dev.release = extcon_dev_release; > > You didn't change extcon_dev_release() to properly free all of the > memory you allocated here, otherwise the slab allocator will oops when > you try to call it... > I'll fix it. Thanks. Best Regards, Chanwoo Choi -- 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/3] extcon: Simplify extcon_dev_register() prototype by removing unnecessary parameter
On Mon, Sep 02, 2013 at 09:20:08AM +0900, Chanwoo Choi wrote: > This patch remove extcon_dev_register()'s second parameter which means > the pointer of parent device to simplify prototype of this function. No, please don't. You want the parent to be passed in, as the core needs it when it is registered with the system, otherwise it will not show up in sysfs properly (i.e. you can't set it afterwards.) > So, if extcon device has the parent device, it should set the pointer of > parent device to edev.dev.parent in extcon device driver instead of in > extcon_dev_register(). No it will break things if you do that :( greg k-h -- 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/3] extcon: Change field type of 'dev' in extcon_dev structure
On Mon, Sep 02, 2013 at 09:20:07AM +0900, Chanwoo Choi wrote: > - edev->dev = kzalloc(sizeof(struct device), GFP_KERNEL); > - if (!edev->dev) > - return -ENOMEM; > - edev->dev->parent = dev; > - edev->dev->class = extcon_class; > - edev->dev->release = extcon_dev_release; > + edev->dev.parent = dev; > + edev->dev.class = extcon_class; > + edev->dev.release = extcon_dev_release; You didn't change extcon_dev_release() to properly free all of the memory you allocated here, otherwise the slab allocator will oops when you try to call it... thanks, greg k-h -- 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/3] extcon: Change field type of 'dev' in extcon_dev structure
The extcon device must always need 'struct device' so this patch change
field type of 'dev' instead of allocating memory for 'struct device' on
extcon_dev_register() function.
Signed-off-by: Chanwoo Choi
Signed-off-by: Myungjoo Ham
---
drivers/extcon/extcon-adc-jack.c | 2 +-
drivers/extcon/extcon-class.c| 52 +++-
include/linux/extcon.h | 4 ++--
3 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index 5d16428..90346d6 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -64,7 +64,7 @@ static void adc_jack_handler(struct work_struct *work)
ret = iio_read_channel_raw(data->chan, _val);
if (ret < 0) {
- dev_err(data->edev.dev, "read channel() error: %d\n", ret);
+ dev_err(>edev.dev, "read channel() error: %d\n", ret);
return;
}
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index ed456b3..8bc43e6 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -160,7 +160,7 @@ static ssize_t name_show(struct device *dev, struct
device_attribute *attr,
return ret;
}
- return sprintf(buf, "%s\n", dev_name(edev->dev));
+ return sprintf(buf, "%s\n", dev_name(>dev));
}
static ssize_t cable_name_show(struct device *dev,
@@ -224,10 +224,11 @@ int extcon_update_state(struct extcon_dev *edev, u32
mask, u32 state)
edev->state |= state & mask;
raw_notifier_call_chain(>nh, old_state, edev);
+
/* This could be in interrupt handler */
prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
if (prop_buf) {
- length = name_show(edev->dev, NULL, prop_buf);
+ length = name_show(>dev, NULL, prop_buf);
if (length > 0) {
if (prop_buf[length - 1] == '\n')
prop_buf[length - 1] = 0;
@@ -235,7 +236,7 @@ int extcon_update_state(struct extcon_dev *edev, u32 mask,
u32 state)
"NAME=%s", prop_buf);
envp[env_offset++] = name_buf;
}
- length = state_show(edev->dev, NULL, prop_buf);
+ length = state_show(>dev, NULL, prop_buf);
if (length > 0) {
if (prop_buf[length - 1] == '\n')
prop_buf[length - 1] = 0;
@@ -247,15 +248,15 @@ int extcon_update_state(struct extcon_dev *edev, u32
mask, u32 state)
/* Unlock early before uevent */
spin_unlock_irqrestore(>lock, flags);
- kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, envp);
+ kobject_uevent_env(>dev.kobj, KOBJ_CHANGE, envp);
free_page((unsigned long)prop_buf);
} else {
/* Unlock early before uevent */
spin_unlock_irqrestore(>lock, flags);
- dev_err(edev->dev,
+ dev_err(>dev,
"out of memory in extcon_set_state\n");
- kobject_uevent(>dev->kobj, KOBJ_CHANGE);
+ kobject_uevent(>dev.kobj, KOBJ_CHANGE);
}
} else {
/* No changes */
@@ -593,20 +594,17 @@ int extcon_dev_register(struct extcon_dev *edev, struct
device *dev)
}
if (index > SUPPORTED_CABLE_MAX) {
- dev_err(edev->dev,
+ dev_err(>dev,
"maximum number of supported cables exceeded\n");
return -EINVAL;
}
- edev->dev = kzalloc(sizeof(struct device), GFP_KERNEL);
- if (!edev->dev)
- return -ENOMEM;
- edev->dev->parent = dev;
- edev->dev->class = extcon_class;
- edev->dev->release = extcon_dev_release;
+ edev->dev.parent = dev;
+ edev->dev.class = extcon_class;
+ edev->dev.release = extcon_dev_release;
edev->name = edev->name ? edev->name : dev_name(dev);
- dev_set_name(edev->dev, "%s", edev->name);
+ dev_set_name(>dev, "%s", edev->name);
if (edev->max_supported) {
char buf[10];
@@ -714,7 +712,7 @@ int extcon_dev_register(struct extcon_dev *edev, struct
device *dev)
goto err_alloc_groups;
}
- edev->extcon_dev_type.name = dev_name(edev->dev);
+ edev->extcon_dev_type.name = dev_name(>dev);
edev->extcon_dev_type.release = dummy_sysfs_dev_release;
for (index = 0; index < edev->max_supported; index++)
@@ -724,25 +722,24 @@ int
[PATCH 1/3] extcon: Fix indentation coding style to improve readability
Signed-off-by: Chanwoo Choi
Signed-off-by: Myungjoo Ham
---
drivers/extcon/extcon-adc-jack.c | 20 +-
drivers/extcon/extcon-class.c | 26 ++---
include/linux/extcon.h | 67 ++
include/linux/extcon/extcon-adc-jack.h | 42 ++---
include/linux/extcon/extcon-gpio.h | 16
5 files changed, 87 insertions(+), 84 deletions(-)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index 5985807..5d16428 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -27,16 +27,16 @@
/**
* struct adc_jack_data - internal data for adc_jack device driver
- * @edev- extcon device.
- * @cable_names - list of supported cables.
- * @num_cables - size of cable_names.
- * @adc_conditions - list of adc value conditions.
- * @num_conditions - size of adc_conditions.
- * @irq - irq number of attach/detach event (0 if not exist).
- * @handling_delay - interrupt handler will schedule extcon event
- * handling at handling_delay jiffies.
- * @handler - extcon event handler called by interrupt handler.
- * @chan - iio channel being queried.
+ * @edev: extcon device.
+ * @cable_names: list of supported cables.
+ * @num_cables:size of cable_names.
+ * @adc_conditions:list of adc value conditions.
+ * @num_conditions:size of adc_conditions.
+ * @irq: irq number of attach/detach event (0 if not exist).
+ * @handling_delay:interrupt handler will schedule extcon event
+ * handling at handling_delay jiffies.
+ * @handler: extcon event handler called by interrupt handler.
+ * @chan: iio channel being queried.
*/
struct adc_jack_data {
struct extcon_dev edev;
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 7b6b996..ed456b3 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -74,7 +74,7 @@ static DEFINE_MUTEX(extcon_dev_list_lock);
/**
* check_mutually_exclusive - Check if new_state violates mutually_exclusive
- * condition.
+ * condition.
* @edev: the extcon device
* @new_state: new cable attach status for @edev
*
@@ -186,7 +186,7 @@ static ssize_t cable_state_show(struct device *dev,
/**
* extcon_update_state() - Update the cable attach states of the extcon device
- * only for the masked bits.
+ *only for the masked bits.
* @edev: the extcon device
* @mask: the bit mask to designate updated bits.
* @state: new cable attach status for @edev
@@ -224,7 +224,6 @@ int extcon_update_state(struct extcon_dev *edev, u32 mask,
u32 state)
edev->state |= state & mask;
raw_notifier_call_chain(>nh, old_state, edev);
-
/* This could be in interrupt handler */
prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
if (prop_buf) {
@@ -337,8 +336,9 @@ EXPORT_SYMBOL_GPL(extcon_get_cable_state);
/**
* extcon_set_cable_state_() - Set the status of a specific cable.
- * @edev: the extcon device that has the cable.
- * @index: cable index that can be retrieved by extcon_find_cable_index().
+ * @edev: the extcon device that has the cable.
+ * @index: cable index that can be retrieved by
+ * extcon_find_cable_index().
* @cable_state: the new cable status. The default semantics is
* true: attached / false: detached.
*/
@@ -357,8 +357,8 @@ EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
/**
* extcon_set_cable_state() - Set the status of a specific cable.
- * @edev: the extcon device that has the cable.
- * @cable_name:cable name.
+ * @edev: the extcon device that has the cable.
+ * @cable_name:cable name.
* @cable_state: the new cable status. The default semantics is
* true: attached / false: detached.
*
@@ -417,14 +417,14 @@ static int _call_per_cable(struct notifier_block *nb,
unsigned long val,
/**
* extcon_register_interest() - Register a notifier for a state change of a
- * specific cable, not an entier set of cables of a
- * extcon device.
- * @obj: an empty extcon_specific_cable_nb object to be returned.
+ * specific cable, not an entier set of cables of a
+ * extcon device.
+ * @obj: an empty extcon_specific_cable_nb object to be returned.
* @extcon_name: the name of extcon device.
* if NULL, extcon_register_interest will register
* every cable with the target cable_name given.
* @cable_name:
[PATCH 0/3] extcon: Code clean to fix up coding style and remove
This patchset fix up indentation coding style and simplify extcon_dev_register() prototype to improbe usability when registering extcon device.*** BLURB HERE *** Chanwoo Choi (3): extcon: Fix indentation coding style to improve readability extcon: Change field type of 'dev' in extcon_dev structure extcon: Simplify extcon_dev_register() prototype by removing unnecessary parameter Documentation/extcon/porting-android-switch-class | 6 +- drivers/extcon/extcon-adc-jack.c | 25 +++ drivers/extcon/extcon-arizona.c | 3 +- drivers/extcon/extcon-class.c | 85 +++ drivers/extcon/extcon-gpio.c | 3 +- drivers/extcon/extcon-max77693.c | 3 +- drivers/extcon/extcon-max8997.c | 3 +- drivers/extcon/extcon-palmas.c| 3 +- include/linux/extcon.h| 72 +-- include/linux/extcon/extcon-adc-jack.h| 42 +-- include/linux/extcon/extcon-gpio.h| 16 ++--- 11 files changed, 135 insertions(+), 126 deletions(-) -- 1.8.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/
[PATCH 3/3] extcon: Simplify extcon_dev_register() prototype by removing unnecessary parameter
This patch remove extcon_dev_register()'s second parameter which means
the pointer of parent device to simplify prototype of this function.
So, if extcon device has the parent device, it should set the pointer of
parent device to edev.dev.parent in extcon device driver instead of in
extcon_dev_register().
Cc: Graeme Gregory
Cc: Kishon Vijay Abraham I
Cc: Charles Keepax
Cc: Mark Brown
Signed-off-by: Chanwoo Choi
Signed-off-by: Myungjoo Ham
---
Documentation/extcon/porting-android-switch-class | 6 --
drivers/extcon/extcon-adc-jack.c | 3 ++-
drivers/extcon/extcon-arizona.c | 3 ++-
drivers/extcon/extcon-class.c | 11 +++
drivers/extcon/extcon-gpio.c | 3 ++-
drivers/extcon/extcon-max77693.c | 3 ++-
drivers/extcon/extcon-max8997.c | 3 ++-
drivers/extcon/extcon-palmas.c| 3 ++-
include/linux/extcon.h| 5 ++---
9 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/Documentation/extcon/porting-android-switch-class
b/Documentation/extcon/porting-android-switch-class
index eb0fa5f..5377f63 100644
--- a/Documentation/extcon/porting-android-switch-class
+++ b/Documentation/extcon/porting-android-switch-class
@@ -25,8 +25,10 @@ MyungJoo Ham
@print_state: no change but type change (switch_dev->extcon_dev)
- switch_dev_register(sdev, dev)
- => extcon_dev_register(edev, dev)
- : no change but type change (sdev->edev)
+ => extcon_dev_register(edev)
+ : type change (sdev->edev)
+ : remove second param('dev'). if edev has parent device, should store
+ 'dev' to 'edev.dev.parent' before registering extcon device
- switch_dev_unregister(sdev)
=> extcon_dev_unregister(edev)
: no change but type change (sdev->edev)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index 90346d6..7f7f930 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -110,6 +110,7 @@ static int adc_jack_probe(struct platform_device *pdev)
goto out;
}
+ data->edev.dev.parent = >dev;
data->edev.supported_cable = pdata->cable_names;
/* Check the length of array and set num_cables */
@@ -148,7 +149,7 @@ static int adc_jack_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
- err = extcon_dev_register(>edev, >dev);
+ err = extcon_dev_register(>edev);
if (err)
goto out;
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 72fc28e..f639f2a 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1132,9 +1132,10 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
}
info->edev.name = "Headset Jack";
+ info->edev.dev.parent = arizona->dev;
info->edev.supported_cable = arizona_cable;
- ret = extcon_dev_register(>edev, arizona->dev);
+ ret = extcon_dev_register(>edev);
if (ret < 0) {
dev_err(arizona->dev, "extcon_dev_register() failed: %d\n",
ret);
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 8bc43e6..b096db8 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -567,14 +567,13 @@ static void dummy_sysfs_dev_release(struct device *dev)
/**
* extcon_dev_register() - Register a new extcon device
* @edev : the new extcon device (should be allocated before calling)
- * @dev: the parent device for this extcon device.
*
* Among the members of edev struct, please set the "user initializing data"
* in any case and set the "optional callbacks" if required. However, please
* do not set the values of "internal data", which are initialized by
* this function.
*/
-int extcon_dev_register(struct extcon_dev *edev, struct device *dev)
+int extcon_dev_register(struct extcon_dev *edev)
{
int ret, index = 0;
@@ -599,11 +598,15 @@ int extcon_dev_register(struct extcon_dev *edev, struct
device *dev)
return -EINVAL;
}
- edev->dev.parent = dev;
edev->dev.class = extcon_class;
edev->dev.release = extcon_dev_release;
- edev->name = edev->name ? edev->name : dev_name(dev);
+ edev->name = edev->name ? edev->name : dev_name(edev->dev.parent);
+ if (IS_ERR_OR_NULL(edev->name)) {
+ dev_err(>dev,
+ "extcon device name is null\n");
+ return -EINVAL;
+ }
dev_set_name(>dev, "%s", edev->name);
if (edev->max_supported) {
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index f874c30..1a83e33 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -95,6 +95,7 @@ static int
[char-misc-next 0/5] mei driver small fixes and cleanups
Alexander Usyskin (1): mei: mei_write correct checks for copy_from_user Tomas Winkler (4): mei: mei_cl_link protect open_handle_count from overflow mei: make sure that me_clients_map big enough before copying mei: fix format compilation warrning on 32 bit architecture mei: revamp read and write length checks drivers/misc/mei/client.c | 6 ++ drivers/misc/mei/hbm.c| 7 +-- drivers/misc/mei/main.c | 23 +++ 3 files changed, 30 insertions(+), 6 deletions(-) -- 1.8.3.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: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount
On Sun, Sep 1, 2013 at 4:30 PM, Al Viro wrote: > > Hrm... It excludes sharing between the locks, all right. AFAICS, that > won't exclude sharing with plain per-cpu vars, will it? Yes it will. DEFINE_PER_CPU_SHARED_ALIGNED not only aligns the data, it also puts it in a separate section with only other aligned data entries. So now the percpu address map around it looks like this: ... 00013a80 d call_single_queue 00013ac0 d cfd_data 00013b00 d files_lglock_lock 00013b40 d vfsmount_lock_lock 00013b80 d file_lock_lglock_lock 00013bc0 D softnet_data 00013d40 D __per_cpu_end .. So there shouldn't be anything to share falsely with. I'd like to say that the profile is bad, but this is *so* consistent, and the profile data really looks perfectly fine in every other way. I'm using "-e cycles:pp", so it's using hardware profiling and all the other functions really look correct. It *is* one of the few locked accesses remaining, and it's clearly getting called a lot (three calls per system call: two mntput's - one for the root path, one for the result path, and one from path_init -> rcu_walk_init), but with up to 8% CPU time for basically that one "lock xadd" instruction is damn odd. I can't see how that could happen without seriously nasty cacheline bouncing, but I can't see how *that* can happen when all the accesses seem to be from the current CPU. This is a new Haswell-based machine that I put together yesterdat, and I haven't used it for profiling before. So maybe it _is_ something odd with the profiling after all, and atomic serializing instructions get incorrect profile counts. 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/
[char-misc-next 2/5] mei: make sure that me_clients_map big enough before copying
To make static analyzers happy validated that
sizeof me_clients_map is larger than sizeof valid_addresses from the
enumeration response before memcpy
We can use BUILD_ON macro as both arrays are defined statically
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hbm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index 6127ab6..95d4dab 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -673,7 +673,10 @@ void mei_hbm_dispatch(struct mei_device *dev, struct
mei_msg_hdr *hdr)
case HOST_ENUM_RES_CMD:
enum_res = (struct hbm_host_enum_response *) mei_msg;
- memcpy(dev->me_clients_map, enum_res->valid_addresses, 32);
+ BUILD_BUG_ON(sizeof(dev->me_clients_map)
+ < sizeof(enum_res->valid_addresses));
+ memcpy(dev->me_clients_map, enum_res->valid_addresses,
+ sizeof(enum_res->valid_addresses));
if (dev->dev_state == MEI_DEV_INIT_CLIENTS &&
dev->hbm_state == MEI_HBM_ENUM_CLIENTS) {
dev->init_clients_timer = 0;
--
1.8.3.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/
[char-misc-next 4/5] mei: fix format compilation warrning on 32 bit architecture
hbm.c: In function mei_hbm_me_cl_allocate: hbm.c:52:212: warning: format %zd expects argument of type signed size_t but argument 4 has type long unsigned Signed-off-by: Tomas Winkler --- drivers/misc/mei/hbm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c index 95d4dab..f706fe8 100644 --- a/drivers/misc/mei/hbm.c +++ b/drivers/misc/mei/hbm.c @@ -45,7 +45,7 @@ static void mei_hbm_me_cl_allocate(struct mei_device *dev) kfree(dev->me_clients); dev->me_clients = NULL; - dev_dbg(>pdev->dev, "memory allocation for ME clients size=%zd.\n", + dev_dbg(>pdev->dev, "memory allocation for ME clients size=%ld.\n", dev->me_clients_num * sizeof(struct mei_me_client)); /* allocate storage for ME clients representation */ clients = kcalloc(dev->me_clients_num, -- 1.8.3.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/
[char-misc-next 1/5] mei: mei_cl_link protect open_handle_count from overflow
mei_cl_link is called both from mei_open and also from
in-kernel drivers so we need to protect open_handle_count
from overflow
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/client.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index e0684b4..a82b443 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -287,6 +287,12 @@ int mei_cl_link(struct mei_cl *cl, int id)
return -ENOENT;
}
+ if (dev->open_handle_count >= MEI_MAX_OPEN_HANDLE_COUNT) {
+ dev_err(>pdev->dev, "open_handle_count exceded %d",
+ MEI_MAX_OPEN_HANDLE_COUNT);
+ return -ENOENT;
+ }
+
dev->open_handle_count++;
cl->host_client_id = id;
--
1.8.3.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: [RFC PATCH v2 next]module: Fix mod->mkobj.kobj potentially freed too early
Greg KH writes: > On Tue, Aug 27, 2013 at 02:08:27PM +0930, Rusty Russell wrote: >> Greg KH writes: >> > On Thu, Aug 22, 2013 at 03:37:55PM +0800, Li Zhong wrote: >> >> DEBUG_KOBJECT_RELEASE helps to find the issue attached below. >> > People are starting to hit these types of issues, and I'd like to take >> > this one out of the picture. >> > >> > Rusty, any objection to me taking this through my driver-core tree, >> > where this new config option shows up? >> >> The original fix was better. >> >> Moving the module_kobject out and giving it its own lifetime solves this >> immediate issue, but it still means there's an accessible module_kobject >> around referring to a module which doesn't exist any more. > > That's ok, it could happen before as well. What's wrong with that? > >> Original copied below, feel free to take it. > > You are just sitting and sleeping until someone drops the last reference > to the module. What if userspace grabs a reference from sysfs? That > could never return, I don't think you want to stall that out. In your scenario, what happens if userspace grabs a reference via sysfs? It then tries to use module_kobj->mod which points into freed memory? eg. show_modinfo_##field or show_refcnt. Is there an owner field I'm missing somewhere which stops this from happening? Otherwise, we can't unload the module until it's done. > I'd prefer not having 2 things determining the lifecycle of a single > object, that's messy, and not needed at all. Normally you'd grab a reference to the module via an owner pointer. Doing that in kobject seems like overkill, so we're working around it here... Hope that clarifies, 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/
[char-misc-next 3/5] mei: mei_write correct checks for copy_from_user
From: Alexander Usyskin
1. return -EFUALT when copy_from_user fails
2. display error message on failure in error level
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/main.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index 173ff09..5ff810b 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -404,8 +404,11 @@ static ssize_t mei_write(struct file *file, const char
__user *ubuf,
goto out;
rets = copy_from_user(write_cb->request_buffer.data, ubuf, length);
- if (rets)
+ if (rets) {
+ dev_err(>pdev->dev, "failed to copy data from userland\n");
+ rets = -EFAULT;
goto out;
+ }
if (cl == >iamthif_cl) {
rets = mei_amthif_write(dev, write_cb);
@@ -567,7 +570,7 @@ static long mei_ioctl(struct file *file, unsigned int cmd,
unsigned long data)
dev_dbg(>pdev->dev, "copy connect data from user\n");
if (copy_from_user(connect_data, (char __user *)data,
sizeof(struct mei_connect_client_data))) {
- dev_dbg(>pdev->dev, "failed to copy data from userland\n");
+ dev_err(>pdev->dev, "failed to copy data from userland\n");
rets = -EFAULT;
goto out;
}
--
1.8.3.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/
[char-misc-next 5/5] mei: revamp read and write length checks
1. Return zero on zero length read and writes
2. For a too large write return -EFBIG as defined in man write(2)
EFBIG An attempt was made to write a file that
exceeds the implementation-defined maximum
file size or the process's file size limit,
or to write at a position past the maximum
allowed offset.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/main.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index 5ff810b..7404584 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -203,12 +203,18 @@ static ssize_t mei_read(struct file *file, char __user
*ubuf,
dev = cl->dev;
+
mutex_lock(>device_lock);
if (dev->dev_state != MEI_DEV_ENABLED) {
rets = -ENODEV;
goto out;
}
+ if (length == 0) {
+ rets = 0;
+ goto out;
+ }
+
if (cl == >iamthif_cl) {
rets = mei_amthif_read(dev, file, ubuf, length, offset);
goto out;
@@ -350,8 +356,14 @@ static ssize_t mei_write(struct file *file, const char
__user *ubuf,
rets = -ENODEV;
goto out;
}
- if (length > dev->me_clients[id].props.max_msg_length || length <= 0) {
- rets = -EMSGSIZE;
+
+ if (length == 0) {
+ rets = 0;
+ goto out;
+ }
+
+ if (length > dev->me_clients[id].props.max_msg_length) {
+ rets = -EFBIG;
goto out;
}
--
1.8.3.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: rcu: Make rcu_assign_pointer's assignment volatile and type-safe
On Mon, Sep 02, 2013 at 07:50:09AM +0800, Wang Shilong wrote: > Hello, Using checkpatch.pl, i get the following warnings(errors): > WARNING: line over 80 characters > #57: FILE: include/linux/rcupdate.h:518: > + extern void __rcu_assign_pointer_typecheck(int, typeof(*(v)) > __kernel *); \ It'd get much uglier if wrapped, and the function name needs to stay unique to avoid conflicts with the macro context. I don't plan to change this. > ERROR: need consistent spacing around '*' (ctx:WxB) > #72: FILE: include/linux/rcupdate.h:568: > + ACCESS_ONCE(p) = (typeof(*(v)) __force space *)(v); \ False positive; checkpatch.pl seems to parse this as multiplication rather than a cast. - Josh Triplett -- 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: linux-next: build failure after merge of the akpm-current tree
Hi Linus,
On Fri, 30 Aug 2013 08:25:06 -0700 Linus Torvalds
wrote:
>
> On Fri, Aug 30, 2013 at 1:12 AM, Stephen Rothwell
> wrote:
> >
> > I don't know if it is safe to read d_lockref.count without locking
>
> That's not the issue. Since commit 84d08fa888e7 ("helper for reading
> ->d_count") non-core VFS code shouldn't try to access d_count directly
> at all. So instead of "dentry->d_count" it should use
> "d_count(dentry)". Then the code doesn't need to know about lockrefs
> or anything like that at all.
Thanks for that. I will implement that temporary fix in linux-next today
unless Andrew has been busy over the weekend.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpfhdmJmbDxt.pgp
Description: PGP signature
Re: Please add git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git branch h8300-remove to linux-next
Hi Guenter, On Fri, 30 Aug 2013 17:00:40 -0700 Guenter Roeck wrote: > > Please add the h8300-remove branch of > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git > to linux-next. Added from today. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au Legal Stuff: By participating in linux-next, your subsystem tree contributions are public and will be included in the linux-next trees. You may be sent e-mail messages indicating errors or other issues when the patches/commits from your subsystem tree are merged and tested in linux-next. These messages may also be cross-posted to the linux-next mailing list, the linux-kernel mailing list, etc. The linux-next tree project and IBM (my employer) make no warranties regarding the linux-next project, the testing procedures, the results, the e-mails, etc. If you don't agree to these ground rules, let me know and I'll remove your tree from participation in linux-next. pgpdf56yVu2hT.pgp Description: PGP signature
[PATCH] rcu: Make rcu_assign_pointer's assignment volatile and type-safe
rcu_assign_pointer needs to use ACCESS_ONCE to make the assignment to
the destination pointer volatile, to protect against compilers too
clever for their own good.
In addition, since rcu_assign_pointer force-casts the source pointer to
add the __rcu address space (overriding any existing address space), add
an explicit check that the source pointer has the __kernel address space
to start with.
This new check produces warnings like this, when attempting to assign
from a __user pointer:
test.c:25:9: warning: incorrect type in argument 2 (different address spaces)
test.c:25:9:expected struct foo *
test.c:25:9:got struct foo [noderef] *badsrc
Signed-off-by: Josh Triplett
---
include/linux/rcupdate.h | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 4b14bdc..3f62def 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -510,8 +510,17 @@ static inline void rcu_preempt_sleep_check(void)
#ifdef __CHECKER__
#define rcu_dereference_sparse(p, space) \
((void)(((typeof(*p) space *)p) == p))
+/* The dummy first argument in __rcu_assign_pointer_typecheck makes the
+ * typechecked pointer the second argument, matching rcu_assign_pointer itself;
+ * this avoids confusion about argument numbers in warning messages. */
+#define __rcu_assign_pointer_check_kernel(v) \
+ do { \
+ extern void __rcu_assign_pointer_typecheck(int, typeof(*(v))
__kernel *); \
+ __rcu_assign_pointer_typecheck(0, v); \
+ } while (0)
#else /* #ifdef __CHECKER__ */
#define rcu_dereference_sparse(p, space)
+#define __rcu_assign_pointer_check_kernel(v) do { } while (0)
#endif /* #else #ifdef __CHECKER__ */
#define __rcu_access_pointer(p, space) \
@@ -555,7 +564,8 @@ static inline void rcu_preempt_sleep_check(void)
#define __rcu_assign_pointer(p, v, space) \
do { \
smp_wmb(); \
- (p) = (typeof(*v) __force space *)(v); \
+ __rcu_assign_pointer_check_kernel(v); \
+ ACCESS_ONCE(p) = (typeof(*(v)) __force space *)(v); \
} while (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/
Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount
On Sun, Sep 01, 2013 at 03:48:01PM -0700, Linus Torvalds wrote: > I made DEFINE_LGLOCK use DEFINE_PER_CPU_SHARED_ALIGNED for the > spinlock, so that each local lock gets its own cacheline, and the > total loops jumped to 62M (from 52-54M before). So when I looked at > the numbers, I thought "oh, that helped". > > But then I looked closer, and realized that I just see a fair amount > of boot-to-boot variation anyway (probably a lot to do with cache > placement and how dentries got allocated etc). And it didn't actually > help at all, the problem is stilte there, and lg_local_lock is still > really really high on the profile, at 8% cpu time: > > - 8.00% lg_local_lock >- lg_local_lock > + 64.83% mntput_no_expire > + 33.81% path_init > + 0.78% mntput > + 0.58% path_lookupat > > which just looks insane. And no, no lg_global_lock visible anywhere.. > > So it's not false sharing. But something is bouncing *that* particular > lock around. Hrm... It excludes sharing between the locks, all right. AFAICS, that won't exclude sharing with plain per-cpu vars, will it? Could you tell what vfsmount_lock is sharing with on that build? The stuff between it and files_lock doesn't have any cross-CPU writers, but with that change it's the stuff after it that becomes interesting... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] x86: avoid remapping data in parse_setup_data()
On 08/13/2013 02:46 PM, Linn Crosetto wrote: > Type SETUP_PCI, added by setup_efi_pci(), may advertise a ROM size > larger than early_memremap() is able to handle, which is currently > limited to 256kB. If this occurs it leads to a NULL dereference in > parse_setup_data(). > > To avoid this, remap the setup_data header and allow parsing functions > for individual types to handle their own data remapping. > > Signed-off-by: Linn Crosetto So it seems this patch generates some new sparse warnings. Can you please create an incremental fixup patch to address those sparse warnings? (See email from Fengguang Wu's robot.) -hpa -- 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] pch_dma: Add MODULE_DEVICE_TABLE
pch_dma currently isn't auto-loaded if built as a module.
Signed-off-by: Ben Hutchings
---
Compile-tested only.
Ben.
drivers/dma/pch_dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index 0bbdea5..c4b02d1 100644
--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -1036,3 +1036,4 @@ MODULE_DESCRIPTION("Intel EG20T PCH / LAPIS Semicon
ML7213/ML7223/ML7831 IOH "
"DMA controller driver");
MODULE_AUTHOR("Yong Wang ");
MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(pci, pch_dma_id_table);
signature.asc
Description: This is a digitally signed message part
Re: [staging] Staging: Convert uses of compare_ether_addr to ether_addr_equal
On Mon, Sep 02, 2013 at 03:30:12AM +0800, Wang Shilong wrote: > Hello, Using checkpatch.pl, i get the following warnings(errors): All of these were there in the original code. Have your script copy the messages to your postponed messages folder and then look over the output before mailing it. regards, dan carpenter -- 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 v7 1/4] spinlock: A new lockref structure for lockless update of refcount
On Sun, Sep 1, 2013 at 3:44 PM, Al Viro wrote:
>
> GRRR... I see something else:
> void file_sb_list_del(struct file *file)
> {
> if (!list_empty(>f_u.fu_list)) {
> lg_local_lock_cpu(_lglock, file_list_cpu(file));
> list_del_init(>f_u.fu_list);
> lg_local_unlock_cpu(_lglock, file_list_cpu(file));
> }
> }
> will cheerfully cause cross-CPU traffic. If that's what is going on, the
> earlier patch I've sent (not putting non-regulars and files opened r/o
> on ->s_list) should reduce the cacheline bouncing on that cacheline.
Hmm. That might indeed be a bad sources of cross-cpu bouncing on some
loads, but the load I test doesn't actually open any files. It just
does "stat()" on a filename.
So no "struct file *" anywhere for me..It really seems to be
vfsmount_lock itself somehow.
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/
[PATCH] hwrng: via-rng: Add MODULE_DEVICE_TABLE
via-rng currently isn't auto-loaded if built as a module.
Signed-off-by: Ben Hutchings
---
Compile-tested only.
Ben.
drivers/char/hw_random/via-rng.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index d0387a8..e737772 100644
--- a/drivers/char/hw_random/via-rng.c
+++ b/drivers/char/hw_random/via-rng.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -220,5 +221,11 @@ static void __exit mod_exit(void)
module_init(mod_init);
module_exit(mod_exit);
+static struct x86_cpu_id via_rng_cpu_id[] = {
+ X86_FEATURE_MATCH(X86_FEATURE_XSTORE),
+ {}
+};
+
MODULE_DESCRIPTION("H/W RNG driver for VIA CPU with PadLock");
MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(x86cpu, via_rng_cpu_id);
signature.asc
Description: This is a digitally signed message part
[PATCH net-hext] wireless: scan: Remove comment to compare_ether_addr
This function is being removed, so remove the reference to it. Signed-off-by: Joe Perches --- net/wireless/scan.c | 4 1 file changed, 4 deletions(-) diff --git a/net/wireless/scan.c b/net/wireless/scan.c index ad1e406..eeb7148 100644 --- a/net/wireless/scan.c +++ b/net/wireless/scan.c @@ -465,10 +465,6 @@ static int cmp_bss(struct cfg80211_bss *a, } } - /* -* we can't use compare_ether_addr here since we need a < > operator. -* The binary return value of compare_ether_addr isn't enough -*/ r = memcmp(a->bssid, b->bssid, sizeof(a->bssid)); if (r) return r; -- 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 v7 1/4] spinlock: A new lockref structure for lockless update of refcount
On Sun, Sep 1, 2013 at 3:16 PM, Linus Torvalds wrote: > > I wonder if there is some false sharing going on. But I don't see that > either, this is the percpu offset map afaik: > > f560 d files_lglock_lock > f564 d nr_dentry > f568 d last_ino > f56c d nr_unused > f570 d nr_inodes > f574 d vfsmount_lock_lock > f580 d bh_accounting I made DEFINE_LGLOCK use DEFINE_PER_CPU_SHARED_ALIGNED for the spinlock, so that each local lock gets its own cacheline, and the total loops jumped to 62M (from 52-54M before). So when I looked at the numbers, I thought "oh, that helped". But then I looked closer, and realized that I just see a fair amount of boot-to-boot variation anyway (probably a lot to do with cache placement and how dentries got allocated etc). And it didn't actually help at all, the problem is stilte there, and lg_local_lock is still really really high on the profile, at 8% cpu time: - 8.00% lg_local_lock - lg_local_lock + 64.83% mntput_no_expire + 33.81% path_init + 0.78% mntput + 0.58% path_lookupat which just looks insane. And no, no lg_global_lock visible anywhere.. So it's not false sharing. But something is bouncing *that* particular lock around. Linus --- 34.60% lockref_get_or_lock 23.35% lockref_put_or_lock 10.57% dput 8.00% lg_local_lock 1.79% copy_user_enhanced_fast_string 1.15% link_path_walk 1.04% path_lookupat 1.03% sysret_check 1.01% kmem_cache_alloc 1.00% selinux_inode_permission 0.97% __d_lookup_rcu 0.95% kmem_cache_free 0.90% 0x7f03e0800ee3 0.88% avc_has_perm_noaudit 0.79% cp_new_stat 0.76% avc_has_perm_flags 0.69% path_init 0.68% getname_flags 0.66% system_call 0.58% generic_permission 0.55% lookup_fast 0.54% user_path_at_empty 0.51% vfs_fstatat 0.49% vfs_getattr 0.49% filename_lookup 0.49% strncpy_from_user 0.44% generic_fillattr 0.40% inode_has_perm.isra.32.constprop.61 0.38% ext4_getattr 0.34% complete_walk 0.34% lg_local_unlock 0.27% d_rcu_to_refcount 0.25% __inode_permission 0.23% _copy_to_user 0.23% security_inode_getattr 0.22% mntget 0.22% selinux_inode_getattr 0.21% SYSC_newstat 0.21% mntput_no_expire 0.20% putname 0.17% path_put 0.16% security_inode_permission 0.16% start_routine 0.14% mntput 0.14% final_putname 0.14% _cond_resched 0.12% inode_permission 0.10% user_path_at 0.09% __xstat64 0.07% sys_newstat 0.03% __xstat@plt 0.03% update_cfs_rq_blocked_load 0.02% task_tick_fair 0.01% common_interrupt 0.01% ktime_get 0.01% lapic_next_deadline 0.01% run_timer_softirq 0.01% hsw_unclaimed_reg_check.isra.6 0.01% sched_clock_cpu 0.01% rcu_check_callbacks 0.01% update_cfs_shares 0.01% _raw_spin_lock 0.01% irqtime_account_irq 0.01% __do_softirq 0.01% ret_from_sys_call 0.01% i915_read32 0.01% hrtimer_interrupt 0.01% update_curr 0.01% profile_tick 0.00% intel_pmu_disable_all 0.00% intel_pmu_enable_all 0.00% tg_load_down 0.00% native_sched_clock 0.00% native_apic_msr_eoi_write 0.00% irqtime_account_process_tick.isra.2 0.00% perf_event_task_tick 0.00% clockevents_program_event 0.00% __acct_update_integrals 0.00% rcu_irq_exit -- 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] batman: Remove reference to compare_ether_addr
This function is being removed, rename the reference.
Signed-off-by: Joe Perches
---
net/batman-adv/main.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h
index 5e9aebb..7333cf8 100644
--- a/net/batman-adv/main.h
+++ b/net/batman-adv/main.h
@@ -253,7 +253,7 @@ static inline void batadv_dbg(int type __always_unused,
/* returns 1 if they are the same ethernet addr
*
- * note: can't use compare_ether_addr() as it requires aligned memory
+ * note: can't use ether_addr_equal() as it requires aligned memory
*/
static inline int batadv_compare_eth(const void *data1, const void *data2)
{
--
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 v7 1/4] spinlock: A new lockref structure for lockless update of refcount
On Sun, Sep 01, 2013 at 11:35:21PM +0100, Al Viro wrote:
> > I wonder if there is some false sharing going on. But I don't see that
> > either, this is the percpu offset map afaik:
> >
> > f560 d files_lglock_lock
> > f564 d nr_dentry
> > f568 d last_ino
> > f56c d nr_unused
> > f570 d nr_inodes
> > f574 d vfsmount_lock_lock
> > f580 d bh_accounting
> >
> > and I don't see anything there that would get cross-cpu accesses, so
> > there shouldn't be any cacheline bouncing. That's the whole point of
> > percpu variables, after all.
>
> Hell knows... Are you sure you don't see br_write_lock() at all? I don't
> see anything else that would cause cross-cpu traffic with that layout...
GRRR... I see something else:
void file_sb_list_del(struct file *file)
{
if (!list_empty(>f_u.fu_list)) {
lg_local_lock_cpu(_lglock, file_list_cpu(file));
list_del_init(>f_u.fu_list);
lg_local_unlock_cpu(_lglock, file_list_cpu(file));
}
}
will cheerfully cause cross-CPU traffic. If that's what is going on, the
earlier patch I've sent (not putting non-regulars and files opened r/o
on ->s_list) should reduce the cacheline bouncing on that cacheline.
--
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-next] staging: vt6655: Remove commented out block with compare_ether_addr
compare_ether_addr is being removed so remove
even the commented out code referring to it.
Signed-off-by: Joe Perches
---
drivers/staging/vt6655/vntwifi.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/drivers/staging/vt6655/vntwifi.c b/drivers/staging/vt6655/vntwifi.c
index d8f4f8e..d2bdb71 100644
--- a/drivers/staging/vt6655/vntwifi.c
+++ b/drivers/staging/vt6655/vntwifi.c
@@ -752,25 +752,3 @@ VNTWIFIbChannelSwitch(
//spin_unlock_irq(>lock);
return true;
}
-
-/*
- bool
- VNTWIFIbRadarPresent(
- void *pMgmtObject,
- unsigned char byChannel
-) {
- PSMgmtObjectpMgmt = (PSMgmtObject) pMgmtObject;
- if ((pMgmt->eCurrMode == WMAC_MODE_IBSS_STA) &&
- (byChannel == (unsigned char) pMgmt->uCurrChannel) &&
- (pMgmt->bSwitchChannel != true) &&
- (pMgmt->b11hEnable == true)) {
- if (!compare_ether_addr(pMgmt->abyIBSSDFSOwner,
CARDpGetCurrentAddress(pMgmt->pAdapter))) {
- pMgmt->byNewChannel = CARDbyAutoChannelSelect(pMgmt->pAdapter,(unsigned
char) pMgmt->uCurrChannel);
- pMgmt->bSwitchChannel = true;
- }
- BEACONbSendBeacon(pMgmt);
- CARDbChannelSwitch(pMgmt->pAdapter, 0, pMgmt->byNewChannel, 10);
- }
- return true;
- }
-*/
--
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 v7 1/4] spinlock: A new lockref structure for lockless update of refcount
On Sun, Sep 01, 2013 at 03:16:24PM -0700, Linus Torvalds wrote: > Does not seem to matter. Still 66% mntput_no_expire, 31% path_init. > And that lg_local_lock() takes 5-6% of CPU, pretty much all of which > is that single xadd instruction that implements the spinlock. > > This is on /tmp, which is tmpfs. But I don't see how any of that could > matter. "mntput()" does an unconditional call to mntput_no_expire(), > and mntput_no_expire() does that br_read_lock() unconditionally too. > > Note that I'm talking about that "cheap" *read* lock being expensive. > It's the local one, not the global one. So it's not what Waiman saw > with the global lock. This is a local per-cpu thing. > > That read-lock is supposed to be very cheap - it's just a per-cpu > spinlock. But it ends up being very expensive for some reason. I'm not > quite sure why - I don't see any lg_global_lock() calls at all, so... > > I wonder if there is some false sharing going on. But I don't see that > either, this is the percpu offset map afaik: > > f560 d files_lglock_lock > f564 d nr_dentry > f568 d last_ino > f56c d nr_unused > f570 d nr_inodes > f574 d vfsmount_lock_lock > f580 d bh_accounting > > and I don't see anything there that would get cross-cpu accesses, so > there shouldn't be any cacheline bouncing. That's the whole point of > percpu variables, after all. Hell knows... Are you sure you don't see br_write_lock() at all? I don't see anything else that would cause cross-cpu traffic with that layout... -- 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 v7 1/4] spinlock: A new lockref structure for lockless update of refcount
On Sun, Sep 1, 2013 at 2:23 PM, Al Viro wrote: > > How much of that is due to br_write_lock() taken in mntput_no_expire() > for no good reason? IOW, could you try shmem.c patch I've sent yesterday > and see how much effect does it have?[1] Basically, we get it grabbed > exclusive on each final fput() of a struct file created by shmem_file_setup(), > which is _not_ a rare event. And the only reason for that is not having > shm_mnt marked long-living, even though its refcount never hits 0... Does not seem to matter. Still 66% mntput_no_expire, 31% path_init. And that lg_local_lock() takes 5-6% of CPU, pretty much all of which is that single xadd instruction that implements the spinlock. This is on /tmp, which is tmpfs. But I don't see how any of that could matter. "mntput()" does an unconditional call to mntput_no_expire(), and mntput_no_expire() does that br_read_lock() unconditionally too. Note that I'm talking about that "cheap" *read* lock being expensive. It's the local one, not the global one. So it's not what Waiman saw with the global lock. This is a local per-cpu thing. That read-lock is supposed to be very cheap - it's just a per-cpu spinlock. But it ends up being very expensive for some reason. I'm not quite sure why - I don't see any lg_global_lock() calls at all, so... I wonder if there is some false sharing going on. But I don't see that either, this is the percpu offset map afaik: f560 d files_lglock_lock f564 d nr_dentry f568 d last_ino f56c d nr_unused f570 d nr_inodes f574 d vfsmount_lock_lock f580 d bh_accounting and I don't see anything there that would get cross-cpu accesses, so there shouldn't be any cacheline bouncing. That's the whole point of percpu variables, after all. Odd. What am I missing? 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: 3.11-final plan: unpriviledged user can crash the kernel (using bluetooth rfcomm)
Hi! > >> . Python sources for client/server are at > >> > >> http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/ > >> > > So... In 3.11 unpriviledged user can crash the kernel, but the fix is > > too big, so we release it without the fix? > > > > Somehow, I don't think that's good idea. > > can you boot a bluetooth-next kernel and see if the planned changes are > fixing this or not. I would like to have that confirmed before we start any > speculations here. > > If the RFCOMM TTY rework that we have in bluetooth-next fixes this issue, > then we can have a look at if this can be patched for 3.11 or a stable kernel > without having to include the whole patch series. Or if the TTY subsystem > changed from 2.6.32 so much that we have to take the whole changes. > > However, please also note there is a different between RFCOMM sockets and > RFCOMM TTYs. I would be curious if only the TTY part is affected or also the > socket part. > Well, you are in as good position to repeat it as I am. Sources are in the CVS referenced above (and they are trivial). The version that reproduces the problem is marked as such in changelog. I already modified my system to work (not triggering oopsen)... Yes, I can probably setup linux-next. It will take some time. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
[tip:x86/smap] Introduce [compat_]save_altstack_ex() to unbreak x86 SMAP
Commit-ID: bd1c149aa9915b9abb6d83d0f01dfd2ace0680b5
Gitweb: http://git.kernel.org/tip/bd1c149aa9915b9abb6d83d0f01dfd2ace0680b5
Author: Al Viro
AuthorDate: Sun, 1 Sep 2013 20:35:01 +0100
Committer: H. Peter Anvin
CommitDate: Sun, 1 Sep 2013 14:16:33 -0700
Introduce [compat_]save_altstack_ex() to unbreak x86 SMAP
For performance reasons, when SMAP is in use, SMAP is left open for an
entire put_user_try { ... } put_user_catch(); block, however, calling
__put_user() in the middle of that block will close SMAP as the
STAC..CLAC constructs intentionally do not nest.
Furthermore, using __put_user() rather than put_user_ex() here is bad
for performance.
Thus, introduce new [compat_]save_altstack_ex() helpers that replace
__[compat_]save_altstack() for x86, being currently the only
architecture which supports put_user_try { ... } put_user_catch().
Reported-by: H. Peter Anvin
Signed-off-by: Al Viro
Signed-off-by: H. Peter Anvin
Cc: # v3.8+
Link: http://lkml.kernel.org/n/tip-es5p6y64if71k8p5u08ag...@git.kernel.org
---
arch/x86/ia32/ia32_signal.c | 2 +-
arch/x86/kernel/signal.c| 6 +++---
include/linux/compat.h | 7 +++
include/linux/signal.h | 8
4 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
index bccfca6..665a730 100644
--- a/arch/x86/ia32/ia32_signal.c
+++ b/arch/x86/ia32/ia32_signal.c
@@ -457,7 +457,7 @@ int ia32_setup_rt_frame(int sig, struct ksignal *ksig,
else
put_user_ex(0, >uc.uc_flags);
put_user_ex(0, >uc.uc_link);
- err |= __compat_save_altstack(>uc.uc_stack, regs->sp);
+ compat_save_altstack_ex(>uc.uc_stack, regs->sp);
if (ksig->ka.sa.sa_flags & SA_RESTORER)
restorer = ksig->ka.sa.sa_restorer;
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index cf91358..d859eea 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -358,7 +358,7 @@ static int __setup_rt_frame(int sig, struct ksignal *ksig,
else
put_user_ex(0, >uc.uc_flags);
put_user_ex(0, >uc.uc_link);
- err |= __save_altstack(>uc.uc_stack, regs->sp);
+ save_altstack_ex(>uc.uc_stack, regs->sp);
/* Set up to return from userspace. */
restorer = VDSO32_SYMBOL(current->mm->context.vdso,
rt_sigreturn);
@@ -423,7 +423,7 @@ static int __setup_rt_frame(int sig, struct ksignal *ksig,
else
put_user_ex(0, >uc.uc_flags);
put_user_ex(0, >uc.uc_link);
- err |= __save_altstack(>uc.uc_stack, regs->sp);
+ save_altstack_ex(>uc.uc_stack, regs->sp);
/* Set up to return from userspace. If provided, use a stub
already in userspace. */
@@ -490,7 +490,7 @@ static int x32_setup_rt_frame(struct ksignal *ksig,
else
put_user_ex(0, >uc.uc_flags);
put_user_ex(0, >uc.uc_link);
- err |= __compat_save_altstack(>uc.uc_stack, regs->sp);
+ compat_save_altstack_ex(>uc.uc_stack, regs->sp);
put_user_ex(0, >uc.uc__pad0);
if (ksig->ka.sa.sa_flags & SA_RESTORER) {
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 7f0c1dd..ec1aee4 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -669,6 +669,13 @@ asmlinkage long compat_sys_sigaltstack(const
compat_stack_t __user *uss_ptr,
int compat_restore_altstack(const compat_stack_t __user *uss);
int __compat_save_altstack(compat_stack_t __user *, unsigned long);
+#define compat_save_altstack_ex(uss, sp) do { \
+ compat_stack_t __user *__uss = uss; \
+ struct task_struct *t = current; \
+ put_user_ex(ptr_to_compat((void __user *)t->sas_ss_sp), &__uss->ss_sp);
\
+ put_user_ex(sas_ss_flags(sp), &__uss->ss_flags); \
+ put_user_ex(t->sas_ss_size, &__uss->ss_size); \
+} while (0);
asmlinkage long compat_sys_sched_rr_get_interval(compat_pid_t pid,
struct compat_timespec __user
*interval);
diff --git a/include/linux/signal.h b/include/linux/signal.h
index d897484..2ac423b 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -434,6 +434,14 @@ void signals_init(void);
int restore_altstack(const stack_t __user *);
int __save_altstack(stack_t __user *, unsigned long);
+#define save_altstack_ex(uss, sp) do { \
+ stack_t __user *__uss = uss; \
+ struct task_struct *t = current; \
+ put_user_ex((void __user *)t->sas_ss_sp, &__uss->ss_sp); \
+ put_user_ex(sas_ss_flags(sp), &__uss->ss_flags); \
+ put_user_ex(t->sas_ss_size, &__uss->ss_size); \
+} while (0);
+
#ifdef CONFIG_PROC_FS
struct seq_file;
extern void render_sigset_t(struct seq_file *, const char *,
