Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
On Sun, Aug 26, 2012 at 6:29 PM, Shilimkar, Santosh
wrote:
> On Sun, Aug 26, 2012 at 3:53 PM, NeilBrown wrote:
>>
>> On Sun, 26 Aug 2012 09:47:50 +0530 "Shilimkar, Santosh"
>> wrote:
>>
>> > + Jon,
>> >
>> > On Sat, Aug 25, 2012 at 5:14 PM, NeilBrown wrote:
>> > >
>> > >
>> > >
>> > > Current kernel will wake from suspend on an event on any active
>> > > GPIO even if enable_irq_wake() wasn't called.
>> > >
>> > > There are two reasons that the hardware wake-enable bit should be set:
>> > >
>> > > 1/ while non-suspended the CPU might go into a deep sleep (off_mode)
>> > > in which the wake-enable bit is needed for an interrupt to be
>> > > recognised.
>> > > 2/ while suspended the GPIO interrupt should wake from suspend if and
>> > >only if irq_wake as been enabled.
>> > >
>> > > The code currently doesn't keep these two reasons separate so they get
>> > > confused and sometimes the wakeup flags is set incorrectly.
>> > >
>> > > This patch reverts:
>> > > commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
>> > > gpio/omap: remove suspend/resume callbacks
>> > > and
>> > > commit 0aa2727399c0b78225021413022c164cb99fbc5e
>> > > gpio/omap: remove suspend_wakeup field from struct gpio_bank
>> > >
>> > > and makes some minor changes so that we have separate flags for "GPIO
>> > > should wake from deep idle" and "GPIO should wake from suspend".
>> > >
>> > > With this patch, the GPIO from my touch screen doesn't wake my device
>> > > any more, which is what I want.
>> > >
>> > > Cc: Kevin Hilman
>> > > Cc: Tony Lindgren
>> > > Cc: Santosh Shilimkar
>> > > Cc: Cousson, Benoit
>> > > Cc: Grant Likely
>> > > Cc: Tarun Kanti DebBarma
>> > > Cc: Felipe Balbi
>> > > Cc: Govindraj.R
>> > >
>> > > Signed-off-by: NeilBrown
>> > >
>> > The patch doesn't seems to be correct. At least the 2/ gets
>> > fixed with a proper IRQCHIP flag. Can you try the patch at
>> > end of the email and see if it helps ? Am attaching it in case
>> > mailer damages it.
>> >
>> > Regards
>> > Santosh
>> >
>> > >From b8a38fc75e046f6462610e26c47c620cad850c24 Mon Sep 17 00:00:00 2001
>> > From: Santosh Shilimkar
>> > Date: Sun, 26 Aug 2012 09:39:51 +0530
>> > Subject: [PATCH] gpio: omap: Set IRQCHIP_MASK_ON_SUSPEND to mask all
>> > non-wakeup gpio wakeups.
>> >
>> > Set the irq chip flag IRQCHIP_MASK_ON_SUSPEND to cause the irq pm code
>> > to mask all non-wake gpios in suspend, which will ensure the wakeup
>> > enable
>> > bit is not set on non-wake gpios.
>> >
>> > Signed-off-by: Santosh Shilimkar
>> > ---
>> > drivers/gpio/gpio-omap.c |1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> > index e6efd77..50b4c18 100644
>> > --- a/drivers/gpio/gpio-omap.c
>> > +++ b/drivers/gpio/gpio-omap.c
>> > @@ -779,6 +779,7 @@ static struct irq_chip gpio_irq_chip = {
>> > .irq_unmask = gpio_unmask_irq,
>> > .irq_set_type = gpio_irq_type,
>> > .irq_set_wake = gpio_wake_enable,
>> > + .flags = IRQCHIP_MASK_ON_SUSPEND;
>> > };
>> >
>> >
>> > /*-*/
>>
>>
>> No obvious damage, unless the mailer is responsible or the ';' at the end
>> of
>> the line, rather than ',' :-)
>>
> :-) That was typo.
>
>> The approach makes sense, but does actually work. Should be fixable
>> though.
>>
>> When I try this I get:
>>
>>
>>
>> [ 158.114440] Checking wakeup interrupts
>> [ 158.118408] Unhandled fault: external abort on non-linefetch (0x1028)
>> at 0xfb054040
>> [ 158.126403] Internal error: : 1028 [#1] PREEMPT ARM
>> [ 158.131500] Modules linked in: ipv6 g_ether hso libertas_sdio libertas
>> cfg80211
>> [ 158.139190] CPU: 0Not tainted (3.5.0-gta04-debug+ #2)
>> [ 158.144927] PC is at _set_gpio_triggering+0x38/0x258
>> [ 158.150115] LR is at gpio_mask_irq+0xac/0xc0
>> [ 158.154602] pc : []lr : []psr: 6193
>> [ 158.154602] sp : db521e90 ip : 0011 fp : beeecc2c
>> [ 158.166595] r10: c05c8ebc r9 : daa5a858 r8 : 0003
>> [ 158.172027] r7 : a193 r6 : r5 : fb054000 r4 : ded44e18
>> [ 158.178863] r3 : 0001 r2 : r1 : ded30340 r0 : 0040
>> [ 158.185668] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
>> Segment use
>>
>> so it looks like runtime PM has turned off the iclk to the GPIO module so
>> that
>> when we try to tell it to change settings, it is no longer listening to
>> us.
> From the crash logs it appears like that.
>
>> The "Checking wakeup interrupts" function happens very late in the suspend
>> cycle, after all the suspend_late and suspend_noirq functions have run.
>> Maybe it needs to be moved earlier...
>>
> No it shouldn't be moved and it is that point for lot many good
> reasons. Ofcourse
> this omap gpio driver crash needs to be addressed. Need to think bit
> more on this
> issue.
>
After thinking bit more on this, the problem seems to be coming
mainly because the gpio device is
[RFC] module: signature infrastructure
OK, I took a look at the module.c parts of David and Dmitry's patchsets,
and didn't really like either, but I stole parts of David's to make
this.
So, here's the module.c part of module signing. I hope you two got time
to discuss the signature format details? Mimi suggested a scheme where
the private key would never be saved on disk (even temporarily), but I
didn't see patches. Frankly it's something we can do later; let's aim
at getting the format right for the next merge window.
Cheers,
Rusty.
---
This patch doesn't compile: we need to implement:
int mod_verify_sig(const void *mod, unsigned long modlen,
const void *sig, unsigned long siglen,
bool *sig_ok);
Also, we need to actually append the signatures during build.
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index ad7e2e5..9b2b8d3 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1582,6 +1582,12 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
log everything. Information is printed at KERN_DEBUG
so loglevel=8 may also need to be specified.
+ module.sig_enforce
+ [KNL] When CONFIG_MODULE_SIG is set, this means that
+ modules without (valid) signatures will fail to load.
+ Note that if CONFIG_MODULE_SIG_ENFORCE is set, that
+ is always true, so this option does nothing.
+
mousedev.tap_time=
[MOUSE] Maximum time between finger touching and
leaving touchpad surface for touch to be considered
diff --git a/include/linux/module.h b/include/linux/module.h
index fbcafe2..7760c6d 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -21,6 +21,9 @@
#include
#include
+/* In stripped ARM and x86-64 modules, ~ is surprisingly rare. */
+#define MODULE_SIG_STRING "~Module signature appended~\n"
+
/* Not Yet Implemented */
#define MODULE_SUPPORTED_DEVICE(name)
@@ -260,6 +263,11 @@ struct module
const unsigned long *unused_gpl_crcs;
#endif
+#ifdef CONFIG_MODULE_SIG
+ /* Signature was verified. */
+ bool sig_ok;
+#endif
+
/* symbols that will be GPL-only in the near future. */
const struct kernel_symbol *gpl_future_syms;
const unsigned long *gpl_future_crcs;
diff --git a/init/Kconfig b/init/Kconfig
index af6c7f8..7452e19 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1585,6 +1585,20 @@ config MODULE_SRCVERSION_ALL
the version). With this option, such a "srcversion" field
will be created for all modules. If unsure, say N.
+config MODULE_SIG
+ bool "Module signature verification"
+ depends on MODULES
+ help
+ Check modules for valid signatures upon load: the signature
+ is simply appended to the module. For more information see
+ Documentation/module-signing.txt.
+
+config MODULE_SIG_FORCE
+ bool "Require modules to be validly signed"
+ depends on MODULE_SIG
+ help
+ Reject unsigned modules or signed modules for which we don't have a
+ key. Without this, such modules will simply taint the kernel.
endif # MODULES
config INIT_ALL_POSSIBLE
diff --git a/kernel/module.c b/kernel/module.c
index 4edbd9c..3cbd1a4 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -102,6 +102,43 @@ static LIST_HEAD(modules);
struct list_head *kdb_modules = /* kdb needs the list of modules */
#endif /* CONFIG_KGDB_KDB */
+#ifdef CONFIG_MODULE_SIG
+#ifdef CONFIG_MODULE_SIG_ENFORCE
+static bool sig_enforce = true;
+#else
+static bool sig_enforce = false;
+
+static int param_set_bool_enable_only(const char *val,
+ const struct kernel_param *kp)
+{
+ int err;
+ bool test;
+ struct kernel_param dummy_kp = *kp;
+
+ dummy_kp.arg =
+
+ err = param_set_bool(val, _kp);
+ if (err)
+ return err;
+
+ /* Don't let them unset it once it's set! */
+ if (!test && sig_enforce)
+ return -EROFS;
+
+ if (test)
+ sig_enforce = true;
+ return 0;
+}
+
+static const struct kernel_param_ops param_ops_bool_enable_only = {
+ .set = param_set_bool_enable_only,
+ .get = param_get_bool,
+};
+#define param_check_bool_enable_only param_check_bool
+
+module_param(sig_enforce, bool_enable_only, 0644);
+#endif /* !CONFIG_MODULE_SIG_ENFORCE */
+#endif /* CONFIG_MODULE_SIG */
/* Block module loading/unloading? */
int modules_disabled = 0;
@@ -136,6 +173,7 @@ struct load_info {
unsigned long symoffs, stroffs;
struct _ddebug *debug;
unsigned int num_debug;
+ bool sig_ok;
struct {
unsigned int sym, str, mod, vers, info, pcpu;
} index;
@@ -2399,7 +2437,50 @@ static
Re: [RFC v2 4/7] modsig: add integrity_module_check hook
Dmitry Kasatkin writes:
> +#else
> +static inline int integrity_module_check(const void *buf, unsigned long len)
> +{
> + return 0;
> +}
> +#endif
...
> + err = integrity_module_check(hdr, len);
> + if (err < 0)
> + goto free_hdr;
> +
> + /* cut signature tail */
> + info->len = err;
This is a bug.
Firstly, you want the 'long' not 'int' as the return vale from
integrity_module_check(). But mainly, you want it to return 'len' not
0.
I'd also prefer it to be *immediately* after we copy from userspace.
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH] extcon-max8997: remove usage of ret in max8997_muic_handle_charger_type_detach
> any comments ?
>
Sorry for replying late.
It has been applied to the extcon-for-next tree at
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/extcon-for-next
, which will appear in hours.
> On Wed, Aug 15, 2012 at 12:19 PM, Devendra Naga
> wrote:
> > actually we can do returns with error or success with out ret in this
> > function,
> > so remove the ret variable, and reduce a very little (4byte) space on stack
> > of this function
> >
> > Signed-off-by: Devendra Naga
> > ---
> > compile tested.
> >
> > drivers/extcon/extcon-max8997.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/extcon/extcon-max8997.c
> > b/drivers/extcon/extcon-max8997.c
> > index ef9090a..77b66b0 100644
> > --- a/drivers/extcon/extcon-max8997.c
> > +++ b/drivers/extcon/extcon-max8997.c
> > @@ -271,8 +271,6 @@ out:
> > static int max8997_muic_handle_charger_type_detach(
> > struct max8997_muic_info *info)
> > {
> > - int ret = 0;
> > -
> > switch (info->pre_charger_type) {
> > case MAX8997_CHARGER_TYPE_USB:
> > extcon_set_cable_state(info->edev, "USB", false);
> > @@ -290,11 +288,11 @@ static int max8997_muic_handle_charger_type_detach(
> > extcon_set_cable_state(info->edev, "Fast-charger", false);
> > break;
> > default:
> > - ret = -EINVAL;
> > + return -EINVAL;
> > break;
> > }
> >
> > - return ret;
> > + return 0;
> > }
> >
> > static int max8997_muic_handle_charger_type(struct max8997_muic_info *info,
> > --
> > 1.7.12.rc2
> >
>
>
>
>
>
>
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z� 췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝
Re: [RFC/PATCH] mmc: core: Add support for idle time BKOPs
On Thu, August 30, 2012 12:36 am, Jaehoon Chung wrote:
> On 08/05/2012 10:08 PM, Maya Erez wrote:
>> When the mmcqd thread is idle, a delayed work is created to check the
>> need for BKOPs. The time to start the delayed work is calculated based
>> on the host controller suspend timeout, in case it was set. If not, a
>> default time is used.
>> If BKOPs is required in level 1, which is non-blocking, there will be
>> polling of the card status to wait for the BKOPs completion and prevent
>> suspend that will interrupt the BKOPs.
>> If the card raised an exception, the need for urgent BKOPs (level 2/3)
>> will be checked immediately and if needed, the BKOPs will be performed
>> without waiting for the next idle time.
>>
>> Signed-off-by: Maya Erez
>> Signed-off-by: Jaehoon Chung
>> ---
>> This patch depends on the following patch:
>> [PATCH v11] mmc: support BKOPS feature for eMMC
>>
>> This patch is based on the periodic BKOPs implementation in version 8 of
>> "support BKOPS feature for eMMC" patch.
>> The patch was modified to answer the following issues:
>> - In order to prevent a race condition between going into suspend and
>> starting BKOPs,
>> the suspend timeout of the host controller is taking into accound in
>> determination of the start time
>> of the delayed work
>> - Since mmc_start_bkops is called from two contexts now, mmc_claim_host
>> was moved to the beginning of the function
>> - Also, the check of doing_bkops should be protected when determing if
>> an HPI is needed due to the same reason.
>> - Starting and canceling the delayed work in each idle caused
>> degradation of iozone performance. Therefore,
>> the delayed work is not started on each idle. Currently the number of
>> issued requests from the last delayed work
>> is the trigger. We still investigate the best trigger for starting the
>> delayed work.
>> - To prevent degaradtion of iozone performance we also moved the call to
>> mmc_claim_host outside of mmc_stop_bkops
>> and its release is done after issue_fn. This prevents an addition of a
>> full claim and release, that is also done
>> in issue_fn for the first request after idle time.
>> ---
>> drivers/mmc/card/block.c |3 +
>> drivers/mmc/card/queue.c | 20 +
>> drivers/mmc/core/core.c | 188
>> +++---
>> drivers/mmc/core/host.c | 24 ++
>> include/linux/mmc/card.h |3 +
>> include/linux/mmc/core.h |3 +
>> include/linux/mmc/host.h | 25 ++
>> 7 files changed, 256 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> index f1c84de..4519271 100644
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -1268,6 +1268,9 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue
>> *mq, struct request *rqc)
>> if (!rqc && !mq->mqrq_prev->req)
>> return 0;
>>
>> +if (rqc)
>> +card->idle_bkops_rw_reqs_nr++;
>> +
>> do {
>> if (rqc) {
>> /*
>> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
>> index e360a97..c9e1cee 100644
>> --- a/drivers/mmc/card/queue.c
>> +++ b/drivers/mmc/card/queue.c
>> @@ -51,6 +51,7 @@ static int mmc_queue_thread(void *d)
>> {
>> struct mmc_queue *mq = d;
>> struct request_queue *q = mq->queue;
>> +bool release_host = false;
>>
>> current->flags |= PF_MEMALLOC;
>>
>> @@ -66,13 +67,32 @@ static int mmc_queue_thread(void *d)
>> spin_unlock_irq(q->queue_lock);
>>
>> if (req || mq->mqrq_prev->req) {
>> +/*
>> + * If this is the first request, BKOPs might be in
>> + * progress and needs to be stopped before issuing the
>> + * request
>> + * */
>> +if (!mq->mqrq_prev->req &&
>> +mq->card->ext_csd.bkops_en &&
>> +mq->card->idle_bkops_rw_reqs_nr == 0) {
>> +release_host = true;
>> +mmc_claim_host(mq->card->host);
>> +mmc_stop_bkops(mq->card);
>> +}
>> +
>> set_current_state(TASK_RUNNING);
>> mq->issue_fn(mq, req);
>> +if (release_host) {
>> +release_host = false;
>> +mmc_release_host(mq->card->host);
>> +}
>> } else {
>> if (kthread_should_stop()) {
>> set_current_state(TASK_RUNNING);
>> break;
>> }
>> +
>> +mmc_start_delayed_bkops(mq->card);
>> up(>thread_sem);
>> schedule();
>> down(>thread_sem);
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index ed2cc93..14830d4
[PATCH v4] media: v4l2-ctrls: add control for dpcm predictor
From: Lad, Prabhakar
add V4L2_CID_DPCM_PREDICTOR control of type menu, which
determines the dpcm predictor. The predictor can be either
simple or advanced.
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
Acked-by: Hans Verkuil
Reviewed-by: Sylwester Nawrocki
Cc: Sakari Ailus
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Hans de Goede
Cc: Kyungmin Park
Cc: Rob Landley
---
This patches has one checkpatch warning for line over
80 characters altough it can be avoided I have kept it
for consistency.
Changes for v4:
1: Aligned the description to fit appropriately in the
para tag, pointed by Sylwester.
Changes for v3:
1: Added better explanation for DPCM, pointed by Hans.
Changes for v2:
1: Added documentaion in controls.xml pointed by Sylwester.
2: Chnaged V4L2_DPCM_PREDICTOR_ADVANCE to V4L2_DPCM_PREDICTOR_ADVANCED
pointed by Sakari.
Documentation/DocBook/media/v4l/controls.xml | 46 +-
drivers/media/v4l2-core/v4l2-ctrls.c |9 +
include/linux/videodev2.h|5 +++
3 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 93b9c68..ad873ea 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -4267,7 +4267,51 @@ interface and may change in the future.
pixels / second.
-
+
+ V4L2_CID_DPCM_PREDICTOR
+ menu
+
+
+Differential pulse-code modulation (DPCM)
is a signal
+ encoder that uses the baseline of pulse-code modulation (PCM) but
adds some
+ functionalities based on the prediction of the samples of the
signal. The input
+ can be an analog signal or a digital signal.
+
+ If the input is a continuous-time analog signal, it needs to
be sampled
+ first so that a discrete-time signal is the input to the DPCM
encoder.
+
+ Simple: take the values of two consecutive samples; if they
are analog
+ samples, quantize them; calculate the difference between the first
one and the
+ next; the output is the difference, and it can be further entropy
coded.
+
+ Advanced: instead of taking a difference relative to a
previous input sample,
+ take the difference relative to the output of a local model of the
decoder process;
+ in this option, the difference can be quantized, which allows a
good way to
+ incorporate a controlled loss in the encoding.
+
+ Applying one of these two processes, short-term redundancy
(positive correlation of
+ nearby values) of the signal is eliminated; compression ratios on
the order of 2 to 4
+ can be achieved if differences are subsequently entropy coded,
because the entropy of
+ the difference signal is much smaller than that of the original
discrete signal treated
+ as independent samples.For more information about DPCM see http://en.wikipedia.org/wiki/Differential_pulse-code_modulation;>Wikipedia.
+
+
+
+
+
+
+V4L2_DPCM_PREDICTOR_SIMPLE
+ Predictor type is simple
+
+
+
V4L2_DPCM_PREDICTOR_ADVANCED
+ Predictor type is advanced
+
+
+
+
+
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b6a2ee7..2d7bc15 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -425,6 +425,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Gray",
NULL,
};
+ static const char * const dpcm_predictor[] = {
+ "Simple Predictor",
+ "Advanced Predictor",
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -502,6 +507,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
+ case V4L2_CID_DPCM_PREDICTOR:
+ return dpcm_predictor;
default:
return NULL;
@@ -732,6 +739,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_IMAGE_PROC_CLASS: return "Image Processing
Controls";
case V4L2_CID_LINK_FREQ:return "Link Frequency";
case V4L2_CID_PIXEL_RATE: return "Pixel Rate";
+ case V4L2_CID_DPCM_PREDICTOR: return "DPCM Predictor";
default:
return NULL;
@@ -832,6 +840,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case
Re: linux-next: build warnings after merge of the drm tree
On Tue, Sep 04, 2012 at 01:58:29PM +1000, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
>
> drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
> drivers/gpu/drm/udl/Kconfig:1:symbol DRM_UDL depends on
> USB_ARCH_HAS_HCD
> drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
> drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
> drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
> warning: (PPC_PS3) selects USB_OHCI_LITTLE_ENDIAN which has unmet direct
> dependencies (USB_SUPPORT && USB_OHCI_HCD)
> warning: (PPC_PS3 && PPC_CELLEB) selects USB_OHCI_BIG_ENDIAN_MMIO which has
> unmet direct dependencies (USB_SUPPORT && USB_OHCI_HCD)
> warning: (PPC_PS3 && PPC_CELLEB && USB_EHCI_HCD_PMC_MSP && XPS_USB_HCD_XILINX
> && USB_OCTEON_EHCI) selects USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct
> dependencies (USB_SUPPORT && USB_EHCI_HCD && (PPC_CELLEB || PPC_PS3 || 440EPX
> || ARCH_IXP4XX || XPS_USB_HCD_XILINX || PPC_MPC512x || CPU_CAVIUM_OCTEON ||
> PMC_MSP || SPARC_LEON || MIPS_SEAD3))
>
> The x86_64 allmodconfig produces these:
>
> drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
> drivers/gpu/drm/udl/Kconfig:1:symbol DRM_UDL depends on
> USB_ARCH_HAS_HCD
> drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
> drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
> drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
> warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB &&
> JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK && TABLET_USB_HANWANG
> && TABLET_USB_KBTAB && TABLET_USB_WACOM && TOUCHSCREEN_USB_COMPOSITE &&
> INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE && INPUT_POWERMATE && INPUT_YEALINK
> && INPUT_CM109 && RC_ATI_REMOTE && IR_IMON && IR_MCEUSB && IR_REDRAT3 &&
> IR_STREAMZAP && IR_IGUANA && IR_TTUSBIR && DRM_USB) selects USB which has
> unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD)
>
> Maybe introduced by commit df0b34430072 ("drm/usb: select USB_SUPPORT in
> Kconfig"), maybe interacting with a commit 8f057d7bca54 ("gpu/mfd/usb:
> Fix USB randconfig problems") from Linus' tree (that added "depends on
> USB_ARCH_HAS_HCD" to "config DRM_USB" and "config DRM_UDL").
>
Looks like it. I'll have a look once the tree is available.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: v4l2-ctrls: add control for test pattern
Hi Sakari, Thanks for the review. On Tuesday 04 September 2012 01:09 AM, Sakari Ailus wrote: > Hi Prabhakar, > > Thanks for the patch. > > On Mon, Sep 03, 2012 at 02:46:17PM +0530, Prabhakar Lad wrote: >> From: Lad, Prabhakar >> >> add V4L2_CID_TEST_PATTERN of type menu, which determines >> the internal test pattern selected by the device. >> >> Signed-off-by: Lad, Prabhakar >> Signed-off-by: Manjunath Hadli >> Cc: Sakari Ailus >> Cc: Hans Verkuil >> Cc: Laurent Pinchart >> Cc: Mauro Carvalho Chehab >> Cc: Sylwester Nawrocki >> Cc: Hans de Goede >> Cc: Kyungmin Park >> Cc: Rob Landley >> Cc: HeungJun Kim >> Cc: Rob Landley >> --- >> This patches has one checkpatch warning for line over >> 80 characters altough it can be avoided I have kept it >> for consistency. >> >> Documentation/DocBook/media/v4l/controls.xml | 52 >> ++ >> drivers/media/v4l2-core/v4l2-ctrls.c | 16 >> include/linux/videodev2.h| 12 ++ >> 3 files changed, 80 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/controls.xml >> b/Documentation/DocBook/media/v4l/controls.xml >> index f704218..06f16e7 100644 >> --- a/Documentation/DocBook/media/v4l/controls.xml >> +++ b/Documentation/DocBook/media/v4l/controls.xml >> @@ -4313,6 +4313,58 @@ interface and may change in the future. >> >> >> >> + >> +> spanname="id">V4L2_CID_TEST_PATTERN >> +menu >> + >> + >> + The capture devices/sensors have the >> capability to >> +generate internal test patterns. This test patterns are used to >> test a device >> +is properly working and can generate the desired waveforms that it >> supports. >> + >> + >> + >> + >> + >> + >> + V4L2_TEST_PATTERN_DISABLED >> + Test pattern generation is disabled >> + >> + >> + >> V4L2_TEST_PATTERN_VERTICAL_LINES >> + Generate vertical lines as test pattern >> + >> + >> + >> V4L2_TEST_PATTERN_HORIZONTAL_LINES >> + Generate horizontal lines as test pattern >> + >> + >> + >> V4L2_TEST_PATTERN_DIAGONAL_LINES >> + Generate diagonal lines as test pattern >> + >> + >> + >> V4L2_TEST_PATTERN_SOLID_BLACK >> + Generate solid black color as test pattern >> + >> + >> + >> V4L2_TEST_PATTERN_SOLID_WHITE >> + Generate solid white color as test pattern >> + >> + >> + >> V4L2_TEST_PATTERN_SOLID_BLUE >> + Generate solid blue color as test pattern >> + >> + >> + >> V4L2_TEST_PATTERN_SOLID_RED >> + Generate solid red color as test pattern >> + >> + >> + >> V4L2_TEST_PATTERN_CHECKER_BOARD >> + Generate a checker board as test pattern >> + > > You're defining 8 different test patterns based on a single device, I guess? > No. > As the test patterns are not standardised, I'd suppose that if another > driver implements the same control, it would require another n menu items > added to the same standard menu. That way we'd run quickly out of menu items > as the maximum is 32. > Agreed the test patterns are not standardized and are hardware dependent, but this entries which have been added are generally common across capture/display/sensors. > For this reason I'd leave the items in the menu up to the driver that > implements the control, until we have more information on the test patterns > different devices implement --- as discussed earlier. > Assuming that I only added disable test pattern and if a driver wants to implement this control and wants add an item to this menu, on what basis an entry to this menu will be qualified then ? Thanks and Regards, --Prabhakar Lad > Kind regards, > -- 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 kvm-ppc tree with the kvm tree
Hi Alexander,
Today's linux-next merge of the kvm-ppc tree got a conflict in
include/linux/kvm.h between commit 4d8b81abc47b ("KVM: introduce readonly
memslot") from the kvm tree and commit 1db21d25a11b ("KVM: PPC: booke:
Add watchdog emulation") from the kvm-ppc tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/kvm.h
index d808694,f4f5be8..000
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@@ -622,9 -621,7 +625,10 @@@ struct kvm_ppc_smmu_info
#define KVM_CAP_PPC_GET_SMMU_INFO 78
#define KVM_CAP_S390_COW 79
#define KVM_CAP_PPC_ALLOC_HTAB 80
-#define KVM_CAP_PPC_BOOKE_WATCHDOG 81
+#ifdef __KVM_HAVE_READONLY_MEM
+#define KVM_CAP_READONLY_MEM 81
+#endif
++#define KVM_CAP_PPC_BOOKE_WATCHDOG 82
#ifdef KVM_CAP_IRQ_ROUTING
pgpB2kbT0seHH.pgp
Description: PGP signature
[v3 1/1] driver-core: Shut up dev_dbg_reatelimited() without DEBUG
dev_dbg_reatelimited() without DEBUG printed "217078 callbacks
suppressed". This shouldn't print anything without DEBUG.
With CONFIG_DYNAMIC_DEBUG, the print should be configured as expected.
Signed-off-by: Hiroshi Doyu
Reported-by: Hin-Tak Leung
Tested-by: Antti Palosaari
Tested-by: Hin-Tak Leung
Acked-by: Hin-Tak Leung
---
include/linux/device.h | 62 +--
1 files changed, 38 insertions(+), 24 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index 9648331..bb6ffcb 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -932,6 +932,32 @@ int _dev_info(const struct device *dev, const char *fmt,
...)
#endif
+/*
+ * Stupid hackaround for existing uses of non-printk uses dev_info
+ *
+ * Note that the definition of dev_info below is actually _dev_info
+ * and a macro is used to avoid redefining dev_info
+ */
+
+#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
+
+#if defined(CONFIG_DYNAMIC_DEBUG)
+#define dev_dbg(dev, format, ...) \
+do {\
+ dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
+} while (0)
+#elif defined(DEBUG)
+#define dev_dbg(dev, format, arg...) \
+ dev_printk(KERN_DEBUG, dev, format, ##arg)
+#else
+#define dev_dbg(dev, format, arg...) \
+({ \
+ if (0) \
+ dev_printk(KERN_DEBUG, dev, format, ##arg); \
+ 0; \
+})
+#endif
+
#define dev_level_ratelimited(dev_level, dev, fmt, ...)
\
do { \
static DEFINE_RATELIMIT_STATE(_rs, \
@@ -955,33 +981,21 @@ do {
\
dev_level_ratelimited(dev_notice, dev, fmt, ##__VA_ARGS__)
#define dev_info_ratelimited(dev, fmt, ...)\
dev_level_ratelimited(dev_info, dev, fmt, ##__VA_ARGS__)
+#if defined(CONFIG_DYNAMIC_DEBUG) || defined(DEBUG)
#define dev_dbg_ratelimited(dev, fmt, ...) \
- dev_level_ratelimited(dev_dbg, dev, fmt, ##__VA_ARGS__)
-
-/*
- * Stupid hackaround for existing uses of non-printk uses dev_info
- *
- * Note that the definition of dev_info below is actually _dev_info
- * and a macro is used to avoid redefining dev_info
- */
-
-#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
-
-#if defined(CONFIG_DYNAMIC_DEBUG)
-#define dev_dbg(dev, format, ...) \
-do {\
- dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
+do { \
+ static DEFINE_RATELIMIT_STATE(_rs, \
+ DEFAULT_RATELIMIT_INTERVAL, \
+ DEFAULT_RATELIMIT_BURST); \
+ DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
+ if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT) &&\
+ __ratelimit(&_rs)) \
+ __dynamic_pr_debug(, pr_fmt(fmt),\
+ ##__VA_ARGS__); \
} while (0)
-#elif defined(DEBUG)
-#define dev_dbg(dev, format, arg...) \
- dev_printk(KERN_DEBUG, dev, format, ##arg)
#else
-#define dev_dbg(dev, format, arg...) \
-({ \
- if (0) \
- dev_printk(KERN_DEBUG, dev, format, ##arg); \
- 0; \
-})
+#define dev_dbg_ratelimited(dev, fmt, ...) \
+ no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
#endif
#ifdef VERBOSE_DEBUG
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" 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 v7 2/3] KVM: x86: trace mmio begin and complete
On 09/03/2012 07:07 PM, Avi Kivity wrote: > On 08/27/2012 12:51 PM, Dong Hao wrote: >> From: Xiao Guangrong >> >> 'perf kvm stat record/report' will use kvm_exit and kvm_mmio(read...) to >> calculate mmio read emulated time for the old kernel, in order to trace >> mmio read event more exactly, we add kvm_mmio_begin to trace the time when >> mmio read begins, also, add kvm_io_done to trace the time when mmio/pio is >> completed >> > > Why is this so critical? > > If a lot of time is spent in in-kernel mmio, then 'perf top' will report > it. Otherwise the time between kvm_exit and kvm_entry describes the > time spent in the host. Not all of it is mmio handling, but it is quite > close. I have done some test, the new events can get more exact result, this is a example in my slides: the event handled time calculated by old events is: 0.66(s) calculated by new events, the result is: 0.05(s). So, i think it is worth introducing these new events. But if you do not care it or think these events are duplicate with current events or unmaintainable, i do not have strong opinion on that. Please let me know, i will drop them in the next version. -- 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: build warnings after merge of the drm tree
Hi Dave,
After merging the drm tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
warning: (PPC_PS3) selects USB_OHCI_LITTLE_ENDIAN which has unmet direct
dependencies (USB_SUPPORT && USB_OHCI_HCD)
warning: (PPC_PS3 && PPC_CELLEB) selects USB_OHCI_BIG_ENDIAN_MMIO which has
unmet direct dependencies (USB_SUPPORT && USB_OHCI_HCD)
warning: (PPC_PS3 && PPC_CELLEB && USB_EHCI_HCD_PMC_MSP && XPS_USB_HCD_XILINX
&& USB_OCTEON_EHCI) selects USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct
dependencies (USB_SUPPORT && USB_EHCI_HCD && (PPC_CELLEB || PPC_PS3 || 440EPX
|| ARCH_IXP4XX || XPS_USB_HCD_XILINX || PPC_MPC512x || CPU_CAVIUM_OCTEON ||
PMC_MSP || SPARC_LEON || MIPS_SEAD3))
The x86_64 allmodconfig produces these:
drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD
drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL
warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB &&
JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK && TABLET_USB_HANWANG
&& TABLET_USB_KBTAB && TABLET_USB_WACOM && TOUCHSCREEN_USB_COMPOSITE &&
INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE && INPUT_POWERMATE && INPUT_YEALINK
&& INPUT_CM109 && RC_ATI_REMOTE && IR_IMON && IR_MCEUSB && IR_REDRAT3 &&
IR_STREAMZAP && IR_IGUANA && IR_TTUSBIR && DRM_USB) selects USB which has unmet
direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD)
Maybe introduced by commit df0b34430072 ("drm/usb: select USB_SUPPORT in
Kconfig"), maybe interacting with a commit 8f057d7bca54 ("gpu/mfd/usb:
Fix USB randconfig problems") from Linus' tree (that added "depends on
USB_ARCH_HAS_HCD" to "config DRM_USB" and "config DRM_UDL").
I have left this mess for now, but it needs addressing.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp1SPD8SZDQ3.pgp
Description: PGP signature
Re: [PATCH v7 1/3] KVM: x86: export svm/vmx exit code and vector code to userspace
On 09/03/2012 07:13 PM, Avi Kivity wrote: > On 08/27/2012 12:51 PM, Dong Hao wrote: >> From: Xiao Guangrong >> >> Exporting KVM exit information to userspace to be consumed by perf. >> >> [ Dong Hao : rebase it on acme's git tree ] >> Signed-off-by: Xiao Guangrong >> Signed-off-by: Dong Hao >> --- >> arch/x86/include/asm/kvm_host.h | 36 --- > > Please put ABIs in kvm.h. But see below. > >> arch/x86/include/asm/svm.h | 205 >> +-- >> arch/x86/include/asm/vmx.h | 126 >> arch/x86/kvm/trace.h| 89 - >> 4 files changed, 234 insertions(+), 222 deletions(-) >> >> >> +#define DE_VECTOR 0 >> +#define DB_VECTOR 1 >> +#define BP_VECTOR 3 >> +#define OF_VECTOR 4 >> +#define BR_VECTOR 5 >> +#define UD_VECTOR 6 >> +#define NM_VECTOR 7 >> +#define DF_VECTOR 8 >> +#define TS_VECTOR 10 >> +#define NP_VECTOR 11 >> +#define SS_VECTOR 12 >> +#define GP_VECTOR 13 >> +#define PF_VECTOR 14 >> +#define MF_VECTOR 16 >> +#define MC_VECTOR 18 > > This is not a kvm ABI, but an x86 architecture constants. It should be > put into an existing x86 header. Okay, i will move them into asm/kvm.h > >> + >> #endif /* _ASM_X86_KVM_HOST_H */ >> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h >> index f2b83bc..cdf5674 100644 >> --- a/arch/x86/include/asm/svm.h >> +++ b/arch/x86/include/asm/svm.h >> @@ -1,6 +1,135 @@ >> #ifndef __SVM_H >> #define __SVM_H >> >> + >> +#ifdef __KERNEL__ >> + > > The entire file can be exported; nothing in there is implementation > specific. Unfortunately, i have tied this but failed: ../../arch/x86/include/asm/svm.h:262:1: error: packed attribute is unnecessary for ‘vmcb_seg’ [-Werror=packed] ../../arch/x86/include/asm/svm.h:307:1: error: packed attribute is unnecessary for ‘vmcb_save_area’ [-Werror=packed] ../../arch/x86/include/asm/svm.h:312:1: error: packed attribute is unnecessary for ‘vmcb’ [-Werror=packed] .. > >> diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h >> index 74fcb96..61e04e9 100644 >> --- a/arch/x86/include/asm/vmx.h >> +++ b/arch/x86/include/asm/vmx.h >> + >> +#ifdef __KERNEL__ >> + > > Ditto. Or: ../../arch/x86/include/asm/vmx.h:376:0: error: "REG_R8" redefined [-Werror] /usr/include/sys/ucontext.h:46:0: note: this is the location of the previous definition ../../arch/x86/include/asm/vmx.h:377:0: error: "REG_R9" redefined [-Werror] /usr/include/sys/ucontext.h:48:0: note: this is the location of the previous definition .. -- 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 v8 PATCH 13/20] memory-hotplug: check page type in get_page_bootmem
Hi, isimatu-san
At 09/01/2012 05:30 AM, Andrew Morton Wrote:
> On Tue, 28 Aug 2012 18:00:20 +0800
> we...@cn.fujitsu.com wrote:
>
>> From: Yasuaki Ishimatsu
>>
>> There is a possibility that get_page_bootmem() is called to the same page
>> many
>> times. So when get_page_bootmem is called to the same page, the function only
>> increments page->_count.
>
> I really don't understand this explanation, even after having looked at
> the code. Can you please have another attempt at the changelog?
What is the problem that you want to fix? The function get_page_bootmem()
may be called to the same page more than once, but I don't find any problem
about current implementation.
Thanks
Wen Congyang
>
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -95,10 +95,17 @@ static void release_memory_resource(struct resource *res)
>> static void get_page_bootmem(unsigned long info, struct page *page,
>> unsigned long type)
>> {
>> -page->lru.next = (struct list_head *) type;
>> -SetPagePrivate(page);
>> -set_page_private(page, info);
>> -atomic_inc(>_count);
>> +unsigned long page_type;
>> +
>> +page_type = (unsigned long) page->lru.next;
>> +if (page_type < MEMORY_HOTPLUG_MIN_BOOTMEM_TYPE ||
>> +page_type > MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE){
>> +page->lru.next = (struct list_head *) type;
>> +SetPagePrivate(page);
>> +set_page_private(page, info);
>> +atomic_inc(>_count);
>> +} else
>> +atomic_inc(>_count);
>> }
>
> And a code comment which explains what is going on would be good. As
> is always the case ;)
>
>
--
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 v5 1/4] mfd: add syscon driver based on regmap
From: Dong Aisheng
Add regmap based syscon driver.
This is usually used for access misc bits in registers which does not belong
to a specific module, for example, IMX IOMUXC GPR and ANATOP.
With this driver, client can use generic regmap API to access registers
which are registered into syscon.
Reviewed-by: Mark Brown
Acked-by: Stephen Warren
Signed-off-by: Dong Aisheng
---
ChangeLog:
v4->v5:
* depends on OF
* do not call of_node_put in syscon_node_to_regmap
v3->v4:
* add more description about syscon(provided by Stephen Warren) in binding doc.
* fix a minor code indent error and remove set cache type code since the cache
is disabled by default.
v2->v3:
* export regmap lookup APIs including syscon_node_to_regmap
* fix a few typo
v1->v2:
* provide a way of retrieving the regmap, suggested by Mark Brown.
* delete imx-syscon io accessors and using generic regmap API for client
drivers.
* change to a more generic name for other SoCs to use.
---
Documentation/devicetree/bindings/mfd/syscon.txt | 20 +++
drivers/mfd/Kconfig |8 +
drivers/mfd/Makefile |1 +
drivers/mfd/syscon.c | 176 ++
include/linux/mfd/syscon.h | 23 +++
5 files changed, 228 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt
b/Documentation/devicetree/bindings/mfd/syscon.txt
new file mode 100644
index 000..fe8150b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/syscon.txt
@@ -0,0 +1,20 @@
+* System Controller Registers R/W driver
+
+System controller node represents a register region containing a set
+of miscellaneous registers. The registers are not cohesive enough to
+represent as any specific type of device. The typical use-case is for
+some other node's driver, or platform-specific code, to acquire a
+reference to the syscon node (e.g. by phandle, node path, or search
+using a specific compatible value), interrogate the node (or associated
+OS driver) to determine the location of the registers, and access the
+registers directly.
+
+Required properties:
+- compatible: Should contain "syscon".
+- reg: the register region can be accessed from syscon
+
+Examples:
+gpr: iomuxc-gpr@020e {
+ compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
+ reg = <0x020e 0x38>;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b1a1462..82247b7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -993,6 +993,14 @@ config MFD_ANATOP
MFD controller. This controller embeds regulator and
thermal devices for Freescale i.MX platforms.
+config MFD_SYSCON
+ bool "System Controller Register R/W Based on Regmap"
+ depends on OF
+ select REGMAP_MMIO
+ help
+ Select this option to enable accessing system control registers
+ via regmap.
+
config MFD_PALMAS
bool "Support for the TI Palmas series chips"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..8384bc9 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -131,4 +131,5 @@ obj-$(CONFIG_MFD_PALMAS)+= palmas.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
+obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
new file mode 100644
index 000..661a7dc
--- /dev/null
+++ b/drivers/mfd/syscon.c
@@ -0,0 +1,176 @@
+/*
+ * System Control Driver
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012 Linaro Ltd.
+ *
+ * Author: Dong Aisheng
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct platform_driver syscon_driver;
+
+struct syscon {
+ struct device *dev;
+ void __iomem *base;
+ struct regmap *regmap;
+};
+
+static int syscon_match(struct device *dev, void *data)
+{
+ struct syscon *syscon = dev_get_drvdata(dev);
+ struct device_node *dn = data;
+
+ return (syscon->dev->of_node == dn) ? 1 : 0;
+}
+
+struct regmap *syscon_node_to_regmap(struct device_node *np)
+{
+ struct syscon *syscon;
+ struct device *dev;
+
+ dev = driver_find_device(_driver.driver, NULL, np,
+syscon_match);
+ if (!dev)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ syscon = dev_get_drvdata(dev);
+
+ return syscon->regmap;
+}
+EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
+
+struct regmap
[PATCH v5 0/4] add syscon driver based on regmap for general registers access
This patch series mainly adds an syscon driver which is used to access general system controller registers like FSL IOMUXC GPR and ANATOP, after that, we convert all the exist private access general registers code to use standard API from regmap to access registers. Finally we remove the old mfd anatop driver which is only for anatop register access. The patch series is based on linus's tree 3.6-rc3 since commit 9160338. ChangeLog v4->v5: * change syscon driver depends on OF * do not call of_node_put in syscon_node_to_regmap * renamed: include/linux/fsl/imx6q-iomuxc-gpr.h -> include/linux/mfd/syscon/imx6q-iomuxc-gpr.h ChangeLog v3->v4: Only '[PATCH v4 1/7] mfd: add syscon driver based on regmap' is changed. Dong Aisheng (4): mfd: add syscon driver based on regmap ARM: imx6q: add iomuxc gpr support into syscon regulator: anatop-regulator: convert to use syscon to access anatop register mfd: anatop-mfd: remove anatop driver Documentation/devicetree/bindings/mfd/syscon.txt | 20 ++ arch/arm/boot/dts/imx6q.dtsi |9 +- arch/arm/mach-imx/Kconfig|2 +- arch/arm/mach-imx/mach-imx6q.c | 47 ++-- drivers/mfd/Kconfig | 12 +- drivers/mfd/Makefile |2 +- drivers/mfd/anatop-mfd.c | 124 - drivers/mfd/syscon.c | 176 drivers/regulator/Kconfig|2 +- drivers/regulator/anatop-regulator.c | 30 ++- include/linux/mfd/anatop.h | 40 --- include/linux/mfd/syscon.h | 23 ++ include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 319 ++ 13 files changed, 592 insertions(+), 214 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/syscon.txt delete mode 100644 drivers/mfd/anatop-mfd.c create mode 100644 drivers/mfd/syscon.c delete mode 100644 include/linux/mfd/anatop.h create mode 100644 include/linux/mfd/syscon.h create mode 100644 include/linux/mfd/syscon/imx6q-iomuxc-gpr.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 v5 3/4] regulator: anatop-regulator: convert to use syscon to access anatop register
From: Dong Aisheng
Using syscon to access anatop register.
Acked-by: Mark Brown
Acked-by: Stephen Warren
Signed-off-by: Dong Aisheng
---
ChangeLog v4->v5:
* merge patch 3,4,5,6 to avoid break bisect.
ChangeLog v2->v3:
* update to use syscon_node_to_regmap and use of_get_parent to get anatop node.
ChangeLog v1-v2:
* update to use generic regmap api
---
arch/arm/boot/dts/imx6q.dtsi |4 +-
arch/arm/mach-imx/Kconfig|2 +-
arch/arm/mach-imx/mach-imx6q.c | 47 +-
drivers/regulator/Kconfig|2 +-
drivers/regulator/anatop-regulator.c | 30 ++---
5 files changed, 42 insertions(+), 43 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index bea21bc..52ed4d1 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -378,8 +378,8 @@
interrupts = <0 87 0x04 0 88 0x04>;
};
- anatop@020c8000 {
- compatible = "fsl,imx6q-anatop";
+ anatop: anatop@020c8000 {
+ compatible = "fsl,imx6q-anatop", "syscon",
"simple-bus";
reg = <0x020c8000 0x1000>;
interrupts = <0 49 0x04 0 54 0x04 0 127 0x04>;
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index afd542a..7bba253 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -839,7 +839,7 @@ config SOC_IMX6Q
select HAVE_IMX_MMDC
select HAVE_IMX_SRC
select HAVE_SMP
- select MFD_ANATOP
+ select MFD_SYSCON
select PINCTRL
select PINCTRL_IMX6Q
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 045b3f6..eaf56b4 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -24,8 +24,9 @@
#include
#include
#include
+#include
#include
-#include
+#include
#include
#include
#include
@@ -120,20 +121,7 @@ static void __init imx6q_sabrelite_init(void)
static void __init imx6q_usb_init(void)
{
- struct device_node *np;
- struct platform_device *pdev = NULL;
- struct anatop *adata = NULL;
-
- np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
- if (np)
- pdev = of_find_device_by_node(np);
- if (pdev)
- adata = platform_get_drvdata(pdev);
- if (!adata) {
- if (np)
- of_node_put(np);
- return;
- }
+ struct regmap *anatop;
#define HW_ANADIG_USB1_CHRG_DETECT 0x01b0
#define HW_ANADIG_USB2_CHRG_DETECT 0x0210
@@ -141,20 +129,21 @@ static void __init imx6q_usb_init(void)
#define BM_ANADIG_USB_CHRG_DETECT_EN_B 0x0010
#define BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B 0x0008
- /*
-* The external charger detector needs to be disabled,
-* or the signal at DP will be poor
-*/
- anatop_write_reg(adata, HW_ANADIG_USB1_CHRG_DETECT,
- BM_ANADIG_USB_CHRG_DETECT_EN_B
- | BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B,
- ~0);
- anatop_write_reg(adata, HW_ANADIG_USB2_CHRG_DETECT,
- BM_ANADIG_USB_CHRG_DETECT_EN_B |
- BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B,
- ~0);
-
- of_node_put(np);
+ anatop = syscon_regmap_lookup_by_compatible("fsl,imx6q-anatop");
+ if (!IS_ERR(anatop)) {
+ /*
+* The external charger detector needs to be disabled,
+* or the signal at DP will be poor
+*/
+ regmap_write(anatop, HW_ANADIG_USB1_CHRG_DETECT,
+ BM_ANADIG_USB_CHRG_DETECT_EN_B
+ | BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B);
+ regmap_write(anatop, HW_ANADIG_USB2_CHRG_DETECT,
+ BM_ANADIG_USB_CHRG_DETECT_EN_B |
+ BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B);
+ } else {
+ pr_warn("failed to find fsl,imx6q-anatop regmap\n");
+ }
}
static void __init imx6q_init_machine(void)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 4e932cc..2ae1d97 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -112,7 +112,7 @@ config REGULATOR_DA9052
config REGULATOR_ANATOP
tristate "Freescale i.MX on-chip ANATOP LDO regulators"
- depends on MFD_ANATOP
+ depends on MFD_SYSCON
help
Say y here to support Freescale i.MX on-chip ANATOP LDOs
regulators. It is recommended that this option be
diff --git a/drivers/regulator/anatop-regulator.c
b/drivers/regulator/anatop-regulator.c
index ce0fe72..346e5f6 100644
---
[PATCH v5 4/4] mfd: anatop-mfd: remove anatop driver
From: Dong Aisheng
The anatop registers are accessed via syscon now, no one will use
mfd anatop driver anymore, remove it.
Acked-by: Stephen Warren
Signed-off-by: Dong Aisheng
---
drivers/mfd/Kconfig|8 ---
drivers/mfd/Makefile |1 -
drivers/mfd/anatop-mfd.c | 124
include/linux/mfd/anatop.h | 40 --
4 files changed, 0 insertions(+), 173 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 82247b7..0b5c0cc 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -985,14 +985,6 @@ config MFD_STA2X11
depends on STA2X11
select MFD_CORE
-config MFD_ANATOP
- bool "Support for Freescale i.MX on-chip ANATOP controller"
- depends on SOC_IMX6Q
- help
- Select this option to enable Freescale i.MX on-chip ANATOP
- MFD controller. This controller embeds regulator and
- thermal devices for Freescale i.MX platforms.
-
config MFD_SYSCON
bool "System Controller Register R/W Based on Regmap"
depends on OF
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8384bc9..0f10a95 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -130,6 +130,5 @@ obj-$(CONFIG_MFD_INTEL_MSIC)+= intel_msic.o
obj-$(CONFIG_MFD_PALMAS) += palmas.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
-obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
diff --git a/drivers/mfd/anatop-mfd.c b/drivers/mfd/anatop-mfd.c
deleted file mode 100644
index 5576e07..000
--- a/drivers/mfd/anatop-mfd.c
+++ /dev/null
@@ -1,124 +0,0 @@
-/*
- * Anatop MFD driver
- *
- * Copyright (C) 2012 Ying-Chun Liu (PaulLiu)
- * Copyright (C) 2012 Linaro
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-u32 anatop_read_reg(struct anatop *adata, u32 addr)
-{
- return readl(adata->ioreg + addr);
-}
-EXPORT_SYMBOL_GPL(anatop_read_reg);
-
-void anatop_write_reg(struct anatop *adata, u32 addr, u32 data, u32 mask)
-{
- u32 val;
-
- data &= mask;
-
- spin_lock(>reglock);
- val = readl(adata->ioreg + addr);
- val &= ~mask;
- val |= data;
- writel(val, adata->ioreg + addr);
- spin_unlock(>reglock);
-}
-EXPORT_SYMBOL_GPL(anatop_write_reg);
-
-static const struct of_device_id of_anatop_match[] = {
- { .compatible = "fsl,imx6q-anatop", },
- { },
-};
-
-static int __devinit of_anatop_probe(struct platform_device *pdev)
-{
- struct device *dev = >dev;
- struct device_node *np = dev->of_node;
- void *ioreg;
- struct anatop *drvdata;
-
- ioreg = of_iomap(np, 0);
- if (!ioreg)
- return -EADDRNOTAVAIL;
- drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
- if (!drvdata)
- return -ENOMEM;
- drvdata->ioreg = ioreg;
- spin_lock_init(>reglock);
- platform_set_drvdata(pdev, drvdata);
- of_platform_populate(np, NULL, NULL, dev);
-
- return 0;
-}
-
-static int __devexit of_anatop_remove(struct platform_device *pdev)
-{
- struct anatop *drvdata;
- drvdata = platform_get_drvdata(pdev);
- iounmap(drvdata->ioreg);
-
- return 0;
-}
-
-static struct platform_driver anatop_of_driver = {
- .driver = {
-
[PATCH v5 2/4] ARM: imx6q: add iomuxc gpr support into syscon
From: Dong Aisheng
Include headfile for easy using.
Acked-by: Stephen Warren
Signed-off-by: Dong Aisheng
---
ChangeLog v4-v5:
* renamed: include/linux/fsl/imx6q-iomuxc-gpr.h ->
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
* a minor typo fix
---
arch/arm/boot/dts/imx6q.dtsi|5 +
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 319 +++
2 files changed, 324 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index fd57079..bea21bc 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -507,6 +507,11 @@
interrupts = <0 89 0x04 0 90 0x04>;
};
+ gpr: iomuxc-gpr@020e {
+ compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
+ reg = <0x020e 0x38>;
+ };
+
iomuxc@020e {
compatible = "fsl,imx6q-iomuxc";
reg = <0x020e 0x4000>;
diff --git a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
new file mode 100644
index 000..dab34a1
--- /dev/null
+++ b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
@@ -0,0 +1,319 @@
+/*
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __LINUX_IMX6Q_IOMUXC_GPR_H
+#define __LINUX_IMX6Q_IOMUXC_GPR_H
+
+#include
+
+#define IOMUXC_GPR00x00
+#define IOMUXC_GPR10x04
+#define IOMUXC_GPR20x08
+#define IOMUXC_GPR30x0c
+#define IOMUXC_GPR40x10
+#define IOMUXC_GPR50x14
+#define IOMUXC_GPR60x18
+#define IOMUXC_GPR70x1c
+#define IOMUXC_GPR80x20
+#define IOMUXC_GPR90x24
+#define IOMUXC_GPR10 0x28
+#define IOMUXC_GPR11 0x2c
+#define IOMUXC_GPR12 0x30
+#define IOMUXC_GPR13 0x34
+
+#define IMX6Q_GPR0_CLOCK_8_MUX_SEL_MASK(0x3 << 30)
+#define IMX6Q_GPR0_CLOCK_8_MUX_SEL_AUDMUX_RXCLK_P7_MUXED (0x0 << 30)
+#define IMX6Q_GPR0_CLOCK_8_MUX_SEL_AUDMUX_RXCLK_P7 (0x1 << 30)
+#define IMX6Q_GPR0_CLOCK_8_MUX_SEL_SSI3_SSI_SRCK (0x2 << 30)
+#define IMX6Q_GPR0_CLOCK_8_MUX_SEL_SSI3_RX_BIT_CLK (0x3 << 30)
+#define IMX6Q_GPR0_CLOCK_0_MUX_SEL_MASK(0x3 << 28)
+#define IMX6Q_GPR0_CLOCK_0_MUX_SEL_ESAI1_IPP_IND_SCKR_MUXED(0x0 << 28)
+#define IMX6Q_GPR0_CLOCK_0_MUX_SEL_ESAI1_IPP_IND_SCKR (0x1 << 28)
+#define IMX6Q_GPR0_CLOCK_0_MUX_SEL_ESAI1_IPP_DO_SCKR (0x2 << 28)
+#define IMX6Q_GPR0_CLOCK_B_MUX_SEL_MASK(0x3 << 26)
+#define IMX6Q_GPR0_CLOCK_B_MUX_SEL_AUDMUX_TXCLK_P7_MUXED (0x0 << 26)
+#define IMX6Q_GPR0_CLOCK_B_MUX_SEL_AUDMUX_TXCLK_P7 (0x1 << 26)
+#define IMX6Q_GPR0_CLOCK_B_MUX_SEL_SSI3_SSI_STCK (0x2 << 26)
+#define IMX6Q_GPR0_CLOCK_B_MUX_SEL_SSI3_TX_BIT_CLK (0x3 << 26)
+#define IMX6Q_GPR0_CLOCK_3_MUX_SEL_MASK(0x3 << 24)
+#define IMX6Q_GPR0_CLOCK_3_MUX_SEL_AUDMUX_RXCLK_P7_MUXED (0x3 << 24)
+#define IMX6Q_GPR0_CLOCK_3_MUX_SEL_AUDMUX_RXCLK_P7 (0x3 << 24)
+#define IMX6Q_GPR0_CLOCK_3_MUX_SEL_SSI3_SSI_SRCK (0x3 << 24)
+#define IMX6Q_GPR0_CLOCK_3_MUX_SEL_SSI3_RX_BIT_CLK (0x3 << 24)
+#define IMX6Q_GPR0_CLOCK_A_MUX_SEL_MASK(0x3 << 22)
+#define IMX6Q_GPR0_CLOCK_A_MUX_SEL_AUDMUX_TXCLK_P2_MUXED (0x0 << 22)
+#define IMX6Q_GPR0_CLOCK_A_MUX_SEL_AUDMUX_TXCLK_P2 (0x1 << 22)
+#define IMX6Q_GPR0_CLOCK_A_MUX_SEL_SSI2_SSI_STCK (0x2 << 22)
+#define IMX6Q_GPR0_CLOCK_A_MUX_SEL_SSI2_TX_BIT_CLK (0x3 << 22)
+#define IMX6Q_GPR0_CLOCK_2_MUX_SEL_MASK(0x3 << 20)
+#define IMX6Q_GPR0_CLOCK_2_MUX_SEL_AUDMUX_RXCLK_P2_MUXED (0x0 << 20)
+#define IMX6Q_GPR0_CLOCK_2_MUX_SEL_AUDMUX_RXCLK_P2 (0x1 << 20)
+#define IMX6Q_GPR0_CLOCK_2_MUX_SEL_SSI2_SSI_SRCK (0x2 << 20)
+#define IMX6Q_GPR0_CLOCK_2_MUX_SEL_SSI2_RX_BIT_CLK (0x3 << 20)
+#define IMX6Q_GPR0_CLOCK_9_MUX_SEL_MASK(0x3 << 18)
+#define IMX6Q_GPR0_CLOCK_9_MUX_SEL_AUDMUX_TXCLK_P1_MUXED (0x0 << 18)
+#define IMX6Q_GPR0_CLOCK_9_MUX_SEL_AUDMUX_TXCLK_P1 (0x1 << 18)
+#define IMX6Q_GPR0_CLOCK_9_MUX_SEL_SSI1_SSI_STCK (0x2 << 18)
+#define IMX6Q_GPR0_CLOCK_9_MUX_SEL_SSI1_SSI_TX_BIT_CLK (0x3 << 18)
+#define IMX6Q_GPR0_CLOCK_1_MUX_SEL_MASK(0x3 << 16)
+#define IMX6Q_GPR0_CLOCK_1_MUX_SEL_AUDMUX_RXCLK_P1_MUXED (0x0 << 16)
+#define IMX6Q_GPR0_CLOCK_1_MUX_SEL_AUDMUX_RXCLK_P1 (0x1 << 16)
+#define IMX6Q_GPR0_CLOCK_1_MUX_SEL_SSI1_SSI_SRCK (0x2 << 16)
+#define IMX6Q_GPR0_CLOCK_1_MUX_SEL_SSI1_SSI_RX_BIT_CLK (0x3 << 16)
+#define IMX6Q_GPR0_TX_CLK2_MUX_SEL_MASK(0x3 << 14)
+#define IMX6Q_GPR0_TX_CLK2_MUX_SEL_ASRCK_CLK1 (0x0 << 14)
+#define IMX6Q_GPR0_TX_CLK2_MUX_SEL_ASRCK_CLK2
Re: [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Mon, Sep 03, 2012 at 04:41:37PM -0400, Mikulas Patocka wrote: > ... or another possibility - start a timer when something is put to > current->bio_list and use that timer to pop entries off current->bio_list > and submit them to a workqueue. The timer can be cpu-local so only > interrupt masking is required to synchronize against the timer. > > This would normally run just like the current kernel and in case of > deadlock, the timer would kick in and resolve the deadlock. Ugh. That's a _terrible_ idea. Remember the old plugging code? You ever have to debug performance issues caused by it? > > > I could be convinced, but right now I prefer my solution. > > It fixes bio allocation problem, but not other similar mempool problems in > dm and md. I looked a bit more, and actually I think the rest of the problem is pretty limited in scope - most of those mempool allocations are per request, not per split. I'm willing to put some time into converting dm/md over to bioset's front_pad. I'm having to learn the code for the immutable biovec work, anyways. -- 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: western digital caviar black. EXT4-fs error
On Sat, Sep 01, 2012 at 11:48:17PM +0400, Azat Khuzhin wrote: > Recently I update my HDD on desktop machine, and bought WD Caviar Black. > But after I format & copy information to it (using dd), and fix > partitions size: I have next errors in kern.log: > > Aug 28 01:49:03 home-spb kernel: [183245.030897] EXT4-fs error (device > sdc2): ext4_mb_generate_buddy:739: group 3675, 32254 clusters in > bitmap, 32258 in gd Sorry for the delay; you sent this to linux-kernel (and not the linux-ext4 list). It also took me a while to dig up the relevant fix from my archives; normally, once a bug has been fixed (as this one was, on June 7, 2012) I don't worry about it any more. The upstream fix is commit b0dd6b70f0fda17ae9762fbb72d98e40a4f66556. Note that you are using the 3.3.0 kernel. This is a not long-term supported kernel, so fixes from upstream are no longer being backported to it. The official Debian kernel (which tracks the 3.2.x stable kernel series) has the backported bug fix. So does the 3.4 long-term stable kernel series, as does the 3.5 kernel or any later kernel. If you don't know how to backport a kernel patch, or even if you do, I would strongly suggest that you either go back to the Debian standard kernel for Wheezy, or track the 3.2.x or 3.4.x long-term stable kernel. (The fix is in v3.2.20 or later, and v3.4.3 or later --- where those trees are up to v3.2.28, and v3.4.10, respectively.) Otherwise, you may very well run into some other kernel bug which has already been fixed upstream, and you'll just waste your time as well as various other kernel developers. Regards, - Ted -- 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 v4l-dvb tree with the arm tree
Hi Mauro,
Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/mach-imx/mach-imx27_visstrim_m10.c between commit 895576427dca
("ARM: iMX: visstrim_m10: use arm_memblock_steal") from the arm tree and
commit b6c14dc29757 ("[media] Visstrim M10: Add support for Coda") from
the v4l-dvb tree.
I just used the version from the v4l-dvb tree and can carry that fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpZkxb67fUQx.pgp
Description: PGP signature
Subject: [PATCH 1/1] drivers/md/raid1.c: fix NULL pointer bug in fix_read_error function
>From 0ba5879082544dc3aa13807087563b1258124b1e Mon Sep 17 00:00:00 2001
From: hank
Date: Tue, 4 Sep 2012 10:23:45 +0800
Subject: [PATCH 1/1] drivers/md/raid1.c: fix NULL pointer bug in
fix_read_error function
in fix_read_error function, the conf->mirrors[read_disk].rdev may
become NULL, as in this function, rdev->nr_pending may be zero, anyone
can delete it. So should check if it is NULL before use.
Signed-off-by: hank
---
drivers/md/raid1.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 611b5f7..fd8de28 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -2005,7 +2005,7 @@ static void fix_read_error(struct r1conf *conf, int
read_disk,
if (!success) {
/* Cannot read from anywhere - mark it bad */
struct md_rdev *rdev = conf->mirrors[read_disk].rdev;
- if (!rdev_set_badblocks(rdev, sect, s, 0))
+ if (!rdev || !rdev_set_badblocks(rdev, sect, s, 0))
md_error(mddev, rdev);
break;
}
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] [media] rc: filter out not allowed protocols when decoding
> > mutex_lock(_raw_handler_lock);
> > - list_for_each_entry(handler, _raw_handler_list, list)
> > - handler->decode(raw->dev, ev);
> > + list_for_each_entry(handler, _raw_handler_list, list) {
> > + /* use all protocol by default */
> > + if (raw->dev->allowed_protos == RC_TYPE_UNKNOWN ||
> > + raw->dev->allowed_protos & handler->protocols)
> > + handler->decode(raw->dev, ev);
> > + }
>
> Each IR protocol decoder already checks whether it is enabled or not;
> should it not be so that only allowed protocols can be enabled rather
> than checking both enabled_protocols and allowed_protocols?
>
> Just from reading store_protocols it looks like decoders which aren't
> in allowed_protocols can be enabled, which makes no sense. Also
> ir_raw_event_register all protocols are enabled rather than the
> allowed ones.
>
>
> Lastely I don't know why raw ir drivers should dictate which protocols
> can be enabled. Would it not be better to remove it entirely?
I agree with you. I just thought that the only thing a decoder should care
is its decoding logic, but not including decoder management. My idaea is:
1) use enabled_protocols to select decoders in ir_raw.c, but not
placed in decoders to do the judgement.
2) remove allowed_protocols or just use it to set the default
decoder (also should rename allowed_protocols to default_protocol).
I also have a question:
Is there a requirement that one more decoders are enabled for a
IR device at the same time?
And if that will lead to a issue that each decoder may decode a
same pulse sequence to different evnets since their protocol is
different?
[Du, Changbin]
>
>
> > raw->prev_ev = ev;
> > mutex_unlock(_raw_handler_lock);
> > }
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" 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 1/3] proc: return -ENOMEM when inode allocation failed
On 09/03/2012 10:14 PM, yan wrote:
Signed-off-by: yan
Please provide a changelog to explain why we need this patch.
---
fs/proc/generic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index b3647fe..9e8f631 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -427,7 +427,7 @@ struct dentry *proc_lookup_de(struct proc_dir_entry *de,
struct inode *dir,
if (!memcmp(dentry->d_name.name, de->name, de->namelen)) {
pde_get(de);
spin_unlock(_subdir_lock);
- error = -EINVAL;
+ error = -ENOMEM;
Why the !memcmp() case is related with ENOMEM ??
--
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/2] hw_random: mxc-rnga: Adapt clocks to new i.mx clock framework
On Mon, Sep 03, 2012 at 06:08:45PM -0300, Fabio Estevam wrote: > Herbert, > > On Fri, Aug 3, 2012 at 12:10 PM, Fabio Estevam wrote: > > Hi Herbert, > > > > On Tue, Jul 31, 2012 at 3:40 AM, Sascha Hauer > > wrote: > >> On Fri, Jul 27, 2012 at 01:47:51PM -0300, Fabio Estevam wrote: > >>> Adapt clocks to the new i.mx clock framework and fix the following > >>> warning: > >>> > >>> Cc: Theodore Ts'o > >>> Cc: Herbert Xu > >>> Cc: > >>> Signed-off-by: Fabio Estevam > >> > >> Both: > >> > >> Acked-by: Sascha Hauer > > > > Looks like git did not Cc'ed you in these patches. > > > > Would it be OK to apply these two patches? > > Ping? It would help if you actually send me the patches. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 13/13] x86, 64bit: Map first 1M ram early before memblock_x86_fill()
On Mon, Sep 3, 2012 at 12:18 AM, Yinghai Lu wrote: > On Sun, Sep 2, 2012 at 11:26 PM, Pekka Enberg wrote: >> >> Yup, or move the globals together with the comment to arch/x86/mm/init.c. >> >> That said, max_pfn_high_mapped really ought to be kept together with >> the other "pfn_mapped" globals and the comment should be updated. > > max_pfn_high_mapped is only for 64bit, and it is in init_64.c > > maybe later could have another patch to move max_pfn_mapped, > max_low_pfn_mapped from > kernel/setup.c to mm/init.c > > Please check attached updated patch. oh, I'm wrong. this patch is not needed, until some day we could not need to do low kernel mapping in head_64.S Thanks Yinghai -- 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 5/5] virtio-scsi: introduce multiqueue support
On Tue, 2012-08-28 at 13:54 +0200, Paolo Bonzini wrote:
> This patch adds queue steering to virtio-scsi. When a target is sent
> multiple requests, we always drive them to the same queue so that FIFO
> processing order is kept. However, if a target was idle, we can choose
> a queue arbitrarily. In this case the queue is chosen according to the
> current VCPU, so the driver expects the number of request queues to be
> equal to the number of VCPUs. This makes it easy and fast to select
> the queue, and also lets the driver optimize the IRQ affinity for the
> virtqueues (each virtqueue's affinity is set to the CPU that "owns"
> the queue).
>
> Signed-off-by: Paolo Bonzini
> ---
Hey Paolo & Co,
I've not had a chance to try this with tcm_vhost just yet, but noticed
one thing wrt to assumptions about virtio_scsi_target_state->reqs access
below..
> drivers/scsi/virtio_scsi.c | 162
> +++-
> 1 files changed, 130 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> index 6414ea0..0c4b096 100644
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
> @@ -26,6 +26,7 @@
>
> #define VIRTIO_SCSI_MEMPOOL_SZ 64
> #define VIRTIO_SCSI_EVENT_LEN 8
> +#define VIRTIO_SCSI_VQ_BASE 2
>
> /* Command queue element */
> struct virtio_scsi_cmd {
> @@ -59,9 +60,13 @@ struct virtio_scsi_vq {
>
> /* Per-target queue state */
> struct virtio_scsi_target_state {
> - /* Protects sg. Lock hierarchy is tgt_lock -> vq_lock. */
> + /* Protects sg, req_vq. Lock hierarchy is tgt_lock -> vq_lock. */
> spinlock_t tgt_lock;
>
> + struct virtio_scsi_vq *req_vq;
> +
> + atomic_t reqs;
> +
> /* For sglist construction when adding commands to the virtqueue. */
> struct scatterlist sg[];
> };
> @@ -70,14 +75,15 @@ struct virtio_scsi_target_state {
> struct virtio_scsi {
> struct virtio_device *vdev;
>
> - struct virtio_scsi_vq ctrl_vq;
> - struct virtio_scsi_vq event_vq;
> - struct virtio_scsi_vq req_vq;
> -
> /* Get some buffers ready for event vq */
> struct virtio_scsi_event_node event_list[VIRTIO_SCSI_EVENT_LEN];
>
> + u32 num_queues;
> struct virtio_scsi_target_state **tgt;
> +
> + struct virtio_scsi_vq ctrl_vq;
> + struct virtio_scsi_vq event_vq;
> + struct virtio_scsi_vq req_vqs[];
> };
>
> static struct kmem_cache *virtscsi_cmd_cache;
> @@ -112,6 +118,9 @@ static void virtscsi_complete_cmd(struct virtio_scsi
> *vscsi, void *buf)
> struct virtio_scsi_cmd *cmd = buf;
> struct scsi_cmnd *sc = cmd->sc;
> struct virtio_scsi_cmd_resp *resp = >resp.cmd;
> + struct virtio_scsi_target_state *tgt = vscsi->tgt[sc->device->id];
> +
> + atomic_dec(>reqs);
>
As tgt->tgt_lock is taken in virtscsi_queuecommand_multi() before the
atomic_inc_return(tgt->reqs) check, it seems like using atomic_dec() w/o
smp_mb__after_atomic_dec or tgt_lock access here is not using atomic.h
accessors properly, no..?
> dev_dbg(>device->sdev_gendev,
> "cmd %p response %u status %#02x sense_len %u\n",
> @@ -185,11 +194,13 @@ static void virtscsi_req_done(struct virtqueue *vq)
> {
> struct Scsi_Host *sh = virtio_scsi_host(vq->vdev);
> struct virtio_scsi *vscsi = shost_priv(sh);
> + int index = virtqueue_get_queue_index(vq) - VIRTIO_SCSI_VQ_BASE;
> + struct virtio_scsi_vq *req_vq = >req_vqs[index];
> unsigned long flags;
>
> - spin_lock_irqsave(>req_vq.vq_lock, flags);
> + spin_lock_irqsave(_vq->vq_lock, flags);
> virtscsi_vq_done(vscsi, vq, virtscsi_complete_cmd);
> - spin_unlock_irqrestore(>req_vq.vq_lock, flags);
> + spin_unlock_irqrestore(_vq->vq_lock, flags);
> };
>
> static void virtscsi_complete_free(struct virtio_scsi *vscsi, void *buf)
> @@ -429,10 +440,10 @@ static int virtscsi_kick_cmd(struct
> virtio_scsi_target_state *tgt,
> return ret;
> }
>
> -static int virtscsi_queuecommand(struct Scsi_Host *sh, struct scsi_cmnd *sc)
> +static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
> + struct virtio_scsi_target_state *tgt,
> + struct scsi_cmnd *sc)
> {
> - struct virtio_scsi *vscsi = shost_priv(sh);
> - struct virtio_scsi_target_state *tgt = vscsi->tgt[sc->device->id];
> struct virtio_scsi_cmd *cmd;
> int ret;
>
> @@ -466,7 +477,7 @@ static int virtscsi_queuecommand(struct Scsi_Host *sh,
> struct scsi_cmnd *sc)
> BUG_ON(sc->cmd_len > VIRTIO_SCSI_CDB_SIZE);
> memcpy(cmd->req.cmd.cdb, sc->cmnd, sc->cmd_len);
>
> - if (virtscsi_kick_cmd(tgt, >req_vq, cmd,
> + if (virtscsi_kick_cmd(tgt, tgt->req_vq, cmd,
> sizeof cmd->req.cmd, sizeof cmd->resp.cmd,
> GFP_ATOMIC) >= 0)
> ret = 0;
> @@ -475,6 +486,38 @@ out:
> return ret;
> }
>
> +static int
Re: [PATCH 5/7] perf ui/browser: Add a browser for perf script
On Mon, 3 Sep 2012 16:14:31 +0800, Feng Tang wrote:
> Create a script browser, so that user can check all the available
> scripts and run them inside the main perf report or annotation
> browsers, for all the perf samples or samples belong to one
> thread/symbol.
>
> The work flow is, users can use function key to list all the available
> scripts in system and chose one, which will be executed with
> popen("perf script -s xxx.xx",) and all the output lines are put into
> one ui browser, pressing 'q' or left arrow key will make it return
> to previous browser.
It could be used for TUI interface of perf script itself too (at least
for --list option) IMHO.
>
> Please be noted, most of the in-tree scripts with name xxxtop are
> dynamically run and not supported by this static browser.
If so, wouldn't it be better adding a filter not to show those
unsupported scripts somehow?
> You can run the event_analyzing_sample.py for example.
>
> Signed-off-by: Feng Tang
> ---
> tools/perf/Makefile |5 +
> tools/perf/ui/browsers/scripts.c | 159
> ++
> tools/perf/ui/browsers/scripts.h |5 +
> 3 files changed, 169 insertions(+), 0 deletions(-)
> create mode 100644 tools/perf/ui/browsers/scripts.c
> create mode 100644 tools/perf/ui/browsers/scripts.h
>
> diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> index 722ddee..1fe23b9 100644
> --- a/tools/perf/Makefile
> +++ b/tools/perf/Makefile
> @@ -569,6 +569,7 @@ else
> LIB_OBJS += $(OUTPUT)ui/browsers/annotate.o
> LIB_OBJS += $(OUTPUT)ui/browsers/hists.o
> LIB_OBJS += $(OUTPUT)ui/browsers/map.o
> + LIB_OBJS += $(OUTPUT)ui/browsers/scripts.o
> LIB_OBJS += $(OUTPUT)ui/progress.o
> LIB_OBJS += $(OUTPUT)ui/util.o
> LIB_OBJS += $(OUTPUT)ui/tui/setup.o
> @@ -576,6 +577,7 @@ else
> LIB_OBJS += $(OUTPUT)ui/tui/helpline.o
> LIB_H += ui/browser.h
> LIB_H += ui/browsers/map.h
> + LIB_H += ui/browsers/scripts.h
> LIB_H += ui/keysyms.h
> LIB_H += ui/libslang.h
> LIB_H += ui/progress.h
> @@ -878,6 +880,9 @@ $(OUTPUT)ui/browsers/hists.o: ui/browsers/hists.c
> $(OUTPUT)PERF-CFLAGS
> $(OUTPUT)ui/browsers/map.o: ui/browsers/map.c $(OUTPUT)PERF-CFLAGS
> $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) -DENABLE_SLFUTURE_CONST $<
>
> +$(OUTPUT)ui/browsers/scripts.o: ui/browsers/scripts.c $(OUTPUT)PERF-CFLAGS
> + $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) -DENABLE_SLFUTURE_CONST $<
> +
> $(OUTPUT)util/rbtree.o: ../../lib/rbtree.c $(OUTPUT)PERF-CFLAGS
> $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS)
> -DETC_PERFCONFIG='"$(ETC_PERFCONFIG_SQ)"' $<
>
> diff --git a/tools/perf/ui/browsers/scripts.c
> b/tools/perf/ui/browsers/scripts.c
> new file mode 100644
> index 000..7183795
> --- /dev/null
> +++ b/tools/perf/ui/browsers/scripts.c
> @@ -0,0 +1,159 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "../../util/sort.h"
> +#include "../../util/util.h"
> +#include "../../util/debug.h"
> +#include "../../util/symbol.h"
> +#include "../browser.h"
> +#include "../helpline.h"
> +#include "../libslang.h"
> +#include "scripts.h"
> +
> +/* 2048 lines should be enough for a script output */
> +#define MAX_LINES2048
> +
> +/* 160 bytes for one output line */
> +#define AVERAGE_LINE_LEN 160
> +
> +struct script_line {
> + struct list_head node;
> + char line[AVERAGE_LINE_LEN];
> +};
> +
> +struct perf_script_browser {
> + struct ui_browser b;
> + struct list_head entries;
> + const char *script_name;
> + int nr_lines;
> +};
> +
> +#define SCRIPT_NAMELEN 40
> +#define SCRIPT_MAX_NO32
> +#define SCRIPT_FULLPATH_LEN 128
I'm not sure these magic numbers are enough.
> +
> +/* Return 0 on success */
> +static int list_scripts(char *script_name)
> +{
> + char *buffer, *scripts[SCRIPT_MAX_NO], *scripts_path[SCRIPT_MAX_NO];
> + int i, num, choice, ret = -1;
> +
> + /* Preset the script name to SCRIPT_NAMELEN */
> + buffer = zalloc(SCRIPT_MAX_NO * (SCRIPT_NAMELEN + SCRIPT_FULLPATH_LEN));
> + if (!buffer)
> + return ret;
> +
> + for (i = 0; i < SCRIPT_MAX_NO; i++) {
> + scripts[i] = buffer + i * (SCRIPT_NAMELEN +
> SCRIPT_FULLPATH_LEN);
> + scripts_path[i] = scripts[i] + SCRIPT_NAMELEN;
> + }
> +
> + num = find_scripts(scripts, scripts_path);
> + if (num) {
It should be:
if (num > 0) {
since the find_scripts() can return -1.
> + choice = ui__popup_menu(num, scripts);
> + if (choice < num && choice >= 0) {
> + strcpy(script_name, scripts_path[choice]);
> + ret = 0;
> + }
> + }
> +
> + free(buffer);
> + return ret;
> +}
> +
> +static void script_browser__write(struct ui_browser *browser,
linux-next: manual merge of the pci tree with Linus' tree
Hi Bjorn,
Today's linux-next merge of the pci tree got a conflict in
drivers/rapidio/devices/tsi721.c between commit 9a9a9a7adafe
("rapidio/tsi721: fix unused variable compiler warning") from Linus' tree
and commit 5cdaaf8a11ba ("rapdio/tsi721: Use PCI Express Capability
accessors") from the pci 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 drivers/rapidio/devices/tsi721.c
index 5d44252,fc22b93..000
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@@ -2219,9 -2212,8 +2219,7 @@@ static int __devinit tsi721_probe(struc
const struct pci_device_id *id)
{
struct tsi721_device *priv;
- int cap;
- int i;
int err;
- u32 regval;
priv = kzalloc(sizeof(struct tsi721_device), GFP_KERNEL);
if (priv == NULL) {
pgp2924el0HuE.pgp
Description: PGP signature
linux-next: manual merge of the pci tree with Linus' tree
Hi Bjorn,
Today's linux-next merge of the pci tree got a conflict in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c between commit
8eee694c3e66 ("bnx2x: fix unload previous driver flow when flr-capable")
from Linus' tree and commit 2a80eebcbf3e ("bnx2x: Use PCI Express
Capability accessors") from the pci tree.
The former removes the function updated by the latter, so I just removed
the function (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 2105498,281cf3f..000
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@@ -9372,29 -9378,28 +9366,25 @@@ static int __devinit bnx2x_prev_mark_pa
return rc;
}
-static bool __devinit bnx2x_can_flr(struct bnx2x *bp)
-{
- u32 cap;
- struct pci_dev *dev = bp->pdev;
-
- pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, );
- if (!(cap & PCI_EXP_DEVCAP_FLR))
- return false;
-
- return true;
-}
-
static int __devinit bnx2x_do_flr(struct bnx2x *bp)
{
- int i, pos;
+ int i;
u16 status;
struct pci_dev *dev = bp->pdev;
- /* probe the capability first */
- if (bnx2x_can_flr(bp))
- return -ENOTTY;
+
+ if (CHIP_IS_E1x(bp)) {
+ BNX2X_DEV_INFO("FLR not supported in E1/E1H\n");
+ return -EINVAL;
+ }
+
+ /* only bootcode REQ_BC_VER_4_INITIATE_FLR and onwards support flr */
+ if (bp->common.bc_ver < REQ_BC_VER_4_INITIATE_FLR) {
+ BNX2X_ERR("FLR not supported by BC_VER: 0x%x\n",
+bp->common.bc_ver);
+ return -EINVAL;
+ }
- pos = pci_pcie_cap(dev);
- if (!pos)
- return -ENOTTY;
-
/* Wait for Transaction Pending bit clean */
for (i = 0; i < 4; i++) {
if (i)
pgpyLejQ1ATC4.pgp
Description: PGP signature
Re: [PATCH 4/7] perf scripts: Export a find_scripts() function
On Mon, 3 Sep 2012 16:14:30 +0800, Feng Tang wrote:
> So that other perf commands/browser has a way to dig out the available
> scripts info in system, this is a preparation for the script browser.
>
> Signed-off-by: Feng Tang
> ---
> tools/perf/builtin-script.c | 46
> +++
> tools/perf/builtin.h|1 +
> 2 files changed, 47 insertions(+), 0 deletions(-)
>
> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
> index 7ab86bb..d46056c 100644
> --- a/tools/perf/builtin-script.c
> +++ b/tools/perf/builtin-script.c
> @@ -1031,6 +1031,52 @@ static int list_available_scripts(const struct option
> *opt __used,
> exit(0);
> }
>
> +/*
> + * Return 0 if none is found, otherwise the actual scripts number.
No. It'll return -1 if perf exec path is not set properly.
Thanks,
Namhyung
> + *
> + * Currently we just return all the raw scripts name, and their full path.
> + *
> + */
> +int find_scripts(char **scripts_array, char **scripts_path_array)
> +{
> + struct dirent *script_next, *lang_next, script_dirent, lang_dirent;
> + char scripts_path[MAXPATHLEN];
> + DIR *scripts_dir, *lang_dir;
> + char lang_path[MAXPATHLEN];
> + struct script_desc *desc;
> + char first_half[BUFSIZ];
> + char *temp;
> + int i = 0;
> +
> + first_half[0] = 0;
> + desc = NULL;
> +
> + snprintf(scripts_path, MAXPATHLEN, "%s/scripts", perf_exec_path());
> +
> + scripts_dir = opendir(scripts_path);
> + if (!scripts_dir)
> + return -1;
> +
> + for_each_lang(scripts_path, scripts_dir, lang_dirent, lang_next) {
> + snprintf(lang_path, MAXPATHLEN, "%s/%s", scripts_path,
> + lang_dirent.d_name);
> + lang_dir = opendir(lang_path);
> + if (!lang_dir)
> + continue;
> +
> + for_each_script(lang_path, lang_dir, script_dirent,
> script_next) {
> + sprintf(scripts_path_array[i], "%s/%s", lang_path,
> + script_dirent.d_name);
> + temp = strchr(script_dirent.d_name, '.');
> + snprintf(scripts_array[i], (temp -
> script_dirent.d_name) + 1,
> + "%s", script_dirent.d_name);
> + i++;
> + }
> + }
> +
> + return i;
> +}
> +
> static char *get_script_path(const char *script_root, const char *suffix)
> {
> struct dirent *script_next, *lang_next, script_dirent, lang_dirent;
> diff --git a/tools/perf/builtin.h b/tools/perf/builtin.h
> index b382bd5..3ea74ed 100644
> --- a/tools/perf/builtin.h
> +++ b/tools/perf/builtin.h
> @@ -36,4 +36,5 @@ extern int cmd_kvm(int argc, const char **argv, const char
> *prefix);
> extern int cmd_test(int argc, const char **argv, const char *prefix);
> extern int cmd_inject(int argc, const char **argv, const char *prefix);
>
> +extern int find_scripts(char **scripts_array, char **scripts_path_array);
> #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix incorrect memset in bnx2fc_parse_fcp_rsp
On 9/3/2012 11:50 AM, Andi Kleen wrote: gcc 4.8 warns because the memset only clears sizeof(char *) bytes, not the whole buffer. Use the correct buffer size and clear the whole sense buffer. /backup/lsrc/git/linux-lto-2.6/drivers/scsi/bnx2fc/bnx2fc_io.c: In function 'bnx2fc_parse_fcp_rsp': /backup/lsrc/git/linux-lto-2.6/drivers/scsi/bnx2fc/bnx2fc_io.c:1810:41: warning: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess] memset(sc_cmd->sense_buffer, 0, sizeof(sc_cmd->sense_buffer)); ^ Signed-off-by: Andi Kleen diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c index 73f231c..8d4626c 100644 --- a/drivers/scsi/bnx2fc/bnx2fc_io.c +++ b/drivers/scsi/bnx2fc/bnx2fc_io.c @@ -1807,7 +1807,7 @@ static void bnx2fc_parse_fcp_rsp(struct bnx2fc_cmd *io_req, fcp_sns_len = SCSI_SENSE_BUFFERSIZE; } - memset(sc_cmd->sense_buffer, 0, sizeof(sc_cmd->sense_buffer)); + memset(sc_cmd->sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); if (fcp_sns_len) memcpy(sc_cmd->sense_buffer, rq_data, fcp_sns_len); Thanks Andi. Looks good to me. Acked-by: Bhanu Prakash Gollapudi -- 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] Staging: bcm: fix possible memory leak in bcm_char_ioctl()
On Mon, Sep 03, 2012 at 06:02:23PM +0800, Wei Yongjun wrote: > From: Wei Yongjun > > psFwInfo has been allocated in this function and should be > freed before leaving from the error handling cases. > > spatch with a semantic match is used to found this problem. > (http://coccinelle.lip6.fr/) > > Signed-off-by: Wei Yongjun > --- > drivers/staging/bcm/Bcmchar.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/staging/bcm/Bcmchar.c b/drivers/staging/bcm/Bcmchar.c > index cf411d1..3d02c2e 100644 > --- a/drivers/staging/bcm/Bcmchar.c > +++ b/drivers/staging/bcm/Bcmchar.c Acked-by: Kevin McKinney -- 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 4/7] perf scripts: Export a find_scripts() function
On Mon, 3 Sep 2012 16:14:30 +0800, Feng Tang wrote:
> So that other perf commands/browser has a way to dig out the available
> scripts info in system, this is a preparation for the script browser.
>
> Signed-off-by: Feng Tang
> ---
> tools/perf/builtin-script.c | 46
> +++
> tools/perf/builtin.h|1 +
> 2 files changed, 47 insertions(+), 0 deletions(-)
>
> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
> index 7ab86bb..d46056c 100644
> --- a/tools/perf/builtin-script.c
> +++ b/tools/perf/builtin-script.c
> @@ -1031,6 +1031,52 @@ static int list_available_scripts(const struct option
> *opt __used,
> exit(0);
> }
>
> +/*
> + * Return 0 if none is found, otherwise the actual scripts number.
> + *
> + * Currently we just return all the raw scripts name, and their full path.
> + *
> + */
> +int find_scripts(char **scripts_array, char **scripts_path_array)
> +{
> + struct dirent *script_next, *lang_next, script_dirent, lang_dirent;
> + char scripts_path[MAXPATHLEN];
> + DIR *scripts_dir, *lang_dir;
> + char lang_path[MAXPATHLEN];
> + struct script_desc *desc;
> + char first_half[BUFSIZ];
> + char *temp;
> + int i = 0;
> +
> + first_half[0] = 0;
> + desc = NULL;
> +
> + snprintf(scripts_path, MAXPATHLEN, "%s/scripts", perf_exec_path());
> +
> + scripts_dir = opendir(scripts_path);
> + if (!scripts_dir)
> + return -1;
> +
> + for_each_lang(scripts_path, scripts_dir, lang_dirent, lang_next) {
It'd be better if checking language supported - ie. by NO_LIBPERL and/or
NO_LIBPYTHON macro rather than showing all regardless. Also you might
consider when perf was built with no script language support.
Thanks,
Namhyung
> + snprintf(lang_path, MAXPATHLEN, "%s/%s", scripts_path,
> + lang_dirent.d_name);
> + lang_dir = opendir(lang_path);
> + if (!lang_dir)
> + continue;
> +
> + for_each_script(lang_path, lang_dir, script_dirent,
> script_next) {
> + sprintf(scripts_path_array[i], "%s/%s", lang_path,
> + script_dirent.d_name);
> + temp = strchr(script_dirent.d_name, '.');
> + snprintf(scripts_array[i], (temp -
> script_dirent.d_name) + 1,
> + "%s", script_dirent.d_name);
> + i++;
> + }
> + }
> +
> + return i;
> +}
> +
> static char *get_script_path(const char *script_root, const char *suffix)
> {
> struct dirent *script_next, *lang_next, script_dirent, lang_dirent;
> diff --git a/tools/perf/builtin.h b/tools/perf/builtin.h
> index b382bd5..3ea74ed 100644
> --- a/tools/perf/builtin.h
> +++ b/tools/perf/builtin.h
> @@ -36,4 +36,5 @@ extern int cmd_kvm(int argc, const char **argv, const char
> *prefix);
> extern int cmd_test(int argc, const char **argv, const char *prefix);
> extern int cmd_inject(int argc, const char **argv, const char *prefix);
>
> +extern int find_scripts(char **scripts_array, char **scripts_path_array);
> #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/4] Add device tree support for on-chip SRAM
On Mon, Sep 03, 2012 at 06:02:04PM +0200, Philipp Zabel wrote: > Changes since v2, as per Shawn's suggestions: > - Moved struct device_node declaration out of #ifdef CONFIG_OF. > - Simplified of_get_named_gen_pool using of_parse_phandle and >of_address_to_resource. > - Return -EADDRNOTAVAIL if devm_request_and_ioremap fails. > - Squashed i.MX changes together. > For the series: Reviewed-by: Shawn Guo Though it will be very simple one, we may still need a binding doc for that "sram" driver. Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Two question about kernel global function declaration and directory layout
On 04/09/12 01:32, daley wrote: > hi, everyone, I'm a big fan of the kernel, I was always being attracted > by its clean and intelligent design. I'm new to the mailing list and > this is my first post. I want to ask two basic question about kernel > which bother me a lot, I've googled a lot but nobody could give a > suitable answer . > > The first one is about global function declaration, I was confused about > the usage of keyword "extern" before a global function which declared in > the header file. for example, It specifies that the function has external linkage, which is the opposite of internal (static keyword) linkage. The default linkage for functions in external, so the extern keyword is not technically required, but many developers like to specify it explicitly. C linkage is explained here: http://publications.gbdirect.co.uk/c_book/chapter4/linkage.html > The second question is why not move the *sound* directory into the > *drivers* directory or put bigger subsystem out of drivers, since there > are more bigger subsystems(e.g. media, scsi) than sound? This was discussed a couple of years back, but never happened. I'm not sure what the reasons were. You can read through the discussion yourself if you are so inclined. There is an email from Linus explaining some of the historical reasons why the sound code is in sound/ and not drivers/sound: http://lkml.indiana.edu/hypermail/linux/kernel/0805.2/3026.html ~Ryan -- 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/7] perf ui/browser: Add browser for perf script
Hi, Feng On Mon, 3 Sep 2012 16:14:26 +0800, Feng Tang wrote: > Hi Arnaldo and all, > > This is a patch set mainly to add a browser for perf script, which > will be integrated into the main hists and annotation browser. > > Patch 1-4 are some preparation for adding the script > patch 5 introduce the script browser > patch 6-7 integrate the browser to hists browser and annotation browser > > The patches are on top of current perf/core branch of your git tree. > Please help to review, thanks > There was a build failure on my F17 box: CC builtin-script.o builtin-script.c: In function ‘find_scripts’: builtin-script.c:1047:7: error: variable ‘first_half’ set but not used [-Werror=unused-but-set-variable] builtin-script.c:1046:22: error: variable ‘desc’ set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make: *** [builtin-script.o] Error 1 Thanks, Namhyung > Feng > --- > Feng Tang (7): > perf symbols: Filter samples with unresolved symbol when "--symbols" > option is used > perf scripts: Add --symbols option to handle specific symbols > perf scripts: Add event_analyzing_sample-record/report > perf scripts: Export a find_scripts() function > perf ui/browser: Add a browser for perf script > perf ui/browser: Integrate script browser into annotation browser > perf ui/browser: Integrate script browser into main hists browser > > tools/perf/Makefile|5 + > tools/perf/builtin-script.c| 49 ++ > tools/perf/builtin.h |1 + > .../python/bin/event_analyzing_sample-record |8 + > .../python/bin/event_analyzing_sample-report |3 + > tools/perf/ui/browsers/annotate.c |8 + > tools/perf/ui/browsers/hists.c | 39 + > tools/perf/ui/browsers/scripts.c | 159 > > tools/perf/ui/browsers/scripts.h |5 + > tools/perf/util/event.c|5 +- > 10 files changed, 280 insertions(+), 2 deletions(-) > create mode 100644 > tools/perf/scripts/python/bin/event_analyzing_sample-record > create mode 100644 > tools/perf/scripts/python/bin/event_analyzing_sample-report > create mode 100644 tools/perf/ui/browsers/scripts.c > create mode 100644 tools/perf/ui/browsers/scripts.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] tools: Fix pthread flag for Makefile of trace-agent used by virtio-trace
pthread flag should not be -lpthread but -pthread using gcc. The -lpthread links the external multithread library. On the other hand, the -pthread manages both the gcc's preprocessor and linker to be able to compile with pthread. Signed-off-by: Yoshihiro YUNOMAE --- tools/virtio/virtio-trace/Makefile |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/tools/virtio/virtio-trace/Makefile b/tools/virtio/virtio-trace/Makefile index ef3adfc..0d23816 100644 --- a/tools/virtio/virtio-trace/Makefile +++ b/tools/virtio/virtio-trace/Makefile @@ -1,14 +1,13 @@ CC = gcc -CFLAGS = -O2 -Wall -LFLAG = -lpthread +CFLAGS = -O2 -Wall -pthread all: trace-agent .c.o: - $(CC) $(CFLAGS) $(LFLAG) -c $^ -o $@ + $(CC) $(CFLAGS) -c $^ -o $@ trace-agent: trace-agent.o trace-agent-ctl.o trace-agent-rw.o - $(CC) $(CFLAGS) $(LFLAG) -o $@ $^ + $(CC) $(CFLAGS) -o $@ $^ clean: rm -f *.o trace-agent -- 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] proc: use kzalloc instead of kmalloc and memset
On 04/09/12 00:14, yan wrote: > Signed-off-by: yan > --- > fs/proc/generic.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/fs/proc/generic.c b/fs/proc/generic.c > index 9e8f631..38de015 100644 > --- a/fs/proc/generic.c > +++ b/fs/proc/generic.c > @@ -616,10 +616,9 @@ static struct proc_dir_entry *__proc_create(struct > proc_dir_entry **parent, > > len = strlen(fn); > > - ent = kmalloc(sizeof(struct proc_dir_entry) + len + 1, GFP_KERNEL); > + ent = kzalloc(sizeof(struct proc_dir_entry) + len + 1, GFP_KERNEL); > if (!ent) goto out; > > - memset(ent, 0, sizeof(struct proc_dir_entry)); > memcpy(ent->name, fn, len + 1); > ent->namelen = len; > ent->mode = mode; Note that this change results in slightly different behaviour. Before your change only sizeof(struct proc_dir_entry) is zero'ed by memset, and then the name is filled in (the len + 1 part). After your change the structure and the name field are both zeroed, so the name field is being written to twice. The cost is probably negligible though. ~Ryan -- 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/3] proc: return -ENOMEM when inode allocation failed
On 04/09/12 00:14, yan wrote:
> Signed-off-by: yan
> ---
> fs/proc/generic.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/proc/generic.c b/fs/proc/generic.c
> index b3647fe..9e8f631 100644
> --- a/fs/proc/generic.c
> +++ b/fs/proc/generic.c
> @@ -427,7 +427,7 @@ struct dentry *proc_lookup_de(struct proc_dir_entry *de,
> struct inode *dir,
> if (!memcmp(dentry->d_name.name, de->name, de->namelen)) {
> pde_get(de);
> spin_unlock(_subdir_lock);
> - error = -EINVAL;
> + error = -ENOMEM;
This seems incorrect. This function doesn't allocate anything, it looks
up an inode. From my reading it looks like -EINVAL is returned here if
the dentry name matches, but the inode cannot be found.
~Ryan
--
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 5/5] scripts/checkincludes.pl: Replace tabs with spaces
My bad, misread the documentation files.
I'll resubmit without this
On Tue, 2012-09-04 at 08:20 +1000, Cruz Julian Bishop wrote:
> This is required by the CodingStyle kernel documentation file
>
> Signed-off-by: Cruz Julian Bishop
> ---
> scripts/checkincludes.pl | 122
> +++
> 1 file changed, 61 insertions(+), 61 deletions(-)
>
> diff --git a/scripts/checkincludes.pl b/scripts/checkincludes.pl
> index bff7316..7e3df9e 100755
> --- a/scripts/checkincludes.pl
> +++ b/scripts/checkincludes.pl
> @@ -14,7 +14,7 @@
> use strict;
>
> sub usage {
> - print < +print < Usage: checkincludes.pl [OPTIONS]... FILE...
> By default, we just warn of duplicates.
>
> @@ -23,84 +23,84 @@ Options:
>-qDo not show messages for files that do not
> have duplicated includes
> EOM
> - exit 1;
> +exit 1;
> }
>
> my $remove = 0;
> my $quiet = 0;
>
> if ($#ARGV < 0) {
> - usage();
> +usage();
> }
>
> my $argc = 0;
>
> foreach my $arg (@ARGV) {
> - if ($arg eq "-r") {
> - $remove = 1;
> - } elsif($arg eq "-q") {
> - $quiet = 1;
> - } else {
> - open(my $f, '<', $arg)
> - or die "Cannot open $arg: $!.\n";
> -
> - $argc++;
> +if ($arg eq "-r") {
> +$remove = 1;
> +} elsif($arg eq "-q") {
> +$quiet = 1;
> +} else {
> +open(my $f, '<', $arg)
> +or die "Cannot open $arg: $!.\n";
> +
> +$argc++;
>
> - my %includedfiles = ();
> - my @file_lines = ();
> +my %includedfiles = ();
> +my @file_lines = ();
>
> - while (<$f>) {
> - if (m/^\s*#\s*include\s*[<"](\S*)[>"]/o) {
> - ++$includedfiles{$1};
> - }
> - push(@file_lines, $_);
> - }
> +while (<$f>) {
> +if (m/^\s*#\s*include\s*[<"](\S*)[>"]/o) {
> +++$includedfiles{$1};
> +}
> +push(@file_lines, $_);
> +}
>
> - close($f);
> +close($f);
>
> - if (!$remove) {
> - my $detected = 0;
> - foreach my $filename (keys %includedfiles) {
> - if ($includedfiles{$filename} > 1) {
> - $detected++;
> - print "$arg: $filename is included more
> than once.\n";
> - }
> - }
> - if (!$detected && !$quiet) {
> - print "$arg: No duplicated includes
> detected.\n";
> - }
> - next;
> - }
> +if (!$remove) {
> +my $detected = 0;
> +foreach my $filename (keys %includedfiles) {
> +if ($includedfiles{$filename} > 1) {
> +$detected++;
> +print "$arg: $filename is included more than
> once.\n";
> +}
> +}
> +if (!$detected && !$quiet) {
> +print "$arg: No duplicated includes
> detected.\n";
> +}
> +next;
> +}
>
> - open($f, '>', $arg)
> - or die("Cannot write to $arg: $!");
> +open($f, '>', $arg)
> +or die("Cannot write to $arg: $!");
>
> - my $dups = 0;
> - foreach(@file_lines) {
> - if (m/^\s*#\s*include\s*[<"](\S*)[>"]/o) {
> - foreach my $filename (keys %includedfiles) {
> - if ($1 eq $filename) {
> - if ($includedfiles{$filename} >
> 1) {
> -
> $includedfiles{$filename}--;
> - $dups++;
> - } else {
> - print {$f} $_;
> - }
> - }
> - }
> - } else {
> - print {$f} $_;
> - }
> - }
> - if ($dups > 0) {
> - print "$arg: removed $dups duplicate includes \n";
> - } elsif (!$quiet) {
> - print "$arg: no duplicated
陈钦键
┏━┯━┯━┯━┯━┓ ┃Ｑ│ │１│低│优┃ ┃Ｑ│联│３│，│惠┃ ┃：│系│６│先│开┃ ┃９│ │６│验│具┃ ┃５│人│２│证│企┃ ┃８│：│６│后│业┃ ┃８│ │０│付│发┃ ┃１│王│７│款│票┃ ┃１│︵│７│！│，┃ ┃６│先│４│手│收┃ ┃３│生│８│机│费┃ ┃９│︶│ │：│较┃ ┗━┷━┷━┷━┷━┛
Re: [PATCH 2/5] scripts/checkincludes.pl: Simplify and shorten argument logic
In my last submission, Joe Perches (is that right?)
suggested using a function that is built in to Perl.
I haven't had a chance to test it yet, but if it turns
out to be okay, I'll make a separate merge request at
a later date.
On Tue, 2012-09-04 at 08:20 +1000, Cruz Julian Bishop wrote:
> This patch allows for much easier implementation of arguments
> when modifying checkincludes.pl
>
> The variable $file is also initially named $arg - I wasn't sure
> if memory would be a problem (I know it would be in Java/C#) if
> another $file variable was initialized with the value of $arg,
> so I just left it.
>
> Overall, this still works nicely. There are some more
> potential simplifications, but I will cover those in another
> patch if I decide to implement them tonight.
>
> Signed-off-by: Cruz Julian Bishop
> ---
> scripts/checkincludes.pl | 85
> ++--
> 1 file changed, 39 insertions(+), 46 deletions(-)
>
> diff --git a/scripts/checkincludes.pl b/scripts/checkincludes.pl
> index 801ed5f..7d713c2 100755
> --- a/scripts/checkincludes.pl
> +++ b/scripts/checkincludes.pl
> @@ -30,64 +30,57 @@ if ($#ARGV < 0) {
> usage();
> }
>
> -if ($#ARGV >= 1) {
> - if ($ARGV[0] =~ /^-/) {
> - if ($ARGV[0] eq "-r") {
> - $remove = 1;
> - shift;
> - } else {
> - usage();
> - }
> - }
> -}
> +foreach my $arg (@ARGV) {
> + if ($arg eq "-r") {
> + $remove = 1;
> + } else {
> + open(my $f, '<', $arg)
> + or die "Cannot open $arg: $!.\n";
>
> -foreach my $file (@ARGV) {
> - open(my $f, '<', $file)
> - or die "Cannot open $file: $!.\n";
> + my %includedfiles = ();
> + my @file_lines = ();
>
> - my %includedfiles = ();
> - my @file_lines = ();
> -
> - while (<$f>) {
> - if (m/^\s*#\s*include\s*[<"](\S*)[>"]/o) {
> - ++$includedfiles{$1};
> + while (<$f>) {
> + if (m/^\s*#\s*include\s*[<"](\S*)[>"]/o) {
> + ++$includedfiles{$1};
> + }
> + push(@file_lines, $_);
> }
> - push(@file_lines, $_);
> - }
>
> - close($f);
> + close($f);
>
> - if (!$remove) {
> - foreach my $filename (keys %includedfiles) {
> - if ($includedfiles{$filename} > 1) {
> - print "$file: $filename is included more than
> once.\n";
> + if (!$remove) {
> + foreach my $filename (keys %includedfiles) {
> + if ($includedfiles{$filename} > 1) {
> + print "$arg: $filename is included more
> than once.\n";
> + }
> }
> + next;
> }
> - next;
> - }
>
> - open($f, '>', $file)
> - or die("Cannot write to $file: $!");
> + open($f, '>', $arg)
> + or die("Cannot write to $arg: $!");
>
> - my $dups = 0;
> - foreach (@file_lines) {
> - if (m/^\s*#\s*include\s*[<"](\S*)[>"]/o) {
> - foreach my $filename (keys %includedfiles) {
> - if ($1 eq $filename) {
> - if ($includedfiles{$filename} > 1) {
> - $includedfiles{$filename}--;
> - $dups++;
> - } else {
> - print {$f} $_;
> + my $dups = 0;
> + foreach(@file_lines) {
> + if (m/^\s*#\s*include\s*[<"](\S*)[>"]/o) {
> + foreach my $filename (keys %includedfiles) {
> + if ($1 eq $filename) {
> + if ($includedfiles{$filename} >
> 1) {
> +
> $includedfiles{$filename}--;
> + $dups++;
> + } else {
> + print {$f} $_;
> + }
> }
> }
> + } else {
> + print {$f} $_;
> }
> - } else {
> - print {$f} $_;
> }
> + if ($dups > 0) {
> + print "$arg: removed $dups duplicate includes \n";
> + }
> + close($f);
> }
> - if ($dups > 0) {
> - print "$file: removed $dups duplicate includes\n";
> - }
> -
RE: [PATCH] gpio:clk: preparation for switch to common clock framework
>> -Original Message- >> From: Linus Walleij [mailto:linus.wall...@linaro.org] >> Sent: Friday, August 31, 2012 7:14 PM >> To: Karicheri, Muralidharan; Hilman, Kevin; Nori, Sekhar >> Cc: grant.lik...@secretlab.ca; linux-kernel@vger.kernel.org; >> mturque...@linaro.org >> Subject: Re: [PATCH] gpio:clk: preparation for switch to common clock >> framework >> >> On Thu, Aug 30, 2012 at 8:03 PM, Murali Karicheri >> wrote: >> >> > As a first step towards migrating davinci platforms to use common clock >> > framework, replace all instances of clk_enable() with clk_prepare_enable() >> > and clk_disable() with clk_disable_unprepare(). Until the platform is >> > switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just >> > adds a might_sleep() call and would work without any issues. >> > >> > This will make it easy later to switch to common clk based implementation >> > of clk driver from DaVinci specific driver. >> > >> > Signed-off-by: Murali Karicheri >> >> OK the patch is so obviously correct so I just applied it, DaVinci folks, >> scream if you still don't want it for some reason... >> Linus, Thanks for applying this patch. Murali Karicheri Software Design Engineer >> Yours, >> Linus Walleij -- 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] tty: Added a CONFIG_TTY option to allow removal of TTY
On Mon, Sep 3, 2012 at 2:45 PM, Jiri Slaby wrote: > On 09/03/2012 11:24 PM, Joe Millenbach wrote: >> I do not have a Power PC system to test on > > Neither do I. But that is no excuse to break it. There are > cross-compilers for instance. True. I was not saying I should leave it, only why I did not catch it sooner and was asking for a better way. >> so during my testing I did >> not notice that option would need TTY also. Thanks for pointing that >> out. Before I spin a new patch is there anything else I should add? >> I do not know of a way for me to easily test all the different CPU >> specific configurations on my x86 based machines. > > Basically everything that does alloc_tty_driver... > > You should minimize the risk of breaking !TTY builds (randconfig for > example) on other arches as much as possible. I'm not trying to force > you to do allmodconfig minus TTY on all arches, but at least do 'git > grep' thoroughly. > > thanks, > -- > js > suse labs Perfect, I'll go through this list and make sure I've handled all of them. Thanks for your time, Joe -- 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: HDD problem, software bug, bios bug, or hardware ?
> But now an interrupt occurs during the hard
>reset, and pdc_interrupt also has to take the host lock.
I have 4 sata connectors on the motherboard -
http://www.hardwareheaven.com/reviews/asusA8V/
If i understand right, just 2 of them are linked to promise controller. Well i
changed the connector where my HDD is connected,
and dmesg warning message is a bit different now - "ata_bmdma_interrupt" was
replaced by "pdc_interrupt".
[ 1.973049] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.984574]
[ 1.984575] =
[ 1.984576] [ INFO: inconsistent lock state ]
[ 1.984578] 3.5.2 #4 Not tainted
[ 1.984578] -
[ 1.984579] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[ 1.984581] swapper/1/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[ 1.984582] (&(>lock)->rlock){?.+...}, at: []
pdc_interrupt+0x48/0x420
[ 1.984590] {HARDIRQ-ON-W} state was registered at:
[ 1.984591] [] __lock_acquire+0x61b/0x1af0
[ 1.984595] [] lock_acquire+0x8a/0x110
[ 1.984597] [] _raw_spin_lock+0x31/0x40
[ 1.984602] [] pdc_sata_hardreset+0x85/0x100
[ 1.984604] [] ata_do_reset+0x3a/0x90
[ 1.984607] [] ata_eh_reset+0x372/0xe00
[ 1.984610] [] ata_eh_recover+0x2a5/0x13d0
[ 1.984612] [] ata_do_eh+0x4d/0xb0
[ 1.984614] [] ata_sff_error_handler+0xca/0x120
[ 1.984617] [] pdc_error_handler+0x24/0x30
[ 1.984619] [] ata_scsi_port_error_handler+0x47c/0x800
[ 1.984622] [] ata_scsi_error+0x9e/0xd0
[ 1.984624] [] scsi_error_handler+0xf8/0x500
[ 1.984628] [] kthread+0xae/0xc0
[ 1.984631] [] kernel_thread_helper+0x4/0x10
[ 1.984634] irq event stamp: 49968
[ 1.984635] hardirqs last enabled at (49965): []
default_idle+0x5d/0x1b0
[ 1.984639] hardirqs last disabled at (49966): []
common_interrupt+0x67/0x6c
[ 1.984641] softirqs last enabled at (49968): []
_local_bh_enable+0x13/0x20
[ 1.984645] softirqs last disabled at (49967): []
irq_enter+0x75/0x90
[ 1.984648]
[ 1.984648] other info that might help us debug this:
[ 1.984648] Possible unsafe locking scenario:
[ 1.984648]
[ 1.984649] CPU0
[ 1.984649]
[ 1.984650] lock(&(>lock)->rlock);
[ 1.984651]
[ 1.984651] lock(&(>lock)->rlock);
[ 1.984653]
[ 1.984653] *** DEADLOCK ***
[ 1.984653]
[ 1.984654] no locks held by swapper/1/0.
[ 1.984654]
[ 1.984654] stack backtrace:
[ 1.984656] Pid: 0, comm: swapper/1 Not tainted 3.5.2 #4
[ 1.984656] Call Trace:
[ 1.984657] [] print_usage_bug+0x1f7/0x208
[ 1.984662] [] ? save_stack_trace+0x2f/0x50
[ 1.984665] [] ?
print_shortest_lock_dependencies+0x1d0/0x1d0
[ 1.984668] [] mark_lock+0x262/0x2a0
[ 1.984670] [] __lock_acquire+0x813/0x1af0
[ 1.984672] [] ? load_balance+0xd1/0x730
[ 1.984676] [] ? update_cfs_shares+0x100/0x100
[ 1.984678] [] lock_acquire+0x8a/0x110
[ 1.984680] [] ? pdc_interrupt+0x48/0x420
[ 1.984682] [] _raw_spin_lock+0x31/0x40
[ 1.984685] [] ? pdc_interrupt+0x48/0x420
[ 1.984686] [] ? rebalance_domains+0x1b8/0x1e0
[ 1.984689] [] pdc_interrupt+0x48/0x420
[ 1.984691] [] handle_irq_event_percpu+0x5d/0x1f0
[ 1.984694] [] handle_irq_event+0x48/0x70
[ 1.984695] [] ? _raw_spin_lock+0x39/0x40
[ 1.984698] [] ? handle_fasteoi_irq+0x1e/0xf0
[ 1.984700] [] handle_fasteoi_irq+0x5a/0xf0
[ 1.984702] [] handle_irq+0x22/0x40
[ 1.984706] [] do_IRQ+0x5a/0xe0
[ 1.984708] [] common_interrupt+0x6c/0x6c
[ 1.984711] [] ? default_idle+0x5f/0x1b0
[ 1.984714] [] ? default_idle+0x5d/0x1b0
[ 1.984717] [] cpu_idle+0x106/0x120
[ 1.984719] [] start_secondary+0x1dd/0x1e4
[ 1.984761] ata1.00: ATA-6: ST3200822AS, 3.01, max UDMA/133
[ 1.984763] ata1.00: 390721968 sectors, multi 0: LBA48
[ 2.006548] ata1.00: configured for UDMA/133
Here is the full dmesg - http://pastebin.com/1xLETNd5
And the crashes are continuing - heavy disk operations like "md5sum -c а.md5",
where a.md5 contains md5 sums of more than 300 000 files,
speed up the crash between 10 and 100 times, compared to the idle case, and it
crashes with oops like:
[10432.283017] BUG: unable to handle kernel NULL pointer dereference
at (null)
[10432.293110] IP: [] update_ts_time_stats+0x6c/0x90
[10432.293110] PGD 7a223067 PUD 7958a067 PMD 0
[10432.293110] Oops: 0002 [#1] SMP
[10432.293110] CPU 1
[10432.293110] Modules linked in:[10432.293110] netconsole snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss ipt_REJECT
xt_tcpudp iptable_raw iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_conntrack iptable_filter ip_tables x_tables lp fuse nouveau
mxm_wmi wmi video ttm drm_kms_helper drm snd_via82xx snd_ac97_codec
snd_mpu401_uart snd_rawmidi powernow_k8 snd_seq_device snd_pcm mperf processor
snd_page_alloc snd_timer i2c_algo_bit snd soundcore ac97_bus gameport ppdev
k8temp
Re: [PATCHv2] tty: Added a CONFIG_TTY option to allow removal of TTY
On 09/03/2012 11:24 PM, Joe Millenbach wrote: > I do not have a Power PC system to test on Neither do I. But that is no excuse to break it. There are cross-compilers for instance. > so during my testing I did > not notice that option would need TTY also. Thanks for pointing that > out. Before I spin a new patch is there anything else I should add? > I do not know of a way for me to easily test all the different CPU > specific configurations on my x86 based machines. Basically everything that does alloc_tty_driver... You should minimize the risk of breaking !TTY builds (randconfig for example) on other arches as much as possible. I'm not trying to force you to do allmodconfig minus TTY on all arches, but at least do 'git grep' thoroughly. thanks, -- js suse labs -- 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] ACPI: Enable SCI_EMULATE to manually simulate physical hotplug testing.
From: Ashok Raj
Emulate an ACPI SCI interrupt to emulate a hot-plug event. Useful
for testing ACPI based hot-plug on systems that don't have the
necessary firmware support.
Enable CONFIG_ACPI_SCI_EMULATE on kernel compile.
Now you will notice /sys/kernel/debug/acpi/sci_notify when new kernel is
booted.
echo "\_SB.PCIB 1" > /sys/kernel/debug/acpi/sci_notify to trigger a hot-add
of root bus that is corresponding to PCIB.
echo "\_SB.PCIB 3" > /sys/kernel/debug/acpi/sci_notify to trigger a hot-remove
of root bus that is corresponding to PCIB.
-v2: Update to current upstream, and remove not related stuff.
-v3: According to Len's request, update it to use debugfs. - Yinghai Lu
Signed-off-by: Yinghai Lu
Cc: Len Brown
Cc: linux-a...@vger.kernel.org
===
---
drivers/acpi/Kconfig | 10 +++
drivers/acpi/Makefile |1
drivers/acpi/sci_emu.c | 145 +
3 files changed, 156 insertions(+)
Index: linux-2.6/drivers/acpi/Kconfig
===
--- linux-2.6.orig/drivers/acpi/Kconfig
+++ linux-2.6/drivers/acpi/Kconfig
@@ -272,6 +272,16 @@ config ACPI_BLACKLIST_YEAR
Enter 0 to disable this mechanism and allow ACPI to
run by default no matter what the year. (default)
+config ACPI_SCI_EMULATE
+bool "ACPI SCI Event Emulation Support"
+depends on DEBUG_FS
+ default n
+ help
+ This will enable your system to emulate sci hotplug event
+ notification through proc file system. For example user needs to
+ echo "XXX 0" > /sys/kernel/debug/acpi/sci_notify (where, XXX is
+ a target ACPI device object name present under \_SB scope).
+
config ACPI_DEBUG
bool "Debug Statements"
default n
Index: linux-2.6/drivers/acpi/sci_emu.c
===
--- /dev/null
+++ linux-2.6/drivers/acpi/sci_emu.c
@@ -0,0 +1,145 @@
+/*
+ * Code to emulate SCI interrupt for Hotplug node insertion/removal
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "internal.h"
+
+#include "acpica/accommon.h"
+#include "acpica/acnamesp.h"
+#include "acpica/acevents.h"
+
+#define _COMPONENT ACPI_SYSTEM_COMPONENT
+ACPI_MODULE_NAME("sci_emu");
+MODULE_LICENSE("GPL");
+
+static struct dentry *sci_notify_dentry;
+
+static void sci_notify_client(char *acpi_name, u32 event)
+{
+ struct acpi_namespace_node *node;
+ acpi_status status, status1;
+ acpi_handle hlsb, hsb;
+ union acpi_operand_object *obj_desc;
+
+ status = acpi_get_handle(NULL, "\\_SB", );
+ status1 = acpi_get_handle(hsb, acpi_name, );
+ if (ACPI_FAILURE(status) || ACPI_FAILURE(status1)) {
+ pr_err(PREFIX
+ "acpi getting handle to <\\_SB.%s> failed inside notify_client\n",
+ acpi_name);
+ return;
+ }
+
+ status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
+ if (ACPI_FAILURE(status)) {
+ pr_err(PREFIX "Acquiring acpi namespace mutext failed\n");
+ return;
+ }
+
+ node = acpi_ns_validate_handle(hlsb);
+ if (!node) {
+ acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
+ pr_err(PREFIX "Mapping handle to node failed\n");
+ return;
+ }
+
+ /*
+* Check for internal object and make sure there is a handler
+* registered for this object
+*/
+ obj_desc = acpi_ns_get_attached_object(node);
+ if (obj_desc) {
+ if (obj_desc->common_notify.notify_list[0]) {
+ /*
+* Release the lock and queue the item for later
+* exectuion
+*/
+ acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
+ status = acpi_ev_queue_notify_request(node, event);
+ if (ACPI_FAILURE(status))
+ pr_err(PREFIX "acpi_ev_queue_notify_request
failed\n");
+ else
+ pr_info(PREFIX "Notify event is queued\n");
+ return;
+ }
+ } else {
+ pr_info(PREFIX "Notify handler not registered for this
device\n");
+ }
+
+ acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
+ return;
+}
+
+static ssize_t sci_notify_write(struct file *file, const char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+ u32 event;
+ char *name1 = NULL;
+ char *name2 = NULL;
+ const char *delim = " ";
+ char *temp_buf = NULL;
+ char *temp_buf_addr = NULL;
+
+ temp_buf = kmalloc(count+1, GFP_ATOMIC);
+ if (!temp_buf) {
+ pr_warn(PREFIX "sci_notify_wire: Memory allocation failed\n");
+
Re: [PATCHv2] tty: Added a CONFIG_TTY option to allow removal of TTY
On Mon, Sep 3, 2012 at 2:15 PM, Jiri Slaby wrote: > > On 09/03/2012 02:44 AM, Joe Millenbach wrote: > > The option allows you to remove TTY and compile without errors. This > > saves space on systems that won't support TTY interfaces anyway. > > bloat-o-meter output is below. > ... > > --- a/drivers/tty/Kconfig > > +++ b/drivers/tty/Kconfig > > @@ -1,3 +1,14 @@ > > +config TTY > > + bool "Enable TTY" if EXPERT > > + default y > > + ---help--- > > + Allows you to remove TTY support which can save space, and > > + blocks features that require TTY from inclusion in the kernel. > > + TTY is required for any text terminals or serial port > > + communication. Most users should leave this enabled. > > + > > +if TTY > > + > > config VT > > bool "Virtual terminal" if EXPERT > > depends on !S390 && !UML > > @@ -355,6 +366,8 @@ config TRACE_SINK > > If you select this option, you need to select > > "Trace data router for MIPI P1149.7 cJTAG standard". > > > > +endif # TTY > > + > > config PPC_EPAPR_HV_BYTECHAN > > tristate "ePAPR hypervisor byte channel driver" > > depends on PPC > > Hmm, I wonder why do not you include EHV in the depends-on-tty list? > > thanks, > -- > js > suse labs I do not have a Power PC system to test on, so during my testing I did not notice that option would need TTY also. Thanks for pointing that out. Before I spin a new patch is there anything else I should add? I do not know of a way for me to easily test all the different CPU specific configurations on my x86 based machines. Joe -- 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] tty: Added a CONFIG_TTY option to allow removal of TTY
On 09/03/2012 02:44 AM, Joe Millenbach wrote: > The option allows you to remove TTY and compile without errors. This > saves space on systems that won't support TTY interfaces anyway. > bloat-o-meter output is below. ... > --- a/drivers/tty/Kconfig > +++ b/drivers/tty/Kconfig > @@ -1,3 +1,14 @@ > +config TTY > + bool "Enable TTY" if EXPERT > + default y > + ---help--- > + Allows you to remove TTY support which can save space, and > + blocks features that require TTY from inclusion in the kernel. > + TTY is required for any text terminals or serial port > + communication. Most users should leave this enabled. > + > +if TTY > + > config VT > bool "Virtual terminal" if EXPERT > depends on !S390 && !UML > @@ -355,6 +366,8 @@ config TRACE_SINK > If you select this option, you need to select > "Trace data router for MIPI P1149.7 cJTAG standard". > > +endif # TTY > + > config PPC_EPAPR_HV_BYTECHAN > tristate "ePAPR hypervisor byte channel driver" > depends on PPC Hmm, I wonder why do not you include EHV in the depends-on-tty list? thanks, -- js suse labs -- 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/2] hw_random: mxc-rnga: Adapt clocks to new i.mx clock framework
Herbert, On Fri, Aug 3, 2012 at 12:10 PM, Fabio Estevam wrote: > Hi Herbert, > > On Tue, Jul 31, 2012 at 3:40 AM, Sascha Hauer wrote: >> On Fri, Jul 27, 2012 at 01:47:51PM -0300, Fabio Estevam wrote: >>> Adapt clocks to the new i.mx clock framework and fix the following warning: >>> >>> Cc: Theodore Ts'o >>> Cc: Herbert Xu >>> Cc: >>> Signed-off-by: Fabio Estevam >> >> Both: >> >> Acked-by: Sascha Hauer > > Looks like git did not Cc'ed you in these patches. > > Would it be OK to apply these two patches? Ping? -- 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 11/13] perf tools: replace mempcpy with memcpy
On Mon, Sep 3, 2012 at 4:09 AM, Namhyung Kim wrote: > On Wed, 29 Aug 2012 01:22:16 +0300, Irina Tirdea wrote: >> mempcpy is not supported by bionic in Android >> and will lead to compilation errors. >> >> Replacing mempcpy with memcpy so it will work in Android. > > Unfortunately I've added another instance of the mempcpy in a > libtraceevent code. :-/ > Thanks for the heads-up. I'll fix it. Irina > Thanks, > Namhyung > -- 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 can-next v6] can: add tx/rx LED trigger support
On 03.09.2012 20:29, Fabio Baltieri wrote: > On Mon, Sep 03, 2012 at 08:13:35PM +0200, Kurt Van Dijck wrote: >> On Mon, Sep 03, 2012 at 02:40:39PM +0200, Marc Kleine-Budde wrote: >>> The net->ifindex is unique. But it's only an integer. Usually can0 has a >>> ifindex != 0, so a simple can%d is contra productive here. >>> >>> Some pointers to related code: >>> http://lxr.free-electrons.com/source/drivers/base/core.c#L1847 >>> http://lxr.free-electrons.com/source/drivers/base/core.c#L73 >>> http://lxr.free-electrons.com/source/include/linux/device.h#L695 >>> >>> comments? > > That would probabily makes really hard to choose the right > default_trigger for led devices to get to the appropriate CAN LED in > embedded systems, as trigger name would depend from other network > devices and probing order (correct me if I'm wrong). > > Something with device name would probaily be more appropriate here. > >> >> a very recent idea: something with netdevice notifiers and NETDEV_CHANGENAME >> ... >> http://lxr.free-electrons.com/source/net/core/dev.c#L1030 >> >> you could: rename the trigger, or if we think it's usefull, >> block the netdev rename when its triggers are in use. > > Blocking the rename looks overkill to me, what about using device name > with an optional "port id" appended to it? Sounds simpler... The name of the device can only be changed when the interface is down. Is it possible to put some scripting around it to detach and attach the leds to the interfaces on ifup/ifdown triggers? Regards, Oliver -- 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 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Thu, 30 Aug 2012, Kent Overstreet wrote: > On Thu, Aug 30, 2012 at 06:07:45PM -0400, Vivek Goyal wrote: > > On Wed, Aug 29, 2012 at 10:13:45AM -0700, Kent Overstreet wrote: > > > > [..] > > > > Performance aside, punting submission to per device worker in case of > > > > deep > > > > stack usage sounds cleaner solution to me. > > > > > > Agreed, but performance tends to matter in the real world. And either > > > way the tricky bits are going to be confined to a few functions, so I > > > don't think it matters that much. > > > > > > If someone wants to code up the workqueue version and test it, they're > > > more than welcome... > > > > Here is one quick and dirty proof of concept patch. It checks for stack > > depth and if remaining space is less than 20% of stack size, then it > > defers the bio submission to per queue worker. > > I can't think of any correctness issues. I see some stuff that could be > simplified (blk_drain_deferred_bios() is redundant, just make it a > wrapper around blk_deffered_bio_work()). > > Still skeptical about the performance impact, though - frankly, on some > of the hardware I've been running bcache on this would be a visible > performance regression - probably double digit percentages but I'd have > to benchmark it. That kind of of hardware/usage is not normal today, > but I've put a lot of work into performance and I don't want to make > things worse without good reason. > > Have you tested/benchmarked it? > > There's scheduling behaviour, too. We really want the workqueue thread's > cpu time to be charged to the process that submitted the bio. (We could > use a mechanism like that in other places, too... not like this is a new > issue). > > This is going to be a real issue for users that need strong isolation - > for any driver that uses non negligable cpu (i.e. dm crypt), we're > breaking that (not that it wasn't broken already, but this makes it > worse). ... or another possibility - start a timer when something is put to current->bio_list and use that timer to pop entries off current->bio_list and submit them to a workqueue. The timer can be cpu-local so only interrupt masking is required to synchronize against the timer. This would normally run just like the current kernel and in case of deadlock, the timer would kick in and resolve the deadlock. > I could be convinced, but right now I prefer my solution. It fixes bio allocation problem, but not other similar mempool problems in dm and md. Mikulas -- 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] Revert "spi/doc: spi_master_put must be followed up by kfree"
Actually, spi_master_put() after spi_alloc_master() must _not_ be followed
by kfree(). The memory is already freed with the call to spi_master_put()
through spi_master_class, which registers a release function. Calling both
spi_master_put() and kfree() results in often nasty (and delayed) crashes
elsewhere in the kernel, often in the networking stack.
This reverts commit eb4af0f5349235df2e4a5057a72fc8962d00308a.
Cc: Uwe Kleine-Koenig
Signed-off-by: Guenter Roeck
---
drivers/spi/spi.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 2d9b5bb..6470750 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1082,8 +1082,7 @@ static struct class spi_master_class = {
*
* The caller is responsible for assigning the bus number and initializing
* the master's methods before calling spi_register_master(); and (after errors
- * adding the device) calling spi_master_put() and kfree() to prevent a memory
- * leak.
+ * adding the device) calling spi_master_put() to prevent a memory leak.
*/
struct spi_master *spi_alloc_master(struct device *dev, unsigned size)
{
--
1.7.9.7
--
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 1/2] virtio_console: Add support for DMA memory allocation
On Mon, Sep 03, 2012 at 04:57:45PM +0200, Sjur Brændeland wrote:
> Hi Michael,
>
> > How does access to descriptors work in this setup?
>
> When the ring is setup by remoteproc the descriptors are
> also allocated using dma_alloc_coherent().
>
> >> -static void free_buf(struct port_buffer *buf)
> >> +/* Allcoate data buffer from DMA memory if requested */
> >
> > typo
>
> Thanks.
>
> >> +static inline void *
> >> +alloc_databuf(struct virtio_device *vdev, size_t size, dma_addr_t
> >> *dma_handle,
> >> +gfp_t flag)
> >> {
> >> - kfree(buf->buf);
> >> +#ifdef CONFIG_HAS_DMA
> >> + if (virtio_has_feature(vdev, VIRTIO_CONSOLE_F_DMA_MEM)) {
> >> + struct device *dev = >dev;
> >> + /*
> >> + * Allocate DMA memory from ancestors. Finding the ancestor
> >> + * is a bit quirky when DMA_MEMORY_INCLUDES_CHILDREN is not
> >> + * implemented.
> >> + */
> >> + dev = dev->parent ? dev->parent : dev;
> >> + dev = dev->parent ? dev->parent : dev;
> >> + return dma_alloc_coherent(dev, size, dma_handle, flag);
> >> + }
> >> +#endif
> >
> > Are these ifdefs really needed? If DMA_MEM is set,
> > can't we use dma_alloc_coherent
> > unconditionally?
>
> If an architecture do not support DMA you will get
> a link error: "unknown symbol" for dma_alloc_coherent.
>
> Regards,
> Sjur
Yes, it even seems intentional.
But I have a question: can the device work without DMA?
Does not VIRTIO_CONSOLE_F_DMA_MEM mean dma api is required?
If yes you should just fail load.
Also let's add a wrapper at top of file so ifdefs
do not litter the code like this. For example:
#ifdef CONFIG_HAS_DMA
#define VIRTIO_CONSOLE_HAS_DMA (1)
#else
#define VIRTIO_CONSOLE_HAS_DMA (0)
#endif
Now use if instead of ifdef.
--
MST
--
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/4] watchdog: introduce retu_wdt driver
Introduce Retu watchdog driver.
Cc: linux-watch...@vger.kernel.org
Acked-by: Tony Lindgren
Signed-off-by: Aaro Koskinen
---
drivers/watchdog/Kconfig| 12 +++
drivers/watchdog/Makefile |1 +
drivers/watchdog/retu_wdt.c | 188 +++
3 files changed, 201 insertions(+), 0 deletions(-)
create mode 100644 drivers/watchdog/retu_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 53d7571..0526c7a 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -352,6 +352,18 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config RETU_WATCHDOG
+ tristate "Retu watchdog"
+ depends on MFD_RETU
+ select WATCHDOG_CORE
+ help
+ Retu watchdog driver for Nokia Internet Tablets (700, N800,
+ N810). At least on N800 the watchdog cannot be disabled, so
+ this driver is essential and you should enable it.
+
+ To compile this driver as a module, choose M here: the
+ module will be called retu_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 572b39b..d2f1c0c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_STMP3XXX_WATCHDOG) += stmp3xxx_wdt.o
obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/retu_wdt.c b/drivers/watchdog/retu_wdt.c
new file mode 100644
index 000..da9750a
--- /dev/null
+++ b/drivers/watchdog/retu_wdt.c
@@ -0,0 +1,188 @@
+/*
+ * Retu watchdog driver
+ *
+ * Copyright (C) 2004, 2005 Nokia Corporation
+ *
+ * Based on code written by Amit Kucheria and Michael Buesch. Rewritten
+ * to use Retu MFD driver and new watchdog core by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Watchdog timer values in seconds */
+#define RETU_WDT_MAX_TIMER 63
+
+struct retu_wdt_dev {
+ struct retu_dev *rdev;
+ struct device *dev;
+ struct delayed_work ping_work;
+};
+
+/*
+ * Since Retu watchdog cannot be disabled in hardware, we must kick it
+ * with a timer until userspace watchdog software takes over. If
+ * CONFIG_WATCHDOG_NOWAYOUT is set, we never start the feeding.
+ */
+static void retu_wdt_ping_enable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev->rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ schedule_delayed_work(>ping_work,
+ round_jiffies_relative(RETU_WDT_MAX_TIMER * HZ / 2));
+}
+
+static void retu_wdt_ping_disable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev->rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ cancel_delayed_work_sync(>ping_work);
+}
+
+static void retu_wdt_ping_work(struct work_struct *work)
+{
+ struct retu_wdt_dev *wdev = container_of(to_delayed_work(work),
+ struct retu_wdt_dev, ping_work);
+ retu_wdt_ping_enable(wdev);
+}
+
+static int retu_wdt_start(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_disable(wdev);
+
+ return retu_write(wdev->rdev, RETU_REG_WATCHDOG, wdog->timeout);
+}
+
+static int retu_wdt_stop(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_enable(wdev);
+
+ return 0;
+}
+
+static int retu_wdt_ping(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ return retu_write(wdev->rdev, RETU_REG_WATCHDOG, wdog->timeout);
+}
+
+static int retu_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int timeout)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ wdog->timeout = timeout;
+ return retu_write(wdev->rdev, RETU_REG_WATCHDOG, wdog->timeout);
+}
+
+static const struct watchdog_info retu_wdt_info = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
+ .identity = "Retu watchdog",
+};
+
+static const struct watchdog_ops retu_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = retu_wdt_start,
+ .stop = retu_wdt_stop,
+
[PATCH 0/4] cbus/retu drivers to mainline
This patch set introduces drivers for CBUS access and Retu multifunction chip found on Nokia Internet Tablets (770, N800, N810). It would be nice get these patches applied as the functionality of these devices is severely lacking without Retu. E.g. watchdog support is mandatory at least on Nokia N800, you cannot currently run the mainline kernel for longer than ~60 seconds (there is no way to disable the watchdog). Drivers originate from linux-omap cbus branch and have been cleaned up/rewritten around i2c and MFD core. Patches have been tested on top of 3.6-rc4 with Nokia N800 (watchdog feeding works, power off shuts down the device, power button triggers IRQs and input events). Changes since the RFC version (http://marc.info/?l=linux-omap=134618967116737=2): - added DT support for getting i2c-cbus GPIO pins - merged n8x0 board file changes into i2c-cbus patch - corrected typo in Kconfig for MFD_RETU - added power off functionality to retu-mfd - added IRQ functionality to retu-mfd - added power button key driver - some cleanups Aaro Koskinen (4): i2c: introduce i2c-cbus driver mfd: introduce retu-mfd driver watchdog: introduce retu_wdt driver input: misc: introduce retu-pwrbutton arch/arm/mach-omap2/board-n8x0.c| 42 drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile |1 + drivers/i2c/busses/i2c-cbus.c | 369 +++ drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile |1 + drivers/input/misc/retu-pwrbutton.c | 127 drivers/mfd/Kconfig |8 + drivers/mfd/Makefile|1 + drivers/mfd/retu-mfd.c | 347 drivers/watchdog/Kconfig| 12 ++ drivers/watchdog/Makefile |1 + drivers/watchdog/retu_wdt.c | 188 ++ include/linux/i2c-cbus.h| 27 +++ include/linux/mfd/retu.h| 22 ++ 15 files changed, 1166 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/busses/i2c-cbus.c create mode 100644 drivers/input/misc/retu-pwrbutton.c create mode 100644 drivers/mfd/retu-mfd.c create mode 100644 drivers/watchdog/retu_wdt.c create mode 100644 include/linux/i2c-cbus.h create mode 100644 include/linux/mfd/retu.h -- 1.7.2.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 2/4] mfd: introduce retu-mfd driver
Retu is a multi-function device found on Nokia Internet Tablets
implementing at least watchdog, RTC, headset detection and power button
functionality.
This patch implements minimum functionality providing register access,
IRQ handling and power off functions.
Cc: sa...@linux.intel.com
Acked-by: Tony Lindgren
Signed-off-by: Aaro Koskinen
---
drivers/mfd/Kconfig |8 +
drivers/mfd/Makefile |1 +
drivers/mfd/retu-mfd.c | 347 ++
include/linux/mfd/retu.h | 22 +++
4 files changed, 378 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/retu-mfd.c
create mode 100644 include/linux/mfd/retu.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b1a1462..7d4ce92 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1003,6 +1003,14 @@ config MFD_PALMAS
If you say yes here you get support for the Palmas
series of PMIC chips from Texas Instruments.
+config MFD_RETU
+ tristate "Support for Retu multi-function device"
+ select MFD_CORE
+ depends on I2C
+ help
+ Retu is a multi-function device found on Nokia Internet Tablets
+ (770, N800 and N810).
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..962ec9d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -132,3 +132,4 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
+obj-$(CONFIG_MFD_RETU) += retu-mfd.o
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
new file mode 100644
index 000..99059d3
--- /dev/null
+++ b/drivers/mfd/retu-mfd.c
@@ -0,0 +1,347 @@
+/*
+ * Retu MFD driver
+ *
+ * Copyright (C) 2004, 2005 Nokia Corporation
+ *
+ * Based on code written by Juha Yrjölä, David Weinehall and Mikko Ylinen.
+ * Rewritten to MFD/I2C driver by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Registers */
+#define RETU_REG_ASICR 0x00/* ASIC ID and revision */
+#define RETU_REG_ASICR_VILMA (1 << 7)/* Bit indicating Vilma */
+#define RETU_REG_IDR 0x01/* Interrupt ID */
+#define RETU_REG_IMR 0x02/* Interrupt mask */
+
+/* Interrupt sources */
+#define RETU_INT_PWR 0 /* Power button */
+
+#define RETU_MAX_IRQ_HANDLERS 16
+
+struct retu_dev {
+ struct device *dev;
+ struct i2c_client *i2c;
+ struct mutexmutex;
+
+ struct irq_chip irq_chip;
+ int irq_base;
+ int irq_end;
+ int irq_mask;
+ boolirq_mask_pending;
+};
+
+static struct resource retu_pwrbutton_res[] = {
+ {
+ .name = "retu-pwrbutton",
+ .start = RETU_INT_PWR,
+ .end= RETU_INT_PWR,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct mfd_cell retu_devs[] = {
+ {
+ .name = "retu-wdt"
+ },
+ {
+ .name = "retu-pwrbutton",
+ .resources = _pwrbutton_res[0],
+ .num_resources = ARRAY_SIZE(retu_pwrbutton_res),
+ }
+};
+
+/* Retu device registered for the power off. */
+static struct retu_dev *retu_pm_power_off;
+
+int retu_read(struct retu_dev *rdev, u8 reg)
+{
+ int ret;
+
+ mutex_lock(>mutex);
+ ret = i2c_smbus_read_word_data(rdev->i2c, reg);
+ mutex_unlock(>mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(retu_read);
+
+int retu_write(struct retu_dev *rdev, u8 reg, u16 data)
+{
+ int ret;
+
+ mutex_lock(>mutex);
+ ret = i2c_smbus_write_word_data(rdev->i2c, reg, data);
+ mutex_unlock(>mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(retu_write);
+
+static void retu_power_off(void)
+{
+ struct retu_dev *rdev = retu_pm_power_off;
+ int reg;
+
+ mutex_lock(_pm_power_off->mutex);
+
+ /* Ignore power button state */
+ reg = i2c_smbus_read_word_data(rdev->i2c, RETU_REG_CC1);
+ i2c_smbus_write_word_data(rdev->i2c, RETU_REG_CC1, reg | 2);
+
+ /* Expire watchdog immediately */
+ i2c_smbus_write_word_data(rdev->i2c, RETU_REG_WATCHDOG, 0);
+
+ /* Wait for poweroff
[PATCH 4/4] input: misc: introduce retu-pwrbutton
Add Retu power button driver.
Cc: linux-in...@vger.kernel.org
Signed-off-by: Aaro Koskinen
---
drivers/input/misc/Kconfig | 10 +++
drivers/input/misc/Makefile |1 +
drivers/input/misc/retu-pwrbutton.c | 127 +++
3 files changed, 138 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/retu-pwrbutton.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7c0f1ec..e5be189 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -367,6 +367,16 @@ config INPUT_CM109
To compile this driver as a module, choose M here: the module will be
called cm109.
+config INPUT_RETU_PWRBUTTON
+ tristate "Retu Power button Driver"
+ depends on MFD_RETU
+ help
+ Say Y here if you want to enable power key reporting via the
+ Retu chips found in Nokia Internet Tablets (770, N800, N810).
+
+ To compile this driver as a module, choose M here. The module will
+ be called retu-pwrbutton.
+
config INPUT_TWL4030_PWRBUTTON
tristate "TWL4030 Power button Driver"
depends on TWL4030_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 83fe6f5..4fbee0d 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
+obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SPARCSPKR) += sparcspkr.o
diff --git a/drivers/input/misc/retu-pwrbutton.c
b/drivers/input/misc/retu-pwrbutton.c
new file mode 100644
index 000..f802d4d
--- /dev/null
+++ b/drivers/input/misc/retu-pwrbutton.c
@@ -0,0 +1,127 @@
+/*
+ * Retu power button driver.
+ *
+ * Copyright (C) 2004-2010 Nokia Corporation
+ *
+ * Original code written by Ari Saastamoinen, Juha Yrjölä and Felipe Balbi.
+ * Converted to use to use Retu MFD driver by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RETU_STATUS_PWRONX (1 << 5)
+
+struct retu_pwrbutton {
+ struct input_dev*idev;
+ struct retu_dev *rdev;
+ struct device *dev;
+ boolpressed;
+ int irq;
+};
+
+static irqreturn_t retu_pwrbutton_irq(int irq, void *_pwr)
+{
+ struct retu_pwrbutton *pwr = _pwr;
+ bool state;
+
+ state = !(retu_read(pwr->rdev, RETU_REG_STATUS) & RETU_STATUS_PWRONX);
+
+ if (pwr->pressed != state) {
+ input_report_key(pwr->idev, KEY_POWER, state);
+ input_sync(pwr->idev);
+ pwr->pressed = state;
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int __devinit retu_pwrbutton_probe(struct platform_device *pdev)
+{
+ struct retu_dev *rdev = dev_get_drvdata(pdev->dev.parent);
+ struct retu_pwrbutton *pwr;
+ int ret;
+
+ pwr = kzalloc(sizeof(*pwr), GFP_KERNEL);
+ if (!pwr)
+ return -ENOMEM;
+
+ pwr->rdev = rdev;
+ pwr->dev = >dev;
+ pwr->irq = platform_get_irq(pdev, 0);
+ platform_set_drvdata(pdev, pwr);
+
+ ret = request_threaded_irq(pwr->irq, NULL, retu_pwrbutton_irq, 0,
+ "retu-pwrbutton", pwr);
+ if (ret < 0)
+ goto error_irq;
+
+ pwr->idev = input_allocate_device();
+ if (!pwr->idev) {
+ ret = -ENOMEM;
+ goto error_input;
+ }
+
+ pwr->idev->evbit[0] = BIT_MASK(EV_KEY);
+ pwr->idev->keybit[BIT_WORD(KEY_POWER)] = BIT_MASK(KEY_POWER);
+ pwr->idev->name = "retu-pwrbutton";
+
+ ret = input_register_device(pwr->idev);
+ if (ret < 0)
+ goto error_reg;
+
+ return 0;
+
+error_reg:
+ input_free_device(pwr->idev);
+error_input:
+ free_irq(pwr->irq, pwr);
+error_irq:
+ kfree(pwr);
+ return ret;
+}
+
+static int __devexit retu_pwrbutton_remove(struct platform_device *pdev)
+{
+ struct retu_pwrbutton *pwr = platform_get_drvdata(pdev);
+
+ free_irq(pwr->irq, pwr);
+ input_unregister_device(pwr->idev);
+
[PATCH 1/4] i2c: introduce i2c-cbus driver
Add i2c driver to enable access to devices behind CBUS on Nokia Internet
Tablets.
The patch also adds CBUS I2C configuration for N8x0 which is one of the
users of this driver.
Cc: linux-...@vger.kernel.org
Acked-by: Felipe Balbi
Acked-by: Tony Lindgren
Signed-off-by: Aaro Koskinen
---
arch/arm/mach-omap2/board-n8x0.c | 42 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-cbus.c| 369 ++
include/linux/i2c-cbus.h | 27 +++
5 files changed, 449 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-cbus.c
create mode 100644 include/linux/i2c-cbus.h
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 677357f..2495f2d 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -16,8 +16,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -42,6 +44,45 @@
#define TUSB6010_GPIO_ENABLE 0
#define TUSB6010_DMACHAN 0x3f
+#if defined(CONFIG_I2C_CBUS) || defined(CONFIG_I2C_CBUS_MODULE)
+static struct i2c_cbus_platform_data n8x0_cbus_data = {
+ .clk_gpio = 66,
+ .dat_gpio = 65,
+ .sel_gpio = 64,
+};
+
+static struct platform_device n8x0_cbus_device = {
+ .name = "i2c-cbus",
+ .id = 3,
+ .dev= {
+ .platform_data = _cbus_data,
+ },
+};
+
+static struct i2c_board_info n8x0_i2c_board_info_3[] __initdata = {
+ {
+ I2C_BOARD_INFO("retu-mfd", 0x01),
+ },
+};
+
+static void __init n8x0_cbus_init(void)
+{
+ const int retu_irq_gpio = 108;
+
+ if (gpio_request_one(retu_irq_gpio, GPIOF_IN, "Retu IRQ"))
+ return;
+ irq_set_irq_type(gpio_to_irq(retu_irq_gpio), IRQ_TYPE_EDGE_RISING);
+ n8x0_i2c_board_info_3[0].irq = gpio_to_irq(retu_irq_gpio);
+ i2c_register_board_info(3, n8x0_i2c_board_info_3,
+ ARRAY_SIZE(n8x0_i2c_board_info_3));
+ platform_device_register(_cbus_device);
+}
+#else /* CONFIG_I2C_CBUS */
+static void __init n8x0_cbus_init(void)
+{
+}
+#endif /* CONFIG_I2C_CBUS */
+
#if defined(CONFIG_USB_MUSB_TUSB6010) ||
defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
/*
* Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
@@ -681,6 +722,7 @@ static void __init n8x0_init_machine(void)
gpmc_onenand_init(board_onenand_data);
n8x0_mmc_init();
n8x0_usb_init();
+ n8x0_cbus_init();
}
MACHINE_START(NOKIA_N800, "Nokia N800")
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b4aaa1b..184ef43 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -331,6 +331,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
help
The unit of the TWI clock is kHz.
+config I2C_CBUS
+ tristate "CBUS I2C driver"
+ depends on GENERIC_GPIO
+ help
+ Support for CBUS access using I2C API. Mostly relevant for Nokia
+ Internet Tablets (770, N800 and N810).
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-cbus.
+
config I2C_CPM
tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)"
depends on (CPM1 || CPM2) && OF_I2C
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index ce3c2be..44dbfd1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_I2C_POWERMAC)+= i2c-powermac.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
+obj-$(CONFIG_I2C_CBUS) += i2c-cbus.o
obj-$(CONFIG_I2C_CPM) += i2c-cpm.o
obj-$(CONFIG_I2C_DAVINCI) += i2c-davinci.o
obj-$(CONFIG_I2C_DESIGNWARE_PLATFORM) += i2c-designware-platform.o
diff --git a/drivers/i2c/busses/i2c-cbus.c b/drivers/i2c/busses/i2c-cbus.c
new file mode 100644
index 000..bacf2a9
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cbus.c
@@ -0,0 +1,369 @@
+/*
+ * CBUS I2C driver for Nokia Internet Tablets.
+ *
+ * Copyright (C) 2004-2010 Nokia Corporation
+ *
+ * Based on code written by Juha Yrjölä, David Weinehall, Mikko Ylinen and
+ * Felipe Balbi. Converted to I2C driver by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct cbus_host {
+ /* host
[PATCH RESEND] video: Remove pnx4008 driver
This patch removes the video driver for pnx4008. The architecture is being removed via the arm-soc tree. Signed-off-by: Roland Stigge Acked-by: Arnd Bergmann --- Applies to v3.6-rc4 drivers/video/Kconfig| 15 drivers/video/Makefile |2 drivers/video/pnx4008/Makefile |7 drivers/video/pnx4008/dum.h | 211 - drivers/video/pnx4008/fbcommon.h | 43 - drivers/video/pnx4008/pnxrgbfb.c | 198 drivers/video/pnx4008/sdum.c | 861 --- drivers/video/pnx4008/sdum.h | 136 -- 8 files changed, 1473 deletions(-) --- linux-2.6.orig/drivers/video/Kconfig +++ linux-2.6/drivers/video/Kconfig @@ -2151,21 +2151,6 @@ config FB_UDL mplayer -vo fbdev. Supports all USB 2.0 era DisplayLink devices. To compile as a module, choose M here: the module name is udlfb. -config FB_PNX4008_DUM - tristate "Display Update Module support on Philips PNX4008 board" - depends on FB && ARCH_PNX4008 - ---help--- - Say Y here to enable support for PNX4008 Display Update Module (DUM) - -config FB_PNX4008_DUM_RGB - tristate "RGB Framebuffer support on Philips PNX4008 board" - depends on FB_PNX4008_DUM - select FB_CFB_FILLRECT - select FB_CFB_COPYAREA - select FB_CFB_IMAGEBLIT - ---help--- - Say Y here to enable support for PNX4008 RGB Framebuffer - config FB_IBM_GXT4500 tristate "Framebuffer support for IBM GXT4500P adaptor" depends on FB && PPC --- linux-2.6.orig/drivers/video/Makefile +++ linux-2.6/drivers/video/Makefile @@ -128,8 +128,6 @@ obj-$(CONFIG_FB_S3C) += s3c-fb.o obj-$(CONFIG_FB_S3C2410) += s3c2410fb.o obj-$(CONFIG_FB_FSL_DIU) += fsl-diu-fb.o obj-$(CONFIG_FB_COBALT) += cobalt_lcdfb.o -obj-$(CONFIG_FB_PNX4008_DUM) += pnx4008/ -obj-$(CONFIG_FB_PNX4008_DUM_RGB) += pnx4008/ obj-$(CONFIG_FB_IBM_GXT4500) += gxt4500.o obj-$(CONFIG_FB_PS3) += ps3fb.o obj-$(CONFIG_FB_SM501)+= sm501fb.o --- linux-2.6.orig/drivers/video/pnx4008/Makefile +++ /dev/null @@ -1,7 +0,0 @@ -# -# Makefile for the new PNX4008 framebuffer device driver -# - -obj-$(CONFIG_FB_PNX4008_DUM) += sdum.o -obj-$(CONFIG_FB_PNX4008_DUM_RGB) += pnxrgbfb.o - --- linux-2.6.orig/drivers/video/pnx4008/dum.h +++ /dev/null @@ -1,211 +0,0 @@ -/* - * linux/drivers/video/pnx4008/dum.h - * - * Internal header for SDUM - * - * 2005 (c) Koninklijke Philips N.V. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. - */ - -#ifndef __PNX008_DUM_H__ -#define __PNX008_DUM_H__ - -#include - -#define PNX4008_DUMCONF_VA_BASEIO_ADDRESS(PNX4008_DUMCONF_BASE) -#define PNX4008_DUM_MAIN_VA_BASE IO_ADDRESS(PNX4008_DUM_MAINCFG_BASE) - -/* DUM CFG ADDRESSES */ -#define DUM_CH_BASE_ADR(PNX4008_DUMCONF_VA_BASE + 0x00) -#define DUM_CH_MIN_ADR (PNX4008_DUMCONF_VA_BASE + 0x00) -#define DUM_CH_MAX_ADR (PNX4008_DUMCONF_VA_BASE + 0x04) -#define DUM_CH_CONF_ADR(PNX4008_DUMCONF_VA_BASE + 0x08) -#define DUM_CH_STAT_ADR(PNX4008_DUMCONF_VA_BASE + 0x0C) -#define DUM_CH_CTRL_ADR(PNX4008_DUMCONF_VA_BASE + 0x10) - -#define CH_MARG(0x100 / sizeof(u32)) -#define DUM_CH_MIN(i) (*((volatile u32 *)DUM_CH_MIN_ADR + (i) * CH_MARG)) -#define DUM_CH_MAX(i) (*((volatile u32 *)DUM_CH_MAX_ADR + (i) * CH_MARG)) -#define DUM_CH_CONF(i) (*((volatile u32 *)DUM_CH_CONF_ADR + (i) * CH_MARG)) -#define DUM_CH_STAT(i) (*((volatile u32 *)DUM_CH_STAT_ADR + (i) * CH_MARG)) -#define DUM_CH_CTRL(i) (*((volatile u32 *)DUM_CH_CTRL_ADR + (i) * CH_MARG)) - -#define DUM_CONF_ADR (PNX4008_DUM_MAIN_VA_BASE + 0x00) -#define DUM_CTRL_ADR (PNX4008_DUM_MAIN_VA_BASE + 0x04) -#define DUM_STAT_ADR (PNX4008_DUM_MAIN_VA_BASE + 0x08) -#define DUM_DECODE_ADR(PNX4008_DUM_MAIN_VA_BASE + 0x0C) -#define DUM_COM_BASE_ADR (PNX4008_DUM_MAIN_VA_BASE + 0x10) -#define DUM_SYNC_C_ADR(PNX4008_DUM_MAIN_VA_BASE + 0x14) -#define DUM_CLK_DIV_ADR (PNX4008_DUM_MAIN_VA_BASE + 0x18) -#define DUM_DIRTY_LOW_ADR (PNX4008_DUM_MAIN_VA_BASE + 0x20) -#define DUM_DIRTY_HIGH_ADR(PNX4008_DUM_MAIN_VA_BASE + 0x24) -#define DUM_FORMAT_ADR(PNX4008_DUM_MAIN_VA_BASE + 0x28) -#define DUM_WTCFG1_ADR(PNX4008_DUM_MAIN_VA_BASE + 0x30) -#define DUM_RTCFG1_ADR(PNX4008_DUM_MAIN_VA_BASE + 0x34) -#define DUM_WTCFG2_ADR(PNX4008_DUM_MAIN_VA_BASE + 0x38) -#define DUM_RTCFG2_ADR(PNX4008_DUM_MAIN_VA_BASE + 0x3C) -#define DUM_TCFG_ADR (PNX4008_DUM_MAIN_VA_BASE + 0x40) -#define DUM_OUTP_FORMAT1_ADR (PNX4008_DUM_MAIN_VA_BASE + 0x44) -#define DUM_OUTP_FORMAT2_ADR (PNX4008_DUM_MAIN_VA_BASE + 0x48) -#define DUM_SYNC_MODE_ADR (PNX4008_DUM_MAIN_VA_BASE + 0x4C)
Re: [PATCH] virtio: Don't access device data after unregistration.
On Mon, Sep 03, 2012 at 04:50:10PM +0200, Sjur Brændeland wrote:
> Hi Michael,
>
> >> Fix panic in virtio.c when CONFIG_DEBUG_SLAB is set.
> >
> > What's the root cause of the panic?
>
> I believe the cause of the panic is calling
> ida_simple_remove(_index_ida, dev->index);
> when the dev structure is "poisoned" after kfree.
> It might be the "BUG_ON((int)id < 0)" that bites...
>
> >> Use device_del() and put_device() instead of
> >> device_unregister(), and access device data before
> >> calling put_device().
>
> > Why does this help? Does device_unregister free the
> > device so dev->index access crashes?
>
> Yes, if device ref-count is one when calling unregister
> the device is freed.
Interesting. Where exactly? Note that:
struct rproc_vdev {
struct list_head node;
struct rproc *rproc;
struct virtio_device vdev;
struct rproc_vring vring[RVDEV_NUM_VRINGS];
unsigned long dfeatures;
unsigned long gfeatures;
};
kfree(_vdev->vdev) is unlikely to be the right thing to do.
> > If yes virtio_pci_remove will crash too
> > as it accesses the device after the
> > call to unregister_virtio_device so the
> > fix won't be effective.
>
> I discovered this using the remoteproc framework.
> It might be that device is unregistered with ref-count greater
> than one normally, in that case this bug will not show up.
>
> Regards,
> Sjur
It might be remoteproc has an unrelated bug?
--
MST
--
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 RESEND 1/2] i2c: pnx: Fix bit definitions
Hi Wolfram, On 20/08/12 19:55, Wolfram Sang wrote: >> I've never had my hands on a PNX4008 chip at NXP, but I do >> believe they are the same IP. That specific I2C IP was used in a >> number of NXP/Phillips chips besides the PNX4008/LPC32xx. I don't >> think there are any PNX4008's in the wild, and even working in >> NXP, I can't find any non-marketing reference material for that >> part (including the user manual). > > Thanks for the heads up. I'll apply both patches, then. Should I consider the two patches as applied now (where? i2c-embedded?), or should I resend? ;-) Thanks in advance, Roland -- 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] Fix uninitialized variable in ath6kl ath6kl_sdio_enable_scatter
gcc 4.8 warns
/backup/lsrc/git/linux-lto-2.6/drivers/net/wireless/ath/ath6kl/sdio.c:
In function 'ath6kl_sdio_enable_scatter':
/backup/lsrc/git/linux-lto-2.6/drivers/net/wireless/ath/ath6kl/sdio.c:748:16:
warning: 'ret' may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (virt_scat || ret) {
^
The variable can indeed be uninitialized when the previous if branch is
skipped. I just set it to zero for now. I'm not fully sure the fix is
correct, maybe the || should be an && ?
Signed-off-by: Andi Kleen
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c
b/drivers/net/wireless/ath/ath6kl/sdio.c
index 05b9540..f495899 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -709,7 +709,7 @@ static int ath6kl_sdio_enable_scatter(struct ath6kl *ar)
{
struct ath6kl_sdio *ar_sdio = ath6kl_sdio_priv(ar);
struct htc_target *target = ar->htc_target;
- int ret;
+ int ret = 0;
bool virt_scat = false;
if (ar_sdio->scatter_enabled)
--
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: western digital caviar black. EXT4-fs error
Anybody? On Sat, Sep 1, 2012 at 11:53 PM, Azat Khuzhin wrote: > I'v also post question here > > http://serverfault.com/questions/423565/western-digital-caviar-black-ext4-fs-error > > On Sat, Sep 1, 2012 at 11:48 PM, Azat Khuzhin wrote: >> Recently I update my HDD on desktop machine, and bought WD Caviar Black. >> But after I format & copy information to it (using dd), and fix >> partitions size: I have next errors in kern.log: >> >> Aug 28 01:49:03 home-spb kernel: [183245.030897] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 3675, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:03 home-spb kernel: [183245.030956] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 4181, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:03 home-spb kernel: [183245.030980] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 2600, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:03 home-spb kernel: [183245.061866] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 9305, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:03 home-spb kernel: [183245.061892] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 8230, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:40 home-spb kernel: [183281.733813] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 2477, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:49:40 home-spb kernel: [183281.743131] JBD2: Spotted dirty >> metadata buffer (dev = sdc2, blocknr = 0). There's a risk of >> filesystem corruption in case of system crash. >> Aug 28 01:50:13 home-spb kernel: [183314.898637] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 3139, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:50:58 home-spb kernel: [183359.783544] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 4061, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:50:58 home-spb kernel: [183359.783577] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 8166, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 01:51:08 home-spb kernel: [183369.757927] EXT4-fs error (device >> sdc2): ext4_mb_generate_buddy:739: group 8171, 32254 clusters in >> bitmap, 32258 in gd >> Aug 28 16:06:54 home-spb kernel: [234584.906721] EXT4-fs (sdc2): error >> count: 26 >> Aug 28 16:06:54 home-spb kernel: [234584.906725] EXT4-fs (sdc2): >> initial error at 1346069075: ext4_mb_generate_buddy:739 >> Aug 28 16:06:54 home-spb kernel: [234584.906727] EXT4-fs (sdc2): last >> error at 1346104268: ext4_mb_generate_buddy:739 >> >> One time, machine rebooted (not manually), when I turn it on, it runs >> fsck on /dev/sdc2 and fix some errors and some files are missing on >> /dev/sdc2 >> >> I'v check /dev/sdc2 for badblocks, it doesn't have it ( using e2fsck >> -c /dev/sdc2 ) >> Here is the output of fsck http://pastebin.com/D5LmLVBY >> >> What else I can do to understand what's wrong here? >> >> BTW for /dev/sdc1 no message like that, in kern.log >> >> Linux version: 3.3.0 >> Distributive: Debian wheezy >> >> -- >> Azat Khuzhin > > > > -- > Azat Khuzhin -- Azat Khuzhin -- 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 bogus memcpy in brcm80211 ai_detach
On 09/03/2012 02:57 PM, Andi Kleen wrote: On Mon, Sep 03, 2012 at 02:22:48PM -0500, Larry Finger wrote: Have you compiled all of wireless with gcc 4.8? If so, can I assume that you will report warnings for other drivers? I did 64bit allyesconfig with LTO yes. wireless has very few warnings overall, compared to many other subsystems. I found one other issue in it for which I'm sending a patch. Thanks for responding, and for doing the cleanup. Larry -- 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 08/13] perf tools: Use __maybe_used for unused variables
On Mon, Sep 3, 2012 at 4:07 AM, Namhyung Kim wrote: > Hi, Hi, > > On Wed, 29 Aug 2012 01:04:25 +0300, Irina Tirdea wrote: >> perf defines __used to for marking unused variables. >> The variable __used is defined to __attribute__((__unused__)), which >> contradicts the kernel definition to __attribute__((__used__)) >> for new gcc versions. On Android), __used is also defined in >> system headers and this leads to warnings like: >> warning: '__used__' attribute ignored >> >> This patch simply replaces all instances of __used with __maybe_unused >> so there will be no such warnings. > > How about just using '__unused' for less typing? Replacing __used with __unused leads to conflicts with glibc headers, since glibc has a variable named __unused in the stat.h header. I forgot to mention this in the commit message. This is the error: In file included from /usr/include/x86_64-linux-gnu/sys/stat.h:107:0, from util/util.h:48, from builtin-bench.c:20: /usr/include/x86_64-linux-gnu/bits/stat.h:106:22: error: expected identifier or ‘(’ before ‘[’ token /usr/include/x86_64-linux-gnu/bits/stat.h:167:22: error: expected identifier or ‘(’ before ‘[’ token make: *** [builtin-bench.o] Error 1 > Btw, the patch looks whitespace-damaged. That's true. I'll fix it. Thanks, Irina -- 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 bogus memcpy in brcm80211 ai_detach
On Mon, Sep 03, 2012 at 02:22:48PM -0500, Larry Finger wrote: > On 09/03/2012 02:13 PM, Andi Kleen wrote: > >gcc 4.8 warns for this memcpy. While the copy size is correct, the whole > >copy seems to be a nop because the destination is never used, and > >there's no need to use memcpy to copy pointers anyways. And the > >type of the pointer was wrong, but at least those are always the same. > > > >Just remove it. > > Andi, > > Have you compiled all of wireless with gcc 4.8? If so, can I assume that > you will report warnings for other drivers? I did 64bit allyesconfig with LTO yes. wireless has very few warnings overall, compared to many other subsystems. I found one other issue in it for which I'm sending a patch. -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: [PATCH] staging/ozwpan: Fix zero address check in oz_set_active_pd
> Its already fixed by this patch :- > > http://driverdev.linuxdriverproject.org/pipermail/devel/2012-August/029734.html Should be in 3.6 then as it's a bug fix. -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: when the MTU interface is modified, the promiscuous mode is reset in gianfar driver
From: chikazawa.ak...@jp.fujitsu.com (近沢 哲史) Date: Mon, 27 Aug 2012 17:38:34 +0900 > I am using the gianfar ethernet driver. I am having a problem with the > interface settings. > Under promiscuous mode, when the MTU interface is modified, the promiscuous > mode setting is turned off in gianfar driver when it should not be. > The details are as follows: > After changing MTU with ifconfig, I could see that the interface flag of > eth0 is still PROMISC. > However, when I checked value of RCTL register with ethtool, PROM bit of > RTCL register is cleared. > It seems to be cause that is the gfar_init_mac() function, it doesn't set > the PROM bit after the interface MTU is changed. > This problem was detected on linux-2.6.32.2, but it seems to same on > linux-3.6.0-rc3. > Is this behavior on purpose? > > I also attach the amended file,I think it would be so. > > Signed-off-by: Akifumi Chikazawa It seems like we also lose all of the multicast configurations as well. Therefore, the thing to do is to simply call gfar_set_multi() at the appropriate location. That will take care of both the promiscuous bit, as well as the multicast addresses. You can then remove some of the code in gfar_init_mac() that does things like gfar_clear_exact_match(), because gfar_set_multi() will take care of that if necessary. -- 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/9] pinctrl: mvebu: pinctrl driver core
On Sun, Sep 02, 2012 at 10:27:29AM +0200, Sebastian Hesselbarth wrote: > Maybe Jason can also comment on what branch he wants to have it based > on, as we all agreed to get it through the Marvell tree. Please base against: git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2 thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging/ozwpan: Fix zero address check in oz_set_active_pd
On 03/09/12 20:17, Andi Kleen wrote:
gcc 4.8 warns about the incorrect memcmp size. I think it's supposed to
be an ethernet address, so should be always 6 bytes.
The code was wrong, would either compare 4 or 8 bytes (32bit vs 64bit)
/backup/lsrc/git/linux-lto-2.6/drivers/staging/ozwpan/ozcdev.c: In function
'oz_set_active_pd':
/backup/lsrc/git/linux-lto-2.6/drivers/staging/ozwpan/ozcdev.c:216:43: warning:
argument to 'sizeof' in 'memcmp' call is the same expression as the
destination; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]
if (!memcmp(addr, "\0\0\0\0\0\0", sizeof(addr))) {
^
Signed-off-by: Andi Kleen
diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c
index d983219..63c1b67 100644
--- a/drivers/staging/ozwpan/ozcdev.c
+++ b/drivers/staging/ozwpan/ozcdev.c
@@ -213,7 +213,7 @@ static int oz_set_active_pd(u8 *addr)
if (old_pd)
oz_pd_put(old_pd);
} else {
- if (!memcmp(addr, "\0\0\0\0\0\0", sizeof(addr))) {
+ if (!memcmp(addr, "\0\0\0\0\0\0", ETH_ALEN)) {
spin_lock_bh(_cdev.lock);
pd = g_cdev.active_pd;
g_cdev.active_pd = 0;
Its already fixed by this patch :-
http://driverdev.linuxdriverproject.org/pipermail/devel/2012-August/029734.html
--
Regards,
Rupesh Gujare
--
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] media: v4l2-ctrls: add control for test pattern
Hi Prabhakar, Thanks for the patch. On Mon, Sep 03, 2012 at 02:46:17PM +0530, Prabhakar Lad wrote: > From: Lad, Prabhakar > > add V4L2_CID_TEST_PATTERN of type menu, which determines > the internal test pattern selected by the device. > > Signed-off-by: Lad, Prabhakar > Signed-off-by: Manjunath Hadli > Cc: Sakari Ailus > Cc: Hans Verkuil > Cc: Laurent Pinchart > Cc: Mauro Carvalho Chehab > Cc: Sylwester Nawrocki > Cc: Hans de Goede > Cc: Kyungmin Park > Cc: Rob Landley > Cc: HeungJun Kim > Cc: Rob Landley > --- > This patches has one checkpatch warning for line over > 80 characters altough it can be avoided I have kept it > for consistency. > > Documentation/DocBook/media/v4l/controls.xml | 52 > ++ > drivers/media/v4l2-core/v4l2-ctrls.c | 16 > include/linux/videodev2.h| 12 ++ > 3 files changed, 80 insertions(+), 0 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > b/Documentation/DocBook/media/v4l/controls.xml > index f704218..06f16e7 100644 > --- a/Documentation/DocBook/media/v4l/controls.xml > +++ b/Documentation/DocBook/media/v4l/controls.xml > @@ -4313,6 +4313,58 @@ interface and may change in the future. > > > > + > + spanname="id">V4L2_CID_TEST_PATTERN > + menu > + > + > + The capture devices/sensors have the > capability to > + generate internal test patterns. This test patterns are used to > test a device > + is properly working and can generate the desired waveforms that it > supports. > + > + > + > + > + > + > + V4L2_TEST_PATTERN_DISABLED > + Test pattern generation is disabled > + > + > + > V4L2_TEST_PATTERN_VERTICAL_LINES > + Generate vertical lines as test pattern > + > + > + > V4L2_TEST_PATTERN_HORIZONTAL_LINES > + Generate horizontal lines as test pattern > + > + > + > V4L2_TEST_PATTERN_DIAGONAL_LINES > + Generate diagonal lines as test pattern > + > + > + > V4L2_TEST_PATTERN_SOLID_BLACK > + Generate solid black color as test pattern > + > + > + > V4L2_TEST_PATTERN_SOLID_WHITE > + Generate solid white color as test pattern > + > + > + > V4L2_TEST_PATTERN_SOLID_BLUE > + Generate solid blue color as test pattern > + > + > + > V4L2_TEST_PATTERN_SOLID_RED > + Generate solid red color as test pattern > + > + > + > V4L2_TEST_PATTERN_CHECKER_BOARD > + Generate a checker board as test pattern > + You're defining 8 different test patterns based on a single device, I guess? As the test patterns are not standardised, I'd suppose that if another driver implements the same control, it would require another n menu items added to the same standard menu. That way we'd run quickly out of menu items as the maximum is 32. For this reason I'd leave the items in the menu up to the driver that implements the control, until we have more information on the test patterns different devices implement --- as discussed earlier. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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 RESEND] usb: ohci: Fix Kconfig dependency on USB_ISP1301
With "select USB_ISP1301 ...", it could happen that I2C isn't selected although USB_ISP1301 depends on it. Fixing with "depends on ..." and emulating the condition via "|| !()". Signed-off-by: Roland Stigge Acked-by: Alan Stern --- drivers/usb/host/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.orig/drivers/usb/host/Kconfig +++ linux-2.6/drivers/usb/host/Kconfig @@ -292,7 +292,7 @@ config USB_OHCI_HCD depends on USB && USB_ARCH_HAS_OHCI select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 select USB_OTG_UTILS if ARCH_OMAP - select USB_ISP1301 if ARCH_LPC32XX + depends on USB_ISP1301 || !ARCH_LPC32XX ---help--- The Open Host Controller Interface (OHCI) is a standard for accessing USB 1.1 host controller hardware. It does more in hardware than Intel's -- 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] ARM: S3C24XX: Add WIZnet W5300E01-ARM board support
On 09/03/2012 07:36 PM, Taehun Kim wrote:
> +static void __init w5300e01_init(void)
> +{
> + s3c_nand_set_platdata(_nand_info);
> + platform_add_devices(w5300e01_devices, ARRAY_SIZE(w5300e01_devices));
> +
> + /* W5300 interrupt pin. */
> + s3c_gpio_cfgpin(S3C2410_GPF(0), S3C2410_GPIO_IRQ);
> +
> + s3c_gpio_cfgpin(S3C2410_GPF(4), S3C2410_GPIO_OUTPUT);
> + s3c_gpio_cfgpin(S3C2410_GPF(5), S3C2410_GPIO_OUTPUT);
> + s3c_gpio_cfgpin(S3C2410_GPF(6), S3C2410_GPIO_OUTPUT);
> + s3c_gpio_cfgpin(S3C2410_GPF(7), S3C2410_GPIO_OUTPUT);
Please don't use these obsolete S3C2410_GPIO_* defines, they will be
gone soon, if aren't yet.
> + gpio_set_value(S3C2410_GPF(0), 1);
> + gpio_set_value(S3C2410_GPF(4), 1);
> + gpio_set_value(S3C2410_GPF(5), 1);
> + gpio_set_value(S3C2410_GPF(6), 1);
> + gpio_set_value(S3C2410_GPF(7), 1);
Instead I would do something like:
8<-
static const struct gpio gpios[] = {
{ S3C2410_GPF(4), GPIOF_OUT_INIT_HIGH, NULL },
{ S3C2410_GPF(5), GPIOF_OUT_INIT_HIGH, NULL },
{ S3C2410_GPF(6), GPIOF_OUT_INIT_HIGH, NULL },
{ S3C2410_GPF(7), GPIOF_OUT_INIT_HIGH, NULL },
};
if (!WARN_ON(gpio_request_array(gpios, ARRAY_SIZE(gpios)))
gpios_free_array(gpios);
/* W5300 interrupt pin. */
if (!WARN_ON(gpio_request(S3C2410_GPF(0), GPIOF_IN, NULL))) {
s3c_gpio_cfgpin(S3C2410_GPF(0), S3C_GPIO_SFN(2)); /* EINT0 */
gpio_free(S3C2410_GPF(0));
}
8<-
--
Regards,
Sylwester
--
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 bogus memcpy in brcm80211 ai_detach
On 09/03/2012 02:13 PM, Andi Kleen wrote: gcc 4.8 warns for this memcpy. While the copy size is correct, the whole copy seems to be a nop because the destination is never used, and there's no need to use memcpy to copy pointers anyways. And the type of the pointer was wrong, but at least those are always the same. Just remove it. Andi, Have you compiled all of wireless with gcc 4.8? If so, can I assume that you will report warnings for other drivers? Thanks, Larry -- 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/
[GIT] kbuild rc fixes for v3.6
Hi Linus, there are two fixes that should go into 3.6. The link-vmlinux.sh one is obvious. The other one fixes make firmware_install with certain configurations, where a file in the toplevel firmware tree gets installed first, and $(INSTALL_FW_PATH)/$$(dir ) results in /lib/firmware/./, which confuses make 3.82 for some reason. Thanks, Michal The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6.git ..BRANCH.NOT.VERIFIED.. Mark Asselstine (1): firmware: fix directory creation rule matching with make 3.82 Michal Marek (1): link-vmlinux.sh: Fix stray "echo" in error message scripts/Makefile.fwinst |2 +- scripts/link-vmlinux.sh |2 +- 2 files changed, 2 insertions(+), 2 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] staging/ozwpan: Fix zero address check in oz_set_active_pd
gcc 4.8 warns about the incorrect memcmp size. I think it's supposed to
be an ethernet address, so should be always 6 bytes.
The code was wrong, would either compare 4 or 8 bytes (32bit vs 64bit)
/backup/lsrc/git/linux-lto-2.6/drivers/staging/ozwpan/ozcdev.c: In function
'oz_set_active_pd':
/backup/lsrc/git/linux-lto-2.6/drivers/staging/ozwpan/ozcdev.c:216:43: warning:
argument to 'sizeof' in 'memcmp' call is the same expression as the
destination; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]
if (!memcmp(addr, "\0\0\0\0\0\0", sizeof(addr))) {
^
Signed-off-by: Andi Kleen
diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c
index d983219..63c1b67 100644
--- a/drivers/staging/ozwpan/ozcdev.c
+++ b/drivers/staging/ozwpan/ozcdev.c
@@ -213,7 +213,7 @@ static int oz_set_active_pd(u8 *addr)
if (old_pd)
oz_pd_put(old_pd);
} else {
- if (!memcmp(addr, "\0\0\0\0\0\0", sizeof(addr))) {
+ if (!memcmp(addr, "\0\0\0\0\0\0", ETH_ALEN)) {
spin_lock_bh(_cdev.lock);
pd = g_cdev.active_pd;
g_cdev.active_pd = 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] Remove bogus memcpy in brcm80211 ai_detach
gcc 4.8 warns for this memcpy. While the copy size is correct, the whole
copy seems to be a nop because the destination is never used, and
there's no need to use memcpy to copy pointers anyways. And the
type of the pointer was wrong, but at least those are always the same.
Just remove it.
/backup/lsrc/git/linux-lto-2.6/drivers/net/wireless/brcm80211/brcmsmac/aiutils.c:
In function 'ai_detach':
/backup/lsrc/git/linux-lto-2.6/drivers/net/wireless/brcm80211/brcmsmac/aiutils.c:539:32:
warning: argument to 'sizeof' in 'memcpy' call is the same pointer type
'struct si_pub **' as the destination; expected 'struct si_pub *' or an
explicit length [-Wsizeof-pointer-memaccess]
memcpy(_local, , sizeof(struct si_pub **));
^
Signed-off-by: Andi Kleen
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/aiutils.c
b/drivers/net/wireless/brcm80211/brcmsmac/aiutils.c
index 8c9345d..b89f127 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/aiutils.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/aiutils.c
@@ -535,9 +535,6 @@ void ai_detach(struct si_pub *sih)
{
struct si_info *sii;
- struct si_pub *si_local = NULL;
- memcpy(_local, , sizeof(struct si_pub **));
-
sii = container_of(sih, struct si_info, pub);
if (sii == NULL)
--
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: [PATCH] Fix memset in NFS zap caches
On Mon, 2012-09-03 at 14:52 -0400, Trond Myklebust wrote:
> On Mon, 2012-09-03 at 20:47 +0200, Andi Kleen wrote:
> > > No, this is a gcc bug.
> > >
> > > NFS_COOKIEVERF(inode) resolves to an array, so the current code is
> > > correct. The above change will cause the 2nd half of the array to remain
> > > uninitialised...
> >
> > Are you sure?
> >
> > include/linux/nfs_fs.h:268:static inline __be32 *NFS_COOKIEVERF(const
> > struct inode *inode)
> >
> > That doesn't look like an array type to me.
>
> Argh... It used to be a #define, but got converted in the commit
> 99fadcd7646 static inline blitz...
>
> OK, let's just get rid of the NFS_COOKIEVERF thing altogether. At this
> point it is clearly just obfuscating the code.
>
This should do the right thing:
8<--
From c8879cbdf7c4697e450c4a001f24b88e04b70857 Mon Sep 17 00:00:00 2001
From: Trond Myklebust
Date: Mon, 3 Sep 2012 14:56:02 -0400
Subject: [PATCH] NFS: Fix the initialisation of the readdir 'cookieverf'
array
When the NFS_COOKIEVERF helper macro was converted into a static
inline function, we broke the initialisation of the readdir cookies,
since it depended on a 'sizeof(NFS_COOKIEVERF(inode))'.
At this point, NFS_COOKIEVERF seems to be more of an obfuscation
than a helper, so the best thing would be to just get rid of it.
Reported-by: Andi Kleen
Signed-off-by: Trond Myklebust
---
fs/nfs/inode.c | 2 +-
fs/nfs/nfs3proc.c | 2 +-
fs/nfs/nfs4proc.c | 4 ++--
include/linux/nfs_fs.h | 5 -
4 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index c6e895f..9b47610 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -154,7 +154,7 @@ static void nfs_zap_caches_locked(struct inode *inode)
nfsi->attrtimeo = NFS_MINATTRTIMEO(inode);
nfsi->attrtimeo_timestamp = jiffies;
- memset(NFS_COOKIEVERF(inode), 0, sizeof(NFS_COOKIEVERF(inode)));
+ memset(NFS_I(inode)->cookieverf, 0, sizeof(NFS_I(inode)->cookieverf));
if (S_ISREG(mode) || S_ISDIR(mode) || S_ISLNK(mode))
nfsi->cache_validity |=
NFS_INO_INVALID_ATTR|NFS_INO_INVALID_DATA|NFS_INO_INVALID_ACCESS|NFS_INO_INVALID_ACL|NFS_INO_REVAL_PAGECACHE;
else
diff --git a/fs/nfs/nfs3proc.c b/fs/nfs/nfs3proc.c
index d6b3b5f..6932209 100644
--- a/fs/nfs/nfs3proc.c
+++ b/fs/nfs/nfs3proc.c
@@ -643,7 +643,7 @@ nfs3_proc_readdir(struct dentry *dentry, struct rpc_cred
*cred,
u64 cookie, struct page **pages, unsigned int count, int plus)
{
struct inode*dir = dentry->d_inode;
- __be32 *verf = NFS_COOKIEVERF(dir);
+ __be32 *verf = NFS_I(dir)->cookieverf;
struct nfs3_readdirargs arg = {
.fh = NFS_FH(dir),
.cookie = cookie,
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 74f5c26..1e50326 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -3215,11 +3215,11 @@ static int _nfs4_proc_readdir(struct dentry *dentry,
struct rpc_cred *cred,
dentry->d_parent->d_name.name,
dentry->d_name.name,
(unsigned long long)cookie);
- nfs4_setup_readdir(cookie, NFS_COOKIEVERF(dir), dentry, );
+ nfs4_setup_readdir(cookie, NFS_I(dir)->cookieverf, dentry, );
res.pgbase = args.pgbase;
status = nfs4_call_sync(NFS_SERVER(dir)->client, NFS_SERVER(dir), ,
_args, _res, 0);
if (status >= 0) {
- memcpy(NFS_COOKIEVERF(dir), res.verifier.data,
NFS4_VERIFIER_SIZE);
+ memcpy(NFS_I(dir)->cookieverf, res.verifier.data,
NFS4_VERIFIER_SIZE);
status += args.pgbase;
}
diff --git a/include/linux/nfs_fs.h b/include/linux/nfs_fs.h
index 1f8fc7f..4b03f56 100644
--- a/include/linux/nfs_fs.h
+++ b/include/linux/nfs_fs.h
@@ -265,11 +265,6 @@ static inline const struct nfs_rpc_ops *NFS_PROTO(const
struct inode *inode)
return NFS_SERVER(inode)->nfs_client->rpc_ops;
}
-static inline __be32 *NFS_COOKIEVERF(const struct inode *inode)
-{
- return NFS_I(inode)->cookieverf;
-}
-
static inline unsigned NFS_MINATTRTIMEO(const struct inode *inode)
{
struct nfs_server *nfss = NFS_SERVER(inode);
--
1.7.11.4
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
Re: [PATCH v2 -tip 1/5] x86, MSI: Support multiple MSIs in presense of IRQ remapping
On Mon, Sep 3, 2012 at 2:17 AM, Alexander Gordeev wrote:
> The MSI specification has several constraints in comparison with MSI-X,
> most notable of them is the inability to configure MSIs independently.
> As a result, it is impossible to dispatch interrupts from different
> queues to different CPUs. This is largely devalues the support of
> multiple MSIs in SMP systems.
>
> Also, a necessity to allocate a contiguous block of vector numbers for
> devices capable of multiple MSIs might cause a considerable pressure on
> x86 interrupt vector allocator and could lead to fragmentation of the
> interrupt vectors space.
>
> This patch overcomes both drawbacks in presense of IRQ remapping and
> lets devices take advantage of multiple queues and per-IRQ affinity
> assignments.
>
> Signed-off-by: Alexander Gordeev
> ---
> arch/x86/kernel/apic/io_apic.c | 166 +--
> include/linux/irq.h|6 ++
> kernel/irq/chip.c | 30 +--
> kernel/irq/irqdesc.c | 31
> 4 files changed, 216 insertions(+), 17 deletions(-)
>
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index c265593..5fd2577 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -305,6 +305,11 @@ static int alloc_irq_from(unsigned int from, int node)
> return irq_alloc_desc_from(from, node);
> }
>
> +static int alloc_irqs_from(unsigned int from, unsigned int count, int node)
> +{
> + return irq_alloc_descs_from(from, count, node);
> +}
> +
> static void free_irq_at(unsigned int at, struct irq_cfg *cfg)
> {
> free_irq_cfg(at, cfg);
> @@ -3039,6 +3044,55 @@ int create_irq(void)
> return irq;
> }
>
> +unsigned int create_irqs(unsigned int from, unsigned int count, int node)
> +{
> + struct irq_cfg **cfg;
> + unsigned long flags;
> + int irq, i;
> +
> + if (from < nr_irqs_gsi)
> + from = nr_irqs_gsi;
> +
> + cfg = kzalloc_node(count * sizeof(cfg[0]), GFP_KERNEL, node);
> + if (!cfg)
> + return 0;
> +
> + irq = alloc_irqs_from(from, count, node);
> + if (irq < 0)
> + goto out_cfgs;
> +
> + for (i = 0; i < count; i++) {
> + cfg[i] = alloc_irq_cfg(irq + i, node);
> + if (!cfg[i])
> + goto out_irqs;
> + }
> +
> + raw_spin_lock_irqsave(_lock, flags);
> + for (i = 0; i < count; i++)
> + if (__assign_irq_vector(irq + i, cfg[i], apic->target_cpus()))
> + goto out_vecs;
> + raw_spin_unlock_irqrestore(_lock, flags);
> +
> + for (i = 0; i < count; i++) {
> + irq_set_chip_data(irq + i, cfg[i]);
> + irq_clear_status_flags(irq + i, IRQ_NOREQUEST);
> + }
> +
> + kfree(cfg);
> + return irq;
> +
> +out_vecs:
> + for (; i; i--)
> + __clear_irq_vector(irq + i - 1, cfg[i - 1]);
> + raw_spin_unlock_irqrestore(_lock, flags);
> +out_irqs:
> + for (i = 0; i < count; i++)
> + free_irq_at(irq + i, cfg[i]);
> +out_cfgs:
> + kfree(cfg);
> + return 0;
> +}
> +
You may update create_irq_nr to be __create_irq_nr, and it could take
extra count.
and later have create_irq_nr to be __create_irq_nr(,1,)
and create_irqs to be __create_irq_nr(,count,)
BTW, in short, how much performance benefits for adding 500 lines code?
Thanks
Yinghai
--
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] Fix memset in NFS zap caches
On Mon, 2012-09-03 at 20:47 +0200, Andi Kleen wrote: > > No, this is a gcc bug. > > > > NFS_COOKIEVERF(inode) resolves to an array, so the current code is > > correct. The above change will cause the 2nd half of the array to remain > > uninitialised... > > Are you sure? > > include/linux/nfs_fs.h:268:static inline __be32 *NFS_COOKIEVERF(const struct > inode *inode) > > That doesn't look like an array type to me. Argh... It used to be a #define, but got converted in the commit 99fadcd7646 static inline blitz... OK, let's just get rid of the NFS_COOKIEVERF thing altogether. At this point it is clearly just obfuscating the code. -- Trond Myklebust Linux NFS client maintainer NetApp trond.mykleb...@netapp.com www.netapp.com
[PATCH] Fix incorrect memset in bnx2fc_parse_fcp_rsp
gcc 4.8 warns because the memset only clears sizeof(char *) bytes, not the whole buffer. Use the correct buffer size and clear the whole sense buffer. /backup/lsrc/git/linux-lto-2.6/drivers/scsi/bnx2fc/bnx2fc_io.c: In function 'bnx2fc_parse_fcp_rsp': /backup/lsrc/git/linux-lto-2.6/drivers/scsi/bnx2fc/bnx2fc_io.c:1810:41: warning: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess] memset(sc_cmd->sense_buffer, 0, sizeof(sc_cmd->sense_buffer)); ^ Signed-off-by: Andi Kleen diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c index 73f231c..8d4626c 100644 --- a/drivers/scsi/bnx2fc/bnx2fc_io.c +++ b/drivers/scsi/bnx2fc/bnx2fc_io.c @@ -1807,7 +1807,7 @@ static void bnx2fc_parse_fcp_rsp(struct bnx2fc_cmd *io_req, fcp_sns_len = SCSI_SENSE_BUFFERSIZE; } - memset(sc_cmd->sense_buffer, 0, sizeof(sc_cmd->sense_buffer)); + memset(sc_cmd->sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); if (fcp_sns_len) memcpy(sc_cmd->sense_buffer, rq_data, fcp_sns_len); -- 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: [PATCH] Fix memset in NFS zap caches
> No, this is a gcc bug. > > NFS_COOKIEVERF(inode) resolves to an array, so the current code is > correct. The above change will cause the 2nd half of the array to remain > uninitialised... Are you sure? include/linux/nfs_fs.h:268:static inline __be32 *NFS_COOKIEVERF(const struct inode *inode) That doesn't look like an array type to me. -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: [PATCH] Fix memset in NFS zap caches
On Mon, 2012-09-03 at 20:35 +0200, Andi Kleen wrote: > Fix memset in nfs_zap_caches_locked > > This memset overruns the buffer by 4 bytes on 64bit systems. > > gcc 4.8 correct complains: > > /backup/lsrc/git/linux-lto-2.6/fs/nfs/inode.c: In function > 'nfs_zap_caches_locked': > /backup/lsrc/git/linux-lto-2.6/fs/nfs/inode.c:157:41: warning: argument > to 'sizeof' in 'memset' call is the same pointer type '__be32 *' as the > destination; expected '__be32' or an explicit length > [-Wsizeof-pointer-memaccess] > memset(NFS_COOKIEVERF(inode), 0, sizeof(NFS_COOKIEVERF(inode))); > ^ > Add a * to sizeof the correct type. > > Signed-off-by: Andi Kleen > > diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c > index c6e895f..69e7f0f 100644 > --- a/fs/nfs/inode.c > +++ b/fs/nfs/inode.c > @@ -154,7 +154,7 @@ static void nfs_zap_caches_locked(struct inode *inode) > nfsi->attrtimeo = NFS_MINATTRTIMEO(inode); > nfsi->attrtimeo_timestamp = jiffies; > > - memset(NFS_COOKIEVERF(inode), 0, sizeof(NFS_COOKIEVERF(inode))); > + memset(NFS_COOKIEVERF(inode), 0, sizeof(*NFS_COOKIEVERF(inode))); > if (S_ISREG(mode) || S_ISDIR(mode) || S_ISLNK(mode)) > nfsi->cache_validity |= > NFS_INO_INVALID_ATTR|NFS_INO_INVALID_DATA|NFS_INO_INVALID_ACCESS|NFS_INO_INVALID_ACL|NFS_INO_REVAL_PAGECACHE; > else Hi Andi, No, this is a gcc bug. NFS_COOKIEVERF(inode) resolves to an array, so the current code is correct. The above change will cause the 2nd half of the array to remain uninitialised... Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp trond.mykleb...@netapp.com www.netapp.com
[PATCH] Fix memset in NFS zap caches
Fix memset in nfs_zap_caches_locked This memset overruns the buffer by 4 bytes on 64bit systems. gcc 4.8 correct complains: /backup/lsrc/git/linux-lto-2.6/fs/nfs/inode.c: In function 'nfs_zap_caches_locked': /backup/lsrc/git/linux-lto-2.6/fs/nfs/inode.c:157:41: warning: argument to 'sizeof' in 'memset' call is the same pointer type '__be32 *' as the destination; expected '__be32' or an explicit length [-Wsizeof-pointer-memaccess] memset(NFS_COOKIEVERF(inode), 0, sizeof(NFS_COOKIEVERF(inode))); ^ Add a * to sizeof the correct type. Signed-off-by: Andi Kleen diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c index c6e895f..69e7f0f 100644 --- a/fs/nfs/inode.c +++ b/fs/nfs/inode.c @@ -154,7 +154,7 @@ static void nfs_zap_caches_locked(struct inode *inode) nfsi->attrtimeo = NFS_MINATTRTIMEO(inode); nfsi->attrtimeo_timestamp = jiffies; - memset(NFS_COOKIEVERF(inode), 0, sizeof(NFS_COOKIEVERF(inode))); + memset(NFS_COOKIEVERF(inode), 0, sizeof(*NFS_COOKIEVERF(inode))); if (S_ISREG(mode) || S_ISDIR(mode) || S_ISLNK(mode)) nfsi->cache_validity |= NFS_INO_INVALID_ATTR|NFS_INO_INVALID_DATA|NFS_INO_INVALID_ACCESS|NFS_INO_INVALID_ACL|NFS_INO_REVAL_PAGECACHE; else -- 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: [PATCH can-next v6] can: add tx/rx LED trigger support
On Mon, Sep 03, 2012 at 08:13:35PM +0200, Kurt Van Dijck wrote: > On Mon, Sep 03, 2012 at 02:40:39PM +0200, Marc Kleine-Budde wrote: > > The net->ifindex is unique. But it's only an integer. Usually can0 has a > > ifindex != 0, so a simple can%d is contra productive here. > > > > Some pointers to related code: > > http://lxr.free-electrons.com/source/drivers/base/core.c#L1847 > > http://lxr.free-electrons.com/source/drivers/base/core.c#L73 > > http://lxr.free-electrons.com/source/include/linux/device.h#L695 > > > > comments? That would probabily makes really hard to choose the right default_trigger for led devices to get to the appropriate CAN LED in embedded systems, as trigger name would depend from other network devices and probing order (correct me if I'm wrong). Something with device name would probaily be more appropriate here. > > a very recent idea: something with netdevice notifiers and NETDEV_CHANGENAME > ... > http://lxr.free-electrons.com/source/net/core/dev.c#L1030 > > you could: rename the trigger, or if we think it's usefull, > block the netdev rename when its triggers are in use. Blocking the rename looks overkill to me, what about using device name with an optional "port id" appended to it? Sounds simpler... Fabio -- 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 can-next v6] can: add tx/rx LED trigger support
On Mon, Sep 03, 2012 at 02:40:39PM +0200, Marc Kleine-Budde wrote: > On 08/25/2012 12:01 AM, Fabio Baltieri wrote: > > Hello Kurt, > > > > On Fri, Aug 24, 2012 at 02:42:48PM +0200, Kurt Van Dijck wrote: > >> On Fri, Aug 24, 2012 at 01:28:16PM +0200, Marc Kleine-Budde wrote: > >>> On 08/24/2012 07:10 AM, Kurt Van Dijck wrote: > Hello, > > I find the CAN led triggers an interesting thing. > > And then, this scenario fell crossed my mind: > Imagine I do: > [insert CAN device: can0] > $ ip link set can0 name helga > [insert another CAN device: again 'can0'] > > Registering 'can0-tx' led trigger will fail for the second CAN device, > since that led trigger name is already reserved for CAN device 'helga'. > >>> Good point. > > > > Yep, thanks for pointing that out! > > > > Interface renaming was something I considered when I first wrote the > > code and I had the mac80211-led driver in mind, as that driver uses the > > phy name and not the netdev one for its triggers. > > > > The reason why I did not care that much in the end is that on SoC based > > systems trigger-led association is made at probe time, based on data > > either from platform_data or devicetree, so I imagined that once the > > kernel is ported to the board and default triggers are set correctly at > > boot time, the userspace is free to rename CAN interfaces and nobody > > should notice... :^) > > > > The thing I did not consider are hot-plug interfaces mixed with > > renaming, such as in the case you pointed out - it's probably not really > > common but still possible. > > > I'm not sure how to fix such. > If 'rx' & 'tx' may be combined, reusing the netdev name may be possible? > Just wild thinking ... > >>> > >>> I think the device's name (not netdev) is unique in the system and > >>> cannot be changed. > >> > >> but may contain several netdev's ... > > > > Ouch. > > The net->ifindex is unique. But it's only an integer. Usually can0 has a > ifindex != 0, so a simple can%d is contra productive here. > > Some pointers to related code: > http://lxr.free-electrons.com/source/drivers/base/core.c#L1847 > http://lxr.free-electrons.com/source/drivers/base/core.c#L73 > http://lxr.free-electrons.com/source/include/linux/device.h#L695 > > comments? a very recent idea: something with netdevice notifiers and NETDEV_CHANGENAME ... http://lxr.free-electrons.com/source/net/core/dev.c#L1030 you could: rename the trigger, or if we think it's usefull, block the netdev rename when its triggers are in use. Kurt -- 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] ARM: S3C24XX: Add WIZnet W5300E01-ARM board support
On Mon, Sep 3, 2012 at 8:36 PM, Taehun Kim wrote:
> This patch adds WIZnet W5300E01 board changed to the new gpio functions.
> Please review this patch and apply it if do not have any problems.
>
> Signed-off-by: Taehun Kim
> ---
> arch/arm/mach-s3c24xx/Kconfig |5 +
> arch/arm/mach-s3c24xx/Makefile|1 +
> arch/arm/mach-s3c24xx/mach-w5300e01.c | 186
> +
> 3 files changed, 192 insertions(+)
> create mode 100644 arch/arm/mach-s3c24xx/mach-w5300e01.c
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig
> b/arch/arm/mach-s3c24xx/Kconfig
> index d56b0f7..94b60ca 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -248,6 +248,11 @@ config MACH_VR1000
> help
> Say Y here if you are using the Thorcom VR1000 board.
>
> +config MACH_W5300E01
> + bool "WIZnet W5300E01-ARM Board"
> + help
> + Say Y here if you are using the Wiznet W5300E01-ARM board.
> +
> endif # CPU_S3C2410
>
> config S3C2412_PM_SLEEP
> diff --git a/arch/arm/mach-s3c24xx/Makefile
> b/arch/arm/mach-s3c24xx/Makefile
> index 0ab6ab1..fc1a89e 100644
> --- a/arch/arm/mach-s3c24xx/Makefile
> +++ b/arch/arm/mach-s3c24xx/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_QT2410) += mach-qt2410.o
> obj-$(CONFIG_ARCH_SMDK2410)+= mach-smdk2410.o
> obj-$(CONFIG_MACH_TCT_HAMMER) += mach-tct_hammer.o
> obj-$(CONFIG_MACH_VR1000) += mach-vr1000.o
> +obj-$(CONFIG_MACH_W5300E01)+= mach-w5300e01.o
>
> obj-$(CONFIG_MACH_JIVE)+= mach-jive.o
> obj-$(CONFIG_MACH_SMDK2413)+= mach-smdk2413.o
> diff --git a/arch/arm/mach-s3c24xx/mach-w5300e01.c
> b/arch/arm/mach-s3c24xx/mach-w5300e01.c
> new file mode 100644
> index 000..7daf82e
> --- /dev/null
> +++ b/arch/arm/mach-s3c24xx/mach-w5300e01.c
> @@ -0,0 +1,186 @@
> +/* linux/arch/arm/mach-s3c24xx/mach-w5300e01.c
> + *
> + * Copyright (c) 2012 Taehun Kim
> + *
> + * For product information, visit http://www.wiznet.co.kr/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * @History:
> + * derived from linux/arch/arm/mach-s3c24xx/mach-bast.c, written by
> + * Ben Dooks
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct map_desc w5300e01_iodesc[] __initdata = {
> + /* Character LCD register map. */
> + { 0xf800, __phys_to_pfn(S3C2410_CS3), SZ_1M, MT_DEVICE }
> +};
> +
> +#define UCON S3C2410_UCON_DEFAULT
> +#define ULCON (S3C2410_LCON_CS8 | S3C2410_LCON_PNONE |
> S3C2410_LCON_STOPB)
> +#define UFCON (S3C2410_UFCON_RXTRIG8 | S3C2410_UFCON_FIFOMODE)
> +
> +static struct s3c2410_uartcfg w5300e01_uartcfgs[] __initdata = {
> + [0] = {
> + .hwport = 0,
> + .flags = 0,
> + .ucon = UCON,
> + .ulcon = ULCON,
> + .ufcon = UFCON,
> + },
> + [1] = {
> + .hwport = 1,
> + .flags = 0,
> + .ucon = UCON,
> + .ulcon = ULCON,
> + .ufcon = UFCON,
> + },
> + [2] = {
> + .hwport = 2,
> + .flags = 0,
> + .ucon = UCON,
> + .ulcon = ULCON,
> + .ufcon = UFCON,
> + }
> +};
> +
> +static struct mtd_partition w5300e01_mtd_partitions[] = {
> + [0] = {
> + .name = "Bootloader",
> + .size = 0x2,
> + .offset = 0,
> + .mask_flags = MTD_WRITEABLE,
> + },
> + [1] = {
> + .name = "Boot Param",
> + .size = 0x2,
> + .offset = MTDPART_OFS_APPEND,
> + },
> + [2] = {
> + .name = "Kernel",
> + .size = 0x3C,
> + .offset = MTDPART_OFS_APPEND,
> + },
> + [3] = {
> + .name = "Ramdisk",
> + .size = 0x100,
> + .offset = MTDPART_OFS_APPEND,
> + },
> + [4] = {
> + .name = "JFFS2 FileSystem",
> + .size = MTDPART_SIZ_FULL,
> + .offset = MTDPART_OFS_APPEND,
> + },
> +};
> +
> +static struct resource w5300_resources[] = {
> + [0] = {
> + .start = S3C2410_CS2,
> + .end= S3C2410_CS2 + SZ_1M,
> + .flags = IORESOURCE_MEM,
> +
[PATCH v2] ARM: S3C24XX: Add WIZnet W5300E01-ARM board support
This patch adds WIZnet W5300E01 board changed to the new gpio functions.
Please review this patch and apply it if do not have any problems.
Signed-off-by: Taehun Kim
---
arch/arm/mach-s3c24xx/Kconfig |5 +
arch/arm/mach-s3c24xx/Makefile|1 +
arch/arm/mach-s3c24xx/mach-w5300e01.c | 186
+
3 files changed, 192 insertions(+)
create mode 100644 arch/arm/mach-s3c24xx/mach-w5300e01.c
diff --git a/arch/arm/mach-s3c24xx/Kconfig
b/arch/arm/mach-s3c24xx/Kconfig
index d56b0f7..94b60ca 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -248,6 +248,11 @@ config MACH_VR1000
help
Say Y here if you are using the Thorcom VR1000 board.
+config MACH_W5300E01
+ bool "WIZnet W5300E01-ARM Board"
+ help
+ Say Y here if you are using the Wiznet W5300E01-ARM board.
+
endif # CPU_S3C2410
config S3C2412_PM_SLEEP
diff --git a/arch/arm/mach-s3c24xx/Makefile
b/arch/arm/mach-s3c24xx/Makefile
index 0ab6ab1..fc1a89e 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_QT2410) += mach-qt2410.o
obj-$(CONFIG_ARCH_SMDK2410)+= mach-smdk2410.o
obj-$(CONFIG_MACH_TCT_HAMMER) += mach-tct_hammer.o
obj-$(CONFIG_MACH_VR1000) += mach-vr1000.o
+obj-$(CONFIG_MACH_W5300E01)+= mach-w5300e01.o
obj-$(CONFIG_MACH_JIVE)+= mach-jive.o
obj-$(CONFIG_MACH_SMDK2413)+= mach-smdk2413.o
diff --git a/arch/arm/mach-s3c24xx/mach-w5300e01.c
b/arch/arm/mach-s3c24xx/mach-w5300e01.c
new file mode 100644
index 000..7daf82e
--- /dev/null
+++ b/arch/arm/mach-s3c24xx/mach-w5300e01.c
@@ -0,0 +1,186 @@
+/* linux/arch/arm/mach-s3c24xx/mach-w5300e01.c
+ *
+ * Copyright (c) 2012 Taehun Kim
+ *
+ * For product information, visit http://www.wiznet.co.kr/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * @History:
+ * derived from linux/arch/arm/mach-s3c24xx/mach-bast.c, written by
+ * Ben Dooks
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct map_desc w5300e01_iodesc[] __initdata = {
+ /* Character LCD register map. */
+ { 0xf800, __phys_to_pfn(S3C2410_CS3), SZ_1M, MT_DEVICE }
+};
+
+#define UCON S3C2410_UCON_DEFAULT
+#define ULCON (S3C2410_LCON_CS8 | S3C2410_LCON_PNONE |
S3C2410_LCON_STOPB)
+#define UFCON (S3C2410_UFCON_RXTRIG8 | S3C2410_UFCON_FIFOMODE)
+
+static struct s3c2410_uartcfg w5300e01_uartcfgs[] __initdata = {
+ [0] = {
+ .hwport = 0,
+ .flags = 0,
+ .ucon = UCON,
+ .ulcon = ULCON,
+ .ufcon = UFCON,
+ },
+ [1] = {
+ .hwport = 1,
+ .flags = 0,
+ .ucon = UCON,
+ .ulcon = ULCON,
+ .ufcon = UFCON,
+ },
+ [2] = {
+ .hwport = 2,
+ .flags = 0,
+ .ucon = UCON,
+ .ulcon = ULCON,
+ .ufcon = UFCON,
+ }
+};
+
+static struct mtd_partition w5300e01_mtd_partitions[] = {
+ [0] = {
+ .name = "Bootloader",
+ .size = 0x2,
+ .offset = 0,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [1] = {
+ .name = "Boot Param",
+ .size = 0x2,
+ .offset = MTDPART_OFS_APPEND,
+ },
+ [2] = {
+ .name = "Kernel",
+ .size = 0x3C,
+ .offset = MTDPART_OFS_APPEND,
+ },
+ [3] = {
+ .name = "Ramdisk",
+ .size = 0x100,
+ .offset = MTDPART_OFS_APPEND,
+ },
+ [4] = {
+ .name = "JFFS2 FileSystem",
+ .size = MTDPART_SIZ_FULL,
+ .offset = MTDPART_OFS_APPEND,
+ },
+};
+
+static struct resource w5300_resources[] = {
+ [0] = {
+ .start = S3C2410_CS2,
+ .end= S3C2410_CS2 + SZ_1M,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_EINT0,
+ .end= IRQ_EINT0,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device w5300_device = {
+ .name = "w5300",
+ .num_resources = ARRAY_SIZE(w5300_resources),
+ .resource = w5300_resources,
+};
+
+static struct
Re: [RFC] semantics of singlestepping vs. tracer exiting
On Mon, Sep 03, 2012 at 06:05:38PM +0200, Oleg Nesterov wrote: > This is not easy to fix. ptrace_disable() and user_disable_single_step() > is arch dependant, but at least on x86 it assumes that the tracee is not > running, so exit_ptrace() can't do this. True (IOW, proposed fix is hopeless - we definitely want the detachees to be in kernel space, and not only on x86). > This is another reason to move enable/disable step into ptrace_stop(). > And in fact I had the patches a loong ago, but we need to cleanup > the usage of PT_SINGLESTEP/PT_BLOCKSTEP first. The tracer should > simply set/clear these PT_ flags and resume the tracee which should > check them and do user_*_single_step() in response. > > Related question: should execve(2) clear (ptrace-inflicted) > > singlestepping? > > Perhaps, but > > > Tracer > > exit(), however, does *not* do that right now, so the state after > > execve(2) is theoretically observable. > > ... why execve() is special? Because that behaviour had been changed over the history, for one thing: commit e1f287735c1e58c653b516931b5d3dd899edcb77 Author: Roland McGrath Date: Wed Jan 30 13:30:50 2008 +0100 x86 single_step: TIF_FORCED_TF had done that for x86, unless I'm misreading something. BTW, now that I've looked at that, alpha seems to have a really unpleasant bug with single-stepping through execve() - it *must* reset ->bpt_nsaved to 0 in start_thread(), simply because the address space the breakpoints used to be in is gone at that point. I don't see any place where that would be done; suppose we single-step right into callsys insn and do PTRACE_CONT when stopped on the way out. Won't that end up with ptrace_cancel_bpt() done in *new* address space, silently buggering new .text contents? BTW, speaking of alpha, what about PTRACE_SINGLESTEP when the task is stopped on syscall entry/exit after previous PTRACE_SYSCALL, BTW? Looks like it will be like PTRACE_CONT until we hit the first signal, at which point it converts to singlesteping mode; unless I'm seriously misreading that code, we rely on ptrace_set_bpt() done shortly after returning from get_signal_to_deliver() if we found that we'd been singlestepping. Fine, but in this case we had been resumed *not* in get_signal_to_deliver()... Cc'd linux-alpha, in hopes to hear "you don't understand how single-stepping works on alpha, you idiot, everything's fine because of $REASONS"... -- 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_bh stalls on 3.2.28
On Mon, 03 Sep 2012, Michael Wang wrote: > On 09/01/2012 07:02 AM, Henrique de Moraes Holschuh wrote: > > Just got one of these: > > > > kernel: INFO: rcu_bh detected stall on CPU 2 (t=0 jiffies) > > kernel: Pid: 0, comm: swapper/2 Not tainted 3.2.28+ #2 > > kernel: Call Trace: > > kernel: [] __rcu_pending+0x159/0x400 > > kernel: [] rcu_check_callbacks+0x9b/0x120 > > kernel: [] update_process_times+0x43/0x80 > > kernel: [] tick_sched_timer+0x5f/0xb0 > > kernel: [] __run_hrtimer.isra.30+0x57/0x100 > > kernel: [] hrtimer_interrupt+0xe5/0x220 > > kernel: [] smp_apic_timer_interrupt+0x64/0xa0 > > kernel: [] apic_timer_interrupt+0x6b/0x70 > > kernel: [] ? intel_idle+0xe5/0x140 > > kernel: [] ? intel_idle+0xc3/0x140 > > kernel: [] cpuidle_idle_call+0x8e/0xf0 > > kernel: [] cpu_idle+0xa5/0x110 > > kernel: [] start_secondary+0x1e5/0x1ec > > Hi, Henrique > > rsp->gp_start and rsp->jiffies_stall should already set before we start > check stall for this gp, but the INFO show that we have a current > jiffies which bigger then rsp->jiffies_stall but equal to rsp->gp_start, > really strange... > > Could you please have a try on the latest kernel and confirm whether > this issue still exist? It is a production box, it is difficult to run a -rc kernel there. And the stalls are very rare, too. That's the only one I got, so at this point I cannot tell you whether something fixed the problem or not, just try to give you clues if a stall does happen. > BTW: > Is this stall info comes from a virtual machine? No, it runs on baremetal. The box has one Xeon X5550 processor, 4 cores, 8 threads, and it is allowed to go into C1, C3 and C6 (which it does very very often). It might be some sort of race related to SMIs? The worst-case SMM-induced delay on this box is quite high (I don't recall if that means 150ms or 150us), as measured by the Intel BITS[1]. [1] http://biosbits.org/ -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] memcg: first step towards hierarchical controller
On Mon 03-09-12 19:46:51, Glauber Costa wrote:
> Here is a new attempt to lay down a path that will allow us to deprecate
> the non-hierarchical mode of operation from memcg. Unlike what I posted
> before, I am making this behavior conditional on a Kconfig option.
> Vanilla users will see no change in behavior unless they don't
> explicitly set this option to on.
Which is the reason why I don't like this approach. Why would you enable
the option in the first place? If you know the default should be 1 then
you would already do that via cgconfig or directly, right?
I think we should either change the default (which I am planning to do
for the next OpenSUSE) or do it slow way suggested by Tejun.
We really want to have as big testing coverage as possible for the
default change and config option is IMHO not a way to accomplish this.
> Distributions, however, are encouraged to set it.
As I said, I plan to change the default with WARN_ONCE for both first
cgroup created and default changed. It would be nice if other
distributions could do the same but this might be tricky as nobody wants
to regress and there are certain usecases which could really suffer
(most of them fixable easily but there still might be some where
use_hierarchy=0 is valid).
> In that case, hierarchy will still be there. We'll just default to
> true in the root cgroup, and print a warning once if you try to set it
> back to 0.
>
> After a grace period, we should be able to gauge if anyone actually
> relies on it and get rid of the hierarchy file, or at least of its
> behavior.
>
> [ v2: make it dependent on a Kconfig option ]
>
> Signed-off-by: Glauber Costa
> CC: Dave Jones
> CC: Ben Hutchings
> CC: Peter Zijlstra
> CC: Paul Turner
> CC: Lennart Poettering
> CC: Kay Sievers
> CC: Michal Hocko
> CC: Kamezawa Hiroyuki
> CC: Johannes Weiner
> CC: Tejun Heo
> ---
> init/Kconfig| 18 ++
> mm/memcontrol.c | 9 +
> 2 files changed, 27 insertions(+)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 707d015..f64f888 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -726,6 +726,24 @@ config MEMCG_SWAP
> if boot option "swapaccount=0" is set, swap will not be accounted.
> Now, memory usage of swap_cgroup is 2 bytes per entry. If swap page
> size is 4096bytes, 512k per 1Gbytes of swap.
> +
> +config MEMCG_HIERARCHY_DEFAULT
> + bool "Hierarchical memcg"
> + depends on MEMCG
> + default n
> + help
> + The memory controller has two modes of accounting: hierarchical and
> + flat. Hierarchical accounting will charge pages all the way towards a
> + group's parent while flat hierarchy will threat all groups as children
> + of the root memcg, regardless of their positioning in the tree.
> +
> + Use of flat hierarchies is highly discouraged, but has been the
> + default for performance reasons for quite some time. Setting this flag
> + to on will make hierarchical accounting the default. It is still
> + possible to set it back to flat by writing 0 to the file
> + memory.use_hierarchy, albeit discouraged. Distributors are encouraged
> + to set this option.
> +
> config MEMCG_SWAP_ENABLED
> bool "Memory Resource Controller Swap Extension enabled by default"
> depends on MEMCG_SWAP
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 61831c33..ab79746 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -4073,6 +4073,12 @@ static int mem_cgroup_hierarchy_write(struct cgroup
> *cont, struct cftype *cft,
> if (memcg->use_hierarchy == val)
> goto out;
>
> +#ifdef CONFIG_MEMCG_HIERARCHY_DEFAULT
> + WARN_ONCE((!parent_memcg && memcg->use_hierarchy && val == false),
> + "Setting this file to 0 (flat hierarchy) is considered deprecated.\n"
> + "If you believe you have a valid use case for that, we kindly ask you
> to contact linux...@kvack.org and let us know");
> +#endif
> +
> /*
>* If parent's use_hierarchy is set, we can't make any modifications
>* in the child subtrees. If it is unset, then the change can
> @@ -5325,6 +5331,9 @@ mem_cgroup_create(struct cgroup *cont)
> INIT_WORK(>work, drain_local_stock);
> }
> hotcpu_notifier(memcg_cpu_hotplug_callback, 0);
> +#ifdef CONFIG_MEMCG_HIERARCHY_DEFAULT
> + memcg->use_hierarchy = true;
> +#endif
> } else {
> parent = mem_cgroup_from_cont(cont->parent);
> memcg->use_hierarchy = parent->use_hierarchy;
> --
> 1.7.11.4
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Re: [PATCH v3 v3 00/20] Input and HID updates for 3.7
> Indeed, we are getting close. I tested the whole patch set again. > So: > - patches 1 to 19 are not introducing any bugs (at least from what I've seen). > - patch 20 is not good (see the reply in the patch). > > So far, devices tested are: > - Elan > - 3M > - Lumio > - Cypress > - Topseed > - Stantum > > you can add my "reviewed by" on patches 1, 7, 8, 10, 17, 18 and 19 > (those that are more MT related than generic input). > You can also add my 'tested-by' on the whole patch set except for the 20st. Excellent. Thank you for testing, Benjamin. Henrik -- 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 20/20] HID: hid-multitouch: Add missing contact count detection
Hi Benjamin, > Unfortunately, this is not working. We have bad devices that present either: > - a null logical_maximum (some Stantum do) -> the value 1 is assigned > to maxcontacts, and the device is turned into a mono touch > - an obviously wrong value (with respect to the current state of the > devices) -> Quanta devices report 255 there and they support only > 2 touches This is really terrible :-) Ok, so let's set maxcontacts to 60 on the 3M class, that ought to work for all present devices, right? > And of course, 3M decided to stop sending 60 touches on their recent > devices: we have here a 0x506 device that present a contact_count of > max 60, a maximum contact feature of max 60, but whatever I'm doing, > it does not want to send more than 10 touches Odd indeed. Speaking of oddness, I have two patches for the Flatfrog MT 3200, which 1) Uses more then 128 fields in the report descriptor (ever seen that before?), and 2) Advertises axes that are not used. But it does give 40 touches worth of awesomeness once quirked properly. Will send shortly. Thanks, Henrik -- 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] semantics of singlestepping vs. tracer exiting
On 09/03, Oleg Nesterov wrote: > > This is another reason to move enable/disable step into ptrace_stop(). > And in fact I had the patches a loong ago, but we need to cleanup > the usage of PT_SINGLESTEP/PT_BLOCKSTEP first. The tracer should > simply set/clear these PT_ flags and resume the tracee which should > check them and do user_*_single_step() in response. Found these patches, see the attachments And this also fixes the problems with DEBUGCTLMSR_BTF. The patches should be re-diffed, but I need to recall why I didn't send them, perhaps I noticed some problem... Oleg. [PATCH 1/3] ptrace_resume: set/clear PT_SINGLESTEP/PT_BLOCKSTEP Contrary to the comment in ptrace.h, PT_SINGLESTEP is only used on arch/xtensa, and PT_BLOCKSTEP is not used at all. Change the arch independent ptrace_resume() to set/clear these bits before user_enable_*_step/user_disable_single_step() and remove this this code from arch/xtensa/kernel/ptrace.c. Also change ptrace_init_task() to prevent the copying of these bits. This doesn't make any difference on xtensa, and other arches do not use these flags so far. But, thereafter we can check task->ptrace & PT_*STEP to figure out if this tracer wants the stepping and unlike TIF_SINGLESTEP it is always correct in this sense and it is not arch dependent. Signed-off-by: Oleg Nesterov --- include/linux/ptrace.h |4 ++-- kernel/ptrace.c |3 +++ arch/xtensa/kernel/ptrace.c |2 -- 3 files changed, 5 insertions(+), 4 deletions(-) --- ptrace/include/linux/ptrace.h~1_use_PT_STEP 2011-06-28 17:50:27.0 +0200 +++ ptrace/include/linux/ptrace.h 2011-07-03 21:55:17.0 +0200 @@ -104,7 +104,6 @@ #define PT_TRACE_MASK 0x03f4 -/* single stepping state bits (used on ARM and PA-RISC) */ #define PT_SINGLESTEP_BIT 31 #define PT_SINGLESTEP (1real_parent; child->ptrace = 0; if (unlikely(ptrace) && (current->ptrace & PT_PTRACED)) { - child->ptrace = current->ptrace; + child->ptrace = current->ptrace & + ~(PT_SINGLESTEP | PT_BLOCKSTEP); __ptrace_link(child, current->parent); } --- ptrace/kernel/ptrace.c~1_use_PT_STEP2011-06-28 17:50:27.0 +0200 +++ ptrace/kernel/ptrace.c 2011-07-03 21:55:17.0 +0200 @@ -599,13 +599,16 @@ static int ptrace_resume(struct task_str clear_tsk_thread_flag(child, TIF_SYSCALL_EMU); #endif + child->ptrace &= ~(PT_SINGLESTEP | PT_BLOCKSTEP); if (is_singleblock(request)) { if (unlikely(!arch_has_block_step())) return -EIO; + child->ptrace |= PT_BLOCKSTEP; user_enable_block_step(child); } else if (is_singlestep(request) || is_sysemu_singlestep(request)) { if (unlikely(!arch_has_single_step())) return -EIO; + child->ptrace |= PT_SINGLESTEP; user_enable_single_step(child); } else { user_disable_single_step(child); --- ptrace/arch/xtensa/kernel/ptrace.c~1_use_PT_STEP2011-04-06 21:33:43.0 +0200 +++ ptrace/arch/xtensa/kernel/ptrace.c 2011-07-03 20:30:57.0 +0200 @@ -33,12 +33,10 @@ void user_enable_single_step(struct task_struct *child) { - child->ptrace |= PT_SINGLESTEP; } void user_disable_single_step(struct task_struct *child) { - child->ptrace &= ~PT_SINGLESTEP; } /* [PATCH 2/3] ptrace: shift user_*_step() from ptrace_resume() to ptrace_stop() path Ignoring the buggy PTRACE_KILL, ptrace_resume() calls user_*_step() when the tracee sleeps in ptrace_stop(). Now that ptrace_resume() sets PT_SINGLE* flags, we can reassign user_*_step() from the tracer to the tracee. Introduce ptrace_finish_stop(), it is called by ptrace_stop() after schedule(). Move user_*_step() call sites from ptrace_resume() to ptrace_finish_stop(). This way: - we can remove user_disable_single_step() from detach paths. This is the main motivation, we can implement asynchronous detach. - this makes the detach-on-exit more correct, we do not leak TIF_SINGLESTEP if the tracer dies. - user_enable_*_step(tsk) can be implemented more efficiently if tsk == current, we can avoid access_process_vm(). Signed-off-by: Oleg Nesterov --- include/linux/ptrace.h |1 + kernel/signal.c|1 + kernel/ptrace.c| 16 3 files changed, 14 insertions(+), 4 deletions(-) --- ptrace/include/linux/ptrace.h~2_ptrace_finish_resume2011-07-03 21:55:17.0 +0200 +++ ptrace/include/linux/ptrace.h 2011-07-03 21:55:37.0 +0200 @@ -112,6 +112,7 @@ #include /* For unlikely. */ #include/* For struct task_struct. */ +extern void ptrace_finish_stop(void); extern long arch_ptrace(struct task_struct
Re: [PATCH v2] memcg: first step towards hierarchical controller
On Mon, Sep 03, 2012 at 07:46:51PM +0400, Glauber Costa wrote: > Here is a new attempt to lay down a path that will allow us to deprecate > the non-hierarchical mode of operation from memcg. Unlike what I posted > before, I am making this behavior conditional on a Kconfig option. > Vanilla users will see no change in behavior unless they don't > explicitly set this option to on. There are too many negatives in this sentence - it is not only unclear, but appears to be incorrect. I think you should delete 'don't'. [...] > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -726,6 +726,24 @@ config MEMCG_SWAP > if boot option "swapaccount=0" is set, swap will not be accounted. > Now, memory usage of swap_cgroup is 2 bytes per entry. If swap page > size is 4096bytes, 512k per 1Gbytes of swap. > + > +config MEMCG_HIERARCHY_DEFAULT > + bool "Hierarchical memcg" > + depends on MEMCG > + default n > + help > + The memory controller has two modes of accounting: hierarchical and > + flat. Hierarchical accounting will charge pages all the way towards a > + group's parent while flat hierarchy will threat all groups as children typo: 'threat' should be 'treat' > + of the root memcg, regardless of their positioning in the tree. > + > + Use of flat hierarchies is highly discouraged, but has been the > + default for performance reasons for quite some time. Setting this flag > + to on will make hierarchical accounting the default. It is still > + possible to set it back to flat by writing 0 to the file > + memory.use_hierarchy, albeit discouraged. Distributors are encouraged > + to set this option. [...] I don't think that 'default n' is effective encouragement! Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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] ipmi: fix message retry timeout
After ddac44b7 the condition in check_msg_timeout() which
does the actual timeout verification is always false.
Both ent->timeout and timeout_period have the value 1000.
This leads to messages erroneously being retried each time
ipmi_timeout_handler() is invoked while a response to a
previously sent message is expected, which is always the
case once a message has been sent.
Address this by only resending messages once the timeout
reaches a negative value. This ensures that at least one
period passes with the current timeout of 1000 ms.
Signed-off-by: Bernhard Schmidt
Cc: Corey Minyard
Cc: sta...@vger.kernel.org
---
This issue is especially noticable with double briging
over KCS because the time between a send and the response
is rather large which gives the retry timer a higher chance
to interfere. With DEBUG_MSG for ipmi_mshandler.c defined
and some printk()s added, dmesg of a doubled bridged
"ipmitool fru" command looks like the following snippet.
The resends happens everytime the retry timer kicks in
(every second), no matter how old the message is.
[ 2465.119132] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x002839, prod_id:
0x5603, dev_id: 0x3c)
[ 2465.119152] ipmi_si ipmi_si.0: IPMI kcs interface initialized
[ 2465.119157] ipmi_si: Found default kcs state machine at i/o address 0xca2
[ 2465.119163] ipmi_si: Adding default-specified smic state machine
[ 2465.119173] ipmi_si: Trying default-specified smic state machine at i/o
address 0xca9, slave address 0x0, irq 0
[ 2465.119184] ipmi_si: Interface detection failed
[ 2465.149857] ipmi_si: Adding default-specified bt state machine
[ 2465.149873] ipmi_si: Trying default-specified bt state machine at i/o
address 0xe4, slave address 0x0, irq 0
[ 2465.149886] ipmi_si: Interface detection failed
[ 2466.522195] ipmi device interface
[ 2469.605640] Send: 18 34 07 20 18 c8 20 02 01 dd
[ 2470.012172] Recv: 1c 33 00 07 1e 6c 20 00 01 c1 1e
[ 2470.012431] Send: 18 34 07 20 18 c8 20 06 34 47 7a 18 6e ff 00 01 00 5f
[ 2470.061072] Resend: 18 34 07 20 18 c8 20 06 34 47 7a 18 6e ff 00 01 00 5f
[ 2470.071474] Recv: 1c 33 00 07 1e 6c 20 04 34 00 20 1c c4 7a 00 01 00 11 81
01 0e 51 29 39 28 00 01 54 b4 a8
[ 2470.071540] Send: 18 34 07 20 18 c8 20 0a 34 47 7a 28 5e ff 00 10 00 f1 5b
[ 2470.482704] Recv: 1c 33 00 07 1e 6c 20 04 34 00 20 1c c4 7a 00 01 00 11 81
01 0e 51 29 39 28 00 01 54 b4 a8
[ 2470.485956] Recv: 1c 33 00 07 1e 6c 20 08 34 00 20 2c b4 7a 00 10 00 f0 01
00 85 a4
[ 2470.486004] Send: 18 34 07 20 18 c8 20 0e 34 47 7a 28 5e ff 00 11 00 00 00
08 e8 57
[ 2470.898083] Recv: 1c 33 00 07 1e 6c 20 0c 34 00 20 2c b4 7a 00 11 00 08 01
00 00 01 08 15 00 e1 6d a0
[ 2470.898142] Send: 18 34 07 20 18 c8 20 12 34 47 7a 28 5e ff 00 11 00 08 00
02 e6 53
[ 2471.060094] Resend: 18 34 07 20 18 c8 20 12 34 47 7a 28 5e ff 00 11 00 08 00
02 e6 53
[ 2471.070417] Recv: 1c 33 00 07 1e 6c 20 10 34 00 20 2c b4 7a 00 11 00 02 01
07 6b 9c
[ 2471.070471] Send: 18 34 07 20 18 c8 20 16 34 47 7a 28 5e ff 00 11 00 08 00
10 d8 4f
[ 2471.480946] Recv: 1c 33 00 07 1e 6c 20 10 34 00 20 2c b4 7a 00 11 00 02 01
07 6b 9c
[ 2471.484298] Recv: 1c 33 00 07 1e 6c 20 14 34 00 20 2c b4 7a 00 11 ca 43
[ 2471.484390] Send: 18 34 07 20 18 c8 20 1a 34 47 7a 28 5e ff 00 11 00 08 00
0f d9 4b
[ 2471.892308] Recv: 1c 33 00 07 1e 6c 20 18 34 00 20 2c b4 7a 00 11 ca 3f
[ 2471.892371] Send: 18 34 07 20 18 c8 20 1e 34 47 7a 28 5e ff 00 11 00 08 00
0e da 47
[ 2472.059123] Resend: 18 34 07 20 18 c8 20 1e 34 47 7a 28 5e ff 00 11 00 08 00
0e da 47
[ 2472.069185] Recv: 1c 33 00 07 1e 6c 20 1c 34 00 20 2c b4 7a 00 11 ca 3b
[ 2472.069201] Send: 18 34 07 20 18 c8 20 22 34 47 7a 28 5e ff 00 11 00 08 00
0d db 43
[ 2472.480090] Recv: 1c 33 00 07 1e 6c 20 1c 34 00 20 2c b4 7a 00 11 ca 3b
[ 2472.483140] Recv: 1c 33 00 07 1e 6c 20 20 34 00 20 2c b4 7a 00 11 ca 37
[ 2472.483230] Send: 18 34 07 20 18 c8 20 26 34 47 7a 28 5e ff 00 11 00 08 00
0c dc 3f
[ 2472.892354] Recv: 1c 33 00 07 1e 6c 20 24 34 00 20 2c b4 7a 00 11 00 0c 01
07 19 2b 36 77 c8 41 44 56 41 4e 3e 88
[ 2472.892428] Send: 18 34 07 20 18 c8 20 2a 34 47 7a 28 5e ff 00 11 00 14 00
0c d0 3b
[ 2473.058147] Resend: 18 34 07 20 18 c8 20 2a 34 47 7a 28 5e ff 00 11 00 14 00
0c d0 3b
[...]
drivers/char/ipmi/ipmi_msghandler.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/ipmi/ipmi_msghandler.c
b/drivers/char/ipmi/ipmi_msghandler.c
index 2c29942..75dfc7f 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -3978,7 +3978,7 @@ static void check_msg_timeout(ipmi_smi_t intf, struct
seq_table *ent,
return;
ent->timeout -= timeout_period;
- if (ent->timeout > 0)
+ if (ent->timeout >= 0)
return;
if (ent->retries_left == 0) {
--
1.7.9.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
