Re: [PATCH] mtd gpmi-nand: Fix read page when reading to vmalloced area
On Tue, Jun 26, 2012 at 05:26:16PM +0200, Sascha Hauer wrote: The gpmi-nand driver uses virt_addr_valid() to check whether a buffer is suitable for dma. If it's not, a driver allocated buffer is used instead. Then after a page read the driver allocated buffer must be copied to the user supplied buffer. This does not happen since: commit 7725cc85932bd02dd12c23108e0ef748c551ccba Author: Brian Norris computersforpe...@gmail.com Date: Wed May 2 10:15:02 2012 -0700 mtd: gpmi-nand: utilize oob_requested parameter Don't read OOB if the caller didn't request it. Signed-off-by: Brian Norris computersforpe...@gmail.com Acked-by: Huang Shijie b32...@freescale.com Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com Signed-off-by: David Woodhouse david.woodho...@intel.com This patch fixes this. The bug is encountered with UBI which uses a vmalloced buffer for the volume table. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Cc: stable@vger.kernel.org Sorry, please remove the stable tag, this bug was introduced in the last merge window. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: sdhci: fix incorrect command used in tuning
For SD hosts using retuning mode 1, when retuning timer expired, it will
need to do retuning in sdhci_request before processing the actual
request. But the retuning command is fixed: cmd19 for SD card and cmd21
for eMMC card, so we can't use the original request's command to do the
tuning.
And since the tuning command depends on the card type atteched to the
host, we will need to know the card type to use the correct tuning
command.
Signed-off-by: Aaron Lu aaron...@amd.com
Cc: stable stable@vger.kernel.org [3.3+]
---
drivers/mmc/host/sdhci.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f4b8b4d..ff522ec 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -27,6 +27,7 @@
#include linux/mmc/mmc.h
#include linux/mmc/host.h
+#include linux/mmc/card.h
#include sdhci.h
@@ -1245,6 +1246,7 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
struct sdhci_host *host;
bool present;
unsigned long flags;
+ u32 tuning_opcode;
host = mmc_priv(mmc);
@@ -1292,8 +1294,11 @@ 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))) {
+ tuning_opcode = mmc-card-type == MMC_TYPE_SD ?
+ MMC_SEND_TUNING_BLOCK :
+ MMC_SEND_TUNING_BLOCK_HS200;
spin_unlock_irqrestore(host-lock, flags);
- sdhci_execute_tuning(mmc, mrq-cmd-opcode);
+ sdhci_execute_tuning(mmc, tuning_opcode);
spin_lock_irqsave(host-lock, flags);
/* Restore original mmc_request structure */
--
1.7.11.2.gd284367
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] aio: make kiocb-private NUll in init_sync_kiocb()
Ocfs2 uses kiocb.*private as a flag of unsigned long size. In
commit a11f7e6 ocfs2: serialize unaligned aio, the unaligned
io flag is involved in it to serialize the unaligned aio. As
*private is not initialized in init_sync_kiocb() of do_sync_write(),
this unaligned io flag may be unexpectly set in an aligned dio.
And this will cause OCFS2_I(inode)-ip_unaligned_aio decreased
to -1 in ocfs2_dio_end_io(), thus the following unaligned dio
will hang forever at ocfs2_aiodio_wait() in ocfs2_file_aio_write().
Signed-off-by: Junxiao Bi junxiao...@oracle.com
Cc: stable@vger.kernel.org
Acked-by: Jeff Moyer jmo...@redhat.com
Acked-by: Joel Becker jl...@evilplan.org
---
include/linux/aio.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/aio.h b/include/linux/aio.h
index 2314ad8..b1a520e 100644
--- a/include/linux/aio.h
+++ b/include/linux/aio.h
@@ -140,6 +140,7 @@ struct kiocb {
(x)-ki_dtor = NULL;\
(x)-ki_obj.tsk = tsk; \
(x)-ki_user_data = 0; \
+ (x)-private = NULL;\
} while (0)
#define AIO_RING_MAGIC 0xa10a10a1
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] ocfs2: clear unaligned io flag when dio fails
The unaligned io flag is set in the kiocb when an unaligned
dio is issued, it should be cleared even when the dio fails,
or it may affect the following io which are using the same
kiocb.
Signed-off-by: Junxiao Bi junxiao...@oracle.com
Cc: stable@vger.kernel.org
---
fs/ocfs2/file.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
index 061591a..98513c8 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -2422,8 +2422,10 @@ out_dio:
unaligned_dio = 0;
}
- if (unaligned_dio)
+ if (unaligned_dio) {
+ ocfs2_iocb_clear_unaligned_aio(iocb);
atomic_dec(OCFS2_I(inode)-ip_unaligned_aio);
+ }
out:
if (rw_level != -1)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] can: flexcan: use be32_to_cpup to handle the value of dt entry
From: Hui Wang jason77.w...@gmail.com
The freescale arm i.MX series platform can support this driver, and
usually the arm cpu works in the little endian mode by default, while
device tree entry value is stored in big endian format, we should use
be32_to_cpup() to handle them, after modification, it can work well
both on the le cpu and be cpu.
Cc: stable stable@vger.kernel.org # v3.2+
Cc: Shawn Guo shawn@linaro.org
Signed-off-by: Hui Wang jason77.w...@gmail.com
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
drivers/net/can/flexcan.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 38c0690..81d4741 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -939,12 +939,12 @@ static int __devinit flexcan_probe(struct platform_device
*pdev)
return PTR_ERR(pinctrl);
if (pdev-dev.of_node) {
- const u32 *clock_freq_p;
+ const __be32 *clock_freq_p;
clock_freq_p = of_get_property(pdev-dev.of_node,
clock-frequency, NULL);
if (clock_freq_p)
- clock_freq = *clock_freq_p;
+ clock_freq = be32_to_cpup(clock_freq_p);
}
if (!clock_freq) {
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[git:v4l-dvb/for_v3.6] [media] gspca-core: Fix buffers staying in queued state after a stream_off
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] gspca-core: Fix buffers staying in queued state after a
stream_off
Author: Hans de Goede hdego...@redhat.com
Date:Tue May 22 11:24:05 2012 -0300
This fixes a regression introduced by commit f7059ea and should be
backported to all supported stable kernels which have this commit.
Signed-off-by: Hans de Goede hdego...@redhat.com
Tested-by: Antonio Ospite osp...@studenti.unina.it
CC: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
drivers/media/video/gspca/gspca.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=af05ef01e9cde84620c6855a8d8ab9c8a1db9009
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 137166d..31721ea 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1653,7 +1653,7 @@ static int vidioc_streamoff(struct file *file, void *priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1678,6 +1678,8 @@ static int vidioc_streamoff(struct file *file, void *priv,
wake_up_interruptible(gspca_dev-wq);
/* empty the transfer queues */
+ for (i = 0; i gspca_dev-nframes; i++)
+ gspca_dev-frame[i].v4l2_buf.flags = ~BUF_ALL_FLAGS;
atomic_set(gspca_dev-fr_q, 0);
atomic_set(gspca_dev-fr_i, 0);
gspca_dev-fr_o = 0;
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/radeon: disable any GPU activity after unrecovered lockup v2
From: Jerome Glisse jgli...@redhat.com
After unrecovered GPU lockup avoid any GPU activities to avoid
things like kernel segfault and alike to happen in any of the
path that assume hw is working.
The segfault is due to PCIE vram gart table being unmapped after
suspend in the GPU reset path. To avoid segault to happen and to
avoid further GPU activity if unsuccessful at reseting GPU we
use the accel_working boolean to transform ttm activities into
noop. It does not impact the module load path because in that
path ttm have an empty schedule queue and accel_working will be
set to true as soon as the gart table is in valid state. Because
ttm might have work queued it is better to use the accel working
then disabling radeon_bo ioctl.
To trigger the segfault launch a program that repeatly create bo
in ttm and let it run in background, then trigger gpu lockup from
another process.
v2: fix spelling error and disable accel before suspend and reenable
it after pcie gart initialization to be even more cautious about
possible segfault. Improve commit message
cc: stable@vger.kernel.org
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/ni.c|2 +-
drivers/gpu/drm/radeon/r300.c |2 +-
drivers/gpu/drm/radeon/r520.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
drivers/gpu/drm/radeon/radeon_device.c |9 ---
drivers/gpu/drm/radeon/radeon_object.c |7 ++
drivers/gpu/drm/radeon/radeon_ttm.c| 41
drivers/gpu/drm/radeon/rs400.c |2 +-
drivers/gpu/drm/radeon/rs600.c |2 +-
drivers/gpu/drm/radeon/rs690.c |2 +-
drivers/gpu/drm/radeon/rv515.c |2 +-
drivers/gpu/drm/radeon/rv770.c |2 +-
drivers/gpu/drm/radeon/si.c|2 +-
drivers/gpu/drm/ttm/ttm_tt.c |1 +
15 files changed, 66 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 7fb3d2e..2a4be53 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3055,6 +3055,7 @@ static int evergreen_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev-accel_working = true;
evergreen_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -3129,7 +3130,6 @@ int evergreen_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev-mode_info.atom_context);
- rdev-accel_working = true;
r = evergreen_startup(rdev);
if (r) {
DRM_ERROR(evergreen startup failed on resume\n);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index b7bf18e..18f87ca 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1229,6 +1229,7 @@ static int cayman_startup(struct radeon_device *rdev)
r = cayman_pcie_gart_enable(rdev);
if (r)
return r;
+ rdev-accel_working = true;
cayman_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -1321,7 +1322,6 @@ int cayman_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev-mode_info.atom_context);
- rdev-accel_working = true;
r = cayman_startup(rdev);
if (r) {
DRM_ERROR(cayman startup failed on resume\n);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 97722a3..206ac1f 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1358,6 +1358,7 @@ static int r300_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev-accel_working = true;
if (rdev-family == CHIP_R300 ||
rdev-family == CHIP_R350 ||
@@ -1426,7 +1427,6 @@ int r300_resume(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
- rdev-accel_working = true;
r = r300_startup(rdev);
if (r) {
rdev-accel_working = false;
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index b5cf837..6409eb0 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -181,6 +181,7 @@ static int r520_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev-accel_working = true;
/* allocate wb buffer */
r = radeon_wb_init(rdev);
@@ -236,7 +237,6 @@ int r520_resume(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
- rdev-accel_working = true;
r = r520_startup(rdev);
if (r) {
rdev-accel_working = false;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 78c0d0d..692b48b 100644
---
[PATCH 3.4] mac80211: fix queues stuck issue with HT bandwidth change
From: Johannes Berg johannes.b...@intel.com No upstream commit, the buggy code was removed in 3.5. Rajkumar changed code for handling channel switching in mac80211 to stop the queues in commit 7cc44ed48d0ec0937c1f098642540b6c9ca38de5 Author: Rajkumar Manoharan rmano...@qca.qualcomm.com Date: Fri Sep 16 15:32:34 2011 +0530 mac80211: Fix regression on queue stop during 2040 bss change which went into 3.2. In the 3.4 cycle, Paul's change commit 3117bbdb7899d43927c8ce4fe885ab7c1231c121 Author: Paul Stewart ps...@chromium.org Date: Tue Mar 13 07:46:18 2012 -0700 mac80211: Don't let regulatory make us deaf went in and changed the TX/RX enable logic, but now the conditions for stopping and restarting the queues were different so that now, if the AP changes between 20/40 MHz bandwidth, it can happen that we stop but never restart the queues. This breaks the connection and the module actually has to be reloaded to get it back to work. Fix this by making sure the queues are always started when they were stopped. Reported-by: Florian Manschwetus manschwe...@googlemail.com Signed-off-by: Johannes Berg johannes.b...@intel.com --- net/mac80211/mlme.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 20c680b..025a844 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -187,7 +187,7 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata, u32 changed = 0; int hti_cfreq; u16 ht_opmode; - bool enable_ht = true; + bool enable_ht = true, queues_stopped = false; enum nl80211_channel_type prev_chantype; enum nl80211_channel_type rx_channel_type = NL80211_CHAN_NO_HT; enum nl80211_channel_type tx_channel_type; @@ -254,6 +254,7 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata, */ ieee80211_stop_queues_by_reason(sdata-local-hw, IEEE80211_QUEUE_STOP_REASON_CHTYPE_CHANGE); + queues_stopped = true; /* flush out all packets */ synchronize_net(); @@ -272,12 +273,12 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata, IEEE80211_RC_HT_CHANGED, tx_channel_type); rcu_read_unlock(); - - if (beacon_htcap_ie) - ieee80211_wake_queues_by_reason(sdata-local-hw, - IEEE80211_QUEUE_STOP_REASON_CHTYPE_CHANGE); } + if (queues_stopped) + ieee80211_wake_queues_by_reason(sdata-local-hw, + IEEE80211_QUEUE_STOP_REASON_CHTYPE_CHANGE); + ht_opmode = le16_to_cpu(hti-operation_mode); /* if bss configuration changed store the new one */ -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/radeon: disable any GPU activity after unrecovered lockup v3
From: Jerome Glisse jgli...@redhat.com
After unrecovered GPU lockup avoid any GPU activities to avoid
things like kernel segfault and alike to happen in any of the
path that assume hw is working.
The segfault is due to PCIE vram gart table being unmapped after
suspend in the GPU reset path. To avoid segault to happen and to
avoid further GPU activity if unsuccessful at reseting GPU we
use the accel_working boolean to transform ttm activities into
noop. It does not impact the module load path because in that
path ttm have an empty schedule queue and accel_working will be
set to true as soon as the gart table is in valid state. Because
ttm might have work queued it is better to use the accel working
then disabling radeon_bo ioctl.
To trigger the segfault launch a program that repeatly create bo
in ttm and let it run in background, then trigger gpu lockup from
another process.
This patch also for video mode restoring on r1xx,r2xx,r3xx,r4xx,
r5xx,rs4xx,rs6xx GPU even if GPU reset fail. When GPU reset fails
it is very likely (so far i never had it not working) that the
modesetting part of the GPU is still alive. So we can have a
chance to get kernel backtrace or other debugging informations
on the screen if we always restore the video mode.
v2: fix spelling error and disable accel before suspend and reenable
it after pcie gart initialization to be even more cautious about
possible segfault. Improve commit message
v3: Improve commit message to describe the video mode restoring no
matter what.
cc: stable@vger.kernel.org
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/ni.c|2 +-
drivers/gpu/drm/radeon/r300.c |2 +-
drivers/gpu/drm/radeon/r520.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
drivers/gpu/drm/radeon/radeon_device.c |9 ---
drivers/gpu/drm/radeon/radeon_object.c |7 ++
drivers/gpu/drm/radeon/radeon_ttm.c| 41
drivers/gpu/drm/radeon/rs400.c |2 +-
drivers/gpu/drm/radeon/rs600.c |2 +-
drivers/gpu/drm/radeon/rs690.c |2 +-
drivers/gpu/drm/radeon/rv515.c |2 +-
drivers/gpu/drm/radeon/rv770.c |2 +-
drivers/gpu/drm/radeon/si.c|2 +-
drivers/gpu/drm/ttm/ttm_tt.c |1 +
15 files changed, 66 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index c3073f7..5f154e3 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3071,6 +3071,7 @@ static int evergreen_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev-accel_working = true;
evergreen_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -3145,7 +3146,6 @@ int evergreen_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev-mode_info.atom_context);
- rdev-accel_working = true;
r = evergreen_startup(rdev);
if (r) {
DRM_ERROR(evergreen startup failed on resume\n);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index dc2e34d..486faa8 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1245,6 +1245,7 @@ static int cayman_startup(struct radeon_device *rdev)
r = cayman_pcie_gart_enable(rdev);
if (r)
return r;
+ rdev-accel_working = true;
cayman_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -1337,7 +1338,6 @@ int cayman_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev-mode_info.atom_context);
- rdev-accel_working = true;
r = cayman_startup(rdev);
if (r) {
DRM_ERROR(cayman startup failed on resume\n);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 97722a3..206ac1f 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1358,6 +1358,7 @@ static int r300_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev-accel_working = true;
if (rdev-family == CHIP_R300 ||
rdev-family == CHIP_R350 ||
@@ -1426,7 +1427,6 @@ int r300_resume(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
- rdev-accel_working = true;
r = r300_startup(rdev);
if (r) {
rdev-accel_working = false;
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index b5cf837..6409eb0 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -181,6 +181,7 @@ static int r520_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev-accel_working =
[PATCH] drm/radeon: disable any GPU activity after unrecovered lockup v4
From: Jerome Glisse jgli...@redhat.com
After unrecovered GPU lockup avoid any GPU activities to avoid
things like kernel segfault and alike to happen in any of the
path that assume hw is working.
The segfault is due to PCIE vram gart table being unmapped after
suspend in the GPU reset path. To avoid segault to happen and to
avoid further GPU activity if unsuccessful at reseting GPU we
use the accel_working boolean to transform ttm activities into
noop. It does not impact the module load path because in that
path ttm have an empty schedule queue and accel_working will be
set to true as soon as the gart table is in valid state. Because
ttm might have work queued it is better to use the accel working
then disabling radeon_bo ioctl.
To trigger the segfault launch a program that repeatly create bo
in ttm and let it run in background, then trigger gpu lockup from
another process.
This patch also for video mode restoring on r1xx,r2xx,r3xx,r4xx,
r5xx,rs4xx,rs6xx GPU even if GPU reset fail. When GPU reset fails
it is very likely (so far i never had it not working) that the
modesetting part of the GPU is still alive. So we can have a
chance to get kernel backtrace or other debugging informations
on the screen if we always restore the video mode.
v2: fix spelling error and disable accel before suspend and reenable
it after pcie gart initialization to be even more cautious about
possible segfault. Improve commit message
v3: Improve commit message to describe the video mode restoring no
matter what.
v4: Avoid issue after successfull GPU lockup recovery. Don't do noop
ttm move, instead report error if move needs bind or unbind or
fallback to memcpy. Don't restrict new bo domain instead refuse
to create new bo if gpu reset failed. Disable accel working
in gart vram table unpin thus we don't change the behavior of
the suspend path.
cc: stable@vger.kernel.org
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/ni.c|2 +-
drivers/gpu/drm/radeon/r300.c |2 +-
drivers/gpu/drm/radeon/r520.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
drivers/gpu/drm/radeon/radeon_device.c |8 +---
drivers/gpu/drm/radeon/radeon_gart.c |1 +
drivers/gpu/drm/radeon/radeon_gem.c| 13 +
drivers/gpu/drm/radeon/radeon_ttm.c| 23 +++
drivers/gpu/drm/radeon/rs400.c |2 +-
drivers/gpu/drm/radeon/rs600.c |2 +-
drivers/gpu/drm/radeon/rs690.c |2 +-
drivers/gpu/drm/radeon/rv515.c |2 +-
drivers/gpu/drm/radeon/rv770.c |2 +-
drivers/gpu/drm/radeon/si.c|2 +-
15 files changed, 53 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index c3073f7..5f154e3 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3071,6 +3071,7 @@ static int evergreen_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev-accel_working = true;
evergreen_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -3145,7 +3146,6 @@ int evergreen_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev-mode_info.atom_context);
- rdev-accel_working = true;
r = evergreen_startup(rdev);
if (r) {
DRM_ERROR(evergreen startup failed on resume\n);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index dc2e34d..486faa8 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1245,6 +1245,7 @@ static int cayman_startup(struct radeon_device *rdev)
r = cayman_pcie_gart_enable(rdev);
if (r)
return r;
+ rdev-accel_working = true;
cayman_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -1337,7 +1338,6 @@ int cayman_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev-mode_info.atom_context);
- rdev-accel_working = true;
r = cayman_startup(rdev);
if (r) {
DRM_ERROR(cayman startup failed on resume\n);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 97722a3..206ac1f 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1358,6 +1358,7 @@ static int r300_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev-accel_working = true;
if (rdev-family == CHIP_R300 ||
rdev-family == CHIP_R350 ||
@@ -1426,7 +1427,6 @@ int r300_resume(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
- rdev-accel_working = true;
r = r300_startup(rdev);
if (r) {
rdev-accel_working =
[PATCH] drm/radeon: disable any GPU activity after unrecovered lockup v5
From: Jerome Glisse jgli...@redhat.com
After unrecovered GPU lockup avoid any GPU activities to avoid
things like kernel segfault and alike to happen in any of the
path that assume hw is working.
The segfault is due to PCIE vram gart table being unmapped after
suspend in the GPU reset path. To avoid segault to happen and to
avoid further GPU activity if unsuccessful at reseting GPU we
use the accel_working boolean to transform ttm activities into
noop. It does not impact the module load path because in that
path ttm have an empty schedule queue and accel_working will be
set to true as soon as the gart table is in valid state. Because
ttm might have work queued it is better to use the accel working
then disabling radeon_bo ioctl.
To trigger the segfault launch a program that repeatly create bo
in ttm and let it run in background, then trigger gpu lockup from
another process.
This patch also for video mode restoring on r1xx,r2xx,r3xx,r4xx,
r5xx,rs4xx,rs6xx GPU even if GPU reset fail. When GPU reset fails
it is very likely (so far i never had it not working) that the
modesetting part of the GPU is still alive. So we can have a
chance to get kernel backtrace or other debugging informations
on the screen if we always restore the video mode.
v2: fix spelling error and disable accel before suspend and reenable
it after pcie gart initialization to be even more cautious about
possible segfault. Improve commit message
v3: Improve commit message to describe the video mode restoring no
matter what.
v4: Avoid issue after successfull GPU lockup recovery. Don't do noop
ttm move, instead report error if move needs bind or unbind or
fallback to memcpy. Don't restrict new bo domain instead refuse
to create new bo if gpu reset failed. Disable accel working
in gart vram table unpin thus we don't change the behavior of
the suspend path.
v5: Avoid set domain to also trigger noop bind/unbind, instead force
it to wait for GPU reset to go through or return failure if
gpu reset fails.
cc: stable@vger.kernel.org
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/ni.c|2 +-
drivers/gpu/drm/radeon/r300.c |2 +-
drivers/gpu/drm/radeon/r520.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
drivers/gpu/drm/radeon/radeon_device.c |8 +---
drivers/gpu/drm/radeon/radeon_gart.c |1 +
drivers/gpu/drm/radeon/radeon_gem.c| 33
drivers/gpu/drm/radeon/radeon_ttm.c| 23 ++
drivers/gpu/drm/radeon/rs400.c |2 +-
drivers/gpu/drm/radeon/rs600.c |2 +-
drivers/gpu/drm/radeon/rs690.c |2 +-
drivers/gpu/drm/radeon/rv515.c |2 +-
drivers/gpu/drm/radeon/rv770.c |2 +-
drivers/gpu/drm/radeon/si.c|2 +-
15 files changed, 73 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index c3073f7..5f154e3 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3071,6 +3071,7 @@ static int evergreen_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev-accel_working = true;
evergreen_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -3145,7 +3146,6 @@ int evergreen_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev-mode_info.atom_context);
- rdev-accel_working = true;
r = evergreen_startup(rdev);
if (r) {
DRM_ERROR(evergreen startup failed on resume\n);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index dc2e34d..486faa8 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1245,6 +1245,7 @@ static int cayman_startup(struct radeon_device *rdev)
r = cayman_pcie_gart_enable(rdev);
if (r)
return r;
+ rdev-accel_working = true;
cayman_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -1337,7 +1338,6 @@ int cayman_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev-mode_info.atom_context);
- rdev-accel_working = true;
r = cayman_startup(rdev);
if (r) {
DRM_ERROR(cayman startup failed on resume\n);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 97722a3..206ac1f 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1358,6 +1358,7 @@ static int r300_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev-accel_working = true;
if (rdev-family == CHIP_R300 ||
rdev-family == CHIP_R350 ||
@@ -1426,7 +1427,6 @@ int r300_resume(struct radeon_device *rdev)
/* Initialize surface
Re: [PATCH] ARM: Orion: Fix Virtual/Physical mixup with watchdog
On Mon, Jun 18, 2012 at 04:15:06PM +0200, Andrew Lunn wrote:
The orion watchdog is expecting to be passed the physcial address of
the hardware, and will ioremap() it to give a virtual address it will
use as the base address for the hardware. However, when creating the
platform resource record, a virtual address was being used.
Add the necassary #define's so we can pass the physical address as
expected.
Tested on Kirkwood and Orion5x.
Cc: stable stable@vger.kernel.org
Signed-off-by: Andrew Lunn and...@lunn.ch
Acked-by: Jason Cooper ja...@lakedaemon.net
---
arch/arm/mach-kirkwood/include/mach/bridge-regs.h |1 +
arch/arm/mach-kirkwood/include/mach/kirkwood.h|1 +
arch/arm/mach-orion5x/include/mach/bridge-regs.h |2 +-
arch/arm/mach-orion5x/include/mach/orion5x.h |1 +
arch/arm/plat-orion/common.c |2 +-
5 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
index 3eee37a..a115142 100644
--- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
+++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
@@ -38,6 +38,7 @@
#define IRQ_MASK_HIGH_OFF0x0014
#define TIMER_VIRT_BASE (BRIDGE_VIRT_BASE | 0x0300)
+#define TIMER_PHYS_BASE (BRIDGE_PHYS_BASE | 0x0300)
#define L2_CONFIG_REG(BRIDGE_VIRT_BASE | 0x0128)
#define L2_WRITETHROUGH 0x0010
diff --git a/arch/arm/mach-kirkwood/include/mach/kirkwood.h
b/arch/arm/mach-kirkwood/include/mach/kirkwood.h
index fede3d5..c5b6851 100644
--- a/arch/arm/mach-kirkwood/include/mach/kirkwood.h
+++ b/arch/arm/mach-kirkwood/include/mach/kirkwood.h
@@ -80,6 +80,7 @@
#define UART1_VIRT_BASE (DEV_BUS_VIRT_BASE | 0x2100)
#define BRIDGE_VIRT_BASE (KIRKWOOD_REGS_VIRT_BASE | 0x2)
+#define BRIDGE_PHYS_BASE (KIRKWOOD_REGS_PHYS_BASE | 0x2)
#define CRYPTO_PHYS_BASE (KIRKWOOD_REGS_PHYS_BASE | 0x3)
diff --git a/arch/arm/mach-orion5x/include/mach/bridge-regs.h
b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
index 96484bc..11a3c1e 100644
--- a/arch/arm/mach-orion5x/include/mach/bridge-regs.h
+++ b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
@@ -35,5 +35,5 @@
#define MAIN_IRQ_MASK(ORION5X_BRIDGE_VIRT_BASE | 0x204)
#define TIMER_VIRT_BASE (ORION5X_BRIDGE_VIRT_BASE | 0x300)
-
+#define TIMER_PHYS_BASE (ORION5X_BRIDGE_PHYS_BASE | 0x300)
#endif
diff --git a/arch/arm/mach-orion5x/include/mach/orion5x.h
b/arch/arm/mach-orion5x/include/mach/orion5x.h
index 2745f5d..683e085 100644
--- a/arch/arm/mach-orion5x/include/mach/orion5x.h
+++ b/arch/arm/mach-orion5x/include/mach/orion5x.h
@@ -82,6 +82,7 @@
#define UART1_VIRT_BASE (ORION5X_DEV_BUS_VIRT_BASE | 0x2100)
#define ORION5X_BRIDGE_VIRT_BASE (ORION5X_REGS_VIRT_BASE | 0x2)
+#define ORION5X_BRIDGE_PHYS_BASE (ORION5X_REGS_PHYS_BASE | 0x2)
#define ORION5X_PCI_VIRT_BASE(ORION5X_REGS_VIRT_BASE |
0x3)
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index 61fd837..c179378 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -582,7 +582,7 @@ void __init orion_spi_1_init(unsigned long mapbase)
* Watchdog
/
static struct resource orion_wdt_resource =
- DEFINE_RES_MEM(TIMER_VIRT_BASE, 0x28);
+ DEFINE_RES_MEM(TIMER_PHYS_BASE, 0x28);
static struct platform_device orion_wdt_device = {
.name = orion_wdt,
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][v3.2.y] samsung-laptop: make the dmi check less strict
Hello, Please consider including upstream commit 3be324a94df0c3f032178d04549dbfbf6cccb09a in the next v3.2.y release. It was included upstream as of v3.4-rc1. It has been tested and confirmed to resolve http://bugs.launchpad.net/bugs/1012284 . commit 3be324a94df0c3f032178d04549dbfbf6cccb09a Author: Corentin Chary corenti...@iksaif.net Date: Sat Nov 26 11:00:10 2011 +0100 samsung-laptop: make the dmi check less strict Sincerely, Joseph Salisbury -- To unsubscribe from this list: send the line unsubscribe stable 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.4] mac80211: fix queues stuck issue with HT bandwidth change
Johannes Berg wrote: No upstream commit, the buggy code was removed in 3.5. What upstream commit removed the buggy code? -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][v3.2.y] samsung-laptop: make the dmi check less strict
Hi, Joseph Salisbury wrote: Please consider including upstream commit 3be324a94df0c3f032178d04549dbfbf6cccb09a in the next v3.2.y release. It was included upstream as of v3.4-rc1. It has been tested and confirmed to resolve http://bugs.launchpad.net/bugs/1012284 . Should 3.0.y get this, too? Thanks, Jonathan commit 3be324a94df0c3f032178d04549dbfbf6cccb09a Author: Corentin Chary corenti...@iksaif.net Date: Sat Nov 26 11:00:10 2011 +0100 samsung-laptop: make the dmi check less strict -- To unsubscribe from this list: send the line unsubscribe stable 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.4] mac80211: fix queues stuck issue with HT bandwidth change
On Wed, 2012-06-27 at 15:32 -0500, Jonathan Nieder wrote: Johannes Berg wrote: No upstream commit, the buggy code was removed in 3.5. What upstream commit removed the buggy code? Nothing git can't answer :-) 7213cf2cb0dfbb4d6b55a1da000d34338f76c0e3 But of course that just removed the queue stop. Really, the buggy bits with channel_type vs. rx_channel_type/tx_channel_type were removed in 24398e39c8ee4a9d9123eed322b859ece4d16cac because that commit changed the logic around the stop/wake queue. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mtd gpmi-nand: Fix read page when reading to vmalloced area
Tested this modification on MX28 hardware that I have access to. With this patch I can now create UBI file system on flash. Tested-by: snijs...@grid-net.com Thanks! -Subodh On 06/26/2012 08:26 AM, Sascha Hauer wrote: The gpmi-nand driver uses virt_addr_valid() to check whether a buffer is suitable for dma. If it's not, a driver allocated buffer is used instead. Then after a page read the driver allocated buffer must be copied to the user supplied buffer. This does not happen since: commit 7725cc85932bd02dd12c23108e0ef748c551ccba Author: Brian Norris computersforpe...@gmail.com Date: Wed May 2 10:15:02 2012 -0700 mtd: gpmi-nand: utilize oob_requested parameter Don't read OOB if the caller didn't request it. Signed-off-by: Brian Norris computersforpe...@gmail.com Acked-by: Huang Shijie b32...@freescale.com Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com Signed-off-by: David Woodhouse david.woodho...@intel.com This patch fixes this. The bug is encountered with UBI which uses a vmalloced buffer for the volume table. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Cc: stable@vger.kernel.org Cc: Huang Shijie b32...@freescale.com Cc: Brian Norris computersforpe...@gmail.com Cc: Subodh Nijsure snijs...@grid-net.com --- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c index 6bb6f48..0179685 100644 --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c @@ -920,12 +920,12 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, struct nand_chip *chip, */ memset(chip-oob_poi, ~0, mtd-oobsize); chip-oob_poi[0] = ((uint8_t *) auxiliary_virt)[0]; - - read_page_swap_end(this, buf, mtd-writesize, - this-payload_virt, this-payload_phys, - nfc_geo-payload_size, - payload_virt, payload_phys); } + + read_page_swap_end(this, buf, mtd-writesize, + this-payload_virt, this-payload_phys, + nfc_geo-payload_size, + payload_virt, payload_phys); exit_nfc: return ret; } -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: drm/nouveau/fbcon: using nv_two_heads is not a good idea
commit: 9bd0c15fcfb42f6245447c53347d65ad9e72080b
From: Ben Skeggs bske...@redhat.com
Date: Tue, 26 Jun 2012 12:12:30 +1000
Subject: drm/nouveau/fbcon: using nv_two_heads is not a good idea
nv_two_heads() was never meant to be used outside of pre-nv50 code. The
code checks for = NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device 0x0ff0).
The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which
gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing
memory corruption because there's actually 2 CRTCs..
This switches fbcon to use the CRTC count directly from the mode_config
structure, which will also fix the same issue on Kepler boards which have
4 CRTCs.
Signed-off-by: Ben Skeggs bske...@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 153b9a1..1074bc5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -467,7 +467,7 @@ int nouveau_fbcon_init(struct drm_device *dev)
nfbdev-helper.funcs = nouveau_fbcon_helper_funcs;
ret = drm_fb_helper_init(dev, nfbdev-helper,
-nv_two_heads(dev) ? 2 : 1, 4);
+dev-mode_config.num_crtc, 4);
if (ret) {
kfree(nfbdev);
return ret;
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: clk: Check parent for NULL in clk_change_rate
commit: bf47b4fd8f9f81cd5ce40e1945c6334d088226d1
From: Pawel Moll pawel.m...@arm.com
Date: Fri, 8 Jun 2012 14:04:06 +0100
Subject: clk: Check parent for NULL in clk_change_rate
clk_change_rate() is accessing parent's rate without checking
if the parent exists at all. In case of root clocks this will
cause NULL pointer dereference.
This patch follows what clk_calc_new_rates() does in such
situation.
Signed-off-by: Pawel Moll pawel.m...@arm.com
Signed-off-by: Mike Turquette mturque...@linaro.org
Cc: sta...@kernel.org
---
drivers/clk/clk.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index df89cbf..dcbe056 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -850,18 +850,21 @@ static void clk_change_rate(struct clk *clk)
{
struct clk *child;
unsigned long old_rate;
+ unsigned long best_parent_rate = 0;
struct hlist_node *tmp;
old_rate = clk-rate;
+ if (clk-parent)
+ best_parent_rate = clk-parent-rate;
+
if (clk-ops-set_rate)
- clk-ops-set_rate(clk-hw, clk-new_rate, clk-parent-rate);
+ clk-ops-set_rate(clk-hw, clk-new_rate, best_parent_rate);
if (clk-ops-recalc_rate)
- clk-rate = clk-ops-recalc_rate(clk-hw,
- clk-parent-rate);
+ clk-rate = clk-ops-recalc_rate(clk-hw, best_parent_rate);
else
- clk-rate = clk-parent-rate;
+ clk-rate = best_parent_rate;
if (clk-notifier_count old_rate != clk-rate)
__clk_notify(clk, POST_RATE_CHANGE, old_rate, clk-rate);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: ALSA: hda - Fix memory leaks at module unload
commit: 59cad16bc6deb85bd2a464da92bbaae289f0286f
From: Takashi Iwai ti...@suse.de
Date: Tue, 26 Jun 2012 15:00:20 +0200
Subject: ALSA: hda - Fix memory leaks at module unload
Some caches aren't released properly at module unloading time.
Cc: stable@vger.kernel.org [v3.4+]
Signed-off-by: Takashi Iwai ti...@suse.de
---
sound/pci/hda/hda_codec.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 7504e62..854dd0c 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -1184,6 +1184,7 @@ static void snd_hda_codec_free(struct hda_codec *codec)
{
if (!codec)
return;
+ snd_hda_jack_tbl_clear(codec);
restore_init_pincfgs(codec);
#ifdef CONFIG_SND_HDA_POWER_SAVE
cancel_delayed_work(codec-power_work);
@@ -1192,6 +1193,7 @@ static void snd_hda_codec_free(struct hda_codec *codec)
list_del(codec-list);
snd_array_free(codec-mixers);
snd_array_free(codec-nids);
+ snd_array_free(codec-cvt_setups);
snd_array_free(codec-conn_lists);
snd_array_free(codec-spdif_out);
codec-bus-caddr_tbl[codec-addr] = NULL;
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: USB: option: Add USB ID for Novatel Ovation MC551
commit: 065b07e7a14676f4138ce4619d229c0be5a74230
From: Forest Bond forest.b...@rapidrollout.com
Date: Fri, 22 Jun 2012 10:30:38 -0400
Subject: USB: option: Add USB ID for Novatel Ovation MC551
This device is also known as the Verizon USB551L.
Signed-off-by: Forest Bond forest.b...@rapidrollout.com
Acked-by: Dan Williams d...@redhat.com
Cc: stable stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/serial/option.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 396d968..adf8ce7 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -236,6 +236,7 @@ static void option_instat_callback(struct urb *urb);
#define NOVATELWIRELESS_PRODUCT_G1 0xA001
#define NOVATELWIRELESS_PRODUCT_G1_M 0xA002
#define NOVATELWIRELESS_PRODUCT_G2 0xA010
+#define NOVATELWIRELESS_PRODUCT_MC551 0xB001
/* AMOI PRODUCTS */
#define AMOI_VENDOR_ID 0x1614
@@ -738,6 +739,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1_M) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G2) },
+ /* Novatel Ovation MC551 a.k.a. Verizon USB551L */
+ { USB_DEVICE_AND_INTERFACE_INFO(NOVATELWIRELESS_VENDOR_ID,
NOVATELWIRELESS_PRODUCT_MC551, 0xff, 0xff, 0xff) },
{ USB_DEVICE(AMOI_VENDOR_ID, AMOI_PRODUCT_H01) },
{ USB_DEVICE(AMOI_VENDOR_ID, AMOI_PRODUCT_H01A) },
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: USB: CP210x Add 10 Device IDs
commit: 3fcc8f96829776cf181918461923d1e3bbb831a2
From: Craig Shelley cr...@microtron.org.uk
Date: Tue, 26 Jun 2012 23:20:04 +0100
Subject: USB: CP210x Add 10 Device IDs
This patch adds 10 device IDs for CP210x based devices from the following
manufacturers:
Timewave
Clipsal
Festo
Link Instruments
Signed-off-by: Craig Shelley cr...@microtron.org.uk
Cc: stable stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/serial/cp210x.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 73d25cd..1e71079 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -93,6 +93,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x814B) }, /* West Mountain Radio RIGtalk */
{ USB_DEVICE(0x10C4, 0x8156) }, /* BG H3000 link cable */
{ USB_DEVICE(0x10C4, 0x815E) }, /* Helicomm IP-Link 1220-DVM */
+ { USB_DEVICE(0x10C4, 0x815F) }, /* Timewave HamLinkUSB */
{ USB_DEVICE(0x10C4, 0x818B) }, /* AVIT Research USB to TTL */
{ USB_DEVICE(0x10C4, 0x819F) }, /* MJS USB Toslink Switcher */
{ USB_DEVICE(0x10C4, 0x81A6) }, /* ThinkOptics WavIt */
@@ -134,7 +135,13 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10CE, 0xEA6A) }, /* Silicon Labs MobiData GPRS USB Modem
100EU */
{ USB_DEVICE(0x13AD, 0x) }, /* Baltech card reader */
{ USB_DEVICE(0x1555, 0x0004) }, /* Owen AC4 USB-RS485 Converter */
+ { USB_DEVICE(0x166A, 0x0201) }, /* Clipsal 5500PACA C-Bus Pascal
Automation Controller */
+ { USB_DEVICE(0x166A, 0x0301) }, /* Clipsal 5800PC C-Bus Wireless PC
Interface */
{ USB_DEVICE(0x166A, 0x0303) }, /* Clipsal 5500PCU C-Bus USB interface
*/
+ { USB_DEVICE(0x166A, 0x0304) }, /* Clipsal 5000CT2 C-Bus Black and
White Touchscreen */
+ { USB_DEVICE(0x166A, 0x0305) }, /* Clipsal C-5000CT2 C-Bus Spectrum
Colour Touchscreen */
+ { USB_DEVICE(0x166A, 0x0401) }, /* Clipsal L51xx C-Bus Architectural
Dimmer */
+ { USB_DEVICE(0x166A, 0x0101) }, /* Clipsal 5560884 C-Bus Multi-room
Audio Matrix Switcher */
{ USB_DEVICE(0x16D6, 0x0001) }, /* Jablotron serial interface */
{ USB_DEVICE(0x16DC, 0x0010) }, /* W-IE-NE-R Plein Baus GmbH PL512
Power Supply */
{ USB_DEVICE(0x16DC, 0x0011) }, /* W-IE-NE-R Plein Baus GmbH RCM
Remote Control for MARATON Power Supply */
@@ -146,7 +153,11 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
+ { USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
+ { USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
{ USB_DEVICE(0x3195, 0xF190) }, /* Link Instruments MSO-19 */
+ { USB_DEVICE(0x3195, 0xF280) }, /* Link Instruments MSO-28 */
+ { USB_DEVICE(0x3195, 0xF281) }, /* Link Instruments MSO-28 */
{ USB_DEVICE(0x413C, 0x9500) }, /* DW700 GPS USB interface */
{ } /* Terminating Entry */
};
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: clk: Allow late cache allocation for clk-parents
commit: 7975059db572eb47f0fb272a62afeae272a4b209
From: Rajendra Nayak rna...@ti.com
Date: Wed, 6 Jun 2012 14:41:31 +0530
Subject: clk: Allow late cache allocation for clk-parents
Parent clocks for muxes are cached in clk-parents to
avoid frequent lookups, however the cache allocation happens
only during clock registeration and later clk_set_parent()
assumes a cache space available and allocated.
This is not entirely true for platforms which do early clock
registerations wherein the cache allocation using kzalloc
could fail during clock registeration.
Allow cache allocation to happen later as part of clk_set_parent()
to help such cases and avoid crashes assuming a cache being
available.
While here also replace existing kmalloc() with kzalloc()
in the file.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Mike Turquette mturque...@linaro.org
Cc: sta...@kernel.org
---
drivers/clk/clk.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 687b00d..df89cbf 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -999,7 +999,7 @@ static struct clk *__clk_init_parent(struct clk *clk)
if (!clk-parents)
clk-parents =
- kmalloc((sizeof(struct clk*) * clk-num_parents),
+ kzalloc((sizeof(struct clk*) * clk-num_parents),
GFP_KERNEL);
if (!clk-parents)
@@ -1065,9 +1065,13 @@ static int __clk_set_parent(struct clk *clk, struct clk
*parent)
old_parent = clk-parent;
/* find index of new parent clock using cached parent ptrs */
- for (i = 0; i clk-num_parents; i++)
- if (clk-parents[i] == parent)
- break;
+ if (clk-parents)
+ for (i = 0; i clk-num_parents; i++)
+ if (clk-parents[i] == parent)
+ break;
+ else
+ clk-parents = kzalloc((sizeof(struct clk*) * clk-num_parents),
+ GFP_KERNEL);
/*
* find index of new parent clock using string name comparison
@@ -1076,7 +1080,8 @@ static int __clk_set_parent(struct clk *clk, struct clk
*parent)
if (i == clk-num_parents)
for (i = 0; i clk-num_parents; i++)
if (!strcmp(clk-parent_names[i], parent-name)) {
- clk-parents[i] = __clk_lookup(parent-name);
+ if (clk-parents)
+ clk-parents[i] =
__clk_lookup(parent-name);
break;
}
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: ALSA: hda - Add Realtek ALC280 codec support
commit: befae82e2906cb7155020876a531b0b8c6c8d8c8
From: David Henningsson david.hennings...@canonical.com
Date: Mon, 25 Jun 2012 19:49:28 +0200
Subject: ALSA: hda - Add Realtek ALC280 codec support
This chip looks very similar to ALC269 and ALC27* variants. The bug reporter
has verified that sound was working after this patch had been applied.
Cc: sta...@kernel.org
BugLink: https://bugs.launchpad.net/bugs/1017017
Tested-by: Richard Crossley richardcross...@o2.co.uk
Signed-off-by: David Henningsson david.hennings...@canonical.com
Signed-off-by: Takashi Iwai ti...@suse.de
---
sound/pci/hda/patch_realtek.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 41475ae..a5534b3 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6800,6 +6800,7 @@ static const struct hda_codec_preset
snd_hda_preset_realtek[] = {
{ .id = 0x10ec0272, .name = ALC272, .patch = patch_alc662 },
{ .id = 0x10ec0275, .name = ALC275, .patch = patch_alc269 },
{ .id = 0x10ec0276, .name = ALC276, .patch = patch_alc269 },
+ { .id = 0x10ec0280, .name = ALC280, .patch = patch_alc269 },
{ .id = 0x10ec0861, .rev = 0x100340, .name = ALC660,
.patch = patch_alc861 },
{ .id = 0x10ec0660, .name = ALC660-VD, .patch = patch_alc861vd },
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: usb-storage: revert commit afff07e61a52 (Add 090c:1000 to unusal-devs)
commit: 0070513b5e005161a7a7fd9a3f48f982b41eb094 From: Alan Stern st...@rowland.harvard.edu Date: Wed, 20 Jun 2012 16:04:30 -0400 Subject: usb-storage: revert commit afff07e61a52 (Add 090c:1000 to unusal-devs) This patch (as1560) reverts commit afff07e61a5243e14ee3f0a272a0380cd744a8a3 (usb-storage: Add 090c:1000 to unusal-devs). It is no longer needed, because usb-storage now tells the sd driver to try READ CAPACITY(10) before READ CAPACITY(16) for every USB mass-storage device. Signed-off-by: Alan Stern st...@rowland.harvard.edu Acked-by: Hans de Goede hdego...@redhat.com CC: Matthew Dharm mdharm-...@one-eyed-alien.net Cc: stable stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- drivers/usb/storage/unusual_devs.h |7 --- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index caf22bf..1719886 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -1107,13 +1107,6 @@ UNUSUAL_DEV( 0x090a, 0x1200, 0x, 0x, USB_SC_RBC, USB_PR_BULK, NULL, 0 ), -/* Feiya QDI U2 DISK, reported by Hans de Goede hdego...@redhat.com */ -UNUSUAL_DEV( 0x090c, 0x1000, 0x, 0x, - Feiya, - QDI U2 DISK, - USB_SC_DEVICE, USB_PR_DEVICE, NULL, - US_FL_NO_READ_CAPACITY_16 ), - /* aeb */ UNUSUAL_DEV( 0x090c, 0x1132, 0x, 0x, Feiya, -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: SCSI usb-storage: add try_rc_10_first flag
commit: 6a0bdffa0073857870a4ed1b4489762146359eb4
From: Alan Stern st...@rowland.harvard.edu
Date: Wed, 20 Jun 2012 16:04:19 -0400
Subject: SCSI usb-storage: add try_rc_10_first flag
Several bug reports have been received recently for USB mass-storage
devices that don't handle READ CAPACITY(16) commands properly. They
report bogus sizes, in some cases becoming unusable as a result.
The bugs were triggered by commit
09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI usb-storage: add
flags for VPD pages and REPORT LUNS), which caused usb-storage to stop
overriding the SCSI level reported by devices. By default, the sd
driver will try READ CAPACITY(16) first for any device whose level is
above SCSI_SPC_2.
It seems likely that any device large enough to require the use of
READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ
CAPACITY(10) commands properly. Indeed, I don't know of any devices
that don't handle READ CAPACITY(10) properly.
Therefore this patch (as1559) adds a new flag telling the sd driver
to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag
for every USB mass-storage device. If a device really is larger than
2 TB, sd will fall back to READ CAPACITY(16) just as it used to.
This fixes Bugzilla #43391.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Hans de Goede hdego...@redhat.com
CC: James E.J. Bottomley jbottom...@parallels.com
CC: Matthew Dharm mdharm-...@one-eyed-alien.net
Cc: stable stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/scsi/sd.c |2 ++
drivers/usb/storage/scsiglue.c |6 ++
include/scsi/scsi_device.h |1 +
3 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 6f0a4c6..6f72b80 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1899,6 +1899,8 @@ static int sd_try_rc16_first(struct scsi_device *sdp)
{
if (sdp-host-max_cmd_len 16)
return 0;
+ if (sdp-try_rc_10_first)
+ return 0;
if (sdp-scsi_level SCSI_SPC_2)
return 1;
if (scsi_device_protection(sdp))
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index a324a5d..11418da 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -202,6 +202,12 @@ static int slave_configure(struct scsi_device *sdev)
if (us-fflags US_FL_NO_READ_CAPACITY_16)
sdev-no_read_capacity_16 = 1;
+ /*
+* Many devices do not respond properly to READ_CAPACITY_16.
+* Tell the SCSI layer to try READ_CAPACITY_10 first.
+*/
+ sdev-try_rc_10_first = 1;
+
/* assume SPC3 or latter devices support sense size 18 */
if (sdev-scsi_level SCSI_SPC_2)
us-fflags |= US_FL_SANE_SENSE;
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 6efb2e1..ba96988 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -151,6 +151,7 @@ struct scsi_device {
SD_LAST_BUGGY_SECTORS */
unsigned no_read_disc_info:1; /* Avoid READ_DISC_INFO cmds */
unsigned no_read_capacity_16:1; /* Avoid READ_CAPACITY_16 cmds */
+ unsigned try_rc_10_first:1; /* Try READ_CAPACACITY_10 first */
unsigned is_visible:1; /* is the device visible in sysfs */
DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events
*/
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: USB: option: add id for Cellient MEN-200
commit: 1e2c4e59d2b8797973471b4a287a43eac12a0f40
From: Dmitry Shmygov shmy...@rambler.ru
Date: Wed, 20 Jun 2012 15:51:40 +0400
Subject: USB: option: add id for Cellient MEN-200
Add vendor and product ID to option.c driver
for Cellient MEN-200 EVDO Rev.B 450MHz data module.
http://cellient.com
Signed-off-by: Dmitry Shmygov shmy...@rambler.ru
Cc: stable stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/serial/option.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index e668a24..396d968 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -497,6 +497,10 @@ static void option_instat_callback(struct urb *urb);
/* MediaTek products */
#define MEDIATEK_VENDOR_ID 0x0e8d
+/* Cellient products */
+#define CELLIENT_VENDOR_ID 0x2692
+#define CELLIENT_PRODUCT_MEN2000x9005
+
/* some devices interfaces need special handling due to a number of reasons */
enum option_blacklist_reason {
OPTION_BLACKLIST_NONE = 0,
@@ -1233,6 +1237,7 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a1, 0xff, 0x02,
0x01) },
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a2, 0xff, 0x00,
0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a2, 0xff, 0x02,
0x01) },/* MediaTek MT6276M modem app port */
+ { USB_DEVICE(CELLIENT_VENDOR_ID, CELLIENT_PRODUCT_MEN200) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, option_ids);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ALSA: hda - Fix power-map regression for HP dv6 co
commit 6e1c39c6b00d9141a82c231ba7c5e5b1716974b2 upstream.
The recent fix for power-map controls (commit b0791dda813) caused
regressions on some other HP laptops. They have fixed pins but these
pins are exposed as jack-detectable. Thus the driver tries to control
the power-map dynamically per jack detection where it never gets on.
This patch corrects the condition check for fixed pins so that the
power-map is set always for these pins.
NOTE: this is no simple backport from 3.5 kernel. Since 3.5 kernel
had significant code change in the relevant part, I fixed this
differently.
BugLink: http://bugs.launchpad.net/bugs/1013183
Reported-by: Luis Henriques luis.henriq...@canonical.com
Signed-off-by: Takashi Iwai ti...@suse.de
---
The original fix was already merged to Linus tree yesterday.
Please pick this up manually. Thank!
sound/pci/hda/patch_sigmatel.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 7b7a516..2b973f5 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -4457,7 +4457,7 @@ static int stac92xx_init(struct hda_codec *codec)
AC_PINCTL_IN_EN);
for (i = 0; i spec-num_pwrs; i++) {
hda_nid_t nid = spec-pwr_nids[i];
- int pinctl, def_conf;
+ unsigned int pinctl, def_conf;
/* power on when no jack detection is available */
/* or when the VREF is used for controlling LED */
@@ -4484,7 +4484,7 @@ static int stac92xx_init(struct hda_codec *codec)
def_conf = get_defcfg_connect(def_conf);
/* skip any ports that don't have jacks since presence
* detection is useless */
- if (def_conf != AC_JACK_PORT_NONE
+ if (def_conf != AC_JACK_PORT_COMPLEX ||
!is_jack_detectable(codec, nid)) {
stac_toggle_power_map(codec, nid, 1);
continue;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
