Re: [PATCH] mpt2sas: prevent double free on error path
Jörn Engel writes:
> diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
> b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
> index c6bdc92..43b3a98 100644
> --- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
> +++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
> @@ -570,6 +570,18 @@ _scsih_sas_device_find_by_handle(struct MPT2SAS_ADAPTER
> *ioc, u16 handle)
> return NULL;
> }
>
> +static void free_sas_device(struct kref *kref)
> +{
> + struct _sas_device *sas_device = container_of(kref, struct _sas_device,
> + kref);
> + kfree(sas_device);
> +}
> +
> +static void put_sas_device(struct _sas_device *sas_device)
> +{
> + kref_put(&sas_device->kref, free_sas_device);
> +}
> +
> /**
> * _scsih_sas_device_remove - remove sas_device from list.
> * @ioc: per adapter object
> @@ -583,14 +595,19 @@ _scsih_sas_device_remove(struct MPT2SAS_ADAPTER *ioc,
> struct _sas_device *sas_device)
> {
> unsigned long flags;
> + int was_on_list = 0;
>
> if (!sas_device)
> return;
>
> spin_lock_irqsave(&ioc->sas_device_lock, flags);
> - list_del(&sas_device->list);
> - kfree(sas_device);
> + if (!list_empty(&sas_device->list)) {
> + list_del_init(&sas_device->list);
> + was_on_list = 1;
> + }
> spin_unlock_irqrestore(&ioc->sas_device_lock, flags);
> + if (was_on_list)
> + put_sas_device(sas_device);
> }
>
How about the copy of this code in drivers/scsi/mpt3sas/mpt3sas_scsih.c?
Is that safe, or does it need fixing as well?
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/2] sched: simplify the select_task_rq_fair()
On Thu, 2013-01-24 at 15:15 +0800, Michael Wang wrote: > On 01/24/2013 02:51 PM, Mike Galbraith wrote: > > On Thu, 2013-01-24 at 14:01 +0800, Michael Wang wrote: > > > >> I've enabled WAKE flag on my box like you did, but still can't see > >> regression, and I've just tested on a power server with 64 cpu, also > >> failed to reproduce the issue (not compared with virgin yet, but can't > >> see collapse). > > > > I'm not surprised. I'm seeing enough inconsistent crap to come to the > > conclusion that stock scheduler knobs flat can't be used on a largish > > box, they're just too preempt-happy, leading to weird crap. > > > > My 2 missing nodes came back, and the very same kernel that highly > > repeatably collapsed with 2 nodes does not with 4 nodes, and 2 nodes > > does not collapse with only preemption knob tweaking, and that's > > bullshit. Virgin shows instability in the mid-range, make a tiny tweak > > that should have little if any effect there, and that instability > > vanishes entirely. Test runs are not consistent enough boot to boot etc > > etc. Either stock knobs suck on NUMA boxen, or this box is possessed. > > Mike, I wonder the reason why change back to the old way make collapse > away may not because there are logical error in new balance path, it's > just changed the cost of select_task_rq(), whatever it's more or less, > it's accidentally achieve the same effect as you tweak the knob, so > that's the reason why it looks like old is better than new. That's what I'm saying, it's a useless crap side-effect of a preempt happy kernel. Results with these knobs are just not stable. Results go wildly unstable with 2 nodes vs 4 in this box, but can be stabilized in all with preemption knob adjustment.. or phase of moon might make them appear stable.. or not. -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 1/2] tcp: make tcp_timestamp dependent on tcp_sock
On Wed, Jan 23, 2013 at 08:25:17AM -0800, Eric Dumazet wrote:
> > @@ -1142,9 +1145,11 @@ static inline void tcp_openreq_init(struct
> > request_sock *req,
> > static inline void tcp_synack_rtt_meas(struct sock *sk,
> >struct request_sock *req)
> > {
> > + const struct tcp_sock *tp = tcp_sk(sk);
> > +
> > if (tcp_rsk(req)->snt_synack)
> > tcp_valid_rtt_meas(sk,
> > - tcp_time_stamp - tcp_rsk(req)->snt_synack);
> > + tcp_time_stamp(tp) - tcp_rsk(req)->snt_synack);
> > }
> >
>
> This first chunk looks not needed.
>
> Can SYN_RECV sockets be live-migrated ? Probably not.
>
> Quite frankly I am sure there is an issue for timewait (not real
> sockets).
>
> Have you really tested this patch, or is it an RFC ?
I set RFC, when I'm not sure, that this idea is right and want to get
opinions and comments before spend a lot of time.
I have tested this patch. I have a virtuall machine, where I test
kernels. SSH is used for accessing this VM. My test dumps an outside
TCP connection, then reboots the VM and restores the TCP connection.
Without this patch the tcp connection are not restored correctly, but
with this patch it works properly.
A timestamp offset is zero by default, so I did not catch any bugs.
I will test my patches more carefully.
Thank you all for the comments and sorry for noise in the ML.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] i2c-designware: add Intel Lynxpoint support
On Thu, Jan 17, 2013 at 12:31:03PM +0200, Mika Westerberg wrote: > Hi all, > > This series adds support for the Intel Lynxpoint Low Power Subsystem I2C > controllers. They are compatible with the DesignWare I2C controller. > > Patches [1/4] and [2/4] are fixes that are necessary to get the driver > working on Lynxpoint. > > Patch [3/4] brings minimal runtime PM support for the designware platform > driver. This is useful if the PM subsystem/domain implements runtime PM, > like in case of ACPI. > > Patch [4/4] finally implements ACPI enumeration support for the designware > platform driver and adds Lynxpoint ACPI IDs. I can't tell much about ACPI usage, but rest looks good to me. Applied to next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] i2c: tegra: add support for Tegra114 SoC
On Sat, Jan 05, 2013 at 05:34:46PM +0530, Laxman Dewangan wrote: > NVIDIA's Tegra114 has following enhanced feature in i2c controller: > - Enable/disable control for per packet transfer complete interrupt. > Earlier SoCs could not disable this. > - Single clock source for standard/fast and HS mode clock speed. > The clock divisor for fast/standard mode is added into the i2c > controller to meet the HS and standard/fast mode of clock speed > from single source. > > Add support for the above feature to make it functional on T114 SOCs. Thanks, applied to next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers: i2c-nforce2: fix coding style issues
On Thu, Jan 10, 2013 at 03:07:42PM +0100, Laurent Navet wrote:
> avoid these checkpatch.pl issues :
> - ERROR: "foo * bar" should be "foo *bar"
> - ERROR: switch and case should be at the same indent
> - ERROR: "(foo*)" should be "(foo *)"
> - ERROR: do not use assignment in if condition
> - ERROR: space required before the open parenthesis '('
> - WARNING: suspect code indent for conditional statements
> - WARNING: quoted string split across lines
> - WARNING: space prohibited between function name and open parenthesis '('
> - WARNING: line over 80 characters
> also add spaces around some "+", "=", "*"
>
> Signed-off-by: Laurent Navet
Thanks, applied to for-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC] misc/at24: distinguish between eeprom and fram chips
On Fri, Dec 07, 2012 at 11:14:28AM +0100, Lars Poeschel wrote: > > > > > I wanted to use a fm24c04 i2c fram chip with linux. I grepped the > > > > > source and found nothing. I later found that my chip can be handled > > > > > by at24 eeprom driver. It creates a sysfs file called eeprom to > > > > > read from and write to the chip. Userspace has no chance to > > > > > distinguish if it is writing an eeprom or a fram chip. > > > > > > > > Why should it? > > > > > > Because writes are much faster and it doesn't have to take care on erase > > > cycles. It could use other write strategies on such devices and update > > > informations that have to survive power downs more often. > > > > I agree. I think that a seperate attribute named e.g. 'page_size' would > > be more helpful than renaming the binary file to fram? > > Yes, this is a much better solution! Adding a seperate sysfs file page_size > and a file for the type of device which would read eeprom, fram, etc then. > If you also think this is the way to go, I would spent one of my next free > timeslots to this. Oops, this mail seems to have dropped off :( I am all for the 'page_size' attribute, but still not convinced what gain the 'type' attribute would allow. For FRAM, the page size will be large. Isn't this enough information? Regards, Wolfram -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] i2c: s3c2410: Add devm_* apis and cleanup
On Fri, Nov 23, 2012 at 02:11:51PM +0530, Tushar Behera wrote: > This patchset cleans up the probe function of i2c-s3c2410 driver. > These have been tested on Exynos4210 based Origen board. > > Changes since V1: > * devm_request_mem_region and devm_ioremap calls were replaced by > devm_request_and_ioremap() call. > * All devm_* related modifications (earlier patches 2-5) were merged > to a single patch. > Patch series looks good. Can you rebase to 3.8-rc4? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/2] sched: simplify the select_task_rq_fair()
On 01/24/2013 02:51 PM, Mike Galbraith wrote: > On Thu, 2013-01-24 at 14:01 +0800, Michael Wang wrote: > >> I've enabled WAKE flag on my box like you did, but still can't see >> regression, and I've just tested on a power server with 64 cpu, also >> failed to reproduce the issue (not compared with virgin yet, but can't >> see collapse). > > I'm not surprised. I'm seeing enough inconsistent crap to come to the > conclusion that stock scheduler knobs flat can't be used on a largish > box, they're just too preempt-happy, leading to weird crap. > > My 2 missing nodes came back, and the very same kernel that highly > repeatably collapsed with 2 nodes does not with 4 nodes, and 2 nodes > does not collapse with only preemption knob tweaking, and that's > bullshit. Virgin shows instability in the mid-range, make a tiny tweak > that should have little if any effect there, and that instability > vanishes entirely. Test runs are not consistent enough boot to boot etc > etc. Either stock knobs suck on NUMA boxen, or this box is possessed. Mike, I wonder the reason why change back to the old way make collapse away may not because there are logical error in new balance path, it's just changed the cost of select_task_rq(), whatever it's more or less, it's accidentally achieve the same effect as you tweak the knob, so that's the reason why it looks like old is better than new. Regards, Michael Wang > > -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/
[PATCH v2 3/3] mtd: add the new detection method for the unparsable nand chips
Add the new detection method find_nand_type_by_fullid() for the
unparsable nand chips. The new detection method is called firstly
before all the other detection methods.
Signed-off-by: Huang Shijie
---
drivers/mtd/nand/nand_base.c | 33 -
1 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 0e80ec4..7f0431d 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3152,6 +3152,29 @@ static void nand_decode_bbm_options(struct mtd_info *mtd,
chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
}
+static struct nand_flash_dev *find_nand_type_by_fullid(struct mtd_info *mtd,
+ struct nand_chip *chip, u8 *id_data, int *busw)
+{
+ struct nand_flash_dev *type = nand_flash_full_ids;
+
+ for (; type->name != NULL; type++) {
+ if (!strncmp(type->id, id_data, type->id_len)) {
+ mtd->writesize = type->pagesize;
+ mtd->erasesize = type->erasesize;
+ mtd->oobsize = type->oobsize;
+
+ chip->cellinfo = id_data[2];
+ chip->chipsize = (uint64_t)type->chipsize << 20;
+ chip->options |= type->options;
+
+ *busw = type->options & NAND_BUSWIDTH_16;
+
+ break;
+ }
+ }
+ return type;
+}
+
/*
* Get the flash and manufacturer id and lookup if the type is supported.
*/
@@ -3200,8 +3223,16 @@ static struct nand_flash_dev *nand_get_flash_type(struct
mtd_info *mtd,
return ERR_PTR(-ENODEV);
}
- if (!type)
+ if (!type) {
+ /*
+* Some nand chips's information can not be paresed out
+* from the id data. So, try your luck in the full-id table.
+*/
+ type = find_nand_type_by_fullid(mtd, chip, id_data, &busw);
+ if (type->name != NULL)
+ goto ident_done;
type = nand_flash_ids;
+ }
for (; type->name != NULL; type++)
if (*dev_id == type->id[1])
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] mtd: add a new table for the unparsable nand chips
We have 4 Toshiba nand chips which can not be parsed out by the
id data. Add a new table for the unparsable nand chips.
It makes mess if we add these entries to the nand_flash_ids table.
The entries in the nand_flash_ids stands for a class of nand chips.
But the unparsable nand chips are just some singular chips.
Signed-off-by: Huang Shijie
---
drivers/mtd/nand/nand_ids.c | 22 ++
include/linux/mtd/nand.h|1 +
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 9dc2e54..c1e32d2 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -11,6 +11,28 @@
#include
#include
#include
+#include
+
+/* This table uses the full ID data as the keyword. */
+struct nand_flash_dev nand_flash_full_ids[] = {
+ /* TOSHIBA */
+ {"TC58NVG2S0F 4G 3.3V 8-bit ",
+ {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08},
+ SZ_4K, SZ_512, SZ_256K, 0, 8, 224},
+ {"TC58NVG3S0F 8G 3.3V 8-bit ",
+ {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08},
+ SZ_4K, SZ_1K, SZ_256K, 0, 8, 232},
+ {"TC58NVG5D2 32G 3.3V 8-bit ",
+ {0x98, 0xd7, 0x94, 0x32, 0x76, 0x56, 0x09, 0x00},
+ SZ_8K, SZ_4K, SZ_1M, 0, 8, 640},
+ {"TC58NVG6D2 64G 3.3V 8-bit ",
+ {0x98, 0xde, 0x94, 0x82, 0x76, 0x56, 0x04, 0x20},
+ SZ_8K, SZ_8K, SZ_2M, 0, 8, 640},
+
+ /* end here */
+ {NULL,}
+};
+
/*
* Chip ID list
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 5293447..346a389 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -620,6 +620,7 @@ struct nand_manufacturers {
};
extern struct nand_flash_dev nand_flash_ids[];
+extern struct nand_flash_dev nand_flash_full_ids[];
extern struct nand_manufacturers nand_manuf_ids[];
extern int nand_scan_bbt(struct mtd_info *mtd, struct nand_bbt_descr *bd);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] mtd: add new fields to nand_flash_dev{}
As time goes on, we begin to meet the situation that we can not get enough
information from some nand chips's id data. Take some Toshiba's nand chips
for example. I have 4 Toshiba's nand chips in my hand:
TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2
When we read these chips' datasheets, we will get the geometry of these chips:
TC58NVG2S0F : 4096 + 224
TC58NVG3S0F : 4096 + 232
TC58NVG5D2 : 8192 + 640
TC58NVG6D2 : 8192 + 640
But we can not parse out the correct oob size for these chips from the id data.
So it is time to add some new fields to the nand_flash_dev{}, and update the
detection mechanisms.
This patch just adds some new fields to the nand_flash_dev{}.
Signed-off-by: Huang Shijie
---
drivers/mtd/devices/doc2000.c |2 +-
drivers/mtd/devices/doc2001.c |2 +-
drivers/mtd/devices/doc2001plus.c |2 +-
drivers/mtd/nand/nand_base.c |2 +-
drivers/mtd/nand/nand_ids.c | 176 +++--
drivers/mtd/nand/nandsim.c|2 +-
drivers/mtd/nand/pxa3xx_nand.c|2 +-
drivers/mtd/nand/sm_common.c | 61 ++---
include/linux/mtd/nand.h | 10 ++-
9 files changed, 133 insertions(+), 126 deletions(-)
diff --git a/drivers/mtd/devices/doc2000.c b/drivers/mtd/devices/doc2000.c
index a4eb8b5..93f037f 100644
--- a/drivers/mtd/devices/doc2000.c
+++ b/drivers/mtd/devices/doc2000.c
@@ -379,7 +379,7 @@ static int DoC_IdentChip(struct DiskOnChip *doc, int floor,
int chip)
/* Print and store the manufacturer and ID codes. */
for (i = 0; nand_flash_ids[i].name != NULL; i++) {
- if (id == nand_flash_ids[i].id) {
+ if (id == nand_flash_ids[i].id[1]) {
/* Try to identify manufacturer */
for (j = 0; nand_manuf_ids[j].id != 0x0; j++) {
if (nand_manuf_ids[j].id == mfr)
diff --git a/drivers/mtd/devices/doc2001.c b/drivers/mtd/devices/doc2001.c
index f692795..15dd177 100644
--- a/drivers/mtd/devices/doc2001.c
+++ b/drivers/mtd/devices/doc2001.c
@@ -206,7 +206,7 @@ static int DoC_IdentChip(struct DiskOnChip *doc, int floor,
int chip)
/* FIXME: to deal with multi-flash on multi-Millennium case more
carefully */
for (i = 0; nand_flash_ids[i].name != NULL; i++) {
- if ( id == nand_flash_ids[i].id) {
+ if (id == nand_flash_ids[i].id[1]) {
/* Try to identify manufacturer */
for (j = 0; nand_manuf_ids[j].id != 0x0; j++) {
if (nand_manuf_ids[j].id == mfr)
diff --git a/drivers/mtd/devices/doc2001plus.c
b/drivers/mtd/devices/doc2001plus.c
index 4f2220a..80aef1b 100644
--- a/drivers/mtd/devices/doc2001plus.c
+++ b/drivers/mtd/devices/doc2001plus.c
@@ -314,7 +314,7 @@ static int DoC_IdentChip(struct DiskOnChip *doc, int floor,
int chip)
return 0;
for (i = 0; nand_flash_ids[i].name != NULL; i++) {
- if (id == nand_flash_ids[i].id) {
+ if (id == nand_flash_ids[i].id[1]) {
/* Try to identify manufacturer */
for (j = 0; nand_manuf_ids[j].id != 0x0; j++) {
if (nand_manuf_ids[j].id == mfr)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index a8c1fb4..0e80ec4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3204,7 +3204,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct
mtd_info *mtd,
type = nand_flash_ids;
for (; type->name != NULL; type++)
- if (*dev_id == type->id)
+ if (*dev_id == type->id[1])
break;
chip->onfi_version = 0;
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index e3aa274..9dc2e54 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -10,6 +10,8 @@
*/
#include
#include
+#include
+
/*
* Chip ID list
*
@@ -24,47 +26,47 @@
struct nand_flash_dev nand_flash_ids[] = {
#ifdef CONFIG_MTD_NAND_MUSEUM_IDS
- {"NAND 1MiB 5V 8-bit", 0x6e, 256, 1, 0x1000, 0},
- {"NAND 2MiB 5V 8-bit", 0x64, 256, 2, 0x1000, 0},
- {"NAND 4MiB 5V 8-bit", 0x6b, 512, 4, 0x2000, 0},
- {"NAND 1MiB 3,3V 8-bit",0xe8, 256, 1, 0x1000, 0},
- {"NAND 1MiB 3,3V 8-bit",0xec, 256, 1, 0x1000, 0},
- {"NAND 2MiB 3,3V 8-bit",0xea, 256, 2, 0x1000, 0},
- {"NAND 4MiB 3,3V 8-bit",0xd5, 512, 4, 0x2000, 0},
- {"NAND 4MiB 3,3V 8-bit",0xe3, 512, 4, 0x2000, 0},
- {"NAND 4MiB 3,3V 8-bit",0xe5, 512, 4, 0x2000, 0},
- {"NAND 8MiB 3,3V 8-bit",0xd6, 512, 8, 0x2000, 0},
-
- {"NAND 8MiB 1,8V 8-bit",0x39, 512, 8, 0x2000, 0},
- {"NAND 8MiB 3,3V 8-bit",0xe6, 512, 8, 0x2000, 0},
- {"NAN
[PATCH v2 0/3] mtd: use the full-id as the keyword.
I ever submitted a patch to use the full-id as the keyword for some
unparsable nand chips. This is the second tries.
As time goes on, we begin to meet the situation that we can not get enough
information from some nand chips's id data. Take some Toshiba's nand chips
for example. I have 4 Toshiba's nand chips in my hand:
TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2
When we read these chips' datasheets, we will get the geometry of these chips:
TC58NVG2S0F : 4096 + 224
TC58NVG3S0F : 4096 + 232
TC58NVG5D2 : 8192 + 640
TC58NVG6D2 : 8192 + 640
But we can not parse out the correct oob size for these chips from the id data.
So it is time to add some new fields to the nand_flash_dev{}, and update the
detection mechanisms.
Huang Shijie (3):
mtd: add new fields to nand_flash_dev{}
mtd: add a new table for the unparsable nand chips
mtd: add the new detection method for the unparsable nand chips
drivers/mtd/devices/doc2000.c |2 +-
drivers/mtd/devices/doc2001.c |2 +-
drivers/mtd/devices/doc2001plus.c |2 +-
drivers/mtd/nand/nand_base.c | 35 ++-
drivers/mtd/nand/nand_ids.c | 198 +
drivers/mtd/nand/nandsim.c|2 +-
drivers/mtd/nand/pxa3xx_nand.c|2 +-
drivers/mtd/nand/sm_common.c | 61 ++--
include/linux/mtd/nand.h | 11 ++-
9 files changed, 188 insertions(+), 127 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: [RFC PATCH 0/2] sched: simplify the select_task_rq_fair()
On 01/24/2013 02:01 PM, Michael Wang wrote: > On 01/23/2013 05:32 PM, Mike Galbraith wrote: > [snip] >> --- >> include/linux/topology.h |6 ++--- >> kernel/sched/core.c | 41 ++--- >> kernel/sched/fair.c | 52 >> +-- >> 3 files changed, 70 insertions(+), 29 deletions(-) >> >> --- a/include/linux/topology.h >> +++ b/include/linux/topology.h >> @@ -95,7 +95,7 @@ int arch_update_cpu_topology(void); >> | 1*SD_BALANCE_NEWIDLE \ >> | 1*SD_BALANCE_EXEC \ >> | 1*SD_BALANCE_FORK \ >> -| 0*SD_BALANCE_WAKE \ >> +| 1*SD_BALANCE_WAKE \ >> | 1*SD_WAKE_AFFINE \ >> | 1*SD_SHARE_CPUPOWER \ >> | 1*SD_SHARE_PKG_RESOURCES \ >> @@ -126,7 +126,7 @@ int arch_update_cpu_topology(void); >> | 1*SD_BALANCE_NEWIDLE \ >> | 1*SD_BALANCE_EXEC \ >> | 1*SD_BALANCE_FORK \ >> -| 0*SD_BALANCE_WAKE \ >> +| 1*SD_BALANCE_WAKE \ >> | 1*SD_WAKE_AFFINE \ >> | 0*SD_SHARE_CPUPOWER \ >> | 1*SD_SHARE_PKG_RESOURCES \ >> @@ -156,7 +156,7 @@ int arch_update_cpu_topology(void); >> | 1*SD_BALANCE_NEWIDLE \ >> | 1*SD_BALANCE_EXEC \ >> | 1*SD_BALANCE_FORK \ >> -| 0*SD_BALANCE_WAKE \ >> +| 1*SD_BALANCE_WAKE \ >> | 1*SD_WAKE_AFFINE \ >> | 0*SD_SHARE_CPUPOWER \ >> | 0*SD_SHARE_PKG_RESOURCES \ > > I've enabled WAKE flag on my box like you did, but still can't see > regression, and I've just tested on a power server with 64 cpu, also > failed to reproduce the issue (not compared with virgin yet, but can't > see collapse). > > I will do more testing on the power box to confirm it. I still can't reproduce the issue, but there are some difference according to my default sd topology: WYT: sbm of cpu 0 WYT: exec map WYT: sd f051be80, idx 0, level 0, weight 4 WYT: sd f08b3700, idx 1, level 1, weight 32 WYT: sd f08b3700, idx 2, level 1, weight 32 WYT: fork map WYT: sd f051be80, idx 0, level 0, weight 4 WYT: sd f08b3700, idx 1, level 1, weight 32 WYT: sd f08b3700, idx 2, level 1, weight 32 WYT: wake map WYT: sd f051be80, idx 0, level 0, weight 4 WYT: sd f08b3700, idx 1, level 1, weight 32 WYT: sd f08b6300, idx 2, level 2, weight 64 WYT: affine map WYT: affine with cpu 0 in sd f051be80, weight 4 WYT: affine with cpu 1 in sd f051be80, weight 4 WYT: affine with cpu 2 in sd f051be80, weight 4 WYT: affine with cpu 3 in sd f051be80, weight 4 ... And there are only sibling, cpu and numa level, no mc level while your box have, but that looks harmless to me... isn't it? This is the aim 7 results of the patched kernel, it's just fine. Tasksjobs/min jti jobs/min/task real cpu 1 424.07 100 424.0728 14.29 4.29 Thu Jan 24 01:52:22 2013 5 2561.28 99 512.2570 11.83 8.82 Thu Jan 24 01:52:35 2013 10 5033.22 97 503.3223 12.04 16.35 Thu Jan 24 01:52:47 2013 2010350.13 98 517.5064 11.71 28.54 Thu Jan 24 01:52:59 2013 4020116.18 98 502.9046 12.05 62.06 Thu Jan 24 01:53:11 2013 8039255.06 98 490.6883 12.35122.18 Thu Jan 24 01:53:24 2013 16069405.87 97 433.7867 13.97234.41 Thu Jan 24 01:53:38 2013 320 92.66 92 347.4771 17.44463.18 Thu Jan 24 01:53:56 2013 640 158044.01 86 246.9438 24.54920.38 Thu Jan 24 01:54:20 2013 1280 199763.07 87 156.0649 38.83 1833.75 Thu Jan 24 01:54:59 2013 2560 229933.30 8189.8177 67.47 3665.30 Thu Jan 24 01:56:07 2013 And this is my cpu info: processor : 63 cpu : POWER7 (raw), altivec supported clock : 8.388608MHz revision: 2.3 (pvr 003f 0203) Regards,
[PATCH] fbcon: don't lose the console font across generic->chip driver switch
From: Dave Airlie
If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however when we then load the native KMS
driver, the first thing it does is tear down the generic framebuffer driver.
The thing is the generic code is doing the right thing, it frees the font
because otherwise it would leak memory. However we can assume that if you
are removing the generic firmware driver (vesa/efi/offb), that a new driver
*should* be loading soon after, so we effectively leak the font.
However the old code left a dangling pointer in vc->vc_font.data and we
can now reuse that dangling pointer to load the font into the new
driver, now that we aren't freeing it.
I'm open for better suggestions on this, but this does work in my brief
test here.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340
Cc: Kay Sievers
Signed-off-by: Dave Airlie
---
drivers/video/console/fbcon.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index fdefa8f..f8dbe76 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -990,7 +990,7 @@ static const char *fbcon_startup(void)
}
/* Setup default font */
- if (!p->fontdata) {
+ if (!p->fontdata && !vc->vc_font.data) {
if (!fontname[0] || !(font = find_font(fontname)))
font = get_default_font(info->var.xres,
info->var.yres,
@@ -1000,6 +1000,8 @@ static const char *fbcon_startup(void)
vc->vc_font.height = font->height;
vc->vc_font.data = (void *)(p->fontdata = font->data);
vc->vc_font.charcount = 256; /* FIXME Need to support more
fonts */
+ } else {
+ p->fontdata = vc->vc_font.data;
}
cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres);
@@ -1159,9 +1161,9 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->p = &fb_display[fg_console];
}
-static void fbcon_free_font(struct display *p)
+static void fbcon_free_font(struct display *p, bool freefont)
{
- if (p->userfont && p->fontdata && (--REFCOUNT(p->fontdata) == 0))
+ if (freefont && p->userfont && p->fontdata && (--REFCOUNT(p->fontdata)
== 0))
kfree(p->fontdata - FONT_EXTRA_WORDS * sizeof(int));
p->fontdata = NULL;
p->userfont = 0;
@@ -1173,8 +1175,8 @@ static void fbcon_deinit(struct vc_data *vc)
struct fb_info *info;
struct fbcon_ops *ops;
int idx;
+ bool free_font = true;
- fbcon_free_font(p);
idx = con2fb_map[vc->vc_num];
if (idx == -1)
@@ -1185,6 +1187,8 @@ static void fbcon_deinit(struct vc_data *vc)
if (!info)
goto finished;
+ if (info->flags & FBINFO_MISC_FIRMWARE)
+ free_font = false;
ops = info->fbcon_par;
if (!ops)
@@ -1196,6 +1200,8 @@ static void fbcon_deinit(struct vc_data *vc)
ops->flags &= ~FBCON_FLAGS_INIT;
finished:
+ fbcon_free_font(p, free_font);
+
if (!con_is_bound(&fb_con))
fbcon_exit();
--
1.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mtd: devices: elm: Removes literals in elm DT node
As part of removing generalized dependency, replace literal fields
in DT compatible field with <52> for am335x platforms.
Signed-off-by: Philip Avinash
---
Documentation/devicetree/bindings/mtd/elm.txt |2 +-
drivers/mtd/devices/elm.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/elm.txt
b/Documentation/devicetree/bindings/mtd/elm.txt
index e43c668..8c1528c 100644
--- a/Documentation/devicetree/bindings/mtd/elm.txt
+++ b/Documentation/devicetree/bindings/mtd/elm.txt
@@ -10,7 +10,7 @@ Optional properties:
Example:
elm: elm@0 {
- compatible = "ti,am33xx-elm";
+ compatible = "ti,am3352-elm";
reg = <0x4808 0x2000>;
interrupts = <4>;
};
diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index f78f43f..f034239 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -381,7 +381,7 @@ static int elm_remove(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id elm_of_match[] = {
- { .compatible = "ti,am33xx-elm" },
+ { .compatible = "ti,am3352-elm" },
{},
};
MODULE_DEVICE_TABLE(of, elm_of_match);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/2] sched: simplify the select_task_rq_fair()
On Thu, 2013-01-24 at 14:01 +0800, Michael Wang wrote: > I've enabled WAKE flag on my box like you did, but still can't see > regression, and I've just tested on a power server with 64 cpu, also > failed to reproduce the issue (not compared with virgin yet, but can't > see collapse). I'm not surprised. I'm seeing enough inconsistent crap to come to the conclusion that stock scheduler knobs flat can't be used on a largish box, they're just too preempt-happy, leading to weird crap. My 2 missing nodes came back, and the very same kernel that highly repeatably collapsed with 2 nodes does not with 4 nodes, and 2 nodes does not collapse with only preemption knob tweaking, and that's bullshit. Virgin shows instability in the mid-range, make a tiny tweak that should have little if any effect there, and that instability vanishes entirely. Test runs are not consistent enough boot to boot etc etc. Either stock knobs suck on NUMA boxen, or this box is possessed. -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/
[PATCHv2] crypto: caam - Added property fsl,sec-era in SEC4.0 device tree binding.
This new property defines the era of the particular SEC version.
The compatible property in device tree "crypto" node has been updated
not to contain SEC era numbers.
Signed-off-by: Vakul Garg
---
Changes in v1:
1. Marked fsl,sec-era as 'optional'.
Changes in v2:
1. Changed 'fsl,sec-era' in example from hex to decimal.
.../devicetree/bindings/crypto/fsl-sec4.txt| 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index fc9ce6f..dc40055 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -54,8 +54,13 @@ PROPERTIES
- compatible
Usage: required
Value type:
- Definition: Must include "fsl,sec-v4.0". Also includes SEC
- ERA versions (optional) with which the device is compatible.
+ Definition: Must include "fsl,sec-v4.0"
+
+ - fsl,sec-era
+ Usage: optional
+ Value type:
+ Definition: A standard property. Define the 'ERA' of the SEC
+ device.
- #address-cells
Usage: required
@@ -107,7 +112,8 @@ PROPERTIES
EXAMPLE
crypto@30 {
- compatible = "fsl,sec-v4.0", "fsl,sec-era-v2.0";
+ compatible = "fsl,sec-v4.0";
+ fsl,sec-era = <2>;
#address-cells = <1>;
#size-cells = <1>;
reg = <0x30 0x1>;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] cgroup: remove a NULL check in cgroup_exit()
init_task.cgroups is initialized at boot phase, and whenver a ask is forked, it's cgroups pointer is inherited from its parent, and it's never set to NULL afterwards. Signed-off-by: Li Zefan --- kernel/cgroup.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 09c5869..5d4c92e 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -5011,8 +5011,7 @@ void cgroup_exit(struct task_struct *tsk, int run_callbacks) } task_unlock(tsk); - if (cg) - put_css_set_taskexit(cg); + put_css_set_taskexit(cg); } /** -- 1.8.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] cgroup: fix exit() vsrmdir() race
In cgroup_exit() put_css_set_taskexit() is called without any lock,
which might lead to accessing a freed cgroup:
thread1 thread2
-
exit()
cgroup_exit()
put_css_set_taskexit()
atomic_dec(cgrp->count);
rmdir();
/* not safe !! */
check_for_release(cgrp);
rcu_read_lock() can be used to make sure the cgroup is alive.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 368cff1..09c5869 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -422,12 +422,20 @@ static void __put_css_set(struct css_set *cg, int
taskexit)
struct cgroup *cgrp = link->cgrp;
list_del(&link->cg_link_list);
list_del(&link->cgrp_link_list);
+
+ /*
+* We may not be holding cgroup_mutex, and if cgrp->count is
+* dropped to 0 the cgroup can be destroyed at any time, hence
+* rcu_read_lock is used to keep it alive.
+*/
+ rcu_read_lock();
if (atomic_dec_and_test(&cgrp->count) &&
notify_on_release(cgrp)) {
if (taskexit)
set_bit(CGRP_RELEASABLE, &cgrp->flags);
check_for_release(cgrp);
}
+ rcu_read_unlock();
kfree(link);
}
--
1.8.0.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: [v3 2/2] ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9
Stephen Warren wrote @ Thu, 24 Jan 2013 06:04:55 +0100: > Branch scu-base-rework contains just the SCU base address patches. After > the few things listed below, I'll rename this branch and send a pull > request to arm-soc. > > 2) Lorenzo's last comment on "ARM: tegra: Use DT /cpu node to detect > number of CPU core" was: > > Please add missing punctuation, reword the commit log to make it clearer. > > ... so that patch needs a reworded commit log. I fixed. I'll send this[1] as a part of the "Tegra114 series(v4)" today. [1] ARM: tegra: Use DT /cpu node to detect number of CPU core -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/6] cgroup: remove bogus comments in cgroup_diput()
Since commit 48ddbe194623ae089cc0576e60363f2d2e85662a
("cgroup: make css->refcnt clearing on cgroup removal optional"),
each css holds a ref on cgroup's dentry, so cgroup_diput() won't be
called until all css' refs go down to 0, which invalids the comments.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index f18b0d9..368cff1 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -899,12 +899,6 @@ static void cgroup_diput(struct dentry *dentry, struct
inode *inode)
struct cgroup *cgrp = dentry->d_fsdata;
BUG_ON(!(cgroup_is_removed(cgrp)));
- /* It's possible for external users to be holding css
-* reference counts on a cgroup; css_put() needs to
-* be able to access the cgroup after decrementing
-* the reference count in order to know if it needs to
-* queue the cgroup to be handled by the release
-* agent */
call_rcu(&cgrp->rcu_head, cgroup_free_rcu);
} else {
struct cfent *cfe = __d_cfe(dentry);
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/6] cgroup: remove synchronize_rcu() from cgroup_diput()
Free cgroup via call_rcu(). The actual work is done through
workqueue.
Signed-off-by: Li Zefan
---
v2: move INIT_WORK() from cgroup_create() to init_cgroup_housekeeping()
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 72 ++
2 files changed, 44 insertions(+), 29 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 8118a31..900af59 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -203,6 +203,7 @@ struct cgroup {
/* For RCU-protected deletion */
struct rcu_head rcu_head;
+ struct work_struct free_work;
/* List of events which userspace want to receive */
struct list_head event_list;
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index a39e2b0..f18b0d9 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -852,12 +852,52 @@ static struct inode *cgroup_new_inode(umode_t mode,
struct super_block *sb)
return inode;
}
+static void cgroup_free_fn(struct work_struct *work)
+{
+ struct cgroup *cgrp = container_of(work, struct cgroup, free_work);
+ struct cgroup_subsys *ss;
+
+ mutex_lock(&cgroup_mutex);
+ /*
+* Release the subsystem state objects.
+*/
+ for_each_subsys(cgrp->root, ss)
+ ss->css_free(cgrp);
+
+ cgrp->root->number_of_cgroups--;
+ mutex_unlock(&cgroup_mutex);
+
+ /*
+* Drop the active superblock reference that we took when we
+* created the cgroup
+*/
+ deactivate_super(cgrp->root->sb);
+
+ /*
+* if we're getting rid of the cgroup, refcount should ensure
+* that there are no pidlists left.
+*/
+ BUG_ON(!list_empty(&cgrp->pidlists));
+
+ simple_xattrs_free(&cgrp->xattrs);
+
+ ida_simple_remove(&cgrp->root->cgroup_ida, cgrp->id);
+ kfree(cgrp);
+}
+
+static void cgroup_free_rcu(struct rcu_head *head)
+{
+ struct cgroup *cgrp = container_of(head, struct cgroup, rcu_head);
+
+ schedule_work(&cgrp->free_work);
+}
+
static void cgroup_diput(struct dentry *dentry, struct inode *inode)
{
/* is dentry a directory ? if so, kfree() associated cgroup */
if (S_ISDIR(inode->i_mode)) {
struct cgroup *cgrp = dentry->d_fsdata;
- struct cgroup_subsys *ss;
+
BUG_ON(!(cgroup_is_removed(cgrp)));
/* It's possible for external users to be holding css
* reference counts on a cgroup; css_put() needs to
@@ -865,34 +905,7 @@ static void cgroup_diput(struct dentry *dentry, struct
inode *inode)
* the reference count in order to know if it needs to
* queue the cgroup to be handled by the release
* agent */
- synchronize_rcu();
-
- mutex_lock(&cgroup_mutex);
- /*
-* Release the subsystem state objects.
-*/
- for_each_subsys(cgrp->root, ss)
- ss->css_free(cgrp);
-
- cgrp->root->number_of_cgroups--;
- mutex_unlock(&cgroup_mutex);
-
- /*
-* Drop the active superblock reference that we took when we
-* created the cgroup
-*/
- deactivate_super(cgrp->root->sb);
-
- /*
-* if we're getting rid of the cgroup, refcount should ensure
-* that there are no pidlists left.
-*/
- BUG_ON(!list_empty(&cgrp->pidlists));
-
- simple_xattrs_free(&cgrp->xattrs);
-
- ida_simple_remove(&cgrp->root->cgroup_ida, cgrp->id);
- kfree(cgrp);
+ call_rcu(&cgrp->rcu_head, cgroup_free_rcu);
} else {
struct cfent *cfe = __d_cfe(dentry);
struct cgroup *cgrp = dentry->d_parent->d_fsdata;
@@ -1391,6 +1404,7 @@ static void init_cgroup_housekeeping(struct cgroup *cgrp)
INIT_LIST_HEAD(&cgrp->allcg_node);
INIT_LIST_HEAD(&cgrp->release_list);
INIT_LIST_HEAD(&cgrp->pidlists);
+ INIT_WORK(&cgrp->free_work, cgroup_free_fn);
mutex_init(&cgrp->pidlist_mutex);
INIT_LIST_HEAD(&cgrp->event_list);
spin_lock_init(&cgrp->event_list_lock);
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/6] cgroup: remove duplicate RCU free on struct cgroup
When destroying a cgroup, though in cgroup_diput() we've called
synchronize_rcu(), we then still have to free it via call_rcu().
The story is, long ago to fix a race between reading /proc/sched_debug
and freeing cgroup, the code was changed to utilize call_rcu(). See
commit a47295e6bc42ad35f9c15ac66f598aa24debd4e2 ("cgroups: make
cgroup_path() RCU-safe")
As we've fixed cpu cgroup that cpu_cgroup_offline_css() is used
to unregister a task_group so there won't be concurrent access
to this task_group after synchronize_rcu() in diput(). Now we can
just kfree(cgrp).
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index b9a76e2..a39e2b0 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -892,7 +892,7 @@ static void cgroup_diput(struct dentry *dentry, struct
inode *inode)
simple_xattrs_free(&cgrp->xattrs);
ida_simple_remove(&cgrp->root->cgroup_ida, cgrp->id);
- kfree_rcu(cgrp, rcu_head);
+ kfree(cgrp);
} else {
struct cfent *cfe = __d_cfe(dentry);
struct cgroup *cgrp = dentry->d_parent->d_fsdata;
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/6] sched: remove redundant NULL cgroup check in task_group_path()
A task_group won't be online (thus no one can see it) until
cpu_cgroup_css_online(), and at that time tg->css.cgroup has
been initialized, so this NULL check is redundant.
Signed-off-by: Li Zefan
---
kernel/sched/debug.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 2cd3c1b..38df0db 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -110,13 +110,6 @@ static char *task_group_path(struct task_group *tg)
if (autogroup_path(tg, group_path, PATH_MAX))
return group_path;
- /*
-* May be NULL if the underlying cgroup isn't fully-created yet
-*/
- if (!tg->css.cgroup) {
- group_path[0] = '\0';
- return group_path;
- }
cgroup_path(tg->css.cgroup, group_path, PATH_MAX);
return group_path;
}
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/6] sched: split out css_online/css_offline from tg creation/destruction
This is a preparaton for later patches.
- What do we gain from cpu_cgroup_css_online():
After ss->css_alloc() and before ss->css_online(), there's a small
window that tg->css.cgroup is NULL. With this change, tg won't be seen
before ss->css_online(), where it's added to the global list, so we're
guaranteed we'll never see NULL tg->css.cgroup.
- What do we gain from cpu_cgroup_css_offline():
tg is freed via RCU, so is cgroup. Without this change, This is how
synchronization works:
cgroup_rmdir()
no ss->css_offline()
diput()
syncornize_rcu()
ss->css_free() <-- unregister tg, and free it via call_rcu()
kfree_rcu(cgroup)<-- wait possible refs to cgroup, and free cgroup
We can't just kfree(cgroup), because tg might access tg->css.cgroup.
With this change:
cgroup_rmdir()
ss->css_offline()<-- unregister tg
diput()
synchronize_rcu()<-- wait possible refs to tg and cgroup
ss->css_free() <-- free tg
kfree_rcu(cgroup)<-- free cgroup
As you see, kfree_rcu() is redundant now.
Signed-off-by: Li Zefan
---
v2: changelog rephrased
---
include/linux/sched.h | 3 +++
kernel/sched/auto_group.c | 3 +++
kernel/sched/core.c | 49 +--
3 files changed, 45 insertions(+), 10 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 206bb08..577eb97 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2750,7 +2750,10 @@ extern void normalize_rt_tasks(void);
extern struct task_group root_task_group;
extern struct task_group *sched_create_group(struct task_group *parent);
+extern void sched_online_group(struct task_group *tg,
+ struct task_group *parent);
extern void sched_destroy_group(struct task_group *tg);
+extern void sched_offline_group(struct task_group *tg);
extern void sched_move_task(struct task_struct *tsk);
#ifdef CONFIG_FAIR_GROUP_SCHED
extern int sched_group_set_shares(struct task_group *tg, unsigned long shares);
diff --git a/kernel/sched/auto_group.c b/kernel/sched/auto_group.c
index 0984a21..64de5f8 100644
--- a/kernel/sched/auto_group.c
+++ b/kernel/sched/auto_group.c
@@ -35,6 +35,7 @@ static inline void autogroup_destroy(struct kref *kref)
ag->tg->rt_se = NULL;
ag->tg->rt_rq = NULL;
#endif
+ sched_offline_group(ag->tg);
sched_destroy_group(ag->tg);
}
@@ -76,6 +77,8 @@ static inline struct autogroup *autogroup_create(void)
if (IS_ERR(tg))
goto out_free;
+ sched_online_group(tg, &root_task_group);
+
kref_init(&ag->kref);
init_rwsem(&ag->lock);
ag->id = atomic_inc_return(&autogroup_seq_nr);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 257002c..1061672 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7159,7 +7159,6 @@ static void free_sched_group(struct task_group *tg)
struct task_group *sched_create_group(struct task_group *parent)
{
struct task_group *tg;
- unsigned long flags;
tg = kzalloc(sizeof(*tg), GFP_KERNEL);
if (!tg)
@@ -7171,6 +7170,17 @@ struct task_group *sched_create_group(struct task_group
*parent)
if (!alloc_rt_sched_group(tg, parent))
goto err;
+ return tg;
+
+err:
+ free_sched_group(tg);
+ return ERR_PTR(-ENOMEM);
+}
+
+void sched_online_group(struct task_group *tg, struct task_group *parent)
+{
+ unsigned long flags;
+
spin_lock_irqsave(&task_group_lock, flags);
list_add_rcu(&tg->list, &task_groups);
@@ -7180,12 +7190,6 @@ struct task_group *sched_create_group(struct task_group
*parent)
INIT_LIST_HEAD(&tg->children);
list_add_rcu(&tg->siblings, &parent->children);
spin_unlock_irqrestore(&task_group_lock, flags);
-
- return tg;
-
-err:
- free_sched_group(tg);
- return ERR_PTR(-ENOMEM);
}
/* rcu callback to free various structures associated with a task group */
@@ -7198,6 +7202,12 @@ static void free_sched_group_rcu(struct rcu_head *rhp)
/* Destroy runqueue etc associated with a task group */
void sched_destroy_group(struct task_group *tg)
{
+ /* wait for possible concurrent references to cfs_rqs complete */
+ call_rcu(&tg->rcu, free_sched_group_rcu);
+}
+
+void sched_offline_group(struct task_group *tg)
+{
unsigned long flags;
int i;
@@ -7209,9 +7219,6 @@ void sched_destroy_group(struct task_group *tg)
list_del_rcu(&tg->list);
list_del_rcu(&tg->siblings);
spin_unlock_irqrestore(&task_group_lock, flags);
-
- /* wait for possible concurrent references to cfs_rqs complete */
- call_rcu(&tg->rcu, free_sched_group_rcu);
}
/* change task's runqueue when it moves between groups.
@@ -7563,6 +7570,19 @@ static struct cgroup_subsys_state
*cpu_cgroup_css_alloc(struct cgroup *cgrp)
return &tg->css;
}
+static int cpu_cgroup_css_online(struct cgroup *cgrp)
+{
+ struct task_group
[PATCH v2 1/6] cgroup: initialize cgrp->dentry before css_alloc()
With this change, we're guaranteed that cgroup_path() won't see NULL
cgrp->dentry, and thus we can remove the NULL check in it.
(Well, it's not true, because dummptop.dentry is always NULL)
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ad3359f..b9a76e2 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1767,7 +1767,7 @@ int cgroup_path(const struct cgroup *cgrp, char *buf, int
buflen)
rcu_lockdep_assert(rcu_read_lock_held() || cgroup_lock_is_held(),
"cgroup_path() called without proper locking");
- if (!dentry || cgrp == dummytop) {
+ if (cgrp == dummytop) {
/*
* Inactive subsystems have no dentry for their root
* cgroup
@@ -4153,6 +4153,9 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
init_cgroup_housekeeping(cgrp);
+ dentry->d_fsdata = cgrp;
+ cgrp->dentry = dentry;
+
cgrp->parent = parent;
cgrp->root = parent->root;
cgrp->top_cgroup = parent->top_cgroup;
@@ -4190,8 +4193,6 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
lockdep_assert_held(&dentry->d_inode->i_mutex);
/* allocation complete, commit to creation */
- dentry->d_fsdata = cgrp;
- cgrp->dentry = dentry;
list_add_tail(&cgrp->allcg_node, &root->allcg_list);
list_add_tail_rcu(&cgrp->sibling, &cgrp->parent->children);
root->number_of_cgroups++;
--
1.8.0.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/
linux-next: New trees - ipsec and ipsec-next
Hello Stephen, could you please add the ipsec and ipsec-next tree to linux-next? The ipsec tree is intended to cover fixes for the ipsec networking subsystem and the ipsec-next tree to cover changes for ipsec with linux-next as target. The trees are located at: git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git master git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git master The ipsec tree follows David Miller's net tree, the ipsec-next tree follows the net-next tree. So they should be merged after net and net-next. Both trees were pulled recently, so they are currently empty. 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/
linux-next: Tree for Jan 24
Hi all, Changes since 20130123: The powerpc tree still had a build failure. The net-next tree gained a conflict against the mips tree. The sound-asoc tree still had its build failure so I used the version from next-20130122. The leds tree lost its build failure. The akpm tree gained a build failure for which I reverted a commit. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 211 trees (counting Linus' and 28 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (248152b Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k) Merging fixes/master (d287b87 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) Merging arm-current/fixes (210b184 Merge branch 'for-rmk/virt/hyp-boot/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into fixes) Merging m68k-current/for-linus (e7e29b4 m68k: Wire up finit_module) Merging powerpc-merge/merge (e6449c9 powerpc: Add missing NULL terminator to avoid boot panic on PPC40x) Merging sparc/master (04cef49 sparc: kernel/sbus.c: fix memory leakage) Merging net/master (5d0feaf r8169: remove the obsolete and incorrect AMD workaround) Merging sound-current/for-linus (0712eea ALSA: hda - Add a fixup for Packard-Bell desktop with ALC880) Merging pci-current/for-linus (444ee9b PCI: remove depends on CONFIG_EXPERIMENTAL) Merging wireless/master (83f0c6d mwifiex: fix typo in PCIe adapter NULL check) Merging driver-core.current/driver-core-linus (7d1f9ae Linux 3.8-rc4) Merging tty.current/tty-linus (ebebd49 8250/16?50: Add support for Broadcom TruManage redirected serial port) Merging usb.current/usb-linus (dba63b2 USB: EHCI: fix build error in ehci-mxc) Merging staging.current/staging-linus (7dfc833 staging/sb105x: PARPORT config is not good enough must use PARPORT_PC) Merging char-misc.current/char-misc-linus (a7e2ca1 Revert "drivers/misc/ti-st: remove gpio handling") Merging input-current/for-linus (b666263 Input: document that unregistering managed devices is not necessary) Merging md-current/for-linus (a9add5d md/raid5: add blktrace calls) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (a2c0911 crypto: caam - Updated SEC-4.0 device tree binding for ERA information.) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (084a0ec x86: add CONFIG_X86_MOVBE option) CONFLICT (content): Merge conflict in arch/x86/Kconfig Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6) Merging devicetree-current/devicetree/merge (ab28698 of: define struct device in of_platform.h if !OF_DEVICE and !OF_ADDRESS) Merging spi-current/spi/merge (d3601e5 spi/sh-hspi: fix return value check in hspi_probe().) Merging gpio-current/gpio/merge (bc10
Re: [PATCH 2/3] tegra: pwm-backlight: add tegra pwm-bl driver
On Wednesday 23 January 2013 17:45:39 Alex Courbot wrote:
> > I'm confused. Why would you want to call into pwm_bl directly? If we're
> > going to split this up into separate platform devices, why not look up a
> > given backlight device and use the backlight API on that? The pieces of
> > the puzzle are all there: you can use of_find_backlight_by_node() to
> > obtain a backlight device from a device tree node, so I'd expect the DT
> > to look something like this:
> > backlight: backlight {
> >
> > compatible = "pwm-backlight";
> > ...
> >
> > };
>
> This would still prevent any power control from the backlight driver. I.e.
> if someone sets the brightness to 0 through sysfs, we cannot power the
> backlight off as pwm-backlight cannot control more than the PWM without
> platform callbacks. Backlight could only be powered off as a result of a fb
> blank event.
In order to solve this, how about adding a backlight notifier call chain to
broadcast backlight events in a fashion similar to what is done in
fbmem/fbcon? Then backlight_update_status() could send events like
BACKLIGHT_EARLY_EVENT_UPDATE and BACKLIGHT_EVENT_UPDATE to which panel drivers
could subscribe in order to power the backlight up and down as needed.
Then as the backlight is mentioned in the panel's DT node,
> panel: panel {
> compatible = "...";
> ...
> backlight = <&backlight>;
> ...
> };
the panel's driver could listen to backlight-related events and do its stuff
transparently, without changing anything to the backlight drivers. This would
be a good way to replace pwm-backlight's callbacks for platforms that use the
DT, and would also be applicable to any backlight class device.
Generally speaking, having a mean to monitor backlights state in the kernel
does not seem too crazy, especially since we already have a way to notify user
space through backlight_generate_event().
Richard, does that sound ok to you?
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/2] sched: simplify the select_task_rq_fair()
On 01/23/2013 05:32 PM, Mike Galbraith wrote:
[snip]
> ---
> include/linux/topology.h |6 ++---
> kernel/sched/core.c | 41 ++---
> kernel/sched/fair.c | 52
> +--
> 3 files changed, 70 insertions(+), 29 deletions(-)
>
> --- a/include/linux/topology.h
> +++ b/include/linux/topology.h
> @@ -95,7 +95,7 @@ int arch_update_cpu_topology(void);
> | 1*SD_BALANCE_NEWIDLE \
> | 1*SD_BALANCE_EXEC \
> | 1*SD_BALANCE_FORK \
> - | 0*SD_BALANCE_WAKE \
> + | 1*SD_BALANCE_WAKE \
> | 1*SD_WAKE_AFFINE \
> | 1*SD_SHARE_CPUPOWER \
> | 1*SD_SHARE_PKG_RESOURCES \
> @@ -126,7 +126,7 @@ int arch_update_cpu_topology(void);
> | 1*SD_BALANCE_NEWIDLE \
> | 1*SD_BALANCE_EXEC \
> | 1*SD_BALANCE_FORK \
> - | 0*SD_BALANCE_WAKE \
> + | 1*SD_BALANCE_WAKE \
> | 1*SD_WAKE_AFFINE \
> | 0*SD_SHARE_CPUPOWER \
> | 1*SD_SHARE_PKG_RESOURCES \
> @@ -156,7 +156,7 @@ int arch_update_cpu_topology(void);
> | 1*SD_BALANCE_NEWIDLE \
> | 1*SD_BALANCE_EXEC \
> | 1*SD_BALANCE_FORK \
> - | 0*SD_BALANCE_WAKE \
> + | 1*SD_BALANCE_WAKE \
> | 1*SD_WAKE_AFFINE \
> | 0*SD_SHARE_CPUPOWER \
> | 0*SD_SHARE_PKG_RESOURCES \
I've enabled WAKE flag on my box like you did, but still can't see
regression, and I've just tested on a power server with 64 cpu, also
failed to reproduce the issue (not compared with virgin yet, but can't
see collapse).
I will do more testing on the power box to confirm it.
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5609,11 +5609,39 @@ static void update_top_cache_domain(int
> static int sbm_max_level;
> DEFINE_PER_CPU_SHARED_ALIGNED(struct sched_balance_map, sbm_array);
>
> +static void debug_sched_balance_map(int cpu)
> +{
> + int i, type, level = 0;
> + struct sched_balance_map *sbm = &per_cpu(sbm_array, cpu);
> +
> + printk("WYT: sbm of cpu %d\n", cpu);
> +
> + for (type = 0; type < SBM_MAX_TYPE; type++) {
> + if (type == SBM_EXEC_TYPE)
> + printk("WYT: \t exec map\n");
> + else if (type == SBM_FORK_TYPE)
> + printk("WYT: \t fork map\n");
> + else if (type == SBM_WAKE_TYPE)
> + printk("WYT: \t wake map\n");
> +
> + for (level = 0; level < sbm_max_level; level++) {
> + if (sbm->sd[type][level])
> + printk("WYT: \t\t sd %x, idx %d, level %d,
> weight %d\n", sbm->sd[type][level], level, sbm->sd[type][level]->level,
> sbm->sd[type][level]->span_weight);
> + }
> + }
> +
> + printk("WYT: \t affine map\n");
> +
> + for_each_possible_cpu(i) {
> + if (sbm->affine_map[i])
> + printk("WYT: \t\t affine with cpu %x in sd %x, weight
> %d\n", i, sbm->affine_map[i], sbm->affine_map[i]->span_weight);
> + }
> +}
> +
> static void build_sched_balance_map(int cpu)
> {
> struct sched_balance_map *sbm = &per_cpu(sbm_array, cpu);
> struct sched_domain *sd = cpu_rq(cpu)->sd;
> - struct sched_domain *top_sd = NULL;
> int i, type, level = 0;
>
> memset(sbm->top_level, 0, sizeof((*sbm).top_level));
> @@ -5656,11 +5684,9 @@ static void build_sched_balance_map(int
>* fill the hole to get lower level sd easily.
>*/
> for (type = 0; type < SBM_MAX_TYPE; type++) {
> - level = sbm->top_level[type];
> - top_sd = sbm->sd[type][level];
> - if ((++level != sbm_max_level) && top_sd) {
> - for (; level < sbm_max_level; level++)
> - sbm->sd[type][level] = top_sd;
> + for (level = 1; level < sbm_max_level; level++) {
> + if (!sbm->sd[type][level])
> + sbm->sd[type][level] = sbm->sd[type][level - 1];
>
Re: [v3 2/2] ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9
Stephen, On Thursday 24 January 2013 10:34 AM, Stephen Warren wrote: On 01/23/2013 01:58 AM, Santosh Shilimkar wrote: On Tuesday 22 January 2013 10:34 PM, Olof Johansson wrote: On Tue, Jan 22, 2013 at 8:57 AM, Stephen Warren wrote: On 01/21/2013 11:07 PM, Santosh Shilimkar wrote: On Tuesday 22 January 2013 11:22 AM, Hiroshi Doyu wrote: Skip scu_enable(scu_base) if CPU is not Cortex A9 with SCU. Signed-off-by: Hiroshi Doyu --- Looks fine. I will also update OMAP code with the new interface. Thanks. OK, so patch 1/2 at least needs to get into a stable arm-soc branch then. Unless there are violent objections, I'll forward patch 1/2 to arm-soc and request it be added into a branch so that Tegra and OMAP can both merge it into their branches as a dependency. I guess patch 2/2 could also be included; I don't think it has any complex dependencies that'd prevent that, and would help to show how patch 1/2 gets used. Hiroshi, is this series the only dependency you need for your Tegra114 series? So, I could merge your Tegra114 series once this series is applied? For something like this, it might make more sense for us to just apply the patches for OMAP on top, i.e. we'll pull the short branch from you, and then we can just apply patches (with maintainer acks) on top, instead of doing a bunch of single-patch pulls. In case you decide to apply patches, you can use patch in the end of the email for OMAP. Attached the same in case mailer damages it. Btw, I noticed the build error with patch 1/1. Since I wasn't using the first interface in OMAP code, I just bypassed it for testing. I might be missing some dependent patch which added read_cpuid_part_number(). Thanks for the OMAP patch. I have pushed a couple of temporary and non-stable branches to: git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git Branch scu-base-rework contains just the SCU base address patches. After the few things listed below, I'll rename this branch and send a pull request to arm-soc. 1) Olof asked that Russell Ack or otherwise OK Hiroshi's latest versions of the following two patches since he commented on previous versions: ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9 ARM: Add API to detect SCU base address from CP15 2) Lorenzo's last comment on "ARM: tegra: Use DT /cpu node to detect number of CPU core" was: Please add missing punctuation, reword the commit log to make it clearer. ... so that patch needs a reworded commit log. 3) This branch needs testing on both Tegra30 and OMAP (I'm away from the office at the moment and can only test on Tegra20 here), Tested 'scu-base-rework' branch on OMAP and it works just fine. I noticed that the OMAP patch subject got line wrapped. Can you please fix that before sending pull request ? Thanks for picking up the patch. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 final tree (akpm tree related)
Hi all, After merging the final tree, today's linux-next build (sparc32 defconfig) failed like this: arch/sparc/mm/init_32.c: In function 'show_mem': arch/sparc/mm/init_32.c:60:23: error: invalid operands to binary << (have 'atomic_long_t' and 'int') Caused by commit "swap: add per-partition lock for swapfile" from the akpm tree. I have reverted that commit for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp1nn_HMYXdh.pgp Description: PGP signature
[GIT PULL for v3.8-rc] DaVinci media fixes for v3.8
Hi Mauro, Please pull the following patches which fixes display on DA850 EVM . To avoid conflicts I have included a arm patch, which has been Acked by its maintainer. Fixes : - adv7343 encoder: fix configuring the encoder. - da850: pass data for adv7343 encoder for required configuration. Thank you! Prabhakar The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git davinci_media Lad, Prabhakar (2): media: adv7343: accept configuration through platform data ARM: davinci: da850 evm: pass platform data for adv7343 encoder arch/arm/mach-davinci/board-da850-evm.c | 13 drivers/media/i2c/adv7343.c | 36 ++--- include/media/adv7343.h | 52 +++ 3 files changed, 96 insertions(+), 5 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: [RFC/PATCH] scripts/tracing: Add trace_analyze.py tool
On Wed, Jan 23, 2013 at 06:37:56PM -0300, Ezequiel Garcia wrote: > Hi Minchan, > > On Wed, Jan 23, 2013 at 1:27 AM, Minchan Kim wrote: > > Hi Ezequiel, > > > > On Tue, Jan 22, 2013 at 06:46:58AM -0300, Ezequiel Garcia wrote: > >> From: Ezequiel Garcia > >> > >> The purpose of trace_analyze.py tool is to perform static > >> and dynamic memory analysis using a kmem ftrace > >> log file and a built kernel tree. > >> > >> This script and related work has been done on the CEWG/2012 project: > >> "Kernel dynamic memory allocation tracking and reduction" > >> (More info here [1]) > >> > >> It produces mainly two kinds of outputs: > >> * an account-like output, similar to the one given by Perf, example below. > >> * a ring-char output, examples here [2]. > >> > >> $ ./scripts/tracing/trace_analyze.py -k linux -f kmem.log --account-file > >> account.txt > >> $ ./scripts/tracing/trace_analyze.py -k linux -f kmem.log -c account.txt > >> > >> This will produce an account file like this: > >> > >> current bytes allocated: 669696 > >> current bytes requested: 618823 > >> current wasted bytes: 50873 > >> number of allocs: 7649 > >> number of frees: 2563 > >> number of callers: 115 > >> > >> totalwaste net alloc/free caller > >> - > >> 2992000 298928 1100/1 alloc_inode+0x4fL > >> 1898240 140544 1483/385 __d_alloc+0x22L > >> 51904047552 811/68sysfs_new_dirent+0x4eL > >> [...] > >> > >> [1] http://elinux.org/Kernel_dynamic_memory_analysis > >> [2] > >> http://elinux.org/Kernel_dynamic_memory_analysis#Current_dynamic_footprint > > > > First of all, Thanks for nice work! It could be very useful for > > embedded side. > > > > Questions. > > > > 1. Can we detect different call path but same function? > >I mean > > > > A C > > \ / > > B D > >\ / > > E > > | > > kmalloc > > > > In this case, E could be called by A or C. I would like to know the call > > path. > > It could point out exact culprit of memory hogger. > > > > I'm sorry, I'm not following you: > How can I know which caller in the call path is the 'real' responsible > for the allocation? > > The only way I can think of achieving something like this is by using > kmalloc_track_caller() instead of kmalloc(). > This is done in cases where an allocer is known to alloc memory on > behalf of its caller. I mean following as. It's a example from page_owner about alloc_pages. I'm not sure it's good example but it could give my intent. 358 times: Page allocated via order 1, mask 0x2852d0 [] new_slab+0x2d5/0x370 [] __slab_alloc+0x2bb/0x41c [] kmem_cache_alloc+0x18c/0x1a0 [] __d_alloc+0x27/0x180 [] d_alloc+0x28/0x80 [] lookup_dcache+0xa3/0xd0 [] __lookup_hash+0x23/0x50 [] lookup_slow+0x49/0xad .. .. 1 times: Page allocated via order 1, mask 0x2852d0 [] new_slab+0x2d5/0x370 [] __slab_alloc+0x2bb/0x41c [] kmem_cache_alloc+0x18c/0x1a0 [] __d_alloc+0x27/0x180 [] d_alloc+0x28/0x80 [] lookup_dcache+0xa3/0xd0 [] __lookup_hash+0x23/0x50 [] lookup_one_len+0xd6/0x130 >From above example, alloc_pages could be called from several path The one path is lookup_slow and another is lookup_one_len so I can investigate who asks lookup_slow frequently. > > > 2. Does it support alloc_pages family? > >kmem event trace already supports it. If it supports, maybe we can > > replace > >CONFIG_PAGE_OWNER hack. > > > > Mmm.. no, it doesn't support alloc_pages and friends, for we found > no reason to do it. > However, it sounds like a nice idea, on a first thought. > > I'll review CONFIG_PAGE_OWNER patches and see if I can come up with something. Thanks! > > Meantime, and given this is just a script submission, is there anything > preventing to merge this? We can move it to perf, and/or add it > features, etc. later, > on top of this. Does this make sense? > > -- > Ezequiel > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 65/76] ARC: UAPI Disintegrate arch/arc/include/asm
On Wednesday 23 January 2013 06:20 PM, David Howells wrote: > Vineet Gupta wrote: > >> I generated this patch using the scripts you provided. If these look OK to >> you, can you please ACK. > > You need to take a look at uapi/asm/setup.h. It's created as an empty file - > which will get discarded by patch. Do you actually need a UAPI instance of > that? > > David > Given that setup.h is exported by include/uapi/asm-generic/Kbuild.asm (as part of userspace header ABI) there's no way we can avoid it's uapi sibling - even if empty. But to workaround patch discarding it, I will add a placeholder comment in generated setup.h (just like you did for arch/cris). Would that take care of it ? BTW looking at metag port, it seems that does #include , but latter doesn't exist in the repository - is it generated for you James or is this same issue which David elucidated to above ? -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][v2] perf tools, powerpc: Fix compile warnings in tests/attr.c
[PATCH][v2] perf tools, powerpc: Fix compile warnings in tests/attr.c We print several '__u64' quantities using '%llu'. On powerpc, we by default include ' which results in __u64 being an unsigned long. This causes compile warnings which are treated as errors due to '-Werror'. By defining __SANE_USERSPACE_TYPES__ we include and define __u64 as unsigned long long. Changelog[v2]: [Michael Ellerman] Use __SANE_USERSPACE_TYPES__ and avoid PRIu64 format specifier - which as Jiri Olsa pointed out, breaks on x86-64. Signed-off-by: Sukadev Bhattiprolu --- tools/perf/tests/attr.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/tools/perf/tests/attr.c b/tools/perf/tests/attr.c index f61dd3f..bdcceb8 100644 --- a/tools/perf/tests/attr.c +++ b/tools/perf/tests/attr.c @@ -19,6 +19,11 @@ * permissions. All the event text files are stored there. */ +/* + * Powerpc needs __SANE_USERSPACE_TYPES__ before to select + * 'int-ll64.h' and avoid compile warnings when printing __u64 with %llu. + */ +#define __SANE_USERSPACE_TYPES__ #include #include #include -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fb: vt8500: Unmerged patches for 3.9
Hi Florian, I have a couple of patches that were submitted 02/Jan/13 that are still floating around - I couldn't see them added to your fbdev-next branch either. https://patchwork.kernel.org/patch/1924971/ https://patchwork.kernel.org/patch/1925021/ https://patchwork.kernel.org/patch/1924961/ https://patchwork.kernel.org/patch/1924951/ Still on Christmas holidays or did they slip through the cracks? Regards Tony Prisk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: mxs: dt: Add Crystalfontz CFA-10037 device tree support
On Tue, Jan 22, 2013 at 05:35:51PM +0100, Maxime Ripard wrote: > The CFA-10037 is another expansion board for the CFA-10036 module, with > only a USB Host, a Ethernet device and a lot of gpios. > > Signed-off-by: Maxime Ripard > --- > arch/arm/boot/dts/imx28-cfa10037.dts | 77 > ++ Please add the dtb target into arch/arm/boot/dts/Makfile. Shawn > arch/arm/mach-mxs/mach-mxs.c |8 > 2 files changed, 85 insertions(+) > create mode 100644 arch/arm/boot/dts/imx28-cfa10037.dts -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] MAINTAINERS: Update John Stultz email
John's email switched from IBM to Linaro. One less place for him to update now... Signed-off-by: Nivedita Singhvi --- MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4e734ed..59e68d8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6596,7 +6596,7 @@ F:drivers/dma/dw_dmac_regs.h F: drivers/dma/dw_dmac.c TIMEKEEPING, NTP -M: John Stultz +M: John Stultz M: Thomas Gleixner T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core S: Supported -- 1.7.5.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] vgacon/vt: clear buffer attributes when we load a 512 character font
We should clear this bit presumably on switching either from or to 512-char
mode, since the bit doesn't really make sense either way.
Dave Airlie wrote:
>From: Dave Airlie
>
>When we switch from 256->512 byte font rendering mode, it means the
>current contents of the screen is being reinterpreted. The bit that
>holds
>the high bit of the 9-bit font, may have been previously set, and thus
>the new font misrenders.
>
>The problem case we see is grub2 writes spaces with the bit set, so it
>ends up with data like 0x820, which gets reinterpreted into 0x120 char
>which the font translates into G with a circumflex. This flashes up on
>screen at boot and is quite ugly.
>
>A current side effect of this patch though is that any rendering on the
>screen changes color to a slightly darker color, but at least the
>screen
>no longer corrupts.
>
>Signed-off-by: Dave Airlie
>---
> drivers/tty/vt/vt.c| 2 +-
> drivers/video/console/vgacon.c | 19 ---
> include/linux/vt_kern.h| 1 +
> 3 files changed, 14 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
>index 8fd8968..c8067ae 100644
>--- a/drivers/tty/vt/vt.c
>+++ b/drivers/tty/vt/vt.c
>@@ -638,7 +638,7 @@ static inline void save_screen(struct vc_data *vc)
> *Redrawing of screen
> */
>
>-static void clear_buffer_attributes(struct vc_data *vc)
>+void clear_buffer_attributes(struct vc_data *vc)
> {
> unsigned short *p = (unsigned short *)vc->vc_origin;
> int count = vc->vc_screenbuf_size / 2;
>diff --git a/drivers/video/console/vgacon.c
>b/drivers/video/console/vgacon.c
>index d449a74..271b5d0 100644
>--- a/drivers/video/console/vgacon.c
>+++ b/drivers/video/console/vgacon.c
>@@ -1064,7 +1064,7 @@ static int vgacon_do_font_op(struct vgastate
>*state,char *arg,int set,int ch512)
> unsigned short video_port_status = vga_video_port_reg + 6;
> int font_select = 0x00, beg, i;
> char *charmap;
>-
>+ bool clear_attribs = false;
> if (vga_video_type != VIDEO_TYPE_EGAM) {
> charmap = (char *) VGA_MAP_MEM(colourmap, 0);
> beg = 0x0e;
>@@ -1169,12 +1169,6 @@ static int vgacon_do_font_op(struct vgastate
>*state,char *arg,int set,int ch512)
>
> /* if 512 char mode is already enabled don't re-enable it. */
> if ((set) && (ch512 != vga_512_chars)) {
>- /* attribute controller */
>- for (i = 0; i < MAX_NR_CONSOLES; i++) {
>- struct vc_data *c = vc_cons[i].d;
>- if (c && c->vc_sw == &vga_con)
>- c->vc_hi_font_mask = ch512 ? 0x0800 : 0;
>- }
> vga_512_chars = ch512;
> /* 256-char: enable intensity bit
> 512-char: disable intensity bit */
>@@ -1185,8 +1179,19 @@ static int vgacon_do_font_op(struct vgastate
>*state,char *arg,int set,int ch512)
> it means, but it works, and it appears necessary */
> inb_p(video_port_status);
> vga_wattr(state->vgabase, VGA_AR_ENABLE_DISPLAY, 0);
>+ clear_attribs = true;
> }
> raw_spin_unlock_irq(&vga_lock);
>+
>+ if (clear_attribs) {
>+ for (i = 0; i < MAX_NR_CONSOLES; i++) {
>+ struct vc_data *c = vc_cons[i].d;
>+ if (c && c->vc_sw == &vga_con) {
>+ clear_buffer_attributes(c);
>+ c->vc_hi_font_mask = ch512 ? 0x0800 : 0;
>+ }
>+ }
>+ }
> return 0;
> }
>
>diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
>index 50ae7d0..1f55665 100644
>--- a/include/linux/vt_kern.h
>+++ b/include/linux/vt_kern.h
>@@ -47,6 +47,7 @@ int con_set_cmap(unsigned char __user *cmap);
> int con_get_cmap(unsigned char __user *cmap);
> void scrollback(struct vc_data *vc, int lines);
> void scrollfront(struct vc_data *vc, int lines);
>+void clear_buffer_attributes(struct vc_data *vc);
>void update_region(struct vc_data *vc, unsigned long start, int count);
> void redraw_screen(struct vc_data *vc, int is_switch);
> #define update_screen(x) redraw_screen(x, 0)
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/14] DMA Engine support for AM33XX
Matt, On 1/24/2013 3:07 AM, Matt Porter wrote: > On Wed, Jan 23, 2013 at 10:21:42AM +0800, Mark Brown wrote: >> On Tue, Jan 22, 2013 at 09:26:34PM +0530, Sekhar Nori wrote: >>> On 1/16/2013 2:02 AM, Matt Porter wrote: >> This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. >> >>> Will you take this series through the OMAP tree? Only 1/14 touches >>> mach-davinci and I am mostly okay with it except some changes I just >>> requested Matt to make in another thread. >> >> Is this series somewhere near actually getting merged then? It seemed >> like there was lots of stuff going on. > > The issues raised by Sekhar and Santosh were reasonably minor and will > be addressed. My major concern is that the dependency on some api to > fetch dmaengine driver SG limitations is not resolved. That's being > discussed in https://lkml.org/lkml/2013/1/10/432 It might be worth posting the patches which don't have dependencies and are ready for acceptance as a separate series. That way at least some of these patches have a good chance of getting into v3.9 if not the entire series. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/14] DMA Engine support for AM33XX
On Thursday 24 January 2013 02:19 AM, Matt Porter wrote: On Wed, Jan 23, 2013 at 04:37:55PM +0530, Santosh Shilimkar wrote: Matt, On Wednesday 16 January 2013 02:02 AM, Matt Porter wrote: [..] This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. The series applies on top of 3.8-rc3 and the following patches: - TPS65910 REGMAP_IRQ build fix: https://patchwork.kernel.org/patch/1857701/ - dmaengine DT support from Vinod's dmaengine_dt branch in git://git.infradead.org/users/vkoul/slave-dma.git since 027478851791df751176398be02a3b1c5f6aa824 - edma dmaengine driver fix: https://patchwork.kernel.org/patch/1961521/ - dmaengine dma_get_channel_caps v2: https://patchwork.kernel.org/patch/1961601/ - dmaengine edma driver channel caps support v2: https://patchwork.kernel.org/patch/1961591/ The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. With this series both BeagleBone and the AM335x EVM have working MMC and SPI support. This is tested on BeagleBone with a SPI framebuffer driver and MMC rootfs. A trivial gpio DMA event misc driver was used to test the crossbar DMA event support. It is also tested on the AM335x EVM with the onboard SPI flash and MMC rootfs. The branch at https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v4 has the complete series, dependencies, and some test drivers/defconfigs. Regression testing was done on AM180x-EVM (which also makes use of the EDMA dmaengine driver and the EDMA private API) using SD, SPI flash, and the onboard audio supported by the ASoC Davinci driver. Regression testing was also done on a BeagleBoard xM booting from the legacy board file using MMC rootfs. Matt Porter (14): ARM: davinci: move private EDMA API to arm/common ARM: edma: remove unused transfer controller handlers ARM: edma: add AM33XX support to the private EDMA API dmaengine: edma: enable build for AM33XX dmaengine: edma: Add TI EDMA device tree binding ARM: dts: add AM33XX EDMA support dmaengine: add dma_request_slave_channel_compat() mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() mmc: omap_hsmmc: set max_segs based on dma engine limitations mmc: omap_hsmmc: add generic DMA request support to the DT binding ARM: dts: add AM33XX MMC support spi: omap2-mcspi: convert to dma_request_slave_channel_compat() spi: omap2-mcspi: add generic DMA request support to the DT binding ARM: dts: add AM33XX SPI DMA support While going through the series and testing it out, I observed an issue with MMC driver. You need patch in the end of the email to avoid the issue. Same is attached in case mailer damages it. Can you please add it with your series if you agree ? Yes, by inspection this makes sense. As you noticed, we've been relying on the fact that DMA resources still don't come from DT, we only use our DT data in conjunction with the DMA OF helpers to do channel filtering. I was figuring we would address that separately later, but I see how even omap4 has this issue with DMA resources named with "tx1", for example. A good followup once this series is taken will be to only use hwmod resources on a !populated-dt platform like we do for other resources now. Baby steps. :) We are already on it :-) Thanks for the catch, I'll add this in with your tested line as well for the series. Thanks. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dw_dmac: return proper residue value
On Wed, Jan 23, 2013 at 9:07 PM, Andy Shevchenko
wrote:
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> static void dwc_scan_descriptors(struct dw_dma *dw, struct dw_dma_chan *dwc)
> {
> dma_addr_t llp;
> @@ -410,6 +441,8 @@ static void dwc_scan_descriptors(struct dw_dma *dw,
> struct dw_dma_chan *dwc)
> */
> desc = dwc_first_active(dwc);
>
> + dwc_update_residue(dwc, desc);
> +
> if (dwc->tx_node_active != &desc->tx_list) {
> child = to_dw_desc(dwc->tx_node_active);
Is there a point updating residue here? I don't have a very good knowledge of
nollp transfers but this is what i know...
The above "if" will pass if we are still doing transfers and fail if
all transfers are done.
After the end of each LLI we receive an interrupt, where we queue next
LLI. Better
would be to initialize dwc->residue at dwc_dostart() with total
length, start decrementing
it with desc->len for every lli interrupt we get and if call for
getting residue comes in
middle of transfer, simple return residue - dwc_get_sent(desc) without
updating residue
field...
> @@ -436,6 +469,9 @@ static void dwc_scan_descriptors(struct dw_dma *dw,
> struct dw_dma_chan *dwc)
>
> if (test_bit(DW_DMA_IS_SOFT_LLP, &dwc->flags)) {
> dev_vdbg(chan2dev(&dwc->chan), "%s: soft LLP mode\n",
> __func__);
> +
> + dwc_update_residue(dwc, dwc_first_active(dwc));
> +
same is applicable here too and so you can get rid of
dwc_update_residue() routine.
> spin_unlock_irqrestore(&dwc->lock, flags);
> return;
> }
> @@ -444,6 +480,9 @@ static void dwc_scan_descriptors(struct dw_dma *dw,
> struct dw_dma_chan *dwc)
> (unsigned long long)llp);
>
> list_for_each_entry_safe(desc, _desc, &dwc->active_list, desc_node) {
> + /* initial residue value */
> + dwc->residue = desc->total_len;
> +
> /* check first descriptors addr */
> if (desc->txd.phys == llp) {
> spin_unlock_irqrestore(&dwc->lock, flags);
> @@ -453,16 +492,21 @@ static void dwc_scan_descriptors(struct dw_dma *dw,
> struct dw_dma_chan *dwc)
> /* check first descriptors llp */
> if (desc->lli.llp == llp) {
> /* This one is currently in progress */
> + dwc->residue -= dwc_get_sent(dwc);
> spin_unlock_irqrestore(&dwc->lock, flags);
> return;
> }
>
> - list_for_each_entry(child, &desc->tx_list, desc_node)
> + dwc->residue -= desc->len;
> + list_for_each_entry(child, &desc->tx_list, desc_node) {
> if (child->lli.llp == llp) {
> /* Currently in progress */
> + dwc->residue -= dwc_get_sent(dwc);
> spin_unlock_irqrestore(&dwc->lock, flags);
> return;
> }
> + dwc->residue -= child->len;
> + }
>
> /*
> * No descriptors so far seem to be in progress, i.e.
> @@ -1058,6 +1102,7 @@ dwc_tx_status(struct dma_chan *chan,
> struct dma_tx_state *txstate)
> {
> struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
> + unsigned long flags;
> enum dma_status ret;
>
> ret = dma_cookie_status(chan, cookie, txstate);
> @@ -1067,8 +1112,12 @@ dwc_tx_status(struct dma_chan *chan,
> ret = dma_cookie_status(chan, cookie, txstate);
> }
>
> + spin_lock_irqsave(&dwc->lock, flags);
> +
why do you need locking here?
> if (ret != DMA_SUCCESS)
> - dma_set_residue(txstate, dwc_first_active(dwc)->len);
> + dma_set_residue(txstate, dwc->residue);
> +
> + spin_unlock_irqrestore(&dwc->lock, flags);
>
> if (dwc->paused)
> return DMA_PAUSED;
> diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
> index 833b4cf..88dd8eb 100644
> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -203,6 +203,7 @@ struct dw_dma_chan {
> struct list_headactive_list;
> struct list_headqueue;
> struct list_headfree_list;
> + u32 residue;
> struct dw_cyclic_desc *cdesc;
>
> unsigned intdescs_allocated;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: adc: add exynos5 adc driver under iio framwork
This patch add an ADC IP found on EXYNOS5250 and EXYNOS5410 SoCs
from Samsung. Also adds the Documentation for device tree bindings.
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
1. Fixed comments from Lars
2. Added support for ADC on EXYNOS5410
Changes since v2:
1. Changed the instance name for (struct iio_dev *) to indio_dev
2. Changed devm_request_irq to request_irq
Few doubts regarding the mappings and child device handling.
Kindly, suggest me better methods.
Changes since v3:
1. Added clk_prepare_disable and regulator_disable calls in _remove()
2. Moved init_completion before irq_request
3. Added NULL pointer check for devm_request_and_ioremap() return value.
4. Use number of channels as per the ADC version
5. Change the define ADC_V1_CHANNEL to ADC_CHANNEL
6. Update the Documentation to include EXYNOS5410 compatible
Changes since v4:
1. if devm_request_and_ioremap() failes, free iio_device before returning
Doug, i've used
chan = iio_channel_get(dev_name(&pdev->dev), "adc3");
in ntc thermistor driver during probe and
iio_read_channel_raw(chan, &val);
for read.
But, then the drivers become kind of coupled. Right.
Lars, Is there an other way.
Thanks for the comments
.../bindings/arm/samsung/exynos5-adc.txt | 38 ++
drivers/iio/adc/Kconfig|7 +
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/exynos5_adc.c | 477
4 files changed, 523 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
create mode 100644 drivers/iio/adc/exynos5_adc.c
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
new file mode 100644
index 000..0f281d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
@@ -0,0 +1,38 @@
+Samsung Exynos5 Analog to Digital Converter bindings
+
+Required properties:
+- compatible: Must be "samsung,exynos5250-adc" for exynos5250
controllers.
+ Must be "samsung,exynos5410-adc" for exynos5410
controllers.
+- reg: Contains ADC register address range (base address and
+ length).
+- interrupts: Contains the interrupt information for the timer. The
+ format is being dependent on which interrupt controller
+ the Samsung device uses.
+
+Note: child nodes can be added for auto probing from device tree.
+
+Example: adding device info in dtsi file
+
+adc@12D1 {
+ compatible = "samsung,exynos5250-adc";
+ reg = <0x12D1 0x100>;
+ interrupts = <0 106 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+};
+
+
+Example: Adding child nodes in dts file
+
+adc@12D1 {
+
+ /* NTC thermistor is a hwmon device */
+ ncp15wb473@0 {
+ compatible = "ntc,ncp15wb473";
+ reg = <0x0>;
+ pullup-uV = <180>;
+ pullup-ohm = <47000>;
+ pulldown-ohm = <0>;
+ };
+};
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index fe822a1..33ceabf 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -91,6 +91,13 @@ config AT91_ADC
help
Say yes here to build support for Atmel AT91 ADC.
+config EXYNOS5_ADC
+ bool "Exynos5 ADC driver support"
+ help
+ Core support for the ADC block found in the Samsung EXYNOS5 series
+ of SoCs for drivers such as the touchscreen and hwmon to use to share
+ this resource.
+
config LP8788_ADC
bool "LP8788 ADC driver"
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 2d5f100..5b4a4f6 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_AD7791) += ad7791.o
obj-$(CONFIG_AD7793) += ad7793.o
obj-$(CONFIG_AD7887) += ad7887.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
+obj-$(CONFIG_EXYNOS5_ADC) += exynos5_adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
diff --git a/drivers/iio/adc/exynos5_adc.c b/drivers/iio/adc/exynos5_adc.c
new file mode 100644
index 000..197d622
--- /dev/null
+++ b/drivers/iio/adc/exynos5_adc.c
@@ -0,0 +1,477 @@
+/*
+ * exynos5_adc.c - Support for ADC in EXYNOS5 SoCs
+ *
+ * 8 ~ 10 channel, 10/12-bit ADC
+ *
+ * Copyright (C) 2013 Naveen Krishna Chatradhi
+ *
+ * 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 warra
Re: [v3 2/2] ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9
On 01/23/2013 01:58 AM, Santosh Shilimkar wrote: > On Tuesday 22 January 2013 10:34 PM, Olof Johansson wrote: >> On Tue, Jan 22, 2013 at 8:57 AM, Stephen Warren >> wrote: >>> On 01/21/2013 11:07 PM, Santosh Shilimkar wrote: On Tuesday 22 January 2013 11:22 AM, Hiroshi Doyu wrote: > Skip scu_enable(scu_base) if CPU is not Cortex A9 with SCU. > > Signed-off-by: Hiroshi Doyu > --- Looks fine. I will also update OMAP code with the new interface. Thanks. >>> >>> OK, so patch 1/2 at least needs to get into a stable arm-soc branch >>> then. Unless there are violent objections, I'll forward patch 1/2 to >>> arm-soc and request it be added into a branch so that Tegra and OMAP can >>> both merge it into their branches as a dependency. I guess patch 2/2 >>> could also be included; I don't think it has any complex dependencies >>> that'd prevent that, and would help to show how patch 1/2 gets used. >>> >>> Hiroshi, is this series the only dependency you need for your Tegra114 >>> series? So, I could merge your Tegra114 series once this series is >>> applied? >> >> For something like this, it might make more sense for us to just apply >> the patches for OMAP on top, i.e. we'll pull the short branch from >> you, and then we can just apply patches (with maintainer acks) on top, >> instead of doing a bunch of single-patch pulls. > > In case you decide to apply patches, you can use patch in the end > of the email for OMAP. Attached the same in case mailer damages it. > > Btw, I noticed the build error with patch 1/1. Since I wasn't using > the first interface in OMAP code, I just bypassed it for testing. > I might be missing some dependent patch which added > read_cpuid_part_number(). Thanks for the OMAP patch. I have pushed a couple of temporary and non-stable branches to: git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git Branch scu-base-rework contains just the SCU base address patches. After the few things listed below, I'll rename this branch and send a pull request to arm-soc. 1) Olof asked that Russell Ack or otherwise OK Hiroshi's latest versions of the following two patches since he commented on previous versions: ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9 ARM: Add API to detect SCU base address from CP15 2) Lorenzo's last comment on "ARM: tegra: Use DT /cpu node to detect number of CPU core" was: Please add missing punctuation, reword the commit log to make it clearer. ... so that patch needs a reworded commit log. 3) This branch needs testing on both Tegra30 and OMAP (I'm away from the office at the moment and can only test on Tegra20 here), Branch test-test-hdoyu-t114 contains the most recent version of the Tegra114 series from Hiroshi, mainly for my local testing etc. Hiroshi said he will repost an updated version based on the latest Tegra common clock framework changes. For the record, what I plan to do when applying this is: 1) Merge the renamed tmp/scu-base-rework into Tegra's for-3.9/soc. 2) Apply the new posting of the Tegra114 patch series. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ARM: arm-soc fixes for 3.8-rc
Hi Linus, The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus for you to fetch changes up to 4ad3041d3b76632c02b50aa384a8f21d7d15bac0: Merge tag 'imx-fixes-3.8-3' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes (2013-01-23 20:35:02 -0800) ARM: arm-soc fixes for 3.8 Here's a long-pending fixes pull request for arm-soc (I didn't send one in the -rc4 cycle). The largest delta is for a fixup of error paths in the mvsdio driver. There's also a header file move for a driver that hadn't been properly converted to multiplatform on i.MX, which was causing build failures when included. The rest are the normal mix of small fixes all over the place; sunxi, omap, imx, mvebu, etc, etc. Alim Akhtar (1): ARM: dts: correct the dw-mshc timing properties as per binding Andrew Lunn (1): mmc: mvsdio: use devm_ API to simplify/correct error paths. Cong Ding (1): clk: mvebu/clk-cpu.c: fix memory leakage Dimitris Papastamos (1): ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore Fabio Estevam (1): video: imxfb: Do not crash on reboot Gregory CLEMENT (1): arm: mvebu: Fix memory size for Armada 370 DB Gwenhael Goavec-Merou (2): ARM: imx: platform-imx-fb: modifies platform device name video: imxfb: fix imxfb_info configuration order Jon Hunter (1): ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function calls Linus Walleij (1): ARM: integrator: move syscon remap for AP PCIv3 Luciano Coelho (1): ARM: OMAP2+: omap4-panda: add UART2 muxing for WiLink shared transport Maxime Ripard (1): ARM: sunxi: Use the Synosys APB UART instead of ns8250 Olof Johansson (8): Merge tag 'mvebu_fixes_for_v3.8-rc3' of git://git.infradead.org/users/jcooper/linux into fixes Merge tag 'imx-fixes-3.8-2' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes Merge tag 'sunxi-fixes-for-3.8-rc4' of git://github.com/mripard/linux into fixes Merge branch 'v3.8-samsung-fixes-3' of git://git.kernel.org/.../kgene/linux-samsung into fixes Merge tag 'imx-fixes-rc' of git://git.pengutronix.de/git/imx/linux-2.6 into fixes Merge tag 'omap-for-v3.8-rc4/fixes-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes Merge tag 'mvebu_fixes_for_v3.8-rc5' of git://git.infradead.org/users/jcooper/linux into fixes Merge tag 'imx-fixes-3.8-3' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes Pantelis Antoniou (1): ARM: OMAP2+: DT node Timer iteration fix Peter Ujfalusi (2): ARM: OMAP4: clock data: Lock ABE DPLL on all revisions ARM: OMAP4: hwmod_data: Correct IDLEMODE for McPDM Rob Clark (1): ARM: OMAP2+: fix build break for omapdrm Sascha Hauer (1): [media] coda: Fix build due to iram.h rename Sebastian Hesselbarth (2): ARM: Dove: add Cubox sdhci card detect gpio ARM: kirkwood: fix missing #interrupt-cells property Shawn Guo (3): ARM: imx: fix build error with !CONFIG_SMP ARM: imx: disable cpu in .cpu_kill hook ARM: imx: correct low-power mode setting Simon Guinot (1): ARM: Kirkwood: fix ns2 gpios by converting to pinctrl Thomas Petazzoni (1): arm: mvebu: use global interrupts for GPIOs on Armada XP Tomasz Figa (1): ARM: S3C64XX: Fix build error with CONFIG_S3C_DEV_FB disabled Tony Lindgren (3): arm: mvebu: Fix compile for multiplatform when ARMv6 is selected Merge tag 'omap-fixes-b-for-v3.8-rc' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.8-rc4/fixes ARM: OMAP2+: Fix section warning for omap_init_ocp2scp() Uwe Kleine-König (1): ARM: compile fix for DEBUG_LL=y && MMU=n arch/arm/boot/dts/armada-370-db.dts| 2 +- arch/arm/boot/dts/armada-xp-mv78230.dtsi | 14 ++-- arch/arm/boot/dts/armada-xp-mv78260.dtsi | 21 +++-- arch/arm/boot/dts/armada-xp-mv78460.dtsi | 21 +++-- arch/arm/boot/dts/cros5250-common.dtsi | 12 +-- arch/arm/boot/dts/dove-cubox.dts | 14 +++- arch/arm/boot/dts/exynos5250-smdk5250.dts | 8 +- arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 16 arch/arm/boot/dts/kirkwood.dtsi| 2 + arch/arm/boot/dts/sunxi.dtsi | 6 +- arch/arm/kernel/debug.S| 2 + arch/arm/mach-imx/Kconfig | 1 + arch/arm/mach-imx/clk-imx6q.c | 3 + arch/arm/mach-imx/common.h | 1 + arch/arm/mach-imx/devices/platform-imx-fb.c| 2 +- arch/arm/mach-imx/hotplug.c| 10 ++- arch/arm
[PATCH] iio: adc: add exynos5 adc driver under iio framwork
This patch adds driver for ADC IP found on EXYNOS5250 and EXYNOS5410
from Samsung. Also adds the Documentation for device tree bindings.
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
1. Fixed comments from Lars
2. Added support for ADC on EXYNOS5410
Changes since v2:
1. Changed the instance name for (struct iio_dev *) to indio_dev
2. Changed devm_request_irq to request_irq
Few doubts regarding the mappings and child device handling.
Kindly, suggest me better methods.
Changes since v3:
1. Added clk_prepare_disable and regulator_disable calls in _remove()
2. Moved init_completion before irq_request
3. Added NULL pointer check for devm_request_and_ioremap() return value.
4. Use number of channels as per the ADC version
5. Change the define ADC_V1_CHANNEL to ADC_CHANNEL
6. Update the Documentation to include EXYNOS5410 compatible
Doug, i've used
chan = iio_channel_get(dev_name(&pdev->dev), "adc3");
in ntc thermistor driver during probe and
iio_read_channel_raw(chan, &val);
for read.
But, then the drivers become kind of coupled. Right.
Lars, Is there an other way.
Thanks for the comments
.../bindings/arm/samsung/exynos5-adc.txt | 38 ++
drivers/iio/adc/Kconfig|7 +
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/exynos5_adc.c | 475
4 files changed, 521 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
create mode 100644 drivers/iio/adc/exynos5_adc.c
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
new file mode 100644
index 000..0f281d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
@@ -0,0 +1,38 @@
+Samsung Exynos5 Analog to Digital Converter bindings
+
+Required properties:
+- compatible: Must be "samsung,exynos5250-adc" for exynos5250
controllers.
+ Must be "samsung,exynos5410-adc" for exynos5410
controllers.
+- reg: Contains ADC register address range (base address and
+ length).
+- interrupts: Contains the interrupt information for the timer. The
+ format is being dependent on which interrupt controller
+ the Samsung device uses.
+
+Note: child nodes can be added for auto probing from device tree.
+
+Example: adding device info in dtsi file
+
+adc@12D1 {
+ compatible = "samsung,exynos5250-adc";
+ reg = <0x12D1 0x100>;
+ interrupts = <0 106 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+};
+
+
+Example: Adding child nodes in dts file
+
+adc@12D1 {
+
+ /* NTC thermistor is a hwmon device */
+ ncp15wb473@0 {
+ compatible = "ntc,ncp15wb473";
+ reg = <0x0>;
+ pullup-uV = <180>;
+ pullup-ohm = <47000>;
+ pulldown-ohm = <0>;
+ };
+};
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index fe822a1..33ceabf 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -91,6 +91,13 @@ config AT91_ADC
help
Say yes here to build support for Atmel AT91 ADC.
+config EXYNOS5_ADC
+ bool "Exynos5 ADC driver support"
+ help
+ Core support for the ADC block found in the Samsung EXYNOS5 series
+ of SoCs for drivers such as the touchscreen and hwmon to use to share
+ this resource.
+
config LP8788_ADC
bool "LP8788 ADC driver"
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 2d5f100..5b4a4f6 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_AD7791) += ad7791.o
obj-$(CONFIG_AD7793) += ad7793.o
obj-$(CONFIG_AD7887) += ad7887.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
+obj-$(CONFIG_EXYNOS5_ADC) += exynos5_adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
diff --git a/drivers/iio/adc/exynos5_adc.c b/drivers/iio/adc/exynos5_adc.c
new file mode 100644
index 000..4963649
--- /dev/null
+++ b/drivers/iio/adc/exynos5_adc.c
@@ -0,0 +1,475 @@
+/*
+ * exynos5_adc.c - Support for ADC in EXYNOS5 SoCs
+ *
+ * 8 ~ 10 channel, 10/12-bit ADC
+ *
+ * Copyright (C) 2013 Naveen Krishna Chatradhi
+ *
+ * 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
Re: [PATCH 1/2] regulator: tps65217: Fix using wrong dev argument for calling of_regulator_match
On Thu, Jan 24, 2013 at 10:27:30AM +0800, Axel Lin wrote: > - count = of_regulator_match(pdev->dev.parent, regs, > - reg_matches, TPS65217_NUM_REGULATOR); > + count = of_regulator_match(&pdev->dev, regs, reg_matches, > +TPS65217_NUM_REGULATOR); This will break the OF bindings for these regulators as the platform device doesn't appear in the DT. signature.asc Description: Digital signature
Re: [PATCH 0/4] mfd: palma: add RTC and GPIO support
On Thursday 03 January 2013 04:16 PM, Laxman Dewangan wrote: This series add the RTC and gpio driver for the TI Palma series PMIC. The changes are splitted so that easy to apply in different sub systems. Laxman Dewangan (4): mfd: palmas: add rtc irq number as irq resource for palmas-rtc mfd: palmas: add apis to access the Palmas' registers gpio: palmas: Add support for Palams GPIO rtc: palmas: add RTC driver Palmas series PMIC Samuel, I think you need to take all these patches to your tree as Linus has dropped the gpio patch due to build error. Possible same will apply for RTC change also. Thanks, Laxman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dw_dmac: fill individual length of descriptor
On Wed, Jan 23, 2013 at 9:07 PM, Andy Shevchenko
wrote:
> It will be useful to have the length of the transfer in the descriptor. The
> cyclic transfer functions remained untouched.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/dma/dw_dmac.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index c3062a5..026a3c7 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -756,6 +756,7 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t
> dest, dma_addr_t src,
> desc->lli.dar = dest + offset;
> desc->lli.ctllo = ctllo;
> desc->lli.ctlhi = xfer_count;
> + desc->len = xfer_count << src_width;
>
> if (!first) {
> first = desc;
> @@ -852,8 +853,8 @@ slave_sg_todev_fill_desc:
> dlen = len;
> len = 0;
> }
> -
:(
> desc->lli.ctlhi = dlen >> mem_width;
> + desc->len = dlen;
>
> if (!first) {
> first = desc;
> @@ -912,6 +913,7 @@ slave_sg_fromdev_fill_desc:
> len = 0;
> }
> desc->lli.ctlhi = dlen >> reg_width;
> + desc->len = dlen;
>
> if (!first) {
> first = desc;
After fixing that.
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] regulator: tps65910: Fix using wrong dev argument for calling of_regulator_match
On Thursday 24 January 2013 08:01 AM, Axel Lin wrote: The dev parameter is the device requesting the data. In this case it should be &pdev->dev rather than pdev->dev.parent. The dev parameter is used to call devm_kzalloc in of_get_regulator_init_data(), which means this fixes a memory leak because the memory is allocated every time probe() is called, thus it should be freed when this driver is unloaded. Signed-off-by: Axel Lin --- Agree with the change. Acked-by: Laxman Dewangan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dw_dmac: remove unnecessary tx_list field in dw_dma_chan
On Wed, Jan 23, 2013 at 9:07 PM, Andy Shevchenko wrote: > The soft LLP mode is working for active descriptor only. So, we do not need to > have a copy of its pointer. > > Signed-off-by: Andy Shevchenko Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] userns: improve uid/gid map collision detection
Quoting Aristeu Rozanski (a...@redhat.com):
> Initial implementation of the uid/gid maps will enforce that the
> maps should be in order and would prevent a use case like this from
> being used:
> 0 10001
> 48 500 1
>
> since the second entry both values should be bigger than the previous.
> This patch implements a more elaborate collision detection allowing any
> order to be used.
>
> Cc: "Eric W. Biederman"
> Cc: "Serge E. Hallyn"
I *think* that looks just right :)
Acked-by: Serge Hallyn
> Signed-off-by: Aristeu Rozanski
>
> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
> index 2b042c4..fb0e492 100644
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -521,6 +521,28 @@ struct seq_operations proc_projid_seq_operations = {
>
> static DEFINE_MUTEX(id_map_mutex);
>
> +#define in_range(b,first,len) ((b)>=(first)&&(b)<(first)+(len))
> +static inline int extent_collision(struct uid_gid_map *new_map,
> +struct uid_gid_extent *extent)
> +{
> + int i;
> + struct uid_gid_extent *cur;
> +
> + for (i = 0; i < new_map->nr_extents; i++) {
> + cur = &new_map->extent[i];
> + if (in_range(extent->first, cur->first, cur->count) ||
> + in_range(extent->first + extent->count, cur->first,
> + cur->count))
> + return 1;
> + if (in_range(extent->lower_first, cur->lower_first,
> + cur->count) ||
> + in_range(extent->lower_first + extent->count,
> + cur->lower_first, cur->count))
> + return 1;
> + }
> + return 0;
> +}
> +
> static ssize_t map_write(struct file *file, const char __user *buf,
>size_t count, loff_t *ppos,
>int cap_setid,
> @@ -634,10 +656,7 @@ static ssize_t map_write(struct file *file, const char
> __user *buf,
> if ((extent->lower_first + extent->count) <=
> extent->lower_first)
> goto out;
>
> - /* For now only accept extents that are strictly in order */
> - if (last &&
> - (((last->first + last->count) > extent->first) ||
> - ((last->lower_first + last->count) > extent->lower_first)))
> + if (extent_collision(&new_map, extent))
> goto out;
>
> new_map.nr_extents++;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] dw_dmac: introduce total_len field in struct dw_desc
On Wed, Jan 23, 2013 at 9:07 PM, Andy Shevchenko wrote: > By this new field we distinguish a total length of the chain and the > individual > length of each descriptor in the chain. > > Signed-off-by: Andy Shevchenko Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 04/45] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
On 01/24/2013 01:27 AM, Tejun Heo wrote: > Hello, Srivatsa. > > On Thu, Jan 24, 2013 at 01:03:52AM +0530, Srivatsa S. Bhat wrote: >> Hmm.. I split it up into steps to help explain the reasoning behind >> the code sufficiently, rather than spring all of the intricacies at >> one go (which would make it very hard to write the changelog/comments >> also). The split made it easier for me to document it well in the >> changelog, because I could deal with reasonable chunks of code/complexity >> at a time. IMHO that helps people reading it for the first time to >> understand the logic easily. > > I don't know. It's a judgement call I guess. I personally would much > prefer having ample documentation as comments in the source itself or > as a separate Documentation/ file as that's what most people are gonna > be looking at to figure out what's going on. Maybe just compact it a > bit and add more in-line documentation instead? > OK, I'll think about this. >>> The only two options are either punishing writers or identifying and >>> updating all such possible deadlocks. percpu_rwsem does the former, >>> right? I don't know how feasible the latter would be. >> >> I don't think we can avoid looking into all the possible deadlocks, >> as long as we use rwlocks inside get/put_online_cpus_atomic() (assuming >> rwlocks are fair). Even with Oleg's idea of using synchronize_sched() >> at the writer, we still need to take care of locking rules, because the >> synchronize_sched() only helps avoid the memory barriers at the reader, >> and doesn't help get rid of the rwlocks themselves. > > Well, percpu_rwlock don't have to use rwlock for the slow path. It > can implement its own writer starving locking scheme. It's not like > implementing slow path global rwlock logic is difficult. > Great idea! So probably I could use atomic ops or something similar in the slow path to implement the scheme we need... >> CPU 0 CPU 1 >> >> read_lock(&rwlock) >> >> write_lock(&rwlock) //spins, because CPU 0 >> //has acquired the lock for read >> >> read_lock(&rwlock) >>^ >> What happens here? Does CPU 0 start spinning (and hence deadlock) or will >> it continue realizing that it already holds the rwlock for read? > > I don't think rwlock allows nesting write lock inside read lock. > read_lock(); write_lock() will always deadlock. > Sure, I understand that :-) My question was, what happens when *two* CPUs are involved, as in, the read_lock() is invoked only on CPU 0 whereas the write_lock() is invoked on CPU 1. For example, the same scenario shown above, but with slightly different timing, will NOT result in a deadlock: Scenario 2: CPU 0CPU 1 read_lock(&rwlock) read_lock(&rwlock) //doesn't spin write_lock(&rwlock) //spins, because CPU 0 //has acquired the lock for read So I was wondering whether the "fairness" logic of rwlocks would cause the second read_lock() to spin (in the first scenario shown above) because a writer is already waiting (and hence new readers should spin) and thus cause a deadlock. Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: pch_uart: fix sysrq handling for pch_uart
When PCH_UART_CONSOLE and SERIAL_CORE_CONSOLE is not set neither, the
uart_port will have no 'sysrq' member hence their will need a '#ifdef'
in pch_uart.c to handle the case, otherwise we'll see compile error
like this:
CC [M] drivers/tty/serial/pch_uart.o
drivers/tty/serial/pch_uart.c: In function 'pch_uart_hal_read':
drivers/tty/serial/pch_uart.c:572:11: error: 'struct uart_port' has no member
named 'sysrq'
make[4]: *** [drivers/tty/serial/pch_uart.o] Error 1
Reported-by: Randy Dunlap
CC: Stephen Rothwell
Signed-off-by: Liang Li
---
Hi Greg,
This is for 'tty-next' of your tty tree. Thanks.
drivers/tty/serial/pch_uart.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 1ddfc66..7a6c989 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -569,10 +569,12 @@ static int pch_uart_hal_read(struct eg20t_port *priv,
unsigned char *buf,
if (uart_handle_break(port))
continue;
}
+#ifdef SUPPORT_SYSRQ
if (port->sysrq) {
if (uart_handle_sysrq_char(port, rbr))
continue;
}
+#endif
buf[i++] = rbr;
}
--
1.7.11.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: linux-next: Tree for Jan 23 (pch_uart.c)
On 2013-01-24 12:15, Stephen Rothwell wrote: > Hi, > > On Thu, 24 Jan 2013 10:30:54 +0800 Liang Li wrote: > > > > Should I add a fix for the compile error .. or do squash then send out > > refreshed patch ? > > You need to send a fix patch to Greg based on his tty tree > (git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git). > Ok, got it. Will keep you and Randy CC'd. Thanks, Liang Li > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vgacon/vt: clear buffer attributes when we load a 512 character font
From: Dave Airlie
When we switch from 256->512 byte font rendering mode, it means the
current contents of the screen is being reinterpreted. The bit that holds
the high bit of the 9-bit font, may have been previously set, and thus
the new font misrenders.
The problem case we see is grub2 writes spaces with the bit set, so it
ends up with data like 0x820, which gets reinterpreted into 0x120 char
which the font translates into G with a circumflex. This flashes up on
screen at boot and is quite ugly.
A current side effect of this patch though is that any rendering on the
screen changes color to a slightly darker color, but at least the screen
no longer corrupts.
Signed-off-by: Dave Airlie
---
drivers/tty/vt/vt.c| 2 +-
drivers/video/console/vgacon.c | 19 ---
include/linux/vt_kern.h| 1 +
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8fd8968..c8067ae 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -638,7 +638,7 @@ static inline void save_screen(struct vc_data *vc)
* Redrawing of screen
*/
-static void clear_buffer_attributes(struct vc_data *vc)
+void clear_buffer_attributes(struct vc_data *vc)
{
unsigned short *p = (unsigned short *)vc->vc_origin;
int count = vc->vc_screenbuf_size / 2;
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index d449a74..271b5d0 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -1064,7 +1064,7 @@ static int vgacon_do_font_op(struct vgastate *state,char
*arg,int set,int ch512)
unsigned short video_port_status = vga_video_port_reg + 6;
int font_select = 0x00, beg, i;
char *charmap;
-
+ bool clear_attribs = false;
if (vga_video_type != VIDEO_TYPE_EGAM) {
charmap = (char *) VGA_MAP_MEM(colourmap, 0);
beg = 0x0e;
@@ -1169,12 +1169,6 @@ static int vgacon_do_font_op(struct vgastate *state,char
*arg,int set,int ch512)
/* if 512 char mode is already enabled don't re-enable it. */
if ((set) && (ch512 != vga_512_chars)) {
- /* attribute controller */
- for (i = 0; i < MAX_NR_CONSOLES; i++) {
- struct vc_data *c = vc_cons[i].d;
- if (c && c->vc_sw == &vga_con)
- c->vc_hi_font_mask = ch512 ? 0x0800 : 0;
- }
vga_512_chars = ch512;
/* 256-char: enable intensity bit
512-char: disable intensity bit */
@@ -1185,8 +1179,19 @@ static int vgacon_do_font_op(struct vgastate *state,char
*arg,int set,int ch512)
it means, but it works, and it appears necessary */
inb_p(video_port_status);
vga_wattr(state->vgabase, VGA_AR_ENABLE_DISPLAY, 0);
+ clear_attribs = true;
}
raw_spin_unlock_irq(&vga_lock);
+
+ if (clear_attribs) {
+ for (i = 0; i < MAX_NR_CONSOLES; i++) {
+ struct vc_data *c = vc_cons[i].d;
+ if (c && c->vc_sw == &vga_con) {
+ clear_buffer_attributes(c);
+ c->vc_hi_font_mask = ch512 ? 0x0800 : 0;
+ }
+ }
+ }
return 0;
}
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index 50ae7d0..1f55665 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -47,6 +47,7 @@ int con_set_cmap(unsigned char __user *cmap);
int con_get_cmap(unsigned char __user *cmap);
void scrollback(struct vc_data *vc, int lines);
void scrollfront(struct vc_data *vc, int lines);
+void clear_buffer_attributes(struct vc_data *vc);
void update_region(struct vc_data *vc, unsigned long start, int count);
void redraw_screen(struct vc_data *vc, int is_switch);
#define update_screen(x) redraw_screen(x, 0)
--
1.8.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: linux-next: Tree for Jan 23 (pch_uart.c)
Hi, On Thu, 24 Jan 2013 10:30:54 +0800 Liang Li wrote: > > Should I add a fix for the compile error .. or do squash then send out > refreshed patch ? You need to send a fix patch to Greg based on his tty tree (git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgprY0rDThXYJ.pgp Description: PGP signature
Re: [PATCH v5 01/45] percpu_rwlock: Introduce the global reader-writer lock backend
On Tue, Jan 22, 2013 at 11:32 AM, Steven Rostedt wrote: > On Tue, 2013-01-22 at 13:03 +0530, Srivatsa S. Bhat wrote: >> A straight-forward (and obvious) algorithm to implement Per-CPU Reader-Writer >> locks can also lead to too many deadlock possibilities which can make it very >> hard/impossible to use. This is explained in the example below, which helps >> justify the need for a different algorithm to implement flexible Per-CPU >> Reader-Writer locks. >> >> We can use global rwlocks as shown below safely, without fear of deadlocks: >> >> Readers: >> >> CPU 0CPU 1 >> -- -- >> >> 1.spin_lock(&random_lock); read_lock(&my_rwlock); >> >> >> 2.read_lock(&my_rwlock); spin_lock(&random_lock); >> >> >> Writer: >> >> CPU 2: >> -- >> >>write_lock(&my_rwlock); >> > > I thought global locks are now fair. That is, a reader will block if a > writer is waiting. Hence, the above should deadlock on the current > rwlock_t types. I believe you are mistaken here. struct rw_semaphore is fair (and blocking), but rwlock_t is unfair. The reason we can't easily make rwlock_t fair is because tasklist_lock currently depends on the rwlock_t unfairness - tasklist_lock readers typically don't disable local interrupts, and tasklist_lock may be acquired again from within an interrupt, which would deadlock if rwlock_t was fair and a writer was queued by the time the interrupt is processed. > We need to fix those locations (or better yet, remove all rwlocks ;-) tasklist_lock is the main remaining user. I'm not sure about removing rwlock_t, but I would like to at least make it fair somehow :) -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86 e820: Introduce memmap=resetusablemap for kdump usage
On Tue, Jan 22, 2013 at 12:06 PM, Yinghai Lu wrote: > On Tue, Jan 22, 2013 at 8:32 AM, H. Peter Anvin wrote: >>> Again: Please explain what is bad with this solution. >>> I cannot see a better and more robust way for kdump other than >>> reserving the original reserved memory areas as declared by the BIOS. >> >> It is bad because it creates more complexity than is needed. >> >> The whole point is that what we want is simply to switch type 1 to type >> X, with the sole exceptions being the areas explicitly reserved for the >> kdump kernel. > > Do you prefer to "reserveram" way in attached patch? Hi, Thomas, Can you please check attached reserveram version on your setup? If it is ok, i will put it in for-x86-boot patchset and send it to Peter for v3.9. Thanks Yinghai e820_reserveram_v2.patch Description: Binary data
Re: [v0][PATCH 1/1] powerpc/book3e: disable interrupt after preempt_schedule_irq
On Sun, 2013-01-06 at 18:49 +0800, Tiejun Chen wrote: > In preempt case current arch_local_irq_restore() from > preempt_schedule_irq() may enable hard interrupt but we really > should disable interrupts when we return from the interrupt, > and so that we don't get interrupted after loading SRR0/1. This is an excellent catch, thanks ! Cheers, Ben. > Signed-off-by: Tiejun Chen > --- > arch/powerpc/kernel/entry_64.S | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S > index e9a906c..4e1de34 100644 > --- a/arch/powerpc/kernel/entry_64.S > +++ b/arch/powerpc/kernel/entry_64.S > @@ -662,6 +662,19 @@ resume_kernel: > ld r4,TI_FLAGS(r9) > andi. r0,r4,_TIF_NEED_RESCHED > bne 1b > + > + /* > + * arch_local_irq_restore() from preempt_schedule_irq above may > + * enable hard interrupt but we really should disable interrupts > + * when we return from the interrupt, and so that we don't get > + * interrupted after loading SRR0/1. > + */ > +#ifdef CONFIG_PPC_BOOK3E > + wrteei 0 > +#else > + ld r10,PACAKMSR(r13) /* Get kernel MSR without EE */ > + mtmsrd r10,1 /* Update machine state */ > +#endif /* CONFIG_PPC_BOOK3E */ > #endif /* CONFIG_PREEMPT */ > > .globl fast_exc_return_irq -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/74] ASoC: pcm: allow backend hardware to be freed in pause state
3.5.7.4 -stable review patch. If anyone has any objections, please let me know. -- From: Patrick Lai commit 08b27848da620f206a8b6d80f26184485dd7aa40 upstream. When front-end PCM session is in paused state, back-end PCM session will be put in paused state as well if given front-end PCM session is the only client of given back-end. Then, application closes front-end PCM session, DPCM framework will not allow back-end enters HW_FREE state so back-end will never get shutdown completely. Signed-off-by: Patrick Lai Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Herton Ronaldo Krzesinski --- sound/soc/soc-pcm.c |1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 48fd15b..6f2bad0 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1240,6 +1240,7 @@ static int dpcm_be_dai_hw_free(struct snd_soc_pcm_runtime *fe, int stream) if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PREPARE) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE) && + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP)) continue; -- 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 04/74] ASoC: wm2200: Fix setting dai format in wm2200_set_fmt
3.5.7.4 -stable review patch. If anyone has any objections, please let me know. -- From: Axel Lin commit 2a5f431592343b78896013b055582f94c12a5049 upstream. According to the defines in wm2200.h: /* * R1284 (0x504) - Audio IF 1_5 */ We should not left shift 1 bit for fmt_val when setting dai format. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Herton Ronaldo Krzesinski --- sound/soc/codecs/wm2200.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm2200.c b/sound/soc/codecs/wm2200.c index c8bff6d..201fc58 100644 --- a/sound/soc/codecs/wm2200.c +++ b/sound/soc/codecs/wm2200.c @@ -1440,7 +1440,7 @@ static int wm2200_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) WM2200_AIF1TX_LRCLK_MSTR | WM2200_AIF1TX_LRCLK_INV, lrclk); snd_soc_update_bits(codec, WM2200_AUDIO_IF_1_5, - WM2200_AIF1_FMT_MASK << 1, fmt_val << 1); + WM2200_AIF1_FMT_MASK, fmt_val); return 0; } -- 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 v4 2/8] input: ti_am335x_tsc: Order of TSC wires, made configurable
From: "Patil, Rachna"
The current driver expected touchscreen input
wires(XP,XN,YP,YN) to be connected in a particular order.
Making changes to accept this as platform data.
Signed-off-by: Patil, Rachna
---
drivers/input/touchscreen/ti_am335x_tsc.c | 156 ++---
include/linux/input/ti_am335x_tsc.h | 12 +++
include/linux/mfd/ti_am335x_tscadc.h | 10 +-
3 files changed, 159 insertions(+), 19 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index da652e0..0c460f9 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -33,6 +33,17 @@
#define SEQ_SETTLE 275
#define MAX_12BIT ((1 << 12) - 1)
+/*
+ * Refer to function regbit_map() to
+ * map the values in the matrix.
+ */
+static int config[4][4] = {
+ {1, 0, 1, 0},
+ {2, 3, 2, 3},
+ {4, 5, 4, 5},
+ {0, 6, 0, 6}
+};
+
struct titsc {
struct input_dev*input;
struct ti_tscadc_dev*mfd_tscadc;
@@ -42,6 +53,9 @@ struct titsc {
unsigned intenable_bits;
boolpen_down;
int steps_to_configure;
+ int config_inp[20];
+ int bit_xp, bit_xn, bit_yp, bit_yn;
+ int inp_xp, inp_xn, inp_yp, inp_yn;
};
static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
@@ -55,6 +69,107 @@ static void titsc_writel(struct titsc *tsc, unsigned int
reg,
writel(val, tsc->mfd_tscadc->tscadc_base + reg);
}
+/*
+ * Each of the analog lines are mapped
+ * with one or two register bits,
+ * which can be either pulled high/low
+ * depending on the value to be read.
+ */
+static int regbit_map(int val)
+{
+ int map_bits = 0;
+
+ switch (val) {
+ case 1:
+ map_bits = XPP;
+ break;
+ case 2:
+ map_bits = XNP;
+ break;
+ case 3:
+ map_bits = XNN;
+ break;
+ case 4:
+ map_bits = YPP;
+ break;
+ case 5:
+ map_bits = YPN;
+ break;
+ case 6:
+ map_bits = YNN;
+ break;
+ }
+
+ return map_bits;
+}
+
+static int titsc_config_wires(struct titsc *ts_dev)
+{
+ int analog_line[10], wire_order[10];
+ int i, temp_bits, err;
+
+ for (i = 0; i < 4; i++) {
+ /*
+* Get the order in which TSC wires are attached
+* w.r.t. each of the analog input lines on the EVM.
+*/
+ analog_line[i] = ts_dev->config_inp[i] & 0xF0;
+ analog_line[i] = analog_line[i] >> 4;
+
+ wire_order[i] = ts_dev->config_inp[i] & 0x0F;
+ }
+
+ for (i = 0; i < 4; i++) {
+ switch (wire_order[i]) {
+ case 0:
+ temp_bits = config[analog_line[i]][0];
+ if (temp_bits == 0) {
+ err = -EINVAL;
+ goto ret;
+ } else {
+ ts_dev->bit_xp = regbit_map(temp_bits);
+ ts_dev->inp_xp = analog_line[i];
+ break;
+ }
+ case 1:
+ temp_bits = config[analog_line[i]][1];
+ if (temp_bits == 0) {
+ err = -EINVAL;
+ goto ret;
+ } else {
+ ts_dev->bit_xn = regbit_map(temp_bits);
+ ts_dev->inp_xn = analog_line[i];
+ break;
+ }
+ case 2:
+ temp_bits = config[analog_line[i]][2];
+ if (temp_bits == 0) {
+ err = -EINVAL;
+ goto ret;
+ } else {
+ ts_dev->bit_yp = regbit_map(temp_bits);
+ ts_dev->inp_yp = analog_line[i];
+ break;
+ }
+ case 3:
+ temp_bits = config[analog_line[i]][3];
+ if (temp_bits == 0) {
+ err = -EINVAL;
+ goto ret;
+ } else {
+ ts_dev->bit_yn = regbit_map(temp_bits);
+ ts_dev->inp_yn = analog_line[i];
+ break;
+ }
+ }
+ }
+
+ return 0;
+
+ret:
+ return err;
+}
[PATCH v4 3/8] input: touchscreen: ti_tsc: remove unwanted fifo flush
From: "Patil, Rachna"
When touchscreen and ADC are used together, this
unwanted fifo flush leads to loss of ADC data.
Signed-off-by: Patil, Rachna
---
drivers/input/touchscreen/ti_am335x_tsc.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 0c460f9..064d2b2 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -308,8 +308,6 @@ static irqreturn_t titsc_irq(int irq, void *dev)
unsigned int x = 0, y = 0;
unsigned int z1, z2, z;
unsigned int fsm;
- unsigned int fifo1count, fifo0count;
- int i;
status = titsc_readl(ts_dev, REG_IRQSTATUS);
if (status & IRQENB_FIFO0THRES) {
@@ -318,14 +316,6 @@ static irqreturn_t titsc_irq(int irq, void *dev)
z1 = titsc_readl(ts_dev, REG_FIFO0) & 0xfff;
z2 = titsc_readl(ts_dev, REG_FIFO1) & 0xfff;
- fifo1count = titsc_readl(ts_dev, REG_FIFO1CNT);
- for (i = 0; i < fifo1count; i++)
- titsc_readl(ts_dev, REG_FIFO1);
-
- fifo0count = titsc_readl(ts_dev, REG_FIFO0CNT);
- for (i = 0; i < fifo0count; i++)
- titsc_readl(ts_dev, REG_FIFO0);
-
if (ts_dev->pen_down && z1 != 0 && z2 != 0) {
/*
* Calculate pressure using formula
--
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 v4 7/8] IIO: ti_am335x_adc: Add DT support
From: "Patil, Rachna"
Add DT support for client ADC driver.
Signed-off-by: Patil, Rachna
---
Changes in v4:
Non-standard properties prefixed with vendor name.
drivers/iio/adc/ti_am335x_adc.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index cd030e1..8e7b089 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -141,11 +143,12 @@ static int tiadc_probe(struct platform_device *pdev)
struct iio_dev *indio_dev;
struct tiadc_device *adc_dev;
struct ti_tscadc_dev*tscadc_dev = pdev->dev.platform_data;
- struct mfd_tscadc_board *pdata;
+ struct mfd_tscadc_board *pdata = tscadc_dev->dev->platform_data;
+ struct device_node *node = tscadc_dev->dev->of_node;
int err;
+ u32 val32;
- pdata = tscadc_dev->dev->platform_data;
- if (!pdata || !pdata->adc_init) {
+ if (!pdata && !node) {
dev_err(&pdev->dev, "Could not find platform data\n");
return -EINVAL;
}
@@ -159,7 +162,22 @@ static int tiadc_probe(struct platform_device *pdev)
adc_dev = iio_priv(indio_dev);
adc_dev->mfd_tscadc = tscadc_dev;
- adc_dev->channels = pdata->adc_init->adc_channels;
+
+ if (pdata)
+ adc_dev->channels = pdata->adc_init->adc_channels;
+ else {
+ node = of_find_node_by_name(node, "adc");
+ if (!node)
+ return -EINVAL;
+ else {
+ err = of_property_read_u32(node,
+ "ti,adc-channels", &val32);
+ if (err < 0)
+ goto err_free_device;
+ else
+ adc_dev->channels = val32;
+ }
+ }
indio_dev->dev.parent = &pdev->dev;
indio_dev->name = dev_name(&pdev->dev);
--
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 v4 0/8] MFD: ti_am335x_tscadc: DT support and TSC features addition
From: "Patil, Rachna" This patch set is a cumulative set of [1] and [2] sent earlier. Note that there are no code changes in either of the patch set, only rebased on top of Linus's v3.8-rc3 tag to make sure that all the patches apply without any conflicts. This patch set has been tested on AM335x EVM. [1] http://www.spinics.net/lists/linux-input/msg23060.html [2] http://www.spinics.net/lists/linux-input/msg23090.html Changes in v4: Subnodes and their properties documentation added. Non-standard properties prefixed with vendor name. Changes in v3: No code change. Changes in v2: Patch "input: ti_am335x_tsc: Add variance filter" from v1 has been dropped. Add MFD device DT node in AM335x EVM. Patil, Rachna (8): input: ti_am335x_tsc: Step enable bits made configurable input: ti_am335x_tsc: Order of TSC wires, made configurable input: touchscreen: ti_tsc: remove unwanted fifo flush MFD: ti_am335x_tscadc: add device tree binding information MFD: ti_am335x_tscadc: Add DT support input: ti_am335x_tsc: Add DT support IIO: ti_am335x_adc: Add DT support arm/dts: AM335x-evm: Add TSC/ADC MFD device support .../devicetree/bindings/mfd/ti_am335x_tscadc.txt | 52 arch/arm/boot/dts/am335x-evm.dts | 13 + arch/arm/boot/dts/am33xx.dtsi |8 + drivers/iio/adc/ti_am335x_adc.c| 26 +- drivers/input/touchscreen/ti_am335x_tsc.c | 266 +--- drivers/mfd/ti_am335x_tscadc.c | 28 ++- include/linux/input/ti_am335x_tsc.h| 12 + include/linux/mfd/ti_am335x_tscadc.h | 11 +- 8 files changed, 364 insertions(+), 52 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt -- 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 v4 6/8] input: ti_am335x_tsc: Add DT support
From: "Patil, Rachna"
Add DT support for client touchscreen driver
Signed-off-by: Patil, Rachna
---
Changes in v4:
Non-standard properties prefixed with vendor name.
drivers/input/touchscreen/ti_am335x_tsc.c | 94 +
1 file changed, 81 insertions(+), 13 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 064d2b2..6ff5a76 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -366,6 +368,74 @@ static irqreturn_t titsc_irq(int irq, void *dev)
return IRQ_HANDLED;
}
+static int titsc_parse_dt(struct ti_tscadc_dev *tscadc_dev,
+ struct titsc *ts_dev)
+{
+ struct device_node *node = tscadc_dev->dev->of_node;
+ int err, i;
+ u32 val32, wires_conf[4];
+
+ if (!node)
+ return -EINVAL;
+ else {
+ node = of_find_node_by_name(node, "tsc");
+ if (!node)
+ return -EINVAL;
+ else {
+ err = of_property_read_u32(node, "ti,wires", &val32);
+ if (err < 0)
+ goto error_ret;
+ else
+ ts_dev->wires = val32;
+
+ err = of_property_read_u32(node,
+ "ti,x-plate-resistance", &val32);
+ if (err < 0)
+ goto error_ret;
+ else
+ ts_dev->x_plate_resistance = val32;
+
+ err = of_property_read_u32(node,
+ "ti,steps-to-configure", &val32);
+ if (err < 0)
+ goto error_ret;
+ else
+ ts_dev->steps_to_configure = val32;
+
+ err = of_property_read_u32_array(node, "ti,wire-config",
+ wires_conf, ARRAY_SIZE(wires_conf));
+ if (err < 0)
+ goto error_ret;
+ else {
+ for (i = 0; i < ARRAY_SIZE(wires_conf); i++)
+ ts_dev->config_inp[i] = wires_conf[i];
+ }
+ }
+ }
+ return 0;
+
+error_ret:
+ return err;
+}
+
+static int titsc_parse_pdata(struct ti_tscadc_dev *tscadc_dev,
+ struct titsc *ts_dev)
+{
+ struct mfd_tscadc_board *pdata = tscadc_dev->dev->platform_data;
+
+ if (!pdata)
+ return -EINVAL;
+
+ ts_dev->wires = pdata->tsc_init->wires;
+ ts_dev->x_plate_resistance =
+ pdata->tsc_init->x_plate_resistance;
+ ts_dev->steps_to_configure =
+ pdata->tsc_init->steps_to_configure;
+ memcpy(ts_dev->config_inp, pdata->tsc_init->wire_config,
+ sizeof(pdata->tsc_init->wire_config));
+ return 0;
+}
+
/*
* The functions for inserting/removing driver as a module.
*/
@@ -375,16 +445,8 @@ static int titsc_probe(struct platform_device *pdev)
struct titsc *ts_dev;
struct input_dev *input_dev;
struct ti_tscadc_dev *tscadc_dev = pdev->dev.platform_data;
- struct mfd_tscadc_board *pdata;
int err;
- pdata = tscadc_dev->dev->platform_data;
-
- if (!pdata) {
- dev_err(&pdev->dev, "Could not find platform data\n");
- return -EINVAL;
- }
-
/* Allocate memory for device */
ts_dev = kzalloc(sizeof(struct titsc), GFP_KERNEL);
input_dev = input_allocate_device();
@@ -398,11 +460,17 @@ static int titsc_probe(struct platform_device *pdev)
ts_dev->mfd_tscadc = tscadc_dev;
ts_dev->input = input_dev;
ts_dev->irq = tscadc_dev->irq;
- ts_dev->wires = pdata->tsc_init->wires;
- ts_dev->x_plate_resistance = pdata->tsc_init->x_plate_resistance;
- ts_dev->steps_to_configure = pdata->tsc_init->steps_to_configure;
- memcpy(ts_dev->config_inp, pdata->tsc_init->wire_config,
- sizeof(pdata->tsc_init->wire_config));
+
+ if (tscadc_dev->dev->platform_data)
+ err = titsc_parse_pdata(tscadc_dev, ts_dev);
+ else
+ err = titsc_parse_dt(tscadc_dev, ts_dev);
+
+ if (err) {
+ dev_err(&pdev->dev, "Could not find platform data\n");
+ err = -EINVAL;
+ goto err_free_mem;
+ }
err = request_irq(ts_dev->irq, titsc_irq,
0, pdev->dev.driver->name, ts_dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo
[PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support
From: "Patil, Rachna"
Make changes to add DT support in the MFD core driver.
Signed-off-by: Patil, Rachna
---
Changes in v4:
Non-standard properties prefixed with vendor name.
drivers/mfd/ti_am335x_tscadc.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index e9f3fb5..87b446b 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -64,20 +66,31 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
struct resource *res;
struct clk *clk;
struct mfd_tscadc_board *pdata = pdev->dev.platform_data;
+ struct device_node *node = pdev->dev.of_node;
struct mfd_cell *cell;
int err, ctrl;
int clk_value, clock_rate;
- int tsc_wires, adc_channels = 0, total_channels;
+ int tsc_wires = 0, adc_channels = 0, total_channels;
- if (!pdata) {
+ if (!pdata && !pdev->dev.of_node) {
dev_err(&pdev->dev, "Could not find platform data\n");
return -EINVAL;
}
- if (pdata->adc_init)
- adc_channels = pdata->adc_init->adc_channels;
+ if (pdev->dev.platform_data) {
+ if (pdata->tsc_init)
+ tsc_wires = pdata->tsc_init->wires;
+
+ if (pdata->adc_init)
+ adc_channels = pdata->adc_init->adc_channels;
+ } else {
+ node = of_find_node_by_name(pdev->dev.of_node, "tsc");
+ of_property_read_u32(node, "ti,wires", &tsc_wires);
+
+ node = of_find_node_by_name(pdev->dev.of_node, "adc");
+ of_property_read_u32(node, "ti,adc-channels", &adc_channels);
+ }
- tsc_wires = pdata->tsc_init->wires;
total_channels = tsc_wires + adc_channels;
if (total_channels > 8) {
@@ -256,11 +269,16 @@ static const struct dev_pm_ops tscadc_pm_ops = {
#define TSCADC_PM_OPS NULL
#endif
+static const struct of_device_id ti_tscadc_dt_ids[] = {
+ { .compatible = "ti,ti-tscadc", },
+};
+
static struct platform_driver ti_tscadc_driver = {
.driver = {
.name = "ti_tscadc",
.owner = THIS_MODULE,
.pm = TSCADC_PM_OPS,
+ .of_match_table = of_match_ptr(ti_tscadc_dt_ids),
},
.probe = ti_tscadc_probe,
.remove = ti_tscadc_remove,
--
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 v4 8/8] arm/dts: AM335x-evm: Add TSC/ADC MFD device support
From: "Patil, Rachna"
Add support for core multifunctional device along
with its clients touchscreen and ADC.
Signed-off-by: Patil, Rachna
---
Changes in v4:
Non-standard properties prefixed with vendor name.
arch/arm/boot/dts/am335x-evm.dts | 13 +
arch/arm/boot/dts/am33xx.dtsi|8
2 files changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d649644..bfd7928 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -244,3 +244,16 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&tscadc {
+ tsc {
+ ti,wires = <4>;
+ ti,x-plate-resistance = <200>;
+ ti,steps-to-configure = <5>;
+ ti,wire-config = <0x00 0x11 0x22 0x33>;
+ };
+
+ adc {
+ ti,adc-channels = <4>;
+ };
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..211ec42 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -385,5 +385,13 @@
mac-address = [ 00 00 00 00 00 00 ];
};
};
+
+ tscadc: tscadc@44e0d000 {
+ compatible = "ti,ti-tscadc";
+ reg = <0x44e0d000 0x1000>;
+ interrupt-parent = <&intc>;
+ interrupts = <16>;
+ ti,hwmods = "adc_tsc";
+ };
};
};
--
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 v4 4/8] MFD: ti_am335x_tscadc: add device tree binding information
From: "Patil, Rachna"
Signed-off-by: Patil, Rachna
---
Changes in v4:
Subnodes and their properties documentation added.
Non-standard properties prefixed with vendor name.
.../devicetree/bindings/mfd/ti_am335x_tscadc.txt | 52
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
diff --git a/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
new file mode 100644
index 000..0100771
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
@@ -0,0 +1,52 @@
+Texas Instruments - TSC / ADC multi-functional device
+
+ti_tscadc is a multi-function device with touchscreen and ADC on chip.
+This document describes the binding for mfd device.
+
+Required properties:
+- compatible: "ti,ti-tscadc"
+- reg: Specifies the address of MFD block
+- interrupts: IRQ line connected to the main SoC
+- interrupt-parent: The parent interrupt controller
+
+Optional properties:
+- ti,hwmods: Hardware information related to TSC/ADC MFD device
+
+Sub-nodes:
+Device Description
+-- ---
+tscTouchscreen
+adcAnalog to digital converter
+
+Sub-node device required properties:
+tsc:
+- ti,wires: 4/5/8 wire touchscreen support on the platform.
+- ti,x-plate-resistance: X plate resistance.
+- ti,steps-to-configure: A step is configured to read a single co-ordinate
value,
+ can be applied more number of times for better results.
+- ti,wire-config: Order for connecting wires on touchscreen.
+
+adc:
+- ti,adc-channels: Number of ADC channels used.
+
+Example:
+
+ tscadc: tscadc@44e0d000 {
+ compatible = "ti,ti-tscadc";
+ reg = <0x44e0d000 0x1000>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <16>;
+ ti,hwmods = "adc_tsc";
+
+ tsc {
+ ti,wires = <4>;
+ ti,x-plate-resistance = <200>;
+ ti,steps-to-configure = <5>;
+ ti,wire-config = <0x00 0x11 0x22 0x33>;
+ };
+
+ adc {
+ ti,adc-channels = <4>;
+ };
+ };
--
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 v4 1/8] input: ti_am335x_tsc: Step enable bits made configurable
From: "Patil, Rachna"
Current code has hard coded value written to
step enable bits. Now the bits are updated based
on how many steps are needed to be configured got
from platform data.
The user needs to take care not to exceed
the count more than 16. While using ADC and TSC
one should take care to set this parameter correctly.
Signed-off-by: Patil, Rachna
---
drivers/input/touchscreen/ti_am335x_tsc.c | 10 --
include/linux/mfd/ti_am335x_tscadc.h |1 -
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 51e7b87..da652e0 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -39,6 +39,7 @@ struct titsc {
unsigned intirq;
unsigned intwires;
unsigned intx_plate_resistance;
+ unsigned intenable_bits;
boolpen_down;
int steps_to_configure;
};
@@ -57,6 +58,7 @@ static void titsc_writel(struct titsc *tsc, unsigned int reg,
static void titsc_step_config(struct titsc *ts_dev)
{
unsigned intconfig;
+ unsigned intstepenable = 0;
int i, total_steps;
/* Configure the Step registers */
@@ -128,7 +130,11 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(total_steps + 2),
STEPCONFIG_OPENDLY);
- titsc_writel(ts_dev, REG_SE, STPENB_STEPENB_TC);
+ for (i = 0; i <= (total_steps + 2); i++)
+ stepenable |= 1 << i;
+ ts_dev->enable_bits = stepenable;
+
+ titsc_writel(ts_dev, REG_SE, ts_dev->enable_bits);
}
static void titsc_read_coordinates(struct titsc *ts_dev,
@@ -250,7 +256,7 @@ static irqreturn_t titsc_irq(int irq, void *dev)
titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
- titsc_writel(ts_dev, REG_SE, STPENB_STEPENB_TC);
+ titsc_writel(ts_dev, REG_SE, ts_dev->enable_bits);
return IRQ_HANDLED;
}
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index c79ad5d..23e4f33 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -47,7 +47,6 @@
#define STEPENB_MASK (0x1 << 0)
#define STEPENB(val) ((val) << 0)
#define STPENB_STEPENB STEPENB(0x1)
-#define STPENB_STEPENB_TC STEPENB(0x1FFF)
/* IRQ enable */
#define IRQENB_HW_PEN BIT(0)
--
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 06/74] mac80211: use del_timer_sync for final sta cleanup timer deletion
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Johannes Berg
commit a56f992cdabc63f56b4b142885deebebf936ff76 upstream.
This is a very old bug, but there's nothing that prevents the
timer from running while the module is being removed when we
only do del_timer() instead of del_timer_sync().
The timer should normally not be running at this point, but
it's not clearly impossible (or we could just remove this.)
Tested-by: Ben Greear
Signed-off-by: Johannes Berg
Signed-off-by: Herton Ronaldo Krzesinski
---
net/mac80211/sta_info.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 6c74f1e..fec8eab 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -844,7 +844,7 @@ void sta_info_init(struct ieee80211_local *local)
void sta_info_stop(struct ieee80211_local *local)
{
- del_timer(&local->sta_cleanup);
+ del_timer_sync(&local->sta_cleanup);
sta_info_flush(local, NULL);
}
--
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 10/74] USB: Ignore xHCI Reset Device status.
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Sarah Sharp
commit 8b8132bc3d1cc3d4c0687e4d638a482fa920d98a upstream.
When the USB core finishes reseting a USB device, the xHCI driver sends
a Reset Device command to the host. The xHC then updates its internal
representation of the USB device to the 'Default' device state. If the
device was already in the Default state, the xHC will complete the
command with an error status.
If a device needs to be reset several times during enumeration, the
second reset will always fail because of the xHCI Reset Device command.
This can cause issues during enumeration.
For example, usb_reset_and_verify_device calls into hub_port_init in a
loop. Say that on the first call into hub_port_init, the device is
successfully reset, but doesn't respond to several set address control
transfers. Then the port will be disabled, but the udev will remain in
tact. usb_reset_and_verify_device will call into hub_port_init again.
On the second call into hub_port_init, the device will be reset, and the
xHCI driver will issue a Reset Device command. This command will fail
(because the device is already in the Default state), and
usb_reset_and_verify_device will fail. The port will be disabled, and
the device won't be able to enumerate.
Fix this by ignoring the return value of the HCD reset_device callback.
This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp
Acked-by: Alan Stern
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/usb/core/hub.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 931eea2..03af701 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2456,14 +2456,11 @@ static void hub_port_finish_reset(struct usb_hub *hub,
int port1,
msleep(10 + 40);
update_devnum(udev, 0);
hcd = bus_to_hcd(udev->bus);
- if (hcd->driver->reset_device) {
- *status = hcd->driver->reset_device(hcd, udev);
- if (*status < 0) {
- dev_err(&udev->dev, "Cannot reset "
- "HCD device state\n");
- break;
- }
- }
+ /* The xHC may think the device is already reset,
+* so ignore the status.
+*/
+ if (hcd->driver->reset_device)
+ hcd->driver->reset_device(hcd, udev);
}
/* FALL THROUGH */
case -ENOTCONN:
--
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 11/74] USB: Allow USB 3.0 ports to be disabled.
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Sarah Sharp
commit 41e7e056cdc662f704fa9262e5c6e213b4ab45dd upstream.
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.
The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes. We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect. However,
external USB 3.0 hubs don't need this code. They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set. Therefore it doesn't make sense to
put this code in the USB core.
This patch is part of a series to fix several reports of infinite loops
on device enumeration failure. This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller. The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp
Acked-by: Alan Stern
Reported-by: John Covici
[ herton: adjust context ]
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/usb/core/hub.c | 63 +--
drivers/usb/host/xhci-hub.c | 31 +++--
2 files changed, 90 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 03af701..ba01327 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -866,6 +866,60 @@ static int hub_hub_status(struct usb_hub *hub,
return ret;
}
+static int hub_set_port_link_state(struct usb_hub *hub, int port1,
+ unsigned int link_status)
+{
+ return set_port_feature(hub->hdev,
+ port1 | (link_status << 3),
+ USB_PORT_FEAT_LINK_STATE);
+}
+
+/*
+ * If USB 3.0 ports are placed into the Disabled state, they will no longer
+ * detect any device connects or disconnects. This is generally not what the
+ * USB core wants, since it expects a disabled port to produce a port status
+ * change event when a new device connects.
+ *
+ * Instead, set the link state to Disabled, wait for the link to settle into
+ * that state, clear any change bits, and then put the port into the RxDetect
+ * state.
+ */
+static int hub_usb3_port_disable(struct usb_hub *hub, int port1)
+{
+ int ret;
+ int total_time;
+ u16 portchange, portstatus;
+
+ if (!hub_is_superspeed(hub->hdev))
+ return -EINVAL;
+
+ ret = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_SS_DISABLED);
+ if (ret) {
+ dev_err(hub->intfdev, "cannot disable port %d (err = %d)\n",
+ port1, ret);
+ return ret;
+ }
+
+ /* Wait for the link to enter the disabled state. */
+ for (total_time = 0; ; total_time += HUB_DEBOUNCE_STEP) {
+ ret = hub_port_status(hub, port1, &portstatus, &portchange);
+ if (ret < 0)
+ return ret;
+
+ if ((portstatus & USB_PORT_STAT_LINK_STATE) ==
+ USB_SS_PORT_LS_SS_DISABLED)
+ break;
+ if (total_time >= HUB_DEBOUNCE_TIMEOUT)
+ break;
+ msleep(HUB_DEBOUNCE_STEP);
+ }
+ if (total_time >= HUB_DEBOUNCE_TIMEOUT)
+ dev_warn(hub->intfdev, "Could not disable port %d after %d
ms\n",
+ port1, total_time);
+
+ return hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_RX_DETECT);
+}
+
static int hub_port_disable(struct usb_hub *hub, int port1, int set_state)
{
struct usb_device *hdev = hub->hdev;
@@ -874,8 +928,13 @@ static int hub_port_disable(struct usb_hub *hub, int
port1, int set_state)
if (hdev->children[port1-1] && set_state)
usb_set_device_state(hdev->children[port1-1],
USB_STATE_NOTATTACHED);
- if (!hub->error && !hub_is_superspeed(hub->hdev))
- ret = clear_port_feature(hdev, port1, USB_PORT_FEAT_ENABLE);
+ if (!hub->error) {
+ if (hub_is_superspeed(hub->hdev))
+ ret = hub_usb3_port_disable(hub, port1);
+ else
+
[PATCH 12/74] USB: Increase reset timeout.
3.5.7.4 -stable review patch. If anyone has any objections, please let me know. -- From: Sarah Sharp commit 77c7f072c87fa951e9a74805febf26466f31170c upstream. John's NEC 0.96 xHCI host controller needs a longer timeout for a warm reset to complete. The logs show it takes 650ms to complete the warm reset, so extend the hub reset timeout to 800ms to be on the safe side. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic". Signed-off-by: Sarah Sharp Acked-by: Alan Stern Reported-by: John Covici Signed-off-by: Herton Ronaldo Krzesinski --- drivers/usb/core/hub.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index ba01327..0b408c6 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -2390,7 +2390,7 @@ static unsigned hub_is_wusb(struct usb_hub *hub) #define HUB_SHORT_RESET_TIME 10 #define HUB_BH_RESET_TIME 50 #define HUB_LONG_RESET_TIME200 -#define HUB_RESET_TIMEOUT 500 +#define HUB_RESET_TIMEOUT 800 static int hub_port_reset(struct usb_hub *hub, int port1, struct usb_device *udev, unsigned int delay, bool warm); -- 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 01/74] usb: gadget: dummy: fix enumeration with g_multi
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
commit 1d16638e3b9cc195bac18a8fcbca748f33c1bc24 upstream.
If we do have endpoints named like "ep-a" then bEndpointAddress is
counted internally by the gadget framework.
If we do have endpoints named like "ep-1" then bEndpointAddress is
assigned from the digit after "ep-".
If we do have both, then it is likely that after we used up the
"generic" endpoints we will use the digits and thus assign one
bEndpointAddress to multiple endpoints.
This theory can be proofed by using the completely enabled g_multi.
Without this patch, the mass storage won't enumerate and times out
because it shares endpoints with RNDIS.
This patch also adds fills up the endpoints list so we have in total
endpoints 1 to 15 in + out available while some of them are restricted
to certain types like BULK or ISO. Without this change the nokia gadget
won't load because the system does not provide enough (BULK) endpoints
but it did before ep-a - ep-f were removed.
Signed-off-by: Sebastian Andrzej Siewior
Acked-by: Alan Stern
Signed-off-by: Felipe Balbi
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/usb/gadget/dummy_hcd.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index afdbb1c..4ad1f1c 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -126,10 +126,7 @@ static const char ep0name[] = "ep0";
static const char *const ep_name[] = {
ep0name,/* everyone has ep0 */
- /* act like a net2280: high speed, six configurable endpoints */
- "ep-a", "ep-b", "ep-c", "ep-d", "ep-e", "ep-f",
-
- /* or like pxa250: fifteen fixed function endpoints */
+ /* act like a pxa250: fifteen fixed function endpoints */
"ep1in-bulk", "ep2out-bulk", "ep3in-iso", "ep4out-iso", "ep5in-int",
"ep6in-bulk", "ep7out-bulk", "ep8in-iso", "ep9out-iso", "ep10in-int",
"ep11in-bulk", "ep12out-bulk", "ep13in-iso", "ep14out-iso",
@@ -137,6 +134,10 @@ static const char *const ep_name[] = {
/* or like sa1100: two fixed function endpoints */
"ep1out-bulk", "ep2in-bulk",
+
+ /* and now some generic EPs so we have enough in multi config */
+ "ep3out", "ep4in", "ep5out", "ep6out", "ep7in", "ep8out", "ep9in",
+ "ep10out", "ep11out", "ep12in", "ep13out", "ep14in", "ep15out",
};
#define DUMMY_ENDPOINTSARRAY_SIZE(ep_name)
--
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 14/74] USB: Handle warm reset failure on empty port.
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Sarah Sharp
commit 65bdac5effd15d6af619b3b7218627ef4d84ed6a upstream.
An empty port can transition to either Inactive or Compliance Mode if a
newly connected USB 3.0 device fails to link train. In that case, we
issue a warm reset. Some devices, such as John's Roseweil eusb3
enclosure, slip back into Compliance Mode after the warm reset.
The current warm reset code does not check for device connect status on
warm reset completion, and it incorrectly reports the warm reset
succeeded. This causes the USB core to attempt to send a Set Address
control transfer to a port in Compliance Mode, which will always fail.
Make hub_port_wait_reset check the current connect status and link state
after the warm reset completes. Return a failure status if the device
is disconnected or the link state is Compliance Mode or SS.Inactive.
Make hub_events disable the port if warm reset fails. This will disable
the port, and then bring it back into the RxDetect state. Make the USB
core ignore the connect change until the device reconnects.
Note that this patch does NOT handle connected devices slipping into the
Inactive state very well. This is a concern, because devices can go
into the Inactive state on U1/U2 exit failure. However, the fix for
that case is too large for stable, so it will be submitted in a separate
patch.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp
Acked-by: Alan Stern
Reported-by: John Covici
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/usb/core/hub.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 89fc61b..2532bdc 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2488,6 +2488,11 @@ static int hub_port_wait_reset(struct usb_hub *hub, int
port1,
return 0;
}
} else {
+ if (!(portstatus & USB_PORT_STAT_CONNECTION) ||
+ hub_port_warm_reset_required(hub,
+ portstatus))
+ return -ENOTCONN;
+
return 0;
}
@@ -4492,9 +4497,14 @@ static void hub_events(void)
* SS.Inactive state.
*/
if (hub_port_warm_reset_required(hub, portstatus)) {
+ int status;
+
dev_dbg(hub_dev, "warm reset port %d\n", i);
- hub_port_reset(hub, i, NULL,
+ status = hub_port_reset(hub, i, NULL,
HUB_BH_RESET_TIME, true);
+ if (status < 0)
+ hub_port_disable(hub, i, 1);
+ connect_change = 0;
}
if (connect_change)
--
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 07/74] mac80211: fix dtim_period in hidden SSID AP association
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Johannes Berg
commit 826262c3d23743cb032a9e1a65a0f9be75091a5e upstream.
When AP's SSID is hidden the BSS can appear several times in
cfg80211's BSS list: once with a zero-length SSID that comes
from the beacon, and once for each SSID from probe reponses.
Since the mac80211 stores its data in ieee80211_bss which
is embedded into cfg80211_bss, mac80211's data will be
duplicated too.
This becomes a problem when a driver needs the dtim_period
since this data exists only in the beacon's instance in
cfg80211 bss table which isn't the instance that is used
when associating.
Remove the DTIM period from the BSS table and track it
explicitly to avoid this problem.
Tested-by: Efi Tubul
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
[ herton: adjust context, no RCU locking (use same backport as the one
for 3.7), keep printk usage instead of non-existent sdata_info in 3.5 ]
Signed-off-by: Herton Ronaldo Krzesinski
---
net/mac80211/ieee80211_i.h |5 +--
net/mac80211/mlme.c| 73 +++-
net/mac80211/scan.c| 13
3 files changed, 53 insertions(+), 38 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index d0b1c56..16655d6 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -81,8 +81,6 @@ struct ieee80211_bss {
size_t ssid_len;
u8 ssid[IEEE80211_MAX_SSID_LEN];
- u8 dtim_period;
-
bool wmm_used;
bool uapsd_supported;
@@ -129,7 +127,6 @@ enum ieee80211_bss_corrupt_data_flags {
/**
* enum ieee80211_valid_data_flags - BSS valid data flags
- * @IEEE80211_BSS_VALID_DTIM: DTIM data was gathered from non-corrupt IE
* @IEEE80211_BSS_VALID_WMM: WMM/UAPSD data was gathered from non-corrupt IE
* @IEEE80211_BSS_VALID_RATES: Supported rates were gathered from non-corrupt
IE
* @IEEE80211_BSS_VALID_ERP: ERP flag was gathered from non-corrupt IE
@@ -140,7 +137,6 @@ enum ieee80211_bss_corrupt_data_flags {
* beacon/probe response.
*/
enum ieee80211_bss_valid_data_flags {
- IEEE80211_BSS_VALID_DTIM= BIT(0),
IEEE80211_BSS_VALID_WMM = BIT(1),
IEEE80211_BSS_VALID_RATES = BIT(2),
IEEE80211_BSS_VALID_ERP = BIT(3)
@@ -444,6 +440,7 @@ struct ieee80211_if_managed {
unsigned long timers_running; /* used for quiesce/restart */
bool powersave; /* powersave requested for this iface */
bool broken_ap; /* AP is broken -- turn off powersave */
+ u8 dtim_period;
enum ieee80211_smps_mode req_smps, /* requested smps mode */
ap_smps, /* smps mode AP thinks we're in */
driver_smps_mode; /* smps mode request */
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 6d79367..4549e7e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -994,12 +994,8 @@ void ieee80211_recalc_ps(struct ieee80211_local *local,
s32 latency)
if (beaconint_us > latency) {
local->ps_sdata = NULL;
} else {
- struct ieee80211_bss *bss;
int maxslp = 1;
- u8 dtimper;
-
- bss = (void *)found->u.mgd.associated->priv;
- dtimper = bss->dtim_period;
+ u8 dtimper = found->u.mgd.dtim_period;
/* If the TIM IE is invalid, pretend the value is 1 */
if (!dtimper)
@@ -1305,10 +1301,17 @@ static void ieee80211_set_associated(struct
ieee80211_sub_if_data *sdata,
ieee80211_led_assoc(local, 1);
- if (local->hw.flags & IEEE80211_HW_NEED_DTIM_PERIOD)
- bss_conf->dtim_period = bss->dtim_period;
- else
+ if (local->hw.flags & IEEE80211_HW_NEED_DTIM_PERIOD) {
+ /*
+* If the AP is buggy we may get here with no DTIM period
+* known, so assume it's 1 which is the only safe assumption
+* in that case, although if the TIM IE is broken powersave
+* probably just won't work at all.
+*/
+ bss_conf->dtim_period = sdata->u.mgd.dtim_period ?: 1;
+ } else {
bss_conf->dtim_period = 0;
+ }
bss_conf->assoc = 1;
@@ -1441,6 +1444,8 @@ static void ieee80211_set_disassoc(struct
ieee80211_sub_if_data *sdata,
del_timer_sync(&sdata->u.mgd.bcn_mon_timer);
del_timer_sync(&sdata->u.mgd.timer);
del_timer_sync(&sdata->u.mgd.chswitch_timer);
+
+ sdata->vif.bss_conf.dtim_period = 0;
}
void ieee80211_sta_rx_notify(struct ieee80211_sub_if_data *sdata,
@@ -2205,11 +2210,18 @@ static void ieee80211_rx_bss_info(struct
ieee80211_sub_if_data *sdata,
struct
Re: [PATCH 1/1] mfd: wm8994: Use devm_regulator_bulk_get API
Hi Samuel, On 8 January 2013 16:06, Mark Brown wrote: > On Tue, Jan 08, 2013 at 02:01:22PM +0530, Sachin Kamat wrote: >> devm_regulator_bulk_get is device managed and saves some cleanup >> and exit code. > > Acked-by: Mark Brown Would you be picking this patch up? -- 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 19/74] ASoC: wm2000: Fix sense of speech clarity enable
3.5.7.4 -stable review patch. If anyone has any objections, please let me know. -- From: Mark Brown commit 267f8fa2e1eef0612b2007e1f1846bcbc35cc1fa upstream. Signed-off-by: Mark Brown Signed-off-by: Herton Ronaldo Krzesinski --- sound/soc/codecs/wm2000.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm2000.c b/sound/soc/codecs/wm2000.c index 45f2faf..baa9752 100644 --- a/sound/soc/codecs/wm2000.c +++ b/sound/soc/codecs/wm2000.c @@ -188,9 +188,9 @@ static int wm2000_power_up(struct i2c_client *i2c, int analogue) ret = wm2000_read(i2c, WM2000_REG_SPEECH_CLARITY); if (wm2000->speech_clarity) - ret &= ~WM2000_SPEECH_CLARITY; - else ret |= WM2000_SPEECH_CLARITY; + else + ret &= ~WM2000_SPEECH_CLARITY; wm2000_write(i2c, WM2000_REG_SPEECH_CLARITY, ret); wm2000_write(i2c, WM2000_REG_SYS_START0, 0x33); -- 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 20/74] drm/i915; Only increment the user-pin-count after successfully pinning the bo
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
commit 93be8788e648817d62fda33e2998eb6ca6ebf3a3 upstream.
As along the error path we do not correct the user pin-count for the
failure, we may end up with userspace believing that it has a pinned
object at offset 0 (when interrupted by a signal for example).
Signed-off-by: Chris Wilson
Signed-off-by: Daniel Vetter
[ herton: adjust context ]
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/gpu/drm/i915/i915_gem.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4dc8a9b..7605f40 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3125,14 +3125,15 @@ i915_gem_pin_ioctl(struct drm_device *dev, void *data,
goto out;
}
- obj->user_pin_count++;
- obj->pin_filp = file;
- if (obj->user_pin_count == 1) {
+ if (obj->user_pin_count == 0) {
ret = i915_gem_object_pin(obj, args->alignment, true);
if (ret)
goto out;
}
+ obj->user_pin_count++;
+ obj->pin_filp = file;
+
/* XXX - flush the CPU caches for pinned objects
* as the X server doesn't manage domains yet
*/
--
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 22/74] sony-laptop: fix SNC buffer calls when SN06 returns Integers
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Mattia Dongili
commit dcbeec264d73b7228ffdfe767eab69b2353099b1 upstream.
SN06 in some cases returns an Integer instead of a buffer. While the
code handling the return value was trying to cope with the difference,
the memcpy call was not making any difference between the two types of
acpi_object union. This regression was introduced in 3.5.
While there also rework the return value logic to improve readability.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=48671
Cc: Fabrizio Narni
Cc:
Signed-off-by: Mattia Dongili
Signed-off-by: Matthew Garrett
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/platform/x86/sony-laptop.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/x86/sony-laptop.c
b/drivers/platform/x86/sony-laptop.c
index d456ff0..d4a6172 100644
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -784,28 +784,29 @@ static int sony_nc_int_call(acpi_handle handle, char
*name, int *value,
static int sony_nc_buffer_call(acpi_handle handle, char *name, u64 *value,
void *buffer, size_t buflen)
{
+ int ret = 0;
size_t len = len;
union acpi_object *object = __call_snc_method(handle, name, value);
if (!object)
return -EINVAL;
- if (object->type == ACPI_TYPE_BUFFER)
+ if (object->type == ACPI_TYPE_BUFFER) {
len = MIN(buflen, object->buffer.length);
+ memcpy(buffer, object->buffer.pointer, len);
- else if (object->type == ACPI_TYPE_INTEGER)
+ } else if (object->type == ACPI_TYPE_INTEGER) {
len = MIN(buflen, sizeof(object->integer.value));
+ memcpy(buffer, &object->integer.value, len);
- else {
+ } else {
pr_warn("Invalid acpi_object: expected 0x%x got 0x%x\n",
ACPI_TYPE_BUFFER, object->type);
- kfree(object);
- return -EINVAL;
+ ret = -EINVAL;
}
- memcpy(buffer, object->buffer.pointer, len);
kfree(object);
- return 0;
+ return ret;
}
struct sony_nc_handles {
--
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 25/74] staging: speakup: avoid out-of-range access in synth_init()
3.5.7.4 -stable review patch. If anyone has any objections, please let me know. -- From: Nickolai Zeldovich commit ae428655b826f2755a8101b27beda42a275ef8ad upstream. Check that array index is in-bounds before accessing the synths[] array. Signed-off-by: Nickolai Zeldovich Cc: Samuel Thibault Signed-off-by: Greg Kroah-Hartman Signed-off-by: Herton Ronaldo Krzesinski --- drivers/staging/speakup/synth.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/speakup/synth.c b/drivers/staging/speakup/synth.c index 331eae7..217fd4a 100644 --- a/drivers/staging/speakup/synth.c +++ b/drivers/staging/speakup/synth.c @@ -342,7 +342,7 @@ int synth_init(char *synth_name) mutex_lock(&spk_mutex); /* First, check if we already have it loaded. */ - for (i = 0; synths[i] != NULL && i < MAXSYNTHS; i++) + for (i = 0; i < MAXSYNTHS && synths[i] != NULL; i++) if (strcmp(synths[i]->name, synth_name) == 0) synth = synths[i]; -- 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 27/74] staging: comedi: fix minimum AO period for NI 625x and NI 628x
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: =?UTF-8?q?=C3=89ric=20Piel?=
commit 34b55d8c48f4f76044d8f4d6ec3dc786cf210312 upstream.
The minimum period was set to 357 ns, while the divider for these boards is 50
ns. This prevented to output at maximum speed as ni_ao_cmdtest() would return
357 but would not accept it.
Not sure why it was set to 357 ns (this was done before the git history,
which starts 5 years ago). My guess is that it comes from reading the
specification stating a 2.8 MHz rate (~ 357 ns). The latest
specification states a 2.86 MHz rate (~ 350 ns), which makes a lot
more sense.
Tested on a pci-6251.
Signed-off-by: Éric Piel
Acked-By: Ian Abbott
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/staging/comedi/drivers/ni_pcimio.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_pcimio.c
b/drivers/staging/comedi/drivers/ni_pcimio.c
index 3974c0d..fa09fd7 100644
--- a/drivers/staging/comedi/drivers/ni_pcimio.c
+++ b/drivers/staging/comedi/drivers/ni_pcimio.c
@@ -963,7 +963,7 @@ static const struct ni_board_struct ni_boards[] = {
.ao_range_table = &range_ni_M_625x_ao,
.reg_type = ni_reg_625x,
.ao_unipolar = 0,
-.ao_speed = 357,
+.ao_speed = 350,
.num_p0_dio_channels = 8,
.caldac = {caldac_none},
.has_8255 = 0,
@@ -982,7 +982,7 @@ static const struct ni_board_struct ni_boards[] = {
.ao_range_table = &range_ni_M_625x_ao,
.reg_type = ni_reg_625x,
.ao_unipolar = 0,
-.ao_speed = 357,
+.ao_speed = 350,
.num_p0_dio_channels = 8,
.caldac = {caldac_none},
.has_8255 = 0,
@@ -1001,7 +1001,7 @@ static const struct ni_board_struct ni_boards[] = {
.ao_range_table = &range_ni_M_625x_ao,
.reg_type = ni_reg_625x,
.ao_unipolar = 0,
-.ao_speed = 357,
+.ao_speed = 350,
.num_p0_dio_channels = 8,
.caldac = {caldac_none},
.has_8255 = 0,
@@ -1037,7 +1037,7 @@ static const struct ni_board_struct ni_boards[] = {
.ao_range_table = &range_ni_M_625x_ao,
.reg_type = ni_reg_625x,
.ao_unipolar = 0,
-.ao_speed = 357,
+.ao_speed = 350,
.num_p0_dio_channels = 32,
.caldac = {caldac_none},
.has_8255 = 0,
@@ -1056,7 +1056,7 @@ static const struct ni_board_struct ni_boards[] = {
.ao_range_table = &range_ni_M_625x_ao,
.reg_type = ni_reg_625x,
.ao_unipolar = 0,
-.ao_speed = 357,
+.ao_speed = 350,
.num_p0_dio_channels = 32,
.caldac = {caldac_none},
.has_8255 = 0,
@@ -1092,7 +1092,7 @@ static const struct ni_board_struct ni_boards[] = {
.ao_range_table = &range_ni_M_628x_ao,
.reg_type = ni_reg_628x,
.ao_unipolar = 1,
-.ao_speed = 357,
+.ao_speed = 350,
.num_p0_dio_channels = 8,
.caldac = {caldac_none},
.has_8255 = 0,
@@ -,7 +,7 @@ static const struct ni_board_struct ni_boards[] = {
.ao_range_table = &range_ni_M_628x_ao,
.reg_type = ni_reg_628x,
.ao_unipolar = 1,
-.ao_speed = 357,
+.ao_speed = 350,
.num_p0_dio_channels = 8,
.caldac = {caldac_none},
.has_8255 = 0,
@@ -1147,7 +1147,7 @@ static const struct ni_board_struct ni_boards[] = {
.ao_range_table = &range_ni_M_628x_ao,
.reg_type = ni_reg_628x,
.ao_unipolar = 1,
-.ao_speed = 357,
+.ao_speed = 350,
.num_p0_dio_channels = 32,
.caldac = {caldac_none},
.has_8255 = 0,
--
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 30/74] regulator: max8997: Use uV in voltage_map_desc
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Axel Lin
commit bc3b7756b5ff66828acf7bc24f148d28b8d61108 upstream.
Current code does integer division (min_vol = min_uV / 1000) before pass
min_vol to max8997_get_voltage_proper_val().
So it is possible min_vol is truncated to a smaller value.
For example, if the request min_uV is 800900 for ldo.
min_vol = 800900 / 1000 = 800 (mV)
Then max8997_get_voltage_proper_val returns 800 mV for this case which is lower
than the requested voltage.
Use uV rather than mV in voltage_map_desc to prevent truncation by integer
division.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/regulator/max8997.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/regulator/max8997.c b/drivers/regulator/max8997.c
index 704cd49..f57f83f 100644
--- a/drivers/regulator/max8997.c
+++ b/drivers/regulator/max8997.c
@@ -69,26 +69,26 @@ struct voltage_map_desc {
int step;
};
-/* Voltage maps in mV */
+/* Voltage maps in uV */
static const struct voltage_map_desc ldo_voltage_map_desc = {
- .min = 800, .max = 3950,.step = 50,
+ .min = 80, .max = 395, .step = 5,
}; /* LDO1 ~ 18, 21 all */
static const struct voltage_map_desc buck1245_voltage_map_desc = {
- .min = 650, .max = 2225,.step = 25,
+ .min = 65, .max = 2225000, .step = 25000,
}; /* Buck1, 2, 4, 5 */
static const struct voltage_map_desc buck37_voltage_map_desc = {
- .min = 750, .max = 3900,.step = 50,
+ .min = 75, .max = 390, .step = 5,
}; /* Buck3, 7 */
-/* current map in mA */
+/* current map in uA */
static const struct voltage_map_desc charger_current_map_desc = {
- .min = 200, .max = 950, .step = 50,
+ .min = 20, .max = 95, .step = 5,
};
static const struct voltage_map_desc topoff_current_map_desc = {
- .min = 50, .max = 200, .step = 10,
+ .min = 5, .max = 20, .step = 1,
};
static const struct voltage_map_desc *reg_voltage_map[] = {
@@ -192,7 +192,7 @@ static int max8997_list_voltage(struct regulator_dev *rdev,
if (val > desc->max)
return -EINVAL;
- return val * 1000;
+ return val;
}
static int max8997_get_enable_register(struct regulator_dev *rdev,
@@ -483,7 +483,6 @@ static int max8997_set_voltage_ldobuck(struct regulator_dev
*rdev,
{
struct max8997_data *max8997 = rdev_get_drvdata(rdev);
struct i2c_client *i2c = max8997->iodev->i2c;
- int min_vol = min_uV / 1000, max_vol = max_uV / 1000;
const struct voltage_map_desc *desc;
int rid = rdev_get_id(rdev);
int i, reg, shift, mask, ret;
@@ -507,7 +506,7 @@ static int max8997_set_voltage_ldobuck(struct regulator_dev
*rdev,
desc = reg_voltage_map[rid];
- i = max8997_get_voltage_proper_val(desc, min_vol, max_vol);
+ i = max8997_get_voltage_proper_val(desc, min_uV, max_uV);
if (i < 0)
return i;
@@ -555,7 +554,7 @@ static int max8997_set_voltage_ldobuck_time_sel(struct
regulator_dev *rdev,
case MAX8997_BUCK4:
case MAX8997_BUCK5:
return DIV_ROUND_UP(desc->step * (new_selector - old_selector),
- max8997->ramp_delay);
+ max8997->ramp_delay * 1000);
}
return 0;
@@ -654,7 +653,6 @@ static int max8997_set_voltage_buck(struct regulator_dev
*rdev,
const struct voltage_map_desc *desc;
int new_val, new_idx, damage, tmp_val, tmp_idx, tmp_dmg;
bool gpio_dvs_mode = false;
- int min_vol = min_uV / 1000, max_vol = max_uV / 1000;
if (rid < MAX8997_BUCK1 || rid > MAX8997_BUCK7)
return -EINVAL;
@@ -679,7 +677,7 @@ static int max8997_set_voltage_buck(struct regulator_dev
*rdev,
selector);
desc = reg_voltage_map[rid];
- new_val = max8997_get_voltage_proper_val(desc, min_vol, max_vol);
+ new_val = max8997_get_voltage_proper_val(desc, min_uV, max_uV);
if (new_val < 0)
return new_val;
@@ -977,8 +975,8 @@ static __devinit int max8997_pmic_probe(struct
platform_device *pdev)
max8997->buck1_vol[i] = ret =
max8997_get_voltage_proper_val(
&buck1245_voltage_map_desc,
- pdata->buck1_voltage[i] / 1000,
- pdata->buck1_voltage[i] / 1000 +
+ pdata->buck1_voltage[i],
+ pdata->buck1_voltage[i] +
buck1245_voltage_map_desc.step);
if (ret < 0)
[PATCH 31/74] regulator: max8998: Convert to regulator_list_voltage_linear()
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Axel Lin
commit 9a0fbb627cfa86303b8eb57377f536c64812cc85 upstream.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/regulator/max8998.c | 32 +++-
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/drivers/regulator/max8998.c b/drivers/regulator/max8998.c
index 18bb58b..105dafc 100644
--- a/drivers/regulator/max8998.c
+++ b/drivers/regulator/max8998.c
@@ -111,27 +111,6 @@ static const struct voltage_map_desc *ldo_voltage_map[] = {
&buck4_voltage_map_desc,/* BUCK4 */
};
-static int max8998_list_voltage(struct regulator_dev *rdev,
- unsigned int selector)
-{
- const struct voltage_map_desc *desc;
- int ldo = rdev_get_id(rdev);
- int val;
-
- if (ldo >= ARRAY_SIZE(ldo_voltage_map))
- return -EINVAL;
-
- desc = ldo_voltage_map[ldo];
- if (desc == NULL)
- return -EINVAL;
-
- val = desc->min + desc->step * selector;
- if (val > desc->max)
- return -EINVAL;
-
- return val * 1000;
-}
-
static int max8998_get_enable_register(struct regulator_dev *rdev,
int *reg, int *shift)
{
@@ -392,8 +371,8 @@ static int max8998_set_voltage_buck(struct regulator_dev
*rdev,
/* if previous_voltage equal new voltage, return */
if (previous_sel == i) {
dev_dbg(max8998->dev, "No voltage change, old:%d, new:%d\n",
- max8998_list_voltage(rdev, previous_sel),
- max8998_list_voltage(rdev, i));
+ regulator_list_voltage_linear(rdev, previous_sel),
+ regulator_list_voltage_linear(rdev, i));
return ret;
}
@@ -519,7 +498,7 @@ static int max8998_set_voltage_buck_time_sel(struct
regulator_dev *rdev,
}
static struct regulator_ops max8998_ldo_ops = {
- .list_voltage = max8998_list_voltage,
+ .list_voltage = regulator_list_voltage_linear,
.is_enabled = max8998_ldo_is_enabled,
.enable = max8998_ldo_enable,
.disable= max8998_ldo_disable,
@@ -530,7 +509,7 @@ static struct regulator_ops max8998_ldo_ops = {
};
static struct regulator_ops max8998_buck_ops = {
- .list_voltage = max8998_list_voltage,
+ .list_voltage = regulator_list_voltage_linear,
.is_enabled = max8998_ldo_is_enabled,
.enable = max8998_ldo_enable,
.disable= max8998_ldo_disable,
@@ -860,7 +839,10 @@ static __devinit int max8998_pmic_probe(struct
platform_device *pdev)
desc = ldo_voltage_map[id];
if (desc && regulators[index].ops != &max8998_others_ops) {
int count = (desc->max - desc->min) / desc->step + 1;
+
regulators[index].n_voltages = count;
+ regulators[index].min_uV = desc->min * 1000;
+ regulators[index].uV_step = desc->step * 1000;
}
config.dev = max8998->dev;
--
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 32/74] regulator: max8998: Convert to set_voltage_sel and regulator_map_voltage_linear
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Axel Lin
commit baae019efe84b6d2c6d5e7e7e1c9cfa130ad6b2a upstream.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/regulator/max8998.c | 97 ---
1 file changed, 27 insertions(+), 70 deletions(-)
diff --git a/drivers/regulator/max8998.c b/drivers/regulator/max8998.c
index 105dafc..a1fa266 100644
--- a/drivers/regulator/max8998.c
+++ b/drivers/regulator/max8998.c
@@ -276,41 +276,18 @@ static int max8998_get_voltage_sel(struct regulator_dev
*rdev)
return val;
}
-static int max8998_set_voltage_ldo(struct regulator_dev *rdev,
- int min_uV, int max_uV, unsigned *selector)
+static int max8998_set_voltage_ldo_sel(struct regulator_dev *rdev,
+ unsigned selector)
{
struct max8998_data *max8998 = rdev_get_drvdata(rdev);
struct i2c_client *i2c = max8998->iodev->i2c;
- int min_vol = min_uV / 1000, max_vol = max_uV / 1000;
- const struct voltage_map_desc *desc;
- int ldo = rdev_get_id(rdev);
- int reg, shift = 0, mask, ret, i;
-
- if (ldo >= ARRAY_SIZE(ldo_voltage_map))
- return -EINVAL;
-
- desc = ldo_voltage_map[ldo];
- if (desc == NULL)
- return -EINVAL;
-
- if (max_vol < desc->min || min_vol > desc->max)
- return -EINVAL;
-
- if (min_vol < desc->min)
- min_vol = desc->min;
-
- i = DIV_ROUND_UP(min_vol - desc->min, desc->step);
-
- if (desc->min + desc->step*i > max_vol)
- return -EINVAL;
-
- *selector = i;
+ int reg, shift = 0, mask, ret;
ret = max8998_get_voltage_register(rdev, ®, &shift, &mask);
if (ret)
return ret;
- ret = max8998_update_reg(i2c, reg, idev);
struct i2c_client *i2c = max8998->iodev->i2c;
- int min_vol = min_uV / 1000, max_vol = max_uV / 1000;
- const struct voltage_map_desc *desc;
int buck = rdev_get_id(rdev);
int reg, shift = 0, mask, ret;
- int i, j, previous_sel;
+ int j, previous_sel;
static u8 buck1_last_val;
- if (buck >= ARRAY_SIZE(ldo_voltage_map))
- return -EINVAL;
-
- desc = ldo_voltage_map[buck];
-
- if (desc == NULL)
- return -EINVAL;
-
- if (max_vol < desc->min || min_vol > desc->max)
- return -EINVAL;
-
- if (min_vol < desc->min)
- min_vol = desc->min;
-
- i = DIV_ROUND_UP(min_vol - desc->min, desc->step);
-
- if (desc->min + desc->step*i > max_vol)
- return -EINVAL;
-
- *selector = i;
-
ret = max8998_get_voltage_register(rdev, ®, &shift, &mask);
if (ret)
return ret;
@@ -369,19 +323,19 @@ static int max8998_set_voltage_buck(struct regulator_dev
*rdev,
/* Check if voltage needs to be changed */
/* if previous_voltage equal new voltage, return */
- if (previous_sel == i) {
+ if (previous_sel == selector) {
dev_dbg(max8998->dev, "No voltage change, old:%d, new:%d\n",
regulator_list_voltage_linear(rdev, previous_sel),
- regulator_list_voltage_linear(rdev, i));
+ regulator_list_voltage_linear(rdev, selector));
return ret;
}
switch (buck) {
case MAX8998_BUCK1:
dev_dbg(max8998->dev,
- "BUCK1, i:%d, buck1_vol1:%d, buck1_vol2:%d\n"
+ "BUCK1, selector:%d, buck1_vol1:%d, buck1_vol2:%d\n"
"buck1_vol3:%d, buck1_vol4:%d\n",
- i, max8998->buck1_vol[0], max8998->buck1_vol[1],
+ selector, max8998->buck1_vol[0], max8998->buck1_vol[1],
max8998->buck1_vol[2], max8998->buck1_vol[3]);
if (gpio_is_valid(pdata->buck1_set1) &&
@@ -390,7 +344,7 @@ static int max8998_set_voltage_buck(struct regulator_dev
*rdev,
/* check if requested voltage */
/* value is already defined */
for (j = 0; j < ARRAY_SIZE(max8998->buck1_vol); j++) {
- if (max8998->buck1_vol[j] == i) {
+ if (max8998->buck1_vol[j] == selector) {
max8998->buck1_idx = j;
buck1_gpio_set(pdata->buck1_set1,
pdata->buck1_set2, j);
@@ -405,11 +359,11 @@ static int max8998_set_voltage_buck(struct regulator_dev
*rdev,
max8998->buck1_idx = (buck1_last_val % 2) + 2;
dev_dbg(max8998->dev, "max8998->buck1_idx:%d\n",
[PATCH 33/74] regulator: max8998: Use uV in voltage_map_desc
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Axel Lin
commit adf6178ad5552a7f2f742a8c85343c50f080c412 upstream.
Integer division may truncate.
This happens when pdata->buckx_voltagex setting is not align with 1000 uV.
Thus use uV in voltage_map_desc, this ensures the selected voltage won't less
than pdata buckx_voltagex settings.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/regulator/max8998.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/regulator/max8998.c b/drivers/regulator/max8998.c
index a1fa266..5e56df0 100644
--- a/drivers/regulator/max8998.c
+++ b/drivers/regulator/max8998.c
@@ -51,39 +51,39 @@ struct voltage_map_desc {
int step;
};
-/* Voltage maps */
+/* Voltage maps in uV*/
static const struct voltage_map_desc ldo23_voltage_map_desc = {
- .min = 800, .step = 50, .max = 1300,
+ .min = 80, .step = 5, .max = 130,
};
static const struct voltage_map_desc ldo456711_voltage_map_desc = {
- .min = 1600,.step = 100,.max = 3600,
+ .min = 160, .step = 10, .max = 360,
};
static const struct voltage_map_desc ldo8_voltage_map_desc = {
- .min = 3000,.step = 100,.max = 3600,
+ .min = 300, .step = 10, .max = 360,
};
static const struct voltage_map_desc ldo9_voltage_map_desc = {
- .min = 2800,.step = 100,.max = 3100,
+ .min = 280, .step = 10, .max = 310,
};
static const struct voltage_map_desc ldo10_voltage_map_desc = {
- .min = 950, .step = 50, .max = 1300,
+ .min = 95000, .step = 5, .max = 130,
};
static const struct voltage_map_desc ldo1213_voltage_map_desc = {
- .min = 800, .step = 100,.max = 3300,
+ .min = 80, .step = 10, .max = 330,
};
static const struct voltage_map_desc ldo1415_voltage_map_desc = {
- .min = 1200,.step = 100,.max = 3300,
+ .min = 120, .step = 10, .max = 330,
};
static const struct voltage_map_desc ldo1617_voltage_map_desc = {
- .min = 1600,.step = 100,.max = 3600,
+ .min = 160, .step = 10, .max = 360,
};
static const struct voltage_map_desc buck12_voltage_map_desc = {
- .min = 750, .step = 25, .max = 1525,
+ .min = 75, .step = 25000, .max = 1525000,
};
static const struct voltage_map_desc buck3_voltage_map_desc = {
- .min = 1600,.step = 100,.max = 3600,
+ .min = 160, .step = 10, .max = 360,
};
static const struct voltage_map_desc buck4_voltage_map_desc = {
- .min = 800, .step = 100,.max = 2300,
+ .min = 80, .step = 10, .max = 230,
};
static const struct voltage_map_desc *ldo_voltage_map[] = {
@@ -445,7 +445,7 @@ static int max8998_set_voltage_buck_time_sel(struct
regulator_dev *rdev,
if (max8998->iodev->type == TYPE_MAX8998 && !(val & MAX8998_ENRAMP))
return 0;
- difference = (new_selector - old_selector) * desc->step;
+ difference = (new_selector - old_selector) * desc->step / 1000;
if (difference > 0)
return difference / ((val & 0x0f) + 1);
@@ -708,7 +708,7 @@ static __devinit int max8998_pmic_probe(struct
platform_device *pdev)
i = 0;
while (buck12_voltage_map_desc.min +
buck12_voltage_map_desc.step*i
- < (pdata->buck1_voltage1 / 1000))
+ < pdata->buck1_voltage1)
i++;
max8998->buck1_vol[0] = i;
ret = max8998_write_reg(i2c, MAX8998_REG_BUCK1_VOLTAGE1, i);
@@ -719,7 +719,7 @@ static __devinit int max8998_pmic_probe(struct
platform_device *pdev)
i = 0;
while (buck12_voltage_map_desc.min +
buck12_voltage_map_desc.step*i
- < (pdata->buck1_voltage2 / 1000))
+ < pdata->buck1_voltage2)
i++;
max8998->buck1_vol[1] = i;
@@ -731,7 +731,7 @@ static __devinit int max8998_pmic_probe(struct
platform_device *pdev)
i = 0;
while (buck12_voltage_map_desc.min +
buck12_voltage_map_desc.step*i
- < (pdata->buck1_voltage3 / 1000))
+ < pdata->buck1_voltage3)
i++;
max8998->buck1_vol[2] = i;
@@ -743,7 +743,7 @@ static __devinit int max8998_pmic_probe(struct
platform_device *pdev)
i = 0;
while (buck12_voltage_map_desc.min +
buck12_voltage_map_desc.step*i
- < (pdata->buck1_voltage4 / 1000))
+ < pdata->buck1_voltage4)
i++;
[PATCH 35/74] ALSA: pxa27x: fix ac97 warm reset
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Mike Dunn
commit 3b4bc7bccc7857274705b05cf81a0c72cfd0b0dd upstream.
This patch fixes some code that implements a work-around to a hardware bug in
the ac97 controller on the pxa27x. A bug in the controller's warm reset
functionality requires that the mfp used by the controller as the AC97_nRESET
line be temporarily reconfigured as a generic output gpio (AF0) and manually
held high for the duration of the warm reset cycle. This is what was done in
the original code, but it was broken long ago by commit fb1bf8cd
([ARM] pxa: introduce processor specific pxa27x_assert_ac97reset())
which changed the mfp to a GPIO input instead of a high output.
The fix requires the ac97 controller to obtain the gpio via gpio_request_one(),
with arguments that configure the gpio as an output initially driven high.
Tested on a palm treo 680 machine. Reportedly, this broken code only prevents a
warm reset on hardware that lacks a pull-up on the line, which appears to be the
case for me.
Signed-off-by: Mike Dunn
Signed-off-by: Igor Grinberg
Signed-off-by: Mark Brown
Signed-off-by: Herton Ronaldo Krzesinski
---
arch/arm/mach-pxa/include/mach/mfp-pxa27x.h |3 +++
arch/arm/mach-pxa/pxa27x.c |4 ++--
sound/arm/pxa2xx-ac97-lib.c | 18 +-
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
b/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
index a611ad3..b6132aa 100644
--- a/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
+++ b/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
@@ -463,6 +463,9 @@
GPIO76_LCD_PCLK,\
GPIO77_LCD_BIAS
+/* these enable a work-around for a hw bug in pxa27x during ac97 warm reset */
+#define GPIO113_AC97_nRESET_GPIO_HIGH MFP_CFG_OUT(GPIO113, AF0, DEFAULT)
+#define GPIO95_AC97_nRESET_GPIO_HIGH MFP_CFG_OUT(GPIO95, AF0, DEFAULT)
extern int keypad_set_wake(unsigned int on);
#endif /* __ASM_ARCH_MFP_PXA27X_H */
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 4726c24..a2fe795 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -47,9 +47,9 @@ void pxa27x_clear_otgph(void)
EXPORT_SYMBOL(pxa27x_clear_otgph);
static unsigned long ac97_reset_config[] = {
- GPIO113_GPIO,
+ GPIO113_AC97_nRESET_GPIO_HIGH,
GPIO113_AC97_nRESET,
- GPIO95_GPIO,
+ GPIO95_AC97_nRESET_GPIO_HIGH,
GPIO95_AC97_nRESET,
};
diff --git a/sound/arm/pxa2xx-ac97-lib.c b/sound/arm/pxa2xx-ac97-lib.c
index 8cfb2c0..bd3ba88 100644
--- a/sound/arm/pxa2xx-ac97-lib.c
+++ b/sound/arm/pxa2xx-ac97-lib.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -344,8 +345,21 @@ int __devinit pxa2xx_ac97_hw_probe(struct platform_device
*dev)
}
if (cpu_is_pxa27x()) {
- /* Use GPIO 113 as AC97 Reset on Bulverde */
+ /*
+* This gpio is needed for a work-around to a bug in the ac97
+* controller during warm reset. The direction and level is set
+* here so that it is an output driven high when switching from
+* AC97_nRESET alt function to generic gpio.
+*/
+ ret = gpio_request_one(reset_gpio, GPIOF_OUT_INIT_HIGH,
+ "pxa27x ac97 reset");
+ if (ret < 0) {
+ pr_err("%s: gpio_request_one() failed: %d\n",
+ __func__, ret);
+ goto err_conf;
+ }
pxa27x_assert_ac97reset(reset_gpio, 0);
+
ac97conf_clk = clk_get(&dev->dev, "AC97CONFCLK");
if (IS_ERR(ac97conf_clk)) {
ret = PTR_ERR(ac97conf_clk);
@@ -388,6 +402,8 @@ EXPORT_SYMBOL_GPL(pxa2xx_ac97_hw_probe);
void pxa2xx_ac97_hw_remove(struct platform_device *dev)
{
+ if (cpu_is_pxa27x())
+ gpio_free(reset_gpio);
GCR |= GCR_ACLINK_OFF;
free_irq(IRQ_AC97, NULL);
if (ac97conf_clk) {
--
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 36/74] SUNRPC: Ensure we release the socket write lock if the rpc_task exits early
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit 87ed50036b866db2ec2ba16b2a7aec4a2b0b7c39 upstream.
If the rpc_task exits while holding the socket write lock before it has
allocated an rpc slot, then the usual mechanism for releasing the write
lock in xprt_release() is defeated.
The problem occurs if the call to xprt_lock_write() initially fails, so
that the rpc_task is put on the xprt->sending wait queue. If the task
exits after being assigned the lock by __xprt_lock_write_func, but
before it has retried the call to xprt_lock_and_alloc_slot(), then
it calls xprt_release() while holding the write lock, but will
immediately exit due to the test for task->tk_rqstp != NULL.
Reported-by: Chris Perl
Signed-off-by: Trond Myklebust
Signed-off-by: Herton Ronaldo Krzesinski
---
net/sunrpc/sched.c |3 +--
net/sunrpc/xprt.c | 12 ++--
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
index fe2cf2f..85b9235 100644
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -953,8 +953,7 @@ static void rpc_async_release(struct work_struct *work)
static void rpc_release_resources_task(struct rpc_task *task)
{
- if (task->tk_rqstp)
- xprt_release(task);
+ xprt_release(task);
if (task->tk_msg.rpc_cred) {
put_rpccred(task->tk_msg.rpc_cred);
task->tk_msg.rpc_cred = NULL;
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index 2d5b811..6329ff3 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -1139,10 +1139,18 @@ static void xprt_request_init(struct rpc_task *task,
struct rpc_xprt *xprt)
void xprt_release(struct rpc_task *task)
{
struct rpc_xprt *xprt;
- struct rpc_rqst *req;
+ struct rpc_rqst *req = task->tk_rqstp;
- if (!(req = task->tk_rqstp))
+ if (req == NULL) {
+ if (task->tk_client) {
+ rcu_read_lock();
+ xprt = rcu_dereference(task->tk_client->cl_xprt);
+ if (xprt->snd_task == task)
+ xprt_release_write(xprt, task);
+ rcu_read_unlock();
+ }
return;
+ }
xprt = req->rq_xprt;
if (task->tk_ops->rpc_count_stats != NULL)
--
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/
[ RFC patch 0/4]: use runnable load avg in cfs balance instead of instant load
This patchset can be used, but causes burst waking benchmark aim9 drop 5~7% on my 2 sockets machine. The reason is too light runnable load in early stage of waked tasks cause imbalance in balancing. So, it is immature and just a reference for guys who want to go gurther. Thanks! Alex [PATCH 1/4] sched: update cpu load after task_tick. [PATCH 2/4] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task [PATCH 3/4] sched: consider runnable load average in move_tasks [PATCH 4/4] sched: consider runnable load average in effective_load -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 18/74] mwifiex: check wait_event_interruptible return value
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Bing Zhao
commit 9c969d8ccb1e17bd20742f4ac9f00c1a64487234 upstream.
wait_event_interruptible function returns -ERESTARTSYS if it's
interrupted by a signal. Driver should check the return value
and handle this case properly.
In mwifiex_wait_queue_complete() routine, as we are now checking
wait_event_interruptible return value, the condition check is not
required. Also, we have removed mwifiex_cancel_pending_ioctl()
call to avoid a chance of sending second command to FW by other path
as soon as we clear current command node. FW can not handle two
commands simultaneously.
Signed-off-by: Bing Zhao
Signed-off-by: Amitkumar Karwar
Signed-off-by: John W. Linville
[ herton: adjust context ]
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/net/wireless/mwifiex/sta_ioctl.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/sta_ioctl.c
b/drivers/net/wireless/mwifiex/sta_ioctl.c
index 106c449..a5db9f1 100644
--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -53,7 +53,6 @@ int mwifiex_copy_mcast_addr(struct mwifiex_multicast_list
*mlist,
*/
int mwifiex_wait_queue_complete(struct mwifiex_adapter *adapter)
{
- bool cancel_flag = false;
int status;
struct cmd_ctrl_node *cmd_queued;
@@ -70,14 +69,11 @@ int mwifiex_wait_queue_complete(struct mwifiex_adapter
*adapter)
queue_work(adapter->workqueue, &adapter->main_work);
/* Wait for completion */
- wait_event_interruptible(adapter->cmd_wait_q.wait,
-*(cmd_queued->condition));
- if (!*(cmd_queued->condition))
- cancel_flag = true;
-
- if (cancel_flag) {
- mwifiex_cancel_pending_ioctl(adapter);
- dev_dbg(adapter->dev, "cmd cancel\n");
+ status = wait_event_interruptible(adapter->cmd_wait_q.wait,
+ *(cmd_queued->condition));
+ if (status) {
+ dev_err(adapter->dev, "cmd_wait_q terminated: %d\n", status);
+ return status;
}
status = adapter->cmd_wait_q.status;
@@ -430,8 +426,11 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
return false;
}
- wait_event_interruptible(adapter->hs_activate_wait_q,
-adapter->hs_activate_wait_q_woken);
+ if (wait_event_interruptible(adapter->hs_activate_wait_q,
+adapter->hs_activate_wait_q_woken)) {
+ dev_err(adapter->dev, "hs_activate_wait_q terminated\n");
+ return false;
+ }
return true;
}
--
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 17/74] ASoC: wm5100: Remove DSP B and left justified formats
3.5.7.4 -stable review patch. If anyone has any objections, please let me know. -- From: Mark Brown commit 5f960294e2031d12f10c8488c3446fecbf59628d upstream. These are not supported Signed-off-by: Mark Brown Signed-off-by: Herton Ronaldo Krzesinski --- sound/soc/codecs/wm5100.c |6 -- 1 file changed, 6 deletions(-) diff --git a/sound/soc/codecs/wm5100.c b/sound/soc/codecs/wm5100.c index cb6d537..d986704 100644 --- a/sound/soc/codecs/wm5100.c +++ b/sound/soc/codecs/wm5100.c @@ -1279,15 +1279,9 @@ static int wm5100_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) case SND_SOC_DAIFMT_DSP_A: mask = 0; break; - case SND_SOC_DAIFMT_DSP_B: - mask = 1; - break; case SND_SOC_DAIFMT_I2S: mask = 2; break; - case SND_SOC_DAIFMT_LEFT_J: - mask = 3; - break; default: dev_err(codec->dev, "Unsupported DAI format %d\n", fmt & SND_SOC_DAIFMT_FORMAT_MASK); -- 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 16/74] ASoC: wm2200: Remove DSP B and left justified AIF modes
3.5.7.4 -stable review patch. If anyone has any objections, please let me know. -- From: Mark Brown commit 0cc411b934c4317b363d1af993549f391852b980 upstream. These are not supported. Signed-off-by: Mark Brown Signed-off-by: Herton Ronaldo Krzesinski --- sound/soc/codecs/wm2200.c |6 -- 1 file changed, 6 deletions(-) diff --git a/sound/soc/codecs/wm2200.c b/sound/soc/codecs/wm2200.c index 201fc58..86b84a1 100644 --- a/sound/soc/codecs/wm2200.c +++ b/sound/soc/codecs/wm2200.c @@ -1380,15 +1380,9 @@ static int wm2200_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) case SND_SOC_DAIFMT_DSP_A: fmt_val = 0; break; - case SND_SOC_DAIFMT_DSP_B: - fmt_val = 1; - break; case SND_SOC_DAIFMT_I2S: fmt_val = 2; break; - case SND_SOC_DAIFMT_LEFT_J: - fmt_val = 3; - break; default: dev_err(codec->dev, "Unsupported DAI format %d\n", fmt & SND_SOC_DAIFMT_FORMAT_MASK); -- 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 28/74] staging: comedi: prevent auto-unconfig of manually configured devices
3.5.7.4 -stable review patch. If anyone has any objections, please let me know.
--
From: Ian Abbott
commit 7d3135af399e92cf4c9bbc5f86b6c140aab3b88c upstream.
When a low-level comedi driver auto-configures a device, a `struct
comedi_dev_file_info` is allocated (as well as a `struct
comedi_device`) by `comedi_alloc_board_minor()`. A pointer to the
hardware `struct device` is stored as a cookie in the `struct
comedi_dev_file_info`. When the low-level comedi driver
auto-unconfigures the device, `comedi_auto_unconfig()` uses the cookie
to find the `struct comedi_dev_file_info` so it can detach the comedi
device from the driver, clean it up and free it.
A problem arises if the user manually unconfigures and reconfigures the
comedi device using the `COMEDI_DEVCONFIG` ioctl so that is no longer
associated with the original hardware device. The problem is that the
cookie is not cleared, so that a call to `comedi_auto_unconfig()` from
the low-level driver will still find it, detach it, clean it up and free
it.
Stop this problem occurring by always clearing the `hardware_device`
cookie in the `struct comedi_dev_file_info` whenever the
`COMEDI_DEVCONFIG` ioctl call is successful.
Signed-off-by: Ian Abbott
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Herton Ronaldo Krzesinski
---
drivers/staging/comedi/comedi_fops.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index d77219a..d231193 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -427,6 +427,9 @@ static long comedi_unlocked_ioctl(struct file *file,
unsigned int cmd,
if (cmd == COMEDI_DEVCONFIG) {
rc = do_devconfig_ioctl(dev,
(struct comedi_devconfig __user *)arg);
+ if (rc == 0)
+ /* Evade comedi_auto_unconfig(). */
+ dev_file_info->hardware_device = NULL;
goto done;
}
--
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 2/4] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task
They are the base values in load balance, update them with rq runnable
load average, then the load balance will consider runnable load avg
naturally.
Signed-off-by: Alex Shi
---
kernel/sched/core.c |8
kernel/sched/fair.c |4 ++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4f4714e..f25b8d8 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2539,7 +2539,11 @@ static void __update_cpu_load(struct rq *this_rq,
unsigned long this_load,
void update_idle_cpu_load(struct rq *this_rq)
{
unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
+#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+ unsigned long load = (unsigned long)this_rq->cfs.runnable_load_avg;
+#else
unsigned long load = this_rq->load.weight;
+#endif
unsigned long pending_updates;
/*
@@ -2589,7 +2593,11 @@ static void update_cpu_load_active(struct rq *this_rq)
* See the mess around update_idle_cpu_load() / update_cpu_load_nohz().
*/
this_rq->last_load_update_tick = jiffies;
+#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+ __update_cpu_load(this_rq, this_rq->cfs.runnable_load_avg, 1);
+#else
__update_cpu_load(this_rq, this_rq->load.weight, 1);
+#endif
calc_load_account_active(this_rq);
}
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7697171..9148bcc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2909,7 +2909,7 @@ static void dequeue_task_fair(struct rq *rq, struct
task_struct *p, int flags)
/* Used instead of source_load when we know the type == 0 */
static unsigned long weighted_cpuload(const int cpu)
{
- return cpu_rq(cpu)->load.weight;
+ return (unsigned long)cpu_rq(cpu)->cfs.runnable_load_avg;
}
/*
@@ -2956,7 +2956,7 @@ static unsigned long cpu_avg_load_per_task(int cpu)
unsigned long nr_running = ACCESS_ONCE(rq->nr_running);
if (nr_running)
- return rq->load.weight / nr_running;
+ return (unsigned long)rq->cfs.runnable_load_avg / nr_running;
return 0;
}
--
1.7.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 37/74] target: use correct sense code for LUN communication failure
3.5.7.4 -stable review patch. If anyone has any objections, please let me know. -- From: Hannes Reinecke commit 18a9df42d53fabfa43b78be1104838cc8b9762e1 upstream. The ASC/ASCQ code for 'Logical Unit Communication failure' is 0x08/0x00; 0x80/0x00 is vendor specific. Signed-off-by: Hannes Reinecke Cc: Nicholas Bellinger Signed-off-by: Nicholas Bellinger [ herton: adjust context, additional offset added ] Signed-off-by: Herton Ronaldo Krzesinski --- drivers/target/target_core_transport.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c index 7879ff4..cf05182 100644 --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -4231,7 +4231,7 @@ int transport_send_check_condition_and_sense( /* ILLEGAL REQUEST */ buffer[offset+SPC_SENSE_KEY_OFFSET] = ILLEGAL_REQUEST; /* LOGICAL UNIT COMMUNICATION FAILURE */ - buffer[offset+SPC_ASC_KEY_OFFSET] = 0x80; + buffer[offset+SPC_ASC_KEY_OFFSET] = 0x08; break; } /* -- 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/
