[PATCH V6 2/2] mmc: host: Adds support for eMMC 4.5 HS200 mode
This patch adds support for the HS200 mode on the host side.
Also enables the tuning feature required when the HS200 mode
is selected.
cc: Chris Ball
Signed-off-by: Girish K S
---
drivers/mmc/host/sdhci.c | 43 +--
drivers/mmc/host/sdhci.h |1 +
include/linux/mmc/host.h | 11 ++-
include/linux/mmc/sdhci.h |1 +
4 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ab6018f..049d51d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -49,7 +49,7 @@ static void sdhci_finish_data(struct sdhci_host *);
static void sdhci_send_command(struct sdhci_host *, struct mmc_command *);
static void sdhci_finish_command(struct sdhci_host *);
-static int sdhci_execute_tuning(struct mmc_host *mmc);
+static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
static void sdhci_tuning_timer(unsigned long data);
#ifdef CONFIG_PM_RUNTIME
@@ -1016,7 +1016,8 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
flags |= SDHCI_CMD_INDEX;
/* CMD19 is special in that the Data Present Select should be set */
- if (cmd->data || (cmd->opcode == MMC_SEND_TUNING_BLOCK))
+ if (cmd->data || (cmd->opcode == MMC_SEND_TUNING_BLOCK) ||
+ (cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200))
flags |= SDHCI_CMD_DATA;
sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND);
@@ -1287,7 +1288,7 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
if ((host->flags & SDHCI_NEEDS_RETUNING) &&
!(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) {
spin_unlock_irqrestore(&host->lock, flags);
- sdhci_execute_tuning(mmc);
+ sdhci_execute_tuning(mmc, mrq->cmd->opcode);
spin_lock_irqsave(&host->lock, flags);
/* Restore original mmc_request structure */
@@ -1375,7 +1376,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host,
struct mmc_ios *ios)
(ios->timing == MMC_TIMING_UHS_SDR104) ||
(ios->timing == MMC_TIMING_UHS_DDR50) ||
(ios->timing == MMC_TIMING_UHS_SDR25) ||
- (ios->timing == MMC_TIMING_UHS_SDR12))
+ (ios->timing == MMC_TIMING_UHS_SDR12) ||
+ (ios->timing == MMC_TIMING_MMC_HS200))
ctrl |= SDHCI_CTRL_HISPD;
ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
@@ -1435,6 +1437,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host,
struct mmc_ios *ios)
ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
else if (ios->timing == MMC_TIMING_UHS_DDR50)
ctrl_2 |= SDHCI_CTRL_UHS_DDR50;
+ else if (ios->timing == MMC_TIMING_MMC_HS200)
+ ctrl_2 |= SDHCI_CTRL_HS_SDR200;
sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
}
@@ -1673,7 +1677,7 @@ static int sdhci_start_signal_voltage_switch(struct
mmc_host *mmc,
return err;
}
-static int sdhci_execute_tuning(struct mmc_host *mmc)
+static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
{
struct sdhci_host *host;
u16 ctrl;
@@ -1694,10 +1698,13 @@ static int sdhci_execute_tuning(struct mmc_host *mmc)
* Host Controller needs tuning only in case of SDR104 mode
* and for SDR50 mode when Use Tuning for SDR50 is set in
* Capabilities register.
+* If the Host Controller supports the HS200 mode then tuning
+* function has to be executed.
*/
if (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR104) ||
(((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR50) &&
- (host->flags & SDHCI_SDR50_NEEDS_TUNING)))
+ (host->flags & SDHCI_SDR50_NEEDS_TUNING)) ||
+ (host->flags & SDHCI_HS200_NEEDS_TUNING))
ctrl |= SDHCI_CTRL_EXEC_TUNING;
else {
spin_unlock(&host->lock);
@@ -1733,7 +1740,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc)
if (!tuning_loop_counter && !timeout)
break;
- cmd.opcode = MMC_SEND_TUNING_BLOCK;
+ cmd.opcode = opcode;
cmd.arg = 0;
cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
cmd.retries = 0;
@@ -1748,7 +1755,17 @@ static int sdhci_execute_tuning(struct mmc_host *mmc)
* block to the Host Controller. So we set the block size
* to 64 here.
*/
- sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, 64), SDHCI_BLOCK_SIZE);
+ if (cmd.opcode == MMC_SEND_TUNING_BLOCK_HS200) {
+
[PATCH V6 1/2] mmc: core: HS200 mode support for eMMC 4.5
This patch adds the support of the HS200 bus speed for eMMC 4.5 devices.
The eMMC 4.5 devices have support for 200MHz bus speed. The function
prototype of the tuning function is modified to handle the tuning command
number which is different in sd and mmc case.
cc: Chris Ball
Signed-off-by: Girish K S
---
drivers/mmc/core/bus.c |3 +-
drivers/mmc/core/debugfs.c |3 +
drivers/mmc/core/mmc.c | 147 +---
drivers/mmc/core/sd.c |3 +-
drivers/mmc/core/sdio.c|4 +-
include/linux/mmc/card.h |3 +
include/linux/mmc/mmc.h| 66 +++-
7 files changed, 216 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index f8a228a..5d011a3 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -303,10 +303,11 @@ int mmc_add_card(struct mmc_card *card)
mmc_card_ddr_mode(card) ? "DDR " : "",
type);
} else {
- printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
+ pr_info("%s: new %s%s%s%s card at address %04x\n",
mmc_hostname(card->host),
mmc_card_uhs(card) ? "ultra high speed " :
(mmc_card_highspeed(card) ? "high speed " : ""),
+ (mmc_card_hs200(card) ? "HS200 " : ""),
mmc_card_ddr_mode(card) ? "DDR " : "",
type, card->rca);
}
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 027615d..9ab5b17 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -135,6 +135,9 @@ static int mmc_ios_show(struct seq_file *s, void *data)
case MMC_TIMING_UHS_DDR50:
str = "sd uhs DDR50";
break;
+ case MMC_TIMING_MMC_HS200:
+ str = "mmc high-speed SDR200";
+ break;
default:
str = "invalid";
break;
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index f0a9f1f..d5d93de 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -286,6 +286,27 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
*ext_csd)
}
card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
+ case EXT_CSD_CARD_TYPE_SDR_ALL:
+ case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_8V:
+ case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_2V:
+ case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_52:
+ card->ext_csd.hs_max_dtr = 2;
+ card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
+ break;
+ case EXT_CSD_CARD_TYPE_SDR_1_2V_ALL:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_8V:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_2V:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_52:
+ card->ext_csd.hs_max_dtr = 2;
+ card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_2V;
+ break;
+ case EXT_CSD_CARD_TYPE_SDR_1_8V_ALL:
+ case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_8V:
+ case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_2V:
+ case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_52:
+ card->ext_csd.hs_max_dtr = 2;
+ card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_8V;
+ break;
case EXT_CSD_CARD_TYPE_DDR_52 | EXT_CSD_CARD_TYPE_52 |
EXT_CSD_CARD_TYPE_26:
card->ext_csd.hs_max_dtr = 5200;
@@ -700,6 +721,52 @@ static int mmc_select_powerclass(struct mmc_card *card,
}
/*
+ * Selects the desired buswidth and switch to the HS200 mode
+ * if bus width set without error
+ */
+static int mmc_select_hs200(struct mmc_card *card)
+{
+ int err = 0;
+ struct mmc_host *host;
+ u32 bus_width = MMC_BUS_WIDTH_4;
+
+ BUG_ON(!card);
+
+ host = card->host;
+
+ /*
+* Host is capable of 8bit transfer, then switch
+* the device to work in 8bit transfer mode. If the
+* mmc switch command returns error then switch to
+* 4bit transfer mode. On success set the corresponding
+* bus width on the host.
+*/
+ if (host->caps & MMC_CAP_8_BIT_DATA) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BUS_WIDTH,
+EXT_CSD_BUS_WIDTH_8,
+card->ext_csd.generic_cmd6_time);
+ bus_width = MMC_BUS_WIDTH_8;
+ }
+
+ /* If the 8bit mode fails switch to 4 bit mode */
+ if (err)
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BUS_WIDTH,
+EXT_CSD_BUS_WIDTH_4,
+card->ext_csd.generic_cmd6_time);
+
+ /* switch to HS200 mode if bus width set successfully */
+ if (!
[PATCH V6 0/2] HS200 Mode support for device and host
Changes in v6: split the patch into 2 and classified them as a patch for device and host. Modified to include the review comments. Changes in v5: Reduced the case statements for better code readability. Removed unused macro definitions. Modified the tuning function prototype and definition to support tuning for both SD and eMMC cards. Changes in v4: Rebased onto chris-mmc/mmc-next branch. This patch is successfully applied on commit with id de022ed3fdc14808299b2fa66dbb1ed5ab921912. Changes in v3: In the previous commits of chris-mmc/mmc-next branch, the patch with commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines caps2 for more capabilities. This patch version deletes the member ext_caps(created in my earlier patch) from struct mmc_host and reuses already accepted caps2 member. Changes in v2: Rebased to latest chris-mmc/mmc-next branch. Resolved indentation problems identified in review. This patch has to be applied before the patch released for modifying the printk messages. Changes in v1: Case statements in switch that produce same result have been combined to reduce repeated assignments. patch recreated after rebase to chris balls mmc-next branch. Girish K S (2): mmc: core: HS200 mode support for eMMC 4.5 mmc: host: Adds support for eMMC 4.5 HS200 mode drivers/mmc/core/bus.c |3 +- drivers/mmc/core/debugfs.c |3 + drivers/mmc/core/mmc.c | 147 +--- drivers/mmc/core/sd.c |3 +- drivers/mmc/core/sdio.c|4 +- drivers/mmc/host/sdhci.c | 43 ++--- drivers/mmc/host/sdhci.h |1 + include/linux/mmc/card.h |3 + include/linux/mmc/host.h | 11 +++- include/linux/mmc/mmc.h| 66 +++- include/linux/mmc/sdhci.h |1 + 11 files changed, 261 insertions(+), 24 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-s3c2410: Fix return code of s3c24xx_i2c_parse_dt_gpio
Ping
On 12/09/2011 03:33 PM, Tushar Behera wrote:
s3c24xx_i2c_parse_dt_gpio is called when cfg_gpio is not defined
in the platform data of the i2c device. When DT is not enabled,
the above function always returns -EINVAL. Since there can be
some i2c devices which don't need to configure any gpio lines,
the probe of such devices would fail here. Changing the default
return value to success would fix this issue.
Signed-off-by: Tushar Behera
---
This patch is rebased on Kukjin's for-next branch.
d3d936c "Merge branch 'samsung-fixes-2' into for-next"
drivers/i2c/busses/i2c-s3c2410.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 2754cef..b5caa42 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -786,7 +786,7 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c
*i2c)
#else
static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c)
{
- return -EINVAL;
+ return 0;
}
static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] s3c-hsudc: add a remove function
On Sun, Dec 18, 2011 at 09:46:08PM +0100, Heiko Stübner wrote:
> > > kobject: 'holders' (c7addc80): kobject_cleanup
> > > Unable to handle kernel paging request at virtual address bf055504
> > > pgd = c0004000
> > > [bf055504] *pgd=371f9811, *pte=, *ppte=
> > > Internal error: Oops: 7 [#1]
> >
> > Please post the entire first oops dump for the above run - it may contain
> > useful information to properly track this down.
>
> kobject: 'holders' (c7addc80): kobject_cleanup
> Unable to handle kernel paging request at virtual address bf055504
> pgd = c0004000
> [bf055504] *pgd=371f9811, *pte=, *ppte=
> Internal error: Oops: 7 [#1]
> Modules linked in: ohci_hcd usbcore leds_s3c24xx i2c_s3c2410 i2c_core
> CPU: 0Not tainted (3.2.0-rc5-next-20111216+ #33)
> PC is at kobject_put+0x18/0x7c
> LR is at kobject_del+0x64/0x70
> pc : []lr : []psr: a013
> sp : c70bdef8 ip : c70bdf18 fp : c70bdf14
> r10: r9 : c0114718 r8 : c7803a00
> r7 : c7abd360 r6 : c02e1de0 r5 : c7addca0 r4 : bf0554a0
> r3 : 0001 r2 : r1 : r0 : bf0554a0
> Backtrace:
> [] (kobject_put+0x0/0x7c) from [] (kobject_del+0x64/0x70)
> r4:c7addc80
> [] (kobject_del+0x0/0x70) from []
> (kobject_delayed_cleanup+0xd4/0x174)
> r4:c7addc80
> [] (kobject_delayed_cleanup+0x0/0x174) from []
> (process_one_work+0x24c/0x3a8)
Right, here's what I think is happening.
You're right that 0xc7addc80 is being cleaned up. So, we enter
kobject_cleanup() with kobj = 0xc7addc80. We get to this:
/* remove from sysfs if the caller did not do it */
if (kobj->state_in_sysfs) {
pr_debug("kobject: '%s' (%p): auto cleanup kobject_del\n",
kobject_name(kobj), kobj);
kobject_del(kobj);
}
So, we call kobject_del() on c7addc80 (which we can see in r4 in the
backtrace):
void kobject_del(struct kobject *kobj)
{
if (!kobj)
return;
sysfs_remove_dir(kobj);
kobj->state_in_sysfs = 0;
kobj_kset_leave(kobj);
kobject_put(kobj->parent);
And so we get to kobject_put(), and we call that with a pointer of
0xbf0554a0. This is a pointer into struct module. And this is where
the problem lies...
The struct module is free'd as part of the core of the module
(mod->module_core) here:
static void module_deallocate(struct module *mod, struct load_info *info)
{
kfree(info->strmap);
percpu_modfree(mod);
module_free(mod, mod->module_init);
module_free(mod, mod->module_core);
}
A struct module contains:
struct module
{
...
/* Sysfs stuff. */
struct module_kobject mkobj;
which in turn is defined as:
struct module_kobject {
struct kobject kobj;
...
}
So, we have a struct kobject contained within a data structure which is
independently allocated and freed - and this is highly illegal. I'm
sure GregKH will want to discuss this with Rusty...
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] s3c-hsudc: add a remove function
Am Sonntag 18 Dezember 2011, 21:39:53 schrieb Russell King - ARM Linux: > On Sun, Dec 18, 2011 at 09:24:12PM +0100, Heiko Stübner wrote: > > Am Sonntag 18 Dezember 2011, 20:45:18 schrieb Russell King - ARM Linux: > > > On Sun, Dec 18, 2011 at 08:33:32PM +0100, Heiko Stübner wrote: > > > > Am Sonntag 18 Dezember 2011, 20:01:02 schrieben Sie: > > > > > On Sun, Dec 18, 2011 at 07:50:37PM +0100, Heiko Stübner wrote: > > > > > > I didn't get this far. With your patch the Oopses already happen > > > > > > during the startup of the system / the loading of the modules. > > > > > > > > > > > > A bit of the message spew I got during testing with linux- > > > > next-20111216: > > > > > In some way, this is a good thing because it's showing that there's > > > > > problems with kobject lifetime rules. > > > > > > > > > > The #2 and further oops dumps are a result of corrupting the work > > > > > queues as a result of #1, so #2 onwards should be ignored. > > > > > > > > > > I suspect if you avoid loading the s3c_hsudc module these will go > > > > > away. > > > > > > > > nope :-), same faults happen even if s3c-hsudc is not present at all. > > > > So it seems, this delayed cleanup poses problems for other drivers as > > > > well. > > > > > > Okay, let's try to find out which one it is. Please use the attached > > > patch - it'll be a little more noisy, reporting which kobjects are > > > being released at the point when they're added to the workqueue. > > > > The cuplrit seems to be a kobject named "holders" and from what I > > gathered is from kernel/module.c and handling module sysfs entries. > > > > > > Partial log below: > > > > kobject: 'bq24022' (c78a9a80): kobject_release > > [...] > > kobject: 'gpio-vbus' (c78a9cc0): kobject_release > > [...] > > kobject: 'bq24022' (c78a9a80): kobject_cleanup > > kobject: 'gpio-vbus' (c78a9cc0): kobject_cleanup > > [...] > > Found /sbin/init, booting ... > > > > INIT: version 2.88 booting > > > > Starting the hotplug events dispatcher: udevdudevd[367]: starting version > > 172 . > > Synthesizing the initial hotplug events...done. > > Waiting for /dev to be fully populated... > > [...] > > Cleaning up ifupdown > > Loading kernel modules... > > kobject: 'holders' (c7addc80): kobject_release > > kobject: 'notes' (c7add080): kobject_release > > done. > > Activating lvm and md swap...done. > > Checking file systems...fsck from util-linux 2.19.1 > > done. > > [...] > > kobject: 'holders' (c7addc80): kobject_cleanup > > Unable to handle kernel paging request at virtual address bf055504 > > pgd = c0004000 > > [bf055504] *pgd=371f9811, *pte=, *ppte= > > Internal error: Oops: 7 [#1] > > Please post the entire first oops dump for the above run - it may contain > useful information to properly track this down. kobject: 'holders' (c7addc80): kobject_cleanup Unable to handle kernel paging request at virtual address bf055504 pgd = c0004000 [bf055504] *pgd=371f9811, *pte=, *ppte= Internal error: Oops: 7 [#1] Modules linked in: ohci_hcd usbcore leds_s3c24xx i2c_s3c2410 i2c_core CPU: 0Not tainted (3.2.0-rc5-next-20111216+ #33) PC is at kobject_put+0x18/0x7c LR is at kobject_del+0x64/0x70 pc : []lr : []psr: a013 sp : c70bdef8 ip : c70bdf18 fp : c70bdf14 r10: r9 : c0114718 r8 : c7803a00 r7 : c7abd360 r6 : c02e1de0 r5 : c7addca0 r4 : bf0554a0 r3 : 0001 r2 : r1 : r0 : bf0554a0 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 378ac000 DAC: 0017 Process kworker/0:1 (pid: 16, stack limit = 0xc70bc270) Stack: (0xc70bdef8 to 0xc70be000) dee0: c7addc80 c7addca0 df00: c02e1de0 c7addc80 c70bdf2c c70bdf18 c011470c c011461c c0114748 c7addc80 df20: c70bdf4c c70bdf30 c01147ec c01146b8 c7addca0 c785fd00 0009 df40: c70bdf84 c70bdf50 c00318fc c0114728 c02dbf00 c7803a05 c02dbf00 c785fd00 df60: c02dbf00 c785fd00 0009 c02dbf00 c785fd10 c70bc000 c70bdfbc c70bdf88 df80: c0032570 c00316c0 c7839edc c785fd10 c0032364 c70bdfcc c7839edc c785fd00 dfa0: c0032364 c70bdff4 c70bdfc0 c0037768 c0032374 dfc0: c7839edc c785fd00 c70bdfd0 c70bdfd0 c7839edc c00376e0 dfe0: c0021ac0 0013 c70bdff8 c0021ac0 c00376f0 59595959 59595959 Backtrace: [] (kobject_put+0x0/0x7c) from [] (kobject_del+0x64/0x70) r4:c7addc80 [] (kobject_del+0x0/0x70) from [] (kobject_delayed_cleanup+0xd4/0x174) r4:c7addc80 [] (kobject_delayed_cleanup+0x0/0x174) from [] (process_one_work+0x24c/0x3a8) r7:0009 r6: r5:c785fd00 r4:c7addca0 [] (process_one_work+0x0/0x3a8) from [] (worker_thread+0x20c/0x428) [] (worker_thread+0x0/0x428) from [] (kthread+0x88/0x90) [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x670) r7:0013 r6:c0021ac0 r5:c00376e0 r4:c7839edc Code: e24cb004 e24dd00c e2504000 0a13 (e5d43064) ---[ end trace 9e78135e0183be43 ]--- -- To unsubscribe from thi
Re: [PATCH 3/7] s3c-hsudc: add a remove function
On Sun, Dec 18, 2011 at 09:24:12PM +0100, Heiko Stübner wrote: > Am Sonntag 18 Dezember 2011, 20:45:18 schrieb Russell King - ARM Linux: > > On Sun, Dec 18, 2011 at 08:33:32PM +0100, Heiko Stübner wrote: > > > Am Sonntag 18 Dezember 2011, 20:01:02 schrieben Sie: > > > > On Sun, Dec 18, 2011 at 07:50:37PM +0100, Heiko Stübner wrote: > > > > > I didn't get this far. With your patch the Oopses already happen > > > > > during the startup of the system / the loading of the modules. > > > > > > > > > A bit of the message spew I got during testing with linux- > next-20111216: > > > > In some way, this is a good thing because it's showing that there's > > > > problems with kobject lifetime rules. > > > > > > > > The #2 and further oops dumps are a result of corrupting the work > > > > queues as a result of #1, so #2 onwards should be ignored. > > > > > > > > I suspect if you avoid loading the s3c_hsudc module these will go away. > > > > > > nope :-), same faults happen even if s3c-hsudc is not present at all. > > > So it seems, this delayed cleanup poses problems for other drivers as > > > well. > > > > Okay, let's try to find out which one it is. Please use the attached > > patch - it'll be a little more noisy, reporting which kobjects are > > being released at the point when they're added to the workqueue. > The cuplrit seems to be a kobject named "holders" and from what I > gathered is from kernel/module.c and handling module sysfs entries. > > > Partial log below: > > kobject: 'bq24022' (c78a9a80): kobject_release > [...] > kobject: 'gpio-vbus' (c78a9cc0): kobject_release > [...] > kobject: 'bq24022' (c78a9a80): kobject_cleanup > kobject: 'gpio-vbus' (c78a9cc0): kobject_cleanup > [...] > Found /sbin/init, booting ... > > INIT: version 2.88 booting > > Starting the hotplug events dispatcher: udevdudevd[367]: starting version 172 > . > Synthesizing the initial hotplug events...done. > Waiting for /dev to be fully populated... > [...] > Cleaning up ifupdown > Loading kernel modules... > kobject: 'holders' (c7addc80): kobject_release > kobject: 'notes' (c7add080): kobject_release > done. > Activating lvm and md swap...done. > Checking file systems...fsck from util-linux 2.19.1 > done. > [...] > kobject: 'holders' (c7addc80): kobject_cleanup > Unable to handle kernel paging request at virtual address bf055504 > pgd = c0004000 > [bf055504] *pgd=371f9811, *pte=, *ppte= > Internal error: Oops: 7 [#1] Please post the entire first oops dump for the above run - it may contain useful information to properly track this down. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] s3c-hsudc: add a remove function
Am Sonntag 18 Dezember 2011, 20:45:18 schrieb Russell King - ARM Linux: > On Sun, Dec 18, 2011 at 08:33:32PM +0100, Heiko Stübner wrote: > > Am Sonntag 18 Dezember 2011, 20:01:02 schrieben Sie: > > > On Sun, Dec 18, 2011 at 07:50:37PM +0100, Heiko Stübner wrote: > > > > I didn't get this far. With your patch the Oopses already happen > > > > during the startup of the system / the loading of the modules. > > > > > > > A bit of the message spew I got during testing with linux- next-20111216: > > > In some way, this is a good thing because it's showing that there's > > > problems with kobject lifetime rules. > > > > > > The #2 and further oops dumps are a result of corrupting the work > > > queues as a result of #1, so #2 onwards should be ignored. > > > > > > I suspect if you avoid loading the s3c_hsudc module these will go away. > > > > nope :-), same faults happen even if s3c-hsudc is not present at all. > > So it seems, this delayed cleanup poses problems for other drivers as > > well. > > Okay, let's try to find out which one it is. Please use the attached > patch - it'll be a little more noisy, reporting which kobjects are > being released at the point when they're added to the workqueue. The cuplrit seems to be a kobject named "holders" and from what I gathered is from kernel/module.c and handling module sysfs entries. Partial log below: kobject: 'bq24022' (c78a9a80): kobject_release [...] kobject: 'gpio-vbus' (c78a9cc0): kobject_release [...] kobject: 'bq24022' (c78a9a80): kobject_cleanup kobject: 'gpio-vbus' (c78a9cc0): kobject_cleanup [...] Found /sbin/init, booting ... INIT: version 2.88 booting Starting the hotplug events dispatcher: udevdudevd[367]: starting version 172 . Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated... [...] Cleaning up ifupdown Loading kernel modules... kobject: 'holders' (c7addc80): kobject_release kobject: 'notes' (c7add080): kobject_release done. Activating lvm and md swap...done. Checking file systems...fsck from util-linux 2.19.1 done. [...] kobject: 'holders' (c7addc80): kobject_cleanup Unable to handle kernel paging request at virtual address bf055504 pgd = c0004000 [bf055504] *pgd=371f9811, *pte=, *ppte= Internal error: Oops: 7 [#1] -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] s3c-hsudc: add a remove function
On Sun, Dec 18, 2011 at 08:33:32PM +0100, Heiko Stübner wrote:
> Am Sonntag 18 Dezember 2011, 20:01:02 schrieben Sie:
> > On Sun, Dec 18, 2011 at 07:50:37PM +0100, Heiko Stübner wrote:
> > > I didn't get this far. With your patch the Oopses already happen during
> > > the startup of the system / the loading of the modules.
> >
> > > A bit of the message spew I got during testing with linux-next-20111216:
> > In some way, this is a good thing because it's showing that there's
> > problems with kobject lifetime rules.
> >
> > The #2 and further oops dumps are a result of corrupting the work
> > queues as a result of #1, so #2 onwards should be ignored.
> >
> > I suspect if you avoid loading the s3c_hsudc module these will go away.
>
> nope :-), same faults happen even if s3c-hsudc is not present at all.
> So it seems, this delayed cleanup poses problems for other drivers as well.
Okay, let's try to find out which one it is. Please use the attached
patch - it'll be a little more noisy, reporting which kobjects are
being released at the point when they're added to the workqueue.
Thanks.
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index ad81e1c..be1c97a 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -26,6 +26,9 @@
#include
#include
#include
+#include
+
+#define KOBJECT_DEBUG_RELEASE
#define UEVENT_HELPER_PATH_LEN 256
#define UEVENT_NUM_ENVP32 /* number of env
pointers */
@@ -65,6 +68,9 @@ struct kobject {
struct kobj_type*ktype;
struct sysfs_dirent *sd;
struct kref kref;
+#ifdef KOBJECT_DEBUG_RELEASE
+ struct delayed_work release;
+#endif
unsigned int state_initialized:1;
unsigned int state_in_sysfs:1;
unsigned int state_add_uevent_sent:1;
diff --git a/lib/kobject.c b/lib/kobject.c
index 640bd98..5c01a78 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -540,7 +540,7 @@ static void kobject_cleanup(struct kobject *kobj)
struct kobj_type *t = get_ktype(kobj);
const char *name = kobj->name;
- pr_debug("kobject: '%s' (%p): %s\n",
+ pr_info("kobject: '%s' (%p): %s\n",
kobject_name(kobj), kobj, __func__);
if (t && !t->release)
@@ -575,9 +575,25 @@ static void kobject_cleanup(struct kobject *kobj)
}
}
+#ifdef KOBJECT_DEBUG_RELEASE
+static void kobject_delayed_cleanup(struct work_struct *work)
+{
+ kobject_cleanup(container_of(to_delayed_work(work),
+struct kobject, release));
+}
+#endif
+
static void kobject_release(struct kref *kref)
{
- kobject_cleanup(container_of(kref, struct kobject, kref));
+ struct kobject *kobj = container_of(kref, struct kobject, kref);
+#ifdef KOBJECT_DEBUG_RELEASE
+ pr_info("kobject: '%s' (%p): %s\n",
+kobject_name(kobj), kobj, __func__);
+ INIT_DELAYED_WORK(&kobj->release, kobject_delayed_cleanup);
+ schedule_delayed_work(&kobj->release, HZ);
+#else
+ kobject_cleanup(kobj);
+#endif
}
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] s3c-hsudc: add a remove function
Am Sonntag 18 Dezember 2011, 20:01:02 schrieben Sie: > On Sun, Dec 18, 2011 at 07:50:37PM +0100, Heiko Stübner wrote: > > I didn't get this far. With your patch the Oopses already happen during > > the startup of the system / the loading of the modules. > > > A bit of the message spew I got during testing with linux-next-20111216: > In some way, this is a good thing because it's showing that there's > problems with kobject lifetime rules. > > The #2 and further oops dumps are a result of corrupting the work > queues as a result of #1, so #2 onwards should be ignored. > > I suspect if you avoid loading the s3c_hsudc module these will go away. nope :-), same faults happen even if s3c-hsudc is not present at all. So it seems, this delayed cleanup poses problems for other drivers as well. Unable to handle kernel paging request at virtual address bf055504 pgd = c0004000 [bf055504] *pgd=3703b811, *pte=, *ppte= Internal error: Oops: 7 [#1] Modules linked in: ohci_hcd leds_s3c24xx usbcore i2c_s3c2410 i2c_core CPU: 0Not tainted (3.2.0-rc5-next-20111216+ #32) PC is at kobject_put+0x18/0x7c LR is at kobject_del+0x64/0x70 pc : []lr : []psr: a013 sp : c70bdef0 ip : c70bdf10 fp : c70bdf0c r10: r9 : c0114700 r8 : c7803a00 r7 : c7043200 r6 : c02e1de0 r5 : c70e5d20 r4 : bf0554a0 r3 : 0001 r2 : r1 : r0 : bf0554a0 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 37994000 DAC: 0017 Process kworker/0:1 (pid: 16, stack limit = 0xc70bc270) Stack: (0xc70bdef0 to 0xc70be000) dee0: c70e5d00 c70e5d20 c02e1de0 c70e5d00 df00: c70bdf24 c70bdf10 c01146f4 c0114604 c01365bc c70e5d00 c70bdf4c c70bdf28 df20: c01147f0 c01146a0 c0427c38 c785fd00 c70e5d20 c785fd00 0009 df40: c70bdf84 c70bdf50 c00318fc c0114710 c02dbf00 c7803a05 c02dbf00 c785fd00 df60: c02dbf00 c785fd00 0009 c02dbf00 c785fd10 c70bc000 c70bdfbc c70bdf88 df80: c0032570 c00316c0 c7839edc c785fd10 c0032364 c70bdfcc c7839edc c785fd00 dfa0: c0032364 c70bdff4 c70bdfc0 c0037768 c0032374 dfc0: c7839edc c785fd00 c70bdfd0 c70bdfd0 c7839edc c00376e0 dfe0: c0021ac0 0013 c70bdff8 c0021ac0 c00376f0 00190021 00024ea8 Backtrace: [] (kobject_put+0x0/0x7c) from [] (kobject_del+0x64/0x70) r4:c70e5d00 [] (kobject_del+0x0/0x70) from [] (kobject_delayed_cleanup+0xf0/0x198) r4:c70e5d00 [] (kobject_delayed_cleanup+0x0/0x198) from [] (process_one_work+0x24c/0x3a8) r7:0009 r6: r5:c785fd00 r4:c70e5d20 [] (process_one_work+0x0/0x3a8) from [] (worker_thread+0x20c/0x428) [] (worker_thread+0x0/0x428) from [] (kthread+0x88/0x90) [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x670) r7:0013 r6:c0021ac0 r5:c00376e0 r4:c7839edc Code: e24cb004 e24dd00c e2504000 0a13 (e5d43064) ---[ end trace ddf7f4f6a0de23b8 ]--- Unable to handle kernel paging request at virtual address fffc pgd = c0004000 [fffc] *pgd=37ffe831, *pte=, *ppte= Internal error: Oops: 17 [#2] Modules linked in: ohci_hcd leds_s3c24xx usbcore i2c_s3c2410 i2c_core CPU: 0Tainted: G D (3.2.0-rc5-next-20111216+ #32) PC is at kthread_data+0x10/0x18 LR is at wq_worker_sleeping+0x18/0xbc pc : []lr : []psr: 2093 sp : c70bdb58 ip : c70bdb68 fp : c70bdb64 r10: c70bc000 r9 : c70bdb90 r8 : c02dc500 r7 : c7826000 r6 : c708cb00 r5 : c708cc54 r4 : r3 : r2 : c02dc500 r1 : r0 : c708cb00 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: 37994000 DAC: 0015 Process kworker/0:1 (pid: 16, stack limit = 0xc70bc270) Stack: (0xc70bdb58 to 0xc70be000) db40: c70bdb7c c70bdb68 db60: c0033974 c00371c4 c003f760 0001 c70bdc04 c70bdb80 c0218ebc c003396c db80: c0406680 c70b4a40 05fb c001c678 0168 c70bdbcc c70bdba8 dba0: c008cb78 c008b680 c0034390 c708cb00 c70b8440 0001 c70b4a40 dbc0: c70bdbdc c70bdbd0 c001c678 c708cb00 c70bdc14 c70bdbe0 c0020db4 0001 dbe0: c70bdc24 c708cb00 c7826000 c708cbd8 c708caf8 c708cbd8 c70bdc14 c70bdc08 dc00: c02194cc c0218dfc c70bdc3c c70bdc18 c0022100 c0219468 0008 0001 dc20: c70bdc3c c70bdc24 c70bdc24 c708cc20 c70bdcb4 c70bdc40 c001222c c0021ad0 dc40: c70bc270 000b 7269762f 6500 62633432 20343030 64343265 dc60: 63303064 35326520 30303430 61302030 30303030 28203331 34643565 34363033 dc80: c0002029 c0217dd8 c027dcbb bf055504 c70bdea8 0007 dca0: 0007 c70bdcdc c70bdcb8 c0013808 c0011f80 c02d5ccc dcc0: a013 c70bdea8 bf055504 c708cb00 c70bddf4 c70bdce0 c0013b58 c00137a8 dce0: bf017fcc bf01a0c8 c70bddc4 c70bdd00 bf01958c 0028 dd00: c70bdd88 0004 0001 c708dbb0 0004 0002 c798e280 dd20: c708cb30 c708dbb0 c70bdd6c c70bdd40 c0040e34 c0040b20 dd40: c00
Re: [PATCH 3/7] s3c-hsudc: add a remove function
On Sun, Dec 18, 2011 at 07:50:37PM +0100, Heiko Stübner wrote: > I didn't get this far. With your patch the Oopses already happen during > the startup of the system / the loading of the modules. > > A bit of the message spew I got during testing with linux-next-20111216: In some way, this is a good thing because it's showing that there's problems with kobject lifetime rules. The #2 and further oops dumps are a result of corrupting the work queues as a result of #1, so #2 onwards should be ignored. I suspect if you avoid loading the s3c_hsudc module these will go away. > > pgd = c0004000 > [bf05b504] *pgd=379af811, *pte=, *ppte= > Internal error: Oops: 7 [#1] > Modules linked in: ohci_hcd leds_s3c24xx usbcore i2c_s3c2410 i2c_core > s3c_hsudc > CPU: 0Not tainted (3.2.0-rc5-next-20111216+ #32) > PC is at kobject_put+0x18/0x7c > LR is at kobject_del+0x64/0x70 > pc : []lr : []psr: a013 > sp : c70bdef0 ip : c70bdf10 fp : c70bdf0c > r10: r9 : c0114700 r8 : c7803a00 > r7 : c79257a0 r6 : c02e1de0 r5 : c79a0120 r4 : bf05b4a0 > r3 : 0001 r2 : r1 : r0 : bf05b4a0 > Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel > Control: 0005317f Table: 37014000 DAC: 0017 > Process kworker/0:1 (pid: 16, stack limit = 0xc70bc270) > Stack: (0xc70bdef0 to 0xc70be000) > dee0: c79a0100 c79a0120 c02e1de0 c79a0100 > df00: c70bdf24 c70bdf10 c01146f4 c0114604 c01365bc c79a0100 c70bdf4c c70bdf28 > df20: c01147f0 c01146a0 c0136640 c0136590 c79a0120 c785fd00 0009 > df40: c70bdf84 c70bdf50 c00318fc c0114710 c02dbf00 c7803a05 c02dbf00 c785fd00 > df60: c02dbf00 c785fd00 0009 c02dbf00 c785fd10 c70bc000 c70bdfbc c70bdf88 > df80: c0032570 c00316c0 c7839edc c785fd10 c0032364 c70bdfcc c7839edc c785fd00 > dfa0: c0032364 c70bdff4 c70bdfc0 c0037768 c0032374 > dfc0: c7839edc c785fd00 c70bdfd0 c70bdfd0 c7839edc c00376e0 > dfe0: c0021ac0 0013 c70bdff8 c0021ac0 c00376f0 00190021 00024ea8 > Backtrace: > [] (kobject_put+0x0/0x7c) from [] (kobject_del+0x64/0x70) > r4:c79a0100 > [] (kobject_del+0x0/0x70) from [] > (kobject_delayed_cleanup+0xf0/0x198) > r4:c79a0100 > [] (kobject_delayed_cleanup+0x0/0x198) from [] > (process_one_work+0x24c/0x3a8) > r7:0009 r6: r5:c785fd00 r4:c79a0120 > [] (process_one_work+0x0/0x3a8) from [] > (worker_thread+0x20c/0x428) > [] (worker_thread+0x0/0x428) from [] (kthread+0x88/0x90) > [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x670) > r7:0013 r6:c0021ac0 r5:c00376e0 r4:c7839edc > Code: e24cb004 e24dd00c e2504000 0a13 (e5d43064) > ---[ end trace ddf7f4f6a0de23b8 ]--- > Unable to handle kernel paging request at virtual address fffc > pgd = c0004000 > [fffc] *pgd=37ffe831, *pte=, *ppte= > Internal error: Oops: 17 [#2] > Modules linked in: ohci_hcd leds_s3c24xx usbcore i2c_s3c2410 i2c_core > s3c_hsudc > CPU: 0Tainted: G D (3.2.0-rc5-next-20111216+ #32) > PC is at kthread_data+0x10/0x18 > LR is at wq_worker_sleeping+0x18/0xbc > pc : []lr : []psr: 2093 > sp : c70bdb58 ip : c70bdb68 fp : c70bdb64 > r10: c70bc000 r9 : c70bdb90 r8 : c02dc500 > r7 : c7826000 r6 : c708cb00 r5 : c708cc54 r4 : > r3 : r2 : c02dc500 r1 : r0 : c708cb00 > Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user > Control: 0005317f Table: 37014000 DAC: 0015 > Process kworker/0:1 (pid: 16, stack limit = 0xc70bc270) > Stack: (0xc70bdb58 to 0xc70be000) > db40: c70bdb7c c70bdb68 > db60: c0033974 c00371c4 c003f760 0001 c70bdc04 c70bdb80 c0218ebc c003396c > db80: c0406680 c70b4a40 0664 c001c678 0168 c70bdbcc c70bdba8 > dba0: c008cb78 c008b680 c0034390 c708cb00 c70b8440 0001 c70b4a40 > dbc0: c70bdbdc c70bdbd0 c001c678 c708cb00 c70bdc14 c70bdbe0 c0020db4 0001 > dbe0: c70bdc24 c708cb00 c7826000 c708cbd8 c708caf8 c708cbd8 c70bdc14 c70bdc08 > dc00: c02194cc c0218dfc c70bdc3c c70bdc18 c0022100 c0219468 0008 0001 > dc20: c70bdc3c c70bdc24 c70bdc24 c708cc20 c70bdcb4 c70bdc40 c001222c c0021ad0 > dc40: c70bc270 000b 7269762f 6500 62633432 20343030 64343265 > dc60: 63303064 35326520 30303430 61302030 30303030 28203331 34643565 34363033 > dc80: c0002029 c0217dd8 c027dcbb bf05b504 c70bdea8 0007 > dca0: 0007 c70bdcdc c70bdcb8 c0013808 c0011f80 c02d5ccc > dcc0: a013 c70bdea8 bf05b504 c708cb00 c70bddf4 c70bdce0 c0013b58 c00137a8 > dce0: bf01dfcc bf0200c8 c70bddc4 c70bdd00 bf01f58c 0028 > dd00: c70bdd88 0004 0001 c708dbb0 0004 0002 c7a7e5e0 > dd20: c708cb30 c708dbb0 c70bdd6c c70bdd40 c0040e34 c0040b20 > dd40: c003f79c c021bf08 c02dc500 c708cb00 00c3 0001 0001 0001 > dd60: c70bdd8c c70bdd70 c003e080 c0040d7
Re: [PATCH 3/7] s3c-hsudc: add a remove function
Am Sonntag 18 Dezember 2011, 15:43:19 schrieb Russell King - ARM Linux: > On Sun, Dec 18, 2011 at 02:44:39PM +0100, Heiko Stübner wrote: > > Am Sonntag 18 Dezember 2011, 09:10:48 schrieb Russell King - ARM Linux: > > > On Sat, Dec 17, 2011 at 08:26:33PM +0100, Heiko Stübner wrote: > > > > As the driver is also buildable as a module it should need > > > > a cleanup function for the removal of the module. > > > > > > My guess is that this wasn't implemented because of the embedded struct > > > device lifetime rules for the gadget - to prevent the unbinding of the > > > driver. > > > > > > Until the struct device lifetime gets fixed, you must not allow the > > > module nor the data structure containing the struct device to be > > > freed. > > > > I understand where this problem comes from (the release method is > > potentially gone with the module before it is called) but after more > > reading, I have a hard time believing that a lot of the other gadget > > drivers would be wrong as well. Some of them since 2009 or possibly > > earlier. > > > > Gadgets with embedded release methods: langwell_udc, goku_udc, fsl_qe_udc > > (and fsl_udc_core), amd5536udc, net2280, pch_udc, cil13xxx_udc, > > dummy_hcd, omap_udc, net2272, mc_udc_core > > > > Gadgets which use the release method from its pdev->dev but also free the > > struct with the gadget in their remove method: r8a66597-udc, m66592-udc, > > fusb300_udc. (possibly before the release function is called) > > > > On the other hand, the gets and puts of the udc->gadget.dev should be > > paired correctly and it's only an intermediate device between the udc > > and the gadget driver, so that the call to device_unregister in the > > remove method should put the refcount to 0 and thus init the cleanup > > (including the call to release) before the module is removed. > > > > So, I am very confused :-). > > Try this patch. If your system oopses 5 seconds after you remove the > module, you have a lifetime bug. I didn't get this far. With your patch the Oopses already happen during the startup of the system / the loading of the modules. A bit of the message spew I got during testing with linux-next-20111216: pgd = c0004000 [bf05b504] *pgd=379af811, *pte=, *ppte= Internal error: Oops: 7 [#1] Modules linked in: ohci_hcd leds_s3c24xx usbcore i2c_s3c2410 i2c_core s3c_hsudc CPU: 0Not tainted (3.2.0-rc5-next-20111216+ #32) PC is at kobject_put+0x18/0x7c LR is at kobject_del+0x64/0x70 pc : []lr : []psr: a013 sp : c70bdef0 ip : c70bdf10 fp : c70bdf0c r10: r9 : c0114700 r8 : c7803a00 r7 : c79257a0 r6 : c02e1de0 r5 : c79a0120 r4 : bf05b4a0 r3 : 0001 r2 : r1 : r0 : bf05b4a0 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 37014000 DAC: 0017 Process kworker/0:1 (pid: 16, stack limit = 0xc70bc270) Stack: (0xc70bdef0 to 0xc70be000) dee0: c79a0100 c79a0120 c02e1de0 c79a0100 df00: c70bdf24 c70bdf10 c01146f4 c0114604 c01365bc c79a0100 c70bdf4c c70bdf28 df20: c01147f0 c01146a0 c0136640 c0136590 c79a0120 c785fd00 0009 df40: c70bdf84 c70bdf50 c00318fc c0114710 c02dbf00 c7803a05 c02dbf00 c785fd00 df60: c02dbf00 c785fd00 0009 c02dbf00 c785fd10 c70bc000 c70bdfbc c70bdf88 df80: c0032570 c00316c0 c7839edc c785fd10 c0032364 c70bdfcc c7839edc c785fd00 dfa0: c0032364 c70bdff4 c70bdfc0 c0037768 c0032374 dfc0: c7839edc c785fd00 c70bdfd0 c70bdfd0 c7839edc c00376e0 dfe0: c0021ac0 0013 c70bdff8 c0021ac0 c00376f0 00190021 00024ea8 Backtrace: [] (kobject_put+0x0/0x7c) from [] (kobject_del+0x64/0x70) r4:c79a0100 [] (kobject_del+0x0/0x70) from [] (kobject_delayed_cleanup+0xf0/0x198) r4:c79a0100 [] (kobject_delayed_cleanup+0x0/0x198) from [] (process_one_work+0x24c/0x3a8) r7:0009 r6: r5:c785fd00 r4:c79a0120 [] (process_one_work+0x0/0x3a8) from [] (worker_thread+0x20c/0x428) [] (worker_thread+0x0/0x428) from [] (kthread+0x88/0x90) [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x670) r7:0013 r6:c0021ac0 r5:c00376e0 r4:c7839edc Code: e24cb004 e24dd00c e2504000 0a13 (e5d43064) ---[ end trace ddf7f4f6a0de23b8 ]--- Unable to handle kernel paging request at virtual address fffc pgd = c0004000 [fffc] *pgd=37ffe831, *pte=, *ppte= Internal error: Oops: 17 [#2] Modules linked in: ohci_hcd leds_s3c24xx usbcore i2c_s3c2410 i2c_core s3c_hsudc CPU: 0Tainted: G D (3.2.0-rc5-next-20111216+ #32) PC is at kthread_data+0x10/0x18 LR is at wq_worker_sleeping+0x18/0xbc pc : []lr : []psr: 2093 sp : c70bdb58 ip : c70bdb68 fp : c70bdb64 r10: c70bc000 r9 : c70bdb90 r8 : c02dc500 r7 : c7826000 r6 : c708cb00 r5 : c708cc54 r4 : r3 : r2 : c02dc500 r1 : r0 : c708cb00 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: 37014000 DAC: 0015 Proce
Re: [PATCH v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On Mon, Dec 19, 2011 at 01:04:18AM +0900, Kukjin Kim wrote: > Hmm, I cannot find the iommu/exynos branch what you said in your iommu > tree yet. Maybe you missed or any problem? Problems. I tried to apply the patches and there were conflicts. After solving them I wasn't able to find a kernel-config for Exynos that conpiled for upstream Linux. Additionally new objections were raised about the patches. Enough to not merge these patches at this point. When I have a config to at least compile-test the code you send me and repost the patches rebased to a recent upstream commit with the objections fixed I can retry to merge it. Thanks, Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On 12/02/11 17:49, 'Joerg Roedel' wrote: On Fri, Dec 02, 2011 at 05:43:21PM +0900, Kukjin Kim wrote: OK, I will merge iommu/exynos into Samsung tree after your creating that. I can't look at iommu/exynos branch in your tree, git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git. That's because I havn't merged any exynos patches yet :) But I will create it soon an merge this driver. Hi Joerg, Hmm, I cannot find the iommu/exynos branch what you said in your iommu tree yet. Maybe you missed or any problem? Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.
On 12/16/11 17:24, Kyungmin Park wrote:
Hi Mr. Kim,
It's maybe missing for v3.3 merge at samsung soc.
Please give your opinion, how to handle it?
Looks ok to me at the moment, and as a note, I'm sorting it out now.
If you don't mind it, it can merge it by devfreq.
Hmm, I think, it should be handled in samsung tree to avoid useless
conflicts with others. And if you need this in the devfreq tree now,
please let me know so that I can create topic branch for it.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
On 12/1/11, MyungJoo Ham wrote:
- Add DMC1
- Enlarge address space for DMC from 4k to 64k so that PPMU registers
may be accessed.
Signed-off-by: MyungJoo Ham
Signed-off-by: Kyungmin Park
---
arch/arm/mach-exynos/cpu.c |7 ++-
arch/arm/mach-exynos/include/mach/map.h |1 +
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
index 90ec247..8bdcba9 100644
--- a/arch/arm/mach-exynos/cpu.c
+++ b/arch/arm/mach-exynos/cpu.c
@@ -108,7 +108,12 @@ static struct map_desc exynos4_iodesc[] __initdata = {
}, {
.virtual= (unsigned long)S5P_VA_DMC0,
.pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
- .length = SZ_4K,
+ .length = SZ_64K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual= (unsigned long)S5P_VA_DMC1,
+ .pfn= __phys_to_pfn(EXYNOS4_PA_DMC1),
+ .length = SZ_64K,
.type = MT_DEVICE,
}, {
.virtual= (unsigned long)S5P_VA_SROMC,
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 058541d..870a980 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -57,6 +57,7 @@
#define EXYNOS4_PA_KEYPAD 0x100A
#define EXYNOS4_PA_DMC0 0x1040
+#define EXYNOS4_PA_DMC10x1041
#define EXYNOS4_PA_COMBINER 0x1044
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Samsung devel-1 for v3.3
On 12/17/11 00:22, Arnd Bergmann wrote: On Friday 16 December 2011, Kukjin Kim wrote: Please pull next-samsung-devel for v3.3. It includes DT support for EXYNOS, update Cragganmore board and SPI clkdev support. As a note, out of arch/arm/samsung stuff got the ack from regarding maintainers and actually, it has been included in linux-next for long time so I think, it has no problem for v3.3. One more, I need to follow up Russell and some arm consolidation work and one plat-samsung directory and apply some patches in my mail-box ;) It will be sent to you soon. If any problems, please let me know. The patches look really good for the most part, but I'd rather not take them like this because you have put so many different things into a single branch. Your branch is much larger than any of the others that are currently queued in arm-soc. Can you split it up into separate branches for dt, board and clkdev and driver changes or something along those lines? Sure, I will re-send 'pull request' with separated topic branches. A number of changes in here also seem to qualify as cleanups, so they might better be held in a branch for that. I'm not sure which commits are cleanups what you said, but let me sort them out again when I re-send. I also found one commit that I think should not be there: 25767e69 "ARM: EXYNOS: Add ioremap interceptor for statically remapped regions" from Thomas Abraham. As far as I know, the work that Nico did on the vmalloc_end elimination will conflict with this patch and solve the problem in a better way. Yes, you're right. There are discussions about Nicolas' patch when it was submitted and since it was not available at that time, it has been added into my tree before 3.2 merge window. Anyway, let me sort it out. I have now pulled in everything up to 39cb263ecc "ARM: S3C64XX: Hook up VDDINT on Cragganmore" into a samsung/board branch and merged that into the next/board branch, because that was easy to do without rebasing. Well, I think it should be included in next/devel branch, because they are developing of Cragganmore boards not adding new board which is the purpose of next/board branch what you said. But if you want it, I will. The rest should be fairly easy to split up into the branches I mentioned if you don't mind rebasing them (best leaving them on v3.2-rc1 though). Without rebasing, it would get a bit trickier but we could easily make 39ae3685 "ARM: dts: Add intial dts file for EXYNOS4210 SoC, SMDKV310 and ORIGEN" the samsung/dt branch and revert the ioremap interceptor on top of that. The samsung/clkdev branch probably should depend on the samsung/dt branch anyway, so it can remain on top without getting rebased. Okay, I will. I can probably fix this all up (this time) in the way I want it, or let you take care of it and send me new pull requests, whichever you prefer. Let me sort our my branches soon :) Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] s3c-hsudc: add a remove function
On Sun, Dec 18, 2011 at 02:44:39PM +0100, Heiko Stübner wrote:
> Am Sonntag 18 Dezember 2011, 09:10:48 schrieb Russell King - ARM Linux:
> > On Sat, Dec 17, 2011 at 08:26:33PM +0100, Heiko Stübner wrote:
> > > As the driver is also buildable as a module it should need
> > > a cleanup function for the removal of the module.
> >
> > My guess is that this wasn't implemented because of the embedded struct
> > device lifetime rules for the gadget - to prevent the unbinding of the
> > driver.
> >
> > Until the struct device lifetime gets fixed, you must not allow the module
> > nor the data structure containing the struct device to be freed.
>
> I understand where this problem comes from (the release method is potentially
> gone with the module before it is called) but after more reading, I have a
> hard time believing that a lot of the other gadget drivers would be wrong as
> well. Some of them since 2009 or possibly earlier.
>
> Gadgets with embedded release methods: langwell_udc, goku_udc, fsl_qe_udc
> (and
> fsl_udc_core), amd5536udc, net2280, pch_udc, cil13xxx_udc, dummy_hcd,
> omap_udc, net2272, mc_udc_core
>
> Gadgets which use the release method from its pdev->dev but also free the
> struct with the gadget in their remove method: r8a66597-udc, m66592-udc,
> fusb300_udc. (possibly before the release function is called)
>
> On the other hand, the gets and puts of the udc->gadget.dev should be paired
> correctly and it's only an intermediate device between the udc and the gadget
> driver, so that the call to device_unregister in the remove method should put
> the refcount to 0 and thus init the cleanup (including the call to release)
> before the module is removed.
>
> So, I am very confused :-).
Try this patch. If your system oopses 5 seconds after you remove the
module, you have a lifetime bug.
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index ad81e1c..be1c97a 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -26,6 +26,9 @@
#include
#include
#include
+#include
+
+#define KOBJECT_DEBUG_RELEASE
#define UEVENT_HELPER_PATH_LEN 256
#define UEVENT_NUM_ENVP32 /* number of env
pointers */
@@ -65,6 +68,9 @@ struct kobject {
struct kobj_type*ktype;
struct sysfs_dirent *sd;
struct kref kref;
+#ifdef KOBJECT_DEBUG_RELEASE
+ struct delayed_work release;
+#endif
unsigned int state_initialized:1;
unsigned int state_in_sysfs:1;
unsigned int state_add_uevent_sent:1;
diff --git a/lib/kobject.c b/lib/kobject.c
index 640bd98..fe57f3a 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -575,9 +575,23 @@ static void kobject_cleanup(struct kobject *kobj)
}
}
+#ifdef KOBJECT_DEBUG_RELEASE
+static void kobject_delayed_cleanup(struct work_struct *work)
+{
+ kobject_cleanup(container_of(to_delayed_work(work),
+struct kobject, release));
+}
+#endif
+
static void kobject_release(struct kref *kref)
{
- kobject_cleanup(container_of(kref, struct kobject, kref));
+ struct kobject *kobj = container_of(kref, struct kobject, kref);
+#ifdef KOBJECT_DEBUG_RELEASE
+ INIT_DELAYED_WORK(&kobj->release, kobject_delayed_cleanup);
+ schedule_delayed_work(&kobj->release, 5 * HZ);
+#else
+ kobject_cleanup(kobj);
+#endif
}
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] s3c-hsudc: add a remove function
Am Sonntag 18 Dezember 2011, 09:10:48 schrieb Russell King - ARM Linux:
> On Sat, Dec 17, 2011 at 08:26:33PM +0100, Heiko Stübner wrote:
> > As the driver is also buildable as a module it should need
> > a cleanup function for the removal of the module.
>
> My guess is that this wasn't implemented because of the embedded struct
> device lifetime rules for the gadget - to prevent the unbinding of the
> driver.
>
> Until the struct device lifetime gets fixed, you must not allow the module
> nor the data structure containing the struct device to be freed.
I understand where this problem comes from (the release method is potentially
gone with the module before it is called) but after more reading, I have a
hard time believing that a lot of the other gadget drivers would be wrong as
well. Some of them since 2009 or possibly earlier.
Gadgets with embedded release methods: langwell_udc, goku_udc, fsl_qe_udc (and
fsl_udc_core), amd5536udc, net2280, pch_udc, cil13xxx_udc, dummy_hcd,
omap_udc, net2272, mc_udc_core
Gadgets which use the release method from its pdev->dev but also free the
struct with the gadget in their remove method: r8a66597-udc, m66592-udc,
fusb300_udc. (possibly before the release function is called)
On the other hand, the gets and puts of the udc->gadget.dev should be paired
correctly and it's only an intermediate device between the udc and the gadget
driver, so that the call to device_unregister in the remove method should put
the refcount to 0 and thus init the cleanup (including the call to release)
before the module is removed.
So, I am very confused :-).
Heiko
> > Signed-off-by: Heiko Stuebner
> > ---
> >
> > drivers/usb/gadget/s3c-hsudc.c | 25 +
> > 1 files changed, 25 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/s3c-hsudc.c
> > b/drivers/usb/gadget/s3c-hsudc.c index 3e5673d..7cb0850 100644
> > --- a/drivers/usb/gadget/s3c-hsudc.c
> > +++ b/drivers/usb/gadget/s3c-hsudc.c
> >
> > @@ -1370,12 +1370,37 @@ err_res:
> > return ret;
> >
> > }
> >
> > +static int __devexit s3c_hsudc_remove(struct platform_device *pdev)
> > +{
> > + struct s3c_hsudc *hsudc = the_controller;
> > +
> > + usb_del_gadget_udc(&hsudc->gadget);
> > +
> > + clk_disable(hsudc->uclk);
> > + clk_put(hsudc->uclk);
> > +
> > + free_irq(hsudc->irq, hsudc);
> > +
> > + iounmap(hsudc->regs);
> > +
> > + release_resource(hsudc->mem_rsrc);
> > + kfree(hsudc->mem_rsrc);
> > +
> > + if (hsudc->transceiver)
> > + otg_put_transceiver(hsudc->transceiver);
> > +
> > + the_controller = NULL;
> > + kfree(hsudc);
> > + return 0;
> > +}
> > +
> >
> > static struct platform_driver s3c_hsudc_driver = {
> >
> > .driver = {
> >
> > .owner = THIS_MODULE,
> > .name = "s3c-hsudc",
> >
> > },
> > .probe = s3c_hsudc_probe,
> >
> > + .remove = __devexit_p(s3c_hsudc_remove),
> >
> > };
> >
> > module_platform_driver(s3c_hsudc_driver);
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] s3c-hsudc: add a remove function
Am Sonntag 18 Dezember 2011, 09:10:48 schrieb Russell King - ARM Linux:
> On Sat, Dec 17, 2011 at 08:26:33PM +0100, Heiko Stübner wrote:
> > As the driver is also buildable as a module it should need
> > a cleanup function for the removal of the module.
>
> My guess is that this wasn't implemented because of the embedded struct
> device lifetime rules for the gadget - to prevent the unbinding of the
> driver.
>
> Until the struct device lifetime gets fixed, you must not allow the module
> nor the data structure containing the struct device to be freed.
so essentially, this patch and the release stuff in 5/7 must go.
Thanks for pointing out this problem.
> > Signed-off-by: Heiko Stuebner
> > ---
> >
> > drivers/usb/gadget/s3c-hsudc.c | 25 +
> > 1 files changed, 25 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/s3c-hsudc.c
> > b/drivers/usb/gadget/s3c-hsudc.c index 3e5673d..7cb0850 100644
> > --- a/drivers/usb/gadget/s3c-hsudc.c
> > +++ b/drivers/usb/gadget/s3c-hsudc.c
> >
> > @@ -1370,12 +1370,37 @@ err_res:
> > return ret;
> >
> > }
> >
> > +static int __devexit s3c_hsudc_remove(struct platform_device *pdev)
> > +{
> > + struct s3c_hsudc *hsudc = the_controller;
> > +
> > + usb_del_gadget_udc(&hsudc->gadget);
> > +
> > + clk_disable(hsudc->uclk);
> > + clk_put(hsudc->uclk);
> > +
> > + free_irq(hsudc->irq, hsudc);
> > +
> > + iounmap(hsudc->regs);
> > +
> > + release_resource(hsudc->mem_rsrc);
> > + kfree(hsudc->mem_rsrc);
> > +
> > + if (hsudc->transceiver)
> > + otg_put_transceiver(hsudc->transceiver);
> > +
> > + the_controller = NULL;
> > + kfree(hsudc);
> > + return 0;
> > +}
> > +
> >
> > static struct platform_driver s3c_hsudc_driver = {
> >
> > .driver = {
> >
> > .owner = THIS_MODULE,
> > .name = "s3c-hsudc",
> >
> > },
> > .probe = s3c_hsudc_probe,
> >
> > + .remove = __devexit_p(s3c_hsudc_remove),
> >
> > };
> >
> > module_platform_driver(s3c_hsudc_driver);
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] s3c-hsudc: add a remove function
On Sat, Dec 17, 2011 at 08:26:33PM +0100, Heiko Stübner wrote:
> As the driver is also buildable as a module it should need
> a cleanup function for the removal of the module.
My guess is that this wasn't implemented because of the embedded struct
device lifetime rules for the gadget - to prevent the unbinding of the
driver.
Until the struct device lifetime gets fixed, you must not allow the module
nor the data structure containing the struct device to be freed.
> Signed-off-by: Heiko Stuebner
> ---
> drivers/usb/gadget/s3c-hsudc.c | 25 +
> 1 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
> index 3e5673d..7cb0850 100644
> --- a/drivers/usb/gadget/s3c-hsudc.c
> +++ b/drivers/usb/gadget/s3c-hsudc.c
> @@ -1370,12 +1370,37 @@ err_res:
> return ret;
> }
>
> +static int __devexit s3c_hsudc_remove(struct platform_device *pdev)
> +{
> + struct s3c_hsudc *hsudc = the_controller;
> +
> + usb_del_gadget_udc(&hsudc->gadget);
> +
> + clk_disable(hsudc->uclk);
> + clk_put(hsudc->uclk);
> +
> + free_irq(hsudc->irq, hsudc);
> +
> + iounmap(hsudc->regs);
> +
> + release_resource(hsudc->mem_rsrc);
> + kfree(hsudc->mem_rsrc);
> +
> + if (hsudc->transceiver)
> + otg_put_transceiver(hsudc->transceiver);
> +
> + the_controller = NULL;
> + kfree(hsudc);
> + return 0;
> +}
> +
> static struct platform_driver s3c_hsudc_driver = {
> .driver = {
> .owner = THIS_MODULE,
> .name = "s3c-hsudc",
> },
> .probe = s3c_hsudc_probe,
> + .remove = __devexit_p(s3c_hsudc_remove),
> };
>
> module_platform_driver(s3c_hsudc_driver);
> --
> 1.7.2.3
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] s3c-hsudc: move device registration to probe and remove
On Sat, Dec 17, 2011 at 08:28:34PM +0100, Heiko Stübner wrote:
> Instead of adding and deleting the gadget device in the start and stop
> invocations. Use device_register in the probe method to initialize
> and add the gadget device and unregister it in the remove function.
>
> This also requires a release function for the gadget device.
Ouch. This is a sure sign that your code is broken. The lifetime of a
device structure is rather indeterminant, and modules should not contain
release functions for these.
> Signed-off-by: Heiko Stuebner
> ---
> drivers/usb/gadget/s3c-hsudc.c | 27 ++-
> 1 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
> index 06ca8c4..fa2ae7a 100644
> --- a/drivers/usb/gadget/s3c-hsudc.c
> +++ b/drivers/usb/gadget/s3c-hsudc.c
> @@ -1156,11 +1156,6 @@ static int s3c_hsudc_start(struct usb_gadget_driver
> *driver,
> hsudc->driver = driver;
> hsudc->gadget.dev.driver = &driver->driver;
> hsudc->gadget.speed = USB_SPEED_UNKNOWN;
> - ret = device_add(&hsudc->gadget.dev);
> - if (ret) {
> - dev_err(hsudc->dev, "failed to probe gadget device");
> - return ret;
> - }
>
> ret = bind(&hsudc->gadget);
> if (ret) {
> @@ -1180,8 +1175,6 @@ static int s3c_hsudc_start(struct usb_gadget_driver
> *driver,
> hsudc->gadget.name);
> driver->unbind(&hsudc->gadget);
>
> - device_del(&hsudc->gadget.dev);
> -
> hsudc->driver = NULL;
> hsudc->gadget.dev.driver = NULL;
> return ret;
> @@ -1222,7 +1215,6 @@ static int s3c_hsudc_stop(struct usb_gadget_driver
> *driver)
> (void) otg_set_peripheral(hsudc->transceiver, NULL);
>
> driver->unbind(&hsudc->gadget);
> - device_del(&hsudc->gadget.dev);
> disable_irq(hsudc->irq);
>
> dev_info(hsudc->dev, "unregistered gadget driver '%s'\n",
> @@ -1260,6 +1252,13 @@ static struct usb_gadget_ops s3c_hsudc_gadget_ops = {
> .vbus_draw = s3c_hsudc_vbus_draw,
> };
>
> +/* The gadget structure is stored inside the hsudc structure and will be
> + * released along with it. */
> +static void s3c_hsudc_gadget_release(struct device *dev)
> +{
> + return;
> +}
> +
> static int __devinit s3c_hsudc_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -1307,7 +1306,6 @@ static int __devinit s3c_hsudc_probe(struct
> platform_device *pdev)
>
> spin_lock_init(&hsudc->lock);
>
> - device_initialize(&hsudc->gadget.dev);
> dev_set_name(&hsudc->gadget.dev, "gadget");
>
> hsudc->gadget.max_speed = USB_SPEED_HIGH;
> @@ -1315,6 +1313,7 @@ static int __devinit s3c_hsudc_probe(struct
> platform_device *pdev)
> hsudc->gadget.name = dev_name(dev);
> hsudc->gadget.dev.parent = dev;
> hsudc->gadget.dev.dma_mask = dev->dma_mask;
> + hsudc->gadget.dev.release = s3c_hsudc_gadget_release;
> hsudc->gadget.ep0 = &hsudc->ep[0].ep;
>
> hsudc->gadget.is_otg = 0;
> @@ -1348,12 +1347,20 @@ static int __devinit s3c_hsudc_probe(struct
> platform_device *pdev)
> disable_irq(hsudc->irq);
> local_irq_enable();
>
> + ret = device_register(&hsudc->gadget.dev);
> + if (ret) {
> + put_device(&hsudc->gadget.dev);
> + goto err_add_device;
> + }
> +
> ret = usb_add_gadget_udc(&pdev->dev, &hsudc->gadget);
> if (ret)
> goto err_add_udc;
>
> return 0;
> err_add_udc:
> + device_unregister(&hsudc->gadget.dev);
> +err_add_device:
> clk_disable(hsudc->uclk);
> clk_put(hsudc->uclk);
> err_clk:
> @@ -1379,6 +1386,8 @@ static int __devexit s3c_hsudc_remove(struct
> platform_device *pdev)
>
> usb_del_gadget_udc(&hsudc->gadget);
>
> + device_unregister(&hsudc->gadget.dev);
> +
> clk_disable(hsudc->uclk);
> clk_put(hsudc->uclk);
>
> --
> 1.7.2.3
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] s3c-hsudc: add a remove function
On Sat, Dec 17, 2011 at 08:26:33PM +0100, Heiko Stübner wrote: > + release_resource(hsudc->mem_rsrc); > + kfree(hsudc->mem_rsrc); release_mem_region() is paired with request_mem_region. Do not go beneath the API by doing the above. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
