Re: [PATCH v7 1/6] SP800-90A Deterministic Random Bit Generator
Am Samstag, 24. Mai 2014, 05:10:07 schrieb Herbert Xu:
Hi Herbert,
> Stephan Mueller wrote:
> > + memset(_algs[i], 0, sizeof(struct crypto_alg));
> > + if (pr) {
> > + memcpy(drbg_algs[i].cra_name, "drbg(pr(", 8);
> > + memcpy(drbg_algs[i].cra_driver_name, "drbg_pr_", 8);
> > + pos = 8;
>
> You shouldn't use the brackets here since this not a real template.
> Just use one name for both cra_name and cra_driver_name.
Thanks for the hint: I would use the name specified for cra_driver_name also
for cra_name
>
> Cheers,
Ciao
Stephan
--
| Cui bono? |
--
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 clockevents tree with the arm-soc tree
Hi Daniel,
Today's linux-next merge of the clockevents tree got a conflict in
arch/arm/boot/dts/vf610.dtsi between commit 0517fe6aa880 ("ARM: dts:
vf610-twr: Add support for sdhc1") from the arm-soc tree and commit
07513e1330a9 ("ARM: dts: vf610: Add Freescale FlexTimer Module timer
node") from the clockevents 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 arch/arm/boot/dts/vf610.dtsi
index 73355ddc5186,3c91b84066a1..
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@@ -360,17 -347,19 +360,30 @@@
status = "disabled";
};
+ esdhc1: esdhc@400b2000 {
+ compatible = "fsl,imx53-esdhc";
+ reg = <0x400b2000 0x4000>;
+ interrupts = <0 28 0x04>;
+ clocks = < VF610_CLK_IPG_BUS>,
+ < VF610_CLK_PLATFORM_BUS>,
+ < VF610_CLK_ESDHC1>;
+ clock-names = "ipg", "ahb", "per";
+ status = "disabled";
+ };
+
+ ftm: ftm@400b8000 {
+ compatible = "fsl,ftm-timer";
+ reg = <0x400b8000 0x1000 0x400b9000 0x1000>;
+ interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "ftm-evt", "ftm-src",
+ "ftm-evt-counter-en",
"ftm-src-counter-en";
+ clocks = < VF610_CLK_FTM2>,
+ < VF610_CLK_FTM3>,
+ < VF610_CLK_FTM2_EXT_FIX_EN>,
+ < VF610_CLK_FTM3_EXT_FIX_EN>;
+ status = "disabled";
+ };
+
fec0: ethernet@400d {
compatible = "fsl,mvf600-fec";
reg = <0x400d 0x1000>;
signature.asc
Description: PGP signature
Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
Am Samstag, 24. Mai 2014, 05:14:59 schrieb Herbert Xu:
Hi Herbert,
> Stephan Mueller wrote:
> > Hi,
> >
> > the following set of patches implements the deterministic random bit
> > generator (DRBG) specified by SP800-90A.
> >
> > The DRBG implementation offers the following:
> >* All three DRBG types are implemented with a derivation function.
> >* All DRBG types are available with and without prediction
> >resistance.
> >* All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available
> >
> > for the HMAC and Hash DRBGs.
> >
> >* All AES types of AES-128, AES-192 and AES-256 are available for
> >the
> >
> > CTR DRBG.
> >
> >* A self test is implemented with drbg_healthcheck().
> >* The FIPS 140-2 continuous self test is implemented.
> >* Additional cipher primitives, such as Serpent or Twofish, can be
> >
> > added to the DRBG without changing the implementation. The only
> > change necessary is to the DRBG definition given in the cores[]
> > array.
>
> Where is the code that actually uses this?
There are several answers to this.
First: as required by NIST SP800-131A, the ANSI X9.31 DRNG is considered to be
sunset by the end of 2015. The FIPS 140-2 validation part of NIST requires
that ANSI X9.31 DRNGs are not allowed for new validations since the start of
this year and prohibited for revalidations starting next year. The replacement
of ANSI X9.31 is SP800-90A.
The Linux kernel currently implements one DRNG in ansi_cprng.c. This DRNG is
an ANSI X9.31 DRNG. This means, the offered SP800-90A implementation can be
considered a replacement of ansi_cprng.c.
A second aspect is the implementation of the stdrng. Currently, the offered
patch does not include the stdrng selection. I am currently working on the
completion of the addition of the stdrng selection to the offered patch. My
idea is the following: currently, all DRBG types are registered with their own
cra_name. However, there shall be one particular DRBG registered twice. When
registering the instance again, the cra_name shall be "stdrng". In addition,
if the kernel command line contains fips=1, the cra_priority of that stdrng
should be set to 300. That implies that when the kernel resolves the stdrng,
it resolves to get_random_bytes in normal mode, but to the stdrng DRBG in FIPS
mode.
Here some code snippet from my patch I am working on:
if (fips_stdrng) {
memcpy(alg->cra_name, "stdrng", 6);
...
if (fips_stdrng)
alg->cra_priority = 300;
else
alg->cra_priority = 100;
Ciao
Stephan
--
| Cui bono? |
--
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] Input: mc13783-pwrbutton: Allocate resources using managed interfaces
On Sun, May 25, 2014 at 03:44:01PM +0530, Himangi Saraogi wrote:
> This patch moves most data allocated in the probe function from
> unmanaged interfaces to managed interfaces. The kfrees and error
> handling code is done away with. The unnecesary labels are
> removed. Also, linux/device.h is added to make sure the devm_*()
> routine declarations are unambiguously available. The name of label
> free_priv is changed to unlock as it does not free priv anymore.
>
> The following Coccinelle semantic patch was used for making a part of
> the change:
>
> @platform@
> identifier p, probefn, removefn;
> @@
> struct platform_driver p = {
> .probe = probefn,
> .remove = removefn,
> };
>
> @prb@
> identifier platform.probefn, pdev;
> expression e, e1, e2;
> @@
> probefn(struct platform_device *pdev, ...) {
> <+...
> - e = kzalloc(e1, e2)
> + e = devm_kzalloc(>dev, e1, e2)
> ...
> ?-kfree(e);
> ...+>
> }
>
> @rem depends on prb@
> identifier platform.removefn;
> expression e;
> @@
> removefn(...) {
> <...
> - kfree(e);
> ...>
> }
>
> Signed-off-by: Himangi Saraogi
> Acked-by: Julia Lawall
> ---
> Not compiled due to incompatible architecture.
>
> mc13xxx_irq_request is not devm'd, and doing so looks complicated due to
> the locks around the frees. Is there some way to resolve this issue?
Yes there us - let's leave the driver as is so we are not mixing the 2
styles.
Thanks.
--
Dmitry
--
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] input: jornada680_kbd: Allocate resources using managed interfaces
On Sat, May 24, 2014 at 05:47:09PM +0530, Himangi Saraogi wrote: > This patch moves most data allocated in the probe function from > unmanaged interfaces to managed interfaces. The kfrees and error > handling code is done away with. Also, the unnecesary labels are > removed and the function mrstouch_remove is removed as it becomes > empty after removing the no longer required function calls. Also, > linux/device.h is added to make sure the devm_*() routine declarations > are unambiguously available. Applied, thank you. -- Dmitry -- 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] workqueue: remove the unneeded cpu_relax() in __queue_work()
On 05/26/2014 12:23 PM, Tejun Heo wrote: > On Thu, May 22, 2014 at 10:21:25PM +0800, Lai Jiangshan wrote: >> On Thu, May 22, 2014 at 9:47 PM, Tejun Heo wrote: >> This is not busy wait, the retry and numa_pwq_tbl() guarantee that >> the retry will get a new pwq (even without cpu_relax()) as the comments says, > > Yes, *eventually*. It's not guaranteed to succeed on the immediate > next try. This is a busy wait. changing pwq: install pwq lock(pool->lock) put_pwq(); unlock(pool->lock) __queue_work(): lock(pool->lock) test ref and find it zero; see the installation here; it is guaranteed to get the installed pwq on the immediate next try. unlock() retry. > >> and the refcnt of this new pwq is very very likely non-zero and >> cpu_relax() can't >> increase the probability of non-zero-refcnt. cpu_relax() is useless here. >> >> It is different from spin_lock() or some other spin code. >> >> it is similar to the loop of __task_rq_lock() which also guarantees progress. > > No, it's not. __task_rq_lock() *already* sees the updated value to > use for the next time. Here, we see the old one dead and the new one > is guaranteed to show up pretty soon but we're still busy waiting for > it. > -- 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/51] Input: atmel_mxt_ts - Set default irqflags when there is no pdata
On Fri, May 23, 2014 at 12:37:46PM -0400, Yufeng Shen wrote: > On Thu, May 22, 2014 at 10:29 AM, Nick Dyer wrote: > > > > Dmitry Torokhov wrote: > > > On Thu, Jul 18, 2013 at 07:17:44PM +0200, rydb...@euromail.se wrote: > > >>> From: Yufeng Shen > > >>> This is the preparation for supporting the code path when there is > > >>> platform data provided and still boot the device into a sane state > > >>> with backup NVRAM config. > > >>> > > >>> Make the irqflags default to be IRQF_TRIGGER_FALLING if no platform > > >>> data is > > >>> provided. > > > > > > I think if there is no platform data we should use 0 as IRQ falgs and > > > assume that IRQ line is properly configured by the board code or via > > > device tree. > > > > Beson/Yufeng - do you still have a requirement to probe without platform > > data or device tree? I'm just merging in some changes to add device tree > > support, and it would simplify things a bit if I can drop this patch. > > > It has been working for quite a while for boards/devices that don't > provide platform > data. If we drop the default IRQ flags, sure we can add code for each > board to configure > the IRQ separately, but that's just adding extra work. Is there strong > reason why we > should not do the default setting in the driver if it is not already > configured in platform > data ? I am not saying that board code needs to add platform data. I am saying that the board code needs to set up interrupt properly (via irq_set_irq_type() or similar) and then the driver can use 0 as irqflags argument in request_irq() in absence of DT/platform data. Thanks. -- Dmitry -- 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] do_mounts: try all available filesystems before panicking
2014-05-26 7:19 GMT+03:00 Dave Chinner : > On Mon, May 26, 2014 at 11:19:04AM +1000, Dave Chinner wrote: >> On Mon, May 26, 2014 at 10:08:13AM +1000, Dave Chinner wrote: >> > On Sun, May 25, 2014 at 01:04:09PM -0700, Linus Torvalds wrote: >> > > On Mon, May 5, 2014 at 11:34 AM, Plamen Petrov >> > > wrote: >> > > > >> > > > The story short: on systems with btrfs root I have a kernel .config >> > > > with ext4, >> > > > xfs and btrfs built-in which works fine with 3.13.x, but 3.14.x >> > > > panics. After >> > > > inserting some debug printks, I got this info from mount_block_root: >> > > > >> > > > ---> EACCESS=13, EINVAL=22, Available filesystems: ext3 ext2 ext4 >> > > > fuseblk xfs btrfs >> > > > -> Tried ext3, error code is -22. >> > > > -> Tried ext2, error code is -22. >> > > > -> Tried ext4, error code is -22. >> > > > -> Tried fuseblk, error code is -22. >> > > > -> Tried xfs, error code is -38. >> > > > VFS: Cannot open root device "sda2" or unknown-block(8,2): error -38 >> > > > Please append a correct "root=" boot option; here are the available >> > > > partitions: >> >> BTW, This is the original thread with lots of triage in it: >> >> http://www.spinics.net/lists/linux-btrfs/msg33455.html >> >> But that doesn't reach any conclusion. I suspect that the >> change of btrfs init (from very early (@~1.8s into the boot) until a >> few milliseconds before the root mount is changing the order in >> which the filesystem type list is traversed by the mount, resulting >> in XFS being used to probe the device before btrfs. > > On that point, on 3.15-rc6: > > $ tail -1 /proc/filesystems > btrfs > $ > >> Why XFS is seeing /dev/sda2 as containing an XFS filesystem is not >> yet clear, but perhaps once you've dumped the the first sector of >> the btrfs partition all will become clear > > No need, I found the regression. Plamen, can you please try the > patch below? > Yes, Dave. I applied your patch on top of linux 3.15-rc5. I tried the patch you sent in a VM I used for tests. With only your patch applied - the system boots up normally. Thanks for the different perspectives, guys! Always a pleasure communicating with you. After a month or so waiting - definetly worth it! Thanks a lot! -- Plamen Petrov -- 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: balance storm
On Mon, 2014-05-26 at 11:04 +0800, Libo Chen wrote:
> hi,
> my box has 16 cpu (E5-2658,8 core, 2 thread per core), i did a test on
> 3.4.24stable, startup 50 same process, every process is sample:
>
> #include
>
> int main()
> {
> for (;;)
> {
> unsigned int i = 0;
>while (i< 100){
>i++;
> }
> usleep(100);
> }
>
>return 0;
> }
>
> the result is process uses 15% cpu time, perf tool shows 70w migrations in 5
> second.
See e0a79f52 sched: Fix select_idle_sibling() bouncing cow syndrome
That commit will fix expensive as hell bouncing for most real loads, but
it won't fix your test. Doing nothing but wake, select_idle_sibling()
will be traversing all cores/siblings mightily, taking L2 misses as it
traverses, bouncing wakees that do _nothing_ when an idle CPU is found.
Your synthetic test is the absolute worst case scenario. There has to
be work between wakeups for select_idle_sibling() to have any chance
whatsoever of turning in a win. At 0 work, it becomes 100% overhead.
> I guess task migration takes up a lot of cpu, so i did another test. use
> taskset tool to bind
> a task to a fixed cpu. Results in line with expectations, cpu usage is down
> to 5%.
>
> other test:
> - 3.15upstream has the same problem with 3.4.24.
> - suse sp2 has low cpu usage about 5%.
SLE11-SP2 has a patch which fixes that behavior, but of course at the
expense of other load types. A trade. It also throttles nohz, which
can have substantial cost when cross CPU scheduling.
> so I think 15% cpu usage and migration event are too high, how to fixed?
You can't for free, low latency wakeup can be worth one hell of a lot.
You could do a decayed hit/miss or such to shut the thing off when the
price is just too high. Restricting migrations per unit time per task
also helps cut the cost, but hurts tasks that could have gotten to the
CPU quicker, and started your next bit of work. Anything you do there
is going to be a rob Peter to pay Paul thing.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] KVM: x86: use new CS.RPL as CPL during task switch
>> During task switch, all of CS.DPL, CS.RPL, SS.DPL must match (in addition >> to all the other requirements) and will be the new CPL. So far this >> worked by carefully setting the CS selector and flag before doing the > > s/flag/EFLAGS/ > >> task switch; however, this will not work once we get the CPL from SS.DPL: >> setting SS itself would fail if the task switch changes the privilege >> level. > > More precisely, before patch 4 in this series setting CS.selector would > already change the CPL. After it, you actually have to set the full > segment descriptor cache to change the CPL, so we cannot use > ctxt->ops->cpl(ctxt) to retrieve the CPL during a task switch. The > check that fails without this patch is that SS.DPL must be == CPL, and > the failure happens because ctxt->ops->cpl(ctxt) is the *old* SS.DPL. This is informative and answered some of my questions. Thanks. It would be helpful to include such info in patch description. > > Paolo > >> Temporarily assume that the CPL comes from CS.RPL during task switch >> to a protected-mode task. This is the same approach used in QEMU's >> emulation code, which (until version 2.0) manually tracks the CPL. -- 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: Silicom: bpctl_mod.c & bypass.c: Adding blank lines
On Sun, 2014-05-25 at 21:58 -0700, Chaitanya Hazarey wrote:
> Added a blank line after declarations in many places to fix
> the following warning issued by checkpatch.pl:
Unrelated trivial note:
> diff --git a/drivers/staging/silicom/bpctl_mod.c
> b/drivers/staging/silicom/bpctl_mod.c
> @@ -2802,6 +2813,7 @@ int wdt_time_left(struct bpctl_dev *pbpctl_dev)
> static int wdt_timer(struct bpctl_dev *pbpctl_dev, int *time_left)
> {
> int ret = 0;
> +
> if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
> {
> if (pbpctl_dev->wdt_status == WDT_STATUS_UNKNOWN)
unnecessary and ugly double brace
--
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 failure after merge of the devicetree tree
Hi Grant,
After merging the devicetree tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/of/base.c: In function 'of_update_property':
drivers/of/base.c:1906:10: error: 'found' undeclared (first use in this
function)
return found ? 0 : -ENODEV;
^
Caused by a bad automatic merge resolution between commits 582da6527da3
("of: make of_update_property() usable earlier in the boot process")
(merged into Linus' tree between v3.15-rc4 and rc5) and 947fdaad0627
("of: fix race between search and remove in of_update_property()") from
the devicetree tree.
I have added the following merge fix patch:
From: Stephen Rothwell
Date: Mon, 26 May 2014 14:50:40 +1000
Subject: [PATCH] of: fix bad merge of drivers/of/base.c
Signed-off-by: Stephen Rothwell
---
drivers/of/base.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 395ee2b3146d..03e7fc6c93e8 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1901,10 +1901,6 @@ int of_update_property(struct device_node *np, struct
property *newprop)
if (!of_kset)
return 0;
- /* At early boot, bail out and defer setup to of_init() */
- if (!of_kset)
- return found ? 0 : -ENODEV;
-
/* Update the sysfs attribute */
if (oldprop)
sysfs_remove_bin_file(>kobj, >attr);
--
2.0.0.rc4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH] input: gpio_keys: Add IRQF_NO_SUSPEND flag to wake-up from freeze state
Hi Chanwoo, On 26 May 2014 10:27, Chanwoo Choi wrote: > This patch add IRQF_NO_SUSPEND flag before requesting interrupt handler > if button->wakeup is true. If ther interrupt of gpio-keys hasn't included > IRQF_NO_SUSPEND, wouldn't wake-up from freeze state when pressing button. Please refer to the below thread. Looks like it was similar to what you are proposing. http://www.spinics.net/lists/linux-input/msg28780.html -- With warm regards, Sachin -- 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: Silicom: bpctl_mod.c & bypass.c: Adding blank lines
Added a blank line after declarations in many places to fix
the following warning issued by checkpatch.pl:
WARNING: Missing a blank line after declarations
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/silicom/bpctl_mod.c| 88 +++-
drivers/staging/silicom/bypasslib/bypass.c |2 +
2 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/silicom/bpctl_mod.c
b/drivers/staging/silicom/bpctl_mod.c
index e361cde..22bf4bf 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -752,6 +752,7 @@ static void write_reg(struct bpctl_dev *pbpctl_dev,
unsigned char value,
uint32_t ctrl_ext = 0, ctrl = 0;
struct bpctl_dev *pbpctl_dev_c = NULL;
unsigned long flags;
+
if (pbpctl_dev->bp_10g9) {
pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
if (!pbpctl_dev_c)
@@ -927,6 +928,7 @@ static int read_reg(struct bpctl_dev *pbpctl_dev, unsigned
char addr)
#ifdef BP_SYNC_FLAG
unsigned long flags;
+
spin_lock_irqsave(_dev->bypass_wr_lock, flags);
#else
atomic_set(_dev->wdt_busy, 1);
@@ -1563,6 +1565,7 @@ int pulse_set_fn(struct bpctl_dev *pbpctl_dev, unsigned
int counter)
int zero_set_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1588,6 +1591,7 @@ int zero_set_fn(struct bpctl_dev *pbpctl_dev)
int pulse_get2_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1603,6 +1607,7 @@ int pulse_get2_fn(struct bpctl_dev *pbpctl_dev)
int pulse_get1_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1666,6 +1671,7 @@ static struct bpctl_dev *lookup_port(struct bpctl_dev
*dev)
{
struct bpctl_dev *p;
int n;
+
for (n = 0, p = bpctl_dev_arr; n < device_num && p->pdev; n++) {
if (p->bus == dev->bus
&& p->slot == dev->slot
@@ -1843,6 +1849,7 @@ static int bypass_off(struct bpctl_dev *pbpctl_dev)
static int tap_off(struct bpctl_dev *pbpctl_dev)
{
int ret = BP_NOT_CAP;
+
if ((pbpctl_dev->bp_caps & TAP_CAP)
&& (pbpctl_dev->bp_ext_ver >= PXG2TBPI_VER)) {
write_data(pbpctl_dev, TAP_OFF);
@@ -1856,6 +1863,7 @@ static int tap_off(struct bpctl_dev *pbpctl_dev)
static int tap_on(struct bpctl_dev *pbpctl_dev)
{
int ret = BP_NOT_CAP;
+
if ((pbpctl_dev->bp_caps & TAP_CAP)
&& (pbpctl_dev->bp_ext_ver >= PXG2TBPI_VER)) {
write_data(pbpctl_dev, TAP_ON);
@@ -1869,6 +1877,7 @@ static int tap_on(struct bpctl_dev *pbpctl_dev)
static int disc_off(struct bpctl_dev *pbpctl_dev)
{
int ret = 0;
+
if ((pbpctl_dev->bp_caps & DISC_CAP) && (pbpctl_dev->bp_ext_ver >=
0x8)) {
write_data(pbpctl_dev, DISC_OFF);
msec_delay_bp(LATCH_DELAY);
@@ -1881,6 +1890,7 @@ static int disc_off(struct bpctl_dev *pbpctl_dev)
static int disc_on(struct bpctl_dev *pbpctl_dev)
{
int ret = 0;
+
if ((pbpctl_dev->bp_caps & DISC_CAP) && (pbpctl_dev->bp_ext_ver >=
0x8)) {
write_data(pbpctl_dev, /*DISC_ON */ 0x85);
msec_delay_bp(LATCH_DELAY);
@@ -2270,6 +2280,7 @@ static int set_tx(struct bpctl_dev *pbpctl_dev, int
tx_state)
{
int ret = 0, ctrl = 0;
struct bpctl_dev *pbpctl_dev_m;
+
if ((is_bypass_fn(pbpctl_dev)) == 1)
pbpctl_dev_m = pbpctl_dev;
else
@@ -2802,6 +2813,7 @@ int wdt_time_left(struct bpctl_dev *pbpctl_dev)
static int wdt_timer(struct bpctl_dev *pbpctl_dev, int *time_left)
{
int ret = 0;
+
if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
{
if (pbpctl_dev->wdt_status == WDT_STATUS_UNKNOWN)
@@ -3014,6 +3026,7 @@ static int tx_status(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl = 0;
struct bpctl_dev *pbpctl_dev_m;
+
if ((is_bypass_fn(pbpctl_dev)) == 1)
pbpctl_dev_m = pbpctl_dev;
else
@@ -3195,6 +3208,7 @@ static int bypass_change_status(struct bpctl_dev
*pbpctl_dev)
static int bypass_status(struct bpctl_dev *pbpctl_dev)
{
u32 ctrl_ext = 0;
+
if (pbpctl_dev->bp_caps & BP_CAP) {
struct bpctl_dev *pbpctl_dev_b = NULL;
@@ -3323,6 +3337,7 @@ static int dis_bypass_cap_status(struct bpctl_dev
*pbpctl_dev)
static int wdt_programmed(struct bpctl_dev *pbpctl_dev, int *timeout)
{
int ret = 0;
+
if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
if (pbpctl_dev->bp_ext_ver >= PXG2BPI_VER) {
if ((read_reg(pbpctl_dev, STATUS_REG_ADDR)) &
@@ -3386,6 +3401,7 @@ static int tap_flag_status(struct bpctl_dev *pbpctl_dev)
static int
Re: [PATCH] Staging: Silicom: bpctl_mod.c & bypass.c: Adding blank lines
On its way. Chaitanya On Sun, May 25, 2014 at 5:51 PM, Greg KH wrote: > On Sun, May 25, 2014 at 05:36:58PM -0700, Chaitanya Hazarey wrote: >> Added a blank line after declarations in many places to fix the following >> warning issued by checkpatch.pl: > > Always wrap your lines at 72 columns, like git asks you to when you type > in the commit message. > >> WARNING: Missing a blank line after declarations >> >> The reason why it was not applying clean against Greg's tree was that >> bpctl_mod.c had changed in the functions which are a part of this patch. > > This doesn't belong as part of the changelog, right? Please resend and > put it below the --- line, if you want to. > > Can you redo this with the changelog fixed up please? > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] input: gpio_keys: Add IRQF_NO_SUSPEND flag to wake-up from freeze state
This patch add IRQF_NO_SUSPEND flag before requesting interrupt handler
if button->wakeup is true. If ther interrupt of gpio-keys hasn't included
IRQF_NO_SUSPEND, wouldn't wake-up from freeze state when pressing button.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Cc: Dmitry Torokhov
Cc: Sachin Kamat
Cc: Chanwoo Choi
Cc: linux-in...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/input/keyboard/gpio_keys.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys.c
b/drivers/input/keyboard/gpio_keys.c
index 2db1324..40f3963 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -503,6 +503,9 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
if (!button->can_disable)
irqflags |= IRQF_SHARED;
+ if (button->wakeup)
+ irqflags |= IRQF_NO_SUSPEND;
+
error = request_any_context_irq(bdata->irq, isr, irqflags, desc, bdata);
if (error < 0) {
dev_err(dev, "Unable to claim irq %d; error %d\n",
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: CMWQ urgent questions
Hi Tejun, You are the implementor of CMWQ workqueues and I am working on device drivers. In this new workqueues, worker threads are created like: kworker/u4:0 kworker/0:0 OK, with the help of ftrace, we are able to know on which cpu id, it is created. Can we read not from u4:0 or 0:0, the cpuid? As per code, for high priority work queues H is appended. The questions are as follows: 1) what does u4:0 means, does it means this is created from user side?, does it give cpu id on which it is working? I am going to understand the meaning of u4:0. I guess you the best person to explain it. 2) Suppose workqueues are created from device driver init functions, When the user space process (through the ioctl calls) schedule the work, can we know which process scheduled the work on workqueues. Waiting for your help and appreciate your help on this. With Regards, D.Raj -- 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 03/22] clk: sunxi: add "pll6" to sun6i protected clock list
On Mon, May 26, 2014 at 2:48 AM, Maxime Ripard wrote: > On Fri, May 23, 2014 at 03:51:06PM +0800, Chen-Yu Tsai wrote: >> PLL6 is used by some important but undocumented module, most likely >> memory related, such as mbus or the actual memory controller. As we >> do not have a driver for that, add pll6 to the list of protected >> clocks, so that it won't be disabled and leave us with a non-responsive >> system. > > What issue have you seen? Completely unresponsive after PLL6 is gated (on the A23). > The system actually works pretty great on the A31. Does it work when there aren't any other PLL6 consumers? Maybe the boot0 on A31 and A23 setup some DRAM-related modules differently. If the A31 works without protecting PLL6, I'll add a separate list for the A23. Thanks, ChenYu -- 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] wan: time_before()
From: Joe Perches Date: Sun, 25 May 2014 10:58:52 -0700 > On Sun, 2014-05-25 at 19:32 +0200, Manuel Schölling wrote: >> To be future-proof and for better readability the time comparisons are >> modified to use time_before() instead of plain, error-prone math. > > Sensible change, but it seems these should be > udelay(some_constant) instead of a a rather > variable time wait based on a system/config > defined jiffies. Agreed, this code probably wants udelay(10) or something like that. -- 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 v6 0/6] add cpuidle support for Exynos5420
On 19 May 2014 11:10, Chander Kashyap wrote: > Hi Daniel/Kgene, > > On 16 May 2014 13:33, Chander Kashyap wrote: >> Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores. >> >> This patchset adds cpuidle support for Exynos5420 SoC based on >> generic big.little cpuidle driver. >> >> Tested on SMDK5420. >> >> This patch set depends on: >> 1. [PATCH 0/5] MCPM backend for Exynos5420 >>http://www.spinics.net/lists/arm-kernel/msg331100.html >> Changelog is in respective patches. >> Chander Kashyap (5): >> driver: cpuidle-big-little: add of_device_id structure >> arm: exynos: add generic function to calculate cpu number >> cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little >> driver >> driver: cpuidle: cpuidle-big-little: init driver for Exynos5420 >> exynos: cpuidle: do not allow cpuidle registration for Exynos5420 >> mcpm: exynos: populate suspend and powered_up callbacks >> >> arch/arm/mach-exynos/exynos.c|4 +++- >> arch/arm/mach-exynos/mcpm-exynos.c | 36 >> ++ >> arch/arm/mach-exynos/regs-pmu.h |9 + >> drivers/cpuidle/Kconfig.arm |2 +- >> drivers/cpuidle/cpuidle-big_little.c | 12 +++- >> 5 files changed, 60 insertions(+), 3 deletions(-) >> >> -- >> 1.7.9.5 >> > > As dependency patches are merged. If their are no further comment, can > these patches be taken? > ping > -- > with warm regards, > Chander Kashyap -- with warm regards, Chander Kashyap -- 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 17/22] mfd: sun6i-prcm: Add support for Allwinner A23 PRCM
On Mon, May 26, 2014 at 3:14 AM, Maxime Ripard
wrote:
> On Fri, May 23, 2014 at 03:51:20PM +0800, Chen-Yu Tsai wrote:
>> The Allwinner A23 SoC has a PRCM unit like the previous A31 SoC.
>> The differences are the AR100 clock can no longer be modified,
>> and the APB0 clock has different divisors.
>>
>> This patch adds a compatible with a modified subdevice list for
>> the A23.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> .../devicetree/bindings/mfd/sun6i-prcm.txt | 2 +-
>> drivers/mfd/sun6i-prcm.c | 30
>> ++
>> 2 files changed, 31 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
>> b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
>> index 1f5a31f..03c5a55 100644
>> --- a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
>> +++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
>> @@ -4,7 +4,7 @@ PRCM is an MFD device exposing several Power Management
>> related devices
>> (like clks and reset controllers).
>>
>> Required properties:
>> - - compatible: "allwinner,sun6i-a31-prcm"
>> + - compatible: "allwinner,sun6i-a31-prcm" or "allwinner,sun8i-a23-prcm"
>> - reg: The PRCM registers range
>>
>> The prcm node may contain several subdevices definitions:
>> diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
>> index 718fc4d..c96bb6c 100644
>> --- a/drivers/mfd/sun6i-prcm.c
>> +++ b/drivers/mfd/sun6i-prcm.c
>> @@ -76,16 +76,46 @@ static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
>> },
>> };
>>
>> +static const struct mfd_cell sun8i_a23_prcm_subdevs[] = {
>> + {
>> + .name = "sun6i-a31-apb0-clk",
>> + .of_compatible = "allwinner,sun8i-a23-apb0-clk",
>> + .num_resources = ARRAY_SIZE(sun6i_a31_apb0_clk_res),
>> + .resources = sun6i_a31_apb0_clk_res,
>> + },
>> + {
>> + .name = "sun6i-a31-apb0-gates-clk",
>> + .of_compatible = "allwinner,sun6i-a31-apb0-gates-clk",
>> + .num_resources = ARRAY_SIZE(sun6i_a31_apb0_gates_clk_res),
>> + .resources = sun6i_a31_apb0_gates_clk_res,
>> + },
>
> Did I just have a brainfart, or didn't you just introduced an
> sun8i-a23-apb0-gates-clk driver?
My bad, I missed this one. The one in the DT is correct.
It actually works, so I'm a bit confused here.
Which one does the driver core actually use?
> And there's no ar100 and ahb0 clocks ?
The ahb0 is a fixed-factor (1:1) clock. There are no controls for it.
The ar100 clock on the A23 has no controls either, so fixed-factor
clock again.
Thanks,
ChenYu
--
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] workqueue: remove the unneeded cpu_relax() in __queue_work()
On Thu, May 22, 2014 at 10:21:25PM +0800, Lai Jiangshan wrote: > On Thu, May 22, 2014 at 9:47 PM, Tejun Heo wrote: > This is not busy wait, the retry and numa_pwq_tbl() guarantee that > the retry will get a new pwq (even without cpu_relax()) as the comments says, Yes, *eventually*. It's not guaranteed to succeed on the immediate next try. This is a busy wait. > and the refcnt of this new pwq is very very likely non-zero and > cpu_relax() can't > increase the probability of non-zero-refcnt. cpu_relax() is useless here. > > It is different from spin_lock() or some other spin code. > > it is similar to the loop of __task_rq_lock() which also guarantees progress. No, it's not. __task_rq_lock() *already* sees the updated value to use for the next time. Here, we see the old one dead and the new one is guaranteed to show up pretty soon but we're still busy waiting for it. -- tejun -- 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 22/22] ARM: sun8i: dt: Add Ippo-q8h v5 support
On Mon, May 26, 2014 at 3:39 AM, Maxime Ripard
wrote:
> On Fri, May 23, 2014 at 03:51:25PM +0800, Chen-Yu Tsai wrote:
>> The Ippo-q8h is a tablet circiut board commonly found in cheap Android
>> tablets with A23 SoCs. There are at least 2 versions of the board, with
>> different peripherals, such as WiFi chips.
>>
>> This patch add supports for v5 of such boards, which has a ESP8089 WiFi
>> chip (not supported) connected to mmc1.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> arch/arm/boot/dts/Makefile | 2 ++
>> arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts | 51
>> +
>> 2 files changed, 53 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 6967393..f809a53 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -354,6 +354,8 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>> sun7i-a20-cubietruck.dtb \
>> sun7i-a20-i12-tvbox.dtb \
>> sun7i-a20-olinuxino-micro.dtb
>> +dtb-$(CONFIG_MACH_SUN8I) += \
>> + sun8i-a23-ippo-q8h-v5.dtb
>> dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
>> tegra20-iris-512.dtb \
>> tegra20-medcom-wide.dtb \
>> diff --git a/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
>> b/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
>> new file mode 100644
>> index 000..7d0bd97
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
>> @@ -0,0 +1,51 @@
>> +/*
>> + * Copyright 2014 Chen-Yu Tsai
>> + *
>> + * Chen-Yu Tsai
>> + *
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
>> +
>> +/dts-v1/;
>> +/include/ "sun8i-a23.dtsi"
>> +
>> +/ {
>> + model = "Ippo Q8H Dual Core Tablet (v5)";
>> + compatible = "ippo,q8h-v5", "allwinner,sun8i-a23";
>> +
>> + chosen {
>> + bootargs = "earlyprintk console=ttyS0,115200";
>> + };
>
> You should probably add the memory node here too.
OK.
>> +
>> + soc@01c0 {
>> + uart0: serial@01c28000 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pins_a>;
>> + status = "okay";
>> + };
>> +
>> + i2c0: i2c@01c2ac00 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pins_a>;
>> + status = "okay";
>> + };
>> +
>> + i2c1: i2c@01c2b000 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pins_a>;
>> + status = "okay";
>> + };
>
> What are the two i2c busses wired to?
i2c0 has the capacitive touch panel controller gsl1680 @ 0x40.
i2c1 has something (gsensor maybe) connected @ 0x15.
The FEX file lists the gsensor on i2c1, but with the address as 0x18.
I may need to boot back to stock Android to figure it out.
i2c2 has the camera sensor (GC0309) control connected to it @ 0x66.
I didn't list it because I overlooked it, and i2cdetect hangs.
It seems to need AXP PMIC support to activate the regulators.
AFAIK, the kernel doesn't have drivers for these devices,
so how would we list them?
>> + r_uart: serial@01f02800 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_uart_pins_a>;
>> + status = "okay";
>> + };
>> + };
>> +};
>> +
>> --
>> 2.0.0.rc2
>>
>
> Thanks,
> Maxime
Thanks,
ChenYu
--
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] do_mounts: try all available filesystems before panicking
On Mon, May 26, 2014 at 11:19:04AM +1000, Dave Chinner wrote:
> On Mon, May 26, 2014 at 10:08:13AM +1000, Dave Chinner wrote:
> > On Sun, May 25, 2014 at 01:04:09PM -0700, Linus Torvalds wrote:
> > > On Mon, May 5, 2014 at 11:34 AM, Plamen Petrov
> > > wrote:
> > > >
> > > > The story short: on systems with btrfs root I have a kernel .config
> > > > with ext4,
> > > > xfs and btrfs built-in which works fine with 3.13.x, but 3.14.x panics.
> > > > After
> > > > inserting some debug printks, I got this info from mount_block_root:
> > > >
> > > > ---> EACCESS=13, EINVAL=22, Available filesystems: ext3 ext2 ext4
> > > > fuseblk xfs btrfs
> > > > -> Tried ext3, error code is -22.
> > > > -> Tried ext2, error code is -22.
> > > > -> Tried ext4, error code is -22.
> > > > -> Tried fuseblk, error code is -22.
> > > > -> Tried xfs, error code is -38.
> > > > VFS: Cannot open root device "sda2" or unknown-block(8,2): error -38
> > > > Please append a correct "root=" boot option; here are the available
> > > > partitions:
>
> BTW, This is the original thread with lots of triage in it:
>
> http://www.spinics.net/lists/linux-btrfs/msg33455.html
>
> But that doesn't reach any conclusion. I suspect that the
> change of btrfs init (from very early (@~1.8s into the boot) until a
> few milliseconds before the root mount is changing the order in
> which the filesystem type list is traversed by the mount, resulting
> in XFS being used to probe the device before btrfs.
On that point, on 3.15-rc6:
$ tail -1 /proc/filesystems
btrfs
$
> Why XFS is seeing /dev/sda2 as containing an XFS filesystem is not
> yet clear, but perhaps once you've dumped the the first sector of
> the btrfs partition all will become clear
No need, I found the regression. Plamen, can you please try the
patch below?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
xfs: xfs_readsb needs to check for magic numbers
From: Dave Chinner
Commit daba542 ("xfs: skip verification on initial "guess"
superblock read") dropped the use of a veridier for the initial
superblock read so we can probe the sector size of the filesystem
stored in the superblock. It, however, now fails to validate that
what was read initially is actually an XFS superblock and hence will
fail the sector size check and return ENOSYS.
This causes probe-based mounts to fail because it expects XFS to
return EINVAL when it doesn't recognise the superblock format.
cc:
Reported-by: Plamen Petrov
Signed-off-by: Dave Chinner
---
fs/xfs/xfs_mount.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 8d1afb8..2409224 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -327,8 +327,19 @@ reread:
/*
* Initialize the mount structure from the superblock.
*/
- xfs_sb_from_disk(>m_sb, XFS_BUF_TO_SBP(bp));
- xfs_sb_quota_from_disk(>m_sb);
+ xfs_sb_from_disk(sbp, XFS_BUF_TO_SBP(bp));
+ xfs_sb_quota_from_disk(sbp);
+
+ /*
+* If we haven't validated the superblock, do so now before we try
+* to check the sector size and reread the superblock appropriately.
+*/
+ if (sbp->sb_magicnum != XFS_SB_MAGIC) {
+ if (loud)
+ xfs_warn(mp, "Invalid superblock magic number");
+ error = EINVAL;
+ goto release_buf;
+ }
/*
* We must be able to do sector-sized and sector-aligned IO.
@@ -341,11 +352,11 @@ reread:
goto release_buf;
}
- /*
-* Re-read the superblock so the buffer is correctly sized,
-* and properly verified.
-*/
if (buf_ops == NULL) {
+ /*
+* Re-read the superblock so the buffer is correctly sized,
+* and properly verified.
+*/
xfs_buf_relse(bp);
sector_size = sbp->sb_sectsize;
buf_ops = loud ? _sb_buf_ops : _sb_quiet_buf_ops;
--
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 failure after merge of the mmc tree
Hi Chris,
After merging the mmc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/mmc/host/sdhci-s3c.c: In function 'sdhci_s3c_notify_change':
drivers/mmc/host/sdhci-s3c.c:402:25: error: 'struct sdhci_host' has no member
named 'card_tasklet'
Caused by commit 3560db8e247a ("mmc: sdhci: push card_tasklet into
threaded irq handler"). This is the second left over one I found.
Please check for any more (grep is your friend).
I have used the mmc tree from next-20140522 again for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH V3 1/8] cpufreq: cpufreq-cpu0: remove dependency on thermal
On 24 May 2014 18:29, Pavel Machek wrote: > On Fri 2014-05-23 10:03:27, Viresh Kumar wrote: >> On 22 May 2014 20:22, Eduardo Valentin wrote: >> > However, on CPUs that needs thermal managment, it makes sense to have >> > such dependency, from functional perspective. Mainly because scaling >> > frequency and voltage up would be allowed only when thermal management >> > is enabled. >> >> AFAIK, dependencies in KCONFIG are only for fixing compilation time issues. > > I do not think that's correct. Yeah, that what I accepted later as well.. Dependency is whatever without which the module is unusable. And cpufreq-cpu0 is usable without THERMAL and so this dependency should go away.. -- 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 21/22] ARM: sunxi: Add Allwinner A23 dtsi
On Mon, May 26, 2014 at 3:38 AM, Maxime Ripard
wrote:
> On Fri, May 23, 2014 at 03:51:24PM +0800, Chen-Yu Tsai wrote:
>> The Allwinner A23 is a tablet oriented SoC with 2 Cortex-A7 cores
>> and a Mali-400MP2 GPU.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> arch/arm/boot/dts/sun8i-a23.dtsi | 524
>> +++
>> 1 file changed, 524 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun8i-a23.dtsi
>>
>> diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi
>> b/arch/arm/boot/dts/sun8i-a23.dtsi
>> new file mode 100644
>> index 000..1cff087
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun8i-a23.dtsi
>> @@ -0,0 +1,524 @@
>> +/*
>> + * Copyright 2014 Chen-Yu Tsai
>> + *
>> + * Chen-Yu Tsai
>> + *
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> + interrupt-parent = <>;
>> +
>> + aliases {
>> + serial0 =
>> + serial1 =
>> + serial2 =
>> + serial3 =
>> + serial4 =
>> + serial5 = _uart;
>> + };
>> +
>> +
>> + cpus {
>> + enable-method = "allwinner,sun8i-a23";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + cpu@0 {
>> + compatible = "arm,cortex-a7";
>> + device_type = "cpu";
>> + reg = <0>;
>> + clocks = <>;
>> + };
>> +
>> + cpu@1 {
>> + compatible = "arm,cortex-a7";
>> + device_type = "cpu";
>> + reg = <1>;
>> + clocks = <>;
>
> The clocks attributes have not been merged yet.
I'll drop them until they are merged.
>> + };
>> + };
>> +
>> + memory {
>> + reg = <0x4000 0x8000>;
>> + };
>> +
>> + pmu {
>> + compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu";
>> + interrupts = <0 120 4>,
>> + <0 121 4>,
>> + <0 122 4>,
>> + <0 123 4>;
>> + };
>
> The PMU usually have as much interrupts as CPU core, so this is most
> likely wrong.
I see. I just copied the interrupts that were listed in Allwinner sources.
I'll drop the extra 2.
> Also, do you know if the arch timers are usable on the A23?
I tried them (copying the "timer" section from A20 dtsi), but the system
just hangs. I think I'll leave this for a follow up series.
>> +
>> + clocks {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + osc24M: osc24M_clk {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <2400>;
>> + clock-output-names = "osc24M";
>> + };
>> +
>> + osc32k: osc32k_clk {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <32768>;
>> + clock-output-names = "osc32k";
>> + };
>> +
>> + pll1: clk@01c2 {
>> + #clock-cells = <0>;
>> + compatible = "allwinner,sun8i-a23-pll1-clk";
>> + reg = <0x01c2 0x4>;
>> + clocks = <>;
>> + clock-output-names = "pll1";
>> + };
>> +
>> + pll6: clk@01c20028 {
>> + #clock-cells = <1>;
>> + compatible = "allwinner,sun6i-a31-pll6-clk";
>> + reg = <0x01c20028 0x4>;
>> + clocks = <>;
>> + clock-output-names = "pll6_other", "pll6";
>> + };
>> +
>> + cpu: cpu_clk@01c20050 {
>> + #clock-cells = <0>;
>> + compatible = "allwinner,sun4i-a10-cpu-clk";
>> + reg = <0x01c20050 0x4>;
>> +
>> + /*
>> + * PLL1 is listed twice here.
>> + * While it looks suspicious, it's actually documented
>> + * that way both in the datasheet and in the code from
>> + * Allwinner.
>> + */
>> + clocks = <>, <>, <>, <>;
>> + clock-output-names = "cpu";
>> + };
>> +
>> + axi: axi_clk@01c20050 {
>> + #clock-cells = <0>;
>> + /*
>> + * AXI clock on A23 is actually wider,
>> + * but extra bit is useless for
Re: [PATCH V4 2/3] cpufreq: add support for intermediate (stable) frequencies
On 23 May 2014 21:26, Stephen Warren wrote: > Oh OK, I guess the "notify" value is static then, and driver defined, so > this is fine. Correct!! Can you reply on the tegra patch also? So that we can close this thread ASAP? -- 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/22] ARM: sun8i: Add SMP support for the Allwinner A23
On Mon, May 26, 2014 at 3:26 AM, Maxime Ripard
wrote:
> On Fri, May 23, 2014 at 03:51:23PM +0800, Chen-Yu Tsai wrote:
>> The A23 is a dual Cortex-A7. Add the logic to use the IPs used to
>> control the CPU configuration and the CPU power so that we can
>> bring up secondary CPUs at boot.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> arch/arm/mach-sunxi/platsmp.c | 69
>> +++
>> 1 file changed, 69 insertions(+)
>>
>> diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
>> index c53077b..688faaf 100644
>> --- a/arch/arm/mach-sunxi/platsmp.c
>> +++ b/arch/arm/mach-sunxi/platsmp.c
>> @@ -121,3 +121,72 @@ struct smp_operations sun6i_smp_ops __initdata = {
>> .smp_boot_secondary = sun6i_smp_boot_secondary,
>> };
>> CPU_METHOD_OF_DECLARE(sun6i_smp, "allwinner,sun6i-a31", _smp_ops);
>> +
>> +static void __init sun8i_smp_prepare_cpus(unsigned int max_cpus)
>> +{
>> + struct device_node *node;
>> +
>> + node = of_find_compatible_node(NULL, NULL, "allwinner,sun8i-a23-prcm");
>> + if (!node) {
>> + pr_err("Missing A23 PRCM node in the device tree\n");
>> + return;
>> + }
>> +
>> + prcm_membase = of_iomap(node, 0);
>> + if (!prcm_membase) {
>> + pr_err("Couldn't map A23 PRCM registers\n");
>> + return;
>> + }
>> +
>> + node = of_find_compatible_node(NULL, NULL,
>> +"allwinner,sun8i-a23-cpuconfig");
>> + if (!node) {
>> + pr_err("Missing A23 CPU config node in the device tree\n");
>> + return;
>> + }
>> +
>> + cpucfg_membase = of_iomap(node, 0);
>> + if (!cpucfg_membase)
>> + pr_err("Couldn't map A23 CPU config registers\n");
>> +
>> +}
>> +
>> +static int sun8i_smp_boot_secondary(unsigned int cpu,
>> + struct task_struct *idle)
>> +{
>> + u32 reg;
>> +
>> + if (!(prcm_membase && cpucfg_membase))
>> + return -EFAULT;
>> +
>> + spin_lock(_lock);
>> +
>> + /* Set CPU boot address */
>> + writel(virt_to_phys(secondary_startup),
>> +cpucfg_membase + CPUCFG_PRIVATE0_REG);
>> +
>> + /* Assert the CPU core in reset */
>> + writel(0, cpucfg_membase + CPUCFG_CPU_RST_CTRL_REG(cpu));
>> +
>> + /* Assert the L1 cache in reset */
>> + reg = readl(cpucfg_membase + CPUCFG_GEN_CTRL_REG);
>> + writel(reg & ~BIT(cpu), cpucfg_membase + CPUCFG_GEN_CTRL_REG);
>> +
>> + /* Clear CPU power-off gating */
>> + reg = readl(prcm_membase + PRCM_CPU_PWROFF_REG);
>> + writel(reg & ~BIT(cpu), prcm_membase + PRCM_CPU_PWROFF_REG);
>> + mdelay(1);
>> +
>> + /* Deassert the CPU core reset */
>> + writel(3, cpucfg_membase + CPUCFG_CPU_RST_CTRL_REG(cpu));
>> +
>> + spin_unlock(_lock);
>> +
>> + return 0;
>> +}
>> +
>> +struct smp_operations sun8i_smp_ops __initdata = {
>> + .smp_prepare_cpus = sun8i_smp_prepare_cpus,
>> + .smp_boot_secondary = sun8i_smp_boot_secondary,
>> +};
>> +CPU_METHOD_OF_DECLARE(sun8i_smp, "allwinner,sun8i-a23", _smp_ops);
>
> You forgot to document the new enable-method.
I will add it.
> Also, is there any plan to hae a working u-boot? I'd much prefer to
> use PSCI if possible.
IIRC PSCI needs a secure SRAM block to store its program code.
Unfortunately the A23 doesn't have secure SRAM. I think it is
missing other security related features as well.
Or could it just live in generic SRAM, and the kernel marks it
as reserved or something.
Maybe Marc Zyngier (CCed) can shed some light on this?
Cheers,
ChenYu
--
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 09/22] clk: sunxi: Implement A31 PLL6 as a divs clock for 2x output
Hi,
On Mon, May 26, 2014 at 2:56 AM, Maxime Ripard
wrote:
> On Fri, May 23, 2014 at 03:51:12PM +0800, Chen-Yu Tsai wrote:
>> Some clock modules on the A31 use PLL6x2 as one of their inputs.
>> This patch changes the PLL6 implementation for A31 to a divs clock,
>> i.e. clock with multiple outputs that have different dividers.
>>
>> This behavior is consistent with previous SoC's by Allwinner.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> drivers/clk/sunxi/clk-sunxi.c | 11 ++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index 6857c6e..339cabc 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> @@ -496,6 +496,7 @@ static const struct factors_data sun6i_a31_pll6_data
>> __initconst = {
>> .enable = 31,
>> .table = _a31_pll6_config,
>> .getter = sun6i_a31_get_pll6_factors,
>> + .name = "pll6",
>> };
>>
>> static const struct factors_data sun4i_apb1_data __initconst = {
>> @@ -969,6 +970,14 @@ static const struct divs_data pll6_divs_data
>> __initconst = {
>> }
>> };
>>
>> +static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
>> + .factors = _a31_pll6_data,
>> + .ndivs = 1,
>> + .div = {
>> + { .fixed = 2 }, /* P, other */
>> + }
>> +};
>> +
>> /**
>> * sunxi_divs_clk_setup() - Setup function for leaf divisors on clocks
>> *
>> @@ -1108,7 +1117,6 @@ static const struct of_device_id clk_factors_match[]
>> __initconst = {
>> {.compatible = "allwinner,sun4i-a10-pll1-clk", .data =
>> _pll1_data,},
>> {.compatible = "allwinner,sun6i-a31-pll1-clk", .data =
>> _a31_pll1_data,},
>> {.compatible = "allwinner,sun7i-a20-pll4-clk", .data =
>> _a20_pll4_data,},
>> - {.compatible = "allwinner,sun6i-a31-pll6-clk", .data =
>> _a31_pll6_data,},
>> {.compatible = "allwinner,sun4i-a10-apb1-clk", .data =
>> _apb1_data,},
>> {.compatible = "allwinner,sun4i-a10-mod0-clk", .data =
>> _mod0_data,},
>> {.compatible = "allwinner,sun7i-a20-out-clk", .data =
>> _a20_out_data,},
>> @@ -1128,6 +1136,7 @@ static const struct of_device_id clk_div_match[]
>> __initconst = {
>> static const struct of_device_id clk_divs_match[] __initconst = {
>> {.compatible = "allwinner,sun4i-a10-pll5-clk", .data =
>> _divs_data,},
>> {.compatible = "allwinner,sun4i-a10-pll6-clk", .data =
>> _divs_data,},
>> + {.compatible = "allwinner,sun6i-a31-pll6-clk", .data =
>> _a31_pll6_divs_data,},
>
> Can't the PLL6x2 clock just be a fixed-factor-clock? It would make the
> change trivial, and better fit what it actually is.
Sounds good. I was worried there might be an extra output. The A23 manual
lists a SATA PHY output, which I have no idea where it's used.
On the IRC someone (you?) mentioned the A31 doesn't have native SATA.
I'll rework this using a fixed-factor clock.
Thanks
ChenYu
--
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] KVM: lapic: sync highest ISR to hardware apic on EOI
Paolo Bonzini wrote on 2014-05-23:
> When Hyper-V enlightenments are in effect, Windows prefers to issue an
> Hyper-V MSR write to issue an EOI rather than an x2apic MSR write.
> The Hyper-V MSR write is not handled by the processor, and besides
> being slower, this also causes bugs with APIC virtualization. The
> reason is that on EOI the processor will modify the highest in-service
> interrupt (SVI) field of the VMCS, as explained in section 29.1.4 of
> the SDM.
>
Not only SVI update. It also includes ISR and PPR update. During PPR update, a
new pending interrupt may be recognized and inject to guest.
> We need to do the same, and be careful not to muck with the isr_count
> and highest_isr_cache fields that are unused when virtual interrupt
> delivery is enabled.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/lapic.c | 62
> ++---
> 1 files changed, 43 insertions(+), 19 deletions(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 9736529..0069118 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -360,6 +360,8 @@ static inline void apic_clear_irr(int vec, struct
> kvm_lapic *apic)
>
> static inline void apic_set_isr(int vec, struct kvm_lapic *apic)
> {
> + /* Note that we never get here with APIC virtualization enabled. */
> +
> if (!__apic_test_and_set_vector(vec, apic->regs + APIC_ISR))
> ++apic->isr_count;
> BUG_ON(apic->isr_count > MAX_APIC_VECTOR);
> @@ -371,12 +373,48 @@ static inline void apic_set_isr(int vec, struct
> kvm_lapic *apic)
> apic->highest_isr_cache = vec;
> }
>
> +static inline int apic_find_highest_isr(struct kvm_lapic *apic)
> +{
> + int result;
> +
> + /*
> + * Note that isr_count is always 1, and highest_isr_cache
> + * is always -1, with APIC virtualization enabled.
> + */
> + if (!apic->isr_count)
> + return -1;
> + if (likely(apic->highest_isr_cache != -1))
> + return apic->highest_isr_cache;
> +
> + result = find_highest_vector(apic->regs + APIC_ISR);
> + ASSERT(result == -1 || result >= 16);
> +
> + return result;
> +}
> +
> static inline void apic_clear_isr(int vec, struct kvm_lapic *apic)
> {
> - if (__apic_test_and_clear_vector(vec, apic->regs + APIC_ISR))
> + struct kvm_vcpu *vcpu;
> + if (!__apic_test_and_clear_vector(vec, apic->regs + APIC_ISR))
> + return;
> +
> + vcpu = apic->vcpu;
> +
> + /*
> + * We do get here for APIC virtualization enabled if the guest
> + * uses the Hyper-V APIC enlightenment. In this case we may need
> + * to trigger a new interrupt delivery by writing the SVI field;
> + * on the other hand isr_count and highest_isr_cache are unused
> + * and must be left alone.
> + */
> + if (unlikely(kvm_apic_vid_enabled(vcpu->kvm)))
> + kvm_x86_ops->hwapic_isr_update(vcpu->kvm,
> +apic_find_highest_isr(apic));
If there is a pending interrupt, will it be recognized? I am not looking into
the Hyper-V enlightenments code, not sure whether it already covers interrupt
recognition. But if it doesn't do it, then we need to do it.
> + else {
> --apic->isr_count;
> - BUG_ON(apic->isr_count < 0);
> - apic->highest_isr_cache = -1;
> + BUG_ON(apic->isr_count < 0);
> + apic->highest_isr_cache = -1;
> + }
> }
>
> int kvm_lapic_find_highest_irr(struct kvm_vcpu *vcpu)
> @@ -456,22 +494,6 @@ static void pv_eoi_clr_pending(struct kvm_vcpu
> *vcpu)
> __clear_bit(KVM_APIC_PV_EOI_PENDING, >arch.apic_attention);
> }
>
> -static inline int apic_find_highest_isr(struct kvm_lapic *apic)
> -{
> - int result;
> -
> - /* Note that isr_count is always 1 with vid enabled */
> - if (!apic->isr_count)
> - return -1;
> - if (likely(apic->highest_isr_cache != -1))
> - return apic->highest_isr_cache;
> -
> - result = find_highest_vector(apic->regs + APIC_ISR);
> - ASSERT(result == -1 || result >= 16);
> -
> - return result;
> -}
> -
> void kvm_apic_update_tmr(struct kvm_vcpu *vcpu, u32 *tmr)
> {
> struct kvm_lapic *apic = vcpu->arch.apic;
> @@ -1605,6 +1627,8 @@ int kvm_get_apic_interrupt(struct kvm_vcpu *vcpu)
> int vector = kvm_apic_has_interrupt(vcpu);
> struct kvm_lapic *apic = vcpu->arch.apic;
>
> + /* Note that we never get here with APIC virtualization enabled. */
> +
> if (vector == -1)
> return -1;
>
> --
> 1.7.1
Best regards,
Yang
--
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: [Ocfs2-devel] [PATCH] fs: ocfs2: move_extents.c: Fix for possible null pointer dereference
Hi, On 05/23/2014 04:46 AM, Rickard Strandqvist wrote: > There is otherwise a risk of a possible null pointer dereference. > > Was largely found by using a static code analysis program called cppcheck. > > Signed-off-by: Rickard Strandqvist > --- > fs/ocfs2/move_extents.c |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/fs/ocfs2/move_extents.c b/fs/ocfs2/move_extents.c > index 599eb4c..6a8e3c8 100644 > --- a/fs/ocfs2/move_extents.c > +++ b/fs/ocfs2/move_extents.c > @@ -902,11 +902,13 @@ static int ocfs2_move_extents(struct > ocfs2_move_extents_context *context) > struct inode *inode = context->inode; > struct ocfs2_dinode *di; > struct buffer_head *di_bh = NULL; > - struct ocfs2_super *osb = OCFS2_SB(inode->i_sb); > + struct ocfs2_super *osb; > > if (!inode) > return -ENOENT; > > + osb = OCFS2_SB(inode->i_sb); > + > if (ocfs2_is_hard_readonly(osb) || ocfs2_is_soft_readonly(osb)) > return -EROFS; Thanks for your patch, it looks reasonable if we consider it in the context of above function only. However, the inode should not be NULL in any case given that ocfs2_move_extents() is called by ocfs2_ioctl_move_extents() at where the inode is already validated. IMO, maybe we can just get rid of the useless inode pre-checkup, i.e, if (!inode) return -ENOENT; Thanks, -Jeff -- 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 v11 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
EXYNOS5410 is SoC in Samsung's Exynos5 SoC series. Add initial support for this SoC. Signed-off-by: Tarek Dakhran Signed-off-by: Vyacheslav Tyrtov --- arch/arm/mach-exynos/Kconfig |5 + arch/arm/mach-exynos/common.h | 12 ++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 15fa610..d58995c9 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -88,6 +88,11 @@ config SOC_EXYNOS5260 default y depends on ARCH_EXYNOS5 +config SOC_EXYNOS5410 + bool "SAMSUNG EXYNOS5410" + default y + depends on ARCH_EXYNOS5 + config SOC_EXYNOS5420 bool "SAMSUNG EXYNOS5420" default y diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h index 9eb6258..80b90e3 100644 --- a/arch/arm/mach-exynos/common.h +++ b/arch/arm/mach-exynos/common.h @@ -24,6 +24,7 @@ #define EXYNOS4_CPU_MASK 0xFFFE #define EXYNOS5250_SOC_ID 0x4352 +#define EXYNOS5410_SOC_ID 0xE541 #define EXYNOS5420_SOC_ID 0xE542 #define EXYNOS5440_SOC_ID 0xE544 #define EXYNOS5800_SOC_ID 0xE5422000 @@ -42,6 +43,7 @@ IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK) IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK) IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK) IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK) +IS_SAMSUNG_CPU(exynos5410, EXYNOS5410_SOC_ID, EXYNOS5_SOC_MASK) IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK) IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK) IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK) @@ -80,6 +82,12 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK) # define soc_is_exynos5250() 0 #endif +#if defined(CONFIG_SOC_EXYNOS5410) +# define soc_is_exynos5410() is_samsung_exynos5410() +#else +# define soc_is_exynos5410() 0 +#endif + #if defined(CONFIG_SOC_EXYNOS5420) # define soc_is_exynos5420() is_samsung_exynos5420() #else @@ -100,8 +108,8 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK) #define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \ soc_is_exynos4412()) -#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5420() || \ - soc_is_exynos5800()) +#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5410() || \ + soc_is_exynos5420() || soc_is_exynos5800()) void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 2/3] clk: exynos5410: register clocks using common clock framework
The EXYNOS5410 clocks are statically listed and registered
using the Samsung specific common clock helper functions.
Signed-off-by: Tarek Dakhran
Signed-off-by: Vyacheslav Tyrtov
---
.../devicetree/bindings/clock/exynos5410-clock.txt | 45 +
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos5410.c | 209
include/dt-bindings/clock/exynos5410.h | 33
4 files changed, 288 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt
create mode 100644 drivers/clk/samsung/clk-exynos5410.c
create mode 100644 include/dt-bindings/clock/exynos5410.h
diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
new file mode 100644
index 000..aeab635
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
@@ -0,0 +1,45 @@
+* Samsung Exynos5410 Clock Controller
+
+The Exynos5410 clock controller generates and supplies clock to various
+controllers within the Exynos5410 SoC.
+
+Required Properties:
+
+- compatible: should be "samsung,exynos5410-clock"
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5410.h header and can be used in device
+tree sources.
+
+External clock:
+
+There is clock that is generated outside the SoC. It
+is expected that it is defined using standard clock bindings
+with following clock-output-name:
+
+ - "fin_pll" - PLL input clock from XXTI
+
+Example 1: An example of a clock controller node is listed below.
+
+ clock: clock-controller@0x1001 {
+ compatible = "samsung,exynos5410-clock";
+ reg = <0x1001 0x3>;
+ #clock-cells = <1>;
+ };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+ serial@12C2 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12C0 0x100>;
+ interrupts = <0 51 0>;
+ clocks = < CLK_UART0>, < CLK_SCLK_UART0>;
+ clock-names = "uart", "clk_uart_baud0";
+ };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 25646c6..69e8177 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_SOC_EXYNOS3250)+= clk-exynos3250.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5260) += clk-exynos5260.o
+obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
diff --git a/drivers/clk/samsung/clk-exynos5410.c
b/drivers/clk/samsung/clk-exynos5410.c
new file mode 100644
index 000..c9505ab
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos5410.c
@@ -0,0 +1,209 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran
+ *
+ * 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.
+ *
+ * Common Clock Framework support for Exynos5410 SoC.
+*/
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+#define APLL_LOCK 0x0
+#define APLL_CON0 0x100
+#define CPLL_LOCK 0x10020
+#define CPLL_CON0 0x10120
+#define MPLL_LOCK 0x4000
+#define MPLL_CON0 0x4100
+#define BPLL_LOCK 0x20010
+#define BPLL_CON0 0x20110
+#define KPLL_LOCK 0x28000
+#define KPLL_CON0 0x28100
+
+#define SRC_CPU0x200
+#define DIV_CPU0 0x500
+#define SRC_CPERI1 0x4204
+#define DIV_TOP0 0x10510
+#define DIV_TOP1 0x10514
+#define DIV_FSYS1 0x1054c
+#define DIV_FSYS2 0x10550
+#define DIV_PERIC0 0x10558
+#define SRC_TOP0 0x10210
+#define SRC_TOP1 0x10214
+#define SRC_TOP2 0x10218
+#define SRC_FSYS 0x10244
+#define SRC_PERIC0 0x10250
+#define SRC_MASK_FSYS 0x10340
+#define SRC_MASK_PERIC00x10350
+#define GATE_BUS_FSYS0 0x10740
+#define GATE_IP_FSYS 0x10944
+#define GATE_IP_PERIC 0x10950
+#define GATE_IP_PERIS 0x10960
+#define SRC_CDREX 0x20200
+#define SRC_KFC0x28200
+#define DIV_KFC0 0x28500
+
[PATCH v11 0/3] Exynos 5410 support
The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on big.LITTLE architecture Patches add new platform description, support of clock controller and device tree for Exynos 5410. Has been build on Samsung Linux Kernel (branch: for-next, commit: 97eae6c Merge branch 'v3.16-next/multiplatform' into for-next) Has been tested on: 1) Exynos 5410 reference board (exynos_defconfig) 2) Exynos 5410 reference board (multi_v7_defconfig) 3) Odroid-XU board (exynos_defconfig) 4) Odroid-XU board (multi_v7_defconfig) I hope this is clean and would be applied. Tarek. Tarek Dakhran (3): ARM: EXYNOS: Add support for EXYNOS5410 SoC clk: exynos5410: register clocks using common clock framework ARM: dts: Add initial device tree support for EXYNOS5410 .../devicetree/bindings/clock/exynos5410-clock.txt | 45 + arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/exynos5410-smdk5410.dts | 82 arch/arm/boot/dts/exynos5410.dtsi | 206 +++ arch/arm/mach-exynos/Kconfig |5 + arch/arm/mach-exynos/common.h | 12 +- drivers/clk/samsung/Makefile |1 + drivers/clk/samsung/clk-exynos5410.c | 209 include/dt-bindings/clock/exynos5410.h | 33 9 files changed, 592 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts create mode 100644 arch/arm/boot/dts/exynos5410.dtsi create mode 100644 drivers/clk/samsung/clk-exynos5410.c create mode 100644 include/dt-bindings/clock/exynos5410.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 3/3] ARM: dts: Add initial device tree support for EXYNOS5410
Add initial device tree nodes for EXYNOS5410 SoC and SMDK5410 board.
Signed-off-by: Tarek Dakhran
Signed-off-by: Vyacheslav Tyrtov
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/Makefile|1 +
arch/arm/boot/dts/exynos5410-smdk5410.dts | 82
arch/arm/boot/dts/exynos5410.dtsi | 206 +
3 files changed, 289 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts
create mode 100644 arch/arm/boot/dts/exynos5410.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cd399a2..709f862 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -73,6 +73,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
exynos5260-xyref5260.dtb \
+ exynos5410-smdk5410.dtb \
exynos5420-arndale-octa.dtb \
exynos5420-peach-pit.dtb \
exynos5420-smdk5420.dtb \
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
new file mode 100644
index 000..7275bbd
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -0,0 +1,82 @@
+/*
+ * SAMSUNG SMDK5410 board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * 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.
+*/
+
+/dts-v1/;
+#include "exynos5410.dtsi"
+/ {
+ model = "Samsung SMDK5410 board based on EXYNOS5410";
+ compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
+
+ memory {
+ reg = <0x4000 0x8000>;
+ };
+
+ chosen {
+ bootargs = "console=ttySAC2,115200";
+ };
+
+ fin_pll: xxti {
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ clock-output-names = "fin_pll";
+ #clock-cells = <0>;
+ };
+
+ firmware@02037000 {
+ compatible = "samsung,secure-firmware";
+ reg = <0x02037000 0x1000>;
+ };
+
+};
+
+_0 {
+ status = "okay";
+ num-slots = <1>;
+ supports-highspeed;
+ broken-cd;
+ card-detect-delay = <200>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <2 3>;
+ samsung,dw-mshc-ddr-timing = <1 2>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+};
+
+_2 {
+ status = "okay";
+ num-slots = <1>;
+ supports-highspeed;
+ card-detect-delay = <200>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <2 3>;
+ samsung,dw-mshc-ddr-timing = <1 2>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <4>;
+ disable-wp;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
new file mode 100644
index 000..3839c26
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -0,0 +1,206 @@
+/*
+ * SAMSUNG EXYNOS5410 SoC device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SAMSUNG EXYNOS5410 SoC device nodes are listed in this file.
+ * EXYNOS5410 based board files can include this file and provide
+ * values for board specfic bindings.
+ *
+ * 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.
+ */
+
+#include "skeleton.dtsi"
+#include
+
+/ {
+ compatible = "samsung,exynos5410", "samsung,exynos5";
+ interrupt-parent = <>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x0>;
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x1>;
+ };
+
+ CPU2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x2>;
+ };
+
+ CPU3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x3>;
+ };
+ };
+
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
Re: [PATCH] workqueue: remove the unneeded cpu_relax() in __queue_work()
On 05/22/2014 10:21 PM, Lai Jiangshan wrote: > On Thu, May 22, 2014 at 9:47 PM, Tejun Heo wrote: >> On Thu, May 22, 2014 at 04:44:16PM +0800, Lai Jiangshan wrote: >>> When pwq->refcnt == 0, the retrying is guaranteed to make forward-progress. >>> The comment above the code explains it well: >>> >>> /* >>>* pwq is determined and locked. For unbound pools, we could have >>>* raced with pwq release and it could already be dead. If its >>>* refcnt is zero, repeat pwq selection. Note that pwqs never die >>>* without another pwq replacing it in the numa_pwq_tbl or while >>>* work items are executing on it, so the retrying is guaranteed to >>>* make forward-progress. >>>*/ >>> >>> It means the cpu_relax() here is useless and sometimes misleading, >>> it should retry directly and make some progress rather than waste time. >> >> cpu_relax() doesn't have much to do with guaranteeing forward >> progress. It's about giving a breather during busy wait so that the > > This is not busy wait, the retry and numa_pwq_tbl() guarantee that > the retry will get a new pwq (even without cpu_relax()) as the comments says, > and the refcnt of this new pwq is very very likely non-zero and > cpu_relax() can't > increase the probability of non-zero-refcnt. cpu_relax() is useless here. > > It is different from spin_lock() or some other spin code. > > it is similar to the loop of __task_rq_lock() which also guarantees progress. > > Thanks, > Lai Ping. Any comments? > >> waiting cpu doesn't busy loop claiming the same cache lines over and >> over ultimately delaying the event being waited on. If you're doing a >> busy wait, you better use cpu_relax(). >> >> Thanks. >> >> -- >> tejun >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- 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/
balance storm
hi,
my box has 16 cpu (E5-2658,8 core, 2 thread per core), i did a test on
3.4.24stable, startup 50 same process, every process is sample:
#include
int main()
{
for (;;)
{
unsigned int i = 0;
while (i< 100){
i++;
}
usleep(100);
}
return 0;
}
the result is process uses 15% cpu time, perf tool shows 70w migrations in 5
second.
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
4374 root 20 0 6020 332 256 S 15 0.0 0:03.73 a2.out
4371 root 20 0 6020 332 256 S 15 0.0 0:03.71 a2.out
4373 root 20 0 6020 332 256 R 15 0.0 0:03.72 a2.out
4377 root 20 0 6020 332 256 R 15 0.0 0:03.72 a2.out
4389 root 20 0 6020 328 256 S 15 0.0 0:03.71 a2.out
4391 root 20 0 6020 332 256 S 15 0.0 0:03.72 a2.out
4394 root 20 0 6020 332 256 S 15 0.0 0:03.70 a2.out
4398 root 20 0 6020 328 256 S 15 0.0 0:03.71 a2.out
4403 root 20 0 6020 332 256 S 15 0.0 0:03.71 a2.out
4405 root 20 0 6020 328 256 S 15 0.0 0:03.72 a2.out
4407 root 20 0 6020 332 256 S 15 0.0 0:03.73 a2.out
4369 root 20 0 6020 332 256 S 15 0.0 0:03.72 a2.out
4370 root 20 0 6020 332 256 S 15 0.0 0:03.70 a2.out
4372 root 20 0 6020 332 256 S 15 0.0 0:03.71 a2.out
4375 root 20 0 6020 332 256 S 15 0.0 0:03.70 a2.out
4378 root 20 0 6020 332 256 S 15 0.0 0:03.71 a2.out
4379 root 20 0 6020 332 256 S 15 0.0 0:03.71 a2.out
4380 root 20 0 6020 332 256 S 15 0.0 0:03.72 a2.out
4381 root 20 0 6020 332 256 S 15 0.0 0:03.71 a2.out
4383 root 20 0 6020 332 256 S 15 0.0 0:03.69 a2.out
4384 root 20 0 6020 332 256 S 15 0.0 0:03.72 a2.out
4386 root 20 0 6020 332 256 S 15 0.0 0:03.71 a2.out
4387 root 20 0 6020 328 256 S 15 0.0 0:03.70 a2.out
4388 root 20 0 6020 332 256 R 15 0.0 0:03.72 a2.out
4390 root 20 0 6020 332 256 S 15 0.0 0:03.70 a2.out
4392 root 20 0 6020 332 256 S 15 0.0 0:03.72 a2.out
4393 root 20 0 6020 332 256 S 15 0.0 0:03.72 a2.out
4395 root 20 0 6020 332 256 S 15 0.0 0:03.70 a2.out
4396 root 20 0 6020 328 256 S 15 0.0 0:03.71 a2.out
4397 root 20 0 6020 332 256 S 15 0.0 0:03.70 a2.out
4399 root 20 0 6020 332 256 R 15 0.0 0:03.72 a2.out
4400 root 20 0 6020 332 256 S 15 0.0 0:03.71 a2.out
4402 root 20 0 6020 332 256 S 15 0.0 0:03.70 a2.out
4404 root 20 0 6020 332 256 R 15 0.0 0:03.69 a2.out
4406 root 20 0 6020 332 256 S 15 0.0 0:03.71 a2.out
4408 root 20 0 6020 328 256 R 15 0.0 0:03.71 a2.out
4409 root 20 0 6020 332 256 R 15 0.0 0:03.71 a2.out
4410 root 20 0 6020 328 256 S 15 0.0 0:03.72 a2.out
4411 root 20 0 6020 332 256 S 15 0.0 0:03.71 a2.out
===
when i reverts commit 908a3283728d92df36e0c7cd63304fd35e93a8a9:
diff --git a/kernel/sched.c b/kernel/sched.c
index 1874c74..4cdc91c 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -5138,7 +5138,20 @@ EXPORT_SYMBOL(task_nice);
*/
int idle_cpu(int cpu)
{
- return cpu_curr(cpu) == cpu_rq(cpu)->idle;
+ struct rq *rq = cpu_rq(cpu);
+
+ if (rq->curr != rq->idle)
+ return 0;
+
+ if (rq->nr_running)
+ return 0;
+
+#ifdef CONFIG_SMP
+ if (!llist_empty(>wake_list))
+ return 0;
+#endif
+
+ return 1;
}
the result is process uses 3-5% cpu time, perf tool shows only 1k migrations
in 5 second.
root 20 0 6020 328 256 S 5 0.0 2:18.49 a2.out
4469 root 20 0 6020 328 256 S 5 0.0 2:15.93 a2.out
4423 root 20 0 6020 328 256 S 5 0.0 2:14.36 a2.out
4433 root 20 0 6020 332 256 S 5 0.0 2:15.81 a2.out
4466 root 20 0 6020 328 256 S 4 0.0 2:17.62 a2.out
4428 root 20 0
Re: [PATCH 2/9] perf, tools: Add --branch-history option to report v3
On Fri, 23 May 2014 11:11:13 -0700, Andi Kleen wrote:
>> > diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
>> > index 1a2d7fc..e6d8ed0 100644
>> > --- a/tools/perf/builtin-report.c
>> > +++ b/tools/perf/builtin-report.c
>> > @@ -315,8 +315,9 @@ static int report__setup_sample_type(struct report
>> > *rep)
>> >return -EINVAL;
>> >}
>> >if (symbol_conf.use_callchain) {
>> > - ui__error("Selected -g but no callchain data. Did "
>> > - "you call 'perf record' without -g?\n");
>> > + ui__error("Selected -g or --branch-history but no "
>> > +"callchain data. Did\n"
>>
>> An unwanted newline in the message.
>
> It was intentional to make it fit onto a 80 column terminal
Did you mean '\n' after the "Did" or line break after "but no"? I meant
the former is weird.. The 80 column rule (in the source code) is not
applied to user messages AFAIK. And ui__error() also needs to handle
line breaks to fit the message on the screen in a dynamic manner.
>>
>>
>> > +"you call 'perf record' without -g?\n");
>> >return -1;
>> >}
>> >} else if (!rep->dont_use_callchains &&
>> > @@ -631,6 +632,16 @@ parse_branch_mode(const struct option *opt
>> > __maybe_unused,
>> > }
>> >
>> > static int
>> > +parse_branch_call_mode(const struct option *opt __maybe_unused,
>> > +const char *str __maybe_unused, int unset)
>> > +{
>> > + int *branch_mode = opt->value;
>> > +
>> > + *branch_mode = !unset;
>> > + return 0;
>> > +}
>> > +
>> > +static int
>> > parse_percent_limit(const struct option *opt, const char *str,
>> >int unset __maybe_unused)
>> > {
>> > @@ -645,7 +656,7 @@ int cmd_report(int argc, const char **argv, const char
>> > *prefix __maybe_unused)
>> >struct perf_session *session;
>> >struct stat st;
>> >bool has_br_stack = false;
>> > - int branch_mode = -1;
>> > + int branch_mode = -1, branch_call_mode = -1;
>> >int ret = -1;
>> >char callchain_default_opt[] = "fractal,0.5,callee";
>> >const char * const report_usage[] = {
>> > @@ -754,7 +765,11 @@ int cmd_report(int argc, const char **argv, const
>> > char *prefix __maybe_unused)
>> >OPT_BOOLEAN(0, "group", _conf.event_group,
>> >"Show event group information together"),
>> >OPT_CALLBACK_NOOPT('b', "branch-stack", _mode, "",
>> > - "use branch records for histogram filling",
>> > parse_branch_mode),
>> > + "use branch records for per branch histogram filling",
>> > + parse_branch_mode),
>> > + OPT_CALLBACK_NOOPT(0, "branch-history", _call_mode, "",
>> > + "add last branch records to call history",
>> > + parse_branch_call_mode),
>>
>> Looks like it can be a boolean option, or at least can share
>> parse_branch_mode() callback.
>
> No it can't. It's a tristate.
>>
>>
>> >OPT_STRING(0, "objdump", _path, "path",
>> > "objdump binary to use for disassembly and annotations"),
>> >OPT_BOOLEAN(0, "demangle", _conf.demangle,
>> > @@ -804,8 +819,16 @@ repeat:
>> >has_br_stack = perf_header__has_feat(>header,
>> > HEADER_BRANCH_STACK);
>> >
>> > - if (branch_mode == -1 && has_br_stack)
>> > + if (branch_mode == -1 && has_br_stack && branch_call_mode == -1)
>> >sort__mode = SORT_MODE__BRANCH;
>> > + if (branch_call_mode != -1) {
>>
>> s/-1/1/ ?
>
> -1 means not specified by the user.
But what about --no-branch-history?
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 v3] pinctrl: to avoid duplicated calling enable_pinmux_setting for a pin
On 05/26/2014 10:43 AM, f...@marvell.com wrote:
From: Fan Wu
What the patch did:
1.To call pinmux_disable_setting ahead of pinmux_enable_setting in each time of
calling pinctrl_select_state
2.Remove the HW disable operation in in pinmux_disable_setting function.
The reason why to do this is that:
1.To avoid duplicated calling enable_setting operation without disabling
operation which will let Pin's desc->mux_usecount keep being added.
2.The HW pin disable operation is not useful for most of the vendors' platform.
And this can be used to avoid the HW glitch after using the item 1#
modification.
In the following case, the issue can be reproduced:
1)There is a driver need to switch Pin state dynamicly, E.g. b/t "sleep" and
"default" state
2)The Pin setting configuration in DTS node may be like the following one:
component a {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_grp_setting _grp_setting>;
pinctrl-1 = <_grp_setting _grp_setting>;
}
The "c_grp_setting" config node is totaly same, maybe like following one:
c_grp_setting: c_grp_setting {
pinctrl-single,pins = ;
MFP_DEFAULT;
}
3)When switching the Pin state in the following official Pinctrl sequence:
pin = pinctrl_get();
state = pinctrl_lookup_state(wanted_state);
pinctrl_select_state(state);
pinctrl_put();
Test Result:
1)The switch is completed as expectation, that is: component's
Pins configuration are changed according to the description in the
"wanted_state" group setting
2)The "desc->mux_usecount" of corresponding Pins in "c_group" is added without
being
decreased, because the "desc" is for each physical pin while the "setting" is
for each setting node in the DTS.
Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead of enabling
"c_grp_setting" in pinctrl-1, the desc->mux_usecount will be kept added without
any chance to be decreased.
According to the comments in the original code, only the setting, in old state
but not in new state, will be "disable"(calling pinmux_disable_setting), which
is correct logic but not intact. We still need consider case that the setting
is in both old state and new state.
We can do this in the following two ways:
1) Avoid "enable"(calling pinmux_enable_setting) the Same Pins setting
repeatedly.
2) "Disable"(calling pinmux_disable_setting) the "Same Pins setting", actually
two setting instance, ahead of enabling them.
Analysis:
1.The solution 2# is better because it can avoid too much iteration.
2.If we disable all of the setting in the old state and one/ones of the
setting(s) is/are
existed in the new state, the Pin's mux function change may happen when
some SoC vendors defined the "pinctrl-single,function-off" in their DTS file.
old_setting=>disabled_setting=>new_setting.
3.In the pinmux framework, when Pin state is switched, the setting in the old
state should be
marked as "disabled".
Conclusion:
1.To Remove the HW disabling operation to above the glitch mentioned above.
2.Handle the issue mentioned above by disabling all of the settings in old
state and then enable the all of the settings in new state.
Signed-off-by: Fan Wu
Signed-off-by: Stephen Warren
---
drivers/pinctrl/core.c | 24 +---
drivers/pinctrl/pinmux.c |4
2 files changed, 5 insertions(+), 23 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index c0fe609..4445a67 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -989,29 +989,15 @@ int pinctrl_select_state(struct pinctrl *p, struct
pinctrl_state *state)
if (p->state) {
/*
-* The set of groups with a mux configuration in the old state
-* may not be identical to the set of groups with a mux setting
-* in the new state. While this might be unusual, it's entirely
-* possible for the "user"-supplied mapping table to be written
-* that way. For each group that was configured in the old state
-* but not in the new state, this code puts that group into a
-* safe/disabled state.
+* For each pinmux setting in the old state, forget SW's record
+* of mux owner for that pingroup. Any pingroups which are
+* still owned by the new state will be re-acquired by the call
+* to pinmux_enable_setting() in the loop below.
*/
list_for_each_entry(setting, >state->settings, node) {
- bool found = false;
if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
continue;
- list_for_each_entry(setting2, >settings, node) {
- if (setting2->type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- if (setting2->data.mux.group ==
-
Re: [PATCH 1/9] perf, tools: Support handling complete branch stacks as histograms v6
Hi Andi,
On Fri, 23 May 2014 14:35:03 -0700, Andi Kleen wrote:
> On Mon, May 19, 2014 at 05:21:15PM +0900, Namhyung Kim wrote:
>> This is gone with 540476de74c9 ("perf tools: Remove
>> symbol_conf.use_callchain check").
>
> The patchkit applies to tip/perf/core.
The commit 540476de74c9 is also in the tip/perf/core. Please check
machine_resolve_callchain_sample().
>
>> > + * Check for overlap into the callchain.
>> > + * The return address is one off compared to
>> > + * the branch entry. To adjust for this
>> > + * assume the calling instruction is not longer
>> > + * than 8 bytes.
>> > + */
>> > + if (be[i].from < chain->ips[first_call] &&
>> > + be[i].from >= chain->ips[first_call] - 8)
>> > + first_call++;
>>
>> It seems that you need to check chain->ips[first_call] is greater than
>> PERF_CONTEXT_MAX and use such value as the cpumode...
>
> I don't understand the comment. The only IP that gets resolved is the from/to.
> And add_callchain_ip does it own resolution.
>
> Wouldn't make any sense to get it from first_call
Okay, let me explain it this way..
You're checking the branch stack with normal callchain to find overlap
by comparing the 'from' address and the address in chain->ips[]. But
chain->ips[0] doesn't contain a valid address but a PERF_CONTEXT_XXX for
cpumode of subsequent callchains. So the first_call of 0 won't do
anything meaningful for you and it'd still contain overlapped
callchains.
$ perf --version
perf version 3.15.rc4.g816bf8
$ perf record -b -g ./tcall
$ perf report -D | grep -A35 SAMPLE
4748858059190923 0x3608 [0x240]: PERF_RECORD_SAMPLE(IP, 0x1): 31914/31914:
0x81043ffa period: 1 addr: 0
... chain: nr:17
. 0: ff80
. 1: 81043ffa
. 2: 81029d40
. 3: 81025554
. 4: 811246c7
. 5: 81125d69
. 6: 811280dc
. 7: 811a4266
. 8: 811a4bb1
. 9: 811f1a4f
. 10: 811a344c
. 11: 811a49bb
. 12: 811a4ac8
. 13: 811a4d3d
. 14: 81664689
. 15: fe00
. 16: 003153ebca47
... branch stack: nr:16
. 0: 81029d3b -> 81043ff0
. 1: 810280c9 -> 81029d18
. 2: 81043ffd -> 810280be
. 3: ->
. 4: ->
. 5: ->
. 6: ->
. 7: ->
. 8: ->
. 9: ->
. 10: ->
. 11: ->
. 12: ->
. 13: ->
. 14: ->
. 15: ->
As you can see, chain->ips[0] is ff80 (= -128) that is
defined as PERF_CONTEXT_KERNEL. And in this case nr of branch stack is
16 but it's actually 3. I guess you need to ignore 0 entries..
Also perf report seems to fail to resolve symbols/srclines in branch
stack (possibly due to missing cpumode) and find loops.
$ perf report --branch-history --stdio
...
0.00% native_writ [k] native_write_msr_safe [kernel.kallsyms]
|
---0x81043ff0
0x81029d3b
0x81029d18
0x810280c9
0x810280be
0x81043ffd
|
|--99.77%-- 0x81043ff0
| 0x81029d3b
| 0x81029d18
| 0x810280c9
| 0x810280be
| 0x81043ffd
| 0
| 0
| |
| |--91.43%-- native_write_msr_safe +10
| | intel_pmu_enable_all +80
| | x86_pmu_enable +628
| | perf_pmu_enable +39
| | perf_event_context_sched_in +121
| | perf_event_comm +364
| | set_task_comm +102
| | setup_new_exec +129
| | load_elf_binary +1007
| |
| --8.57%-- 0
|
[PATCH v3] pinctrl: to avoid duplicated calling enable_pinmux_setting for a pin
From: Fan Wu
What the patch did:
1.To call pinmux_disable_setting ahead of pinmux_enable_setting in each time of
calling pinctrl_select_state
2.Remove the HW disable operation in in pinmux_disable_setting function.
The reason why to do this is that:
1.To avoid duplicated calling enable_setting operation without disabling
operation which will let Pin's desc->mux_usecount keep being added.
2.The HW pin disable operation is not useful for most of the vendors' platform.
And this can be used to avoid the HW glitch after using the item 1#
modification.
In the following case, the issue can be reproduced:
1)There is a driver need to switch Pin state dynamicly, E.g. b/t "sleep" and
"default" state
2)The Pin setting configuration in DTS node may be like the following one:
component a {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_grp_setting _grp_setting>;
pinctrl-1 = <_grp_setting _grp_setting>;
}
The "c_grp_setting" config node is totaly same, maybe like following one:
c_grp_setting: c_grp_setting {
pinctrl-single,pins = ;
MFP_DEFAULT;
}
3)When switching the Pin state in the following official Pinctrl sequence:
pin = pinctrl_get();
state = pinctrl_lookup_state(wanted_state);
pinctrl_select_state(state);
pinctrl_put();
Test Result:
1)The switch is completed as expectation, that is: component's
Pins configuration are changed according to the description in the
"wanted_state" group setting
2)The "desc->mux_usecount" of corresponding Pins in "c_group" is added without
being
decreased, because the "desc" is for each physical pin while the "setting" is
for each setting node in the DTS.
Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead of enabling
"c_grp_setting" in pinctrl-1, the desc->mux_usecount will be kept added without
any chance to be decreased.
According to the comments in the original code, only the setting, in old state
but not in new state, will be "disable"(calling pinmux_disable_setting), which
is correct logic but not intact. We still need consider case that the setting
is in both old state and new state.
We can do this in the following two ways:
1) Avoid "enable"(calling pinmux_enable_setting) the Same Pins setting
repeatedly.
2) "Disable"(calling pinmux_disable_setting) the "Same Pins setting", actually
two setting instance, ahead of enabling them.
Analysis:
1.The solution 2# is better because it can avoid too much iteration.
2.If we disable all of the setting in the old state and one/ones of the
setting(s) is/are
existed in the new state, the Pin's mux function change may happen when
some SoC vendors defined the "pinctrl-single,function-off" in their DTS file.
old_setting=>disabled_setting=>new_setting.
3.In the pinmux framework, when Pin state is switched, the setting in the old
state should be
marked as "disabled".
Conclusion:
1.To Remove the HW disabling operation to above the glitch mentioned above.
2.Handle the issue mentioned above by disabling all of the settings in old
state and then enable the all of the settings in new state.
Signed-off-by: Fan Wu
Signed-off-by: Stephen Warren
---
drivers/pinctrl/core.c | 24 +---
drivers/pinctrl/pinmux.c |4
2 files changed, 5 insertions(+), 23 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index c0fe609..4445a67 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -989,29 +989,15 @@ int pinctrl_select_state(struct pinctrl *p, struct
pinctrl_state *state)
if (p->state) {
/*
-* The set of groups with a mux configuration in the old state
-* may not be identical to the set of groups with a mux setting
-* in the new state. While this might be unusual, it's entirely
-* possible for the "user"-supplied mapping table to be written
-* that way. For each group that was configured in the old state
-* but not in the new state, this code puts that group into a
-* safe/disabled state.
+* For each pinmux setting in the old state, forget SW's record
+* of mux owner for that pingroup. Any pingroups which are
+* still owned by the new state will be re-acquired by the call
+* to pinmux_enable_setting() in the loop below.
*/
list_for_each_entry(setting, >state->settings, node) {
- bool found = false;
if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
continue;
- list_for_each_entry(setting2, >settings, node) {
- if (setting2->type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- if (setting2->data.mux.group ==
-
Re: [RFC PATCH 2/3] CMA: aggressively allocate the pages on cma reserved memory when not used
On Fri, May 23, 2014 at 05:57:58PM -0700, Laura Abbott wrote: > On 5/12/2014 10:04 AM, Laura Abbott wrote: > > > > I'm going to see about running this through tests internally for comparison. > > Hopefully I'll get useful results in a day or so. > > > > Thanks, > > Laura > > > > We ran some tests internally and found that for our purposes these patches > made > the benchmarks worse vs. the existing implementation of using CMA first for > some > pages. These are mostly androidisms but androidisms that we care about for > having a device be useful. > > The foreground memory headroom on the device was on average about 40 MB > smaller > when using these patches vs our existing implementation of something like > solution #1. By foreground memory headroom we simply mean the amount of memory > that the foreground application can allocate before it is killed by the > Android > Low Memory killer. > > We also found that when running a sequence of app launches these patches had > more high priority app kills by the LMK and more alloc stalls. The test did a > total of 500 hundred app launches (using 9 separate applications) The CMA > memory in our system is rarely used by its client and is therefore available > to the system most of the time. > > Test device > - 4 CPUs > - Android 4.4.2 > - 512MB of RAM > - 68 MB of CMA > > > Results: > > Existing solution: > Foreground headroom: 200MB > Number of higher priority LMK kills (oom_score_adj < 529): 332 > Number of alloc stalls: 607 > > > Test patches: > Foreground headroom: 160MB > Number of higher priority LMK kills (oom_score_adj < 529): > 459 Number of alloc stalls: 29538 > > We believe that the issues seen with these patches are the result of the LMK > being more aggressive. The LMK will be more aggressive because it will ignore > free CMA pages for unmovable allocations, and since most calls to the LMK are > made by kswapd (which uses GFP_KERNEL) the LMK will mostly ignore free CMA > pages. Because the LMK thresholds are higher than the zone watermarks, there > will often be a lot of free CMA pages in the system when the LMK is called, > which the LMK will usually ignore. Hello, Really thanks for testing!!! If possible, please let me know nr_free_cma of these patches/your in-house implementation before testing. I can guess following scenario about your test. On boot-up, CMA memory are mostly used by native processes, because your implementation use CMA first for some pages. kswapd is woken up late since non-CMA free memory is larger than my implementation. And, on reclaiming, the LMK reclaiming memory by killing app process would reclaim movable memory with high probability since cma memory are mostly used by native processes and app processes have just movable memory. This is just my guess. But, if it is true, this is not fair test for this patchset. If possible, could you make nr_free_cma same on both implementation before testing? Moreover, in mainline implementation, the LMK doesn't consider if memory type is CMA or not. Maybe your overall system would be highly optimized for your implementation, so I'm not sure if your testing is appropriate or not for this patchset. Anyway, I would like to optimize this for android. :) Please let me know more about your system. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] do_mounts: try all available filesystems before panicking
On Sun, May 25, 2014 at 05:11:30PM -0400, Theodore Ts'o wrote:
> On Sun, May 25, 2014 at 01:04:09PM -0700, Linus Torvalds wrote:
> >
> > The fact is, I think xfs is just buggy. Returning 38 (ENOSYS) is
> > totally insane. "No such system call"? Somebody is on some bad bad
> > drugs. Not that the mount_block_root() loop and error handling might
> > not be a good thing to perhaps tweak _too_, but at the very least your
> > patch means that now it no longer prints out the error number at all.
>
> There's only a single instance of ENOSYS in fs/xfs/xfs_mount.c:
>
> /*
>* We must be able to do sector-sized and sector-aligned IO.
>*/
> if (sector_size > sbp->sb_sectsize) {
> if (loud)
> xfs_warn(mp, "device supports %u byte sectors (not %u)",
> sector_size, sbp->sb_sectsize);
> error = ENOSYS;
> goto release_buf;
> }
>
> Plamen, does changing the ENOSYS to EINVAL above fix things for you?
>
> > Anyway, I'm also not seeing why that xfs error would be new to 3.14,
> > though.. Adding the XFS people to the cc.
>
> If I had to guess, commit daba5427d is new to 3.14, and it might
> explain the change in behavior.
Yup, it's buggy, though not in an obvious way. I'll have a patch for
it soon.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] swap: Avoid scanning invalidated region for cheap seek
For cheap seek, when we scan the region between si->lowset_bit
and scan_base, if san_base is greater than si->highest_bit, the
scan operation between si->highest_bit and scan_base is not
unnecessary.
This patch can be used to avoid scanning invalidated region for
cheap seek.
Signed-off-by: Chen Yucong
---
mm/swapfile.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index bf8..7f0f27e 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -489,6 +489,7 @@ static unsigned long scan_swap_map(struct swap_info_struct
*si,
{
unsigned long offset;
unsigned long scan_base;
+ unsigned long upper_bound;
unsigned long last_in_cluster = 0;
int latency_ration = LATENCY_LIMIT;
@@ -551,9 +552,11 @@ static unsigned long scan_swap_map(struct swap_info_struct
*si,
offset = si->lowest_bit;
last_in_cluster = offset + SWAPFILE_CLUSTER - 1;
+ upper_bound = (scan_base <= si->highest_bit) ?
+ scan_base : (si->highest_bit + 1);
/* Locate the first empty (unaligned) cluster */
- for (; last_in_cluster < scan_base; offset++) {
+ for (; last_in_cluster < upper_bound; offset++) {
if (si->swap_map[offset])
last_in_cluster = offset + SWAPFILE_CLUSTER;
else if (offset == last_in_cluster) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/13] overlay filesystem v22
Thanks for CC-ing me. Here are some comments. - I have no objection about the 0:0 char-dev whiteout, but you don't have to have the inode for each whiteout. The hardlink is better. In this version, you have now. How about creating a "base" whiteout under workdir at the mount-time? Maybe it is possible by user-space "mount.overlayfs" or kernel-space. When the whiteout meets EMLINK, create a non-hardlink for that target synchronously and re-create the "base" asynchronously. - Is /work always visible to users? If a user accidentally removes it or its children, then some operations will fail. And he cannot recover it anymore. I know it cannot easily happen since its mode is 0. But I am afraid it will be a source of troubles. For example, find(1) or "ls -R /overlayfs" will almost always fail. - If I remember correctly, the length of the dir mutex is held time has been pointed out. This version has still a long mutex held time, a whole copy-up operation includeing lookup, create, copy filedata, copy xattr/attr, and then rename. How about unlock the dir before copying filedata and re-lock and confirm after copying attr? - When two processes copy-up a similar dir hierarcy, for example /dirA/dirB/fileC and /dirA/dirB/dirC/fileD, may a race condition happen? Two processes begin copying-up dirA, first processA succeeds it and second processB fails and returns EIO? - All copy-up operations will be serialized due to lock. - In fstat(2) for a dir, is nlink set to 1 even it is removed? - In readdir, it lookup or getattr to determine whether the found char dev entry is a whiteout or not. I know a char dev is not so many, so this overhead won't be large. But if its name represented "I am a whiteout", then the extra lookup or getattr would be unnecessary. My personal impression for overall is overlayfs starts growing. Also several parts look like towarding aufs. For example, - a means an overlayfs specific work. Aufs has such special dir for copying-up an unlinked file and a pseudo-link. Both are unnecessary for overlayfs because overlayfs copies-up a file in open(2) time, and doesn't support the hardlink between layers. - many small wrapper functions for VFS helpers resemble to aufs too. In aufs, all they have lockdep_off/on. - the internal cache for readdir allocating extra memory. Aufs adopts a simple hashing, while overlayfs uses rbtree. But of course the fundamental design differences between overlayfs and aufs are kept, such as - a name-based union .vs. an inode-aware union - multiple layers - allow users to access the layers directly - etc... If LKML people consider merging overlayfs, then I'd ask to consier aufs too. The basic design is unchanged since when I posted a few years ago. http://marc.info/?l=linux-kernel=123934927611907=2 And latest one is http://aufs.sourceforge.net J. R. Okajima -- 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] spi: rspi: Round up division to avoid slave overclocking
On Thu, May 22, 2014 at 08:07:35PM +0200, Geert Uytterhoeven wrote: > The calculation of the bit rate divider used a standard C division, which > rounds down the quotient. This may lead to a higher bitrate than requested. > Round up to avoid this. > > E.g. on Koelsch, the SPI flash (configured for 30 MHz) was driven at 48.75 > MHz. After this patch it's driven at a safe 24.375 MHz. > > Signed-off-by: Geert Uytterhoeven > --- > Simon: I think you want this in renesas-backports. Thanks, I'll backport it once its been accepted by Mark. > drivers/spi/spi-rspi.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c > index 1fb0ad213324..5639f9529e0b 100644 > --- a/drivers/spi/spi-rspi.c > +++ b/drivers/spi/spi-rspi.c > @@ -266,7 +266,8 @@ static int rspi_set_config_register(struct rspi_data > *rspi, int access_size) > rspi_write8(rspi, rspi->sppcr, RSPI_SPPCR); > > /* Sets transfer bit rate */ > - spbr = clk_get_rate(rspi->clk) / (2 * rspi->max_speed_hz) - 1; > + spbr = DIV_ROUND_UP(clk_get_rate(rspi->clk), > + 2 * rspi->max_speed_hz) - 1; > rspi_write8(rspi, clamp(spbr, 0, 255), RSPI_SPBR); > > /* Disable dummy transmission, set 16-bit word access, 1 frame */ > @@ -302,7 +303,8 @@ static int rspi_rz_set_config_register(struct rspi_data > *rspi, int access_size) > rspi_write8(rspi, rspi->sppcr, RSPI_SPPCR); > > /* Sets transfer bit rate */ > - spbr = clk_get_rate(rspi->clk) / (2 * rspi->max_speed_hz) - 1; > + spbr = DIV_ROUND_UP(clk_get_rate(rspi->clk), > + 2 * rspi->max_speed_hz) - 1; > rspi_write8(rspi, clamp(spbr, 0, 255), RSPI_SPBR); > > /* Disable dummy transmission, set byte access */ > @@ -335,7 +337,7 @@ static int qspi_set_config_register(struct rspi_data > *rspi, int access_size) > rspi_write8(rspi, rspi->sppcr, RSPI_SPPCR); > > /* Sets transfer bit rate */ > - spbr = clk_get_rate(rspi->clk) / (2 * rspi->max_speed_hz); > + spbr = DIV_ROUND_UP(clk_get_rate(rspi->clk), 2 * rspi->max_speed_hz); > rspi_write8(rspi, clamp(spbr, 0, 255), RSPI_SPBR); > > /* Disable dummy transmission, set byte access */ > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] do_mounts: try all available filesystems before panicking
On Mon, May 26, 2014 at 10:08:13AM +1000, Dave Chinner wrote: > On Sun, May 25, 2014 at 01:04:09PM -0700, Linus Torvalds wrote: > > On Mon, May 5, 2014 at 11:34 AM, Plamen Petrov > > wrote: > > > > > > The story short: on systems with btrfs root I have a kernel .config with > > > ext4, > > > xfs and btrfs built-in which works fine with 3.13.x, but 3.14.x panics. > > > After > > > inserting some debug printks, I got this info from mount_block_root: > > > > > > ---> EACCESS=13, EINVAL=22, Available filesystems: ext3 ext2 ext4 fuseblk > > > xfs btrfs > > > -> Tried ext3, error code is -22. > > > -> Tried ext2, error code is -22. > > > -> Tried ext4, error code is -22. > > > -> Tried fuseblk, error code is -22. > > > -> Tried xfs, error code is -38. > > > VFS: Cannot open root device "sda2" or unknown-block(8,2): error -38 > > > Please append a correct "root=" boot option; here are the available > > > partitions: BTW, This is the original thread with lots of triage in it: http://www.spinics.net/lists/linux-btrfs/msg33455.html But that doesn't reach any conclusion. I suspect that the change of btrfs init (from very early (@~1.8s into the boot) until a few milliseconds before the root mount is changing the order in which the filesystem type list is traversed by the mount, resulting in XFS being used to probe the device before btrfs. Why XFS is seeing /dev/sda2 as containing an XFS filesystem is not yet clear, but perhaps once you've dumped the the first sector of the btrfs partition all will become clear Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the nfsd tree
Hi Bruce,
After merging the nfsd tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/nfsd/nfs4proc.c: In function 'warn_on_nonidempotent_op':
fs/nfsd/nfs4proc.c:1861:3: error: implicit declaration of function
'nfsd4_op_name' [-Werror=implicit-function-declaration]
pr_err("unable to encode reply to nonidempotent op %d (%s)\n",
^
Caused by commit 4d332a993e64 ("nfsd4: fix encoding of out-of-space replies").
I have used the nfsd tree from next-20140523 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH] Staging: Silicom: bpctl_mod.c & bypass.c: Adding blank lines
On Sun, May 25, 2014 at 05:36:58PM -0700, Chaitanya Hazarey wrote: > Added a blank line after declarations in many places to fix the following > warning issued by checkpatch.pl: Always wrap your lines at 72 columns, like git asks you to when you type in the commit message. > WARNING: Missing a blank line after declarations > > The reason why it was not applying clean against Greg's tree was that > bpctl_mod.c had changed in the functions which are a part of this patch. This doesn't belong as part of the changelog, right? Please resend and put it below the --- line, if you want to. Can you redo this with the changelog fixed up please? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the samsung tree with the arm-soc tree
Hi all,
On Mon, 26 May 2014 10:17:41 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the samsung tree got a conflict in
> arch/arm/Kconfig.debug between commit 7098cff2a3f4 ("ARM: debug: qcom:
> make UART address selection configuration option") from the arm-soc
> tree and commit 1899de289497 ("ARM: S3C24XX: use generic
> DEBUG_UART_PHY/_VIRT in debug macro") from the samsung 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 arch/arm/Kconfig.debug
> index 6ff3dc661fdd,4678870f8ee8..
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@@ -966,10 -1007,10 +1003,11 @@@ config DEBUG_LL_INCLUD
>DEBUG_IMX51_UART || \
>DEBUG_IMX53_UART ||\
>DEBUG_IMX6Q_UART || \
> - DEBUG_IMX6SL_UART
> -default "debug/msm.S" if DEBUG_MSM_UART
> + DEBUG_IMX6SL_UART || \
> + DEBUG_IMX6SX_UART
> +default "debug/msm.S" if DEBUG_MSM_UART || DEBUG_QCOM_UARTDM
> default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
> + default "debug/s3c24xx.S" if DEBUG_S3C24XX_UART
> default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 ||
> DEBUG_SIRFMARCO_UART1
> default "debug/sti.S" if DEBUG_STI_UART
> default "debug/tegra.S" if DEBUG_TEGRA_UART
> @@@ -1057,8 -1102,7 +1101,8 @@@ config DEBUG_UART_PHY
> default 0xf700 if ARCH_IOP33X
> depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
> DEBUG_LL_UART_EFM32 || \
> - DEBUG_UART_8250 || DEBUG_UART_PL01X || \
> -DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART
> ++DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART \
I forgot the || at the end, sorry. I fixed this up.
> +DEBUG_MSM_UART || DEBUG_QCOM_UARTDM
>
> config DEBUG_UART_VIRT
> hex "Virtual base address of debug UART"
> @@@ -1118,8 -1166,7 +1168,8 @@@
> default 0xff003000 if DEBUG_U300_UART
> default DEBUG_UART_PHYS if !MMU
> depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
> - DEBUG_UART_8250 || DEBUG_UART_PL01X || \
> -DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART
> ++DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART \
Same here.
> +DEBUG_MSM_UART || DEBUG_QCOM_UARTDM
>
> config DEBUG_UART_8250_SHIFT
> int "Register offset shift for the 8250 debug UART"
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[PATCH] Staging: Silicom: bpctl_mod.c & bypass.c: Adding blank lines
Added a blank line after declarations in many places to fix the following
warning issued by checkpatch.pl:
WARNING: Missing a blank line after declarations
The reason why it was not applying clean against Greg's tree was that
bpctl_mod.c had changed in the functions which are a part of this patch.
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/silicom/bpctl_mod.c| 88 +++-
drivers/staging/silicom/bypasslib/bypass.c |2 +
2 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/silicom/bpctl_mod.c
b/drivers/staging/silicom/bpctl_mod.c
index e361cde..22bf4bf 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -752,6 +752,7 @@ static void write_reg(struct bpctl_dev *pbpctl_dev,
unsigned char value,
uint32_t ctrl_ext = 0, ctrl = 0;
struct bpctl_dev *pbpctl_dev_c = NULL;
unsigned long flags;
+
if (pbpctl_dev->bp_10g9) {
pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
if (!pbpctl_dev_c)
@@ -927,6 +928,7 @@ static int read_reg(struct bpctl_dev *pbpctl_dev, unsigned
char addr)
#ifdef BP_SYNC_FLAG
unsigned long flags;
+
spin_lock_irqsave(_dev->bypass_wr_lock, flags);
#else
atomic_set(_dev->wdt_busy, 1);
@@ -1563,6 +1565,7 @@ int pulse_set_fn(struct bpctl_dev *pbpctl_dev, unsigned
int counter)
int zero_set_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1588,6 +1591,7 @@ int zero_set_fn(struct bpctl_dev *pbpctl_dev)
int pulse_get2_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1603,6 +1607,7 @@ int pulse_get2_fn(struct bpctl_dev *pbpctl_dev)
int pulse_get1_fn(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl_ext = 0, ctrl_value = 0;
+
if (!pbpctl_dev)
return -1;
@@ -1666,6 +1671,7 @@ static struct bpctl_dev *lookup_port(struct bpctl_dev
*dev)
{
struct bpctl_dev *p;
int n;
+
for (n = 0, p = bpctl_dev_arr; n < device_num && p->pdev; n++) {
if (p->bus == dev->bus
&& p->slot == dev->slot
@@ -1843,6 +1849,7 @@ static int bypass_off(struct bpctl_dev *pbpctl_dev)
static int tap_off(struct bpctl_dev *pbpctl_dev)
{
int ret = BP_NOT_CAP;
+
if ((pbpctl_dev->bp_caps & TAP_CAP)
&& (pbpctl_dev->bp_ext_ver >= PXG2TBPI_VER)) {
write_data(pbpctl_dev, TAP_OFF);
@@ -1856,6 +1863,7 @@ static int tap_off(struct bpctl_dev *pbpctl_dev)
static int tap_on(struct bpctl_dev *pbpctl_dev)
{
int ret = BP_NOT_CAP;
+
if ((pbpctl_dev->bp_caps & TAP_CAP)
&& (pbpctl_dev->bp_ext_ver >= PXG2TBPI_VER)) {
write_data(pbpctl_dev, TAP_ON);
@@ -1869,6 +1877,7 @@ static int tap_on(struct bpctl_dev *pbpctl_dev)
static int disc_off(struct bpctl_dev *pbpctl_dev)
{
int ret = 0;
+
if ((pbpctl_dev->bp_caps & DISC_CAP) && (pbpctl_dev->bp_ext_ver >=
0x8)) {
write_data(pbpctl_dev, DISC_OFF);
msec_delay_bp(LATCH_DELAY);
@@ -1881,6 +1890,7 @@ static int disc_off(struct bpctl_dev *pbpctl_dev)
static int disc_on(struct bpctl_dev *pbpctl_dev)
{
int ret = 0;
+
if ((pbpctl_dev->bp_caps & DISC_CAP) && (pbpctl_dev->bp_ext_ver >=
0x8)) {
write_data(pbpctl_dev, /*DISC_ON */ 0x85);
msec_delay_bp(LATCH_DELAY);
@@ -2270,6 +2280,7 @@ static int set_tx(struct bpctl_dev *pbpctl_dev, int
tx_state)
{
int ret = 0, ctrl = 0;
struct bpctl_dev *pbpctl_dev_m;
+
if ((is_bypass_fn(pbpctl_dev)) == 1)
pbpctl_dev_m = pbpctl_dev;
else
@@ -2802,6 +2813,7 @@ int wdt_time_left(struct bpctl_dev *pbpctl_dev)
static int wdt_timer(struct bpctl_dev *pbpctl_dev, int *time_left)
{
int ret = 0;
+
if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
{
if (pbpctl_dev->wdt_status == WDT_STATUS_UNKNOWN)
@@ -3014,6 +3026,7 @@ static int tx_status(struct bpctl_dev *pbpctl_dev)
{
uint32_t ctrl = 0;
struct bpctl_dev *pbpctl_dev_m;
+
if ((is_bypass_fn(pbpctl_dev)) == 1)
pbpctl_dev_m = pbpctl_dev;
else
@@ -3195,6 +3208,7 @@ static int bypass_change_status(struct bpctl_dev
*pbpctl_dev)
static int bypass_status(struct bpctl_dev *pbpctl_dev)
{
u32 ctrl_ext = 0;
+
if (pbpctl_dev->bp_caps & BP_CAP) {
struct bpctl_dev *pbpctl_dev_b = NULL;
@@ -3323,6 +3337,7 @@ static int dis_bypass_cap_status(struct bpctl_dev
*pbpctl_dev)
static int wdt_programmed(struct bpctl_dev *pbpctl_dev, int *timeout)
{
int ret = 0;
+
if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
if (pbpctl_dev->bp_ext_ver >= PXG2BPI_VER) {
if
Re: [GIT PULL] SH Driver Updates for v3.15
[ For the benefit of those watching at home ]
Linus pulled this and it was included in v3.15-rc6.
Thanks Linus, Geert and a cast of 1000s.
On Tue, May 13, 2014 at 04:42:04PM +0900, Simon Horman wrote:
> Hi Linus,
>
> Please consider this SH Driver Update for v3.15.
>
> It consists of a single fix for a regression
> introduced in v3.14 by bf98c1eac1d4a6bcf00532e4fa41d8126cd6c187.
>
>
> This is my first pull-request to you for these drivers.
>
> It is my understanding that previously the SH Drivers were maintained by
> Paul Mundt as part of his maintenance of the SH architecture and Renesas
> ARM Based SoCs. These days the SH architecture is orphaned and the Renesas
> ARM Based SoCs are maintained by Magnus Damm and I.
>
> Over the past year or so there have been very few updates to these drivers.
> And the few that have been made have generally been taken by other
> subsystem maintainers as part of larger patchsets. As this patch
> does not fall into that category I would like you to consider pulling it.
>
>
> The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:
>
> Linux 3.15-rc1 (2014-04-13 14:18:35 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> tags/renesas-sh-drivers-for-v3.15
>
> for you to fetch changes up to 3c90c55dcde745bed81f6447f24ba96bda43d984:
>
> drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
> (2014-05-12 16:05:01 +0900)
>
>
> SH Driver Updates for v3.15
>
> * Compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
>
>
> Geert Uytterhoeven (1):
> drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
>
> drivers/Makefile| 2 +-
> drivers/sh/Makefile | 14 --
> drivers/sh/pm_runtime.c | 20 +++-
> 3 files changed, 28 insertions(+), 8 deletions(-)
>
>
> The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:
>
> Linux 3.15-rc1 (2014-04-13 14:18:35 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> tags/renesas-sh-drivers-for-v3.15
>
> for you to fetch changes up to 3c90c55dcde745bed81f6447f24ba96bda43d984:
>
> drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
> (2014-05-12 16:05:01 +0900)
>
>
> SH Driver Update for v3.15
>
> * Compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
>
> This resolves a regression introduced in v3.14 by
> bf98c1eac1d4a6 ("ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY").
>
>
> Geert Uytterhoeven (1):
> drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI
>
> drivers/Makefile| 2 +-
> drivers/sh/Makefile | 14 --
> drivers/sh/pm_runtime.c | 20 +++-
> 3 files changed, 28 insertions(+), 8 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/
Re: [PATCH v3] staging: lustre: lnet: klnds: Fix coding style in socklnd.c
On Mon, May 26, 2014 at 12:57:39AM +0100, Masaru Nomura wrote: > > What _branch_ of that git tree did you make it against? > > > > I did my work against > > commit 4b660a7f5c8099d88d1a43d8ae138965112592c7 That is a commit, not a branch. Please work against the staging-next branch, not master. master reflects Linus's tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: remap_file_pages() use
On Mon, May 19, 2014 at 9:38 AM, Christoph Hellwig wrote: > On Mon, May 19, 2014 at 05:35:40PM +0300, Kirill A. Shutemov wrote: >> >From functional POV, emulation *should* be identical to original >> remap_file_pages(), but slower. It would be nice, if you test it early. >> >> It's not clear yet how long emulation will be there. > > Stop right there. We found out about two real life users of > remap_file_pages() already, without even committing the patches to warn > about using it to any tree. > > I think at this point the whole idea of removing the API should be dead > on the floor, as we do not needlessly break userspace programs. > > If we can get rid of the ugly guts and provide a good enough emulation > that the user won't cry I'd love to get rid of this cruft, but even > that doesn't look certain yet. Sorry for being late to the party, but I just noticed this proposal via the LWN summary byline. I wanted to comment that Kenny's use case is (I believe) quite widespread. I've used the technique since ~2008, and I've come across other people in subsequent jobs who independently developed the same technique. Mirrored mapping is absolutely required by several independent proprietary platforms I'm aware of, and remap_file_pages() has historically been the only sane way to accomplish this. (i.e., shm_open(), mmap(NULL, 2^(n+1) pages), remap_file_pages() on 2nd half). It may not be individuals who are involved in the kernel development scene to any great extent, but I am sure that remap_file_pages() being deprecated would seriously piss off a lot of individuals. The pattern has even had a section in the Wikipedia article for quite some time: http://en.wikipedia.org/wiki/Circular_buffer#Mirroring It would be most preferable from a user standpoint to keep the existing system intact, but failing that, a reservation API would need to be created (possibly a MAP_RESERVE flag) that would set aside a region that could only be subsequently mapped via explicit address-requesting mmap() calls. Thanks for any consideration of these concerns. --Jeff -- 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 samsung tree with the arm-soc tree
Hi Kukjin,
Today's linux-next merge of the samsung tree got a conflict in
arch/arm/Kconfig.debug between commit 7098cff2a3f4 ("ARM: debug: qcom:
make UART address selection configuration option") from the arm-soc
tree and commit 1899de289497 ("ARM: S3C24XX: use generic
DEBUG_UART_PHY/_VIRT in debug macro") from the samsung 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 arch/arm/Kconfig.debug
index 6ff3dc661fdd,4678870f8ee8..
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@@ -966,10 -1007,10 +1003,11 @@@ config DEBUG_LL_INCLUD
DEBUG_IMX51_UART || \
DEBUG_IMX53_UART ||\
DEBUG_IMX6Q_UART || \
- DEBUG_IMX6SL_UART
- default "debug/msm.S" if DEBUG_MSM_UART
+ DEBUG_IMX6SL_UART || \
+ DEBUG_IMX6SX_UART
+ default "debug/msm.S" if DEBUG_MSM_UART || DEBUG_QCOM_UARTDM
default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
+ default "debug/s3c24xx.S" if DEBUG_S3C24XX_UART
default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 ||
DEBUG_SIRFMARCO_UART1
default "debug/sti.S" if DEBUG_STI_UART
default "debug/tegra.S" if DEBUG_TEGRA_UART
@@@ -1057,8 -1102,7 +1101,8 @@@ config DEBUG_UART_PHY
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
DEBUG_LL_UART_EFM32 || \
- DEBUG_UART_8250 || DEBUG_UART_PL01X || \
- DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART
++ DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART \
+ DEBUG_MSM_UART || DEBUG_QCOM_UARTDM
config DEBUG_UART_VIRT
hex "Virtual base address of debug UART"
@@@ -1118,8 -1166,7 +1168,8 @@@
default 0xff003000 if DEBUG_U300_UART
default DEBUG_UART_PHYS if !MMU
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
- DEBUG_UART_8250 || DEBUG_UART_PL01X || \
- DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART
++ DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART \
+ DEBUG_MSM_UART || DEBUG_QCOM_UARTDM
config DEBUG_UART_8250_SHIFT
int "Register offset shift for the 8250 debug UART"
signature.asc
Description: PGP signature
Re: [PATCH] Staging: Silicom: bpctl_mod.c & bypass.c: Fixed a lot of checkpatch.pl warnings
OK sure, will do Dan. Greg, the patch has some issues, I did sync to your staging-next branch and am having issues applying it. Will send an update when i am able to do it. Thanks, Chaitanya On Sun, May 25, 2014 at 3:30 PM, Dan Carpenter wrote: > Since you're redoing this one anyway, please use a more specific subject > like: > > [PATCH] Staging: Silicom: bpctl_mod.c & bypass.c: add blank lines > > regards, > dan carpenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] do_mounts: try all available filesystems before panicking
On Sun, May 25, 2014 at 01:04:09PM -0700, Linus Torvalds wrote: > On Mon, May 5, 2014 at 11:34 AM, Plamen Petrov wrote: > > > > The story short: on systems with btrfs root I have a kernel .config with > > ext4, > > xfs and btrfs built-in which works fine with 3.13.x, but 3.14.x panics. > > After > > inserting some debug printks, I got this info from mount_block_root: > > > > ---> EACCESS=13, EINVAL=22, Available filesystems: ext3 ext2 ext4 fuseblk > > xfs btrfs > > -> Tried ext3, error code is -22. > > -> Tried ext2, error code is -22. > > -> Tried ext4, error code is -22. > > -> Tried fuseblk, error code is -22. > > -> Tried xfs, error code is -38. > > VFS: Cannot open root device "sda2" or unknown-block(8,2): error -38 > > Please append a correct "root=" boot option; here are the available > > partitions: So, XFS returned ENOSYS to the mount attempt. That means it found what appears to be a valid XFS superblock at block zero. That is, the magic number matched, the version was valid, all of the sanity checks of the values are within supported ranges, and the reason the mount failed was either a block size larger than page size or an unsupported inode size. There would have been an error in dmesg to tell you which. Can you please send the dmesg output of the failed mount attempt, as well as the output of: # dd if=/dev/sda2 bs=512 count=1 | hexdump -C So we can determine exactly why XFS thought it should be mounting that block device? > > Last one tried is xfs, the needed btrfs in this case never gets a chance. > > Looking at the code in init/do_mounts.c we can see that it "continue"s only > > if > > the return code it got is EINVAL, yet xfs clearly does not fit - so the > > kernel > > panics. Maybe there are other filesystems like xfs - I did not check. This > > patch fixes mount_block_root to try all available filesystems first, and > > then > > panic. The patched 3.14.x works for me. > > Hmm. I don't really dislike your patch, but it makes all the code > _after_ the switch-statement dead, since there is now no way to ever > fall through the switch statement. I don't think the patch addresses the cause of the problem. The code is trying to "mount the first filesystem type it finds that matches", but that match has resulted in a "filesystem cannot be mounted" error. The cause of the problem is that there's a difference between "don't understand what is on disk" and "understand exactly what is on disk and we don't support it". If we find a superblock match, then there is no other filesystem type that should be checked regardless of the error that is returned to upper loop. The loop should only continue if the filesystem doesn't recognise what is on disk (i.e. EINVAL) is returned. If it matches, then the filesystem must try to mount the filesystem. What do you expect a filesystem to do if it has an error during mount? It's going to return something other than EINVAL. It could be ENOMEM, EIO, etc, and those cases should terminate the "search until we find a match" loop. So, from that persepective the change is simply wrong. > The fact is, I think xfs is just buggy. Returning 38 (ENOSYS) is > totally insane. "No such system call"? Somebody is on some bad bad > drugs. Not that the mount_block_root() loop and error handling might > not be a good thing to perhaps tweak _too_, but at the very least your > patch means that now it no longer prints out the error number at all. Sure, the error might be silly, but it's irrelevant to the patch being discussed because it could have been one of several different errors that a failed mount could return. And, besides, XFS has returned that error for this condition for, well, more than 10 years: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=archive/xfs-import.git;a=commitdiff;h=ba4331892d608b4e816b52a4de29693af0dd5c13 IOWs, ENOSYS in this case effectively means "system does not support filesystem configuration". It's not an invalid superblock (EINVAL) nor is it a corrupted superblock (EFSCORRUPTED), so it's something else... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IPC initialize shmmax and shmall from the current value not the default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Manfred, On 05/25/2014 11:01 PM, Manfred Spraul wrote: > Hi Marian, > > On 05/22/2014 03:01 PM, Marian Marinov wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 05/05/2014 10:59 PM, Marian Marinov wrote: >>> >>> In my tests it worked exactly as expected. Here is an example: >>> >>> [root@sp2 ~]# sysctl -a|grep shmmax kernel.shmmax = 68719476736 [root@sp2 >>> ~]# lxc-attach -n cent_plain >>> [root@localhost ~]# sysctl -a|grep shmmax kernel.shmmax = 68719476736 >>> [root@localhost ~]# halt [root@sp2 ~]# >>> sysctl -a|grep shmmax kernel.shmmax = 68719476736 [root@sp2 ~]# sysctl >>> kernel.shmmax=34359738368 kernel.shmmax >>> = 34359738368 [root@sp2 ~]# lxc-start -n cent_plain -d [root@sp2 ~]# >>> lxc-attach -n cent_plain [root@localhost >>> ~]# sysctl -a|grep shmmax kernel.shmmax = 34359738368 [root@localhost ~]# >>> >>> So it seams to work as expected :) >>> >>> It works because wen you setup a new shmmax limit it is actually the limit >>> in the init_ipc_ns. So when we are >>> creating a new ipc_ns its ok to copy the values from init_ipc_ns. >>> >>> -Marian >>> >> Ping? >> >> So will there be any more comments on that? >> >> It seams logical. I like your approach even better. I'll test it tomorrow to confirm if all of my tests are successful. Marian > Attached is an untested idea: - each new namespace copies from it's parent, > i.e. nested namespaces should work. - > msg, sem and shm updated > > -- Manfred - -- Marian Marinov Founder & CEO of 1H Ltd. Jabber/GTalk: hack...@jabber.org ICQ: 7556201 Mobile: +359 886 660 270 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlOCha4ACgkQ4mt9JeIbjJTMvwCdGHV2R7Y1H7x14n53Vyihg5AB 2k4Anjp6inQsGjvof2MAx9Sh2/1K3L25 =QTO9 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] staging: lustre: lnet: klnds: Fix coding style in socklnd.c
> What _branch_ of that git tree did you make it against? > I did my work against commit 4b660a7f5c8099d88d1a43d8ae138965112592c7 Thank you, Masaru -- 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] gpio: gpiolib: set gpiochip_remove retval to void
On Mon, May 26, 2014 at 1:40 AM, abdoulaye berthe wrote:
> Well, ignoring the return value as it is done in gpio-bt8xx makes the
> compiler complain and display a warning message. The problem with
> false warning is that it might distract you.
Isn't the warning due to the __must_check in the function's
declaration? If so just removing it might do the trick...
> I think that the patch
> will makes things consistent once completed
Yeah fundamentally speaking I am not against this patch - I just
wonder if it is worth going through all the call sites and changing
them. Also we cannot exclude that a few users actually make something
meaningful with the return value (don't know what that would be
though).
> Thanks a lot for the review.
>
> On Sun, May 25, 2014 at 9:46 AM, Alexandre Courbot wrote:
>> On Sat, May 24, 2014 at 2:12 AM, abdoulaye berthe
>> wrote:
>>> This avoids handling gpiochip remove error in device
>>> remove handler.
>>
>> Be aware that at the moment many callers of gpiochip_remove() read its
>> return value. So applying your patch as-is would break compilation.
>>
>> This patch should therefore be the last of a series that first
>> modifies all callers of gpiochip_remove() to ignore its return value,
>> then neutralizes the function itself.
>>
>> I am not sure whether the world would really be a better place after
>> this though. Callers that don't need the return value of
>> gpiochip_remove() can simply ignore it...
>>
>>>
>>> Signed-off-by: abdoulaye berthe
>>> ---
>>> drivers/gpio/gpiolib.c | 24 +++-
>>> include/linux/gpio/driver.h | 2 +-
>>> 2 files changed, 8 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>>> index f48817d..4878980 100644
>>> --- a/drivers/gpio/gpiolib.c
>>> +++ b/drivers/gpio/gpiolib.c
>>> @@ -1263,10 +1263,9 @@ static void gpiochip_irqchip_remove(struct gpio_chip
>>> *gpiochip);
>>> *
>>> * A gpio_chip with any GPIOs still requested may not be removed.
>>> */
>>> -int gpiochip_remove(struct gpio_chip *chip)
>>> +void gpiochip_remove(struct gpio_chip *chip)
>>> {
>>> unsigned long flags;
>>> - int status = 0;
>>> unsignedid;
>>>
>>> acpi_gpiochip_remove(chip);
>>> @@ -1278,24 +1277,15 @@ int gpiochip_remove(struct gpio_chip *chip)
>>> of_gpiochip_remove(chip);
>>>
>>> for (id = 0; id < chip->ngpio; id++) {
>>> - if (test_bit(FLAG_REQUESTED, >desc[id].flags)) {
>>> - status = -EBUSY;
>>> - break;
>>> - }
>>> - }
>>> - if (status == 0) {
>>> - for (id = 0; id < chip->ngpio; id++)
>>> - chip->desc[id].chip = NULL;
>>> -
>>> - list_del(>list);
>>> + if (test_bit(FLAG_REQUESTED, >desc[id].flags))
>>> + panic("gpiolib.c: gpiochip is still requested\n");
>>
>> panic() sounds a little harsh here. Maybe a dev_err() would be enough?
>>
>>> }
>>> + for (id = 0; id < chip->ngpio; id++)
>>> + chip->desc[id].chip = NULL;
>>>
>>> + list_del(>list);
>>> spin_unlock_irqrestore(_lock, flags);
>>> -
>>> - if (status == 0)
>>> - gpiochip_unexport(chip);
>>> -
>>> - return status;
>>> + gpiochip_unexport(chip);
>>> }
>>> EXPORT_SYMBOL_GPL(gpiochip_remove);
>>>
>>> diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
>>> index 1827b43..72ed256 100644
>>> --- a/include/linux/gpio/driver.h
>>> +++ b/include/linux/gpio/driver.h
>>> @@ -138,7 +138,7 @@ extern const char *gpiochip_is_requested(struct
>>> gpio_chip *chip,
>>>
>>> /* add/remove chips */
>>> extern int gpiochip_add(struct gpio_chip *chip);
>>> -extern int __must_check gpiochip_remove(struct gpio_chip *chip);
>>> +void gpiochip_remove(struct gpio_chip *chip);
>>
>> "extern" should be preserved here for style consistency.
--
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: inotify, new idea?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/24/2014 03:34 PM, Richard Weinberger wrote: > Am 24.05.2014 09:52, schrieb Michael Kerrisk (man-pages): >> On 04/21/2014 10:42 AM, Richard Weinberger wrote: >>> Am 21.04.2014 09:24, schrieb Michael Kerrisk: > Does recursive monitoring even work with inotify? Last time I've tried it > did failed as soon I did a mkdir > -p a/b/c/d because mkdir() raced against the thread which installes the > new watches. As I understand it, you have to program to deal with the races (rescan directories after adding watches). I recently did a lot of work updating the inotify(7) man page to discuss all the issues that I know of, and their remedies. If I missed anything, I'd appreciate a note on it, so that it can be added. See http://man7.org/linux/man-pages/man7/inotify.7.html#NOTES >>> >>> I'm aware of the rescan hack, but in my case it does not help because my >>> program must not miss any event. >>> Currently I'm using a fuse overlay filesystem to log everything. Not >>> perfect but works... :-) >> >> Richard, >> >> A late follow up question. How does your application deal with the event >> overflow problem (i.e., when you get a >> large number of events much faster than your application can deal with them? > > The downside of the FUSE approach is that you have to intercept every > filesystem function. This can be a > performance issue. But due to this design the overflow problem cannot happen > as the FUSE filesystem blocks until > the event has been proceed. > Have anyone of you looked at this: https://github.com/1and1/linux-filemon/ I haven't stress tested it, but in the past I ported it to more recent kernels: https://github.com/hackman/filemon-patches It is not polished, but it works. I'm considering fixing some of the issues at has for use in my home setup. Marian > Thanks, //richard -- To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in the body of a > message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html Please read > the FAQ at http://www.tux.org/lkml/ > - -- Marian Marinov Founder & CEO of 1H Ltd. Jabber/GTalk: hack...@jabber.org ICQ: 7556201 Mobile: +359 886 660 270 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlOCgOwACgkQ4mt9JeIbjJSXrgCdHCFADxvKN3Hxb4qinc/5Fj6V WYMAnArk3Zb8YqTUNoyNCh1zYplUUx9B =y/Sm -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v2 0/4] mfd: Intel SoC Power Management IC
On 5/23/2014 6:08 PM, Lee Jones wrote: > > Why are you re-sending this? > Hi, My mail server reported that it failed to send [PATCH v2 1/4] to LKML, so I resent the whole series, only to get it properly archived. Sorry for the confusion. Best Regards Lejun -- 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 3.15-rc7
.. and with this, I'm back on my usual Sunday schedule. It's just a few days after -rc6, but as expected, there were some pending stuff for when I got back home, so you should think of this as being the "normal" release, and rc6 just having been oddly delayed by my travel. The bulk of this is (by far) the networking changes (mostly drivers), since most other trees had synced up for rc6, but there are various smaller things in here too: drm, scheduler, perf, nfsd, afs etc. Linus --- Alex Deucher (4): drm/radeon: fix DCE83 check for mullins drm/radeon: handle non-VGA class pci devices with ATRM drm/radeon: fix register typo on si drm/radeon/pm: don't allow debugfs/sysfs access when PX card is off (v2) Alexander Bondar (1): iwlwifi: mvm: several fixes in scan Alexei Starovoitov (1): net: filter: x86: fix JIT address randomization Antonio Quartulli (3): batman-adv: fix reference counting imbalance while sending fragment batman-adv: increase orig refcount when storing ref in gw_node batman-adv: fix local TT check for outgoing arp requests in DAT Ben Skeggs (1): drm/gf119-/disp: fix nasty bug which can clobber SOR0's clock setup Bjørn Mork (2): net: cdc_mbim: __vlan_find_dev_deep need rcu_read_lock net: cdc_mbim: handle unaccelerated VLAN tagged frames Bob Copeland (1): mac80211: fixup radiotap tx flags for RTS/CTS Chen Yucong (1): hwpoison, hugetlb: lock_page/unlock_page does not match for handling a free hugepage Christian König (4): drm/radeon: also try GART for CPU accessed buffers drm/radeon: fix page directory update size estimation drm/radeon: fix buffer placement under memory pressure v2 drm/radeon: fix typo in finding PLL params Chun-Yeow Yeoh (1): mac80211: avoid handling of SMPS for mesh Cong Wang (5): ipv4: move local_port_range out of CONFIG_SYSCTL ping: move ping_group_range out of CONFIG_SYSCTL rtnetlink: wait for unregistering devices in rtnl_link_unregister() net_sched: fix an oops in tcindex filter batman: fix a bogus warning from batadv_is_on_batman_iface() Daniel Kim (1): brcmfmac: Fix iovar 'bw_cap' set command failure Daniel Mack (1): net: mdio: of_mdiobus_register(): fall back to mdiobus_register() for !CONFIG_OF Darek Marcinkiewicz (1): Driver for Beckhoff CX5020 EtherCAT master module. David Howells (2): AFS: Fix cache manager service handlers AFS: Pass an afs_call* to call->async_workfn() instead of a work_struct* David S. Miller (3): sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fault addresses. sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus. sparc64: Add membar to Niagara2 memcpy code. David Spinadel (2): iwlwifi: mvm: do no sched scan while associated iwlwifi: mvm: prevent sched scan while not idle David Vrabel (1): xen-netback: fix race between napi_complete() and interrupt handler Denys Fedoryshchenko (1): netfilter: nfnetlink: Fix use after free when it fails to process batch Duan Jiong (2): neigh: set nud_state to NUD_INCOMPLETE when probing router reachability ipv6: update Destination Cache entries when gateway turn into host Eliad Peller (5): cfg80211: free sme on connection failures cfg80211: add cfg80211_sched_scan_stopped_rtnl mac80211: fix nested rtnl locking on ieee80211_reconfig mac80211: fix vif name tracing iwlwifi: mvm: fix off-by-one in scan channels configuration Emil Goode (1): net: cassini: use nested lock annotation Emmanuel Grumbach (5): iwlwifi: mvm: BT Coex - fix validity flags during init iwlwifi: mvm: rs - s/CPTCFG/CONFIG iwlwifi: pcie: disable interrupts upon PCIe alloc iwlwifi: mvm: fix setting channel in monitor mode mac80211: fix suspend vs. association race Eric Dumazet (2): net: gro: make sure skb->cb[] initial content has not to be zero ipv6: gro: fix CHECKSUM_COMPLETE support Ezequiel Garcia (1): dma: mv_xor: Flush descriptors before activating a channel Fabian Godehardt (1): net/dsa/dsa.c: increment chip_index during of_node handling on dsa_of_probe() Florian Westphal (6): netfilter: ctnetlink: don't add null bindings if no nat requested netfilter: ipv4: defrag: set local_df flag on defragmented skb net: ipv4: ip_forward: fix inverted local_df test net: ipv6: send pkttoobig immediately if orig frag size > mtu net: ip: push gso skb forwarding handling down the stack Revert "net: core: introduce netif_skb_dev_features" Guenter Roeck (1): net: phy: Don't call phy_resume if phy_init_hw failed Hannes Frederic Sowa (2): net: avoid dependency of net_get_random_once on nop patching ipv6: fix calculation of option len in ip6_append_data Hans de Goede (1): stmmac: Remove unbalanced clk_disable call Heiko
Re: [PATCH v3] staging: lustre: lnet: klnds: Fix coding style in socklnd.c
On Sun, May 25, 2014 at 11:50:03PM +0100, Masaru Nomura wrote: > > > > 2014-05-25 23:37 GMT+01:00 Greg KH : > > On Sun, May 25, 2014 at 11:24:12PM +0100, Masaru Nomura wrote: > > Remove prohibited space between function name and > > open parenthesis to meet kernel coding style. > > Also fix indenting due to changes to keep readability. > > > > -since v2: > > None. This is the resend of v2 as v2 failed to apply > > This should be below the --- line. > > > > I'm sorry for that. Will fix it. > > > And it still doesn't apply :( > > What branch did you make it against? > > > > I'm using[1] which is your staging.git (is it correct?) and downloaded it > today. So, there should not be a patch failure... :( What _branch_ of that git tree did you make it against? And please don't send html email, the mailing lists reject it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/18] Cross-architecture definitions of relaxed MMIO accessors
On Thu, 2014-05-22 at 17:47 +0100, Will Deacon wrote:
> Hi all,
>
> This is version 2 of the series I originally posted here:
>
> https://lkml.org/lkml/2014/4/17/269
>
> Changes since v1 include:
>
> - Added relevant acks from arch maintainers
> - Fixed potential compiler re-ordering issue for x86 definitions
>
> I'd *really* appreciate some feedback on the proposed semantics here, but
> acks are still good :)
>
> The original cover letter is duplicated below.
Question (sorry if I missed an existing explanation...), do we have an
equivalent bunch for iomap ?
Cheers,
Ben.
> Cheers,
>
> Will
>
> --->8
>
> This RFC series attempts to define a portable (i.e. cross-architecture)
> definition of the {readX,writeX}_relaxed MMIO accessor functions. These
> functions are already in widespread use amongst drivers (mainly those
> supporting
> devices embedded in ARM SoCs), but lack any well-defined semantics and,
> subsequently, any portable definitions to allow these drivers to be compiled
> for
> other architectures.
>
> The two main motivations for this series are:
>
> (1) To promote use of the _relaxed MMIO accessors on weakly-ordered
> architectures, where they can bring significant performance improvements
> over their non-relaxed counterparts.
>
> (2) To allow COMPILE_TEST to build drivers using the relaxed accessors across
> all architectures.
>
> The proposed semantics largely match exactly those provided by the ARM
> implementation (i.e. no weaker), with one exception (see below).
>
> Informally:
>
> - Relaxed accesses to the same device are ordered with respect to each
> other.
>
> - Relaxed accesses are *not* guaranteed to be ordered with respect to normal
> memory accesses (e.g. DMA buffers -- this is what gives us the performance
> boost over the non-relaxed versions).
>
> - Relaxed accesses are not guaranteed to be ordered with respect to
> LOCK/UNLOCK operations.
>
> In actual fact, the relaxed accessors *are* ordered with respect to
> LOCK/UNLOCK
> operations on ARM[64], but I have added this constraint for the benefit of
> PowerPC, which has expensive I/O barriers in the spin_unlock path for the
> non-relaxed accessors.
>
> A corollary to this is that mmiowb() probably needs rethinking. As it
> currently
> stands, an mmiowb() is required to order MMIO writes to a device from multiple
> CPUs, even if that device is protected by a lock. However, this isn't often
> used
> in practice, leading to PowerPC implementing both mmiowb() *and* synchronising
> I/O in spin_unlock.
>
> I would propose making the non-relaxed I/O accessors ordered with respect to
> LOCK/UNLOCK, leaving mmiowb() to be used with the relaxed accessors, if
> required, but would welcome thoughts/suggestions on this topic.
>
>
> Will Deacon (18):
> asm-generic: io: implement relaxed accessor macros as conditional
> wrappers
> microblaze: io: remove dummy relaxed accessor macros
> s390: io: remove dummy relaxed accessor macros for reads
> xtensa: io: remove dummy relaxed accessor macros for reads
> alpha: io: implement relaxed accessor macros for writes
> frv: io: implement dummy relaxed accessor macros for writes
> cris: io: implement dummy relaxed accessor macros for writes
> ia64: io: implement dummy relaxed accessor macros for writes
> m32r: io: implement dummy relaxed accessor macros for writes
> m68k: io: implement dummy relaxed accessor macros for writes
> mn10300: io: implement dummy relaxed accessor macros for writes
> parisc: io: implement dummy relaxed accessor macros for writes
> powerpc: io: implement dummy relaxed accessor macros for writes
> sparc: io: implement dummy relaxed accessor macros for writes
> tile: io: implement dummy relaxed accessor macros for writes
> x86: io: implement dummy relaxed accessor macros for writes
> documentation: memory-barriers: clarify relaxed io accessor semantics
> asm-generic: io: define relaxed accessor macros unconditionally
>
> Documentation/memory-barriers.txt | 13 +
> arch/alpha/include/asm/io.h | 12
> arch/cris/include/asm/io.h| 3 +++
> arch/frv/include/asm/io.h | 3 +++
> arch/ia64/include/asm/io.h| 4
> arch/m32r/include/asm/io.h| 3 +++
> arch/m68k/include/asm/io.h| 8
> arch/m68k/include/asm/io_no.h | 4
> arch/microblaze/include/asm/io.h | 8
> arch/mn10300/include/asm/io.h | 4
> arch/parisc/include/asm/io.h | 12
> arch/powerpc/include/asm/io.h | 12
> arch/s390/include/asm/io.h| 5 -
> arch/sparc/include/asm/io.h | 9 +
> arch/sparc/include/asm/io_32.h| 3 ---
> arch/sparc/include/asm/io_64.h| 22 ++
> arch/tile/include/asm/io.h| 4
> arch/x86/include/asm/io.h | 10 +++---
> arch/xtensa/include/asm/io.h | 7 ---
>
Von Dr. David Sidwell
-- Von Dr. David Sidwell Global Equity Forschung London Regional Office- UBS Investment Bank in London. 1-Fins begraben Avenue, London EC2M 2PP Mein lieber Freund, Mein Name ist Dr. David Sidwell von Harlesden North west London. Ich arbeite mit UBS Investment Bank Großbritannien. Ich möchte kurz Diskus über ein Angebot, das von einer immensen Nutzen für beide von uns ist. In meiner Abteilung, wobei die Eigenkapital Leiter Forschung, entdeckte ich eine verlassene Summe von £ 19,7 Millionen britische Pfund Sterling (Neunzehn Millionen siebenhunderttausend britische Pfund) in einem Konto, das zu einem unserer ausländischen Kunden / Kunden Stephen Richard gehört, die vor vielen Jahren starb bei einem Flugzeugabsturz mit seiner Frau und einzige Tochter. Die Wahl der Kontaktaufnahme mit Ihnen ist aus der geographischen Natur, wo Sie leben erweckt, insbesondere aufgrund der Sensibilität der Transaktion hat die Bank gewartet keine der Verwandten zu kommen-up für die Behauptung, aber niemand hat das getan, ich persönlich gewesen sein in der Suche die Verwandten für 3 Jahre jetzt erfolglos. Ich suche Ihre Zustimmung an Sie als nächsten Angehörigen / Wird Zuschussempfängers mit dem Verstorbenen zu präsentieren, so dass die Erlöse aus diesem Konto bei £ 19,7 Millionen Pfund geschätzt wird an Ihre angegebene Bankkonto als die nächsten Angehörigen zu spät Stephen Richard übertragen werden. Dies wird ausgezahlt oder geteilt werden in diese Prozentsätze, 60% für mich und 40% für Sie. Alles was ich brauche ist es, Ihre Daten in unserer Bank Datenbanksystem wie die nächsten Angehörigen zu spät Stephen Richard hochladen. Was ich jetzt im Grunde verlangen, ist Ihre ehrliche Zusammenarbeit, Verschwiegenheit und Vertrauen, um mir zu ermöglichen, und Sie sehen den Erfolg in dieser Transaktion. Bitte haben Sie, um diese Transaktion 100% geheim, weil meine Position hier in meiner Bank und in der Gesellschaft zu halten. Ich habe Ihre Kontaktdaten aus Ihrem Land internationale Geschäftsinformationen; Ich entschied mich, kontaktieren Sie hoffen, dass Sie das Angebot interessant finden. Bitte auf Ihrer Bestätigung dieser Nachricht und Ihr Interesse werde ich Ihnen weitere Informationen liefern. Geben Sie mir mit Ihrer vollständigen Details unten, so wird es mir ermöglichen, Ihre Daten in unsere Datenbank hochladen Bank in der Bank-Netzwerk-System, dass Sie die Namen nächsten Angehörigen zu reflektieren / wird Begünstigten dieses Fonds, und ich werde Sie führen, wie Offene Kommunikation mit der Bank und machen die Forderungen zur Weiterleitung des Fonds zu Ihnen. Als Insider und meine langjährige Erfahrung im Bankensektor habe ich alle Modalität Struktur, um den Erfolg dieser Transaktion alle i wünschen Ihnen ist, dass Sie die Zusammenarbeit zu sehen. Ich glaube nicht, dass du nach verrate die Gelder auf Ihr Bankkonto überwiesen worden, wenn man nicht gerade nach vorne und Vertrauen verdient bitte kontaktieren Sie mich nicht. . 1 Vollständiger Name: 2 Ihre Adresse Einwohner.: . 3 Ihre Direct Mobile Number: 4 Ihre Fax-Nummer.: . 5 Geschlecht: . 6 Alter: Bitte geben Sie mir mit Ihrer vollständigen Details oben, so dass wir gehen und erhalten die Fonds Transfer zu Ihrem nominierten Bank Konto kann. Bitte kontaktieren Sie mich auf meiner privaten E-Mail-dr.sidwell2david @ outlook.com Grüße, Von Dr. David Sidwell Global Equity Forschung London Regional Office- UBS Investment Bank in London. www.ubs.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] KVM: x86: get CPL from SS.DPL
> CS.RPL is not equal to the CPL in the few instructions between
> setting CR0.PE and reloading CS. And CS.DPL is also not equal
> to the CPL for conforming code segments.
Out of my curiousity, could you elaborate the problem of this
CPL gap window, such as breaking any VMs or tests? From Linux kernel
code, it seems kernel enables CR0.PE and immediately ljmpl to
CS. This windows is very small and I am curious how severely it could
be.
>
> However, SS.DPL *is* always equal to the CPL except for the weird
Is this specified anywhere in SDM as a requirement for x86 OS? If so,
maybe provide a pointer to support this.
> case of SYSRET on AMD processors, which sets SS.DPL=SS.RPL from the
> value in the STAR MSR, but force CPL=3 (Intel instead forces
> SS.DPL=SS.RPL=CPL=3).
Thinking out loud here... Should we force SYSRET SS.RPL to be 3 when
VM updates STAR MSR? Following the same thought, does it make sense to
check (and force) SS.DPL==3 when STAR MSR is being updated. Will
forcing SYSRET SS.DPL=3 break any OS? I think any reasonable OS would
probably sets SS.RPL=SS.DPL=3.
>
> So this patch:
>
> - modifies SVM to update the CPL from SS.DPL rather than CS.RPL;
> the above case with SYSRET is not broken further, and the way
> to fix it would be to pass the CPL to userspace and back
>
> - modifies VMX to always return the CPL from SS.DPL (except
> forcing it to 0 if we are emulating real mode via vm86 mode;
> in vm86 mode all DPLs have to be 3, but real mode does allow
> privileged instructions). It also removes the CPL cache,
> which becomes a duplicate of the SS access rights cache.
>
> This fixes doing KVM_IOCTL_SET_SREGS exactly after setting
nit-picking: s/KVM_IOCTL_SET_SREGS/KVM_SET_SREGS IOCTL/, to
match with IOCTL function name exactly.
> CR0.PE=1 but before CS has been reloaded.
>
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/include/asm/kvm_host.h | 1 -
> arch/x86/kvm/svm.c | 35 ++-
> arch/x86/kvm/vmx.c | 24
> 3 files changed, 18 insertions(+), 42 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index e21aee98a5c2..49314155b66c 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -130,7 +130,6 @@ enum kvm_reg_ex {
> VCPU_EXREG_PDPTR = NR_VCPU_REGS,
> VCPU_EXREG_CR3,
> VCPU_EXREG_RFLAGS,
> - VCPU_EXREG_CPL,
> VCPU_EXREG_SEGMENTS,
> };
>
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 0b7d58d0c5fb..ec8366c5cfea 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -1338,21 +1338,6 @@ static void svm_vcpu_put(struct kvm_vcpu *vcpu)
> wrmsrl(host_save_user_msrs[i], svm->host_user_msrs[i]);
> }
>
> -static void svm_update_cpl(struct kvm_vcpu *vcpu)
> -{
> - struct vcpu_svm *svm = to_svm(vcpu);
> - int cpl;
> -
> - if (!is_protmode(vcpu))
> - cpl = 0;
> - else if (svm->vmcb->save.rflags & X86_EFLAGS_VM)
> - cpl = 3;
> - else
> - cpl = svm->vmcb->save.cs.selector & 0x3;
> -
> - svm->vmcb->save.cpl = cpl;
> -}
> -
> static unsigned long svm_get_rflags(struct kvm_vcpu *vcpu)
> {
> return to_svm(vcpu)->vmcb->save.rflags;
> @@ -1360,11 +1345,12 @@ static unsigned long svm_get_rflags(struct
> kvm_vcpu *vcpu)
>
> static void svm_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags)
> {
> - unsigned long old_rflags = to_svm(vcpu)->vmcb->save.rflags;
> -
> + /*
> +* Any change of EFLAGS.VM is accompained by a reload of SS
> +* (caused by either a task switch or an inter-privilege IRET),
> +* so we do not need to update the CPL here.
> +*/
> to_svm(vcpu)->vmcb->save.rflags = rflags;
> - if ((old_rflags ^ rflags) & X86_EFLAGS_VM)
> - svm_update_cpl(vcpu);
> }
>
> static void svm_cache_reg(struct kvm_vcpu *vcpu, enum kvm_reg reg)
> @@ -1631,8 +1617,15 @@ static void svm_set_segment(struct kvm_vcpu *vcpu,
> s->attrib |= (var->db & 1) << SVM_SELECTOR_DB_SHIFT;
> s->attrib |= (var->g & 1) << SVM_SELECTOR_G_SHIFT;
> }
> - if (seg == VCPU_SREG_CS)
> - svm_update_cpl(vcpu);
> +
> + /*
> + * This is always accurate, except if SYSRET returned to a segment
> + * with SS.DPL != 3. Intel does not have this quirk, and always
> + * forces SS.DPL to 3 on sysret, so we ignore that case; fixing it
> + * would entail passing the CPL to userspace and back.
> + */
> + if (seg == VCPU_SREG_SS)
> + svm->vmcb->save.cpl = (s->attrib >> SVM_SELECTOR_DPL_SHIFT) & 3;
>
> mark_dirty(svm->vmcb, VMCB_SEG);
> }
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 6f7463f53ed9..a267108403f5 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -414,7 +414,6 @@ struct vcpu_vmx {
> struct kvm_vcpu vcpu;
> unsigned long host_rsp;
> u8fail;
> - u8cpl;
> bool nmi_known_unmasked;
> u32 exit_intr_info;
> u32 idt_vectoring_info;
> @@
Re: [PATCH] kconfig: plug false-positive warning in get_prompt_str() seen with gcc-4.9
On Sun, May 25, 2014 at 08:47:51PM +0400, Konstantin Khlebnikov wrote: > scripts/kconfig/menu.c: In function ‘get_symbol_str’: > scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in > this function [-Wmaybe-uninitialized] > jump->offset = strlen(r->s); > ^ BTW, why do we need strlen() there? what's wrong with r->len? -- Kirill A. Shutemov -- 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 3/4] KVM: x86: check CS.DPL against RPL during task switch
On Sat, May 24, 2014 at 1:12 PM, Wei Huang wrote:
> Table 7-1 of the SDM mentions a check that the code segment's
> DPL must match the selector's RPL. This was not done by KVM,
> fix it.
>
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/emulate.c | 31 +--
> 1 file changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index 47e716ef46b7..2fa7ab069817 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -1411,7 +1411,7 @@ static int write_segment_descriptor(struct
> x86_emulate_ctxt *ctxt,
>
> /* Does not support long mode */
> static int __load_segment_descriptor(struct x86_emulate_ctxt *ctxt,
> - u16 selector, int seg, u8 cpl)
> + u16 selector, int seg, u8 cpl, bool in_task_switch)
A small nit-picking: a new line to comply with 80 characters per line
rule. otherwise looks good to me.
Reviewed-by: Wei Huang
> {
> struct desc_struct seg_desc, old_desc;
> u8 dpl, rpl;
> @@ -1486,6 +1486,9 @@ static int __load_segment_descriptor(struct
> x86_emulate_ctxt *ctxt,
> goto exception;
> break;
> case VCPU_SREG_CS:
> + if (in_task_switch && rpl != dpl)
> + goto exception;
> +
> if (!(seg_desc.type & 8))
> goto exception;
>
> @@ -1547,7 +1550,7 @@ static int load_segment_descriptor(struct
> x86_emulate_ctxt *ctxt,
> u16 selector, int seg)
> {
> u8 cpl = ctxt->ops->cpl(ctxt);
> - return __load_segment_descriptor(ctxt, selector, seg, cpl);
> + return __load_segment_descriptor(ctxt, selector, seg, cpl, false);
> }
>
> static void write_register_operand(struct operand *op)
> @@ -2440,19 +2443,19 @@ static int load_state_from_tss16(struct
> x86_emulate_ctxt *ctxt,
> * Now load segment descriptors. If fault happens at this stage
> * it is handled in a context of new task
> */
> - ret = __load_segment_descriptor(ctxt, tss->ldt, VCPU_SREG_LDTR, cpl);
> + ret = __load_segment_descriptor(ctxt, tss->ldt, VCPU_SREG_LDTR, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
> - ret = __load_segment_descriptor(ctxt, tss->es, VCPU_SREG_ES, cpl);
> + ret = __load_segment_descriptor(ctxt, tss->es, VCPU_SREG_ES, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
> - ret = __load_segment_descriptor(ctxt, tss->cs, VCPU_SREG_CS, cpl);
> + ret = __load_segment_descriptor(ctxt, tss->cs, VCPU_SREG_CS, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
> - ret = __load_segment_descriptor(ctxt, tss->ss, VCPU_SREG_SS, cpl);
> + ret = __load_segment_descriptor(ctxt, tss->ss, VCPU_SREG_SS, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
> - ret = __load_segment_descriptor(ctxt, tss->ds, VCPU_SREG_DS, cpl);
> + ret = __load_segment_descriptor(ctxt, tss->ds, VCPU_SREG_DS, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
>
> @@ -2577,25 +2580,25 @@ static int load_state_from_tss32(struct
> x86_emulate_ctxt *ctxt,
> * Now load segment descriptors. If fault happenes at this stage
> * it is handled in a context of new task
> */
> - ret = __load_segment_descriptor(ctxt, tss->ldt_selector, VCPU_SREG_LDTR,
> cpl);
> + ret = __load_segment_descriptor(ctxt, tss->ldt_selector,
> VCPU_SREG_LDTR, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
> - ret = __load_segment_descriptor(ctxt, tss->es, VCPU_SREG_ES, cpl);
> + ret = __load_segment_descriptor(ctxt, tss->es, VCPU_SREG_ES, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
> - ret = __load_segment_descriptor(ctxt, tss->cs, VCPU_SREG_CS, cpl);
> + ret = __load_segment_descriptor(ctxt, tss->cs, VCPU_SREG_CS, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
> - ret = __load_segment_descriptor(ctxt, tss->ss, VCPU_SREG_SS, cpl);
> + ret = __load_segment_descriptor(ctxt, tss->ss, VCPU_SREG_SS, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
> - ret = __load_segment_descriptor(ctxt, tss->ds, VCPU_SREG_DS, cpl);
> + ret = __load_segment_descriptor(ctxt, tss->ds, VCPU_SREG_DS, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
> - ret = __load_segment_descriptor(ctxt, tss->fs, VCPU_SREG_FS, cpl);
> + ret = __load_segment_descriptor(ctxt, tss->fs, VCPU_SREG_FS, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
> - ret = __load_segment_descriptor(ctxt, tss->gs, VCPU_SREG_GS, cpl);
> + ret = __load_segment_descriptor(ctxt, tss->gs, VCPU_SREG_GS, cpl, true);
> if (ret != X86EMUL_CONTINUE)
> return ret;
>
> --
> 1.8.3.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next] imx-drm: imx-tve: remove unused variable
Hi all,
On Sun, 25 May 2014 15:12:35 -0700 Greg Kroah-Hartman
wrote:
>
> On Sun, May 25, 2014 at 11:54:14PM +0200, Vincent Stehlé wrote:
> > Commit f9b0e251dfbf 'drm: make mode_valid callback optional' left variable
> > ret
> > unused; remove it.
> >
> > This fixes the following compilation warning:
> >
> > drivers/staging/imx-drm/imx-tve.c: In function
> > ‘imx_tve_connector_mode_valid’:
> > drivers/staging/imx-drm/imx-tve.c:252:6: warning: unused variable ‘ret’
> > [-Wunused-variable]
>
> It doesn't apply to my tree :(
Yeah, commit f9b0e251dfbf 'drm: make mode_valid callback optional' is
in the drm tree, so this patch needs to go to Dave Airlie (cc'd).
Though Daniel Vetter may want to send it on.
For Dave's benefit, here is the patch again:
From: Vincent Stehlé
Subject: [PATCH linux-next] imx-drm: imx-tve: remove unused variable
Date: Sun, 25 May 2014 23:54:14 +0200
Commit f9b0e251dfbf 'drm: make mode_valid callback optional' left variable ret
unused; remove it.
This fixes the following compilation warning:
drivers/staging/imx-drm/imx-tve.c: In function ‘imx_tve_connector_mode_valid’:
drivers/staging/imx-drm/imx-tve.c:252:6: warning: unused variable ‘ret’
[-Wunused-variable]
Signed-off-by: Vincent Stehlé
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
---
Hi,
This can be seen with e.g. linux next-20140523 and arm allmodconfig.
Best regards,
V.
drivers/staging/imx-drm/imx-tve.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/imx-drm/imx-tve.c
b/drivers/staging/imx-drm/imx-tve.c
index 3e8b0a1..4caef2b1 100644
--- a/drivers/staging/imx-drm/imx-tve.c
+++ b/drivers/staging/imx-drm/imx-tve.c
@@ -249,7 +249,6 @@ static int imx_tve_connector_mode_valid(struct
drm_connector *connector,
{
struct imx_tve *tve = con_to_tve(connector);
unsigned long rate;
- int ret;
/* pixel clock with 2x oversampling */
rate = clk_round_rate(tve->clk, 2000UL * mode->clock) / 2000;
--
2.0.0.rc2
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH linux-next] DRM: Armada: update dma_buf_export use
Hi all,
On Sun, 25 May 2014 23:54:35 +0100 Russell King - ARM Linux
wrote:
>
> On Sun, May 25, 2014 at 02:08:48PM +0200, David Herrmann wrote:
> >
> > On Sat, May 24, 2014 at 11:05 PM, Vincent Stehlé
> > wrote:
> > > The dma_buf_export function was updated in commit 4bcec44ffaf9 'dma-buf:
> > > use
> > > reservation objects' to take a reservation object parameter; update Armada
> > > export method accordingly.
> > >
> > > This fixes the following compilation error:
> > >
> > > drivers/gpu/drm/armada/armada_gem.c: In function
> > > ‘armada_gem_prime_export’:
> > > drivers/gpu/drm/armada/armada_gem.c:544:16: error: macro
> > > "dma_buf_export" requires 5 arguments, but only 4 given
> > >
> > > Signed-off-by: Vincent Stehlé
> > > Cc: Russell King
> > > Cc: David Airlie
> > > Cc: Maarten Lankhorst
> > > Cc: Sumit Semwal
> >
> > Reviewed-by: David Herrmann
>
> Acked-by: Russell King
>
> Airlied, can you merge this please? Thanks.
Except that commit 4bcec44ffaf9 'dma-buf: use reservation objects'
comes from the dma-buf tree, so Sumit needs to add this commit to his
tree.
> > > This can be seen with e.g. linux next-20140523 and arm allmodconfig.
> > >
> > > Best regards,
> > >
> > > V.
> > >
> > > drivers/gpu/drm/armada/armada_gem.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/armada/armada_gem.c
> > > b/drivers/gpu/drm/armada/armada_gem.c
> > > index 887816f..7adb0c3 100644
> > > --- a/drivers/gpu/drm/armada/armada_gem.c
> > > +++ b/drivers/gpu/drm/armada/armada_gem.c
> > > @@ -541,7 +541,7 @@ armada_gem_prime_export(struct drm_device *dev,
> > > struct drm_gem_object *obj,
> > > int flags)
> > > {
> > > return dma_buf_export(obj, _gem_prime_dmabuf_ops,
> > > obj->size,
> > > - O_RDWR);
> > > + O_RDWR, NULL);
> > > }
> > >
> > > struct drm_gem_object *
> > > --
> > > 2.0.0.rc2
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH v2 2/4] KVM: x86: drop set_rflags callback
> Not needed anymore now that the CPL is computed directly
> by the task switch code.
Given the current form, looks OK to me.
Reviewed-by: Wei Huang
>
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/include/asm/kvm_emulate.h | 1 -
> arch/x86/kvm/x86.c | 6 --
> 2 files changed, 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_emulate.h
> b/arch/x86/include/asm/kvm_emulate.h
> index 24ec1216596e..a04fe4eb237d 100644
> --- a/arch/x86/include/asm/kvm_emulate.h
> +++ b/arch/x86/include/asm/kvm_emulate.h
> @@ -189,7 +189,6 @@ struct x86_emulate_ops {
> void (*set_idt)(struct x86_emulate_ctxt *ctxt, struct desc_ptr *dt);
> ulong (*get_cr)(struct x86_emulate_ctxt *ctxt, int cr);
> int (*set_cr)(struct x86_emulate_ctxt *ctxt, int cr, ulong val);
> - void (*set_rflags)(struct x86_emulate_ctxt *ctxt, ulong val);
> int (*cpl)(struct x86_emulate_ctxt *ctxt);
> int (*get_dr)(struct x86_emulate_ctxt *ctxt, int dr, ulong *dest);
> int (*set_dr)(struct x86_emulate_ctxt *ctxt, int dr, ulong value);
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index fb313fc896dd..57eac309c22e 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -4646,11 +4646,6 @@ static int emulator_set_cr(struct x86_emulate_ctxt
> *ctxt, int cr, ulong val)
> return res;
> }
>
> -static void emulator_set_rflags(struct x86_emulate_ctxt *ctxt, ulong val)
> -{
> - kvm_set_rflags(emul_to_vcpu(ctxt), val);
> -}
> -
> static int emulator_get_cpl(struct x86_emulate_ctxt *ctxt)
> {
> return kvm_x86_ops->get_cpl(emul_to_vcpu(ctxt));
> @@ -4835,7 +4830,6 @@ static const struct x86_emulate_ops emulate_ops = {
> .set_idt = emulator_set_idt,
> .get_cr = emulator_get_cr,
> .set_cr = emulator_set_cr,
> - .set_rflags = emulator_set_rflags,
> .cpl = emulator_get_cpl,
> .get_dr = emulator_get_dr,
> .set_dr = emulator_set_dr,
> --
> 1.8.3.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] KVM: x86: get CPL from SS.DPL
> Another day, another CPL patch... > > It turns out that the simple approach of getting CPL from SS.DPL > broke x86/taskswitch2.flat. To fix that, already "imagine" that the > CPL is CS.RPL, or 3 for VM86 tasks, while loading segment descriptors > during task switches. This removes the hack where task switches call > kvm_set_rflags to override the VM flag (patch 2). My understanding about this problem is that during task switch, the CPL might be inconsistent with SS.DPL. This breaks the assumption of previous patch (i.e. patch 4). To fix this problem, we have to rely on CS.RPL to figure out CPL. If so , my question: is there other special cases similar to task switch which can break patch 4? > > While at it, add a new privilege test during task switches that is > missing. > > Patch 4 is the same as before. > > Paolo Bonzini (4): > KVM: x86: use new CS.RPL as CPL during task switch > KVM: x86: drop set_rflags callback > KVM: x86: check CS.DPL against RPL during task switch > KVM: x86: get CPL from SS.DPL > > arch/x86/include/asm/kvm_emulate.h | 1 - > arch/x86/include/asm/kvm_host.h| 1 - > arch/x86/kvm/emulate.c | 63 > ++ > arch/x86/kvm/svm.c | 35 + > arch/x86/kvm/vmx.c | 24 +++ > arch/x86/kvm/x86.c | 6 > 6 files changed, 54 insertions(+), 76 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/
Re: [PATCH linux-next] DRM: Armada: update dma_buf_export use
On Sun, May 25, 2014 at 02:08:48PM +0200, David Herrmann wrote:
> Hi
>
> On Sat, May 24, 2014 at 11:05 PM, Vincent Stehlé
> wrote:
> > The dma_buf_export function was updated in commit 4bcec44ffaf9 'dma-buf: use
> > reservation objects' to take a reservation object parameter; update Armada
> > export method accordingly.
> >
> > This fixes the following compilation error:
> >
> > drivers/gpu/drm/armada/armada_gem.c: In function
> > ‘armada_gem_prime_export’:
> > drivers/gpu/drm/armada/armada_gem.c:544:16: error: macro "dma_buf_export"
> > requires 5 arguments, but only 4 given
> >
> > Signed-off-by: Vincent Stehlé
> > Cc: Russell King
> > Cc: David Airlie
> > Cc: Maarten Lankhorst
> > Cc: Sumit Semwal
>
> Reviewed-by: David Herrmann
Acked-by: Russell King
Airlied, can you merge this please? Thanks.
> Thanks
> David
>
> > ---
> >
> > Hi,
> >
> > This can be seen with e.g. linux next-20140523 and arm allmodconfig.
> >
> > Best regards,
> >
> > V.
> >
> > drivers/gpu/drm/armada/armada_gem.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/armada/armada_gem.c
> > b/drivers/gpu/drm/armada/armada_gem.c
> > index 887816f..7adb0c3 100644
> > --- a/drivers/gpu/drm/armada/armada_gem.c
> > +++ b/drivers/gpu/drm/armada/armada_gem.c
> > @@ -541,7 +541,7 @@ armada_gem_prime_export(struct drm_device *dev, struct
> > drm_gem_object *obj,
> > int flags)
> > {
> > return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
> > - O_RDWR);
> > + O_RDWR, NULL);
> > }
> >
> > struct drm_gem_object *
> > --
> > 2.0.0.rc2
> >
> > --
> > 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/
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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] iio: add support of the max1027
Philippe Reynes schrieb:
> This driver add partial support of the
> maxim 1027/1029/1031. Differential mode is not
> supported.
>
> It was tested on armadeus apf27 board.
>
> Signed-off-by: Philippe Reynes
> ---
> .../devicetree/bindings/iio/adc/max1027-adc.txt| 21 +
> drivers/staging/iio/adc/Kconfig|9 +
> drivers/staging/iio/adc/Makefile |1 +
> drivers/staging/iio/adc/max1027.c | 553
>
> 4 files changed, 584 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
> create mode 100644 drivers/staging/iio/adc/max1027.c
>
> Changelog:
> v2: (thanks Hartmut Knaack and Jonathan Cameron for the feedback)
> - really use devm_*
> - use demux magic
> - use spi_read and spi_write (instead of spi_sync)
> - use define for register (instead of hardcoded value)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
> b/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
> new file mode 100644
> index 000..2e8b9f3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
> @@ -0,0 +1,21 @@
> +* Maxim 1027/1029/1031 Analog to Digital Converter (ADC)
> +
> +Required properties:
> + - compatible: Should be "maxim,max1027" or "maxim,max1029" or
> "maxim,max1031"
> + - reg: Should contain the ADC SPI address
> + - interrupt-parent: the phandle for the gpio controller
> + - interrupts: (gpio) interrupt to which the chip is connected
> +
> +Example:
> +adc@0 {
> + compatible = "maxim,max1027";
> + reg = <0>;
> + interrupt-parent = <>;
> + interrupts = <15 IRQ_TYPE_EDGE_RISING>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_max1027>;
> + /* SPI mode = 0 */
> + spi-cpol = <0>;
> + spi-cpha = <0>;
> + spi-max-frequency = <100>;
> +};
> diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
> index 3633298..12a78eb 100644
> --- a/drivers/staging/iio/adc/Kconfig
> +++ b/drivers/staging/iio/adc/Kconfig
> @@ -112,6 +112,15 @@ config LPC32XX_ADC
> activate only one via device tree selection. Provides direct access
> via sysfs.
>
> +config MAX1027
> + tristate "Maxim max1027 ADC driver"
> + depends on SPI
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> + Say yes here to build support for Maxim SPI ADC models
> + max1027, max1029 and max1031.
> +
> config MXS_LRADC
> tristate "Freescale i.MX23/i.MX28 LRADC"
> depends on ARCH_MXS || COMPILE_TEST
> diff --git a/drivers/staging/iio/adc/Makefile
> b/drivers/staging/iio/adc/Makefile
> index 3e9fb14..22fbd0c 100644
> --- a/drivers/staging/iio/adc/Makefile
> +++ b/drivers/staging/iio/adc/Makefile
> @@ -18,5 +18,6 @@ obj-$(CONFIG_AD7816) += ad7816.o
> obj-$(CONFIG_AD7192) += ad7192.o
> obj-$(CONFIG_AD7280) += ad7280a.o
> obj-$(CONFIG_LPC32XX_ADC) += lpc32xx_adc.o
> +obj-$(CONFIG_MAX1027) += max1027.o
> obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
> obj-$(CONFIG_SPEAR_ADC) += spear_adc.o
> diff --git a/drivers/staging/iio/adc/max1027.c
> b/drivers/staging/iio/adc/max1027.c
> new file mode 100644
> index 000..c2e5936
> --- /dev/null
> +++ b/drivers/staging/iio/adc/max1027.c
> @@ -0,0 +1,553 @@
> + /*
> + * iio/adc/max1027.c
> + * Copyright (C) 2014 Philippe Reynes
> + *
> + * based on linux/drivers/iio/ad7923.c
> + * Copyright 2011 Analog Devices Inc (from AD7923 Driver)
> + * Copyright 2012 CS Systemes d'Information
> + *
> + * 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.
> + *
> + * max1027.c
> + *
> + * Partial support for max1027 and similar chips.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX1027_CONV_REG 0x80
> +#define MAX1027_SETUP_REG 0x40
> +#define MAX1027_AVG_REG 0x20
> +#define MAX1027_RST_REG 0x10
> +
> +/* conversion register */
> +#define MAX1027_TEMP 0x01
> +#define MAX1027_SCAN_0_N (0x00 << 1)
> +#define MAX1027_SCAN_N_M (0x01 << 1)
> +#define MAX1027_SCAN_N(0x02 << 1)
> +#define MAX1027_NOSCAN(0x03 << 1)
> +#define MAX1027_CHAN(n) ((n) << 3)
> +
> +/* setup register */
> +#define MAX1027_UNIPOLAR 0x02
> +#define MAX1027_BIPOLAR 0x03
> +#define MAX1027_REF_MODE0 (0x00 << 2)
> +#define MAX1027_REF_MODE1 (0x01 << 2)
> +#define MAX1027_REF_MODE2 (0x02 << 2)
> +#define MAX1027_REF_MODE3 (0x03 << 2)
> +#define MAX1027_CKS_MODE0 (0x00 << 4)
> +#define MAX1027_CKS_MODE1 (0x01 << 4)
> +#define MAX1027_CKS_MODE2 (0x02 << 4)
> +#define MAX1027_CKS_MODE3 (0x03 << 4)
> +
> +/* averaging register */
> +#define MAX1027_NSCAN_4 0x00
> +#define MAX1027_NSCAN_8 0x01
Re: [PATCH v3] staging: lustre: lnet: klnds: Fix coding style in socklnd.c
On Sun, May 25, 2014 at 11:24:12PM +0100, Masaru Nomura wrote: > Remove prohibited space between function name and > open parenthesis to meet kernel coding style. > Also fix indenting due to changes to keep readability. > > -since v2: > None. This is the resend of v2 as v2 failed to apply This should be below the --- line. And it still doesn't apply :( What branch did you make it against? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Silicom: bpctl_mod.c & bypass.c: Fixed a lot of checkpatch.pl warnings
Since you're redoing this one anyway, please use a more specific subject like: [PATCH] Staging: Silicom: bpctl_mod.c & bypass.c: add blank lines regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 1/3] ARM: sunxi: Add documentation for sunxi consumer infrared devices
This patch adds documentation for Device-Tree bindings for sunxi IR
controller.
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
.../devicetree/bindings/media/sunxi-ir.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
new file mode 100644
index 000..014dd8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -0,0 +1,23 @@
+Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
+
+Required properties:
+- compatible : should be "allwinner,sun7i-a20-ir";
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "apb" and "ir" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+
+Optional properties:
+- linux,rc-map-name : Remote control map name.
+
+Example:
+
+ir0: ir@01c21800 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <_gates 6>, <_clk>;
+ clock-names = "apb", "ir";
+ interrupts = <0 5 1>;
+ reg = <0x01C21800 0x40>;
+ linux,rc-map-name = "rc-rc6-mce";
+};
--
1.9.3
--
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 v8 2/3] [media] rc: add sunxi-ir driver
This patch adds driver for sunxi IR controller.
It is based on Alexsey Shestacov's work based on the original driver
supplied by Allwinner.
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
drivers/media/rc/Kconfig | 10 ++
drivers/media/rc/Makefile| 1 +
drivers/media/rc/sunxi-cir.c | 313 +++
3 files changed, 324 insertions(+)
create mode 100644 drivers/media/rc/sunxi-cir.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 8fbd377..9427fad 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -343,4 +343,14 @@ config RC_ST
If you're not sure, select N here.
+config IR_SUNXI
+tristate "SUNXI IR remote control"
+depends on RC_CORE
+depends on ARCH_SUNXI
+---help---
+ Say Y if you want to use sunXi internal IR Controller
+
+ To compile this driver as a module, choose M here: the module will
+ be called sunxi-ir.
+
endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index f8b54ff..9ee9ee7 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
obj-$(CONFIG_IR_IGUANA) += iguanair.o
obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
obj-$(CONFIG_RC_ST) += st_rc.o
+obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
obj-$(CONFIG_IR_IMG) += img-ir/
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
new file mode 100644
index 000..245d8dc
--- /dev/null
+++ b/drivers/media/rc/sunxi-cir.c
@@ -0,0 +1,313 @@
+/*
+ * Driver for Allwinner sunXi IR controller
+ *
+ * Copyright (C) 2014 Alexsey Shestacov
+ * Copyright (C) 2014 Alexander Bersenev
+ *
+ * Based on sun5i-ir.c:
+ * Copyright (C) 2007-2012 Daniel Wang
+ * Allwinner Technology Co., Ltd.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define SUNXI_IR_DEV "sunxi-ir"
+
+/* Registers */
+/* IR Control */
+#define SUNXI_IR_CTL_REG 0x00
+#define REG_CTL_GEN BIT(0) /* Global Enable */
+#define REG_CTL_RXEN BIT(1) /* RX block enable */
+#define REG_CTL_MD(BIT(4)|BIT(5)) /* CIR mode */
+
+/* Rx Config */
+#define SUNXI_IR_RXCTL_REG0x10
+#define REG_RXCTL_RPPIBIT(2) /* Pulse Polarity Invert flag */
+
+/* Rx Data */
+#define SUNXI_IR_RXFIFO_REG 0x20
+
+/* Rx Interrupt Enable */
+#define SUNXI_IR_RXINT_REG0x2C
+#define REG_RXINT_ROI_EN BIT(0) /* Rx FIFO Overflow */
+#define REG_RXINT_RPEI_EN BIT(1) /* Rx Packet End */
+#define REG_RXINT_RAI_EN BIT(4) /* Rx FIFO Data Available */
+/* Rx FIFO available byte level */
+#define REG_RXINT_RAL(val)(((val) << 8) & (BIT(8)|BIT(9)|BIT(10)|BIT(11)))
+
+/* Rx Interrupt Status */
+#define SUNXI_IR_RXSTA_REG0x30
+/* RX FIFO Get Available Counter */
+#define REG_RXSTA_GET_AC(val) (((val) >> 8) & (BIT(0)|BIT(1)|BIT(2)|BIT(3) \
+ |BIT(4)|BIT(5)))
+/* Clear all interrupt status value */
+#define REG_RXSTA_CLEARALL0xff
+
+/* IR Sample Config */
+#define SUNXI_IR_CIR_REG 0x34
+/* CIR_REG register noise threshold */
+#define REG_CIR_NTHR(val)(((val) << 2) & (BIT(2)|BIT(3)|BIT(4)|BIT(5) \
+|BIT(6)|BIT(7)))
+/* CIR_REG register idle threshold */
+#define REG_CIR_ITHR(val)(((val) << 8) & (BIT(8)|BIT(9)|BIT(10)|BIT(11) \
+|BIT(12)|BIT(13)|BIT(14)|BIT(15)))
+
+/* Hardware supported fifo size */
+#define SUNXI_IR_FIFO_SIZE16
+/* How many messages in FIFO trigger IRQ */
+#define TRIGGER_LEVEL 8
+/* Required frequency for IR0 or IR1 clock in CIR mode */
+#define SUNXI_IR_BASE_CLK 800
+/* Frequency after IR internal divider */
+#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
+/* Sample period in ns */
+#define SUNXI_IR_SAMPLE (10ul / SUNXI_IR_CLK)
+/* Noise threshold in samples */
+#define SUNXI_IR_RXNOISE 1
+/* Idle Threshold in samples */
+#define SUNXI_IR_RXIDLE 20
+/* Time after which device stops sending data in ms */
+#define SUNXI_IR_TIMEOUT 120
+
+struct sunxi_ir {
+ spinlock_t ir_lock;
+ struct rc_dev *rc;
+ void __iomem*base;
+ int irq;
+ struct clk *clk;
+ struct clk *apb_clk;
+ const char *map_name;
+};
+
+static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
+{
+ unsigned long status;
+ unsigned char dt;
+
[PATCH v8 3/3] ARM: sunxi: Add IR controller support in DT on A20
This patch adds IR controller in A20 Device-Tree:
- Two IR devices found in A20 user manual
- Pins for two devices
- One IR device physically found on Cubieboard 2
- One IR device physically found on Cubietruck
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 6 ++
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 6 ++
arch/arm/boot/dts/sun7i-a20.dtsi| 32 +
3 files changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index feeff64..b44d61b 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -65,6 +65,12 @@
};
};
+ ir0: ir@01c21800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "okay";
+ };
+
uart0: serial@01c28000 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index e288562..5f5c31d 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -121,6 +121,12 @@
};
};
+ ir0: ir@01c21800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "okay";
+ };
+
uart0: serial@01c28000 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 0ae2b77..fe1f8ff 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -724,6 +724,20 @@
allwinner,drive = <2>;
allwinner,pull = <0>;
};
+
+ ir0_pins_a: ir0@0 {
+ allwinner,pins = "PB3","PB4";
+ allwinner,function = "ir0";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ ir1_pins_a: ir1@0 {
+ allwinner,pins = "PB22","PB23";
+ allwinner,function = "ir1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
};
timer@01c20c00 {
@@ -749,6 +763,24 @@
interrupts = <0 24 4>;
};
+ ir0: ir@01c21800 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <_gates 6>, <_clk>;
+ clock-names = "apb", "ir";
+ interrupts = <0 5 4>;
+ reg = <0x01c21800 0x40>;
+ status = "disabled";
+ };
+
+ ir1: ir@01c21c00 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <_gates 7>, <_clk>;
+ clock-names = "apb", "ir";
+ interrupts = <0 6 4>;
+ reg = <0x01c21c00 0x40>;
+ status = "disabled";
+ };
+
lradc: lradc@01c22800 {
compatible = "allwinner,sun4i-lradc-keys";
reg = <0x01c22800 0x100>;
--
1.9.3
--
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 v8 0/3] ARM: sunxi: Add support for consumer infrared devices
This patch introduces Consumer IR(CIR) support for sunxi boards. This is based on Alexsey Shestacov's work based on the original driver supplied by Allwinner. Signed-off-by: Alexander Bersenev Signed-off-by: Alexsey Shestacov --- Changes since version 1: - Fix timer memory leaks - Fix race condition when driver unloads while interrupt handler is active - Support Cubieboard 2(need testing) Changes since version 2: - More reliable keydown events - Documentation fixes - Rename registers accurding to A20 user manual - Remove some includes, order includes alphabetically - Use BIT macro - Typo fixes Changes since version 3: - Split the patch on smaller parts - More documentation fixes - Add clock-names in DT - Use devm_clk_get function to get the clocks - Removed gpios property from ir's DT - Changed compatible from allwinner,sunxi-ir to allwinner,sun7i-a20-ir in DT - Use spin_lock_irq instead spin_lock_irqsave in interrupt handler - Add myself in the copyright ;) - Coding style and indentation fixes Changes since version 4: - Try to fix indentation errors by sending patches with git send-mail Changes since version 5: - More indentation fixes - Make patches pass checkpatch with --strict option - Replaced magic numbers with defines(patch by Priit Laes) - Fixed oops on loading(patch by Hans de Goede) Changes since version 6: - Removed constants from code - Better errrors handling on loading - Renamed sunxi-ir.c to sunxi-cir.c - Changed description of second commit - Order entries in dts and dtsi by register address - Code style fixes Changes since version 7: - Removed a couple of blank lines in code - Delay interrupts init until we are ready to handle them - Increased the reported duration of each pulse by one - Refactored defines Alexander Bersenev (3): ARM: sunxi: Add documentation for sunxi consumer infrared devices [media] rc: add sunxi-ir driver ARM: sunxi: Add IR controller support in DT on A20 .../devicetree/bindings/media/sunxi-ir.txt | 23 ++ arch/arm/boot/dts/sun7i-a20-cubieboard2.dts| 6 + arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 6 + arch/arm/boot/dts/sun7i-a20.dtsi | 32 +++ drivers/media/rc/Kconfig | 10 + drivers/media/rc/Makefile | 1 + drivers/media/rc/sunxi-cir.c | 313 + 7 files changed, 391 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt create mode 100644 drivers/media/rc/sunxi-cir.c -- 1.9.3 -- 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: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
Quoting James Bottomley (james.bottom...@hansenpartnership.com): > On Sat, 2014-05-24 at 22:25 +, Serge Hallyn wrote: > > Quoting James Bottomley (james.bottom...@hansenpartnership.com): > > > On Fri, 2014-05-23 at 11:20 +0300, Marian Marinov wrote: > > > > On 05/20/2014 05:19 PM, Serge Hallyn wrote: > > > > > Quoting Andy Lutomirski (l...@amacapital.net): > > > > >> On May 15, 2014 1:26 PM, "Serge E. Hallyn" wrote: > > > > >>> > > > > >>> Quoting Richard Weinberger (rich...@nod.at): > > > > Am 15.05.2014 21:50, schrieb Serge Hallyn: > > > > > Quoting Richard Weinberger (richard.weinber...@gmail.com): > > > > >> On Thu, May 15, 2014 at 4:08 PM, Greg Kroah-Hartman > > > > >> wrote: > > > > >>> Then don't use a container to build such a thing, or fix the > > > > >>> build scripts to not do that :) > > > > >> > > > > >> I second this. To me it looks like some folks try to (ab)use > > > > >> Linux containers for purposes where KVM > > > > >> would much better fit in. Please don't put more complexity into > > > > >> containers. They are already horrible > > > > >> complex and error prone. > > > > > > > > > > I, naturally, disagree :) The only use case which is inherently > > > > > not valid for containers is running a > > > > > kernel. Practically speaking there are other things which likely > > > > > will never be possible, but if someone > > > > > offers a way to do something in containers, "you can't do that in > > > > > containers" is not an apropos response. > > > > > > > > > > "That abstraction is wrong" is certainly valid, as when vpids > > > > > were originally proposed and rejected, > > > > > resulting in the development of pid namespaces. "We have to work > > > > > out (x) first" can be valid (and I can > > > > > think of examples here), assuming it's not just trying to hide > > > > > behind a catch-22/chicken-egg problem. > > > > > > > > > > Finally, saying "containers are complex and error prone" is > > > > > conflating several large suites of userspace > > > > > code and many kernel features which support them. Being more > > > > > precise would, if the argument is valid, lend > > > > > it a lot more weight. > > > > > > > > We (my company) use Linux containers since 2011 in production. > > > > First LXC, now libvirt-lxc. To understand the > > > > internals better I also wrote my own userspace to create/start > > > > containers. There are so many things which can > > > > hurt you badly. With user namespaces we expose a really big attack > > > > surface to regular users. I.e. Suddenly a > > > > user is allowed to mount filesystems. > > > > >>> > > > > >>> That is currently not the case. They can mount some virtual > > > > >>> filesystems and do bind mounts, but cannot mount > > > > >>> most real filesystems. This keeps us protected (for now) from > > > > >>> potentially unsafe superblock readers in the > > > > >>> kernel. > > > > >>> > > > > Ask Andy, he found already lots of nasty things... > > > > >> > > > > >> I don't think I have anything brilliant to add to this discussion > > > > >> right now, except possibly: > > > > >> > > > > >> ISTM that Linux distributions are, in general, vulnerable to all > > > > >> kinds of shenanigans that would happen if an > > > > >> untrusted user can cause a block device to appear. That user > > > > >> doesn't need permission to mount it > > > > > > > > > > Interesting point. This would further suggest that we absolutely > > > > > must ensure that a loop device which shows up in > > > > > the container does not also show up in the host. > > > > > > > > Can I suggest the usage of the devices cgroup to achieve that? > > > > > > Not really ... cgroups impose resource limits, it's namespaces that > > > impose visibility separations. In theory this can be done with the > > > device namespace that's been proposed; however, a simpler way is simply > > > to rm the device node in the host and mknod it in the guest. I don't > > > really see host visibility as a huge problem: in a shared OS > > > virtualisation it's not really possible securely to separate the guest > > > from the host (only vice versa). > > > > > > But I really don't think we want to do it this way. Giving a container > > > the ability to do a mount is too dangerous. What we want to do is > > > intercept the mount in the host and perform it on behalf of the guest as > > > host root in the guest's mount namespace. If you do it that way, it > > > > That doesn't help the problem of guests being able to provide bad input > > for (basically fuzz) the in-kernel filesystem code. So apparently I'm > > suffering a failure of the imagination - what problem exactly does it solve? > > Well, there's two types of fuzzing, one is on sys_mount, which this > would help with because the host
[PATCH v3] staging: lustre: lnet: klnds: Fix coding style in socklnd.c
Remove prohibited space between function name and
open parenthesis to meet kernel coding style.
Also fix indenting due to changes to keep readability.
-since v2:
None. This is the resend of v2 as v2 failed to apply
Signed-off-by: Masaru Nomura
---
.../staging/lustre/lnet/klnds/socklnd/socklnd.c| 242 ++--
1 file changed, 120 insertions(+), 122 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
index 21d36ee..39b607f 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
@@ -65,15 +65,15 @@ ksocknal_ip2iface(lnet_ni_t *ni, __u32 ip)
}
ksock_route_t *
-ksocknal_create_route (__u32 ipaddr, int port)
+ksocknal_create_route(__u32 ipaddr, int port)
{
ksock_route_t *route;
- LIBCFS_ALLOC (route, sizeof (*route));
+ LIBCFS_ALLOC(route, sizeof(*route));
if (route == NULL)
return (NULL);
- atomic_set (>ksnr_refcount, 1);
+ atomic_set(>ksnr_refcount, 1);
route->ksnr_peer = NULL;
route->ksnr_retry_interval = 0; /* OK to connect at any time */
route->ksnr_ipaddr = ipaddr;
@@ -89,27 +89,27 @@ ksocknal_create_route (__u32 ipaddr, int port)
}
void
-ksocknal_destroy_route (ksock_route_t *route)
+ksocknal_destroy_route(ksock_route_t *route)
{
- LASSERT (atomic_read(>ksnr_refcount) == 0);
+ LASSERT(atomic_read(>ksnr_refcount) == 0);
if (route->ksnr_peer != NULL)
ksocknal_peer_decref(route->ksnr_peer);
- LIBCFS_FREE (route, sizeof (*route));
+ LIBCFS_FREE(route, sizeof(*route));
}
int
-ksocknal_create_peer (ksock_peer_t **peerp, lnet_ni_t *ni, lnet_process_id_t
id)
+ksocknal_create_peer(ksock_peer_t **peerp, lnet_ni_t *ni, lnet_process_id_t id)
{
ksock_net_t *net = ni->ni_data;
ksock_peer_t *peer;
- LASSERT (id.nid != LNET_NID_ANY);
- LASSERT (id.pid != LNET_PID_ANY);
- LASSERT (!in_interrupt());
+ LASSERT(id.nid != LNET_NID_ANY);
+ LASSERT(id.pid != LNET_PID_ANY);
+ LASSERT(!in_interrupt());
- LIBCFS_ALLOC (peer, sizeof (*peer));
+ LIBCFS_ALLOC(peer, sizeof(*peer));
if (peer == NULL)
return -ENOMEM;
@@ -117,17 +117,17 @@ ksocknal_create_peer (ksock_peer_t **peerp, lnet_ni_t
*ni, lnet_process_id_t id)
peer->ksnp_ni = ni;
peer->ksnp_id = id;
- atomic_set (>ksnp_refcount, 1); /* 1 ref for caller */
+ atomic_set(>ksnp_refcount, 1); /* 1 ref for caller */
peer->ksnp_closing = 0;
peer->ksnp_accepting = 0;
peer->ksnp_proto = NULL;
peer->ksnp_last_alive = 0;
peer->ksnp_zc_next_cookie = SOCKNAL_KEEPALIVE_PING + 1;
- INIT_LIST_HEAD (>ksnp_conns);
- INIT_LIST_HEAD (>ksnp_routes);
- INIT_LIST_HEAD (>ksnp_tx_queue);
- INIT_LIST_HEAD (>ksnp_zc_req_list);
+ INIT_LIST_HEAD(>ksnp_conns);
+ INIT_LIST_HEAD(>ksnp_routes);
+ INIT_LIST_HEAD(>ksnp_tx_queue);
+ INIT_LIST_HEAD(>ksnp_zc_req_list);
spin_lock_init(>ksnp_lock);
spin_lock_bh(>ksnn_lock);
@@ -149,21 +149,21 @@ ksocknal_create_peer (ksock_peer_t **peerp, lnet_ni_t
*ni, lnet_process_id_t id)
}
void
-ksocknal_destroy_peer (ksock_peer_t *peer)
+ksocknal_destroy_peer(ksock_peer_t *peer)
{
ksock_net_t*net = peer->ksnp_ni->ni_data;
- CDEBUG (D_NET, "peer %s %p deleted\n",
- libcfs_id2str(peer->ksnp_id), peer);
+ CDEBUG(D_NET, "peer %s %p deleted\n",
+ libcfs_id2str(peer->ksnp_id), peer);
- LASSERT (atomic_read (>ksnp_refcount) == 0);
- LASSERT (peer->ksnp_accepting == 0);
- LASSERT (list_empty (>ksnp_conns));
- LASSERT (list_empty (>ksnp_routes));
- LASSERT (list_empty (>ksnp_tx_queue));
- LASSERT (list_empty (>ksnp_zc_req_list));
+ LASSERT(atomic_read(>ksnp_refcount) == 0);
+ LASSERT(peer->ksnp_accepting == 0);
+ LASSERT(list_empty(>ksnp_conns));
+ LASSERT(list_empty(>ksnp_routes));
+ LASSERT(list_empty(>ksnp_tx_queue));
+ LASSERT(list_empty(>ksnp_zc_req_list));
- LIBCFS_FREE (peer, sizeof (*peer));
+ LIBCFS_FREE(peer, sizeof(*peer));
/* NB a peer's connections and routes keep a reference on their peer
* until they are destroyed, so we can be assured that _all_ state to
@@ -175,17 +175,17 @@ ksocknal_destroy_peer (ksock_peer_t *peer)
}
ksock_peer_t *
-ksocknal_find_peer_locked (lnet_ni_t *ni, lnet_process_id_t id)
+ksocknal_find_peer_locked(lnet_ni_t *ni, lnet_process_id_t id)
{
struct list_head *peer_list = ksocknal_nid2peerlist(id.nid);
struct list_head *tmp;
ksock_peer_t *peer;
- list_for_each (tmp, peer_list) {
+ list_for_each(tmp, peer_list) {
- peer = list_entry (tmp, ksock_peer_t, ksnp_list);
[PATCHv2] nbd: Zero from and len fields in NBD_CMD_DISCONNECT.
Len field is already set to zero, but not the from field which is sent as
0xfe00. This makes no sense, and may cause confuse server
implementations doing sanity checks (qemu-nbd is an example.)
Signed-off-by: Hani Benhabiles
---
Compared to v1:
* Zero the request structure instead of conditionally zeroing specific fields.
drivers/block/nbd.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 3a70ea2..8e1df52 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -243,14 +243,11 @@ static int nbd_send_req(struct nbd_device *nbd, struct
request *req)
struct nbd_request request;
unsigned long size = blk_rq_bytes(req);
+ memset(, 0, sizeof(request));
request.magic = htonl(NBD_REQUEST_MAGIC);
request.type = htonl(nbd_cmd(req));
- if (nbd_cmd(req) == NBD_CMD_FLUSH) {
- /* Other values are reserved for FLUSH requests. */
- request.from = 0;
- request.len = 0;
- } else {
+ if (nbd_cmd(req) != NBD_CMD_FLUSH && nbd_cmd(req) != NBD_CMD_DISC) {
request.from = cpu_to_be64((u64)blk_rq_pos(req) << 9);
request.len = htonl(size);
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Silicom: bpctl_mod.c & bypass.c: Fixed a lot of checkpatch.pl warnings
On Sun, May 25, 2014 at 11:59:08AM -0700, Chaitanya Hazarey wrote: > Added a blank line after declarations in many places to fix the following > warning issued by checkpatch.pl: > > WARNING: Missing a blank line after declarations > > Lets see if this works now, this patch is prepared against Greg's staging > tree. What branch of my staging.git tree are you using? You should use the staging-next branch, this patch still doesn't apply to there :( greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next] imx-drm: imx-tve: remove unused variable
On Sun, May 25, 2014 at 11:54:14PM +0200, Vincent Stehlé wrote: > Commit f9b0e251dfbf 'drm: make mode_valid callback optional' left variable ret > unused; remove it. > > This fixes the following compilation warning: > > drivers/staging/imx-drm/imx-tve.c: In function > ‘imx_tve_connector_mode_valid’: > drivers/staging/imx-drm/imx-tve.c:252:6: warning: unused variable ‘ret’ > [-Wunused-variable] It doesn't apply to my tree :( -- 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] serial: efm32: add module_exit
On Sun, May 25, 2014 at 11:13:05PM +0200, Vincent Stehlé wrote: > Add missing specification of efm32_uart_exit as module_exit. > > This fixes the following compilation warning: > > drivers/tty/serial/efm32-uart.c:840:123: warning: ‘efm32_uart_exit’ defined > but not used [-Wunused-function] This warning doesn't occur in my builds, probably because I have MODULES=n. I can reproduce it on allmodconfig though. > Signed-off-by: Vincent Stehlé > Cc: Uwe Kleine-König Acked-by: Uwe Kleine-König Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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 linux-next] imx-drm: imx-tve: remove unused variable
Commit f9b0e251dfbf 'drm: make mode_valid callback optional' left variable ret
unused; remove it.
This fixes the following compilation warning:
drivers/staging/imx-drm/imx-tve.c: In function ‘imx_tve_connector_mode_valid’:
drivers/staging/imx-drm/imx-tve.c:252:6: warning: unused variable ‘ret’
[-Wunused-variable]
Signed-off-by: Vincent Stehlé
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
---
Hi,
This can be seen with e.g. linux next-20140523 and arm allmodconfig.
Best regards,
V.
drivers/staging/imx-drm/imx-tve.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/imx-drm/imx-tve.c
b/drivers/staging/imx-drm/imx-tve.c
index 3e8b0a1..4caef2b1 100644
--- a/drivers/staging/imx-drm/imx-tve.c
+++ b/drivers/staging/imx-drm/imx-tve.c
@@ -249,7 +249,6 @@ static int imx_tve_connector_mode_valid(struct
drm_connector *connector,
{
struct imx_tve *tve = con_to_tve(connector);
unsigned long rate;
- int ret;
/* pixel clock with 2x oversampling */
rate = clk_round_rate(tve->clk, 2000UL * mode->clock) / 2000;
--
2.0.0.rc2
--
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] nbd: Zero from and len fields in NBD_CMD_DISCONNECT.
On Sun, May 25, 2014 at 02:11:13PM -0400, Paul Clements wrote:
> On Sun, May 25, 2014 at 6:18 AM, Hani Benhabiles wrote:
> > On Sun, May 18, 2014 at 10:11:13AM +0100, Hani Benhabiles wrote:
> >> On Fri, May 16, 2014 at 10:56:33PM -0400, Paul Clements wrote:
> >> > Agreed. But better yet, the request structure should just be zeroed when
> >> > it's allocated.
> >> >
> >>
> >> It is already initialized in __nbd_ioctl() with the blk_rq_init() call
> >> which
> >> sets the __sector value to -1 (which is 0xfe00 after the left
> >> shifts.)
> >>
> >> This is the only (non-ugly / non-intrusive) way to do it afaict.
> >>
> >
> > Ping!
> >
> > Anything blocking this patch ?
>
> It's cleaner to just zero the struct and get rid of the conditional
> zeroing of specific fields. I'll prepare a patch in the next few days.
>
Sorry, I misunderstood which struct you were talking about!
Will send a v2 shortly.
> Thanks,
> Paul
>
> >> > On Fri, May 16, 2014 at 7:43 PM, Hani Benhabiles
> >> > wrote:
> >> >
> >> > > Len field is already set to zero, but not the from field which is sent
> >> > > as
> >> > > 0xfe00. This makes no sense, and may cause confuse server
> >> > > implementations doing sanity checks (qemu-nbd is an example.)
> >> > >
> >> > > Signed-off-by: Hani Benhabiles
> >> > > ---
> >> > > drivers/block/nbd.c | 2 +-
> >> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> > >
> >> > > diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> >> > > index 3a70ea2..657bdac 100644
> >> > > --- a/drivers/block/nbd.c
> >> > > +++ b/drivers/block/nbd.c
> >> > > @@ -246,7 +246,7 @@ static int nbd_send_req(struct nbd_device *nbd,
> >> > > struct
> >> > > request *req)
> >> > > request.magic = htonl(NBD_REQUEST_MAGIC);
> >> > > request.type = htonl(nbd_cmd(req));
> >> > >
> >> > > - if (nbd_cmd(req) == NBD_CMD_FLUSH) {
> >> > > + if (nbd_cmd(req) == NBD_CMD_FLUSH || nbd_cmd(req) ==
> >> > > NBD_CMD_DISC)
> >> > > {
> >> > > /* Other values are reserved for FLUSH requests. */
> >> > > request.from = 0;
> >> > > request.len = 0;
> >> > > --
> >> > > 1.8.3.2
> >> > >
> >> > >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/18] Cross-architecture definitions of relaxed MMIO accessors
On Thu, 2014-05-22 at 17:47 +0100, Will Deacon wrote: > A corollary to this is that mmiowb() probably needs rethinking. As it > currently > stands, an mmiowb() is required to order MMIO writes to a device from multiple > CPUs, even if that device is protected by a lock. However, this isn't often > used > in practice, leading to PowerPC implementing both mmiowb() *and* synchronising > I/O in spin_unlock. > > I would propose making the non-relaxed I/O accessors ordered with respect to > LOCK/UNLOCK, leaving mmiowb() to be used with the relaxed accessors, if > required, but would welcome thoughts/suggestions on this topic. I agree on the proposed semantics, though for us that does mean we still need that per-cpu flag tracking non-relaxed MMIO stores and corresponding added barrier in unlock. Eventually, if the use of the relaxed accessors becomes pervasive enough I suppose I can just make the ordered ones unconditionally do 2 barriers. Cheers, Ben. -- 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] serial: efm32: add module_exit
Add missing specification of efm32_uart_exit as module_exit.
This fixes the following compilation warning:
drivers/tty/serial/efm32-uart.c:840:123: warning: ‘efm32_uart_exit’ defined
but not used [-Wunused-function]
Signed-off-by: Vincent Stehlé
Cc: Uwe Kleine-König
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
---
Hi,
This can be seen with e.g. arm allmodconfig.
Best regards,
V.
drivers/tty/serial/efm32-uart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/efm32-uart.c b/drivers/tty/serial/efm32-uart.c
index c167a71..b373f64 100644
--- a/drivers/tty/serial/efm32-uart.c
+++ b/drivers/tty/serial/efm32-uart.c
@@ -842,6 +842,7 @@ static void __exit efm32_uart_exit(void)
platform_driver_unregister(_uart_driver);
uart_unregister_driver(_uart_reg);
}
+module_exit(efm32_uart_exit);
MODULE_AUTHOR("Uwe Kleine-Koenig ");
MODULE_DESCRIPTION("EFM32 UART/USART driver");
--
2.0.0.rc2
--
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] do_mounts: try all available filesystems before panicking
On Sun, May 25, 2014 at 01:04:09PM -0700, Linus Torvalds wrote:
>
> The fact is, I think xfs is just buggy. Returning 38 (ENOSYS) is
> totally insane. "No such system call"? Somebody is on some bad bad
> drugs. Not that the mount_block_root() loop and error handling might
> not be a good thing to perhaps tweak _too_, but at the very least your
> patch means that now it no longer prints out the error number at all.
There's only a single instance of ENOSYS in fs/xfs/xfs_mount.c:
/*
* We must be able to do sector-sized and sector-aligned IO.
*/
if (sector_size > sbp->sb_sectsize) {
if (loud)
xfs_warn(mp, "device supports %u byte sectors (not %u)",
sector_size, sbp->sb_sectsize);
error = ENOSYS;
goto release_buf;
}
Plamen, does changing the ENOSYS to EINVAL above fix things for you?
> Anyway, I'm also not seeing why that xfs error would be new to 3.14,
> though.. Adding the XFS people to the cc.
If I had to guess, commit daba5427d is new to 3.14, and it might
explain the change in behavior.
Cheers,
- 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/
scaling of msgmni
Hi Nadia, You added a patch that adds dynamic scaling of MSGMNI (f7bf3df8). The description begins with: On large systems we'd like to allow a larger number of message queues. In some cases up to 32K. However simply setting MSGMNI to a larger value may cause problems for smaller systems. Which problems did you imagine? For shm, we have just completed patches that set the limit to (nearly) ULONG_MAX as default. Perhaps we could do the same step for msg, too? Remove the whole logic, increase the limits to the maximum supported. (or, if your concerns are valid and apply to shm, too - drop the patch for shm). -- Manfred -- 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 v10 3/3] ARM: dts: Add initial device tree support for EXYNOS5410
On 05/24/14 06:15, Tomasz Figa wrote: Hi Tarek, On 23.05.2014 12:35, Tarek Dakhran wrote: Add initial device tree nodes for EXYNOS5410 SoC and SMDK5410 board. Signed-off-by: Tarek Dakhran Signed-off-by: Vyacheslav Tyrtov --- arch/arm/boot/dts/Makefile|1 + arch/arm/boot/dts/exynos5410-smdk5410.dts | 82 arch/arm/boot/dts/exynos5410.dtsi | 206 + 3 files changed, 289 insertions(+) create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts create mode 100644 arch/arm/boot/dts/exynos5410.dtsi Looks good. Hopefully we can have this patch applied soon, so it won't get outdated again. Yes. Tarek, please respin as soon as possible. Reviewed-by: Tomasz Figa - Kukjin -- 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] KVM: x86: MOV CR/DR emulation should ignore mod
MOV CR/DR instructions ignore the mod field (in the ModR/M byte). As the SDM
states: "The 2 bits in the mod field are ignored". Accordingly, the second
operand of these instructions is always a general purpose register.
The current emulator implementation does not do so. If the mod bits do not
equal 3, it expects the second operand to be in memory.
Signed-off-by: Nadav Amit
---
arch/x86/kvm/emulate.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 2fa7ab0..e4e833d 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -161,6 +161,7 @@
#define Fastop ((u64)1 << 44) /* Use opcode::u.fastop */
#define NoWrite ((u64)1 << 45) /* No writeback */
#define SrcWrite((u64)1 << 46) /* Write back src operand */
+#define NoMod ((u64)1 << 47) /* Mod field is ignored */
#define DstXacc (DstAccLo | SrcAccHi | SrcWrite)
@@ -1077,7 +1078,7 @@ static int decode_modrm(struct x86_emulate_ctxt *ctxt,
ctxt->modrm_rm |= (ctxt->modrm & 0x07);
ctxt->modrm_seg = VCPU_SREG_DS;
- if (ctxt->modrm_mod == 3) {
+ if (ctxt->modrm_mod == 3 || (ctxt->d & NoMod)) {
op->type = OP_REG;
op->bytes = (ctxt->d & ByteOp) ? 1 : ctxt->op_bytes;
op->addr.reg = decode_register(ctxt, ctxt->modrm_rm,
@@ -3877,10 +3878,12 @@ static const struct opcode twobyte_table[256] = {
N, N, N, N, N, N, N, N,
D(ImplicitOps | ModRM), N, N, N, N, N, N, D(ImplicitOps | ModRM),
/* 0x20 - 0x2F */
- DIP(ModRM | DstMem | Priv | Op3264, cr_read, check_cr_read),
- DIP(ModRM | DstMem | Priv | Op3264, dr_read, check_dr_read),
- IIP(ModRM | SrcMem | Priv | Op3264, em_cr_write, cr_write,
check_cr_write),
- IIP(ModRM | SrcMem | Priv | Op3264, em_dr_write, dr_write,
check_dr_write),
+ DIP(ModRM | DstMem | Priv | Op3264 | NoMod, cr_read, check_cr_read),
+ DIP(ModRM | DstMem | Priv | Op3264 | NoMod, dr_read, check_dr_read),
+ IIP(ModRM | SrcMem | Priv | Op3264 | NoMod, em_cr_write, cr_write,
+ check_cr_write),
+ IIP(ModRM | SrcMem | Priv | Op3264 | NoMod, em_dr_write, dr_write,
+ check_dr_write),
N, N, N, N,
GP(ModRM | DstReg | SrcMem | Mov | Sse, _0f_28_0f_29),
GP(ModRM | DstMem | SrcReg | Mov | Sse, _0f_28_0f_29),
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] do_mounts: try all available filesystems before panicking
On Mon, May 5, 2014 at 11:34 AM, Plamen Petrov wrote:
>
> The story short: on systems with btrfs root I have a kernel .config with ext4,
> xfs and btrfs built-in which works fine with 3.13.x, but 3.14.x panics. After
> inserting some debug printks, I got this info from mount_block_root:
>
> ---> EACCESS=13, EINVAL=22, Available filesystems: ext3 ext2 ext4 fuseblk xfs
> btrfs
> -> Tried ext3, error code is -22.
> -> Tried ext2, error code is -22.
> -> Tried ext4, error code is -22.
> -> Tried fuseblk, error code is -22.
> -> Tried xfs, error code is -38.
> VFS: Cannot open root device "sda2" or unknown-block(8,2): error -38
> Please append a correct "root=" boot option; here are the available
> partitions:
>
> Last one tried is xfs, the needed btrfs in this case never gets a chance.
> Looking at the code in init/do_mounts.c we can see that it "continue"s only if
> the return code it got is EINVAL, yet xfs clearly does not fit - so the kernel
> panics. Maybe there are other filesystems like xfs - I did not check. This
> patch fixes mount_block_root to try all available filesystems first, and then
> panic. The patched 3.14.x works for me.
Hmm. I don't really dislike your patch, but it makes all the code
_after_ the switch-statement dead, since there is now no way to ever
fall through the switch statement.
So now that
/*
* Allow the user to distinguish between failed sys_open
* and bad superblock on root device.
* and give them a list of the available devices
*/
comment ends up being entirely stale, and the code after it is
pointless and it all looks very misleading. And I'm assuming somebody
cared about that difference at some point.
The fact is, I think xfs is just buggy. Returning 38 (ENOSYS) is
totally insane. "No such system call"? Somebody is on some bad bad
drugs. Not that the mount_block_root() loop and error handling might
not be a good thing to perhaps tweak _too_, but at the very least your
patch means that now it no longer prints out the error number at all.
Maybe just making it do something like the attached patch instead? It
doesn't panic on unrecognized errors, just prints them out (just once,
if it repeats). It also doesn't do the "goto repeat" if we already
have the RDONLY bit set, because if somebody is returning insane error
numbers, that could otherwise result in an endless loop.
Anyway, I'm also not seeing why that xfs error would be new to 3.14,
though.. Adding the XFS people to the cc.
Comments (patch obviously TOTALLY UNTESTED)
Linus
init/do_mounts.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 82f22885c87e..a6a725f46f18 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -385,6 +385,7 @@ void __init mount_block_root(char *name, int flags)
#else
const char *b = name;
#endif
+ int last_err = 0;
get_fs_names(fs_names);
retry:
@@ -394,29 +395,16 @@ retry:
case 0:
goto out;
case -EACCES:
+ if (flags & MS_RDONLY)
+ break;
flags |= MS_RDONLY;
goto retry;
case -EINVAL:
continue;
}
- /*
-* Allow the user to distinguish between failed sys_open
-* and bad superblock on root device.
-* and give them a list of the available devices
-*/
-#ifdef CONFIG_BLOCK
- __bdevname(ROOT_DEV, b);
-#endif
- printk("VFS: Cannot open root device \"%s\" or %s: error %d\n",
- root_device_name, b, err);
- printk("Please append a correct \"root=\" boot option; here are
the available partitions:\n");
-
- printk_all_partitions();
-#ifdef CONFIG_DEBUG_BLOCK_EXT_DEVT
- printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
- "explicit textual name for \"root=\" boot option.\n");
-#endif
- panic("VFS: Unable to mount root fs on %s", b);
+ if (err != last_err)
+ printk("VFS: Cannot open root device \"%s\" or %s:
error %d\n",
+ root_device_name, b, err);
}
printk("List of all partitions:\n");
Re: [PATCH] IPC initialize shmmax and shmall from the current value not the default
Hi Marian,
On 05/22/2014 03:01 PM, Marian Marinov wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/05/2014 10:59 PM, Marian Marinov wrote:
In my tests it worked exactly as expected. Here is an example:
[root@sp2 ~]# sysctl -a|grep shmmax kernel.shmmax = 68719476736 [root@sp2 ~]#
lxc-attach -n cent_plain
[root@localhost ~]# sysctl -a|grep shmmax kernel.shmmax = 68719476736
[root@localhost ~]# halt [root@sp2 ~]# sysctl
-a|grep shmmax kernel.shmmax = 68719476736 [root@sp2 ~]# sysctl
kernel.shmmax=34359738368 kernel.shmmax =
34359738368 [root@sp2 ~]# lxc-start -n cent_plain -d [root@sp2 ~]# lxc-attach
-n cent_plain [root@localhost ~]#
sysctl -a|grep shmmax kernel.shmmax = 34359738368 [root@localhost ~]#
So it seams to work as expected :)
It works because wen you setup a new shmmax limit it is actually the limit in
the init_ipc_ns. So when we are
creating a new ipc_ns its ok to copy the values from init_ipc_ns.
-Marian
Ping?
So will there be any more comments on that?
Attached is an untested idea:
- each new namespace copies from it's parent, i.e. nested namespaces
should work.
- msg, sem and shm updated
--
Manfred
>From ed73ce838fc3f55e34041591a72b3135ccaa460b Mon Sep 17 00:00:00 2001
From: Manfred Spraul
Date: Sun, 25 May 2014 21:04:42 +0200
Subject: [PATCH] ipc namespace: copy settings from parent namespace
Right now, each IPC namespace starts with the kernel boot standard
settings.
This patch changes that:
Now each new namespace starts with the settings from the parent
namespace.
The patch updates msg, sem and shm.
Marian: Would that patch help you?
It's just a proposal - not yet tested.
Open issues:
- auto_msgmni is not yet taken from parent.
--
Manfred
---
ipc/msg.c | 13 +
ipc/namespace.c | 6 +++---
ipc/sem.c | 19 +--
ipc/shm.c | 19 +--
ipc/util.h | 12 ++--
5 files changed, 44 insertions(+), 25 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 6498531..6c72d43 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -107,10 +107,15 @@ void recompute_msgmni(struct ipc_namespace *ns)
ns->msg_ctlmni = allowed;
}
-void msg_init_ns(struct ipc_namespace *ns)
+void msg_init_ns(struct ipc_namespace *ns, struct ipc_namespace *old_ns)
{
- ns->msg_ctlmax = MSGMAX;
- ns->msg_ctlmnb = MSGMNB;
+ if (old_ns != NULL) {
+ ns->msg_ctlmax = old_ns->msg_ctlmax;
+ ns->msg_ctlmnb = old_ns->msg_ctlmnb;
+ } else {
+ ns->msg_ctlmax = MSGMAX;
+ ns->msg_ctlmnb = MSGMNB;
+ }
recompute_msgmni(ns);
@@ -129,7 +134,7 @@ void msg_exit_ns(struct ipc_namespace *ns)
void __init msg_init(void)
{
- msg_init_ns(_ipc_ns);
+ msg_init_ns(_ipc_ns, NULL);
printk(KERN_INFO "msgmni has been set to %d\n",
init_ipc_ns.msg_ctlmni);
diff --git a/ipc/namespace.c b/ipc/namespace.c
index 59451c1..57b65fa 100644
--- a/ipc/namespace.c
+++ b/ipc/namespace.c
@@ -41,9 +41,9 @@ static struct ipc_namespace *create_ipc_ns(struct user_namespace *user_ns,
}
atomic_inc(_ipc_ns);
- sem_init_ns(ns);
- msg_init_ns(ns);
- shm_init_ns(ns);
+ sem_init_ns(ns, old_ns);
+ msg_init_ns(ns, old_ns);
+ shm_init_ns(ns, old_ns);
/*
* msgmni has already been computed for the new ipc ns.
diff --git a/ipc/sem.c b/ipc/sem.c
index bee5554..0e232e6 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -170,12 +170,19 @@ static int sysvipc_sem_proc_show(struct seq_file *s, void *it);
#define sc_semopm sem_ctls[2]
#define sc_semmni sem_ctls[3]
-void sem_init_ns(struct ipc_namespace *ns)
+void sem_init_ns(struct ipc_namespace *ns, struct ipc_namespace *old_ns)
{
- ns->sc_semmsl = SEMMSL;
- ns->sc_semmns = SEMMNS;
- ns->sc_semopm = SEMOPM;
- ns->sc_semmni = SEMMNI;
+ if (old_ns != NULL) {
+ ns->sc_semmsl = old_ns->sc_semmsl;
+ ns->sc_semmns = old_ns->sc_semmns;
+ ns->sc_semopm = old_ns->sc_semopm;
+ ns->sc_semmni = old_ns->sc_semmni;
+ } else {
+ ns->sc_semmsl = SEMMSL;
+ ns->sc_semmns = SEMMNS;
+ ns->sc_semopm = SEMOPM;
+ ns->sc_semmni = SEMMNI;
+ }
ns->used_sems = 0;
ipc_init_ids(>ids[IPC_SEM_IDS]);
}
@@ -190,7 +197,7 @@ void sem_exit_ns(struct ipc_namespace *ns)
void __init sem_init(void)
{
- sem_init_ns(_ipc_ns);
+ sem_init_ns(_ipc_ns, NULL);
ipc_init_proc_interface("sysvipc/sem",
" key semid perms nsems uid gid cuid cgid otime ctime\n",
IPC_SEM_IDS, sysvipc_sem_proc_show);
diff --git a/ipc/shm.c b/ipc/shm.c
index 7645961..5c54b25 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -72,12 +72,19 @@ static void shm_destroy(struct ipc_namespace *ns, struct shmid_kernel *shp);
static int sysvipc_shm_proc_show(struct seq_file *s, void *it);
#endif
-void shm_init_ns(struct ipc_namespace *ns)
+void shm_init_ns(struct ipc_namespace *ns, struct ipc_namespace *old_ns)
{
- ns->shm_ctlmax = SHMMAX;
- ns->shm_ctlall = SHMALL;
- ns->shm_ctlmni = SHMMNI;
- ns->shm_rmid_forced = 0;
+ if (old_ns != NULL) {
+ ns->shm_ctlmax = old_ns->shm_ctlmax;
+ ns->shm_ctlall = old_ns->shm_ctlall;
+
kernel BUG at fs/jbd2/journal.c:1951!
Tried yesterdays git v3.15-rc6-190-g1ee1cea on Sun Fire T2000 (32-thread sparc64) and got reproducibly stuck on boot with ext journal replay like below. Booting Debian 3.14.2-1 replayed the log and mounted FS fine. After that, my test kernel works fine too. SO I can not reproduce it any more but it seems like I hit a bug. [ 62.064329] EXT4-fs (sda1): INFO: recovery required on readonly filesystem [ 62.064395] EXT4-fs (sda1): write access will be enabled during recovery [ 62.077043] EXT4-fs (sda1): orphan cleanup on readonly fs [ 62.156585] EXT4-fs (sda1): 14 orphan inodes deleted [ 62.156645] EXT4-fs (sda1): recovery complete [ 62.156702] kernel BUG at fs/jbd2/journal.c:1951! [ 62.156752] \|/ \|/ [ 62.156752] "@'/ .. \`@" [ 62.156752] /_| \__/ |_\ [ 62.156752] \__U_/ [ 62.156893] swapper/0(1): Kernel bad sw trap 5 [#1] [ 62.156943] CPU: 8 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc6+ #6 [ 62.157004] task: ff8008677640 ti: ff800870c000 task.ti: ff800870c000 [ 62.157079] TSTATE: 004480001605 TPC: 005f3c00 TNPC: 005f3c04 Y: Not tainted [ 62.157180] TPC: [ 62.157225] g0: 009528c8 g1: g2: 00a17f88 g3: 00a17f80 [ 62.157301] g4: ff8008677640 g5: ff83f6a4a000 g6: ff800870c000 g7: ff8008633fa0 [ 62.157375] o0: 0025 o1: 00961ed8 o2: 079f o3: ff83f3aab888 [ 62.157451] o4: ff83ffb72000 o5: 00961ed8 sp: ff800870ed11 ret_pc: 005f3bf8 [ 62.157530] RPC: [ 62.157575] l0: l1: 000e l2: 10018001 l3: 0088e438 [ 62.157650] l4: 009528c8 l5: ff00 l6: 00ff l7: 0095ee30 [ 62.157726] i0: ff83f3aab800 i1: ff83f3aab824 i2: ff83f3aabb98 i3: ff83f3aab8e8 [ 62.157801] i4: ff83f3aab824 i5: ff83f3aab8e8 i6: ff800870edc1 i7: 005bd640 [ 62.157887] I7: [ 62.157942] Call Trace: [ 62.157990] [005bd640] ext4_mark_recovery_complete.isra.232+0x4c/0xb0 [ 62.158068] [005c3860] ext4_fill_super+0x303c/0x33e8 [ 62.158132] [00538fc4] mount_bdev+0x124/0x18c [ 62.158192] [00539a4c] mount_fs+0x60/0x17c [ 62.158246] [0055087c] vfs_kern_mount+0x48/0xe4 [ 62.158309] [00552e24] do_mount+0x808/0x974 [ 62.158370] [005531b0] SyS_mount+0x6c/0xa4 [ 62.158427] [00a74cb8] mount_block_root+0x108/0x2ac [ 62.158490] [00a75180] prepare_namespace+0x180/0x1bc [ 62.158552] [00a74a80] kernel_init_freeable+0x208/0x218 [ 62.158619] [00864724] kernel_init+0x4/0xf4 [ 62.158684] [00406084] ret_from_fork+0x1c/0x2c [ 62.158738] [] (null) [ 62.158780] Disabling lock debugging due to kernel taint [ 62.158847] Caller[005bd640]: ext4_mark_recovery_complete.isra.232+0x4c/0xb0 [ 62.158926] Caller[005c3860]: ext4_fill_super+0x303c/0x33e8 [ 62.158990] Caller[00538fc4]: mount_bdev+0x124/0x18c [ 62.159051] Caller[00539a4c]: mount_fs+0x60/0x17c [ 62.159143] Caller[0055087c]: vfs_kern_mount+0x48/0xe4 [ 62.159215] Caller[00552e24]: do_mount+0x808/0x974 [ 62.159279] Caller[005531b0]: SyS_mount+0x6c/0xa4 [ 62.159345] Caller[00a74cb8]: mount_block_root+0x108/0x2ac [ 62.159411] Caller[00a75180]: prepare_namespace+0x180/0x1bc [ 62.159475] Caller[00a74a80]: kernel_init_freeable+0x208/0x218 [ 62.159540] Caller[00864724]: kernel_init+0x4/0xf4 [ 62.159604] Caller[00406084]: ret_from_fork+0x1c/0x2c [ 62.159660] Caller[]: (null) [ 62.166652] Instruction DUMP: 901222d8 7ff8d20a 0100 <91d02005> 11002587 921027a1 0af07ffb 901222d8 c45e2310 [ 62.207443] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 -- Meelis Roos (mr...@linux.ee) -- 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 06/22] clk: sunxi: Support factor clocks with N multiplier factor starting from 1
On Fri, May 23, 2014 at 03:51:09PM +0800, Chen-Yu Tsai wrote: > The PLLs on newer Allwinner SoC's, such as the A31 and A23, have a > N multiplier factor that starts from 1, not 0. > > This patch adds an option to the clock driver's config data structures > to define the difference. > > Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
